Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to about 170 overflows in 10 minutes.
Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
support ? That should help you a lot.
I'll have a look at that series. Thanks for pointing it out.
drivers/tty/serial/omap-serial.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 14a0167..57664b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up,
unsigned int lsr)
}
/**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+ struct uart_omap_port *up = dev_id;
+ unsigned int iir = serial_in(up, UART_IIR);
+
+ if (iir UART_IIR_NO_INT)
+ return IRQ_NONE;
+
+ disable_irq_nosync(up-port.irq);
NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
registers (basically clearing IER).
Given the work that's been done on the 8250 based driver, what are the
short-term chances omap-serial will be dropped? I'd be happy to improve
here if it makes sense to do so. If the 8250 based driver is going to
replace omap-serial anyway on the short term, I don't see the point of
further developing this patch. The others would still make sense in my
opinion.
Thanks,
Frans
--
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/1] clk: ti: add support for external clock provider
On 08/19/2014 04:22 PM, Mark Rutland wrote:
Hi Tero,
On Fri, Aug 01, 2014 at 02:15:48PM +0100, Tero Kristo wrote:
External clock provider can now be used to register external clocks under
it. This is needed as the TI clock driver only registers clocks
hierarchically under clock providers, and external clocks do not belong
under any of the current ones.
I must admit that I don't understand the justification for this binding.
Why can't these clocks be descrbied elsewhere and wired up as usual? Why
must they be under the TI clock provide node?
From the limited description above it sounds like the only reason this
exists is to work around a deficiency in the TI clock driver. That does
not sound like a very good reason for having this.
I wouldn't call it a deficiency, but its by design due to need for
registering clocks and clock providers hierarchically.
I guess it might be possible to re-work the TI clock init to check for
the parent node, and if it is a clock provider, see if it has been
initialized or not. The clock provider maps the IO range so it must be
initialized before any clocks under it are initialized. I'll experiment
with this a bit and see how it works out.
-Tero
Thanks,
Mark.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/arm/omap/ext-clocks.txt| 32
arch/arm/mach-omap2/io.c | 12 ++--
drivers/clk/ti/clk.c | 23 ++
include/linux/clk/ti.h |2 ++
4 files changed, 67 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
b/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
new file mode 100644
index 000..8e784bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/ext-clocks.txt
@@ -0,0 +1,32 @@
+TI external clock provider properties
+
+External clock provider is used to group SoC external board specific
+clock nodes. A separate provider node is required as the TI clock
+driver registers clocks hierarchically.
+
+Required properties:
+- compatible: Shall be: ti,external-clocks
+- clocks: Contains the external clocks for the board
+- clockdomains:Contains the external clockdomains for the board
+
+Example:
+
+ext_clocks {
+ compatible = ti,external-clocks;
+
+ ext_clocks: clocks {
+ };
+
+ ext_clockdomains: clockdomains {
+ };
+};
+
+...
+
+ext_clocks {
+ gpio_test_clock {
+ compatible = gpio-clock;
+ #clock-cells = 0;
+ enable-gpios = gpio5 25 GPIO_ACTIVE_HIGH;
+ };
+};
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 8f55945..77be18b 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -21,6 +21,8 @@
#include linux/init.h
#include linux/io.h
#include linux/clk.h
+#include linux/clk-provider.h
+#include linux/clk/ti.h
#include asm/tlb.h
#include asm/mach/map.h
@@ -729,8 +731,14 @@ int __init omap_clk_init(void)
return 0;
ret = of_prcm_init();
- if (!ret)
- ret = omap_clk_soc_init();
+ if (ret)
+ return ret;
+
+ ret = ti_dt_clk_ext_init();
+ if (ret)
+ return ret;
+
+ ret = omap_clk_soc_init();
return ret;
}
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index b1a6f71..c84ce4d 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -165,3 +165,26 @@ void ti_dt_clk_init_provider(struct device_node *parent,
int index)
kfree(retry);
}
}
+
+static struct of_device_id ti_ext_clk_match_table[] = {
+ { .compatible = ti,external-clocks },
+ { }
+};
+
+/**
+ * ti_dt_clk_ext_init - initialize external clocks from DT
+ *
+ * Some clocks are provided from external chips outside the main SoC.
+ * The details for these are given under a special DT node, which will
+ * be parsed by this function.
+ */
+int ti_dt_clk_ext_init(void)
+{
+ struct device_node *np;
+
+ for_each_matching_node(np, ti_ext_clk_match_table) {
+ ti_dt_clk_init_provider(np, -1);
+ }
+
+ return 0;
+}
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index e8d8a35..188270c 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -310,6 +310,8 @@ int am43xx_dt_clk_init(void);
int omap2420_dt_clk_init(void);
int omap2430_dt_clk_init(void);
+int ti_dt_clk_ext_init(void);
+
#ifdef CONFIG_OF
void of_ti_clk_allow_autoidle_all(void);
void of_ti_clk_deny_autoidle_all(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send
Re: [PATCH 03/15] tty: serial: 8250_core: add run time pm
Hi,
On Fri, Aug 15, 2014 at 07:42:31PM +0200, Sebastian Andrzej Siewior wrote:
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1899,12 +1984,22 @@ static void wait_for_xmitr(struct uart_8250_port *up,
int bits)
static int serial8250_get_poll_char(struct uart_port *port)
{
- unsigned char lsr = serial_port_in(port, UART_LSR);
+ unsigned char lsr;
+ int status;
+
+ serial8250_rpm_get(up);
or up won't be defined below. You probably need
+ struct uart_8250_port *up = up_to_u8250p(port);
somewhere in there.
- if (!(lsr UART_LSR_DR))
- return NO_POLL_CHAR;
+ lsr = serial_port_in(port, UART_LSR);
- return serial_port_in(port, UART_RX);
+ if (!(lsr UART_LSR_DR)) {
+ status = NO_POLL_CHAR;
+ goto out;
+ }
+
+ status = serial_port_in(port, UART_RX);
+out:
+ serial8250_rpm_put(up);
+ return status;
}
Cheers,
Frans
--
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 03/15] tty: serial: 8250_core: add run time pm
On Wed, Aug 20, 2014 at 11:23:21AM +0200, Frans Klaver wrote:
Hi,
On Fri, Aug 15, 2014 at 07:42:31PM +0200, Sebastian Andrzej Siewior wrote:
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1899,12 +1984,22 @@ static void wait_for_xmitr(struct uart_8250_port
*up, int bits)
static int serial8250_get_poll_char(struct uart_port *port)
{
- unsigned char lsr = serial_port_in(port, UART_LSR);
+ unsigned char lsr;
+ int status;
+
+ serial8250_rpm_get(up);
or up won't be defined below. You probably need
Obviously I meant to say that 'up' won't be defined here.
+ struct uart_8250_port *up = up_to_u8250p(port);
somewhere in there.
- if (!(lsr UART_LSR_DR))
- return NO_POLL_CHAR;
+ lsr = serial_port_in(port, UART_LSR);
- return serial_port_in(port, UART_RX);
+ if (!(lsr UART_LSR_DR)) {
+ status = NO_POLL_CHAR;
+ goto out;
+ }
+
+ status = serial_port_in(port, UART_RX);
+out:
+ serial8250_rpm_put(up);
+ return status;
}
Cheers,
Frans
--
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] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators
On Tue, 19 Aug 2014, Tony Lindgren wrote: Commit 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle) added support for configuring the PMIC to cut off resources during deeper idle states to save power. This however caused regression for n900 display power that needed the PMIC configuration to be disabled with commit d937678ab625 (ARM: dts: Revert enabling of twl configuration for n900). Turns out the root cause of the problem is that we must use TWL4030_RESCONFIG_UNDEF instead of DEV_GRP_NULL to avoid disabling regulators that may have been enabled before the init function for twl4030-power.c runs. With TWL4030_RESCONFIG_UNDEF we let the regulator framework control the regulators like it should. Here we need to only configure the sys_clken and sys_off_mode triggers for the regulators that cannot be done by the regulator framework as it's not running at that point. This allows us to enable the PMIC configuration for n900. Fixes: 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle) Cc: sta...@vger.kernel.org # v3.16 Signed-off-by: Tony Lindgren t...@atomide.com --- Lee, can you please pick this one for the v3.17-rc series? Applied with Aaro's Tested-by. -- Lee Jones Linaro STMicroelectronics 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 v2 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On Tue, Aug 19, 2014 at 08:40:51PM +0100, Jyri Sarha wrote:
On 08/19/2014 04:16 PM, Mark Rutland wrote:
On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote:
Add machine driver support for BeagleBone-Black HDMI audio. BBB has
NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
44100 Hz sample-rate and it's multiples can not be accurately produced
on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-evm-audio.txt |4 +-
sound/soc/davinci/davinci-evm.c| 82
+++-
2 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 963e100..c137436 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,9 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
-- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible : ti,da830-evm-audio : for DM365/DA8xx/OMAPL1x/AM33xx
+ ti,am335x-beaglebone-black-audio : for Beaglebone-black
HDMI
+audio
To keep this legible I'd recommend reorganising this like:
- compatible: should contain one of:
* ti,da830-evm-audio for DM365/DA8xx/OMAPL1x/AM33xx
* ti,am335x-beaglebone-black-audio for Beaglebone-black HDMI audio
The above looks indeed better. I'll make the change. Oh, and I probably
should change the first line to something like:
* TI SoC audio using McASP to connect to TLV320AIC3X or HDMI endcoder
For the BBB case, do you expect both strings or just the BBB-specific
string?
Normally just the one. In theory a BBB with an audio-cape on top could
utilize another sound node with ti,da830-evm-audio compatible property.
Sorry, I meant in the same node. I take it we never expect:
compatible = ti,am335x-beaglebone-black-audio, ti,da830-evm-audio;
Is the 'x' in the BBB string a wildcard? If we know the particular
number for BBB we should use that.
Yes, its a wild card. BBBs have been made at least with AM3358 and
AM3359 SoCs.
In general we've pushed back against wildcard strings, and used the
first implementation for the naming. We should be able to use
ti,am3358-beaglebone-black-audio for AM335{8,9} assuming the block is
the same? Otherwise we might need separate strings anyway.
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 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On 08/20/2014 03:34 PM, Mark Rutland wrote:
...
Sorry, I meant in the same node. I take it we never expect:
compatible = ti,am335x-beaglebone-black-audio, ti,da830-evm-audio;
No never like that.
Is the 'x' in the BBB string a wildcard? If we know the particular
number for BBB we should use that.
Yes, its a wild card. BBBs have been made at least with AM3358 and
AM3359 SoCs.
In general we've pushed back against wildcard strings, and used the
first implementation for the naming. We should be able to use
ti,am3358-beaglebone-black-audio for AM335{8,9} assuming the block is
the same? Otherwise we might need separate strings anyway.
At least the relevant block (McASP) is the same. AM335x is commonly used
in all TI documentation, but I am not picky am3358 is fine with me.
Could we drop the SoC id completely and make it just
beaglebone-black-audio?
The board design is the unique factor here, not the SoC. McASP block can
be found from several TI SoCs.
Cheers,
Jyri
--
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 3/4] tty: omap-serial: use threaded interrupt handler
On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling
reduces
this to about 170 overflows in 10 minutes.
Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
support ? That should help you a lot.
I'll have a look at that series. Thanks for pointing it out.
drivers/tty/serial/omap-serial.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 14a0167..57664b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port
*up, unsigned int lsr)
}
/**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+ struct uart_omap_port *up = dev_id;
+ unsigned int iir = serial_in(up, UART_IIR);
+
+ if (iir UART_IIR_NO_INT)
+ return IRQ_NONE;
+
+ disable_irq_nosync(up-port.irq);
NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
registers (basically clearing IER).
Given the work that's been done on the 8250 based driver, what are the
short-term chances omap-serial will be dropped? I'd be happy to improve
here if it makes sense to do so. If the 8250 based driver is going to
replace omap-serial anyway on the short term, I don't see the point of
further developing this patch. The others would still make sense in my
opinion.
if we find a way to maintain the same ttyO* naming scheme and make it
coexist with ttyS* naming, then we could drop as soon as 8250_omap is
ready for prime time.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Wed, Jul 30, 2014 at 04:28:11PM +0100, Peter Griffin wrote: -ENOLOG Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Lee Jones lee.jo...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 702ca10..269ad3b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1325,6 +1325,7 @@ F: drivers/pinctrl/pinctrl-st.c F: drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c +F: drivers/usb/dwc3/dwc3-st.c also doesn't apply, please rebase on v3.17-rc1. As for the other two patches, I'm reviewing them right now and they apply cleanly, at least. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
On Wed, Jul 30, 2014 at 04:28:10PM +0100, Peter Griffin wrote:
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 69
+++
1 file changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..de3fea3
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,69 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible: must be st,stih407-dwc3
+ - reg : glue logic base address and USB syscfg ctrl register
offset
+ - reg-names : should be reg-glue and syscfg-reg
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets: list of phandle and reset specifier pairs. There should be
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be
powerdown and softreset
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names : A pinctrl state named default must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver,
as the default value
+is otg, which isn't supported by this SoC. Valid dr_mode values for
dwc3-st are either host
+or device.
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = disabled;
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN;
+ softreset STIH407_MIPHY2_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host
+ usb-phy = usb3_phy;
+ phy-names = usb2-phy;
+ phys= usb2_picophy2;
why are you using different binding for usb2 and usb3 phys ? Why can't
you just:
phys-names = usb2-phy, usb3-phy;
phys= usb2_picophy2, usb3_phy;
??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Wed, Jul 30, 2014 at 04:28:09PM +0100, Peter Griffin wrote:
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 336
+
3 files changed, 346 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..6c85c43 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3_HOST
this seems wrong as USB_DWC3_{HOST,GADGET,DUAL_ROLE} are booleans and
USB_DWC3_ST is a tristate. Better to stick with defaulting to USB_DWC3
instead like all the others.
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS)+= dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..227698f
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,336 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics
platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/reset.h
+#include linux/usb/of.h
+
+#include core.h
+#include io.h
+
+/* glue registers */
+#define CLKRST_CTRL 0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N BIT(4)
+#define EXT_CFG_RESET_N BIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISIONBIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL10x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_signal_name from usb3_top is selected
+ * 2’b10 : pipew_signal_name from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG30 0x0
+#define USB2_VBUS_UTMIOTG0x1
+#define USB2_VBUS_PIPEW 0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n)(n 0)
+#define SEL_OVERRIDE_POWERPRESENT(n) (n 4)
+#define SEL_OVERRIDE_BVALID(n) (n 8)
+
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK0xffe
+#define USB_SET_PORT_DEVICE 0x1
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev: device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap: regmap pointer for getting syscfg
+ * @syscfg_reg_off: usb syscfg control offset
+ * @dr_mode: drd static host/device config
+ * @rstc_pwrdn: rest controller for powerdown signal
+ * @rstc_rst:reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+ struct device *dev;
+ void __iomem *glue_base;
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Wed, Jul 23, 2014 at 03:33:23PM +0100, Peter Griffin wrote: + reset_control_assert(dwc3_data-rstc_pwrdn); + + pinctrl_pm_select_sleep_state(dev); pinctrl will select sleep and default states automatically for you. I've left this in v3, as greping around I couldn't see how that could happen automatically. Also I just double checked with linusw on irc who confirmed that the only state which is ever auto-selected is default. All other states, as well as going back to default state need to be explicitly called. Hope thats ok. yeah, that's fine. Thanks :-) -- balbi signature.asc Description: Digital signature
[PATCH v4 4/7] net: cpsw: Replace pr_err by dev_err
Use dev_err instead of pr_err.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Reviewed-by: Wolfram Sang w...@the-dreams.de
---
drivers/net/ethernet/ti/cpsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index f09b4639ad31..0bc2c2a2c236 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1921,7 +1921,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
mdio = of_find_device_by_node(mdio_node);
of_node_put(mdio_node);
if (!mdio) {
- pr_err(Missing mdio platform device\n);
+ dev_err(pdev-dev, Missing mdio platform device\n);
return -EINVAL;
}
snprintf(slave_data-phy_id, sizeof(slave_data-phy_id),
--
2.1.0.rc1
--
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 7/7] arm: dts: am33xx, Add syscon phandle to cpsw node
There are 2 MACIDs stored in the control module of the am33xx. These are
read by the cpsw driver if no valid MACID was found in the devicetree.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Reviewed-by: Wolfram Sang w...@the-dreams.de
---
arch/arm/boot/dts/am33xx.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 25e38b6ac376..13e44b0f5adc 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -701,6 +701,7 @@
*/
interrupts = 40 41 42 43;
ranges;
+ syscon = cm;
status = disabled;
davinci_mdio: mdio@4a101000 {
--
2.1.0.rc1
--
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/7] DT doc: net: cpsw mac-address is optional
mac-address is an optional property. If no mac-address is set, a random mac-address will be generated. Signed-off-by: Markus Pargmann m...@pengutronix.de Reviewed-by: Wolfram Sang w...@the-dreams.de --- Documentation/devicetree/bindings/net/cpsw.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index ae2b8b7f9c38..107caf174a0e 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -29,10 +29,10 @@ Slave Properties: Required properties: - phy_id : Specifies slave phy id - phy-mode : See ethernet.txt file in the same directory -- mac-address : See ethernet.txt file in the same directory Optional properties: - dual_emac_res_vlan : Specifies VID to be used to segregate the ports +- mac-address : See ethernet.txt file in the same directory Note: ti,hwmods field is used to fetch the base address and irq resources from TI, omap hwmod data base during device registration. -- 2.1.0.rc1 -- 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 6/7] am33xx: define syscon control module device node
Signed-off-by: Markus Pargmann m...@pengutronix.de
Reviewed-by: Wolfram Sang w...@the-dreams.de
---
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..25e38b6ac376 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -132,6 +132,11 @@
};
};
+ cm: syscon@44e1 {
+ compatible = ti,am33xx-controlmodule, syscon;
+ reg = 0x44e1 0x800;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
--
2.1.0.rc1
--
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/7] net: cpsw: Add missing return value
ret is set 0 at this point, so jumping to that error label would result
in a return value of 0. Set ret to -ENOMEM to return a proper error
value.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Reviewed-by: Wolfram Sang w...@the-dreams.de
---
drivers/net/ethernet/ti/cpsw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 999fb72688d2..f09b4639ad31 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2063,6 +2063,7 @@ static int cpsw_probe(struct platform_device *pdev)
priv-irq_enabled = true;
if (!priv-cpts) {
dev_err(pdev-dev, error allocating cpts\n);
+ ret = -ENOMEM;
goto clean_ndev_ret;
}
--
2.1.0.rc1
--
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/7] net: cpsw: Support for am335x chip MACIDs
This series adds support to the cpsw driver to read the MACIDs of the am335x chip and use them as fallback. These addresses are only used if there are no mac addresses in the devicetree, for example set by a bootloader. In v4 I removed an unused Makefile rule which was introduced by me when this series introduced a seperate driver to read the MACID. As the code is now integrated into the main driver this is not necessary anymore. Best regards, Markus Pargmann Markus Pargmann (7): DT doc: net: cpsw mac-address is optional net: cpsw: Add missing return value net: cpsw: header, Add missing include net: cpsw: Replace pr_err by dev_err net: cpsw: Add am33xx MACID readout am33xx: define syscon control module device node arm: dts: am33xx, Add syscon phandle to cpsw node Documentation/devicetree/bindings/net/cpsw.txt | 6 +++- arch/arm/boot/dts/am33xx.dtsi | 6 drivers/net/ethernet/ti/Kconfig| 2 ++ drivers/net/ethernet/ti/cpsw.c | 49 -- drivers/net/ethernet/ti/cpsw.h | 1 + 5 files changed, 60 insertions(+), 4 deletions(-) -- 2.1.0.rc1 -- 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 5/7] net: cpsw: Add am33xx MACID readout
This patch adds a function to get the MACIDs from the am33xx SoC
control module registers which hold unique vendor MACIDs. This is only
used if of_get_mac_address() fails to get a valid mac address.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Reviewed-by: Wolfram Sang w...@the-dreams.de
Tested-by: Steven Rostedt rost...@goodmis.org
---
Documentation/devicetree/bindings/net/cpsw.txt | 4 +++
drivers/net/ethernet/ti/Kconfig| 2 ++
drivers/net/ethernet/ti/cpsw.c | 46 --
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 107caf174a0e..33fe8462edf4 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Optional properties:
- ti,hwmods: Must be cpgmac0
- no_bd_ram: Must be 0 or 1
- dual_emac: Specifies Switch to act as Dual EMAC
+- syscon : Phandle to the system control device node, which is
+ the control module device of the am33x
Slave Properties:
Required properties:
@@ -57,6 +59,7 @@ Examples:
active_slave = 0;
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
+ syscon = cm;
cpsw_emac0: slave@0 {
phy_id = davinci_mdio, 0;
phy-mode = rgmii-txid;
@@ -85,6 +88,7 @@ Examples:
active_slave = 0;
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
+ syscon = cm;
cpsw_emac0: slave@0 {
phy_id = davinci_mdio, 0;
phy-mode = rgmii-txid;
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 1769700a6070..5d8cb7956113 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -62,6 +62,8 @@ config TI_CPSW
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
select TI_CPSW_PHY_SEL
+ select MFD_SYSCON
+ select REGMAP
---help---
This driver supports TI's CPSW Ethernet Switch.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 0bc2c2a2c236..aaf8a42f9633 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -33,6 +33,8 @@
#include linux/of_net.h
#include linux/of_device.h
#include linux/if_vlan.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include linux/pinctrl/consumer.h
@@ -1816,6 +1818,39 @@ static void cpsw_slave_init(struct cpsw_slave *slave,
struct cpsw_priv *priv,
slave-port_vlan = data-dual_emac_res_vlan;
}
+#define AM33XX_CTRL_MAC_LO_REG(id) (0x630 + 0x8 * id)
+#define AM33XX_CTRL_MAC_HI_REG(id) (0x630 + 0x8 * id + 0x4)
+
+static int cpsw_am33xx_cm_get_macid(struct device *dev, int slave,
+ u8 *mac_addr)
+{
+ u32 macid_lo;
+ u32 macid_hi;
+ struct regmap *syscon;
+
+ if (!of_machine_is_compatible(ti,am33xx))
+ return 0;
+
+ syscon = syscon_regmap_lookup_by_phandle(dev-of_node, syscon);
+ if (IS_ERR(syscon)) {
+ if (PTR_ERR(syscon) == -ENODEV)
+ return 0;
+ return PTR_ERR(syscon);
+ }
+
+ regmap_read(syscon, AM33XX_CTRL_MAC_LO_REG(slave), macid_lo);
+ regmap_read(syscon, AM33XX_CTRL_MAC_HI_REG(slave), macid_hi);
+
+ mac_addr[5] = (macid_lo 8) 0xff;
+ mac_addr[4] = macid_lo 0xff;
+ mac_addr[3] = (macid_hi 24) 0xff;
+ mac_addr[2] = (macid_hi 16) 0xff;
+ mac_addr[1] = (macid_hi 8) 0xff;
+ mac_addr[0] = macid_hi 0xff;
+
+ return 0;
+}
+
static int cpsw_probe_dt(struct cpsw_platform_data *data,
struct platform_device *pdev)
{
@@ -1928,8 +1963,15 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
PHY_ID_FMT, mdio-name, phyid);
mac_addr = of_get_mac_address(slave_node);
- if (mac_addr)
- memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
+ if (mac_addr) {
+ memcpy(slave_data-mac_addr, mac_addr,
+ ETH_ALEN);
+ } else {
+ ret = cpsw_am33xx_cm_get_macid(pdev-dev, i,
+ slave_data-mac_addr);
+ if (ret)
+ return ret;
+ }
slave_data-phy_if = of_get_phy_mode(slave_node);
if (slave_data-phy_if 0) {
--
2.1.0.rc1
--
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/7] net: cpsw: header, Add missing include
MII_BUS_ID_SIZE is defined in linux/phy.h which is not included in the
cpsw.h file.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Reviewed-by: Wolfram Sang w...@the-dreams.de
---
drivers/net/ethernet/ti/cpsw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
index 574f49da693f..1b710674630c 100644
--- a/drivers/net/ethernet/ti/cpsw.h
+++ b/drivers/net/ethernet/ti/cpsw.h
@@ -15,6 +15,7 @@
#define __CPSW_H__
#include linux/if_ether.h
+#include linux/phy.h
struct cpsw_slave_data {
charphy_id[MII_BUS_ID_SIZE];
--
2.1.0.rc1
--
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
