[PATCH 1/5 v2] drivers/gpio/gpio-omap.c: convert comma to semicolon
From: Julia Lawall julia.law...@lip6.fr Replace a comma between expression statements by a semicolon. This changes the semantics of the code, but given the current indentation appears to be what is intended. A simplified version of the semantic patch that performs this transformation is as follows: (http://coccinelle.lip6.fr/) // smpl @r@ expression e1,e2,e; type T; identifier i; @@ e1 -, +; e2; // /smpl Signed-off-by: Julia Lawall julia.law...@lip6.fr --- Not tested. The first version did a different transformation to avoid changing the semantics. This one leaves the layout as it is, but changes the semantics. drivers/gpio/gpio-omap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index dfeb3a3..9f19ec9 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1030,7 +1030,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start, ct-chip.irq_set_type = gpio_irq_type; if (bank-regs-wkup_en) - ct-chip.irq_set_wake = gpio_wake_enable, + ct-chip.irq_set_wake = gpio_wake_enable; ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride; irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
Hi,
On Fri, 2013-08-09 at 10:31 -0500, Kumar Gala wrote:
On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS)
probably good to spell out Synopsys rather than SNPS
I could make it look like this? Synopsys (SNPS)
and HS, SS PHY's controll and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
.../devicetree/bindings/usb/msm-ssusb.txt | 101
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..7a97163
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,101 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
We should have a heading here like:
DWC3 Highspeed USB PHY
Ok, I will add these headings.
+Required properities :
+- compatible : sould be qcom,dwc3-hsphy;
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ xo : External reference clock 19 MHz
+ sleep_a_clk : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+supply-name-supply : phandle to the regulator device tree node
+Required supply-name are:
+ v1p8 : 1.8v supply for HSPHY
+ v3p3 : 3.3v supply for HSPHY
+ vbus : vbus supply for host mode
+ vddcx : vdd supply for HS-PHY digital circuit operation
+
DWC3 Superspeed USB PHY
+Required properities :
+- compatible : sould be qcom,dwc3-ssphy;
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ xo : External reference clock 19 MHz
+ ref_clk : Reference clock - used in host mode.
+supply-name-supply : phandle to the regulator device tree node
+Required supply-name are:
+ v1p8 : 1.8v supply for SS-PHY
+ vddcx : vdd supply for SS-PHY digital circuit operation
+
DWC3 controller
+Required properties :
+- compatible : should be qcom,dwc3
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ core_clk : Master/Core clock, have to be = 125 MHz for SS
+ operation and = 60MHz for HS operation
+ iface_clk : System bus AXI clock
+ sleep_clk : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+ utmi_clk : Generated by HS-PHY. Used to clock the low power
+ parts of thr HS Link layer.
+
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+
+Sub nodes:
+- Sub node for DWC3 USB3 controller.
+ This sub node is required property for device node. The properties
+ of this subnode are specified in dwc3.txt.
Is tx-fifo-resize required for qcom,dwc3? if so we should call that out in
the binding.
It looks like this is used in apq8084.dtsi (codeaurora repo)
+
+Example device nodes:
+
+ dwc3_hsphy: phy@f92f8800 {
+ compatible = qcom,dwc3-hsphy;
+ reg = 0xf92f8800 0x30;
+
+ clocks = cxo, usb2a_phy_sleep_cxc;
+ clock-names = xo, sleep_a_clk;
+
+ vbus-supply = supply;
+ vddcx-supply = supply;
+ v1p8-supply = supply;
+ v3p3-supply = supply;
+ };
+
+ dwc3_ssphy: phy@f92f8830 {
+ compatible = qcom,dwc3-ssphy;
+ reg = 0xf92f8830 0x30;
+
+ clocks = cxo, usb30_mock_utmi_cxc;
+ clock-names = xo, ref_clk;
+
+ vddcx-supply = supply;
+ v1p8-supply = supply;
+ };
+
+ usb@fd4ab000 {
+ compatible = qcom,dwc3;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xfd4ab000 0x4;
+
+ clocks = usb30_master_cxc, sys_noc_usb3_axi_cxc,
+ usb30_sleep_cxc, usb30_mock_utmi_cxc;
+ clock-names = core_clk, iface_clk, sleep_clk, utmi_clk;
+
+ gdsc-supply = supply;
+ ranges;
+
+ dwc3@f920 {
+ compatible = snps,dwc3;
+ reg = 0xf920 0xcd00;
+ interrupts = 0 131 0;
+ interrupt-names = irq;
I'd drop interrupt-names since its not terribly meaningful w/a single IRQ
Ok.
Thanks,
Ivan
+ usb-phy = dwc3_hsphy, dwc3_ssphy;
+
Re: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
[]..
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = 1 13 0x308,
+1 14 0x308;
+ clock-frequency = 6144000;
+ };
+ };
The cpu nodes should have a reg matching their unit-address, and a
device_type = cpu.
The timer nodes should *not* be under the CPU nodes. They should be
under under the root node. I realise that it makes intuitive sense to
describe per-cpu resources this way, but that's not the way the bindings
are intended to be used (does thei DT even work?).
No virtual/hypervisor interrupts?
Mark, all valid points. I just updated the patch to include all the missing
interrupts and registers for timer and gic and moved the timer node out as
its supposed to be.
Do you really need the clock-frequency property? It's far preferrable to
have your bootloader do the right thing and program CNTFRQ with the
correct value.
I kept the clock-frequency property since our bootloader does not handle this
and I am not sure if its a good idea to have the dependency on bootloader
to do this.
Updated patch:
From 4d2e7cfe8a8a37686a4af26f320ab0d66acb Mon Sep 17 00:00:00 2001
From: R Sricharan r.sricha...@ti.com
Date: Thu, 7 Feb 2013 16:14:00 +0530
Subject: [PATCH] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm
board
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts | 140 ++
arch/arm/boot/dts/dra7.dtsi| 568
3 files changed, 710 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/dra7-evm.dts
create mode 100644 arch/arm/boot/dts/dra7.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
- am43x-epos-evm.dtb
+ am43x-epos-evm.dtb \
+ dra7-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 000..21fe16b
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) 2013 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 dra7.dtsi
+
+/ {
+ model = TI DRA7;
+ compatible = ti,dra7-evm, ti,dra752, ti,dra7;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x6000; /* 1536 MB */
+ };
+};
+
+dra7_pmx_core {
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x400 0x6 /* i2c1_sda */
+ 0x404 0x6 /* i2c1_scl */
+ ;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x408 0x6 /* i2c2_sda */
+ 0x40c 0x6 /* i2c2_scl */
+ ;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins =
+ 0x410 0x6 /* i2c3_sda */
+ 0x414 0x6 /* i2c3_scl */
+ ;
+ };
+
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins =
+ 0x3a4 0x4 /* spi2_clk */
+ 0x3a8 0x4 /* spi2_d1 */
+ 0x3ac 0x4 /* spi2_d0 */
+ 0x3b0 0xc /* spi2_cs0 */
+ 0x3b4 0xc /* spi2_cs1 */
+ 0x3b8 0xe0006 /* spi2_cs2 */
+ 0x3bc 0xe0006 /* spi2_cs3 */
+ ;
+ };
+
+ mcspi2_pins:
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Mon, 2013-08-12 at 13:04 -0500, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 10:31:58AM -0500, Kumar Gala wrote: On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) probably good to spell out Synopsys rather than SNPS Synopsys (the company) has always used snps in their bindings though. +Required properities : +- compatible : sould be qcom,dwc3-hsphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + sleep_a_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for HSPHY + v3p3 : 3.3v supply for HSPHY + vbus : vbus supply for host mode + vddcx : vdd supply for HS-PHY digital circuit operation I believe these regulators belong to the PHY, not DWC3. Please write a PHY driver. There is already usb phy drivers for these?? [PATCH v2 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core +Required properities : +- compatible : sould be qcom,dwc3-ssphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + ref_clk : Reference clock - used in host mode. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for SS-PHY + vddcx : vdd supply for SS-PHY digital circuit operation likewise, these regulators should be moved to the PHY driver. +Required properties : +- compatible : should be qcom,dwc3 +- reg : offset and length of the register set in the memory map + offset and length of the TCSR register for routing USB + signals to either picoPHY0 or picoPHY1. +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + core_clk : Master/Core clock, have to be = 125 MHz for SS + operation and = 60MHz for HS operation + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). + utmi_clk : Generated by HS-PHY. Used to clock the low power + parts of thr HS Link layer. + +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. + +Sub nodes: +- Sub node for DWC3 USB3 controller. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. Is tx-fifo-resize required for qcom,dwc3? if so we should call that out in the binding. AFAICT that's only needed for OMAP5 ES1.0. Unless Qualcomm also screwed up default TX FIFO sizes :-p Or it is intentional? :-) Look at [1] dwc3@f920 Ivan [1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/boot/dts/apq8084.dtsi?h=msm-3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] DRA7xx core support
* Rajendra Nayak rna...@ti.com [130812 04:41]: ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board Looks like you just updated the dts patch based on the comments from Mark? Actually can you please just drop the .dts patch from this series so it can be queued separately by Benoit and then reply with an updated pull request. 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: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach d-gerl...@ti.com wrote: From: Vaibhav Bedia vaibhav.be...@ti.com AM335x supports various low power modes as documented in section 8.1.4.3 of the AM335x TRM which is available @ http://www.ti.com/litv/pdf/spruh73f DeepSleep0 mode offers the lowest power mode with limited wakeup sources without a system reboot and is mapped as the suspend state in the kernel. In this state, MPU and PER domains are turned off with the internal RAM held in retention to facilitate resume process. As part of the boot process, the assembly code is copied over to OCMCRAM using the OMAP SRAM code. AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU in DeepSleep0 entry and exit. WKUP_M3 takes care of the clockdomain and powerdomain transitions based on the intended low power state. MPU needs to load the appropriate WKUP_M3 binary onto the WKUP_M3 memory space before it can leverage any of the PM features like DeepSleep. The IPC mechanism between MPU and WKUP_M3 uses a mailbox sub-module and 8 IPC registers in the Control module. MPU uses the assigned Mailbox for issuing an interrupt to WKUP_M3 which then goes and checks the IPC registers for the payload. WKUP_M3 has the ability to trigger on interrupt to MPU by executing the sev instruction. In the current implementation when the suspend process is initiated MPU interrupts the WKUP_M3 to let it know about the intent of entering DeepSleep0 and waits for an ACK. When the ACK is received MPU continues with its suspend process to suspend all the drivers and then jumps to assembly in OCMC RAM. The assembly code puts the PLLs in bypass, puts the external RAM in self-refresh mode and then finally execute the WFI instruction. Execution of the WFI instruction triggers another interrupt to the WKUP_M3 which then continues wiht the power down sequence wherein the clockdomain and powerdomain transition takes place. As part of the sleep sequence, WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI execution on WKUP_M3 causes the hardware to disable the main oscillator of the SoC. When a wakeup event occurs, WKUP_M3 starts the power-up sequence by switching on the power domains and finally enabling the clock to MPU. Since the MPU gets powered down as part of the sleep sequence in the resume path ROM code starts executing. The ROM code detects a wakeup from sleep and then jumps to the resume location in OCMC which was populated in one of the IPC registers as part of the suspend sequence. The low level code in OCMC relocks the PLLs, enables access to external RAM and then jumps to the cpu_resume code of the kernel to finish the resume process. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Dave Gerlach d-gerl...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@linaro.org --- arch/arm/mach-omap2/pm33xx.c | 474 + arch/arm/mach-omap2/pm33xx.h | 77 +++ arch/arm/mach-omap2/wkup_m3.c | 183 3 files changed, 734 insertions(+) create mode 100644 arch/arm/mach-omap2/pm33xx.c create mode 100644 arch/arm/mach-omap2/pm33xx.h create mode 100644 arch/arm/mach-omap2/wkup_m3.c diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c new file mode 100644 index 000..d291c76 --- /dev/null +++ b/arch/arm/mach-omap2/pm33xx.c @@ -0,0 +1,474 @@ +/* + * AM33XX Power Management Routines + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ + * Vaibhav Bedia vaibhav.be...@ti.com + * + * 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 version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/kernel.h +#include linux/init.h +#include linux/cpu.h +#include linux/err.h +#include linux/firmware.h +#include linux/io.h +#include linux/platform_device.h +#include linux/sched.h +#include linux/suspend.h +#include linux/completion.h +#include linux/module.h +#include linux/interrupt.h +#include linux/ti_emif.h +#include linux/omap-mailbox.h + +#include asm/suspend.h +#include asm/proc-fns.h +#include asm/sizes.h +#include asm/fncpy.h +#include asm/system_misc.h + +#include pm.h +#include cm33xx.h +#include pm33xx.h +#include control.h +#include common.h +#include clockdomain.h +#include powerdomain.h +#include omap_hwmod.h +#include omap_device.h +#include soc.h +#include sram.h + +static void __iomem
Re: [PATCH v2 1/1] MAINTAINERS: update BenoƮt Cousson email address
* Benoit Cousson bcous...@baylibre.com [130812 07:22]: Here is my official new email address. I'll repost it properly, except if Tony is fine taking it like that. Thanks applied into omap-for-v3.11/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/22] OMAPDSS: DT support
* Tomi Valkeinen tomi.valkei...@ti.com [130809 01:46]: So as is evident, I have things in my mind that should be improved. Maybe the most important question for short term future is: Can we add DSS DT bindings for OMAP4 as unstable bindings? It would give us some proper testing of the related code, and would also allow us to remove the related hacks (which don't even work quite right). However, I have no idea yet when the unstable DSS bindings would turn stable. If we shouldn't add the bindings as unstable, when should the bindings be added? Wait until CDF is in the mainline, and use that? I don't think we should add any temporary bindings as it's going to be a pain to support those in the long run. I suggest you initially just stick to established bindings for the basic hardware IO address and interrupts etc, then those should still be valid with the generic panel bindings later on. 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Paul Benoit, Does this series look OK to you guys to queue or ack? * Afzal Mohammed af...@ti.com [130802 06:42]: Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. I am aware that this series adds around +1K lines to platform. We in TI, here are making efforts to clean platform code gradually and keep to minumum the code being added to support new SoC's. Please note that this SoC support series has positive diffstat of just above 1K only. This compared to last SoC that was supported in OMAP family during last merge window is way less (this is only around 1/8th postive diffstat of it). Clock data is not added in this series, instead directly clock tree in DT with driver would be used, this is a work in progress. And as seen from recent OMAP clock tree DT conversion series, there are serious efforts ongoing to that end. Also we will start working on moving hwmod away from platform folders. In addition, recently there was a PRCM cleanup by Rajendra Nayak that removed near to 11K lines. Considering the above facts, I request the maintainers to consider this series for the next merge window. Currently there is no public TRM available for AM43x. Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that are being DT'fied. Additional DTS changes (posted separate from this series) are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Regards Afzal Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 Vaibhav Bedia (1): ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4 arch/arm/mach-omap2/Makefile|5 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 arch/arm/mach-omap2/cm33xx.c| 30 +- arch/arm/mach-omap2/cm33xx.h| 28 +- arch/arm/mach-omap2/cminst44xx.c| 58 ++- arch/arm/mach-omap2/cminst44xx.h| 25 +- arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_hwmod.c|8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 691 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c | 145 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 13 files changed, 1198 insertions(+), 143 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 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
Re: [PATCH 1/3] misc: Add crossbar driver
* Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. 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 v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
[Adding Marc to Cc]
On Tue, Aug 13, 2013 at 08:24:31AM +0100, Rajendra Nayak wrote:
[]..
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = 1 13 0x308,
+1 14 0x308;
+ clock-frequency = 6144000;
+ };
+ };
The cpu nodes should have a reg matching their unit-address, and a
device_type = cpu.
The timer nodes should *not* be under the CPU nodes. They should be
under under the root node. I realise that it makes intuitive sense to
describe per-cpu resources this way, but that's not the way the bindings
are intended to be used (does thei DT even work?).
No virtual/hypervisor interrupts?
Mark, all valid points. I just updated the patch to include all the missing
interrupts and registers for timer and gic and moved the timer node out as
its supposed to be.
Great!
Do you really need the clock-frequency property? It's far preferrable to
have your bootloader do the right thing and program CNTFRQ with the
correct value.
I kept the clock-frequency property since our bootloader does not handle this
and I am not sure if its a good idea to have the dependency on bootloader
to do this.
There is precedent for handling it this way, but it would be far nicer
to fix the bootloader to set CNTFRQ. For one thing it's only writeable
from the secure side, so a host os can't fix it up for guests that might
depend on it rather than dt. I realise it's not necessarily as simple as
it sounds to fix that up, however.
[...]
+ timer {
+ compatible = arm,armv7-timer;
+ /* PPI secure/nonsecure IRQ */
The comment's now stale, and I don't think it's necessary - the binding
defines the order these are in.
+ interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 14 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 11 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW),
+GIC_PPI 10 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW);
+ clock-frequency = 6144000;
+ };
Thanks,
Mark.
--
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] usb: musb: convert to devm_* to allocate resources
No functional change. Used devm_kzalloc and devm_clk_get instead of
kzalloc and clk_get.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
only *compile* tested.
drivers/usb/musb/am35x.c | 40 ++--
drivers/usb/musb/blackfin.c |8 ++--
drivers/usb/musb/da8xx.c | 28 ++--
drivers/usb/musb/davinci.c | 28 ++--
drivers/usb/musb/musb_dsps.c |4 +---
drivers/usb/musb/tusb6010.c | 16 ++--
drivers/usb/musb/ux500.c | 28 ++--
7 files changed, 53 insertions(+), 99 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 5c310c6..50ba013 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -465,7 +465,7 @@ static int am35x_probe(struct platform_device *pdev)
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
goto err0;
@@ -474,33 +474,33 @@ static int am35x_probe(struct platform_device *pdev)
musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err0;
}
- phy_clk = clk_get(pdev-dev, fck);
+ phy_clk = devm_clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
- goto err3;
+ goto err1;
}
- clk = clk_get(pdev-dev, ick);
+ clk = devm_clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err4;
+ goto err1;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
- goto err5;
+ goto err1;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err6;
+ goto err2;
}
musb-dev.parent= pdev-dev;
@@ -520,40 +520,31 @@ static int am35x_probe(struct platform_device *pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err7;
+ goto err3;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err7;
+ goto err3;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err7;
+ goto err3;
}
return 0;
-err7:
+err3:
clk_disable(clk);
-err6:
+err2:
clk_disable(phy_clk);
-err5:
- clk_put(clk);
-
-err4:
- clk_put(phy_clk);
-
-err3:
- platform_device_put(musb);
-
err1:
- kfree(glue);
+ platform_device_put(musb);
err0:
return ret;
@@ -566,9 +557,6 @@ static int am35x_remove(struct platform_device *pdev)
platform_device_unregister(glue-musb);
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
- clk_put(glue-clk);
- clk_put(glue-phy_clk);
- kfree(glue);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 72e2056..70f4c5d 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -457,7 +457,7 @@ static int bfin_probe(struct platform_device *pdev)
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
goto err0;
@@ -466,7 +466,7 @@ static int bfin_probe(struct platform_device *pdev)
musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err0;
}
musb-dev.parent= pdev-dev;
@@ -517,9 +517,6 @@ static int bfin_probe(struct platform_device *pdev)
err3:
platform_device_put(musb);
-err1:
- kfree(glue);
-
err0:
return ret;
}
@@ -529,7 +526,6 @@ static int bfin_remove(struct platform_device *pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- kfree(glue);
Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs
Am Mittwoch, 31. Juli 2013, 01:44:53 schrieb Linus Walleij: On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely grant.lik...@linaro.org wrote: On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij linus.wall...@linaro.org wrote: To solve this dilemma, perform an interrupt consistency check when adding a GPIO chip: if the chip is both gpio-controller and interrupt-controller, walk all children of the device tree, check if these in turn reference the interrupt-controller, and if they do, loop over the interrupts used by that child and perform gpio_reques() and gpio_direction_input() on these, making them unreachable from the GPIO side. Ugh, that's pretty awful, and it doesn't actually solve the root problem of the GPIO and IRQ subsystems not cooperating. It's also a very DT-centric solution even though we're going to see the exact same issue on ACPI machines. The problem is that the patches for OMAP that I applied and now have had to revert solves it in an even uglier way, leading to breaking boards, as was noticed. The approach in this patch has the potential to actually work without regressing a bunch of boards... I fully agree. I spent many time understanding the problem and reading mails to see what happend so far. This is by far the best way to solve the problem that was proposed until now. I support that approach. Whether this is a problem in ACPI or not remains to be seen, but I'm not sure about that. Device trees allows for a GPIO line to be used as an interrupt source and GPIO line orthogonally, and that is the root of this problem. Does ACPI have the same problem, or does it impose natural restrictions on such use cases? Is requesting GPIOs directly common in the ACPI world? Does ACPI allow to use GPIOs for interrupts? And even if ACPI had the same problems than device tree, finding a common solution seems very difficult to me. I also prefer Linus' way here. This can be fixes in gpiolib for the device tree path and this is ok. We have to solve the problem in a better way than that. Linus asked for real solutions more than once. Can anybody propose a better way ? This has the following undesired effects: - The GPIOlib subsystem is not aware that the line is in use and willingly lets some other consumer perform gpio_request() on it, leading to a complex resource conflict if it occurs. If a gpio line is being both requested as a gpio and used as an interrupt line, then either a) it's a bug, or b) the gpio line needs to be used as input only so it is compatible with irq usage. b) should be supportable. Yes this is what I'm saying too I think... The bug in (a) manifested itself in the OMAP patch with no real solution in sight. - The GPIO debugfs file claims this GPIO line is free. Surely we can fix this. I still don't see a problem of having the controller request the gpio when it is claimed as an irq if we can get around the problem of another user performing a /valid/ request on the same GPIO line. The solution may be to have a special form of request or flag that allows it to be shared. I don't see how sharing works here, or how another user, i.e. another one than the user wanting to recieve the IRQ, can validly request such a line? What would the usecase for that valid request be? I also don't see the usecase for that. Sure, that can be done, but it is of no use. If it shows, that someone really needs this, it can be implemented later. Basically I believe these two things need to be exclusive in the DT world: A: request_irq(a resource passed from interrupts); - core implicitly performs gpio_request() gpio_direction_input() B: gpio_request(a resource passed from gpios); gpio_direction_input() request_irq(gpio_to_irq()) Never both. And IIUC that was what happened in the OMAP case. ACK. - The line direction of the interrupt GPIO line is not explicitly set as input, even though it is obvious that such a line need to be set up in this way, often making the system depend on boot-on defaults for this kind of settings. Should also be solvable if the gpio request problem is solved. Agreed... To push the discussion a bit further, I took Linus patch and extended it so that it can be tested now on real world hardware. I tested it on my device tree enabled board and it works fine here. Refer to [1], [2] for version 2 of the patch. It completely scans the device tree for interrupt-controller users of the gpio_chip in question. It requests the needed gpios and sets them as input. If the gpio_chip is removed, it also frees the gpio lines. Folks please help testing! Thanks, Lars [1] http://marc.info/?l=linux-kernelm=137638745909335w=2 [2] https://patchwork.kernel.org/patch/2843525/ -- 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
[PATCH 2/2] usb: musb: pass on all the required resources from glue to musb core
musb glue have to pass either 2 resources or 3 resources to the musb
core (musb core irq number, dma irq number and a memory
resource). So allocated *resource* for musb core in glue (based on the number
of resources in glue), copy all the resources from glue to core before creating
the musb core device. This prevents the need to know the number of resources
beforehand.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Tested omap4 panda and omap3 beagle for enumeration .
All other platforms compile tested only.
drivers/usb/musb/am35x.c| 16 +++-
drivers/usb/musb/blackfin.c | 28 ++--
drivers/usb/musb/da8xx.c| 28 ++--
drivers/usb/musb/davinci.c | 28 ++--
drivers/usb/musb/omap2430.c | 33 ++---
drivers/usb/musb/tusb6010.c | 33 ++---
drivers/usb/musb/ux500.c| 28 ++--
7 files changed, 99 insertions(+), 95 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 50ba013..6ea907d 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -457,8 +457,10 @@ static u64 am35x_dmamask = DMA_BIT_MASK(32);
static int am35x_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = dev_get_platdata(pdev-dev);
+ struct resource *musb_resources;
struct platform_device *musb;
struct am35x_glue *glue;
+ int i;
struct clk *phy_clk;
struct clk *clk;
@@ -477,6 +479,11 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}
+ musb_resources = devm_kzalloc(pdev-dev, pdev-num_resources *
+ sizeof(*musb_resources), GFP_KERNEL);
+ if (!musb_resources)
+ goto err1;
+
phy_clk = devm_clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
@@ -516,7 +523,14 @@ static int am35x_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
- ret = platform_device_add_resources(musb, pdev-resource,
+ for (i = 0; i pdev-num_resources; i++) {
+ musb_resources[i].name = pdev-resource[i].name;
+ musb_resources[i].start = pdev-resource[i].start;
+ musb_resources[i].end = pdev-resource[i].end;
+ musb_resources[i].flags = pdev-resource[i].flags;
+ }
+
+ ret = platform_device_add_resources(musb, musb_resources,
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 70f4c5d..9331ca9 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -450,10 +450,11 @@ static u64 bfin_dmamask = DMA_BIT_MASK(32);
static int bfin_probe(struct platform_device *pdev)
{
- struct resource musb_resources[2];
+ struct resource *musb_resources;
struct musb_hdrc_platform_data *pdata = dev_get_platdata(pdev-dev);
struct platform_device *musb;
struct bfin_glue*glue;
+ int i;
int ret = -ENOMEM;
@@ -469,6 +470,11 @@ static int bfin_probe(struct platform_device *pdev)
goto err0;
}
+ musb_resources = devm_kzalloc(pdev-dev, pdev-num_resources *
+ sizeof(*musb_resources), GFP_KERNEL);
+ if (!musb_resources)
+ goto err3;
+
musb-dev.parent= pdev-dev;
musb-dev.dma_mask = bfin_dmamask;
musb-dev.coherent_dma_mask = bfin_dmamask;
@@ -480,21 +486,15 @@ static int bfin_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
- memset(musb_resources, 0x00, sizeof(*musb_resources) *
- ARRAY_SIZE(musb_resources));
-
- musb_resources[0].name = pdev-resource[0].name;
- musb_resources[0].start = pdev-resource[0].start;
- musb_resources[0].end = pdev-resource[0].end;
- musb_resources[0].flags = pdev-resource[0].flags;
-
- musb_resources[1].name = pdev-resource[1].name;
- musb_resources[1].start = pdev-resource[1].start;
- musb_resources[1].end = pdev-resource[1].end;
- musb_resources[1].flags = pdev-resource[1].flags;
+ for (i = 0; i pdev-num_resources; i++) {
+ musb_resources[i].name = pdev-resource[i].name;
+ musb_resources[i].start = pdev-resource[i].start;
+ musb_resources[i].end = pdev-resource[i].end;
+ musb_resources[i].flags = pdev-resource[i].flags;
+ }
ret = platform_device_add_resources(musb, musb_resources,
-
Re: [PATCH 1/2] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*
Hi Kishon,
On 08/13/2013 02:37 PM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so added a
compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible
types for backward compatibility.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/extcon/extcon-twl.txt |3 ++-
drivers/extcon/extcon-palmas.c |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
index 58f531a..5be4afc 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
@@ -2,7 +2,8 @@ EXTCON FOR TWL CHIPS
PALMAS USB COMPARATOR
Required Properties:
- - compatible : Should be ti,palmas-usb or ti,twl6035-usb
+ - compatible : Should be ti,palmas-usb or ti,twl6035-usb or
+ ti,palmas-usb-vid.
- vbus-supply : phandle to the regulator device tree node.
Optional Properties:
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index b752a0a..4f83fae 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -223,6 +223,7 @@ static int palmas_usb_remove(struct platform_device *pdev)
static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,palmas-usb, },
+ { .compatible = ti,palmas-usb-vid, },
{ .compatible = ti,twl6035-usb, },
{ /* end */ }
};
This patch has a conflict. You have to always implement patch on extcon branch
including latest patch. You need to resend v2 patch based on extcon-next branch.
'extcon-twl.txt' is renamed as 'extcon-palmas.txt' on following patch:
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-nextid=80d644b297dc26c5126858555044edef76f4ffe8
And, 'vbus-supply' phandle was removed on following patch:
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-nextid=26ece4f0b7d2264282d9077d1843ff1e98189b6c
Thanks,
Chanwoo Choi
--
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 1/3] misc: Add crossbar driver
Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. Regards, Sricharan -- 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 1/2] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*
On Tuesday 13 August 2013 03:24 PM, Chanwoo Choi wrote:
Hi Kishon,
On 08/13/2013 02:37 PM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VID detector, so added a
compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible
types for backward compatibility.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/extcon/extcon-twl.txt |3 ++-
drivers/extcon/extcon-palmas.c |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
index 58f531a..5be4afc 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
@@ -2,7 +2,8 @@ EXTCON FOR TWL CHIPS
PALMAS USB COMPARATOR
Required Properties:
- - compatible : Should be ti,palmas-usb or ti,twl6035-usb
+ - compatible : Should be ti,palmas-usb or ti,twl6035-usb or
+ ti,palmas-usb-vid.
- vbus-supply : phandle to the regulator device tree node.
Optional Properties:
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index b752a0a..4f83fae 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -223,6 +223,7 @@ static int palmas_usb_remove(struct platform_device
*pdev)
static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,palmas-usb, },
+{ .compatible = ti,palmas-usb-vid, },
{ .compatible = ti,twl6035-usb, },
{ /* end */ }
};
This patch has a conflict. You have to always implement patch on extcon branch
including latest patch. You need to resend v2 patch based on extcon-next
branch.
'extcon-twl.txt' is renamed as 'extcon-palmas.txt' on following patch:
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-nextid=80d644b297dc26c5126858555044edef76f4ffe8
And, 'vbus-supply' phandle was removed on following patch:
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-nextid=26ece4f0b7d2264282d9077d1843ff1e98189b6c
Alright. I'll send the patch shortly.
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 v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On 2013-08-13 10:46, Mark Rutland wrote:
[Adding Marc to Cc]
On Tue, Aug 13, 2013 at 08:24:31AM +0100, Rajendra Nayak wrote:
[]..
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = 1 13 0x308,
+1 14 0x308;
+ clock-frequency = 6144000;
+ };
+ };
The cpu nodes should have a reg matching their unit-address, and a
device_type = cpu.
The timer nodes should *not* be under the CPU nodes. They should
be
under under the root node. I realise that it makes intuitive sense
to
describe per-cpu resources this way, but that's not the way the
bindings
are intended to be used (does thei DT even work?).
No virtual/hypervisor interrupts?
Mark, all valid points. I just updated the patch to include all the
missing
interrupts and registers for timer and gic and moved the timer node
out as
its supposed to be.
Great!
Do you really need the clock-frequency property? It's far
preferrable to
have your bootloader do the right thing and program CNTFRQ with
the
correct value.
I kept the clock-frequency property since our bootloader does not
handle this
and I am not sure if its a good idea to have the dependency on
bootloader
to do this.
There is precedent for handling it this way, but it would be far
nicer
to fix the bootloader to set CNTFRQ. For one thing it's only
writeable
from the secure side, so a host os can't fix it up for guests that
might
depend on it rather than dt. I realise it's not necessarily as simple
as
it sounds to fix that up, however.
Indeed, having the wrong CNTFRQ in the host has the unfortunate effect
of propagating the crap into the guests.
While this can be worked around for Linux guests (you have to hack the
DT passed to the guests, which is very unpleasant at best and varies
from one host to another), there is nothing you can do for non-DT
guests.
So please, fix it in your firmware/boot-ROM while it is still time.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
--
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] serial: OMAP: add RS485 support
On 12/08/13 23:56, Greg KH wrote: On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote: This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Fix incorrect logic in serial_omap_config_rs485() drivers/tty/serial/omap-serial.c | 178 ++ 1 file changed, 178 insertions(+) This doesn't apply to my tty-next branch: checking file drivers/tty/serial/omap-serial.c Hunk #1 FAILED at 40. Hunk #2 succeeded at 162 (offset 6 lines). Hunk #3 succeeded at 280 (offset 5 lines). Hunk #4 succeeded at 378 (offset 6 lines). Hunk #5 succeeded at 1312 (offset 8 lines). Hunk #6 succeeded at 1405 (offset 8 lines). Hunk #7 succeeded at 1528 (offset 10 lines). Hunk #8 FAILED at 1638. Hunk #9 succeeded at 1705 (offset 6 lines). 2 out of 9 hunks FAILED so I can't apply it, sorry. It was applied on top of Linus' tree, if that makes any difference. I'll rebase onto yours and re-post the patch. -- 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: Pandaboard: DT Boot fails when initramfs is loaded
On Mon, Aug 12, 2013 at 03:17:07PM +0300, Roger Quadros wrote: What is the size of your uImage and uInitrd? Are you sure the load addresses are far apart to not cause overwrite? There should be about 23M space for the uImage (0x8160-0x8000) and ca. 245MB for the uInitrd (0x9000 - 0x8160). The actual files are much smaller than that: -rw-r--r-- 1 root root 2.7M Mai 25 17:59 uImage-3.10.0-rc1+ -rw-r--r-- 1 root root 4.9M Mai 25 18:00 uInitrd-3.10.0-rc1+ -rw-r--r-- 1 root root 2.8M Aug 11 13:27 uImage-3.11.0-rc4+ -rw-r--r-- 1 root root 4.9M Aug 11 13:27 uInitrd-3.11.0-rc4+ -rw-r--r-- 1 root root 18K Aug 11 13:01 omap4-panda.dtb Apart from that I was able to boot the 3.10 kernel without using the device tree information. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
correct binding information to the PHY framework. I think we can drop having
this non-dt support in PHY framework? I see only one platform (OMAP3) going
to
be needing this non-dt support and we can use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the controller?
It should be deterministic as the PHY framework assigns its own id and we
*don't* want to add any requirement that the ID must be assigned manually
without using PLATFORM_DEVID_AUTO. We can get rid of *phy_init_data* in the v10
patch series.
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 v2] N900: add device tree
Hi Pavel,
I finally got released by the aliens. It took longer than expected and
beside a small scar on the back of my neck, I feel pretty OK.
I just have few cosmetic comments on top of Javier's ones.
On 11/08/2013 17:02, Javier Martinez Canillas wrote:
Hi Pavel,
some minor comments about your patch below
On Sat, Jul 13, 2013 at 2:17 PM, Pavel Machek pa...@ucw.cz wrote:
This adds device tree with neccessary support to boot with functional
Typo^
video (on both emulator and real N900 device).
Signed-off-by: Pavel Machek pa...@ucw.cz
---
From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
can be enabled on 3.10, and tested it on that kernel.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..1950aed 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -141,6 +141,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3-n900.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 000..fb461bf
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2013 Pavel Machek pa...@ucw.cz
+ * Copyright 2013 Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * 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/ omap34xx.dtsi
+
The current trend is to use #include omap34xx.dtsi instead /include/
in order to use the C pre-processor and the macros defined in
include/dt-bindings.
+/ {
+ model = Nokia N900;
+ compatible = nokia,omap3-n900, ti,omap3;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+};
+
+i2c1 {
+ clock-frequency = 220;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+twl_gpio {
+ ti,pullups = 0x0;
+ ti,pulldowns= 0x03ff3f; /* BIT(0..5) | BIT(8..17) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+mcspi1 {
+ // For some reason, touchscreen is neccessary for screen to work at
Same typo than before---^
+ // all on real hw. It works well without it on emulator.
+ //
+ // Also... order in the device tree actually matters here.
Nit: Please use the regular Linux style comment.
The order should not matter at all in DT, it should be a static
representation of the HW, so there is probably something wrong in the
code that make the device creation order important.
+ tsc2005@0 {
+ compatible = tsc2005;
+ spi-max-frequency = 600;
+ reg = 0;
+ };
+ mipid@2 {
+ compatible = acx565akm;
+ spi-max-frequency = 600;
+ reg = 2;
+ // turbo_mode = 0,
+ // cs_per_word = 0
+ };
+};
You should remove these properties if they are not being used instead
of keeping them as commented.
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 2;
+ power = 50;
+};
Beside my comments and the ones from Javier, it looks good.
If you can repost ASAP, I'll take it right after.
It will be the first one in the list.
Thanks,
Benoit
--
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: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
Hi,
On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote:
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/dpll.txt | 70 +++
arch/arm/mach-omap2/clock.h| 144 +-
arch/arm/mach-omap2/clock3xxx.h|2 -
drivers/clk/Makefile |1 +
drivers/clk/ti/Makefile|3 +
drivers/clk/ti/dpll.c | 488
include/linux/clk/ti.h | 164 +++
7 files changed, 727 insertions(+), 145 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt
create mode 100644 drivers/clk/ti/Makefile
create mode 100644 drivers/clk/ti/dpll.c
create mode 100644 include/linux/clk/ti.h
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
new file mode 100644
index 000..dcd6e63
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -0,0 +1,70 @@
+Binding for Texas Instruments DPLL clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped DPLL with usually two selectable input clocks
+(reference clock and bypass clock), with digital phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) This binding has several
+sub-types, which effectively result in slightly different setup
+for the actual DPLL clock.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of:
+ ti,omap4-dpll-x2-clock,
+ ti,omap3-dpll-clock,
+ ti,omap3-dpll-core-clock,
+ ti,omap3-dpll-per-clock,
+ ti,omap3-dpll-per-j-type-clock,
+ ti,omap4-dpll-clock,
+ ti,omap4-dpll-core-clock,
+ ti,omap4-dpll-m4xen-clock,
+ ti,omap4-dpll-j-type-clock,
+ ti,omap4-dpll-no-gate-clock,
+ ti,omap4-dpll-no-gate-j-type-clock,
+
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
It might be a good idea to use clock-names to clarify which clocks are
present (I notice your examples contain only one clock input).
+- reg : array of register base addresses for controlling the DPLL (some
+ of these can also be left as NULL):
+ reg[0] = control register
+ reg[1] = idle status register
+ reg[2] = autoidle register
+ reg[3] = multiplier / divider set register
Are all of these always present? Using reg-names seems sensible here.
+- ti,clk-ref : link phandle for the reference clock
+- ti,clk-bypass : link phandle for the bypass clock
You already have these in clocks, why do you need them again here?
+
+Optional properties:
+- ti,modes : available modes for the DPLL
Huh? What type is that property? What does it mean?
+- ti,recal-en-bit : recalibration enable bit
+- ti,recal-st-bit : recalibration status bit
+- ti,auto-recal-bit : auto recalibration enable bit
These seem rather low-level, but I see other clock bindings are doing
similar things. When are these needed, and why? What type are they?
+- ti,clkdm-name : clockdomain name for the DPLL
Could you elaborate on what this is for? What constitutes a valid name?
I'm not sure a string is the best way to define the linkage of several
elements to a domain...
+
+Examples:
+ dpll_core_ck: dpll_core_ck@44e00490 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-core-clock;
+ clocks = sys_clkin_ck;
+ reg = 0x44e00490 0x4, 0x44e0045c 0x4, 0x0 0x4,
+ 0x44e00468 0x4;
+ ti,clk-ref = sys_clkin_ck;
+ ti,clk-bypass = sys_clkin_ck;
Huh? Why aren't these both in the clocks property?
[...]
+static inline void __iomem *get_dt_register(struct device_node *node,
+ int index)
+{
+ u32 val;
+
+ of_property_read_u32_index(node, reg, 2 * index, val);
+ if (val)
+ return of_iomap(node, index);
+ else
+ return NULL;
NAK. Use reg-names to handle registers being optional.
[...]
+ clkspec.np = of_parse_phandle(node, ti,clk-ref, 0);
+ dd-clk_ref = of_clk_get_from_provider(clkspec);
+ if (IS_ERR(dd-clk_ref)) {
+ pr_err(%s: ti,clk-ref for %s not found\n, __func__,
+ clk_name);
+ goto cleanup;
+ }
+
+ clkspec.np = of_parse_phandle(node, ti,clk-bypass, 0);
+
Re: [PATCH v2] serial: OMAP: add RS485 support
On Tue, Aug 13, 2013 at 12:22 PM, Mark Jackson mpfj-l...@newflow.co.uk wrote: On 12/08/13 23:56, Greg KH wrote: On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote: This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Fix incorrect logic in serial_omap_config_rs485() drivers/tty/serial/omap-serial.c | 178 ++ 1 file changed, 178 insertions(+) This doesn't apply to my tty-next branch: checking file drivers/tty/serial/omap-serial.c Hunk #1 FAILED at 40. Hunk #2 succeeded at 162 (offset 6 lines). Hunk #3 succeeded at 280 (offset 5 lines). Hunk #4 succeeded at 378 (offset 6 lines). Hunk #5 succeeded at 1312 (offset 8 lines). Hunk #6 succeeded at 1405 (offset 8 lines). Hunk #7 succeeded at 1528 (offset 10 lines). Hunk #8 FAILED at 1638. Hunk #9 succeeded at 1705 (offset 6 lines). 2 out of 9 hunks FAILED so I can't apply it, sorry. It was applied on top of Linus' tree, if that makes any difference. I'll rebase onto yours and re-post the patch. -- Hi Mark, I've seen several attempts to add RS485 support to the omap serial driver and it is always nack-ed. There seems to be concerns about controlling the RTS by software when RS485 is not supported by the UART hardware. Please refer to [1] and [2] for more information. Best regards, Javier [1]: http://comments.gmane.org/gmane.linux.serial/6770 [2]: http://article.gmane.org/gmane.linux.serial/3619/ -- 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 1/1] MAINTAINERS: update BenoƮt Cousson email address
Hi Benoit, On Mon, Aug 12, 2013 at 4:15 PM, Benoit Cousson bcous...@baylibre.com wrote: Hi Javier, Thanks for taking care of that. Sorry if I missed you for so long :-) no worries, welcome back! I had to manage TI layoffs then vacation then starting my new job. I'm glad to know that you have all sorted now :) Best regards, Javier On 12/08/2013 16:03, Javier Martinez Canillas wrote: On Mon, Aug 12, 2013 at 11:09 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Hi Tony, On Mon, Aug 12, 2013 at 9:55 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130811 08:28]: Using the email address listed on MAINTAINERS I keep getting SMTP 550 Invalid recipient errors. Update with what seems to be current BenoƮt's email address to make get_maintainer.pl to stop lying. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Is the linaro.org address still valid? We should probably wait for Benoit to confirm this to avoid more confusion. It seems so, at least I don't get SMTP 550 errors with it. But I agree that is best to wait for Benoit to confirm what is his current address. I just wanted to help... I see that Benoit also has a gmail address. I'm cc'ing him in this thread so he can confirm what is his current email address and MAINTAINERS can be updated so people can send OMAP DT patches to the correct address. Thanks a lot and best regards, Javier Here is my official new email address. I'll repost it properly, except if Tony is fine taking it like that. Regards, Benoit --- From 8a5464b6da7f076b7caa21ac96905b46cf26e269 Mon Sep 17 00:00:00 2001 From: Benoit Cousson bcous...@baylibre.com Date: Fri, 9 Aug 2013 23:19:15 +0200 Subject: [PATCH] MAINTAINERS: Update my email address Goodbye TI. Welcome new life! Signed-off-by: Benoit Cousson bcous...@baylibre.com Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7cacc88..300c9f4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5884,7 +5884,7 @@ F:drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h OMAP DEVICE TREE SUPPORT -M: BenoƮt Cousson b-cous...@ti.com +M: BenoƮt Cousson bcous...@baylibre.com M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org @@ -5964,14 +5964,14 @@ S: Maintained F: drivers/char/hw_random/omap-rng.c OMAP HWMOD SUPPORT -M: BenoƮt Cousson b-cous...@ti.com +M: BenoƮt Cousson bcous...@baylibre.com M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* OMAP HWMOD DATA FOR OMAP4-BASED DEVICES -M: BenoƮt Cousson b-cous...@ti.com +M: BenoƮt Cousson bcous...@baylibre.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.8.1.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: [PATCHv5 05/31] CLK: TI: add support for OMAP gate clock
On Fri, Aug 02, 2013 at 05:25:24PM +0100, Tero Kristo wrote:
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/gate.txt | 41
arch/arm/mach-omap2/clock.h|9 --
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/gate.c | 106
include/linux/clk/ti.h |8 ++
5 files changed, 156 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/gate.txt
create mode 100644 drivers/clk/ti/gate.c
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt
b/Documentation/devicetree/bindings/clock/ti/gate.txt
new file mode 100644
index 000..620a73d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
@@ -0,0 +1,41 @@
+Binding for Texas Instruments gate clock.
+
+This binding uses the common clock binding[1]. This clock is
+quite much similar to the basic gate-clock [2], however,
+it supports a number of additional features. If no register
+is provided for this clock, the code assumes that a clockdomain
+will be controlled instead and the corresponding hw-ops for
+that is used.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+
+Required properties:
+- compatible : shall be ti,gate-clock
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : link to phandle of parent clock
+
+Optional properties:
+- reg : base address for register controlling adjustable gate
Optional? That's odd. If I have a clock with registers, but don't
specify the register, will it still work? i.e. are registerless clocks
really compatible with clocks with registers?.
+- ti,enable-bit : bit shift for programming the clock gate
Why is this needed? Does the hardware vary wildly, or are several clocks
sharing the same register(s)?
+- ti,dss-clk : use DSS hardware OPS for the clock
+- ti,am35xx-clk : use AM35xx hardware OPS for the clock
Those last two sounds like the kind of thing that should be derived from
the compatible string (e.g. ti,am35xx-gate-clock).
+- ti,clkdm-name : clockdomain to control this gate
As previously mentioned, I'm not a fan of this property. It would make
more sense to describe the domain and have an explicit link to it
(either nodes being children of the domain or having a phandle).
[...]
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init = { 0 };
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names = NULL;
+ int i;
+ u32 val;
+
+ clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return;
+ }
+
+ clk_hw-hw.init = init;
+
+ of_property_read_string(node, clock-output-names, clk_name);
+ of_property_read_string(node, ti,clkdm-name, clk_hw-clkdm_name);
+
+ init.name = clk_name;
+ init.flags = 0;
+
+ if (of_property_read_u32_index(node, reg, 0, val)) {
+ /* No register, clkdm control only */
+ init.ops = omap_gate_clkdm_clk_ops;
If they're truly compatible, you can just see if you can of_iomap, and
if not, continue. Your reg values might be wider than 32 bits, and usig
of_property_read_u32 to read this feels wrong.
+ } else {
+ init.ops = omap_gate_clk_ops;
+ clk_hw-enable_reg = of_iomap(node, 0);
+ of_property_read_u32(node, ti,enable-bit, val);
+ clk_hw-enable_bit = val;
What if of_property_read_u32 failed to read the ti,enable-bit
property? One might not be present, it's marked as optional in the
binding description.
+
+ clk_hw-ops = clkhwops_wait;
+
+ if (of_property_read_bool(node, ti,dss-clk))
+ clk_hw-ops = clkhwops_omap3430es2_dss_usbhost_wait;
+
+ if (of_property_read_bool(node, ti,am35xx-clk))
+ clk_hw-ops = clkhwops_am35xx_ipss_module_wait;
I really don't like this. I think this should be done based on the
compatible string.
Thanks,
Mark.
--
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] serial: OMAP: add RS485 support
On 13/08/13 11:54, Javier Martinez Canillas wrote: snip Hi Mark, I've seen several attempts to add RS485 support to the omap serial driver and it is always nack-ed. There seems to be concerns about controlling the RTS by software when RS485 is not supported by the UART hardware. Please refer to [1] and [2] for more information. H ... okay, I guess I'll just have to maintain our own code (as did the OP in [1]). Thanks for the info. -- 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] serial: OMAP: add RS485 support
On Tue, Aug 13, 2013 at 1:07 PM, Mark Jackson mpfj-l...@newflow.co.uk wrote: On 13/08/13 11:54, Javier Martinez Canillas wrote: snip Hi Mark, I've seen several attempts to add RS485 support to the omap serial driver and it is always nack-ed. There seems to be concerns about controlling the RTS by software when RS485 is not supported by the UART hardware. Please refer to [1] and [2] for more information. H ... okay, I guess I'll just have to maintain our own code (as did the OP in [1]). Yes, back then we had to do the same using Ilya Yanok's OMAP RS485 patches [1] on a vendor tree :( Thanks for the info. I just wanted to avoid you wasting more time on this, unless the mindset has changed in which case it would be really great to have RS485 support for OMAP serial. Thanks a lot and best regards, Javier [1]: http://comments.gmane.org/gmane.linux.serial/6770 -- 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: [PATCHv5 16/31] CLK: TI: DRA7: Add APLL support
On Fri, Aug 02, 2013 at 05:25:35PM +0100, Tero Kristo wrote:
From: Keerthy j-keer...@ti.com
The patch adds support for DRA7 PCIe APLL. The APLL
sources the optional functional clocks for PCIe module.
APLL stands for Analog PLL. This is different when comapred
with DPLL meaning Digital PLL, the phase detection is done
using an analog circuit.
Signed-off-by: Keerthy j-keer...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/apll.txt | 32 +++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|2 +-
drivers/clk/ti/apll.c | 209
include/linux/clk/ti.h |2 +
5 files changed, 244 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/apll.txt
create mode 100644 drivers/clk/ti/apll.c
diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt
b/Documentation/devicetree/bindings/clock/ti/apll.txt
new file mode 100644
index 000..f7a82e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/apll.txt
@@ -0,0 +1,32 @@
+Binding for Texas Instruments APLL clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped APLL with usually two selectable input clocks
+(reference clock and bypass clock), with analog phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) APLL mostly behaves like
+a subtype of a DPLL [2], although a simplified one at that.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/dpll.txt
+
+Required properties:
+- compatible : shall be ti,dra7-apll-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
+- reg : array of register base addresses for controlling the APLL:
+ reg[0] = control register
+ reg[1] = idle status register
Using reg-names is likely a good idea here.
+- ti,clk-ref : link phandle for the reference clock
+- ti,clk-bypass : link phandle for the bypass clock
You don't need this. Use the clocks and clock-names properties.
[...]
+static int dra7_apll_enable(struct clk_hw *hw)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+ int r = 0, i = 0;
+ struct dpll_data *ad;
+ const char *clk_name;
+ u8 state = 1;
+ u32 v;
+
+ ad = clk-dpll_data;
+ if (!ad)
+ return -EINVAL;
+
+ clk_name = __clk_get_name(clk-hw.clk);
+
+ state = __ffs(ad-idlest_mask);
+
+ /* Check is already locked */
+ if ((__raw_readl(ad-idlest_reg) ad-idlest_mask) == state)
+ return r;
Why __raw_readl rather than raw_readl?
+
+ v = __raw_readl(ad-control_reg);
+ v = ~ad-enable_mask;
+ v |= APLL_FORCE_LOCK __ffs(ad-enable_mask);
+ __raw_writel(v, ad-control_reg);
Why not raw_writel? Do you not need the rmb() provided by writel, here
or anywhere else?
[...]
+void __init of_dra7_apll_setup(struct device_node *node)
+{
+ const struct clk_ops *ops;
+ struct clk *clk;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names = NULL;
+ struct of_phandle_args clkspec;
+ u8 apll_flags = 0;
+ struct dpll_data *ad;
+ u32 idlest_mask = 0x1;
+ u32 autoidle_mask = 0x3;
+ int i;
+
+ ops = apll_ck_ops;
+ ad = kzalloc(sizeof(*ad), GFP_KERNEL);
+ if (!ad) {
+ pr_err(%s: could not allocate dpll_data\n, __func__);
+ return;
+ }
+
+ of_property_read_string(node, clock-output-names, clk_name);
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents 1) {
+ pr_err(%s: omap dpll %s must have parent(s)\n,
+ __func__, node-name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ clkspec.np = of_parse_phandle(node, ti,clk-ref, 0);
+ ad-clk_ref = of_clk_get_from_provider(clkspec);
Use clocks, clock-names, and of_clk_get_by_name().
Thanks,
Mark.
--
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: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: On Friday 02 August 2013 11:48 AM, Will Deacon wrote: I think this an A9-specific register, which reads as 0 on UP A9 and reads as some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE is zero. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. The only other alternative I can think of is forcing people to have CONFIG_SMP=n, but that blows away single zImage for your platform. Will -- 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 1/3] ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration
Hi Javier,
On 03/08/2013 21:11, Javier Martinez Canillas wrote:
On Thu, Jun 20, 2013 at 4:42 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
IGEP boards have a number of LED connected to OMAP or TWL GPIO
lines. The actual wiring is different on each board so each board
DT has need to configure the mux correctly.
Even though it works with the current DT, the kernel complains with:
[2.305023] leds-gpio leds.18: pins are not configured from the driver
Add an empty pinmux_leds_pins pinctrl child node so boards can
override with the correct mux configuration and not depend on
default values for the GPIO LEDs to work.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index bc48b11..55f9f61 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -68,6 +68,8 @@
0x1a2 (PIN_INPUT | MUX_MODE4) /*
mcspi1_cs2.gpio_176 */
;
};
+
+ leds_pins: pinmux_leds_pins { };
I'm just wondering what will happen if you do not override it with the
board file?
Will we still have the warning? Because the warning is there to notify
you that the pin config is missing so we should not prevent that to work.
Regards,
Benoit
--
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: [PATCHv5 18/31] CLK: DT: add support for set-rate-parent flag
On Fri, Aug 02, 2013 at 05:25:37PM +0100, Tero Kristo wrote:
Adding set-rate-parent to clock node now allows a node to forward
clk_set_rate request to its parent clock.
Why do you need this?
Is this a description of the hardware, or configuration for Linux?
It feels like the latter, which shouldn't really be in DT.
I'm not that familiar with the internals of the clock framework, and
don't understand the implications of this.
If this is necessary, the bindings need to be updated.
Mike, thoughts?
Mark.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c |6 +-
drivers/clk/clk-fixed-factor.c |6 +-
drivers/clk/clk-gate.c |8 ++--
drivers/clk/clk-mux.c |6 +-
4 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ff24ec2..01d967f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -388,6 +388,7 @@ void of_divider_clk_setup(struct device_node *node)
u32 mask = 0;
u32 shift = 0;
struct clk_div_table *table;
+ u32 flags = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -418,12 +419,15 @@ void of_divider_clk_setup(struct device_node *node)
if (of_property_read_bool(node, hiword-mask))
clk_divider_flags |= CLK_DIVIDER_HIWORD_MASK;
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
table = of_clk_get_div_table(node);
if (IS_ERR(table))
return;
clk = _register_divider(NULL, clk_name,
- parent_name, 0,
+ parent_name, flags,
reg, (u8) shift, mask,
clk_divider_flags, table,
NULL);
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 9ff7d51..30aa121 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -107,6 +107,7 @@ void __init of_fixed_factor_clk_setup(struct device_node
*node)
const char *clk_name = node-name;
const char *parent_name;
u32 div, mult;
+ u32 flags = 0;
if (of_property_read_u32(node, clock-div, div)) {
pr_err(%s Fixed factor clock %s must have a clock-div
property\n,
@@ -123,7 +124,10 @@ void __init of_fixed_factor_clk_setup(struct device_node
*node)
of_property_read_string(node, clock-output-names, clk_name);
parent_name = of_clk_get_parent_name(node, 0);
- clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
+ clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
mult, div);
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index cd595ec..0be25b9 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -176,6 +176,7 @@ void of_gate_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_gate_flags = 0;
u32 bit_idx = 0;
+ u32 flags = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -195,8 +196,11 @@ void of_gate_clk_setup(struct device_node *node)
if (of_property_read_bool(node, hiword-mask))
clk_gate_flags |= CLK_GATE_HIWORD_MASK;
- clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, (u8)
bit_idx,
- clk_gate_flags, NULL);
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
+ clk = clk_register_gate(NULL, clk_name, parent_name, flags, reg,
+ (u8) bit_idx, clk_gate_flags, NULL);
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4751bce..890ddbf 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -184,6 +184,7 @@ void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
+ u32 flags = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -219,8 +220,11 @@ void of_mux_clk_setup(struct device_node *node)
if (of_property_read_bool(node, hiword-mask))
clk_mux_flags |= CLK_MUX_HIWORD_MASK;
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
clk = clk_register_mux_table(NULL, clk_name, parent_names, num_parents,
- 0, reg, (u8) shift, mask, clk_mux_flags,
+ flags, reg, (u8) shift, mask, clk_mux_flags,
NULL, NULL);
if
Re: [GIT PULL] DRA7xx core support
On Tuesday 13 August 2013 01:10 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130812 04:41]: ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board Looks like you just updated the dts patch based on the comments from Mark? Yeah, I was about to send you an updated pull with the fixes. Actually can you please just drop the .dts patch from this series so it can be queued separately by Benoit and then reply with an updated pull request. ok, I'll drop the dts changes and send an updated pull and repost the latest dts patch so Benoit can pick it up. regards, Rajendra 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
[PATCH v2] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*
The Palmas device contains only a USB VID detector, so added a
compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible
types for backward compatibility.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Changes from v1:
rebased on extcon-next
Documentation/devicetree/bindings/extcon/extcon-palmas.txt |3 ++-
drivers/extcon/extcon-palmas.c |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
index 7dab6a8..dc5fab3 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
@@ -2,7 +2,8 @@ EXTCON FOR PALMAS/TWL CHIPS
PALMAS USB COMPARATOR
Required Properties:
- - compatible : Should be ti,palmas-usb or ti,twl6035-usb
+ - compatible : Should be ti,palmas-usb or ti,twl6035-usb or
+ ti,palmas-usb-vid.
Optional Properties:
- ti,wakeup : To enable the wakeup comparator in probe
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 89fdd05..9672f31 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -268,6 +268,7 @@ static const struct dev_pm_ops palmas_pm_ops = {
static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,palmas-usb, },
+ { .compatible = ti,palmas-usb-vid, },
{ .compatible = ti,twl6035-usb, },
{ /* end */ }
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 22/31] CLK: TI: add interface clock support for OMAP3
On Fri, Aug 02, 2013 at 05:25:41PM +0100, Tero Kristo wrote: OMAP3 has interface clocks in addition to functional clocks, which require special handling for the autoidle and idle status register offsets mainly. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/interface.txt | 45 + arch/arm/mach-omap2/clock.h|6 -- drivers/clk/ti/Makefile|2 +- drivers/clk/ti/interface.c | 105 include/linux/clk/ti.h |7 ++ 5 files changed, 158 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/interface.txt create mode 100644 drivers/clk/ti/interface.c diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt new file mode 100644 index 000..8b09ae7 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -0,0 +1,45 @@ +Binding for Texas Instruments interface clock. + +This binding uses the common clock binding[1]. This clock is +quite much similar to the basic gate-clock [2], however, +it supports a number of additional features, including +companion clock finding (match corresponding functional gate +clock) and hardware autoidle enable / disable. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/gate-clock.txt + +Required properties: +- compatible : shall be ti,interface-clock It might make sense to be more specific: ti,omap3-interface-clock. +- #clock-cells : from common clock binding; shall be set to 0 +- clocks : link to phandle of parent clock +- reg : base address for the control register + +Optional properties: +- ti,enable-bit : bit shift for the bit enabling/disabling the clock + (default 0) +- ti,iclk-no-wait : flag for selecting non-waiting hw-ops +- ti,iclk-hsotgusb : flag for selecting hsotgusb hw-ops +- ti,iclk-dss : flag for selecting DSS interface clock hw-ops +- ti,iclk-ssi : flag for selecting SSI interface clock hw-ops +- ti,am35xx-clk : flag for selecting AM35xx interface clock hw-ops I think these should be selected based on the compatible string. They're mutually exclusive, and incompatible. Thanks, Mark. -- 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 1/3] ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration
On Tue, Aug 13, 2013 at 1:20 PM, Benoit Cousson bcous...@baylibre.com wrote:
Hi Javier,
On 03/08/2013 21:11, Javier Martinez Canillas wrote:
On Thu, Jun 20, 2013 at 4:42 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
IGEP boards have a number of LED connected to OMAP or TWL GPIO
lines. The actual wiring is different on each board so each board
DT has need to configure the mux correctly.
Even though it works with the current DT, the kernel complains with:
[2.305023] leds-gpio leds.18: pins are not configured from the driver
Add an empty pinmux_leds_pins pinctrl child node so boards can
override with the correct mux configuration and not depend on
default values for the GPIO LEDs to work.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index bc48b11..55f9f61 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -68,6 +68,8 @@
0x1a2 (PIN_INPUT | MUX_MODE4) /*
mcspi1_cs2.gpio_176 */
;
};
+
+ leds_pins: pinmux_leds_pins { };
I'm just wondering what will happen if you do not override it with the board
file?
Will we still have the warning? Because the warning is there to notify you
that the pin config is missing so we should not prevent that to work.
If you don't override on the board file you will just get the warning.
Once when I send this patches the gpio-leds driver was indeed failing
to probe because of this. I noticed this because the LED stop working
and didn't appear in /sys/class/leds/ and setting the pin mux
correctly solved the issue.
Now I just see a warning so it seems this got fixed in the meantime.
So since is not a regression probably this is v3.12 material and there
is no need to send it on the -rc series.
Regards,
Benoit
Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] DRA7xx core support
Hi Tony, Heres an updated pull request dropping the dts files. The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://github.com/rrnayak/linux.git tags/dra7-core-support-minus-dt for you to fetch changes up to 8dd21c93197cc465ae87e142435b3f7f262eade9: ARM: DRA7: Add the build support in omap2plus (2013-08-13 16:58:16 +0530) DRA7xx based SoC core support R Sricharan (7): ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra ARM: DRA7: Reuse io tables and add a new .init_early ARM: DRA7: Resue the clocksource, clockevent support ARM: DRA7: board-generic: Add basic DT support ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512 ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs' ARM: DRA7: Add the build support in omap2plus Rajendra Nayak (1): ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 .../devicetree/bindings/arm/omap/omap.txt |3 +++ arch/arm/Kconfig |2 +- arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap1/include/mach/soc.h |1 + arch/arm/mach-omap2/Kconfig| 12 ++-- arch/arm/mach-omap2/Makefile |6 ++ arch/arm/mach-omap2/board-generic.c| 18 ++ arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/id.c |4 ++-- arch/arm/mach-omap2/io.c | 20 ++-- arch/arm/mach-omap2/omap54xx.h |4 arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/soc.h | 17 + arch/arm/mach-omap2/timer.c|3 ++- arch/arm/plat-omap/Kconfig |2 +- 15 files changed, 86 insertions(+), 10 deletions(-) On Monday 12 August 2013 05:04 PM, Rajendra Nayak wrote: Hi Tony, Heres the pull request for the dra7xx core support patches. The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://github.com/rrnayak/linux.git tags/dra7-core-support-v3 for you to fetch changes up to 41f2119b3037e50482cb14eaa39e6b5c52113fb5: ARM: DRA7: Add the build support in omap2plus (2013-08-12 15:25:38 +0530) DRA7xx based SoC core support R Sricharan (8): ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra ARM: DRA7: Reuse io tables and add a new .init_early ARM: DRA7: Resue the clocksource, clockevent support ARM: DRA7: board-generic: Add basic DT support ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512 ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs' ARM: DRA7: Add the build support in omap2plus Rajendra Nayak (1): ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/Kconfig |2 +- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts | 140 + arch/arm/boot/dts/dra7.dtsi| 567 arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap1/include/mach/soc.h |1 + arch/arm/mach-omap2/Kconfig| 12 +- arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/board-generic.c| 18 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/id.c |4 +- arch/arm/mach-omap2/io.c | 20 +- arch/arm/mach-omap2/omap54xx.h |4 + arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/soc.h | 17 + arch/arm/mach-omap2/timer.c|3 +- arch/arm/plat-omap/Kconfig |2 +- 18 files changed, 795 insertions(+), 11 deletions(-) create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: AM33XX: node definition cleanups
+ Few TI folks to review and test. On 10/08/2013 19:05, Javier Martinez Canillas wrote: Hi, While reviewing the submission of a DT file for a new board based on the am3352 SoC, I noticed that am33xx*.dts files needed some cleanups. All am33xx based board files redefine device nodes that are already defined in the included am33xx.dtsi file. This not only makes the DTS harder to maintain without any benefit but also leaks SoC internal details to board files such as how the OCP interconnect is modeled (currently just a flat representation) and the addresses of some IP modules that are part of the SoC and are not going to change from board to board. This patch-set cleans these board files and is composed of the following patches: [PATCH 1/2] ARM: dts: AM33XX: use pinmux node defined in included [PATCH 2/2] ARM: dts: AM33XX: don't redefine OCP bus and device NOTE: I don't own any of these am33xx based boards so I was only able to build test the changes. However I compared the generated dtb before and after the changes and the disassembled DTS with dtc -I dtb -O dts foo.dtb bar.dts are identical. Even though the binary dtb is the same and there shouldn't be any visible changes, boot testing will be highly appreciated. Thanks it looks good to me. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: AM33XX: Add PMU support
Salut Alexandre, On 03/08/2013 20:00, Alexandre Belloni wrote: ARM Performance Monitor Units are available on the am33xx, add the support in the dtsi. Tested with perf and oprofile on a regular beaglebone. Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com Thanks, applied for 3.12. Regards, Benoit -- 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 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
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: RX51: kernel message spam from CPUfreq driver
Hi, On Mon, Aug 12, 2013 at 11:59:28AM +0530, Rajendra Nayak wrote: Whats the system clock frequency used on RX-51? I guess omap2_dpll_round_rate() for some reason thinks that with the given sys clock its not possible to lock the DPLL at 125Mhz. If you can send the debug logs from omap2_dpll_round_rate() that should probably help know whats going wrong. It's also not possible to lock the DPLL at other frequencies. During the boot process at least 125MHz, 250MHz and 550MHz cannot be locked. I uploaded a full serial dump from the n900 with debug output from omap2_dpll_round_rate to the following url: http://paste.debian.net/24628/ -- Sebastian signature.asc Description: Digital signature
Re: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hi Dave, On 12.08.2013 20:59, Dave Gerlach wrote: On 08/11/2013 06:53 AM, Daniel Mack wrote: The problem I currently face is that I can't make the board resume, as neither UART0 nor GPIO0 seem to work as wakeup source. Did you apply the other patches that are mentioned besides Suman's series? The board will hang while suspending without these. Yes. However, just to make sure you referenced the correct patches - on top of yours an Suman's set, I have: [PATCH 1/2] ARM: OMAP2+: hwmod: rt address space index for DT [PATCH 2/2] ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space [PATCH 1/2] ARM: dts: add AM33XX EDMA support The last one seems somewhat unrelated though. However, I see an issue with the musb dsps glue. With the usb controller disabled in DT, I also had to remove the usb_otg_hs entry from am33xx_mod[] (pm33xx.c). When the usb controller is _enabled_, I get an instant NULL pointer exception due to a rather obvious bug. I'll send out a patch right now. When I send the board to suspend (with USB disabled), the power consumption drops significantly, and the output is: # echo mem /sys/power/state [ 93.001937] PM: Syncing filesystems ... done. [ 93.033591] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 93.048532] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 93.059277] PM: Sending message for entering DeepSleep mode [ 93.085368] PM: suspend of devices complete after 15.070 msecs [ 93.096671] PM: late suspend of devices complete after 5.122 msecs [ 93.108853] PM: noirq suspend of devices complete after 5.647 msecs ... but traffic on UART0 won't cause a resume. I'll dig a little deeper now, but if you have any idea, please let me know. Thanks, Daniel -- 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: omap5: dts: split SMPS10 dt node
Hi Kishon,
On 12/08/2013 11:37, Kishon Vijay Abraham I wrote:
SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as
two regulators. The dt node is split to reflect it.
Mmm, I'm curious. How is it supposed to work?
Do you have dedicated control on each output?
Otherwise, it should be seen as one output with two potential consumers.
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..05b9b12 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,9 +334,18 @@
ti,smps-range = 0x80;
};
- smps10_reg: smps10 {
+ smps10_out2_reg: smps10_out2 {
/* VBUS_5V_OTG */
- regulator-name = smps10;
+ regulator-name = smps10_out2;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps10_out1_reg: smps10_out1 {
+ /* VBUS_5V_OTG */
+ regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
regulator-always-on;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am33xx: Correct gpio #interrupt-cells property
Hi lars, On 07/08/2013 17:11, Lars Poeschel wrote: On Wednesday 07 August 2013 at 16:53:09, Mark Rutland wrote: On Wed, Aug 07, 2013 at 12:06:32PM +0100, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de Following commit ff5c9059 and therefore other omap platforms using the gpio-omap driver correct the #interrupt-cells property on am33xx too. The omap gpio binding documentaion also states that the #interrupt-cells property should be 2. I take it there are no device nodes for which any of these nodes are an interrupt parent (which would need to be updated)? As far as I know: No. Lars If so: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks, Mark. Signed-off-by: Lars Poeschel poesc...@lemonage.de Thank, applied with Mark and Javier A-By / R-By. Thanks, Benoit -- 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 1/3] misc: Add crossbar driver
On Tuesday 13 August 2013 04:10 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Interrupt mask/unmask, really ? Thats like abusing those irqchip hooks completely. Your point is to just setup events which we need and thats what I also suggested. But the use of irqchip hooks is certainly not the right idea since they are for masking/unmasking interrupts in running system and not for joining the interrupt line which needs to happen once during probe. 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: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote: On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: On Friday 02 August 2013 11:48 AM, Will Deacon wrote: I think this an A9-specific register, which reads as 0 on UP A9 and reads as some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE is zero. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. The only other alternative I can think of is forcing people to have CONFIG_SMP=n, but that blows away single zImage for your platform. Yep which surely we don't want considering after so much effort we have it working first place. How about going ahead with assumption that PERIPH_BASE = 0 case doesn't work. 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: [PATCH 1/3] misc: Add crossbar driver
On Tuesday 13 August 2013 05:56 AM, Sricharan R wrote: Hi Tony, On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130724 12:06]: On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote: On 07/24/2013 01:43 PM, Sricharan R wrote: On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote: On 07/24/2013 11:38 AM, Santosh Shilimkar wrote: On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote: That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible. an option might be to statically allocate default number of interrupts to a domain - example: * GIC IRQ 72-78 allotted to UARTs * pinctrl mapping provided for those but only 6 can be used (rest are marked status=disabled as default) at any given time (choice of pinctrl option determines GIC interrupt line to use) * All modules will have a pinctrl definition to have a mapping - to avoid bootloader overriding default cross bar setting in ways un-expected by kernel. Does that sound fair trade off? This sounds better. That way we can get all the devices in the DT at least. Fair enough - if Linus and Tony are still ok with this approach to the problem, seeing a patch series with the effect would be beneficial. Ok, i will use this idea of certain number interrupts to groups. Yes on DRA7XX, we have about 160 gic lines and 320 irq crossbar device inputs contending for it. 1:2 and fully arbitrary. But will we be really exhausting them ? Depends on how we allocate :). The default arbitary allocation can be made more logical in your series ofcourse :). I would just most logical peripherals rather than providing every single IP connected to cross bar. Otherwise we will end up wth hwmod like scenario where now started removing the unused stuff because of maintenance and loc issues ;-) Sorry for the delay on this, I think the best way to set this up is as a separate drivers/irqchip controller. Then just map the configured interrupts for the board with interrupt-map and interrupt-map-mask binding. No need to stuff all the SoC specific maps to the .dts, just the ones used for the board. Regards, Tony Initially irqchip was discussed, but we also have a DMA crossbar to map the dma-requests. Since both irq/dma crossbars should be handled, pinctrl was suggested as the appropriate place to handle this. I replied on other thread. I guess Tony's point is to setup only required events for a board rather than setting up every possible event. 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
[PATCH v3] N900: add device tree
Hi!
I finally got released by the aliens. It took longer than expected
and beside a small scar on the back of my neck, I feel pretty OK.
Scars on neck sound scary...
The order should not matter at all in DT, it should be a static
representation of the HW, so there is probably something wrong in
the code that make the device creation order important.
I understand that there's something wrong with the code, but it turned
out not to be easy to debug. Yes, it will have to be debugged some
day, but it happens with old code, too, so it is actually orthogonal
to device tree.
Beside my comments and the ones from Javier, it looks good.
If you can repost ASAP, I'll take it right after.
It will be the first one in the list.
Thanks, here you go.
Pavel
---
This adds device tree with neccessary support to boot with functional
video (on both emulator and real N900 device).
Signed-off-by: Pavel Machek pa...@ucw.cz
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
can be enabled on 3.10, and tested it on that kernel.
From v2: spelling, improved comments. Tested on 3.11-rc (0ed4402).
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a0f2365..c48b1ef 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -162,6 +162,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3-n900.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 000..7ff90f8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2013 Pavel Machek pa...@ucw.cz
+ * Copyright 2013 Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (or later) as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include omap34xx.dtsi
+
+/ {
+ model = Nokia N900;
+ compatible = nokia,omap3-n900, ti,omap3;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+};
+
+i2c1 {
+ clock-frequency = 220;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+#include twl4030.dtsi
+
+twl_gpio {
+ ti,pullups = 0x0;
+ ti,pulldowns= 0x03ff3f; /* BIT(0..5) | BIT(8..17) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+mcspi1 {
+ /*
+* For some reason, touchscreen is necessary for screen to work at
+* all on real hw. It works well without it on emulator.
+*
+* Also... order in the device tree actually matters here.
+*/
+ tsc2005@0 {
+ compatible = tsc2005;
+ spi-max-frequency = 600;
+ reg = 0;
+ };
+ mipid@2 {
+ compatible = acx565akm;
+ spi-max-frequency = 600;
+ reg = 2;
+ };
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 2;
+ power = 50;
+};
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] N900: add device tree
On 13/08/2013 15:36, Pavel Machek wrote:
Hi!
I finally got released by the aliens. It took longer than expected
and beside a small scar on the back of my neck, I feel pretty OK.
Scars on neck sound scary...
The order should not matter at all in DT, it should be a static
representation of the HW, so there is probably something wrong in
the code that make the device creation order important.
I understand that there's something wrong with the code, but it turned
out not to be easy to debug. Yes, it will have to be debugged some
day, but it happens with old code, too, so it is actually orthogonal
to device tree.
Beside my comments and the ones from Javier, it looks good.
If you can repost ASAP, I'll take it right after.
It will be the first one in the list.
Thanks, here you go.
Thanks. I've just applied it after adding the prefix ARM: dts: to the
subject.
Regards,
Benoit
Pavel
---
This adds device tree with neccessary support to boot with functional
video (on both emulator and real N900 device).
Signed-off-by: Pavel Machek pa...@ucw.cz
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
From v1: Aaro wants just GPLv2, so I did that. I re-enabled parts that
can be enabled on 3.10, and tested it on that kernel.
From v2: spelling, improved comments. Tested on 3.11-rc (0ed4402).
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a0f2365..c48b1ef 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -162,6 +162,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
+ omap3-n900.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
omap3-igep0030.dtb \
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
new file mode 100644
index 000..7ff90f8
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2013 Pavel Machek pa...@ucw.cz
+ * Copyright 2013 Aaro Koskinen aaro.koski...@iki.fi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (or later) as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include omap34xx.dtsi
+
+/ {
+ model = Nokia N900;
+ compatible = nokia,omap3-n900, ti,omap3;
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+};
+
+i2c1 {
+ clock-frequency = 220;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+#include twl4030.dtsi
+
+twl_gpio {
+ ti,pullups = 0x0;
+ ti,pulldowns= 0x03ff3f; /* BIT(0..5) | BIT(8..17) */
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+};
+
+mmc1 {
+ status = disabled;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+mcspi1 {
+ /*
+* For some reason, touchscreen is necessary for screen to work at
+* all on real hw. It works well without it on emulator.
+*
+* Also... order in the device tree actually matters here.
+*/
+ tsc2005@0 {
+ compatible = tsc2005;
+ spi-max-frequency = 600;
+ reg = 0;
+ };
+ mipid@2 {
+ compatible = acx565akm;
+ spi-max-frequency = 600;
+ reg = 2;
+ };
+};
+
+usb_otg_hs {
+ interface-type = 0;
+ usb-phy = usb2_phy;
+ mode = 2;
+ power = 50;
+};
--
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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
Dave Gerlach d-gerl...@ti.com writes: On 08/12/2013 02:17 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. Any control module register access still needs to stay in control.c. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Looping Suman Anna who handled the IPC patches this patch set is based on top of... For the wkup_m3, the mailbox isn't used in a traditional manner. It's only used with a dummy write to trigger an interrupt from the A8 to the M3 and then communication happens in IPC registers within the control module. No messages are actually sent through the mailbox in either direction so that's why it was done this way rather than bring in full support for the mailbox. I don't believe remoteproc/rpmsg forces you to use the mailbox for communication, and can use other IPC mechanisms. This still sounds cleaner than reinventing remoteproc/rpmsg because of slight variations. The linux way is to use and extend what is already there, and if it's extended to the breaking point, then make a case for why something new is needed. Kevin -- 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: omap5: dts: split SMPS10 dt node
Hi, On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote: Hi Kishon, On 12/08/2013 11:37, Kishon Vijay Abraham I wrote: SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as two regulators. The dt node is split to reflect it. Mmm, I'm curious. How is it supposed to work? Do you have dedicated control on each output? Yes. It can be controlled by setting different values to the same bit fields. You can refer [1] where we actually implement SMPS10 as two different regulators. [1] - http://permalink.gmane.org/gmane.linux.kernel/1542521 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] arm: omap5: dts: split SMPS10 dt node
On 13/08/2013 16:45, Kishon Vijay Abraham I wrote: Hi, On Tuesday 13 August 2013 06:51 PM, Benoit Cousson wrote: Hi Kishon, On 12/08/2013 11:37, Kishon Vijay Abraham I wrote: SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as two regulators. The dt node is split to reflect it. Mmm, I'm curious. How is it supposed to work? Do you have dedicated control on each output? Yes. It can be controlled by setting different values to the same bit fields. You can refer [1] where we actually implement SMPS10 as two different regulators. [1] - http://permalink.gmane.org/gmane.linux.kernel/1542521 Great, thanks. Can we merge that one safely if the driver changed are not done yet? Regards, Benoit -- 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 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
Russ Dill russ.d...@gmail.com writes:
On Tue, Aug 6, 2013 at 10:49 AM, Dave Gerlach d-gerl...@ti.com wrote:
[...]
+static int wkup_m3_probe(struct platform_device *pdev)
+{
+ int irq, ret = 0;
+ struct resource *mem;
+
+ pm_runtime_enable(pdev-dev);
+
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(pdev-dev, pm_runtime_get_sync() failed\n);
+ return ret;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (!irq) {
+ dev_err(wkup_m3-dev, no irq resource\n);
pdev-dev
+ ret = -ENXIO;
+ goto err;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(wkup_m3-dev, no memory resource\n);
pdev-dev
For future reference, when reviewing, please trim to only relevant
content/context, especially on large patches so maintainers/reviewers do
not have to find 2 one-line comments in a huge amount of irrelevant
context.
Thanks,
Kevin
--
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 1/5 v2] drivers/gpio/gpio-omap.c: convert comma to semicolon
Julia Lawall julia.law...@lip6.fr writes: From: Julia Lawall julia.law...@lip6.fr Replace a comma between expression statements by a semicolon. This changes the semantics of the code, but given the current indentation appears to be what is intended. A simplified version of the semantic patch that performs this transformation is as follows: (http://coccinelle.lip6.fr/) // smpl @r@ expression e1,e2,e; type T; identifier i; @@ e1 -, +; e2; // /smpl Signed-off-by: Julia Lawall julia.law...@lip6.fr --- Not tested. The first version did a different transformation to avoid changing the semantics. This one leaves the layout as it is, but changes the semantics. This is the right one, the previous semantics were wrong due to a copy/paste error. Acked-by: Kevin Hilman khil...@linaro.org drivers/gpio/gpio-omap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index dfeb3a3..9f19ec9 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1030,7 +1030,7 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int irq_start, ct-chip.irq_set_type = gpio_irq_type; if (bank-regs-wkup_en) - ct-chip.irq_set_wake = gpio_wake_enable, + ct-chip.irq_set_wake = gpio_wake_enable; ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride; irq_setup_generic_chip(gc, IRQ_MSK(num), IRQ_GC_INIT_MASK_CACHE, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Tuesday 13 August 2013 10:29 AM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/12/2013 02:17 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. Any control module register access still needs to stay in control.c. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Looping Suman Anna who handled the IPC patches this patch set is based on top of... For the wkup_m3, the mailbox isn't used in a traditional manner. It's only used with a dummy write to trigger an interrupt from the A8 to the M3 and then communication happens in IPC registers within the control module. No messages are actually sent through the mailbox in either direction so that's why it was done this way rather than bring in full support for the mailbox. I don't believe remoteproc/rpmsg forces you to use the mailbox for communication, and can use other IPC mechanisms. This still sounds cleaner than reinventing remoteproc/rpmsg because of slight variations. The linux way is to use and extend what is already there, and if it's extended to the breaking point, then make a case for why something new is needed. While I agree to re-use frameworks, am strongly against use of IPC for the power management which is time sensitive. Imagine a scenario where ACPI is asked to go through remoteproc/ipc for talking to firmware. If it takes 10 to 15 uS just to send a command to firmware to change some control, that just tells something is not right and thats what IPC will do. ARM world is also moving towards that by standardizing some of these through (read PSCI) and thats the way to go in general. Specifically for this series, I am also against having tons of exports and all of that should be extracted properly but remoteproc is not going to be the way. Firmware download has to happen much earlier(ROM path) so thats not the requirement where we could have used the remoteproc firmware download feature. 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: [PATCHv9 1/2] drivers: spi: Add qspi flash controller
Hi,
On Sun, Aug 04, 2013 at 02:28:09PM +0530, Sourav Poddar wrote:
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..4328ae2
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
@@ -0,0 +1,591 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Sourav Poddar sourav.pod...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GPLv2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+
+#include linux/spi/spi.h
+
+struct ti_qspi_regs {
+ u32 clkctrl;
+};
+
+struct ti_qspi {
+ struct completion transfer_complete;
+
+ /* IRQ synchronization */
+ spinlock_t lock;
+
+ /* list synchronization */
+ struct mutexlist_lock;
+
+ struct spi_master *master;
+ void __iomem*base;
+ struct clk *fclk;
+ struct device *dev;
+
+ struct ti_qspi_regs ctx_reg;
+
+ u32 spi_max_frequency;
+ u32 cmd;
+ u32 dc;
+ u32 stat;
+};
+
+#define QSPI_PID (0x0)
+#define QSPI_SYSCONFIG (0x10)
+#define QSPI_INTR_STATUS_RAW_SET (0x20)
+#define QSPI_INTR_STATUS_ENABLED_CLEAR (0x24)
+#define QSPI_INTR_ENABLE_SET_REG (0x28)
+#define QSPI_INTR_ENABLE_CLEAR_REG (0x2c)
+#define QSPI_SPI_CLOCK_CNTRL_REG (0x40)
+#define QSPI_SPI_DC_REG (0x44)
+#define QSPI_SPI_CMD_REG (0x48)
+#define QSPI_SPI_STATUS_REG (0x4c)
+#define QSPI_SPI_DATA_REG(0x50)
+#define QSPI_SPI_SETUP0_REG (0x54)
+#define QSPI_SPI_SWITCH_REG (0x64)
+#define QSPI_SPI_SETUP1_REG (0x58)
+#define QSPI_SPI_SETUP2_REG (0x5c)
+#define QSPI_SPI_SETUP3_REG (0x60)
+#define QSPI_SPI_DATA_REG_1 (0x68)
+#define QSPI_SPI_DATA_REG_2 (0x6c)
+#define QSPI_SPI_DATA_REG_3 (0x70)
+
+#define QSPI_COMPLETION_TIMEOUT msecs_to_jiffies(2000)
+
+#define QSPI_FCLK19200
+
+/* Clock Control */
+#define QSPI_CLK_EN (1 31)
+#define QSPI_CLK_DIV_MAX 0x
+
+/* Command */
+#define QSPI_EN_CS(n)(n 28)
+#define QSPI_WLEN(n) ((n-1) 19)
spaces around '-'
+#define QSPI_3_PIN (1 18)
+#define QSPI_RD_SNGL (1 16)
+#define QSPI_WR_SNGL (2 16)
+#define QSPI_RD_DUAL (3 16)
+#define QSPI_RD_QUAD (7 16)
+#define QSPI_INVAL (4 16)
+#define QSPI_WC_CMD_INT_EN (1 14)
+#define QSPI_FLEN(n) ((n-1) 0)
spaces around '-'
+/* STATUS REGISTER */
+#define WC 0x02
+
+/* INTERRUPT REGISTER */
+#define QSPI_WC_INT_EN (1 1)
+#define QSPI_WC_INT_DISABLE (1 1)
+
+/* Device Control */
+#define QSPI_DD(m, n)(m (3 + n * 8))
+#define QSPI_CKPHA(n)(1 (2 + n * 8))
+#define QSPI_CSPOL(n)(1 (1 + n * 8))
+#define QSPI_CKPOL(n)(1 (n*8))
spaces around '*'
+#define QSPI_FRAME 4096
+
+#define QSPI_AUTOSUSPEND_TIMEOUT 2000
+
+static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
+ unsigned long reg)
+{
+ return readl(qspi-base + reg);
+}
+
+static inline void ti_qspi_write(struct ti_qspi *qspi,
+ unsigned long val, unsigned long reg)
+{
+ writel(val, qspi-base + reg);
+}
+
+static int ti_qspi_setup(struct spi_device *spi)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi-master);
+ struct ti_qspi_regs *ctx_reg = qspi-ctx_reg;
+ int clk_div = 0, ret;
+ u32 clk_ctrl_reg, clk_rate, clk_mask;
+
+ if (spi-master-busy) {
+ dev_dbg(qspi-dev, master busy doing other trasnfers\n);
+ return -EBUSY;
+ }
+
+ if (!qspi-spi_max_frequency) {
+ dev_err(qspi-dev, spi max frequency not defined\n);
+
Re: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 08/13/2013 07:39 AM, Daniel Mack wrote: Hi Dave, On 12.08.2013 20:59, Dave Gerlach wrote: On 08/11/2013 06:53 AM, Daniel Mack wrote: The problem I currently face is that I can't make the board resume, as neither UART0 nor GPIO0 seem to work as wakeup source. Did you apply the other patches that are mentioned besides Suman's series? The board will hang while suspending without these. Yes. However, just to make sure you referenced the correct patches - on top of yours an Suman's set, I have: [PATCH 1/2] ARM: OMAP2+: hwmod: rt address space index for DT [PATCH 2/2] ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space [PATCH 1/2] ARM: dts: add AM33XX EDMA support The last one seems somewhat unrelated though. However, I see an issue with the musb dsps glue. With the usb controller disabled in DT, I also had to remove the usb_otg_hs entry from am33xx_mod[] (pm33xx.c). When the usb controller is _enabled_, I get an instant NULL pointer exception due to a rather obvious bug. I'll send out a patch right now. When I send the board to suspend (with USB disabled), the power consumption drops significantly, and the output is: # echo mem /sys/power/state [ 93.001937] PM: Syncing filesystems ... done. [ 93.033591] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 93.048532] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 93.059277] PM: Sending message for entering DeepSleep mode [ 93.085368] PM: suspend of devices complete after 15.070 msecs [ 93.096671] PM: late suspend of devices complete after 5.122 msecs [ 93.108853] PM: noirq suspend of devices complete after 5.647 msecs ... but traffic on UART0 won't cause a resume. It looks like you are using no_console_suspend? UART0 does not work as a wakeup source with this option set. I'll dig a little deeper now, but if you have any idea, please let me know. Thanks, Daniel -- 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 16/22] ARM: dts: Remove '0x's from OMAP3430 SDP DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3430-sdp.dts | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..281914e 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -84,15 +84,15 @@
label = bootloader-nor;
reg = 0 0x4;
};
- partition@0x4 {
+ partition@4 {
label = params-nor;
reg = 0x4 0x4;
};
- partition@0x8 {
+ partition@8 {
label = kernel-nor;
reg = 0x8 0x20;
};
- partition@0x28 {
+ partition@28 {
label = filesystem-nor;
reg = 0x24 0x7d8;
};
@@ -125,19 +125,19 @@
label = xloader-nand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-nand;
reg = 0x8 0x14;
};
- partition@0x1c {
+ partition@1c {
label = params-nand;
reg = 0x1c 0xc;
};
- partition@0x28 {
+ partition@28 {
label = kernel-nand;
reg = 0x28 0x50;
};
- partition@0x78 {
+ partition@78 {
label = filesystem-nand;
reg = 0x78 0x788;
};
@@ -170,19 +170,19 @@
label = xloader-onenand;
reg = 0 0x8;
};
- partition@0x8 {
+ partition@8 {
label = bootloader-onenand;
reg = 0x8 0x4;
};
- partition@0xc {
+ partition@c {
label = params-onenand;
reg = 0xc 0x2;
};
- partition@0xe {
+ partition@e {
label = kernel-onenand;
reg = 0xe 0x20;
};
- partition@0x2e {
+ partition@2e {
label = filesystem-onenand;
reg = 0x2e 0xfd2;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 17/22] ARM: dts: Remove '0x's from OMAP4 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..45708e1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -56,7 +56,7 @@
cache-level = 2;
};
- local-timer@0x48240600 {
+ local-timer@48240600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x48240600 0x20;
interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_HIGH);
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 15/22] ARM: dts: Remove '0x's from OMAP3 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..16420ae 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -111,7 +111,7 @@
pinctrl-single,function-mask = 0x7f1f;
};
- omap3_pmx_wkup: pinmux@0x48002a00 {
+ omap3_pmx_wkup: pinmux@48002a00 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002a00 0x5c;
#address-cells = 1;
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 14/22] ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0030.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d0538..f628200 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -74,19 +74,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 13/22] ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap3-igep0020.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..f7a8122 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -99,19 +99,19 @@
label = SPL;
reg = 0 0x10;
};
- partition@0x8 {
+ partition@8 {
label = U-Boot;
reg = 0x10 0x18;
};
- partition@0x1c {
+ partition@1c {
label = Environment;
reg = 0x28 0x10;
};
- partition@0x28 {
+ partition@28 {
label = Kernel;
reg = 0x38 0x30;
};
- partition@0x78 {
+ partition@78 {
label = Filesystem;
reg = 0x68 0x1f98;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 12/22] ARM: dts: Remove '0x's from OMAP2420 H4 DTS file
Tony, Benoit,
Poke
On Mon, 22 Jul 2013, Lee Jones wrote:
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap2420-h4.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
index 224c08f..34cdecb 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -50,15 +50,15 @@
label = bootloader;
reg = 0 0x2;
};
- partition@0x2 {
+ partition@2 {
label = params;
reg = 0x2 0x2;
};
- partition@0x4 {
+ partition@4 {
label = kernel;
reg = 0x4 0x20;
};
- partition@0x24 {
+ partition@24 {
label = file-system;
reg = 0x24 0x3dc;
};
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 18/22] ARM: dts: Remove '0x's from OMAP5 DTS file
Tony, Benoit,
Poke
Cc: BenoƮt Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..be58604 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,7 +604,7 @@
ti,hwmods = wd_timer2;
};
- emif1: emif@0x4c00 {
+ emif1: emif@4c00 {
compatible = ti,emif-4d5;
ti,hwmods = emif1;
phy-type= 2; /* DDR PHY type: Intelli PHY */
@@ -615,7 +615,7 @@
hw-caps-temp-alert;
};
- emif2: emif@0x4d00 {
+ emif2: emif@4d00 {
compatible = ti,emif-4d5;
ti,hwmods = emif2;
phy-type= 2; /* DDR PHY type: Intelli PHY */
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ā Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 13.08.2013 17:33, Dave Gerlach wrote: On 08/13/2013 07:39 AM, Daniel Mack wrote: ... but traffic on UART0 won't cause a resume. It looks like you are using no_console_suspend? UART0 does not work as a wakeup source with this option set. Meh. Sorry, I didn't think about that possibility. Indeed, without that option, it does resume. Now I can search for the reason why other wakeup sources won't work yet, but that shouldn't bother you. Thanks again, Daniel -- 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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
+ Ohad Santosh Shilimkar santosh.shilim...@ti.com writes: On Tuesday 13 August 2013 10:29 AM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/12/2013 02:17 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. Any control module register access still needs to stay in control.c. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Looping Suman Anna who handled the IPC patches this patch set is based on top of... For the wkup_m3, the mailbox isn't used in a traditional manner. It's only used with a dummy write to trigger an interrupt from the A8 to the M3 and then communication happens in IPC registers within the control module. No messages are actually sent through the mailbox in either direction so that's why it was done this way rather than bring in full support for the mailbox. I don't believe remoteproc/rpmsg forces you to use the mailbox for communication, and can use other IPC mechanisms. This still sounds cleaner than reinventing remoteproc/rpmsg because of slight variations. The linux way is to use and extend what is already there, and if it's extended to the breaking point, then make a case for why something new is needed. While I agree to re-use frameworks, am strongly against use of IPC for the power management which is time sensitive. Maybe I'm misunderstanding what you mean by IPC, but I'm not sure how you can be against IPC here. Communication with M3 requires it. The only question is what framework to use: create a new wkup_m3 driver which creates yet another set of IPC APIs as well as a seprate firmware load path? Or reuse remoteproc/rpmsg which provides both. Imagine a scenario where ACPI is asked to go through remoteproc/ipc for talking to firmware. If it takes 10 to 15 uS just to send a command to firmware to change some control, that just tells something is not right and thats what IPC will do. Sounds like what you're saying is that remoteproc/rpmsg will be too slow for this? Is there any evidence of that? Even if it is slow, it sounds like a perfect opportuntity to enhance it. Also, if speed is that much of a concern concern here, I wonder why there's a 500msec timeout in in the communication between MPU and M3 in the current code. ARM world is also moving towards that by standardizing some of these through (read PSCI) and thats the way to go in general. Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms that don't support it natively. Are you saying that the AM33xx firmware should be converted to be PSCI compliant? Admittedly, I haven't read the PSCI spec closely, but I'm wondering if the current role splitting between MPU and M3 fits well with PSCI. Specifically for this series, I am also against having tons of exports and all of that should be extracted properly but remoteproc is not going to be the way. Firmware download has to happen much earlier(ROM path) so thats not the requirement where we could have used the remoteproc firmware download feature. At least for AM33xx, I don't see any requirement that firmware download happens early (or at all.) PM will simply be disabled until firmware is available (and running.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to
Re: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Tuesday 13 August 2013 12:19 PM, Kevin Hilman wrote: + Ohad Santosh Shilimkar santosh.shilim...@ti.com writes: On Tuesday 13 August 2013 10:29 AM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/12/2013 02:17 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. Any control module register access still needs to stay in control.c. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Looping Suman Anna who handled the IPC patches this patch set is based on top of... For the wkup_m3, the mailbox isn't used in a traditional manner. It's only used with a dummy write to trigger an interrupt from the A8 to the M3 and then communication happens in IPC registers within the control module. No messages are actually sent through the mailbox in either direction so that's why it was done this way rather than bring in full support for the mailbox. I don't believe remoteproc/rpmsg forces you to use the mailbox for communication, and can use other IPC mechanisms. This still sounds cleaner than reinventing remoteproc/rpmsg because of slight variations. The linux way is to use and extend what is already there, and if it's extended to the breaking point, then make a case for why something new is needed. While I agree to re-use frameworks, am strongly against use of IPC for the power management which is time sensitive. Maybe I'm misunderstanding what you mean by IPC, but I'm not sure how you can be against IPC here. Communication with M3 requires it. The only question is what framework to use: create a new wkup_m3 driver which creates yet another set of IPC APIs as well as a seprate firmware load path? Or reuse remoteproc/rpmsg which provides both. I mean Linux IPC layers. Imagine a scenario where ACPI is asked to go through remoteproc/ipc for talking to firmware. If it takes 10 to 15 uS just to send a command to firmware to change some control, that just tells something is not right and thats what IPC will do. Sounds like what you're saying is that remoteproc/rpmsg will be too slow for this? Is there any evidence of that? Even if it is slow, it sounds like a perfect opportuntity to enhance it. Well 10's uS is fine for the pure IPC kind of messaging. The numbers were measured on Linux OMAP IPC stack for different purpose. Also, if speed is that much of a concern concern here, I wonder why there's a 500msec timeout in in the communication between MPU and M3 in the current code. ARM world is also moving towards that by standardizing some of these through (read PSCI) and thats the way to go in general. Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms that don't support it natively. Are you saying that the AM33xx firmware should be converted to be PSCI compliant? Admittedly, I haven't read the PSCI spec closely, but I'm wondering if the current role splitting between MPU and M3 fits well with PSCI. I didn't mean for the AM3XXX specifically because its current job is rather very limited. i.e suspend. My concern is that IPC is not viewed as an option for power management controllers like M3 which can abstract all the hardware gory details and export a simpled interface for OS in form of PSCI/ACPI. Specifically for this series, I am also against having tons of
Re: [PATCH] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: This is a very simple device that allows testing of the removal path for platform devices. The only interface is a single writeable sysfs attribute (action). Why not use the existing unbind/bind sysfs files that all busses support? That's what userspace is expecting to use for adding and removing devices from drivers from userspace. This is a per-driver flag that the function platform_driver_probe() sets for all platform drivers in the first line of that function. Remove that line and see what happens :) thanks, greg k-h -- 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: +/* + * pdevtest.c + * + * Tester of platform device's operation. + * + * Copyright (C) 2013, Pantelis Antoniou pa...@antoniou-consulting.com + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ Minor legal nit, for the future, you don't actually say what the license is for this file. You imply it by using the GPL paragraphs about warranties, and the totally-useless office address information (do you really want to track the office movements of the FSF for the next 40 years?), but it's not specified. In the future, you can drop these two paragraphs, and just add a sentance about the file being released under the GPLv2 instead. thanks, greg k-h -- 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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
ARM world is also moving towards that by standardizing some of these through (read PSCI) and thats the way to go in general. Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms that don't support it natively. Are you saying that the AM33xx firmware should be converted to be PSCI compliant? Admittedly, I haven't read the PSCI spec closely, but I'm wondering if the current role splitting between MPU and M3 fits well with PSCI. I didn't mean for the AM3XXX specifically because its current job is rather very limited. i.e suspend. My concern is that IPC is not viewed as an option for power management controllers like M3 which can abstract all the hardware gory details and export a simpled interface for OS in form of PSCI/ACPI. The IPC between the M3 and the A8 on the am335x is just a pair of notification mechanisms (one from the A8, mailbox, and one from the M3, sev) and a set of 8 32 bit registers. The 8 32 bit registers are just a scratchpad and have no access rules or functionality beyond being a scratchpad. How complicated do we want to make this? -- 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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Tuesday 13 August 2013 02:30 PM, Russ Dill wrote: ARM world is also moving towards that by standardizing some of these through (read PSCI) and thats the way to go in general. Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms that don't support it natively. Are you saying that the AM33xx firmware should be converted to be PSCI compliant? Admittedly, I haven't read the PSCI spec closely, but I'm wondering if the current role splitting between MPU and M3 fits well with PSCI. I didn't mean for the AM3XXX specifically because its current job is rather very limited. i.e suspend. My concern is that IPC is not viewed as an option for power management controllers like M3 which can abstract all the hardware gory details and export a simpled interface for OS in form of PSCI/ACPI. The IPC between the M3 and the A8 on the am335x is just a pair of notification mechanisms (one from the A8, mailbox, and one from the M3, sev) and a set of 8 32 bit registers. The 8 32 bit registers are just a scratchpad and have no access rules or functionality beyond being a scratchpad. How complicated do we want to make this? Exactly what I mean as well. 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: [PATCH] staging: Platform device tester - Allow removal
Hi Greg, On Aug 13, 2013, at 9:20 PM, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: This is a very simple device that allows testing of the removal path for platform devices. The only interface is a single writeable sysfs attribute (action). Why not use the existing unbind/bind sysfs files that all busses support? That's what userspace is expecting to use for adding and removing devices from drivers from userspace. This is a per-driver flag that the function platform_driver_probe() sets for all platform drivers in the first line of that function. Remove that line and see what happens :) I suppose you're talking about the sysfs bind/unbind attributes. Unfortunately it doesn't work for what I want to do; it doesn't use the same path that the of platform devices use for creating and unregistering. My intention is to use exactly the same path the kernel uses (and what the capemanager does). To wit: Using the bind/unbind method (removal seems to work) root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c unbind [ 139.261522] omap_hwmod: i2c3: enabling [ 139.265514] omap_hwmod: i2c3: enabling clocks [ 139.270090] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.276130] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.286477] omap_hwmod: i2c3: idling [ 139.290279] omap_hwmod: i2c3: _am33xx_disable_module [ 139.295501] omap_hwmod: i2c3: disabling clocks [ 139.305721] omap_hwmod: i2c3: enabling [ 139.309702] omap_hwmod: i2c3: enabling clocks [ 139.314279] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.320332] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.341437] omap_hwmod: i2c3: disabling [ 139.345515] omap_hwmod: i2c3: _am33xx_disable_module [ 139.350735] omap_hwmod: i2c3: disabling clocks But creation just crashes. root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c bind [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 0001 [ 145.062651] pgd = ca8c [ 145.065507] [0001] *pgd=8f437831, *pte=, *ppte= [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM [ 145.077105] Modules linked in: ipv6 autofs4 [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 [ 145.105808] pc : [c0386350]lr : [c0386348]psr: a00f0013 [ 145.105808] sp : cf465e20 ip : fp : [ 145.117860] r10: 0008 r9 : c00523c0 r8 : cf465e70 [ 145.123346] r7 : 0008 r6 : 03e8 r5 : cf0bd210 r4 : c0027c78 [ 145.130202] r3 : r2 : fa19c000 r1 : cf0bd280 r0 : cf178c10 [ 145.137059] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 145.144549] Control: 10c5387d Table: 8a8c0019 DAC: 0015 [ 145.150572] Process sh (pid: 301, stack limit = 0xcf464240) [ 145.156423] Stack: (0xcf465e20 to 0xcf466000) [ 145.161009] 5e20: c0386340 c02cb2fc c0027c84 c0027c78 cf0bd210 c02cc060 [ 145.169594] 5e40: cf0bd210 cf0bd210 c02cc0f4 cf0bd210 03e8 c02cc65c [ 145.178186] 5e60: cf465e8c c0059798 cf0bd2dc 000a0009 cf0bd280 [ 145.186781] 5e80: cf0bd210 03e8 002e cf175d00 c04c3ee4 c02cd344 [ 145.195377] 5ea0: cf178c10 cf0bd210 cf0bd200 c03867dc 0001 c0131124 cf0518b8 c0056890 [ 145.203977] 5ec0: 0003 cf102c08 000186a0 c0704d08 cf0bd210 c0704d08 [ 145.212568] 5ee0: c0714004 cf0bd244 c04c3ee4 cf15f6c0 c02c84ec c02c84d8 c02c7628 [ 145.221151] 5f00: cf5b5580 c0714004 c0704d08 000d cf0bd210 c02c6558 cf18fb48 cf465f80 [ 145.229743] 5f20: 000d cf3c4ec0 cf3c4ed8 c02c5c50 000d c012f050 cf501980 000d [ 145.238331] 5f40: 000d6408 cf465f80 000d6408 cf464000 000d c00d9a5c cf501980 000d6408 [ 145.246923] 5f60: 000d cf501980 000d6408 000d c00d9eb0 [ 145.255510] 5f80: 000d 000d 000d6408 b6f25a80 0004 c000dc08 [ 145.264108] 5fa0: c000da60 000d 000d6408 0001 000d6408 000d [ 145.272703] 5fc0: 000d 000d6408 b6f25a80 0004 000d 000d 000d6408 [ 145.281293] 5fe0: be89d984 b6e61b2c b6eb430c 600f0010 0001 [ 145.289926] [c0386350] (omap_i2c_runtime_suspend+0x10/0xb4) from [c02cb2fc] (pm_generic_runtime_suspend+0x2c/0x40) [ 145.301187] [c02cb2fc] (pm_generic_runtime_suspend+0x2c/0x40) from [c0027c84] (_od_runtime_suspend+0xc/0x24) [ 145.311890] [c0027c84] (_od_runtime_suspend+0xc/0x24) from [c02cc060] (__rpm_callback+0x38/0x68) [ 145.321488] [c02cc060] (__rpm_callback+0x38/0x68) from [c02cc0f4]
Re: [PATCH v2] serial: OMAP: add RS485 support
On Tue, Aug 13, 2013 at 12:54:47PM +0200, Javier Martinez Canillas wrote: On Tue, Aug 13, 2013 at 12:22 PM, Mark Jackson mpfj-l...@newflow.co.uk wrote: On 12/08/13 23:56, Greg KH wrote: On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote: This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Fix incorrect logic in serial_omap_config_rs485() drivers/tty/serial/omap-serial.c | 178 ++ 1 file changed, 178 insertions(+) This doesn't apply to my tty-next branch: checking file drivers/tty/serial/omap-serial.c Hunk #1 FAILED at 40. Hunk #2 succeeded at 162 (offset 6 lines). Hunk #3 succeeded at 280 (offset 5 lines). Hunk #4 succeeded at 378 (offset 6 lines). Hunk #5 succeeded at 1312 (offset 8 lines). Hunk #6 succeeded at 1405 (offset 8 lines). Hunk #7 succeeded at 1528 (offset 10 lines). Hunk #8 FAILED at 1638. Hunk #9 succeeded at 1705 (offset 6 lines). 2 out of 9 hunks FAILED so I can't apply it, sorry. It was applied on top of Linus' tree, if that makes any difference. I'll rebase onto yours and re-post the patch. -- Hi Mark, I've seen several attempts to add RS485 support to the omap serial driver and it is always nack-ed. There seems to be concerns about controlling the RTS by software when RS485 is not supported by the UART hardware. Please refer to [1] and [2] for more information. Hm, but we do support RS485 now in the kernel, look at Documentation/serial/serial-rs485.txt. Why can't this driver support it as well if the serial core already does? thanks, greg k-h -- 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] serial: OMAP: add RS485 support
On Tue, Aug 13, 2013 at 12:07:01PM +0100, Mark Jackson wrote: On 13/08/13 11:54, Javier Martinez Canillas wrote: snip Hi Mark, I've seen several attempts to add RS485 support to the omap serial driver and it is always nack-ed. There seems to be concerns about controlling the RTS by software when RS485 is not supported by the UART hardware. Please refer to [1] and [2] for more information. H ... okay, I guess I'll just have to maintain our own code (as did the OP in [1]). I don't want to have that happen, that's just foolish. I'd rather merge it so that everyone can benifit, and so you don't have to spend extra work maintaining this out-of-tree. thanks, greg k-h -- 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] serial: OMAP: add RS485 support
On Tue, Aug 13, 2013 at 11:22:54AM +0100, Mark Jackson wrote: On 12/08/13 23:56, Greg KH wrote: On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote: This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Fix incorrect logic in serial_omap_config_rs485() drivers/tty/serial/omap-serial.c | 178 ++ 1 file changed, 178 insertions(+) This doesn't apply to my tty-next branch: checking file drivers/tty/serial/omap-serial.c Hunk #1 FAILED at 40. Hunk #2 succeeded at 162 (offset 6 lines). Hunk #3 succeeded at 280 (offset 5 lines). Hunk #4 succeeded at 378 (offset 6 lines). Hunk #5 succeeded at 1312 (offset 8 lines). Hunk #6 succeeded at 1405 (offset 8 lines). Hunk #7 succeeded at 1528 (offset 10 lines). Hunk #8 FAILED at 1638. Hunk #9 succeeded at 1705 (offset 6 lines). 2 out of 9 hunks FAILED so I can't apply it, sorry. It was applied on top of Linus' tree, if that makes any difference. Ah, that makes sense. I should have tried a --3way merge to see if it worked, sorry about that. Let me go try it again... Nope, a few merge errors that I don't know how to resolve, sorry. I'll rebase onto yours and re-post the patch. That would be great, please do. thanks, greg k-h -- 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 09:42:27PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 13, 2013, at 9:20 PM, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: This is a very simple device that allows testing of the removal path for platform devices. The only interface is a single writeable sysfs attribute (action). Why not use the existing unbind/bind sysfs files that all busses support? That's what userspace is expecting to use for adding and removing devices from drivers from userspace. This is a per-driver flag that the function platform_driver_probe() sets for all platform drivers in the first line of that function. Remove that line and see what happens :) I suppose you're talking about the sysfs bind/unbind attributes. Yes. Unfortunately it doesn't work for what I want to do; it doesn't use the same path that the of platform devices use for creating and unregistering. My intention is to use exactly the same path the kernel uses (and what the capemanager does). It should use the same path, if not, that should be fixed, as that's what all other busses in the kernel use. How does this not call the disconnect() function properly? To wit: Using the bind/unbind method (removal seems to work) root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c unbind [ 139.261522] omap_hwmod: i2c3: enabling [ 139.265514] omap_hwmod: i2c3: enabling clocks [ 139.270090] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.276130] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.286477] omap_hwmod: i2c3: idling [ 139.290279] omap_hwmod: i2c3: _am33xx_disable_module [ 139.295501] omap_hwmod: i2c3: disabling clocks [ 139.305721] omap_hwmod: i2c3: enabling [ 139.309702] omap_hwmod: i2c3: enabling clocks [ 139.314279] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.320332] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.341437] omap_hwmod: i2c3: disabling [ 139.345515] omap_hwmod: i2c3: _am33xx_disable_module [ 139.350735] omap_hwmod: i2c3: disabling clocks But creation just crashes. Good. root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c bind [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 0001 [ 145.062651] pgd = ca8c [ 145.065507] [0001] *pgd=8f437831, *pte=, *ppte= [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM [ 145.077105] Modules linked in: ipv6 autofs4 [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 [ 145.105808] pc : [c0386350]lr : [c0386348]psr: a00f0013 [ 145.105808] sp : cf465e20 ip : fp : [ 145.117860] r10: 0008 r9 : c00523c0 r8 : cf465e70 [ 145.123346] r7 : 0008 r6 : 03e8 r5 : cf0bd210 r4 : c0027c78 [ 145.130202] r3 : r2 : fa19c000 r1 : cf0bd280 r0 : cf178c10 [ 145.137059] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 145.144549] Control: 10c5387d Table: 8a8c0019 DAC: 0015 [ 145.150572] Process sh (pid: 301, stack limit = 0xcf464240) [ 145.156423] Stack: (0xcf465e20 to 0xcf466000) [ 145.161009] 5e20: c0386340 c02cb2fc c0027c84 c0027c78 cf0bd210 c02cc060 [ 145.169594] 5e40: cf0bd210 cf0bd210 c02cc0f4 cf0bd210 03e8 c02cc65c [ 145.178186] 5e60: cf465e8c c0059798 cf0bd2dc 000a0009 cf0bd280 [ 145.186781] 5e80: cf0bd210 03e8 002e cf175d00 c04c3ee4 c02cd344 [ 145.195377] 5ea0: cf178c10 cf0bd210 cf0bd200 c03867dc 0001 c0131124 cf0518b8 c0056890 [ 145.203977] 5ec0: 0003 cf102c08 000186a0 c0704d08 cf0bd210 c0704d08 [ 145.212568] 5ee0: c0714004 cf0bd244 c04c3ee4 cf15f6c0 c02c84ec c02c84d8 c02c7628 [ 145.221151] 5f00: cf5b5580 c0714004 c0704d08 000d cf0bd210 c02c6558 cf18fb48 cf465f80 [ 145.229743] 5f20: 000d cf3c4ec0 cf3c4ed8 c02c5c50 000d c012f050 cf501980 000d [ 145.238331] 5f40: 000d6408 cf465f80 000d6408 cf464000 000d c00d9a5c cf501980 000d6408 [ 145.246923] 5f60: 000d cf501980 000d6408 000d c00d9eb0 [ 145.255510] 5f80: 000d 000d 000d6408 b6f25a80 0004 c000dc08 [ 145.264108] 5fa0: c000da60 000d 000d6408 0001 000d6408 000d [ 145.272703] 5fc0: 000d 000d6408 b6f25a80 0004 000d 000d 000d6408 [ 145.281293] 5fe0: be89d984 b6e61b2c b6eb430c 600f0010 0001 [ 145.289926] [c0386350] (omap_i2c_runtime_suspend+0x10/0xb4) from
Re: [PATCH] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 09:42:27PM +0300, Pantelis Antoniou wrote: But creation just crashes. root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c bind [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 0001 [ 145.062651] pgd = ca8c [ 145.065507] [0001] *pgd=8f437831, *pte=, *ppte= [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM [ 145.077105] Modules linked in: ipv6 autofs4 [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 Well then, what you have here is a bug in the way that OMAP re-uses the platform device stuff - and that _does_ need fixing somehow. The problem is that i2c_dev-regs is NULL at the point where pm_runtime_set_autosuspend_delay() is called, which as autosuspend is still set from the time that the device was unbound, it means that this triggers an immediate suspend. I suspect that: pm_runtime_set_autosuspend_delay(dev-dev, OMAP_I2C_PM_TIMEOUT); pm_runtime_use_autosuspend(dev-dev); should be moved later in the probe function, after the switch (scheme) block. -- 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] staging: Platform device tester - Allow removal
Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Without it you get the original crash I've posted in the pdevtest patch with the unbind method. Regards -- Pantelis -- 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 09:59:03PM +0300, Pantelis Antoniou wrote: Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Without it you get the original crash I've posted in the pdevtest patch with the unbind method. Yes, congratulations, you've found a bug in the way OMAP uses the runtime PM stuff in this driver. That bug needs to be fixed irrespective of anything else. -- 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 09:59:03PM +0300, Pantelis Antoniou wrote: Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Ah, ok, I never applied those, so could you resend them? thanks, greg k-h -- 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] staging: Platform device tester - Allow removal
Hi Russell, On Aug 13, 2013, at 10:02 PM, Russell King - ARM Linux wrote: On Tue, Aug 13, 2013 at 09:59:03PM +0300, Pantelis Antoniou wrote: Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Without it you get the original crash I've posted in the pdevtest patch with the unbind method. Yes, congratulations, you've found a bug in the way OMAP uses the runtime PM stuff in this driver. That bug needs to be fixed irrespective of anything else. Not just OMAP. And not just PM stuff. There are crashes occurring due to the way resources are handled by platform devices created via OF. Regards -- Pantelis -- 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 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
Russ Dill russ.d...@gmail.com writes: ARM world is also moving towards that by standardizing some of these through (read PSCI) and thats the way to go in general. Agreed, but I'm not sure (yet) about enforcing PSCI on legacy platforms that don't support it natively. Are you saying that the AM33xx firmware should be converted to be PSCI compliant? Admittedly, I haven't read the PSCI spec closely, but I'm wondering if the current role splitting between MPU and M3 fits well with PSCI. I didn't mean for the AM3XXX specifically because its current job is rather very limited. i.e suspend. My concern is that IPC is not viewed as an option for power management controllers like M3 which can abstract all the hardware gory details and export a simpled interface for OS in form of PSCI/ACPI. The IPC between the M3 and the A8 on the am335x is just a pair of notification mechanisms (one from the A8, mailbox, and one from the M3, sev) and a set of 8 32 bit registers. The 8 32 bit registers are just a scratchpad and have no access rules or functionality beyond being a scratchpad. How complicated do we want to make this? The OMAP IPC between the MPU and DSP (read: any other remote processor) is just a mailbox and some shared memory. No complicated, and works with remoteproc/rpmsg. What's more complicated? reusing existing frameworks or re-inventing them? Don't forget that simple drivers rarely stay that way. Also, this is not a hard stance on my part. I just need to be convinced. The fact is that there are existing frameworks for doing what is being proposed here. Either use the existing frameworks, or make a technical argument based on why those frameworks are not a good fit (ideally, after having tried to use those frameworks.) Once again, I'm pretty sure I mentioned this in earlier reviews of this series. Kevin -- 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 1/2] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*
On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so added a compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible s/Dint/Didn't/ diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb or ti,twl6035-usb or + ti,palmas-usb-vid. So are ti,palmas-usb and ti,twl6035-usb full EHCI controllers then? -- 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] staging: Platform device tester - Allow removal
Hi Pantelis, For some reason, with both this patch and the earlier versions, I don't see the patch until Greg (or someone else) responds. Nor do I find the originals in the linux-omap or LKML archives. Something's going on with your mail so that the first ones don't make it to the lists, so I don't have the original patches. Kevin -- 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] staging: Platform device tester - Allow removal
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Tue, Aug 13, 2013 at 09:42:27PM +0300, Pantelis Antoniou wrote: But creation just crashes. root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c bind [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 0001 [ 145.062651] pgd = ca8c [ 145.065507] [0001] *pgd=8f437831, *pte=, *ppte= [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM [ 145.077105] Modules linked in: ipv6 autofs4 [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 Well then, what you have here is a bug in the way that OMAP re-uses the platform device stuff - and that _does_ need fixing somehow. The problem is that i2c_dev-regs is NULL at the point where pm_runtime_set_autosuspend_delay() is called, which as autosuspend is still set from the time that the device was unbound, it means that this triggers an immediate suspend. I suspect that: pm_runtime_set_autosuspend_delay(dev-dev, OMAP_I2C_PM_TIMEOUT); pm_runtime_use_autosuspend(dev-dev); should be moved later in the probe function, after the switch (scheme) block. That's correct. At a minimum, it should be after the _get_sync() call. Without any users (callers of pm_runtime_get*) the _set_autosuspend_delay() call will try to rpm_idle(). Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
On 08/09/2013 03:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) and HS, SS PHY's controll and configuration registers. s/controll/control/ It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt +MSM SuperSpeed DWC3 USB SoC controller + +Required properities : +- compatible : sould be qcom,dwc3-hsphy; ... +Required properities : +- compatible : sould be qcom,dwc3-ssphy; I would expect different compatible values to be documented in different files. +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. Which of the 3 compatible values that were described above is that property optional for? +Sub nodes: +- Sub node for DWC3 USB3 controller. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. Why not represent the PHY and USB controller as separate top-level nodes? They can point at each-other with phandles if they need to know each-others' identity. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] OMAP: allow GPIO pin to enable/disable external UART driver chip.
Sorry for the late reply, I've been thinking about this for some time and was sad to see it didn't really evoke any sort of discussion :(. On Sat, Aug 10, 2013 at 02:58:08PM +0100, Mark Jackson wrote: When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows the GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. Still to do:- Allow userspace to turn this feature on/off Do the same for the receiver (useful for 2 wire RS485) I've been wondering about this as well but I have a slightly different situation. On my board the RTS line controls the RS485 transmit/receive direction. I don't know if you've found the Documentation/serial/serial-rs485.txt file but it describes, at the very least, a standard API For controlling several parameters related to RS485 including configurable delay between rts-start of data/end of data-rts. Unfortunately it seems like only one driver really implements the full API (Atmel AT91) and I guess it needs to be bolted onto each serial driver individually (although it seems like a fairly general concept that could be handled at another level). That being said, maybe this patch would better be rethought as a way to specify a GPIO for the RTS line (I don't know enough about OMAP and whether or not it already provides for hardware flow control in its builtin UARTs and you just aren't using it for RS485 flow control?) and then in a separate patch implement this already documented user-kernel API? - Andy -- 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] serial: OMAP: add RS485 support
On Tue, Aug 13, 2013 at 8:50 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Aug 13, 2013 at 12:54:47PM +0200, Javier Martinez Canillas wrote: On Tue, Aug 13, 2013 at 12:22 PM, Mark Jackson mpfj-l...@newflow.co.uk wrote: On 12/08/13 23:56, Greg KH wrote: On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote: This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Fix incorrect logic in serial_omap_config_rs485() drivers/tty/serial/omap-serial.c | 178 ++ 1 file changed, 178 insertions(+) This doesn't apply to my tty-next branch: checking file drivers/tty/serial/omap-serial.c Hunk #1 FAILED at 40. Hunk #2 succeeded at 162 (offset 6 lines). Hunk #3 succeeded at 280 (offset 5 lines). Hunk #4 succeeded at 378 (offset 6 lines). Hunk #5 succeeded at 1312 (offset 8 lines). Hunk #6 succeeded at 1405 (offset 8 lines). Hunk #7 succeeded at 1528 (offset 10 lines). Hunk #8 FAILED at 1638. Hunk #9 succeeded at 1705 (offset 6 lines). 2 out of 9 hunks FAILED so I can't apply it, sorry. It was applied on top of Linus' tree, if that makes any difference. I'll rebase onto yours and re-post the patch. -- Hi Mark, I've seen several attempts to add RS485 support to the omap serial driver and it is always nack-ed. There seems to be concerns about controlling the RTS by software when RS485 is not supported by the UART hardware. Please refer to [1] and [2] for more information. Hm, but we do support RS485 now in the kernel, look at Documentation/serial/serial-rs485.txt. Why can't this driver support it as well if the serial core already does? Hi Greg, Please don't shoot the messenger :-) In fact I was one of those who needed RS485 support in the OMAP serial driver a couple of years ago and we were told that software RS485 is not mainlinable [1]. I just wanted to warn Mark that he could be losing time pushing this but I'm glad to learn that this seems not to be true anymore. thanks, greg k-h Thanks a lot and best regards, Javier [1]: http://comments.gmane.org/gmane.linux.serial/6770 -- 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 v4 3/4] ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM.
From: Hebbar, Gururaja gururaja.heb...@ti.com
This adds a sleep and wake sequence to set the VDD core voltage to the
OPP50 level, 0.950V. This saves power during suspend. The sequences are
specific to the EVM layout and PMIC, the TPS65910. The sequences
are written out by the Cortex-M3.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..81ce169 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -166,6 +166,16 @@
status = okay;
clock-frequency = 40;
+ /* Set OPP50 (0.95V) for VDD core */
+ sleep_sequence = /bits/ 8
+ 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */
+ ;
+
+ /* Set OPP100 (1.10V) for VDD core */
+ wake_sequence = /bits/ 8
+ 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */
+ ;
+
tps: tps@2d {
reg = 0x2d;
};
--
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
[PATCH v4 0/4] ARM: OMAP2+: AM33XX: VDD CORE OPP50 support
This is v4 of the OPP50 (VDD CORE 0.95V during suspend) patch set.
Adjusting voltages to this lower operating point during suspend saves
additional power. This operating point can only be reached when SDRAM is
in self refresh and certain DPLLs have been put into bypass mode. This
means that the code to change the regulator to run at the correct voltage
must be run from either SRAM or the Cortex-M3 (CM3) PM co-processor must
perform the action.
As different boards will power VDD CORE through different methods, the
necessary steps must be contained within the device tree. In order to
accommodate this, additional device tree properties have been created that
can be placed in I2C bus nodes. The properties give a sequence of I2C
commands that should be run at suspend and resume time.
The purpose and method of executing these sequences is left up to each
platform. In the case of the am33xx, the CM3 firmware writes out the
simple I2C sequences.
Each sequence is a series of I2C write commands. The first byte is the
length of the write, the second byte the I2C device to address, and the
following bytes are the message.
Example:
i2c0: i2c@44e0b000 {
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
status = okay;
clock-frequency = 40;
/* Set OPP50 (0.95V) for VDD core */
sleep_sequence = /bits/ 8
0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */
;
/* Set OPP100 (1.10V) for VDD core */
wake_sequence = /bits/ 8
0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */
;
tps: tps@2d {
reg = 0x2d;
};
};
In the above example, the sequence 0x25 0x1f is written to the I2C
device at address 0x2d (the TPS65910 PMIC). The PMIC interprets that as
a write to a register at address 0x25.
I'd really like to get some feedback on the devicetree bindings.
The patch set depends on the latest am335x suspend resume patch set from Dave
Gerlach[1], which also depends on the latest Mailbox patch set from Suman
Anna[2], and the latest CM3 firmware[3].
Changes since v1:
* Rebased onto new am335x PM branch
* Changed to use 5th param register
Changes since v2:
* Pass bus speed in kHz to M3 firmware
Changes since v3:
* Rebase to Dave Gerlach's am335x suspend/resume patch set
* Add device tree documentation
* Add dts changes for evmsk and gp evm
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/102561
[2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/258196
[3]
http://arago-project.org/git/projects/?p=am33x-cm3.git;a=shortlog;h=refs/heads/next2
Russ Dill (4):
ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support
ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone.
ARM: dts: add AM33XX vdd core opp50 suspend for AM335X GP EVM.
ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK
.../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++
arch/arm/boot/dts/am335x-bone.dts | 25 +-
arch/arm/boot/dts/am335x-evm.dts | 10 +++
arch/arm/boot/dts/am335x-evmsk.dts | 10 +++
arch/arm/mach-omap2/control.c | 1 +
arch/arm/mach-omap2/pm33xx.c | 89 ++
arch/arm/mach-omap2/pm33xx.h | 2 +
arch/arm/mach-omap2/wkup_m3.c | 57 --
8 files changed, 230 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt
--
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
[PATCH v4 2/4] ARM: dts: add AM33XX vdd core opp50 suspend for Beaglebone.
Changes since v1:
* Rebased onto new am335x PM branch
This adds a sleep and wake sequence to set the VDD core voltage to the
OPP50 level, 0.950V. This saves power during suspend. The sequences are
specific to the Beaglebone layout and PMIC, the TPS65217. The sequences
are written out by the Cortex-M3.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 444b4ed..3f6528d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -127,10 +127,33 @@
status = okay;
clock-frequency = 40;
+ /* Set OPP50 (0.95V) for VDD core */
+ sleep_sequence = /bits/ 8
+ 0x02 0x24 0x0b 0x6d /* Password unlock 1 */
+ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */
+ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */
+ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ ;
+
+ /* Set OPP100 (1.10V) for VDD core */
+ wake_sequence = /bits/ 8
+ 0x02 0x24 0x0b 0x6d /* Password unlock 1 */
+ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */
+ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */
+ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ ;
+
tps: tps@24 {
reg = 0x24;
};
-
};
};
--
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
[PATCH v4 1/4] ARM: OMAP2+: AM33XX: I2C Sleep/wake sequence support
Changes since v1:
* Rebased onto new am335x PM branch
* Changed to use 5th param register
Changes since v2:
* Passes I2C bus speed in kHz to M3 firmware
Changes since v3:
* Rebased to 3.11-rc3, moves some functionality to wkup_m3.c
* Additional comments
* Added device-tree binding documentation
This patch adds the ability to pass an I2C sleep sequence and wake sequence
to the Cortex-M3. This is useful for adjusting voltages during sleep that
cannot be lowered while SDRAM is active. A modified M3 firmware with I2C
support is required.
Each sequence is a series of I2C transfers in the form:
u8 length | u8 chip address | u8 byte0/reg address | u8 byte 1 | u8 byte n ...
The length indicates the number of bytes to transfer, including the register
address. The length of each transfer is limited by the I2C buffer size of
32 bytes.
The sequences are taken from the i2c1 node in the device tree. The property
name for the sleep sequence is sleep_sequence and the property name for
the wake sequence is wake_sequence. Each property should be an array of
bytes.
No actions are performed if the properties are not present in the device
tree.
Signed-off-by: Russ Dill russ.d...@ti.com
---
.../devicetree/bindings/i2c/i2c-suspend-resume.txt | 44 +++
arch/arm/mach-omap2/control.c | 1 +
arch/arm/mach-omap2/pm33xx.c | 89 ++
arch/arm/mach-omap2/pm33xx.h | 2 +
arch/arm/mach-omap2/wkup_m3.c | 57 --
5 files changed, 186 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt
b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt
new file mode 100644
index 000..af19372
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-suspend-resume.txt
@@ -0,0 +1,44 @@
+I2C suspend/resume sequences
+
+This provides the ability for a simple I2C sequence to be written at
+suspend time and resume time. This is for sequences that cannot be written
+by the I2C bus driver for reasons such as needing to be run from SRAM
+or needing to be written by firmware.
+
+The sequence is composed of messages. Each message contains a length byte,
+an address byte, and then the message.
+
+Optional properties:
+- sleep_sequence
+ I2C sequence to write during suspend
+
+- wake_sequence
+ I2C sequence to write during wake
+
+Examples :
+
+i2c0: i2c@0 {
+ /* Set OPP50 (0.95V) for VDD core */
+ sleep_sequence = /bits/ 8
+ 0x02 0x24 0x0b 0x6d /* Password unlock 1 */
+ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */
+ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */
+ 0x02 0x24 0x10 0x02 /* Set DCDC3 to 0.95V */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ ;
+
+ /* Set OPP100 (1.10V) for VDD core */
+ wake_sequence = /bits/ 8
+ 0x02 0x24 0x0b 0x6d /* Password unlock 1 */
+ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */
+ 0x02 0x24 0x0b 0x6d /* Password unlock 2 */
+ 0x02 0x24 0x10 0x08 /* Set DCDC3 to 1.1V */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 1 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ 0x02 0x24 0x0b 0x6c /* Password unlock 2 */
+ 0x02 0x24 0x11 0x86 /* Apply DCDC changes */
+ ;
+}
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 934041a..dfbd5f0 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -639,6 +639,7 @@ void am33xx_pm_ipc_cmd(struct am33xx_ipc_data *data)
omap_ctrl_writel(data-param1, AM33XX_CONTROL_IPC_MSG_REG2);
omap_ctrl_writel(data-param2, AM33XX_CONTROL_IPC_MSG_REG3);
omap_ctrl_writel(data-param3, AM33XX_CONTROL_IPC_MSG_REG4);
+ omap_ctrl_writel(data-param4, AM33XX_CONTROL_IPC_MSG_REG5);
}
int am33xx_pm_status(void)
diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
index d291c76..8880da3 100644
--- a/arch/arm/mach-omap2/pm33xx.c
+++ b/arch/arm/mach-omap2/pm33xx.c
@@ -29,6 +29,7 @@
#include linux/ti_emif.h
#include linux/omap-mailbox.h
+#include asm/unaligned.h
#include asm/suspend.h
#include asm/proc-fns.h
#include asm/sizes.h
@@ -50,6 +51,10 @@
static void __iomem *am33xx_emif_base;
static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm;
static struct clockdomain *gfx_l4ls_clkdm;
+static char *am33xx_i2c_sleep_sequence;
+static char *am33xx_i2c_wake_sequence;
+static size_t i2c_sleep_sequence_sz;
+static size_t i2c_wake_sequence_sz;
struct wakeup_src wakeups[] = {
{.irq_nr = 35, .src =
[PATCH v4 4/4] ARM: dts: AM33XX vdd core opp50 suspend for EVM-SK
From: Hebbar, Gururaja gururaja.heb...@ti.com
This adds a sleep and wake sequence to set the VDD core voltage to the
OPP50 level, 0.950V. This saves power during suspend. The sequences are
specific to the EVM-SK layout and PMIC, the TPS65910. The sequences
are written out by the Cortex-M3.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0c8ad17..704bbb3 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -174,6 +174,16 @@
status = okay;
clock-frequency = 40;
+ /* Set OPP50 (0.95V) for VDD core */
+ sleep_sequence = /bits/ 8
+ 0x02 0x2d 0x25 0x1f /* Set VDD2 to 0.95V */
+ ;
+
+ /* Set OPP100 (1.10V) for VDD core */
+ wake_sequence = /bits/ 8
+ 0x02 0x2d 0x25 0x2b /* Set VDD2 to 1.1V */
+ ;
+
tps: tps@2d {
reg = 0x2d;
};
--
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 01/15] drivers: phy: add generic PHY framework
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I
wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing
things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1,
phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change
and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup
methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned
manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id,
is
frought with fragility and will break in the future in various
ways
when
devices get added to systems, making these strings constantly
have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that
this
happens today with the clock code, doesn't make it right, it
makes
the
clock code wrong. Others have already said that this is wrong
there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be
removed,
the
device id should be automatically created by the phy core just
to
make
things unique in sysfs, and no driver code should _ever_ be
reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this
subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people
trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already
points
to a big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will
end up
adding similar infrastructure to the driver themselves to make
sure
we
don't end up with duplicate names in sysfs in case we have
multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we
can
give the correct binding information to the PHY framework. I think
we
can drop having this non-dt support in PHY framework? I see only
one
platform (OMAP3) going to be needing this non-dt support and we
can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we
lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns
its
own id and we *don't* want to add any requirement that the ID must
be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid
of
*phy_init_data* in the v10 patch series.
OK, so the PHY device name would have a fixed part, passed as
platform data of the controller and a variable part appended
by the PHY core, depending on the number of registered PHYs ?
Then same PHY names would be passed as the PHY provider driver's
platform data ?
Then if there are 2 instances of the above (same names in platform
data) how would be determined which PHY controller is linked to
which PHY supplier ?
I guess you want each device instance to have different PHY device
names already in platform data ? That might work. We probably will
be focused mostly on DT anyway. It seem without DT we are trying
to find some layer that would allow us to couple relevant devices
and overcome driver core inconvenience that it provides to means
to identify specific devices in advance. :) Your proposal sounds
reasonable, however I might be missing some details or corner cases.
What about slightly altering the concept of v9 to pass a pointer to
struct device instead of device name inside phy_init_data?
As Felipe said, we don't want to pass pointers in platform_data
to/from random subsystems. We pass data, passing pointers would
be a total mess IMHO.
Well, this
Re: [PATCH 1/2] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*
Hi, On Wednesday 14 August 2013 12:43 AM, Stephen Warren wrote: On 08/12/2013 11:37 PM, Kishon Vijay Abraham I wrote: The Palmas device contains only a USB VID detector, so added a compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible s/Dint/Didn't/ diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt PALMAS USB COMPARATOR Required Properties: - - compatible : Should be ti,palmas-usb or ti,twl6035-usb + - compatible : Should be ti,palmas-usb or ti,twl6035-usb or + ti,palmas-usb-vid. So are ti,palmas-usb and ti,twl6035-usb full EHCI controllers then? No. I thought I shouldn't remove those if someone is already using those compatible value. 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
