Re: [PATCH v2 4/6] ARM: dts: omap5: add dwc3 omap dt data
On Sunday 27 January 2013 01:17 AM, Sergei Shtylyov wrote:
Hello.
On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5f59bf2..1703a72 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,17 @@
ti,type = <2>;
};
+omap_dwc3@4a02 {
+compatible = "ti,dwc3";
+ti,hwmods = "usb_otg_ss";
+reg = <0x4a02 0x1ff>;
Shoudn't the "reg" length be 0x200 here? It's length, not limit.
I think 0x1ff is correct. I got the data from hwmod data.
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 01/13] usb: phy: nop: Add device tree support and binding information
On 02/05/2013 09:26 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
>>
>> drivers/usb/otg/nop-usb-xceiv.c| 31 ++
>> 2 files changed, 65 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> new file mode 100644
>> index 000..d7e2726
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -0,0 +1,34 @@
>> +USB NOP PHY
>> +
>> +Required properties:
>> +- compatible: should be usb-nop-xceiv
>> +
>> +Optional properties:
>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>> + /bindings/clock/clock-bindings.txt
>> + This property is required if clock-frequency is specified.
>> +
>> +- clock-names: Should be "main_clk"
>> +
>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>> + be configured to.
>> +
>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>> +
>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>> +
>> +Example:
>> +
>> +hsusb1_phy {
>> +compatible = "usb-nop-xceiv";
>> +clock-frequency = <1920>;
>> +clocks = <&osc 0>;
>> +clock-names = "main_clk";
>> +vcc-supply = <&hsusb1_vcc_regulator>;
>> +reset-supply = <&hsusb1_reset_regulator>;
>> +};
>> +
>> +hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
>> +and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
>> +hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
>> +controls RESET.
>> diff --git a/drivers/usb/otg/nop-usb-xceiv.c
>> b/drivers/usb/otg/nop-usb-xceiv.c
>> index ac027a1..adbb7ab 100644
>> --- a/drivers/usb/otg/nop-usb-xceiv.c
>> +++ b/drivers/usb/otg/nop-usb-xceiv.c
>> @@ -34,6 +34,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> struct nop_usb_xceiv {
>> struct usb_phy phy;
>> @@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct
>> usb_bus *host)
>> return 0;
>> }
>>
>> +static void nop_xeiv_get_dt_pdata(struct device *dev,
>
> asking to remove, but xeiv != xceiv :-)
>
>> +struct nop_usb_xceiv_platform_data *pdata)
>> +{
>> +struct device_node *node = dev->of_node;
>> +u32 clk_rate;
>> +
>> +if (!of_property_read_u32(node, "clock-frequency", &clk_rate))
>> +pdata->clk_rate = clk_rate;
>> +}
>> +
>> static int nop_usb_xceiv_probe(struct platform_device *pdev)
>> {
>> +struct device *dev = &pdev->dev;
>> struct nop_usb_xceiv_platform_data *pdata = pdev->dev.platform_data;
>> struct nop_usb_xceiv*nop;
>> enum usb_phy_type type = USB_PHY_TYPE_USB2;
>> @@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device
>> *pdev)
>> if (!nop->phy.otg)
>> return -ENOMEM;
>>
>> +if (dev->of_node) {
>> +pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> +if (!pdata) {
>> +dev_err(dev, "Memory allocation failure\n");
>> +return -ENOMEM;
>> +}
>> +nop_xeiv_get_dt_pdata(dev, pdata);
>
> actually, I would prefer to not create pdata at all. I mean, ideally
> pdata would be used to initialize fields in your own structure, so first
> move clk_rate to your own private structure, copy pdata's clk_rate value
> to that, then you don't need this hackery when using DT.
>
OK, got it. Will revise.
cheers,
-roger
--
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 4/6] ARM: dts: omap5: add dwc3 omap dt data
On Tue, Feb 05, 2013 at 01:59:26PM +0530, kishon wrote:
> On Sunday 27 January 2013 01:17 AM, Sergei Shtylyov wrote:
> >Hello.
> >
> >On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:
> >
> >>Add dwc3 omap glue data to the omap5 dt data file. The information about
> >>the dt node added here is available @
> >>Documentation/devicetree/bindings/usb/omap-usb.txt
> >
> >>Signed-off-by: Kishon Vijay Abraham I
> >>---
> >> arch/arm/boot/dts/omap5.dtsi | 11 +++
> >> 1 file changed, 11 insertions(+)
> >
> >>diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> >>index 5f59bf2..1703a72 100644
> >>--- a/arch/arm/boot/dts/omap5.dtsi
> >>+++ b/arch/arm/boot/dts/omap5.dtsi
> >>@@ -513,6 +513,17 @@
> >> ti,type = <2>;
> >> };
> >>
> >>+omap_dwc3@4a02 {
> >>+compatible = "ti,dwc3";
> >>+ti,hwmods = "usb_otg_ss";
> >>+reg = <0x4a02 0x1ff>;
> >
> >Shoudn't the "reg" length be 0x200 here? It's length, not limit.
>
> I think 0x1ff is correct. I got the data from hwmod data.
hwmod is utterly wrong. Looking at TRM, it says the size here is 64KiB
(0x1), so is the size for dwc3 itself. Please don't blindly trust
hwmod, make sure you read data from TRM ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V3 5/7] ARM: OMAP3: Update clocksource timer selection
On 02/04/13 21:46, Jon Hunter wrote: > When booting with device-tree for OMAP3 and AM335x devices and a gptimer > is used as the clocksource (which is always the case for AM335x), a > gptimer located in a power domain that is not always-on is selected. > Ideally we should use a gptimer located in a power domain that is always > on (such as the wake-up domain) so that time can be maintained during a > kernel suspend without keeping on additional power domains unnecessarily. > > In order to fix this so that we can select a gptimer located in a power > domain that is always-on, the following changes were made ... > 1. Currently, only when selecting a gptimer to use for a clockevent >timer, do we pass a timer property that can be used to select a >specific gptimer. Change this so that we can pass a property when >selecting a gptimer to use for a clocksource timer too. > 2. Currently, when selecting either a gptimer to use for a clockevent >timer or a clocksource timer and no timer property is passed, then >the first available timer is selected regardless of the properties >it has. Change this so that if no properties are passed, then a timer >that does not have additional features (such as always-on, dsp-irq, >pwm, and secure) is selected. > > Please note that using a gptimer for both clocksource and clockevents > can have a system power impact during idle. The reason being is that > OMAP and AMxxx devices typically only have one gptimer in a power domain > that is always-on. Therefore when the kernel is idle both the clocksource > and clockevent timers will be active and this will keep additional power > domains on. During kernel suspend, only the clocksource timer is active > and therefore, it is better to use a gptimer in a power domain that is > always-on for clocksource. Hmmm... Do I miss something or you have forgot to update the commit message? > > Signed-off-by: Jon Hunter > --- > arch/arm/mach-omap2/timer.c | 33 + > 1 file changed, 21 insertions(+), 12 deletions(-) [...] > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) > -OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon", > -2, "timer_sys_ck"); > +OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, > +1, "timer_sys_ck", "ti,timer-alwon"); > #endif [...] -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET
On 02/05/2013 07:54 AM, kishon wrote:
> On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
>> Add 2 flags, needs_vcc and needs_reset to platform data.
>> If the flag is set and the regulator couldn't be found
>> then we bail out with -EPROBE_DEFER.
>>
>> For device tree boot we depend on presensce of vcc-supply/
>> reset-supply properties to decide if we should bail out
>> with -EPROBE_DEFER or just continue in case the regulator
>> can't be found.
>>
>> This is required for proper functionality in cases where the
>> regulator is needed but is probed later than the PHY device.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/usb/otg/nop-usb-xceiv.c |8
>> include/linux/usb/nop-usb-xceiv.h |4
>> 2 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/otg/nop-usb-xceiv.c
>> b/drivers/usb/otg/nop-usb-xceiv.c
>> index adbb7ab..7860e7569 100644
>> --- a/drivers/usb/otg/nop-usb-xceiv.c
>> +++ b/drivers/usb/otg/nop-usb-xceiv.c
>> @@ -147,6 +147,10 @@ static void nop_xeiv_get_dt_pdata(struct device *dev,
>>
>> if (!of_property_read_u32(node, "clock-frequency", &clk_rate))
>> pdata->clk_rate = clk_rate;
>> +if (of_property_read_bool(node, "vcc-supply"))
>> +pdata->needs_vcc = true;
> This can be written as..
> pdata->needs_vcc = of_property_read_bool(node, "vcc-supply");
OK.
>
>> +if (of_property_read_bool(node, "reset-supply"))
>> +pdata->needs_reset = true;
> same here..
>> }
>>
>> static int nop_usb_xceiv_probe(struct platform_device *pdev)
>> @@ -205,12 +209,16 @@ static int nop_usb_xceiv_probe(struct platform_device
>> *pdev)
>> if (IS_ERR(nop->vcc)) {
>> dev_dbg(&pdev->dev, "Error getting vcc regulator: %ld\n",
>> PTR_ERR(nop->vcc));
>> +if (pdata->needs_vcc)
>> +return -EPROBE_DEFER;
>> }
>>
>> nop->reset = devm_regulator_get(&pdev->dev, "reset");
>> if (IS_ERR(nop->reset)) {
>> dev_dbg(&pdev->dev, "Error getting reset regulator: %ld\n",
>> PTR_ERR(nop->reset));
>> +if (pdata->needs_reset)
>> +return -EPROBE_DEFER;
>> }
>>
>> nop->dev= &pdev->dev;
>> diff --git a/include/linux/usb/nop-usb-xceiv.h
>> b/include/linux/usb/nop-usb-xceiv.h
>> index 3265b61..148d351 100644
>> --- a/include/linux/usb/nop-usb-xceiv.h
>> +++ b/include/linux/usb/nop-usb-xceiv.h
>> @@ -6,6 +6,10 @@
>> struct nop_usb_xceiv_platform_data {
>> enum usb_phy_type type;
>> unsigned long clk_rate;
>> +
>> +/* if set fails with -EPROBE_DEFER if can't get regulator */
>> +unsigned int needs_vcc:1;
>> +unsigned int needs_reset:1;
>
> how about u8 here?
Not sure. Bitfields are usually defined as unsigned int.
cheers,
-roger
--
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 4/6] ARM: dts: omap5: add dwc3 omap dt data
Hi,
On Tuesday 05 February 2013 02:08 PM, Felipe Balbi wrote:
On Tue, Feb 05, 2013 at 01:59:26PM +0530, kishon wrote:
On Sunday 27 January 2013 01:17 AM, Sergei Shtylyov wrote:
Hello.
On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5f59bf2..1703a72 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,17 @@
ti,type = <2>;
};
+omap_dwc3@4a02 {
+compatible = "ti,dwc3";
+ti,hwmods = "usb_otg_ss";
+reg = <0x4a02 0x1ff>;
Shoudn't the "reg" length be 0x200 here? It's length, not limit.
I think 0x1ff is correct. I got the data from hwmod data.
hwmod is utterly wrong. Looking at TRM, it says the size here is 64KiB
(0x1), so is the size for dwc3 itself. Please don't blindly trust
hwmod, make sure you read data from TRM ;-)
hmm..ok. But it has only 17 registers :-D
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 04/13] mfd: omap-usb-tll: Add device tree support
On 02/05/2013 08:04 AM, kishon wrote:
> On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
>> Enable this driver to probe in device tree boot.
>>
>> CC: Samuel Ortiz
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/mfd/omap-usb-tll.txt | 17 +
>> drivers/mfd/omap-usb-tll.c |9 +
>> 2 files changed, 26 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
>> b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
>> new file mode 100644
>> index 000..835cf4f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
>> @@ -0,0 +1,17 @@
>> +OMAP HS USB Host TLL (Transceiver-Less Interface)
>> +
>> +Required properties:
>> +
>> +- compatible : should be "ti,usbhs-tll"
>> +- reg : should contain one register range i.e. start and length
>> +- interrupts : should contain the TLL module's interrupt
>> +- ti,hwmod : must contain "usb_tll_hs"
>> +
>> +Example:
>> +
>> +usbhstll: usbhstll@0x4a062000 {
> The node name shouldn't have 0x. This comment applies to all your patches
> adding device tree support.
OK, will fix.
cheers,
-roger
--
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 09/13] mfd: omap-usb-host: Add device tree support and binding information
On 02/05/2013 08:16 AM, kishon wrote:
> On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
>> Allows the OMAP HS USB host controller to be specified
>> via device tree.
>>
>> CC: Samuel Ortiz
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/mfd/omap-usb-host.txt | 68
>> drivers/mfd/omap-usb-host.c| 83
>> ++--
>> 2 files changed, 145 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> new file mode 100644
>> index 000..2196893
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> @@ -0,0 +1,68 @@
>> +OMAP HS USB Host
>> +
>> +Required properties:
>> +
>> +- compatible: should be "ti,usbhs-host"
>> +- reg: should contain one register range i.e. start and length
>> +- ti,hwmods: must contain "usb_host_hs"
>> +
>> +Optional properties:
>> +
>> +- nports: number of USB ports. Usually this is automatically detected
>> + from the IP's revision register but can be overridden by specifying
>> + this property.
>> +
>> +- portN_mode: Integer specifying the port mode for port N, where N can be
>> + from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
>> + in include/linux/platform_data/usb-omap.h
>> + If the port mode is not specified, that port is treated as unused.
>> +
>> +- single_ulpi_bypass: Must be present if the controller contains a single
>> + ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
>> +
>> +Required properties if child node exists:
>> +
>> +- #address-cells: Must be 1
>> +- #size-cells: Must be 1
>> +- ranges: must be present
>> +
>> +Properties for children:
>> +
>> +The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
>> +See Documentation/devicetree/bindings/usb/omap-ehci.txt and
>> +omap3-ohci.txt
>> +
>> +Example for OMAP4:
>> +
>> +usbhshost: usbhshost@0x4a064000 {
>> +compatible = "ti,usbhs-host";
>> +reg = <0x4a064000 0x800>;
>> +ti,hwmods = "usb_host_hs";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +usbhsohci: ohci@0x4a064800 {
>> +compatible = "ti,omap3-ohci", "usb-ohci";
>> +reg = <0x4a064800 0x400>;
>> +interrupt-parent = <&gic>;
>> +interrupts = <0 76 0x4>;
>> +};
>> +
>> +usbhsehci: ehci@0x4a064c00 {
>> +compatible = "ti,omap-ehci", "usb-ehci";
>> +reg = <0x4a064c00 0x400>;
>> +interrupt-parent = <&gic>;
>> +interrupts = <0 77 0x4>;
>> +};
>> +};
>> +
>> +&usbhshost {
>> +port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
>> +port2_mode = <2>; /* OMAP_EHCI_PORT_MODE_TLL */
>> +port3_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
>> +};
>> +
>> +&usbhsehci {
>> +phy = <&hsusb1_phy 0 &hsusb3_phy>;
>> +};
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index f8ed08e..0f67856 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -1,8 +1,9 @@
>> /**
>>* omap-usb-host.c - The USBHS core driver for OMAP EHCI & OHCI
>>*
>> - * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
>> + * Copyright (C) 2011-2013 Texas Instruments Incorporated -
>> http://www.ti.com
>>* Author: Keshava Munegowda
>> + * Author: Roger Quadros
>>*
>>* This program is free software: you can redistribute it and/or modify
>>* it under the terms of the GNU General Public License version 2 of
>> @@ -27,6 +28,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include "omap-usb.h"
>>
>> @@ -464,6 +467,37 @@ static void omap_usbhs_init(struct device *dev)
>> pm_runtime_put_sync(dev);
>> }
>>
>> +static int usbhs_omap_get_dt_pdata(struct device_node *node,
>> +struct usbhs_omap_platform_data *pdata)
>> +{
>> +int ret, i;
>> +
>> +ret = of_property_read_u32(node, "nports", &pdata->nports);
>> +if (ret)
>> +pdata->nports = 0;
>> +
>> +/* get port modes */
>> +for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
>> +char prop[11];
>> +
>> +snprintf(prop, sizeof(prop), "port%d_mode", i + 1);
>> +ret = of_property_read_u32(node, prop, &pdata->port_mode[i]);
>> +if (ret)
>> +pdata->port_mode[i] = OMAP_USBHS_PORT_MODE_UNUSED;
>> +}
>> +
>> +/* get flags */
>> +pdata->single_ulpi_bypass = of_property_read_bool(node,
>> +"single_ulpi_bypass");
>> +return 0;
>> +}
>> +
>> +static struct of_device_id usbhs_child_match_table[] __initdata = {
>> +{ .compatible = "ti,omap-ehci", },
>> +{ .compatible = "ti,omap-ohci", },
>> +{ }
>> +};
>> +
>> /**
>>* usbhs_omap_probe - initialize TI-based HCDs
>>*
>> @@ -479,6 +513,21 @@ static int usbhs_omap_p
Re: [PATCH 10/13] ARM: dts: OMAP4: Add HS USB Host IP nodes
On 02/05/2013 08:24 AM, kishon wrote:
> On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
>> Adds device nodes for HS USB Host module, TLL module,
>> OHCI and EHCI controllers.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/boot/dts/omap4.dtsi | 30 ++
>> 1 files changed, 30 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 739bb79..3429280 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -529,5 +529,35 @@
>> ti,hwmods = "timer11";
>> ti,timer-pwm;
>> };
>> +
>> +usbhstll: usbhstll@0x4a062000 {
>> +compatible = "ti,usbhs-tll";
>> +reg = <0x4a062000 0x1000>;
>> +interrupts = <0 78 0x4>;
>> +ti,hwmods = "usb_tll_hs";
>> +};
>> +
>> +usbhshost: usbhshost@0x4a064000 {
>> +compatible = "ti,usbhs-host";
>> +reg = <0x4a064000 0x800>;
>> +ti,hwmods = "usb_host_hs";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +usbhsohci: ohci@0x4a064800 {
>> +compatible = "ti,omap3-ohci", "usb-ohci";
>> +reg = <0x4a064800 0x400>;
>> +interrupt-parent = <&gic>;
>
> Just curious.. Were you facing issues if you are not having interrupt-parent
> here? It's also missing in your dt node usbhstll.
Yes I was. Interrupt-parent is not there in any of the children which are at
the same level as usbhstll.
cheers,
-roger
--
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 10/13] ARM: dts: OMAP4: Add HS USB Host IP nodes
On Tuesday 05 February 2013 02:24 PM, Roger Quadros wrote:
On 02/05/2013 08:24 AM, kishon wrote:
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..3429280 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = "timer11";
ti,timer-pwm;
};
+
+usbhstll: usbhstll@0x4a062000 {
+compatible = "ti,usbhs-tll";
+reg = <0x4a062000 0x1000>;
+interrupts = <0 78 0x4>;
+ti,hwmods = "usb_tll_hs";
+};
+
+usbhshost: usbhshost@0x4a064000 {
+compatible = "ti,usbhs-host";
+reg = <0x4a064000 0x800>;
+ti,hwmods = "usb_host_hs";
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+usbhsohci: ohci@0x4a064800 {
+compatible = "ti,omap3-ohci", "usb-ohci";
+reg = <0x4a064800 0x400>;
+interrupt-parent = <&gic>;
Just curious.. Were you facing issues if you are not having interrupt-parent
here? It's also missing in your dt node usbhstll.
Yes I was. Interrupt-parent is not there in any of the children which are at
the same level as usbhstll.
Cool. Thought so :-)
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 10/13] ARM: dts: OMAP4: Add HS USB Host IP nodes
On 02/05/2013 09:41 AM, Felipe Balbi wrote:
> On Mon, Feb 04, 2013 at 05:58:57PM +0200, Roger Quadros wrote:
>> Adds device nodes for HS USB Host module, TLL module,
>> OHCI and EHCI controllers.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/boot/dts/omap4.dtsi | 30 ++
>> 1 files changed, 30 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 739bb79..3429280 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -529,5 +529,35 @@
>> ti,hwmods = "timer11";
>> ti,timer-pwm;
>> };
>> +
>> +usbhstll: usbhstll@0x4a062000 {
>> +compatible = "ti,usbhs-tll";
>> +reg = <0x4a062000 0x1000>;
>> +interrupts = <0 78 0x4>;
>> +ti,hwmods = "usb_tll_hs";
>> +};
>> +
>> +usbhshost: usbhshost@0x4a064000 {
>> +compatible = "ti,usbhs-host";
>> +reg = <0x4a064000 0x800>;
>> +ti,hwmods = "usb_host_hs";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +usbhsohci: ohci@0x4a064800 {
>
> usbhsohci is a bit misleading :-)
>
> How about we stick to ohci and ehci for these nodes ? :-)
>
Was just thinking of a unique label that will point to the OHCI/EHCI
controller in the HS USB subsystem. We need the label to provide
PHY information in the board DT.
If we are sure we won't have another OHCI/EHCI controller then I can
just use ehci/ohci.
cheers,
-roger
--
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 4/6] ARM: dts: omap5: add dwc3 omap dt data
On Tuesday 05 February 2013 02:16 PM, kishon wrote:
Hi,
On Tuesday 05 February 2013 02:08 PM, Felipe Balbi wrote:
On Tue, Feb 05, 2013 at 01:59:26PM +0530, kishon wrote:
On Sunday 27 January 2013 01:17 AM, Sergei Shtylyov wrote:
Hello.
On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:
Add dwc3 omap glue data to the omap5 dt data file. The information
about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 5f59bf2..1703a72 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,17 @@
ti,type = <2>;
};
+omap_dwc3@4a02 {
+compatible = "ti,dwc3";
+ti,hwmods = "usb_otg_ss";
+reg = <0x4a02 0x1ff>;
Shoudn't the "reg" length be 0x200 here? It's length, not limit.
I think 0x1ff is correct. I got the data from hwmod data.
hwmod is utterly wrong. Looking at TRM, it says the size here is 64KiB
(0x1), so is the size for dwc3 itself. Please don't blindly trust
hwmod, make sure you read data from TRM ;-)
hmm..ok. But it has only 17 registers :-D
As Felipe said, it should be 0x200. And if you are
interested in lesser space, there is no need to map entire 64 KB
address space if it isn't being used.
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 01/13] usb: phy: nop: Add device tree support and binding information
On Tue, Feb 05, 2013 at 10:30:49AM +0200, Roger Quadros wrote:
> On 02/05/2013 09:26 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
> >> The PHY clock, clock rate, VCC regulator and RESET regulator
> >> can now be provided via device tree.
> >>
> >> Signed-off-by: Roger Quadros
> >> ---
> >> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
> >>
> >> drivers/usb/otg/nop-usb-xceiv.c| 31
> >> ++
> >> 2 files changed, 65 insertions(+), 0 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> >> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> >> new file mode 100644
> >> index 000..d7e2726
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> >> @@ -0,0 +1,34 @@
> >> +USB NOP PHY
> >> +
> >> +Required properties:
> >> +- compatible: should be usb-nop-xceiv
> >> +
> >> +Optional properties:
> >> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
> >> + /bindings/clock/clock-bindings.txt
> >> + This property is required if clock-frequency is specified.
> >> +
> >> +- clock-names: Should be "main_clk"
> >> +
> >> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
> >> + be configured to.
> >> +
> >> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
> >> +
> >> +- reset-supply: phandle to the regulator that provides power to the PHY.
> >> +
> >> +Example:
> >> +
> >> + hsusb1_phy {
> >> + compatible = "usb-nop-xceiv";
> >> + clock-frequency = <1920>;
> >> + clocks = <&osc 0>;
> >> + clock-names = "main_clk";
> >> + vcc-supply = <&hsusb1_vcc_regulator>;
> >> + reset-supply = <&hsusb1_reset_regulator>;
> >> + };
> >> +
> >> +hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
> >> +and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
> >> +hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
> >> +controls RESET.
> >> diff --git a/drivers/usb/otg/nop-usb-xceiv.c
> >> b/drivers/usb/otg/nop-usb-xceiv.c
> >> index ac027a1..adbb7ab 100644
> >> --- a/drivers/usb/otg/nop-usb-xceiv.c
> >> +++ b/drivers/usb/otg/nop-usb-xceiv.c
> >> @@ -34,6 +34,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> struct nop_usb_xceiv {
> >>struct usb_phy phy;
> >> @@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct
> >> usb_bus *host)
> >>return 0;
> >> }
> >>
> >> +static void nop_xeiv_get_dt_pdata(struct device *dev,
> >
> > asking to remove, but xeiv != xceiv :-)
> >
> >> + struct nop_usb_xceiv_platform_data *pdata)
> >> +{
> >> + struct device_node *node = dev->of_node;
> >> + u32 clk_rate;
> >> +
> >> + if (!of_property_read_u32(node, "clock-frequency", &clk_rate))
> >> + pdata->clk_rate = clk_rate;
> >> +}
> >> +
> >> static int nop_usb_xceiv_probe(struct platform_device *pdev)
> >> {
> >> + struct device *dev = &pdev->dev;
> >>struct nop_usb_xceiv_platform_data *pdata = pdev->dev.platform_data;
> >>struct nop_usb_xceiv*nop;
> >>enum usb_phy_type type = USB_PHY_TYPE_USB2;
> >> @@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device
> >> *pdev)
> >>if (!nop->phy.otg)
> >>return -ENOMEM;
> >>
> >> + if (dev->of_node) {
> >> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> >> + if (!pdata) {
> >> + dev_err(dev, "Memory allocation failure\n");
> >> + return -ENOMEM;
> >> + }
> >> + nop_xeiv_get_dt_pdata(dev, pdata);
> >
> > actually, I would prefer to not create pdata at all. I mean, ideally
> > pdata would be used to initialize fields in your own structure, so first
> > move clk_rate to your own private structure, copy pdata's clk_rate value
> > to that, then you don't need this hackery when using DT.
> >
> OK, got it. Will revise.
Cool, after that you can add my:
Acked-by: Felipe Balbi
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET
On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
> >> diff --git a/include/linux/usb/nop-usb-xceiv.h
> >> b/include/linux/usb/nop-usb-xceiv.h
> >> index 3265b61..148d351 100644
> >> --- a/include/linux/usb/nop-usb-xceiv.h
> >> +++ b/include/linux/usb/nop-usb-xceiv.h
> >> @@ -6,6 +6,10 @@
> >> struct nop_usb_xceiv_platform_data {
> >> enum usb_phy_type type;
> >> unsigned long clk_rate;
> >> +
> >> +/* if set fails with -EPROBE_DEFER if can't get regulator */
> >> +unsigned int needs_vcc:1;
> >> +unsigned int needs_reset:1;
> >
> > how about u8 here?
>
> Not sure. Bitfields are usually defined as unsigned int.
IIRC the benefit is that compiler can try to optimize those flags. I
mean, if you have 32 1-bit flags, compiler will combine those in a
single u32. Someone correct me if I'm wrong.
after you fix other comments from kishon (about of_read_bool()), you can
add my:
Acked-by: Felipe Balbi
--
balbi
signature.asc
Description: Digital signature
how to specify an OMAP clock in device tree?
Hi Rajendra,
On 02/04/2013 05:58 PM, Roger Quadros wrote:
> Provide the RESET and Power regulators for the USB PHY,
> the USB Host port mode and the PHY device.
>
> Also provide pin multiplexer information for the USB host
> pins.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap4-panda.dts | 55
> +
> 1 files changed, 55 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda.dts
> b/arch/arm/boot/dts/omap4-panda.dts
> index 4122efe..fe2d3d4 100644
> --- a/arch/arm/boot/dts/omap4-panda.dts
> +++ b/arch/arm/boot/dts/omap4-panda.dts
> @@ -57,6 +57,35 @@
> "AFML", "Line In",
> "AFMR", "Line In";
> };
> +
> + /* HS USB Port 1 RESET */
> + hsusb1_reset: hsusb1_reset_reg {
> + compatible = "regulator-fixed";
> + regulator-name = "hsusb1_reset";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpio2 30 0>; /* gpio_62 */
> + startup-delay-us = <7>;
> + enable-active-high;
> + };
> +
> + /* HS USB Port 1 Power */
> + hsusb1_power: hsusb1_power_reg {
> + compatible = "regulator-fixed";
> + regulator-name = "hsusb1_vbus";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpio1 1 0>;/* gpio_1 */
> + startup-delay-us = <7>;
> + enable-active-high;
> + };
> +
> + /* HS USB Host PHY on PORT 1 */
> + hsusb1_phy: hsusb1_phy {
> + compatible = "usb-nop-xceiv";
> + reset-supply = <&hsusb1_reset>;
> + vcc-supply = <&hsusb1_power>;
> + };
This is the patch I was discussing with you about before.
Let me explain the problem again.
The Pandaboard has a USB PHY whose reference clock is provided by
FREF_CLK3 pin which is a clock generated by the OMAP.
The PHY driver expects a reference to this clock in the PHY device node.
See the above node hsusb1_phy. we would need something like
hsusb1_phy {
...
clocks = <&fref_clk3>;
clock-names = "main_clk";
...
};
Currently on OMAP, there is no way to provide a phandle to this clock.
Is it practical to provide device tree based implementation of at least
the externally accessible OMAP clocks?
cheers,
-roger
> };
>
> &omap4_pmx_core {
> @@ -67,6 +96,7 @@
> &mcbsp1_pins
> &dss_hdmi_pins
> &tpd12s015_pins
> + &hsusbb1_pins
> >;
>
> twl6040_pins: pinmux_twl6040_pins {
> @@ -110,6 +140,23 @@
> 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
> MODE3 */
> >;
> };
--
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 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET
On 02/05/2013 11:09 AM, Felipe Balbi wrote:
> On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 3265b61..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -6,6 +6,10 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
unsigned long clk_rate;
+
+/* if set fails with -EPROBE_DEFER if can't get regulator */
+unsigned int needs_vcc:1;
+unsigned int needs_reset:1;
>>>
>>> how about u8 here?
>>
>> Not sure. Bitfields are usually defined as unsigned int.
>
> IIRC the benefit is that compiler can try to optimize those flags. I
> mean, if you have 32 1-bit flags, compiler will combine those in a
> single u32. Someone correct me if I'm wrong.
>
Yes you are right. Kishon was asking me to use u8 instead of unsigned int, which
I don't think is necessary. AFAIK, it is a norm to use unsigned int when
defining
a bitfield. Compilers are known to behave funny with bitfields. I don't mind
using bool for each.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
Hi Tony,
On 02/04/2013 08:52 PM, Tony Lindgren wrote:
> Looks like this now adds some new section warnings:
>
> WARNING: vmlinux.o(.text+0x34124): Section mismatch in reference from the
> function sdp3430_twl_gpio_setup() to the function
> .init.text:omap_twl4030_audio_init()
> The function sdp3430_twl_gpio_setup() references
> the function __init omap_twl4030_audio_init().
> This is often because sdp3430_twl_gpio_setup lacks a __init
> annotation or the annotation of omap_twl4030_audio_init is wrong.
>
> WARNING: vmlinux.o(.text+0x34b8c): Section mismatch in reference from the
> function zoom_twl_gpio_setup() to the function
> .init.text:omap_twl4030_audio_init()
> The function zoom_twl_gpio_setup() references
> the function __init omap_twl4030_audio_init().
> This is often because zoom_twl_gpio_setup lacks a __init
> annotation or the annotation of omap_twl4030_audio_init is wrong.
For some reason the CONFIG_DEBUG_SECTION_MISMATCH got disabled in my rolling
kernel config...
> These can be fixed with the following patch, but I suspect some
> of these cannot be __init/__initdata if the driver reprobes.
>
> Can you please check this? I'll hold on sendinf off
> this branch until it's been checked and fixed properly.
I think this is not the correct way. the *_twl_gpio_setup() is called from the
gpio-twl4030 driver's platform_driver probe function which if I'm not mistaken
is not __init.
I think we should remove the __init from the omap_twl4030_audio_init() in
twl-common.c
With this change I do not have section mismatch either.
--
Péter
>
> Regards,
>
> Tony
>
>
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -223,7 +223,7 @@ static struct omap_tw4030_pdata omap_twl4030_audio_data =
> {
> .has_linein = OMAP_TWL4030_LEFT | OMAP_TWL4030_RIGHT,
> };
>
> -static int sdp3430_twl_gpio_setup(struct device *dev,
> +static int __init sdp3430_twl_gpio_setup(struct device *dev,
> unsigned gpio, unsigned ngpio)
> {
> /* gpio + 0 is "mmc0_cd" (input/IRQ),
> @@ -245,7 +245,7 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
> return 0;
> }
>
> -static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
> +static struct twl4030_gpio_platform_data __initdata sdp3430_gpio_data = {
> .pulldowns = BIT(2) | BIT(6) | BIT(8) | BIT(13)
> | BIT(16) | BIT(17),
> .setup = sdp3430_twl_gpio_setup,
> @@ -374,7 +374,7 @@ static struct regulator_init_data sdp3430_vsim = {
> .consumer_supplies = sdp3430_vsim_supplies,
> };
>
> -static struct twl4030_platform_data sdp3430_twldata = {
> +static struct twl4030_platform_data __initdata sdp3430_twldata = {
> /* platform_data for children goes here */
> .gpio = &sdp3430_gpio_data,
> .keypad = &sdp3430_kp_data,
> --- a/arch/arm/mach-omap2/board-zoom-peripherals.c
> +++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
> @@ -238,7 +238,7 @@ static struct omap_tw4030_pdata omap_twl4030_audio_data =
> {
> .has_linein = OMAP_TWL4030_LEFT | OMAP_TWL4030_RIGHT,
> };
>
> -static int zoom_twl_gpio_setup(struct device *dev,
> +static int __init zoom_twl_gpio_setup(struct device *dev,
> unsigned gpio, unsigned ngpio)
> {
> /* gpio + 0 is "mmc0_cd" (input/IRQ) */
> @@ -252,11 +252,11 @@ static int zoom_twl_gpio_setup(struct device *dev,
> return 0;
> }
>
> -static struct twl4030_gpio_platform_data zoom_gpio_data = {
> +static struct twl4030_gpio_platform_data __initdata zoom_gpio_data = {
> .setup = zoom_twl_gpio_setup,
> };
>
> -static struct twl4030_platform_data zoom_twldata = {
> +static struct twl4030_platform_data __initdata zoom_twldata = {
> /* platform_data for children goes here */
> .gpio = &zoom_gpio_data,
> .keypad = &zoom_kp_twl4030_data,
>
--
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 4/6] ARM: dts: omap5: add dwc3 omap dt data
On Tue, Feb 05, 2013 at 02:37:05PM +0530, Santosh Shilimkar wrote:
> On Tuesday 05 February 2013 02:16 PM, kishon wrote:
> >Hi,
> >
> >On Tuesday 05 February 2013 02:08 PM, Felipe Balbi wrote:
> >>On Tue, Feb 05, 2013 at 01:59:26PM +0530, kishon wrote:
> >>>On Sunday 27 January 2013 01:17 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:
>
> >Add dwc3 omap glue data to the omap5 dt data file. The information
> >about
> >the dt node added here is available @
> >Documentation/devicetree/bindings/usb/omap-usb.txt
>
> >Signed-off-by: Kishon Vijay Abraham I
> >---
> > arch/arm/boot/dts/omap5.dtsi | 11 +++
> > 1 file changed, 11 insertions(+)
>
> >diff --git a/arch/arm/boot/dts/omap5.dtsi
> >b/arch/arm/boot/dts/omap5.dtsi
> >index 5f59bf2..1703a72 100644
> >--- a/arch/arm/boot/dts/omap5.dtsi
> >+++ b/arch/arm/boot/dts/omap5.dtsi
> >@@ -513,6 +513,17 @@
> > ti,type = <2>;
> > };
> >
> >+omap_dwc3@4a02 {
> >+compatible = "ti,dwc3";
> >+ti,hwmods = "usb_otg_ss";
> >+reg = <0x4a02 0x1ff>;
>
> Shoudn't the "reg" length be 0x200 here? It's length, not limit.
> >>>
> >>>I think 0x1ff is correct. I got the data from hwmod data.
> >>
> >>hwmod is utterly wrong. Looking at TRM, it says the size here is 64KiB
> >>(0x1), so is the size for dwc3 itself. Please don't blindly trust
> >>hwmod, make sure you read data from TRM ;-)
> >
> >hmm..ok. But it has only 17 registers :-D
> >
> As Felipe said, it should be 0x200. And if you are
> interested in lesser space, there is no need to map entire 64 KB
> address space if it isn't being used.
We get really close to using all of it. For DWC3, the last address is at
0xcc10 (a 32-bit register).
For dwc3-wrapper, then it's correct, we don't use it, I would still map
the whole thing to make it future proof.
Any draw-backs from mapping all 64K ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 09/13] mfd: omap-usb-host: Add device tree support and binding information
On 02/05/2013 08:16 AM, kishon wrote:
> On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
>> Allows the OMAP HS USB host controller to be specified
>> via device tree.
>>
>> CC: Samuel Ortiz
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/mfd/omap-usb-host.txt | 68
>> drivers/mfd/omap-usb-host.c| 83
>> ++--
>> 2 files changed, 145 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> new file mode 100644
>> index 000..2196893
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> @@ -0,0 +1,68 @@
>> +OMAP HS USB Host
>> +
>> +Required properties:
>> +
>> +- compatible: should be "ti,usbhs-host"
>> +- reg: should contain one register range i.e. start and length
>> +- ti,hwmods: must contain "usb_host_hs"
>> +
>> +Optional properties:
>> +
>> +- nports: number of USB ports. Usually this is automatically detected
>> + from the IP's revision register but can be overridden by specifying
>> + this property.
>> +
>> +- portN_mode: Integer specifying the port mode for port N, where N can be
>> + from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
>> + in include/linux/platform_data/usb-omap.h
>> + If the port mode is not specified, that port is treated as unused.
>> +
>> +- single_ulpi_bypass: Must be present if the controller contains a single
>> + ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
>> +
>> +Required properties if child node exists:
>> +
>> +- #address-cells: Must be 1
>> +- #size-cells: Must be 1
>> +- ranges: must be present
>> +
>> +Properties for children:
>> +
>> +The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
>> +See Documentation/devicetree/bindings/usb/omap-ehci.txt and
>> +omap3-ohci.txt
>> +
>> +Example for OMAP4:
>> +
>> +usbhshost: usbhshost@0x4a064000 {
>> +compatible = "ti,usbhs-host";
>> +reg = <0x4a064000 0x800>;
>> +ti,hwmods = "usb_host_hs";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +usbhsohci: ohci@0x4a064800 {
>> +compatible = "ti,omap3-ohci", "usb-ohci";
>> +reg = <0x4a064800 0x400>;
>> +interrupt-parent = <&gic>;
>> +interrupts = <0 76 0x4>;
>> +};
>> +
>> +usbhsehci: ehci@0x4a064c00 {
>> +compatible = "ti,omap-ehci", "usb-ehci";
>> +reg = <0x4a064c00 0x400>;
>> +interrupt-parent = <&gic>;
>> +interrupts = <0 77 0x4>;
>> +};
>> +};
>> +
>> +&usbhshost {
>> +port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
>> +port2_mode = <2>; /* OMAP_EHCI_PORT_MODE_TLL */
>> +port3_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
>> +};
>> +
>> +&usbhsehci {
>> +phy = <&hsusb1_phy 0 &hsusb3_phy>;
>> +};
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index f8ed08e..0f67856 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -1,8 +1,9 @@
>> /**
>>* omap-usb-host.c - The USBHS core driver for OMAP EHCI & OHCI
>>*
>> - * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
>> + * Copyright (C) 2011-2013 Texas Instruments Incorporated -
>> http://www.ti.com
>>* Author: Keshava Munegowda
>> + * Author: Roger Quadros
>>*
>>* This program is free software: you can redistribute it and/or modify
>>* it under the terms of the GNU General Public License version 2 of
>> @@ -27,6 +28,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include "omap-usb.h"
>>
>> @@ -464,6 +467,37 @@ static void omap_usbhs_init(struct device *dev)
>> pm_runtime_put_sync(dev);
>> }
>>
>> +static int usbhs_omap_get_dt_pdata(struct device_node *node,
>> +struct usbhs_omap_platform_data *pdata)
>> +{
>> +int ret, i;
>> +
>> +ret = of_property_read_u32(node, "nports", &pdata->nports);
>> +if (ret)
>> +pdata->nports = 0;
>> +
>> +/* get port modes */
>> +for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
>> +char prop[11];
>> +
>> +snprintf(prop, sizeof(prop), "port%d_mode", i + 1);
>> +ret = of_property_read_u32(node, prop, &pdata->port_mode[i]);
>> +if (ret)
>> +pdata->port_mode[i] = OMAP_USBHS_PORT_MODE_UNUSED;
>> +}
>> +
>> +/* get flags */
>> +pdata->single_ulpi_bypass = of_property_read_bool(node,
>> +"single_ulpi_bypass");
>> +return 0;
>> +}
>> +
>> +static struct of_device_id usbhs_child_match_table[] __initdata = {
>> +{ .compatible = "ti,omap-ehci", },
>> +{ .compatible = "ti,omap-ohci", },
>> +{ }
>> +};
>> +
>> /**
>>* usbhs_omap_probe - initialize TI-based HCDs
>>*
>> @@ -479,6 +513,21 @@ static int usbhs_omap_p
Re: how to specify an OMAP clock in device tree?
On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote:
Hi Rajendra,
On 02/04/2013 05:58 PM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda.dts | 55 +
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..fe2d3d4 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,35 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb1_reset";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio2 30 0>; /* gpio_62 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb1_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio1 1 0>; /* gpio_1 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ reset-supply = <&hsusb1_reset>;
+ vcc-supply = <&hsusb1_power>;
+ };
This is the patch I was discussing with you about before.
Let me explain the problem again.
The Pandaboard has a USB PHY whose reference clock is provided by
FREF_CLK3 pin which is a clock generated by the OMAP.
The PHY driver expects a reference to this clock in the PHY device node.
Well, the driver just does a clk_get(dev, "main_clk"); and clk_get() is
then able to either pick the reference from the PHY dt node or from a
clkdev entry.
The problem here seems to be that you are not able to add a clkdev entry
because the device name wouldn't be fixed, since you have a node in
the form of 'node: node {'. All other onchip OMAP devices don't have
this issue because they have an entry in the form of 'node: node@addr'
and hence have a fixed device name and hence can add a clkdev entry for
the clocks they want to control.
I don't know if there is any good way to define the DT node for the
on board PHY in such a way that the device name is always fixed, in
which case you can then add a clkdev entry for 'dev, main_clk' mapping
to the onchip clock that provides the clock, but if there is one, then
that should fix your problem.
See the above node hsusb1_phy. we would need something like
hsusb1_phy {
...
clocks = <&fref_clk3>;
clock-names = "main_clk";
...
};
Currently on OMAP, there is no way to provide a phandle to this clock.
Is it practical to provide device tree based implementation of at least
the externally accessible OMAP clocks?
cheers,
-roger
};
&omap4_pmx_core {
@@ -67,6 +96,7 @@
&mcbsp1_pins
&dss_hdmi_pins
&tpd12s015_pins
+ &hsusbb1_pins
>;
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +140,23 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] Device tree support for OMAP HS USB Host
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote: This patchset adds device tree support for OMAP's High Speed USB Host subsystem. Board adaptation for Panda and Beagleboard is also provided. Tested on Beagleboard. Will only work with Panda if we provide a reference to the PHY clock But there is no reference provided even for Beagle. Does it work because the default clk speed is 192Mhz? generator in the device tree in PATCH 11. I do not know how to do that as there is no way to provide a phandle to any of the OMAP generated clocks in the device tree. Suggestions welcome:). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] Device tree support for OMAP HS USB Host
On 02/05/2013 01:25 PM, Rajendra Nayak wrote: > On Monday 04 February 2013 09:28 PM, Roger Quadros wrote: >> This patchset adds device tree support for OMAP's High Speed USB Host >> subsystem. Board adaptation for Panda and Beagleboard is also provided. >> >> Tested on Beagleboard. >> >> Will only work with Panda if we provide a reference to the PHY clock > > But there is no reference provided even for Beagle. Does it work because > the default clk speed is 192Mhz? On beagle board the PHY is connected differently, i.e. as the clock receptor. The PHY clock comes directly from the USB_CLK pin. On Panda the PHY is the clock provider to the USB_CLK pin. For that it needs a reference clock at the REFCLK pin which comes from FREF_CLK3. > >> generator in the device tree in PATCH 11. I do not know how to do that >> as there is no way to provide a phandle to any of the OMAP generated clocks >> in the device tree. Suggestions welcome:). > cheers, -roger -- 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 09/13] mfd: omap-usb-host: Add device tree support and binding information
Hi,
On Tuesday 05 February 2013 04:28 PM, Roger Quadros wrote:
On 02/05/2013 08:16 AM, kishon wrote:
On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Allows the OMAP HS USB host controller to be specified
via device tree.
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 68
drivers/mfd/omap-usb-host.c| 83
++--
2 files changed, 145 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..2196893
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,68 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be "ti,usbhs-host"
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain "usb_host_hs"
+
+Optional properties:
+
+- nports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property.
+
+- portN_mode: Integer specifying the port mode for port N, where N can be
+ from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
+ in include/linux/platform_data/usb-omap.h
+ If the port mode is not specified, that port is treated as unused.
+
+- single_ulpi_bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@0x4a064000 {
+compatible = "ti,usbhs-host";
+reg = <0x4a064000 0x800>;
+ti,hwmods = "usb_host_hs";
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+usbhsohci: ohci@0x4a064800 {
+compatible = "ti,omap3-ohci", "usb-ohci";
+reg = <0x4a064800 0x400>;
+interrupt-parent = <&gic>;
+interrupts = <0 76 0x4>;
+};
+
+usbhsehci: ehci@0x4a064c00 {
+compatible = "ti,omap-ehci", "usb-ehci";
+reg = <0x4a064c00 0x400>;
+interrupt-parent = <&gic>;
+interrupts = <0 77 0x4>;
+};
+};
+
+&usbhshost {
+port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
+port2_mode = <2>; /* OMAP_EHCI_PORT_MODE_TLL */
+port3_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
+};
+
+&usbhsehci {
+phy = <&hsusb1_phy 0 &hsusb3_phy>;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index f8ed08e..0f67856 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
/**
* omap-usb-host.c - The USBHS core driver for OMAP EHCI & OHCI
*
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
* Author: Keshava Munegowda
+ * Author: Roger Quadros
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 of
@@ -27,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include "omap-usb.h"
@@ -464,6 +467,37 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_put_sync(dev);
}
+static int usbhs_omap_get_dt_pdata(struct device_node *node,
+struct usbhs_omap_platform_data *pdata)
+{
+int ret, i;
+
+ret = of_property_read_u32(node, "nports", &pdata->nports);
+if (ret)
+pdata->nports = 0;
+
+/* get port modes */
+for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
+char prop[11];
+
+snprintf(prop, sizeof(prop), "port%d_mode", i + 1);
+ret = of_property_read_u32(node, prop, &pdata->port_mode[i]);
+if (ret)
+pdata->port_mode[i] = OMAP_USBHS_PORT_MODE_UNUSED;
+}
+
+/* get flags */
+pdata->single_ulpi_bypass = of_property_read_bool(node,
+"single_ulpi_bypass");
+return 0;
+}
+
+static struct of_device_id usbhs_child_match_table[] __initdata = {
+{ .compatible = "ti,omap-ehci", },
+{ .compatible = "ti,omap-ohci", },
+{ }
+};
+
/**
* usbhs_omap_probe - initialize TI-based HCDs
*
@@ -479,6 +513,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
inti;
boolneed_logic_fck;
+if (dev->of_node) {
+/* For DT boot we populate platform data from OF node */
+pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+if (!pdata)
+return -ENOMEM;
+
+if (usbhs_omap_get_dt_pdata(dev->of_nod
Re: [PATCH 09/13] mfd: omap-usb-host: Add device tree support and binding information
On 02/05/2013 02:11 PM, kishon wrote:
> Hi,
>
> On Tuesday 05 February 2013 04:28 PM, Roger Quadros wrote:
>> On 02/05/2013 08:16 AM, kishon wrote:
>>> On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:
Allows the OMAP HS USB host controller to be specified
via device tree.
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 68
drivers/mfd/omap-usb-host.c| 83
++--
2 files changed, 145 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mfd/omap-usb-host.txt
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..2196893
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,68 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be "ti,usbhs-host"
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain "usb_host_hs"
+
+Optional properties:
+
+- nports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property.
+
+- portN_mode: Integer specifying the port mode for port N, where N can be
+ from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
+ in include/linux/platform_data/usb-omap.h
+ If the port mode is not specified, that port is treated as unused.
+
+- single_ulpi_bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@0x4a064000 {
+compatible = "ti,usbhs-host";
+reg = <0x4a064000 0x800>;
+ti,hwmods = "usb_host_hs";
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+usbhsohci: ohci@0x4a064800 {
+compatible = "ti,omap3-ohci", "usb-ohci";
+reg = <0x4a064800 0x400>;
+interrupt-parent = <&gic>;
+interrupts = <0 76 0x4>;
+};
+
+usbhsehci: ehci@0x4a064c00 {
+compatible = "ti,omap-ehci", "usb-ehci";
+reg = <0x4a064c00 0x400>;
+interrupt-parent = <&gic>;
+interrupts = <0 77 0x4>;
+};
+};
+
+&usbhshost {
+port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
+port2_mode = <2>; /* OMAP_EHCI_PORT_MODE_TLL */
+port3_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
+};
+
+&usbhsehci {
+phy = <&hsusb1_phy 0 &hsusb3_phy>;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index f8ed08e..0f67856 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
/**
* omap-usb-host.c - The USBHS core driver for OMAP EHCI & OHCI
*
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated -
http://www.ti.com
* Author: Keshava Munegowda
+ * Author: Roger Quadros
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 of
@@ -27,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include "omap-usb.h"
@@ -464,6 +467,37 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_put_sync(dev);
}
+static int usbhs_omap_get_dt_pdata(struct device_node *node,
+struct usbhs_omap_platform_data *pdata)
+{
+int ret, i;
+
+ret = of_property_read_u32(node, "nports", &pdata->nports);
+if (ret)
+pdata->nports = 0;
+
+/* get port modes */
+for (i = 0; i < OMAP3_HS_USB_PORTS; i++) {
+char prop[11];
+
+snprintf(prop, sizeof(prop), "port%d_mode", i + 1);
+ret = of_property_read_u32(node, prop, &pdata->port_mode[i]);
+if (ret)
+pdata->port_mode[i] = OMAP_USBHS_PORT_MODE_UNUSED;
+}
+
+/* get flags */
+pdata->single_ulpi
Re: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
On Mon, Feb 04, 2013 at 11:52:51AM -0800, Tony Lindgren wrote:
> @@ -245,7 +245,7 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
> return 0;
> }
>
> -static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
> +static struct twl4030_gpio_platform_data __initdata sdp3430_gpio_data = {
> .pulldowns = BIT(2) | BIT(6) | BIT(8) | BIT(13)
> | BIT(16) | BIT(17),
> .setup = sdp3430_twl_gpio_setup,
Seeing platform data marked with __initdata makes me extremely nervous.
Are you _absolutely_ _sure_ that this data either:
(a) gets copied before use, or
(b) is not used after kernel init
?
Normally, platform data is passed via a pointer in struct device to
drivers, and drivers either store a pointer to it, or if the driver is
unbound/rebound, they can access it well after init time.
Certainly marking a function pointed to by platform data as __init looks
very very wrong.
--
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 08/13] USB: ehci-omap: Add device tree support and binding information
On Mon, Feb 04, 2013 at 03:58:55PM +, Roger Quadros wrote: > Allows the OMAP EHCI controller to be specified via device tree. > > Signed-off-by: Roger Quadros > --- > .../devicetree/bindings/usb/omap-ehci.txt | 34 ++ > drivers/usb/host/ehci-omap.c | 36 > +++- > 2 files changed, 69 insertions(+), 1 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/omap-ehci.txt > > diff --git a/Documentation/devicetree/bindings/usb/omap-ehci.txt > b/Documentation/devicetree/bindings/usb/omap-ehci.txt > new file mode 100644 > index 000..90e6e3a > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/omap-ehci.txt > @@ -0,0 +1,34 @@ > +OMAP HS USB EHCI controller > + > +This device is usually the child of the omap-usb-host > +Documentation/devicetree/bindings/mfd/omap-usb-host.txt > + > +Required properties: > + > +- compatible: should be "ti,omap-ehci" > +- reg: should contain one register range i.e. start and length > +- interrupt-parent: phandle to the interrupt controller > +- interrupts: description of the interrupt line > + > +Optional properties: > + > +- phy: list of phandles to PHY nodes. > + This property is required if at least one of the ports are in > + PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY Any reason for not calling this "phys", given it's a list? [...] 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: DSS errors in linux next when booted with DTB append
Hi, On 2013-01-16 21:08, Tony Lindgren wrote: > Hi Tomi, > > Looks like omap_dss_init() goes crazy on panda es when booted with > PANEL_TAAL and DTB append enabled, see below. Does not seem to happen when > booted on blaze. Noticed this after enabling all the panels, my modified > omap2plus_defconfig attached. Hmm, looks odd. The log shows it's trying to use Taal panel, even if Panda doesn't have such a panel. Who's adding the Taal device? Are you booting Panda with Blaze's dtb? That said, I have seen similar circular locking warnings related to omapfb/omapdss, but I haven't been able to resolve them, or even to really find out why the warning happens. I haven't seen any problems though, it's just a warning. So my guess is that you're seeing two unrelated problems, one related to dtbs or such, and the other related to locks. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote: > On Monday 04 February 2013, Linus Walleij wrote: > > So I think the above concerns are moot. The callback we can > > set on cookies is entirely optional, and it's even implemented by > > each DMA engine, and some may not even support it but require > > polling, and then it won't even be implemented by the driver. > > Just to ensure that everybody is talking about the same thing here: > Is it just the callback that is optional, or also the interrupt > coming from the hardware? If everyone implements stuff correctly, both. The callback most certainly is optional as things stand. The interrupt - that depends on the DMA engine. Some DMA engines you can't avoid it because you need to reprogram the hardware with the next+1 transfer upon completion of an existing transfer. Others may allow you to chain transfers in hardware. That's all up to how the DMA engine driver is implemented and how the hardware behaves. Now, there's another problem here: that is, people abuse the API. People don't pass DMA_CTRL_ACK | DMA_PREP_INTERRUPT into their operations by default. People like typing '0'. The intention of the "DMA_PREP_INTERRUPT" is significant here: it means "ask the hardware to send an interrupt upon completion of this transfer". Because soo many people like to type '0' instead in their DMA engine clients, it means that this flag is utterly useless today - you have to ignore it. So there's _no_ way for client drivers to actually tell the a DMA engine driver which _doesn't_ need to signal interrupts at the end of every transfer not to do so. So yes, the DMA engine API supports it. Whether the _implementations_ themselves do is very much hit and miss (and in reality is much more miss than hit.) -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote: > You're assuming that cookies complete in order. That is not necessarily > true. Under what circumstances is that not true? -- 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 08/13] USB: ehci-omap: Add device tree support and binding information
On 02/05/2013 02:33 PM, Mark Rutland wrote: > On Mon, Feb 04, 2013 at 03:58:55PM +, Roger Quadros wrote: >> Allows the OMAP EHCI controller to be specified via device tree. >> >> Signed-off-by: Roger Quadros >> --- >> .../devicetree/bindings/usb/omap-ehci.txt | 34 ++ >> drivers/usb/host/ehci-omap.c | 36 >> +++- >> 2 files changed, 69 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/usb/omap-ehci.txt >> >> diff --git a/Documentation/devicetree/bindings/usb/omap-ehci.txt >> b/Documentation/devicetree/bindings/usb/omap-ehci.txt >> new file mode 100644 >> index 000..90e6e3a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/usb/omap-ehci.txt >> @@ -0,0 +1,34 @@ >> +OMAP HS USB EHCI controller >> + >> +This device is usually the child of the omap-usb-host >> +Documentation/devicetree/bindings/mfd/omap-usb-host.txt >> + >> +Required properties: >> + >> +- compatible: should be "ti,omap-ehci" >> +- reg: should contain one register range i.e. start and length >> +- interrupt-parent: phandle to the interrupt controller >> +- interrupts: description of the interrupt line >> + >> +Optional properties: >> + >> +- phy: list of phandles to PHY nodes. >> + This property is required if at least one of the ports are in >> + PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY > > Any reason for not calling this "phys", given it's a list? > No good reason. "phys" seems more appropriate. Thanks. cheers, -roger -- 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: USB related clk warnings on 3.8-rc6
On 02/05/2013 02:57 PM, Tomi Valkeinen wrote: > Hi, > > I'm seeing clk warnings related to USB with both Panda and Overo, on > 3.8-rc6. For example: > > [0.801055] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed > error:-38 > [0.801513] [ cut here ] > [0.801574] WARNING: at drivers/clk/clk.c:522 __clk_enable+0x94/0xa4() > > I've attached logs for both Panda and Overo, and my kernel config. > > The USB seems to work ok, though, at least on Overo (I use NFS root over > USB on that one). > Thanks Tomi, I'm aware of the issue and it should be fixed on linux-next. regards, -roger -- 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 RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.
Now that machines may select the mode of working of DWC3,
we can set the Port capability direction based on selected mode.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/core.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 177f4c6..f4c47f7 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -479,7 +479,6 @@ static int dwc3_probe(struct platform_device *pdev)
switch (mode) {
case DWC3_MODE_DEVICE:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize gadget\n");
@@ -487,7 +486,6 @@ static int dwc3_probe(struct platform_device *pdev)
}
break;
case DWC3_MODE_HOST:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
ret = dwc3_host_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize host\n");
@@ -495,7 +493,6 @@ static int dwc3_probe(struct platform_device *pdev)
}
break;
case DWC3_MODE_DRD:
- dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
ret = dwc3_host_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize host\n");
@@ -514,6 +511,14 @@ static int dwc3_probe(struct platform_device *pdev)
}
dwc->mode = mode;
+#if IS_ENABLED(CONFIG_USB_DWC3_HOST)
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+#else
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+#endif
+
ret = dwc3_debugfs_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize debugfs\n");
--
1.7.6.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: how to specify an OMAP clock in device tree?
On 02/05/2013 01:15 PM, Rajendra Nayak wrote:
> On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote:
>> Hi Rajendra,
>>
>> On 02/04/2013 05:58 PM, Roger Quadros wrote:
>>> Provide the RESET and Power regulators for the USB PHY,
>>> the USB Host port mode and the PHY device.
>>>
>>> Also provide pin multiplexer information for the USB host
>>> pins.
>>>
>>> Signed-off-by: Roger Quadros
>>> ---
>>> arch/arm/boot/dts/omap4-panda.dts | 55
>>> +
>>> 1 files changed, 55 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-panda.dts
>>> b/arch/arm/boot/dts/omap4-panda.dts
>>> index 4122efe..fe2d3d4 100644
>>> --- a/arch/arm/boot/dts/omap4-panda.dts
>>> +++ b/arch/arm/boot/dts/omap4-panda.dts
>>> @@ -57,6 +57,35 @@
>>> "AFML", "Line In",
>>> "AFMR", "Line In";
>>> };
>>> +
>>> +/* HS USB Port 1 RESET */
>>> +hsusb1_reset: hsusb1_reset_reg {
>>> +compatible = "regulator-fixed";
>>> +regulator-name = "hsusb1_reset";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +gpio = <&gpio2 30 0>;/* gpio_62 */
>>> +startup-delay-us = <7>;
>>> +enable-active-high;
>>> +};
>>> +
>>> +/* HS USB Port 1 Power */
>>> +hsusb1_power: hsusb1_power_reg {
>>> +compatible = "regulator-fixed";
>>> +regulator-name = "hsusb1_vbus";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +gpio = <&gpio1 1 0>;/* gpio_1 */
>>> +startup-delay-us = <7>;
>>> +enable-active-high;
>>> +};
>>> +
>>> +/* HS USB Host PHY on PORT 1 */
>>> +hsusb1_phy: hsusb1_phy {
>>> +compatible = "usb-nop-xceiv";
>>> +reset-supply = <&hsusb1_reset>;
>>> +vcc-supply = <&hsusb1_power>;
>>> +};
>>
>> This is the patch I was discussing with you about before.
>>
>> Let me explain the problem again.
>>
>> The Pandaboard has a USB PHY whose reference clock is provided by
>> FREF_CLK3 pin which is a clock generated by the OMAP.
>> The PHY driver expects a reference to this clock in the PHY device node.
>
> Well, the driver just does a clk_get(dev, "main_clk"); and clk_get() is
> then able to either pick the reference from the PHY dt node or from a
> clkdev entry.
>
> The problem here seems to be that you are not able to add a clkdev entry
> because the device name wouldn't be fixed, since you have a node in
> the form of 'node: node {'. All other onchip OMAP devices don't have
> this issue because they have an entry in the form of 'node: node@addr'
> and hence have a fixed device name and hence can add a clkdev entry for
> the clocks they want to control.
>
> I don't know if there is any good way to define the DT node for the
> on board PHY in such a way that the device name is always fixed, in
> which case you can then add a clkdev entry for 'dev, main_clk' mapping
> to the onchip clock that provides the clock, but if there is one, then
> that should fix your problem.
Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.
So you can't provide this information in some common clock data file.
The data has to come from a board specific location, which in the DT boot
case is the board's dts file.
I think all we need to do is register a clock provider using
of_clk_add_provider()
and provide a clk_src_get() hook that can get the right clock.
usage e.g.
/* provider */
clks: omapclocks {
compatible = "ti,omapclocks";
#clock-cells = <1>;
};
/* consumer */
hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
clocks = <&clks "auxclk3_ck">; /* FREF_CLK3 */
clock-names = "main-clk";
};
The only problem I see is that the argument to the clks phandle
cannot be a string. It needs to be u32.
In that case we need to map all clocks into a u32 index.
If we can do that only for auxclks, my problem is solved for panda.
The usage e.g then changes to
/* provider */
aux_clks: omap_aux_clocks {
compatible = "ti,omap_aux_clocks";
#clock-cells = <1>;
};
/* consumer */
hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
clocks = <&aux_clks 3>; /* FREF_CLK3 */
clock-names = "main-clk";
};
Does this idea sound reasonable?
regards,
-roger
--
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: how to specify an OMAP clock in device tree?
On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: Fixing the device name doesn't really solve the problem. Not all OMAP boards will use the same clock for the external device. Are you saying different OMAP boards will use different Internal clocks? Or different OMAP boards will use a single Internal clock or an external one. -- 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: how to specify an OMAP clock in device tree?
On 02/05/2013 04:13 PM, Rajendra Nayak wrote: > On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: >> Fixing the device name doesn't really solve the problem. >> Not all OMAP boards will use the same clock for the external device. > > Are you saying different OMAP boards will use different Internal clocks? > Or different OMAP boards will use a single Internal clock or an > external one. > All I was saying is that one board can use for example auxclk1 whereas another one can use auxclk3, both generated by OMAP for the same PHY configuration. cheers, -roger -- 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 09/13] mfd: omap-usb-host: Add device tree support and binding information
Hi,
I have a few comments on the binding and the way it's parsed.
On Mon, Feb 04, 2013 at 03:58:56PM +, Roger Quadros wrote:
> Allows the OMAP HS USB host controller to be specified
> via device tree.
>
> CC: Samuel Ortiz
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/mfd/omap-usb-host.txt | 68
> drivers/mfd/omap-usb-host.c| 83
> ++--
> 2 files changed, 145 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> new file mode 100644
> index 000..2196893
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> @@ -0,0 +1,68 @@
> +OMAP HS USB Host
> +
> +Required properties:
> +
> +- compatible: should be "ti,usbhs-host"
> +- reg: should contain one register range i.e. start and length
> +- ti,hwmods: must contain "usb_host_hs"
> +
> +Optional properties:
> +
> +- nports: number of USB ports. Usually this is automatically detected
> + from the IP's revision register but can be overridden by specifying
> + this property.
It would be nice if this were "num-ports", as atmel-usb is already using that,
and it's clear that it's a number of ports rather than some other meaning of
'n'.
>From a quick grep of binding documents, out of "nTHING(s)", "nr-THINGs", and
num-THINGs, num-THINGs seems to be the most common. It would be nice if new
bindings could standardise this.
> +
> +- portN_mode: Integer specifying the port mode for port N, where N can be
> + from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
> + in include/linux/platform_data/usb-omap.h
> + If the port mode is not specified, that port is treated as unused.
I'm against devicetree bindings refering to Linux internals. It makes a poorly
documented ABI that someone might change in future without realising the
implications, and it makes it stupidly difficult to read a dts.
Everything required should be specified in the binding document (or another
linked binding document). It might be better to describe this with a string
property that gets mapped by your dt parsing code to whatever internal
representation you need. That way it's far easier for a human to verify the dts
is correct, and you know by construction that the parsed value is something you
can handle in the driver.
It would be nicer is you used '-' rather than '_' for consistency with
devicetree bindings in general.
> +
> +- single_ulpi_bypass: Must be present if the controller contains a single
> + ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
Again it would be nicer to have '-' rather than '_' here. It might be worth
prefixing this "ti,".
> +
> +Required properties if child node exists:
> +
> +- #address-cells: Must be 1
> +- #size-cells: Must be 1
> +- ranges: must be present
> +
> +Properties for children:
> +
> +The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
> +See Documentation/devicetree/bindings/usb/omap-ehci.txt and
> +omap3-ohci.txt
> +
> +Example for OMAP4:
> +
> +usbhshost: usbhshost@0x4a064000 {
> + compatible = "ti,usbhs-host";
> + reg = <0x4a064000 0x800>;
> + ti,hwmods = "usb_host_hs";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usbhsohci: ohci@0x4a064800 {
> + compatible = "ti,omap3-ohci", "usb-ohci";
> + reg = <0x4a064800 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 76 0x4>;
> + };
> +
> + usbhsehci: ehci@0x4a064c00 {
> + compatible = "ti,omap-ehci", "usb-ehci";
> + reg = <0x4a064c00 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 77 0x4>;
> + };
> +};
> +
> +&usbhshost {
> + port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
> + port2_mode = <2>; /* OMAP_EHCI_PORT_MODE_TLL */
> + port3_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
With a string property, these values would be self-documenting.
> +};
> +
> +&usbhsehci {
> + phy = <&hsusb1_phy 0 &hsusb3_phy>;
> +};
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index f8ed08e..0f67856 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -1,8 +1,9 @@
> /**
> * omap-usb-host.c - The USBHS core driver for OMAP EHCI & OHCI
> *
> - * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
> + * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
> * Author: Keshava Munegowda
> + * Author: Roger Quadros
> *
> * This program is free software: you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 of
> @@ -27,6 +28,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "omap-usb.h"
>
> @@
Re: how to specify an OMAP clock in device tree?
On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote: On 02/05/2013 04:13 PM, Rajendra Nayak wrote: On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: Fixing the device name doesn't really solve the problem. Not all OMAP boards will use the same clock for the external device. Are you saying different OMAP boards will use different Internal clocks? Or different OMAP boards will use a single Internal clock or an external one. All I was saying is that one board can use for example auxclk1 whereas another one can use auxclk3, both generated by OMAP for the same PHY configuration. Ok, so lets keep DT aside for a while. How would something like this work in a non-DT world? Would the driver then be able to do a clk_get(dev, "main_clk"); and get say auxclk1 on one board and auxclk3 on another? cheers, -roger -- 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
Latest additional build warnings
arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type or storage class arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in declaration of 'omap_postcore_initcall' arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without types) in function declaration arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' defined but not used -- 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: how to specify an OMAP clock in device tree?
On 02/05/2013 04:21 PM, Rajendra Nayak wrote:
> On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:
>> On 02/05/2013 04:13 PM, Rajendra Nayak wrote:
>>> On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:
Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.
>>>
>>> Are you saying different OMAP boards will use different Internal clocks?
>>> Or different OMAP boards will use a single Internal clock or an
>>> external one.
>>>
>> All I was saying is that one board can use for example auxclk1 whereas
>> another
>> one can use auxclk3, both generated by OMAP for the same PHY configuration.
>
> Ok, so lets keep DT aside for a while. How would something like this
> work in a non-DT world? Would the driver then be able to do a
> clk_get(dev, "main_clk"); and get say auxclk1 on one board and
> auxclk3 on another?
>
Yes, all you need to do is specify an alias to the clock in the board file.
e.g. in board 1 file
clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL);
in board 2 file
clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL);
cheers,
-roger
--
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: how to specify an OMAP clock in device tree?
On Tuesday 05 February 2013 07:59 PM, Roger Quadros wrote:
On 02/05/2013 04:21 PM, Rajendra Nayak wrote:
On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:
On 02/05/2013 04:13 PM, Rajendra Nayak wrote:
On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:
Fixing the device name doesn't really solve the problem.
Not all OMAP boards will use the same clock for the external device.
Are you saying different OMAP boards will use different Internal clocks?
Or different OMAP boards will use a single Internal clock or an
external one.
All I was saying is that one board can use for example auxclk1 whereas another
one can use auxclk3, both generated by OMAP for the same PHY configuration.
Ok, so lets keep DT aside for a while. How would something like this
work in a non-DT world? Would the driver then be able to do a
clk_get(dev, "main_clk"); and get say auxclk1 on one board and
auxclk3 on another?
Yes, all you need to do is specify an alias to the clock in the board file.
Can we then create a special board specific node for panda and do
similar things from DT?
See a similar discussion below on how to handle the gpio_request()
we had as part of board files
http://www.spinics.net/lists/linux-omap/msg85248.html
e.g. in board 1 file
clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL);
in board 2 file
clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL);
cheers,
-roger
--
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 09/13] mfd: omap-usb-host: Add device tree support and binding information
On 02/05/2013 04:20 PM, Mark Rutland wrote:
> Hi,
>
> I have a few comments on the binding and the way it's parsed.
>
> On Mon, Feb 04, 2013 at 03:58:56PM +, Roger Quadros wrote:
>> Allows the OMAP HS USB host controller to be specified
>> via device tree.
>>
>> CC: Samuel Ortiz
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/mfd/omap-usb-host.txt | 68
>> drivers/mfd/omap-usb-host.c| 83
>> ++--
>> 2 files changed, 145 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> new file mode 100644
>> index 000..2196893
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
>> @@ -0,0 +1,68 @@
>> +OMAP HS USB Host
>> +
>> +Required properties:
>> +
>> +- compatible: should be "ti,usbhs-host"
>> +- reg: should contain one register range i.e. start and length
>> +- ti,hwmods: must contain "usb_host_hs"
>> +
>> +Optional properties:
>> +
>> +- nports: number of USB ports. Usually this is automatically detected
>> + from the IP's revision register but can be overridden by specifying
>> + this property.
>
> It would be nice if this were "num-ports", as atmel-usb is already using that,
> and it's clear that it's a number of ports rather than some other meaning of
> 'n'.
>
> From a quick grep of binding documents, out of "nTHING(s)", "nr-THINGs", and
> num-THINGs, num-THINGs seems to be the most common. It would be nice if new
> bindings could standardise this.
Agreed.
>
>> +
>> +- portN_mode: Integer specifying the port mode for port N, where N can be
>> + from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
>> + in include/linux/platform_data/usb-omap.h
>> + If the port mode is not specified, that port is treated as unused.
>
> I'm against devicetree bindings refering to Linux internals. It makes a poorly
> documented ABI that someone might change in future without realising the
> implications, and it makes it stupidly difficult to read a dts.
>
> Everything required should be specified in the binding document (or another
> linked binding document). It might be better to describe this with a string
> property that gets mapped by your dt parsing code to whatever internal
> representation you need. That way it's far easier for a human to verify the
> dts
> is correct, and you know by construction that the parsed value is something
> you
> can handle in the driver.
As string makes it self documenting, I'll convert it to a string and update the
binding document.
>
> It would be nicer is you used '-' rather than '_' for consistency with
> devicetree bindings in general.
OK.
>
>> +
>> +- single_ulpi_bypass: Must be present if the controller contains a single
>> + ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
>
> Again it would be nicer to have '-' rather than '_' here. It might be worth
> prefixing this "ti,".
Is prefixing with "ti" really required? how does it better?
>
>> +
>> +Required properties if child node exists:
>> +
>> +- #address-cells: Must be 1
>> +- #size-cells: Must be 1
>> +- ranges: must be present
>> +
>> +Properties for children:
>> +
>> +The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
>> +See Documentation/devicetree/bindings/usb/omap-ehci.txt and
>> +omap3-ohci.txt
>> +
>> +Example for OMAP4:
>> +
>> +usbhshost: usbhshost@0x4a064000 {
>> +compatible = "ti,usbhs-host";
>> +reg = <0x4a064000 0x800>;
>> +ti,hwmods = "usb_host_hs";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +usbhsohci: ohci@0x4a064800 {
>> +compatible = "ti,omap3-ohci", "usb-ohci";
>> +reg = <0x4a064800 0x400>;
>> +interrupt-parent = <&gic>;
>> +interrupts = <0 76 0x4>;
>> +};
>> +
>> +usbhsehci: ehci@0x4a064c00 {
>> +compatible = "ti,omap-ehci", "usb-ehci";
>> +reg = <0x4a064c00 0x400>;
>> +interrupt-parent = <&gic>;
>> +interrupts = <0 77 0x4>;
>> +};
>> +};
>> +
>> +&usbhshost {
>> +port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
>> +port2_mode = <2>; /* OMAP_EHCI_PORT_MODE_TLL */
>> +port3_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */
>
> With a string property, these values would be self-documenting.
>
>> +};
>> +
>> +&usbhsehci {
>> +phy = <&hsusb1_phy 0 &hsusb3_phy>;
>> +};
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index f8ed08e..0f67856 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -1,8 +1,9 @@
>> /**
>> * omap-usb-host.c - The USBHS core driver for OMAP EHCI & OHCI
>> *
>> - * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
>> + * Copyright (C) 2011-2013 Texas Instruments I
Re: how to specify an OMAP clock in device tree?
On 02/05/2013 04:36 PM, Rajendra Nayak wrote:
> On Tuesday 05 February 2013 07:59 PM, Roger Quadros wrote:
>> On 02/05/2013 04:21 PM, Rajendra Nayak wrote:
>>> On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote:
On 02/05/2013 04:13 PM, Rajendra Nayak wrote:
> On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote:
>> Fixing the device name doesn't really solve the problem.
>> Not all OMAP boards will use the same clock for the external device.
>
> Are you saying different OMAP boards will use different Internal clocks?
> Or different OMAP boards will use a single Internal clock or an
> external one.
>
All I was saying is that one board can use for example auxclk1 whereas
another
one can use auxclk3, both generated by OMAP for the same PHY configuration.
>>>
>>> Ok, so lets keep DT aside for a while. How would something like this
>>> work in a non-DT world? Would the driver then be able to do a
>>> clk_get(dev, "main_clk"); and get say auxclk1 on one board and
>>> auxclk3 on another?
>>>
>>
>> Yes, all you need to do is specify an alias to the clock in the board file.
>
> Can we then create a special board specific node for panda and do
> similar things from DT?
> See a similar discussion below on how to handle the gpio_request()
> we had as part of board files
> http://www.spinics.net/lists/linux-omap/msg85248.html
Doesn't look very elegant to me, but I wouldn't mind if there is no better
option.
Even then, we can't rely on the device name as its index can change based on
where it is
located in the dts file. e.g. in the beginning it may be named phy.8, and if a
device
node is added before it, it will get changed to phy.9
>
>>
>> e.g. in board 1 file
>> clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL);
>>
>> in board 2 file
>> clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL);
>>
cheers,
-roger
--
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
[GIT PULL] ARM part of USB patches
Hi Tony, As discussed, I'm sending a pull request for the arch/arm part of my USB patches. These patches are necessary to get MUSB functional in both dt and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch series *depends* on some of the patches which are merged in usb-next. Thanks Kishon The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://gitorious.org/linux-usb/linux-usb.git arm-usb-dt for you to fetch changes up to 09084a48903c6056e20e27ae5054902958a10275: ARM: dts: omap5: add dwc3 core dt data (2013-02-05 20:11:46 +0530) Kishon Vijay Abraham I (12): ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: OMAP: USB: Add phy binding information ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap dt data ARM: dts: omap5: add dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++ arch/arm/boot/dts/omap3-evm.dts|6 ++ arch/arm/boot/dts/omap3-overo.dtsi |6 ++ arch/arm/boot/dts/omap3.dtsi | 12 arch/arm/boot/dts/omap4-panda.dts |6 ++ arch/arm/boot/dts/omap4-sdp.dts|6 ++ arch/arm/boot/dts/omap4.dtsi | 26 ++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- arch/arm/mach-omap2/board-2430sdp.c|2 ++ arch/arm/mach-omap2/board-3430sdp.c|2 ++ arch/arm/mach-omap2/board-4430sdp.c|2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c|2 ++ arch/arm/mach-omap2/board-omap3beagle.c|2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c |2 ++ arch/arm/mach-omap2/board-rm680.c |2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ arch/arm/mach-omap2/devices.c | 45 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 - arch/arm/mach-omap2/usb-musb.c |3 +++ include/linux/usb/musb.h |2 ++ 31 files changed, 202 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM part of USB patches
Hi Tony, Greg, On Tuesday 05 February 2013 08:54 PM, kishon wrote: Hi Tony, As discussed, I'm sending a pull request for the arch/arm part of my USB patches. These patches are necessary to get MUSB functional in both dt and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch series *depends* on some of the patches which are merged in usb-next. This patch series should go in only after USB. Or else it will break compilation. Thanks Kishon Thanks Kishon The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://gitorious.org/linux-usb/linux-usb.git arm-usb-dt for you to fetch changes up to 09084a48903c6056e20e27ae5054902958a10275: ARM: dts: omap5: add dwc3 core dt data (2013-02-05 20:11:46 +0530) Kishon Vijay Abraham I (12): ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: dts: omap: Add omap control usb data ARM: dts: omap: Add omap-usb2 dt data ARM: dts: omap: Add usb_otg and glue data ARM: OMAP: USB: Add phy binding information ARM: dts: omap5: Add omap control usb data ARM: dts: omap5: Add ocp2scp data ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data ARM: dts: omap5: add dwc3 omap dt data ARM: dts: omap5: add dwc3 core dt data Documentation/devicetree/bindings/usb/omap-usb.txt |1 + arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++ arch/arm/boot/dts/omap3-evm.dts|6 ++ arch/arm/boot/dts/omap3-overo.dtsi |6 ++ arch/arm/boot/dts/omap3.dtsi | 12 arch/arm/boot/dts/omap4-panda.dts |6 ++ arch/arm/boot/dts/omap4-sdp.dts|6 ++ arch/arm/boot/dts/omap4.dtsi | 26 ++ arch/arm/boot/dts/omap5.dtsi | 48 arch/arm/boot/dts/twl4030.dtsi |2 +- arch/arm/mach-omap2/board-2430sdp.c|2 ++ arch/arm/mach-omap2/board-3430sdp.c|2 ++ arch/arm/mach-omap2/board-4430sdp.c|2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c|2 ++ arch/arm/mach-omap2/board-omap3beagle.c|2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c |2 ++ arch/arm/mach-omap2/board-rm680.c |2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ arch/arm/mach-omap2/devices.c | 45 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 - arch/arm/mach-omap2/usb-musb.c |3 +++ include/linux/usb/musb.h |2 ++ 31 files changed, 202 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote: > On 02/04/2013 04:11 PM, Linus Walleij wrote: >> Cyril, just stack up the cookies and take a sweep over them to see >> which ones are baked when the NAPI poll comes in -> problem >> solved. > > You're assuming that cookies complete in order. That is not necessarily > true. So put them on a wait list? Surely you will have a list of pending cookies and pick from the front of the queue if there isn't a hole on queue position 0. Yours, Linus Walleij -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On 02/05/2013 07:38 AM, Russell King - ARM Linux wrote: On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote: On Monday 04 February 2013, Linus Walleij wrote: So I think the above concerns are moot. The callback we can set on cookies is entirely optional, and it's even implemented by each DMA engine, and some may not even support it but require polling, and then it won't even be implemented by the driver. Just to ensure that everybody is talking about the same thing here: Is it just the callback that is optional, or also the interrupt coming from the hardware? If everyone implements stuff correctly, both. The callback most certainly is optional as things stand. The interrupt - that depends on the DMA engine. Some DMA engines you can't avoid it because you need to reprogram the hardware with the next+1 transfer upon completion of an existing transfer. Others may allow you to chain transfers in hardware. That's all up to how the DMA engine driver is implemented and how the hardware behaves. Now, there's another problem here: that is, people abuse the API. People don't pass DMA_CTRL_ACK | DMA_PREP_INTERRUPT into their operations by default. People like typing '0'. The intention of the "DMA_PREP_INTERRUPT" is significant here: it means "ask the hardware to send an interrupt upon completion of this transfer". Because soo many people like to type '0' instead in their DMA engine clients, it means that this flag is utterly useless today - you have to ignore it. So there's _no_ way for client drivers to actually tell the a DMA engine driver which _doesn't_ need to signal interrupts at the end of every transfer not to do so. So yes, the DMA engine API supports it. Whether the _implementations_ themselves do is very much hit and miss (and in reality is much more miss than hit.) Don't these assume that the driver can determine the need for an interrupt upfront at prep/submit time? AFAICT, this assumption doesn't hold true with NAPI. Thanks -- Cyril. -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On 02/05/2013 07:41 AM, Russell King - ARM Linux wrote: On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote: You're assuming that cookies complete in order. That is not necessarily true. Under what circumstances is that not true? Notably when hardware can prioritize certain classes of traffic over others, for instance with data center bridging mechanisms. -- 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 09/13] mfd: omap-usb-host: Add device tree support and binding information
[...] > >> + > >> +- single_ulpi_bypass: Must be present if the controller contains a single > >> + ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1 > > > > Again it would be nicer to have '-' rather than '_' here. It might be worth > > prefixing this "ti,". > > Is prefixing with "ti" really required? how does it better? I thought single-ulpi-bypass sounded rather generic, but it probably is specific enough as-is. I don't know enough about USB hardware to have strong feelings either way. [...] > Thanks for the in-depth review :). You're welcome. 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: DT GPMC SRAM and NOR flash support ?
On 01/02/13 19:39, Mark Jackson wrote: > On 01/02/13 17:12, Jon Hunter wrote: >> Hi Mark, >> >> On 02/01/2013 10:56 AM, Mark Jackson wrote: >>> There's plenty of DT support going in for NAND flash, but is there any work >>> going on to support NOR >>> flash ? >> >> What board and device are you working that is using NOR? I have a >> OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but >> I don't spend much time on it. Eventually it will have to be done but it >> is always good to know if there is a pressing need. > > We have a custom AM335x CPU board (arriving on my desk within the next few > weeks) that has both NAND > and NOR Flash. > >>> And how about SRAM chips or other memory mapped devices ? >> >> Not sure about SRAM (trying to think if I have a board with SRAM even), >> but definitely, boards using the GPMC to interface to ethernet chips >> need to be added. > > The board also contains an FRAM chip (which is just treated as SRAM). > > If you'd anything in the pipeline, I'm glad to help in any testing. I've > created a custom cape board > for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not > waiting for the new > hardware to arrive. I've experimented with trying to add a mtd-physmap device, but no joy. I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ? Mark J. -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 11:30 PM, Cyril Chemparathy wrote: > NAPI needs to switch between polled and interrupt driven modes of operation. > Further, in a given poll, it needs to be able to limit the amount of traffic > processed to a specified budget. I don't think any of this is a problem. Polling, just scan cookies. Disable or ignore the callbacks. For IRQ mode, use the completion callback to push each cookie to NAPI, and thus let the IRQ drive the traffic. >> The thing you're looking for sounds more like an adapter on top >> of dmaengine, which can surely be constructed, some >> drivers/dma/dmaengine-napi.c or whatever. > > I'm not debating the possibility of duct-taping a network driver on top of > the dma-engine interface. That is very much doable, and we have done this > already. So it seems I have a different opinion on elegance. I think it can be a nice little adapter, and you're talking about duct-tape, like it's something ugly and crude. So let's get to the bottom of that. > Starting with a stock dma-engine driver, our first approach was to use > dmaengine_pause() and dmaengine_resume() in the network driver to throttle > completion callbacks per NAPI's needs. Why? Do you really need to limit this in the middle of transfers? I'm half-guessing that one transfer is typically something like one packet. Pausing and starting would be something you would use in case you had a circular buffer with an eternal ongoing transfer, and you wanted to slow that down. > Having learned our lessons from the first attempt, the second step was to > add a separate notification callback from the dma-engine layer - a > notification independent of any particular descriptor. With this callback > in place, we got rid of some of the state machine crap in the network > driver. > > The third step was to add a dmaengine_poll() call instead of constantly > bouncing a channel between paused and running states. This further cleaned > up some of the network driver code, but now the dma-engine driver looks like > crap if it needs to support both the traditional and new (i.e. notify + > poll) modes. This is where we are at today. I don't see why you have to modify dmaengine to do poll. It should be trivial as discussed to just keep track of the cookies, scan over them and poll out the completed work. Then to mitigate the load I guess you just do not issue too many dma transfers? Can you not regulate the workload by adjusting the number of transfer cookies you issue in parallel, and if they're not issued in parallel but adjacent, can you not just issue them so often? Or are you polling out half transfers or something, so that the granularity of one transfer/cookie would be enough? Maybe I'm not getting the picture here? Can you describe how the network stream is chopped into transfers in this hardware, I think that could ease our understanding? Especially I guess we need to know if the hardware is providing useful chunks like one packet or if it's just one eternal stream of bits that you then have to demux and put into skbufs or something. > Even with the addition of these extensions, the interaction between the > network driver and the dma-engine driver is clumsy and involves multiple > back and forth calls per packet. This is not elegant, and certainly not > efficient. In comparison, the virtqueue interface is a natural fit with the > network driver, and is free of the aforementioned problems. Yes the described approach and hacking around in dmaengine to do the polling seems ugly. But just a queue of cookies does not seem so ugly, rather the opposite. > [Russell writes] >> So yes, the DMA engine API supports it. Whether the _implementations_ >> themselves do is very much hit and miss (and in reality is much more >> miss than hit.) > > Don't these assume that the driver can determine the need for an interrupt > upfront at prep/submit time? AFAICT, this assumption doesn't hold true > with NAPI. Yes it does. You can however stop an ongoing transfer (by referring to the cookie), pick out the bytes transferred so far and trigger a new transfer using/not using an IRQ if you want. This is an abstracted way of doing the same brutal buffer slaying that I hear NAPI is doing to some network drivers. For example see the RX path of this driver: drivers/tty/serial/amba-pl011.c There is DMA for it, but we may stop the DMA transfer on an IRQ, take the partial buffer out and feed it to the TTY. Could just as well be a network packet. Sometimes it is, if there is a modem on the other end. RX DMA is triggered in pl011_dma_rx_trigger_dma(), then either pl011_dma_rx_callback() gets called if the DMA transfer completes, or we get an IRQ (like a timeout) and endup in pl011_dma_rx_irq(), where the transfer is stopped, buffer emtied and then we can decide what to do next. This could just as well have been some API calling in and saying "give me your buffer NOW". I think we need to look at an NAPI driver that does this
Re: DT GPMC SRAM and NOR flash support ?
On 02/05/2013 10:16 AM, Mark Jackson wrote: > On 01/02/13 19:39, Mark Jackson wrote: >> On 01/02/13 17:12, Jon Hunter wrote: >>> Hi Mark, >>> >>> On 02/01/2013 10:56 AM, Mark Jackson wrote: There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ? >>> >>> What board and device are you working that is using NOR? I have a >>> OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but >>> I don't spend much time on it. Eventually it will have to be done but it >>> is always good to know if there is a pressing need. >> >> We have a custom AM335x CPU board (arriving on my desk within the next few >> weeks) that has both NAND >> and NOR Flash. >> And how about SRAM chips or other memory mapped devices ? >>> >>> Not sure about SRAM (trying to think if I have a board with SRAM even), >>> but definitely, boards using the GPMC to interface to ethernet chips >>> need to be added. >> >> The board also contains an FRAM chip (which is just treated as SRAM). >> >> If you'd anything in the pipeline, I'm glad to help in any testing. I've >> created a custom cape board >> for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not >> waiting for the new >> hardware to arrive. Sorry for the delay. I personally don't have anything in the pipe. Afzal, do you know of anyone looking at this? > I've experimented with trying to add a mtd-physmap device, but no joy. > > I'm guessing that the current mtd-physmap code is (in some way) currently > incompatible with the GPMC > device ? I am not familiar with mtd-physmap to comment. Is that DT specific? Cheers Jon -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > For IRQ mode, use the completion callback to push each cookie > to NAPI, and thus let the IRQ drive the traffic. The whole purpose of NAPI is to avoid taking interrupts for completion of transfers. Anything that generates interrupts when NAPI is in polling mode is defeating the point. signature.asc Description: Digital signature
Re: DT GPMC SRAM and NOR flash support ?
On 05/02/13 16:35, Jon Hunter wrote:
>
> On 02/05/2013 10:16 AM, Mark Jackson wrote:
>> On 01/02/13 19:39, Mark Jackson wrote:
>>> On 01/02/13 17:12, Jon Hunter wrote:
Hi Mark,
On 02/01/2013 10:56 AM, Mark Jackson wrote:
> There's plenty of DT support going in for NAND flash, but is there any
> work going on to support NOR
> flash ?
What board and device are you working that is using NOR? I have a
OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
I don't spend much time on it. Eventually it will have to be done but it
is always good to know if there is a pressing need.
>>>
>>> We have a custom AM335x CPU board (arriving on my desk within the next few
>>> weeks) that has both NAND
>>> and NOR Flash.
>>>
> And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even),
but definitely, boards using the GPMC to interface to ethernet chips
need to be added.
>>>
>>> The board also contains an FRAM chip (which is just treated as SRAM).
>>>
>>> If you'd anything in the pipeline, I'm glad to help in any testing. I've
>>> created a custom cape board
>>> for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not
>>> waiting for the new
>>> hardware to arrive.
>
> Sorry for the delay. I personally don't have anything in the pipe.
>
> Afzal, do you know of anyone looking at this?
>
>> I've experimented with trying to add a mtd-physmap device, but no joy.
>>
>> I'm guessing that the current mtd-physmap code is (in some way) currently
>> incompatible with the GPMC
>> device ?
>
> I am not familiar with mtd-physmap to comment. Is that DT specific?
Well, it's documented in Documentation/devicetree/bindings/mtd/mtd-physmap.txt,
showing you can
specify "cfi-flash" or "mtd-ram" devices, eg (taken from mtd-physmap.txt):-
flash@ff00 {
compatible = "amd,am29lv128ml", "cfi-flash";
reg = ;
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
fs@0 {
label = "fs";
reg = <0 f8>;
};
firmware@f8 {
label ="firmware";
reg = ;
read-only;
};
};
sram@2,0 {
compatible = "samsung,k6f1616u6a", "mtd-ram";
reg = <2 0 0x0020>;
bank-width = <2>;
};
But I guess the GPMC needs to be configured to enable chip selects, data
widths, etc.
I did get *something* on the address / data bus by adding the patches below,
but I'm getting bus
contention, so something else needs setting up in the GPMC.
I'm no great device driver writer, but if anyone can give me some pointers, I'm
happy to keep digging.
Cheers
Mark J.
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a37e1c9..8f45d18 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, &pdev->dev);
+ unsigned long base;
if (!of_id)
return 0;
+ gpmc_cs_request(0, SZ_16M, &base);
+
for_each_node_by_name(child, "nand") {
ret = gpmc_probe_nand_child(pdev, child);
of_node_put(child);
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..ad89446 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0>;
+ pinctrl-0 = <&user_leds_s0 &gpmc_pins_s0>;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
@@ -36,6 +36,49 @@
0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
>;
};
+
+ gpmc_pins_s0: gpmc_pins_s0 {
+ pinctrl-single,pins = <
+ 0x0 0x30/* gpmc_ad0.gpmc_ad0, INPUT |
PULLUP | MODE0 */
+ 0x4 0x30/* gpmc_ad1.gpmc_ad1, INPUT |
PULLUP | MODE0 */
+ 0x8 0x30/* gpmc_ad2.gpmc_ad2, INPUT |
PULLUP | MODE0 */
+ 0xc 0x30/* gpmc_ad3.gpmc_ad3, INPUT |
PULLUP | MODE0 */
+ 0x10 0x30 /* gpmc_ad4.gpmc_ad4, INPUT |
PULLUP | MODE0 */
+ 0x14 0x30 /* gpmc_ad5.gpmc_ad5, INPUT |
PULLUP | MODE0 */
+
Re: [PATCH V3 5/7] ARM: OMAP3: Update clocksource timer selection
On 02/05/2013 02:39 AM, Igor Grinberg wrote: > On 02/04/13 21:46, Jon Hunter wrote: >> When booting with device-tree for OMAP3 and AM335x devices and a gptimer >> is used as the clocksource (which is always the case for AM335x), a >> gptimer located in a power domain that is not always-on is selected. >> Ideally we should use a gptimer located in a power domain that is always >> on (such as the wake-up domain) so that time can be maintained during a >> kernel suspend without keeping on additional power domains unnecessarily. >> >> In order to fix this so that we can select a gptimer located in a power >> domain that is always-on, the following changes were made ... >> 1. Currently, only when selecting a gptimer to use for a clockevent >>timer, do we pass a timer property that can be used to select a >>specific gptimer. Change this so that we can pass a property when >>selecting a gptimer to use for a clocksource timer too. >> 2. Currently, when selecting either a gptimer to use for a clockevent >>timer or a clocksource timer and no timer property is passed, then >>the first available timer is selected regardless of the properties >>it has. Change this so that if no properties are passed, then a timer >>that does not have additional features (such as always-on, dsp-irq, >>pwm, and secure) is selected. >> >> Please note that using a gptimer for both clocksource and clockevents >> can have a system power impact during idle. The reason being is that >> OMAP and AMxxx devices typically only have one gptimer in a power domain >> that is always-on. Therefore when the kernel is idle both the clocksource >> and clockevent timers will be active and this will keep additional power >> domains on. During kernel suspend, only the clocksource timer is active >> and therefore, it is better to use a gptimer in a power domain that is >> always-on for clocksource. > > Hmmm... > Do I miss something or you have forgot to update the commit message? Ugh you are right :-( Some how yesterday when rebasing the series and adding a couple more patches, I royally screwed it up. How about the following ... Cheers Jon >From c82699e94d0255b3b1524e0d5ff4fd1f5852de69 Mon Sep 17 00:00:00 2001 From: Jon Hunter Date: Mon, 28 Jan 2013 17:53:57 -0600 Subject: [PATCH] ARM: OMAP3: Update clocksource timer selection When booting with device-tree for OMAP3 and AM335x devices and a gptimer is used as the clocksource (which is always the case for AM335x), a gptimer located in a power domain that is not always-on is selected. Ideally we should use a gptimer for clocksource that is located in a power domain that is always on (such as the wake-up domain) so that time can be maintained during a kernel suspend without keeping on additional power domains unnecessarily. In order to fix this so that we can select a gptimer located in a power domain that is always-on, the following changes were made ... 1. Currently, only when selecting a gptimer to use for a clockevent timer, do we pass a timer property that can be used to select a specific gptimer. Change this so that we can pass a property when selecting a gptimer to use for a clocksource timer too. 2. Currently, when selecting either a gptimer to use for a clockevent timer or a clocksource timer and no timer property is passed, then the first available timer is selected regardless of the properties it has. Change this so that if no properties are passed, then a timer that does not have additional features (such as always-on, dsp-irq, pwm, and secure) is selected. For OMAP3 and AM335x devices that use a gptimer for clocksource, change the selection of the gptimer so that by default the gptimer located in the always-on power domain is used for clocksource instead of clockevents. Please note that using a gptimer for both clocksource and clockevents can have a system power impact during idle. The reason being is that OMAP and AMxxx devices typically only have one gptimer in a power domain that is always-on. Therefore when the kernel is idle both the clocksource and clockevent timers will be active and this will keep additional power domains on. During kernel suspend, only the clocksource timer is active and therefore, it is better to use a gptimer in a power domain that is always-on for clocksource. Signed-off-by: Jon Hunter Acked-by: Santosh Shilimkar Acked-by: Igor Grinberg --- arch/arm/mach-omap2/timer.c | 33 + 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 3ad9a3b..fce495e 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -160,6 +160,12 @@ static struct device_node * __init omap_get_timer_dt(struct of_device_id *match, if (property && !of_get_property(np, property, NULL)) continue; + if (!property && (of_get_property(np, "ti,timer-alwon"
Re: DT GPMC SRAM and NOR flash support ?
On 02/05/2013 10:48 AM, Mark Jackson wrote:
> On 05/02/13 16:35, Jon Hunter wrote:
>>
>> On 02/05/2013 10:16 AM, Mark Jackson wrote:
>>> On 01/02/13 19:39, Mark Jackson wrote:
On 01/02/13 17:12, Jon Hunter wrote:
> Hi Mark,
>
> On 02/01/2013 10:56 AM, Mark Jackson wrote:
>> There's plenty of DT support going in for NAND flash, but is there any
>> work going on to support NOR
>> flash ?
>
> What board and device are you working that is using NOR? I have a
> OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but
> I don't spend much time on it. Eventually it will have to be done but it
> is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few
weeks) that has both NAND
and NOR Flash.
>> And how about SRAM chips or other memory mapped devices ?
>
> Not sure about SRAM (trying to think if I have a board with SRAM even),
> but definitely, boards using the GPMC to interface to ethernet chips
> need to be added.
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've
created a custom cape board
for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not
waiting for the new
hardware to arrive.
>>
>> Sorry for the delay. I personally don't have anything in the pipe.
>>
>> Afzal, do you know of anyone looking at this?
>>
>>> I've experimented with trying to add a mtd-physmap device, but no joy.
>>>
>>> I'm guessing that the current mtd-physmap code is (in some way) currently
>>> incompatible with the GPMC
>>> device ?
>>
>> I am not familiar with mtd-physmap to comment. Is that DT specific?
>
> Well, it's documented in
> Documentation/devicetree/bindings/mtd/mtd-physmap.txt, showing you can
> specify "cfi-flash" or "mtd-ram" devices, eg (taken from mtd-physmap.txt):-
>
> flash@ff00 {
> compatible = "amd,am29lv128ml", "cfi-flash";
> reg = ;
> bank-width = <4>;
> device-width = <1>;
> #address-cells = <1>;
> #size-cells = <1>;
> fs@0 {
> label = "fs";
> reg = <0 f8>;
> };
> firmware@f8 {
> label ="firmware";
> reg = ;
> read-only;
> };
> };
>
> sram@2,0 {
> compatible = "samsung,k6f1616u6a", "mtd-ram";
> reg = <2 0 0x0020>;
> bank-width = <2>;
> };
Ok, I see that the NOR flash on my omap2420 H4 is named "physmap-flash"
(I have not ported to DT yet). So the GPMC should work with it.
> But I guess the GPMC needs to be configured to enable chip selects, data
> widths, etc.
Exactly.
> I did get *something* on the address / data bus by adding the patches below,
> but I'm getting bus
> contention, so something else needs setting up in the GPMC.
>
> I'm no great device driver writer, but if anyone can give me some pointers,
> I'm happy to keep digging.
>
> Cheers
> Mark J.
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index a37e1c9..8f45d18 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
> struct device_node *child;
> const struct of_device_id *of_id =
> of_match_device(gpmc_dt_ids, &pdev->dev);
> + unsigned long base;
>
> if (!of_id)
> return 0;
>
> + gpmc_cs_request(0, SZ_16M, &base);
> +
You should check what gpmc_cs_request returns.
Where are the NOR flash timings setup? Or are they already configured by
the bootloader? If so then that is probably ok for now.
> for_each_node_by_name(child, "nand") {
> ret = gpmc_probe_nand_child(pdev, child);
> of_node_put(child);
If you look at the gpmc_probe_nand_child(), this function is setting up
the NAND timings for the GPMC.
Ideally, we would have a similar function for nor (ie.
gpmc_probe_nor_child()), that would read the NOR information
(chip-select, size, timings, etc) from DT. However, I understand that
the above is just for test purposes.
Cheers
Jon
--
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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote: > On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > > > For IRQ mode, use the completion callback to push each cookie > > to NAPI, and thus let the IRQ drive the traffic. > > The whole purpose of NAPI is to avoid taking interrupts for completion > of transfers. Anything that generates interrupts when NAPI is in > polling mode is defeating the point. Yes, but you're missing one very important point. If your DMA engine is decoupled from the network device, and the DMA engine relies upon interrupts to queue further transfers to move data into RAM, then you have two options: 1. Receive these interrupts so you can update the DMA engine for further data transfer. 2. Don't receive these interrupts, and cause the network device to error out with a FIFO overrun because its DMA requests have not been serviced. (which may raise an interrupt.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 5/7] ARM: OMAP3: Update clocksource timer selection
On 02/05/13 18:49, Jon Hunter wrote:
>
> On 02/05/2013 02:39 AM, Igor Grinberg wrote:
[...]
>>
>> Hmmm...
>> Do I miss something or you have forgot to update the commit message?
>
> Ugh you are right :-(
>
> Some how yesterday when rebasing the series and adding a couple more
> patches, I royally screwed it up. How about the following ...
Yep, that should do.
Thanks!
>
> Cheers
> Jon
>
>>From c82699e94d0255b3b1524e0d5ff4fd1f5852de69 Mon Sep 17 00:00:00 2001
> From: Jon Hunter
> Date: Mon, 28 Jan 2013 17:53:57 -0600
> Subject: [PATCH] ARM: OMAP3: Update clocksource timer selection
>
> When booting with device-tree for OMAP3 and AM335x devices and a gptimer
> is used as the clocksource (which is always the case for AM335x), a
> gptimer located in a power domain that is not always-on is selected.
> Ideally we should use a gptimer for clocksource that is located in a
> power domain that is always on (such as the wake-up domain) so that time
> can be maintained during a kernel suspend without keeping on additional
> power domains unnecessarily.
>
> In order to fix this so that we can select a gptimer located in a power
> domain that is always-on, the following changes were made ...
> 1. Currently, only when selecting a gptimer to use for a clockevent
>timer, do we pass a timer property that can be used to select a
>specific gptimer. Change this so that we can pass a property when
>selecting a gptimer to use for a clocksource timer too.
> 2. Currently, when selecting either a gptimer to use for a clockevent
>timer or a clocksource timer and no timer property is passed, then
>the first available timer is selected regardless of the properties
>it has. Change this so that if no properties are passed, then a timer
>that does not have additional features (such as always-on, dsp-irq,
>pwm, and secure) is selected.
>
> For OMAP3 and AM335x devices that use a gptimer for clocksource, change
> the selection of the gptimer so that by default the gptimer located in
> the always-on power domain is used for clocksource instead of
> clockevents.
>
> Please note that using a gptimer for both clocksource and clockevents
> can have a system power impact during idle. The reason being is that
> OMAP and AMxxx devices typically only have one gptimer in a power domain
> that is always-on. Therefore when the kernel is idle both the clocksource
> and clockevent timers will be active and this will keep additional power
> domains on. During kernel suspend, only the clocksource timer is active
> and therefore, it is better to use a gptimer in a power domain that is
> always-on for clocksource.
>
> Signed-off-by: Jon Hunter
> Acked-by: Santosh Shilimkar
> Acked-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/timer.c | 33 +
> 1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 3ad9a3b..fce495e 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -160,6 +160,12 @@ static struct device_node * __init
> omap_get_timer_dt(struct of_device_id *match,
> if (property && !of_get_property(np, property, NULL))
> continue;
>
> + if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
> + of_get_property(np, "ti,timer-dsp", NULL) ||
> + of_get_property(np, "ti,timer-pwm", NULL) ||
> + of_get_property(np, "ti,timer-secure", NULL)))
> + continue;
> +
> of_add_property(np, &device_disabled);
> return np;
> }
> @@ -435,13 +441,14 @@ static int __init __maybe_unused
> omap2_sync32k_clocksource_init(void)
> }
>
> static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> - const char *fck_source)
> + const char *fck_source,
> + const char *property)
> {
> int res;
>
> clksrc.errata = omap_dm_timer_get_errata();
>
> - res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
> + res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, property,
>&clocksource_gpt.name,
>OMAP_TIMER_NONPOSTED);
> BUG_ON(res);
> @@ -538,47 +545,49 @@ static inline void __init realtime_counter_init(void)
> #endif
>
> #define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,
> \
> -clksrc_nr, clksrc_src) \
> +clksrc_nr, clksrc_src, clksrc_prop) \
> void __init omap##name##_gptimer_timer_init(void)\
> {\
> omap_dmtimer_init();
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote: > On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote: > > On 02/04/2013 04:11 PM, Linus Walleij wrote: > > >> Cyril, just stack up the cookies and take a sweep over them to see > >> which ones are baked when the NAPI poll comes in -> problem > >> solved. > > > > You're assuming that cookies complete in order. That is not necessarily > > true. > > So put them on a wait list? Surely you will have a list of pending > cookies and pick from the front of the queue if there isn't a hole on > queue position 0. Not quite. The key is the cookie system DMA engine employs to indicate when a cookie is complete. Cookies between the "issued sequence" and "completed sequence" are defined to be in progress, everything else is defined to be completed. This means that if "completed sequence" is 1, and "issued sequence" is 5, then cookies with values 2, 3, 4, 5 are in progress. You can't mark sequence 4 as being complete until 2 and 3 have completed. If we need out-of-order completion, then that's a problem for the DMA engine API, because you'd need to radically change the way "completion" is marked. -- 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] ARM: dts: OMAP3: Add GPMC controller
Hi Javier, On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote: [...] Yes, I saw on the list that Tony asked you too extend the GPMC DT support. Flash support is on my TODO list too but I don't know if I'm going to have time to work on this in the next few weeks. Since you are thinking to change the binding, there is something I want to discuss with you. We have two different version for each IGEP board, one that uses NAND memory and another that has OneNAND. With board files this is easy because the flash memory type is hardcoded (in hardware) using sysboot pins [3]. So we check the sysboot value and call board_nand_init() or board_onenand_init() accordingly and pass the same static struct mtd_partition igep_flash_partitions[] in both cases. But with DT this is a little bit trickier since you have to define either a nand@0 or onenand@0 child node for the gpmc device node. So, we will have to create lots of dts and dtsi to handle each combination (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc). I wonder if we could just have a generic gpmc-flash binding and maybe use a "gpmc, flash_type" property or something like that to decide if gpmc_onenand_init() or gpmc_nand_init() has to be called. This boils down to the problem where you have an "if" statement in your board file, and I think no general solution exists. In your suggestion, having a property will force you anyway to write distinct DT files to account for the two versions, so it won't really help if I understand correctly. We would need conditional section inside device trees, at least to test for simple parameters. Or a way to generate several DT blobs based on a single DT source file. Another hackish solution would be to write a meta component, whose probe section would do your test. But this is just a stripped down version of the board file, far from being generic... I will think on it during my holidays :) Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM part of USB patches
On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: > Hi Tony, Greg, > > On Tuesday 05 February 2013 08:54 PM, kishon wrote: > >Hi Tony, > > > >As discussed, I'm sending a pull request for the arch/arm part of my USB > >patches. These patches are necessary to get MUSB functional in both dt > >and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch > >series *depends* on some of the patches which are merged in usb-next. > > This patch series should go in only after USB. Or else it will break > compilation. Then it probably should go through the USB tree, right? We don't want to break bisectability. 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 05:06:28PM +, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote: > > On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > > > For IRQ mode, use the completion callback to push each cookie > > > to NAPI, and thus let the IRQ drive the traffic. > > The whole purpose of NAPI is to avoid taking interrupts for completion > > of transfers. Anything that generates interrupts when NAPI is in > > polling mode is defeating the point. > Yes, but you're missing one very important point. If your DMA engine > is decoupled from the network device, and the DMA engine relies upon > interrupts to queue further transfers to move data into RAM, then you > have two options: > 1. Receive these interrupts so you can update the DMA engine for >further data transfer. > 2. Don't receive these interrupts, and cause the network device to >error out with a FIFO overrun because its DMA requests have not >been serviced. (which may raise an interrupt.) There's still the third option of just implementing a non-NAPI driver, though I guess we've now built so much infrastructure on top of NAPI that it's still useful to pretend we can disable interrupts. signature.asc Description: Digital signature
Re: Latest additional build warnings
* Russell King - ARM Linux [130205 06:25]: > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type > or storage class > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in > declaration of 'omap_postcore_initcall' > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without > types) in function declaration > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' defined > but not used Thanks looks like I missed that one somehow. Here's a fix for it. Arnd & Olof, care to apply this directly into the arm-soc multiplatform branch? Regards, Tony From: Tony Lindgren Date: Tue, 5 Feb 2013 09:48:08 -0800 Subject: [PATCH] ARM: OMAP2+: Fix warning for hwspinlock omap_postcore_initcall Commit 816a65ef4 (ARM: OMAP2+: Limit omap initcalls to omap only on multiplatform kernels) fixed up things for multiplatform booting but failed to include soc.h causing a new warning: arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type or storage class arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in declaration of 'omap_postcore_initcall' arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without types) in function declaration arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' defined but not used Reported-by: Signed-off-by: Russell King Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c index ce1b5b6..bcb357e 100644 --- a/arch/arm/mach-omap2/hwspinlock.c +++ b/arch/arm/mach-omap2/hwspinlock.c @@ -21,6 +21,7 @@ #include #include +#include "soc.h" #include "omap_hwmod.h" #include "omap_device.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: [GIT PULL] ARM part of USB patches
* gre...@linuxfoundation.org [130205 09:28]: > On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: > > Hi Tony, Greg, > > > > On Tuesday 05 February 2013 08:54 PM, kishon wrote: > > >Hi Tony, > > > > > >As discussed, I'm sending a pull request for the arch/arm part of my USB > > >patches. These patches are necessary to get MUSB functional in both dt > > >and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch > > >series *depends* on some of the patches which are merged in usb-next. > > > > This patch series should go in only after USB. Or else it will break > > compilation. > > Then it probably should go through the USB tree, right? We don't want > to break bisectability. Looks like this branch needs to be based on at least 01658f0f (usb: phy: add a new driver for usb part of control module) to compile. Probably needs other USB patches too to make sense. This branch has a high likelihood of conflicting with .dts files, so Kishon, I suggest you do two branches: 1. A branch for Greg based on top of the USB changes This branch should contain: ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: OMAP: USB: Add phy binding information Naturally please make sure they compile and boot on their own. Looks like this will only cause few trivial include merge conflicts with what I have queued up. You can add my Acked-by: Tony Lindgren for those. 2. A branch for Benoit based on v3.8-rc6 That branch should contain all the .dts changes as those will most likely cause nasty merge conflicts otherwise with what Benoit has queued up. 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 v4 0/2] Add CPSW VLAN Support
CPSW is capable of filtering VLAN packets in hardware. This patch series implements VLAN support to CPSW driver. This patch series is tested on net-next with AM335x EVM with ping test. Changes from initial version * added vlan support to existing add/delete unicast/multicast apis * Made driver as default VLAN enabled so that drivers need to be recompiled when stack is compiled with VLAN Changes from V2 * Moved repeated code to static inline function * Made vlan add/delete function return type to void as it is not used in the current driver implementation * Modified cpsw_add_default_vlan for better readability * changed BIT(1) port representation to defines Changes from V3 * Dropped default VLAN id passing from DT, will find a way to pass it through ethtool or similar interface and submit the patch. Mugunthan V N (2): drivers: net: cpsw: Add helper functions for VLAN ALE implementation drivers: net:ethernet: cpsw: add support for VLAN drivers/net/ethernet/ti/cpsw.c | 114 ++-- drivers/net/ethernet/ti/cpsw_ale.c | 107 + drivers/net/ethernet/ti/cpsw_ale.h | 24 ++-- include/linux/platform_data/cpsw.h |1 + 4 files changed, 222 insertions(+), 24 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] drivers: net:ethernet: cpsw: add support for VLAN
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N
---
drivers/net/ethernet/ti/cpsw.c | 106 +++-
drivers/net/ethernet/ti/cpsw_ale.h |4 ++
include/linux/platform_data/cpsw.h |1 +
3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 534bf7b..888708c 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
@@ -118,6 +119,9 @@ do {
\
#define TX_PRIORITY_MAPPING0x33221100
#define CPDMA_TX_PRIORITY_MAP 0x76543210
+#define CPSW_VLAN_AWAREBIT(1)
+#define CPSW_ALE_VLAN_AWARE1
+
#define cpsw_enable_irq(priv) \
do {\
u32 i; \
@@ -607,14 +611,40 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
}
}
+static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
+{
+ const int vlan = priv->data.default_vlan;
+ const int port = priv->host_port;
+ u32 reg;
+ int i;
+
+ reg = (priv->version == CPSW_VERSION_1) ? CPSW1_PORT_VLAN :
+ CPSW2_PORT_VLAN;
+
+ writel(vlan, &priv->host_port_regs->port_vlan);
+
+ for (i = 0; i < 2; i++)
+ slave_write(priv->slaves + i, vlan, reg);
+
+ cpsw_ale_add_vlan(priv->ale, vlan, ALE_ALL_PORTS << port,
+ ALE_ALL_PORTS << port, ALE_ALL_PORTS << port,
+ (ALE_PORT_1 | ALE_PORT_2) << port);
+}
+
static void cpsw_init_host_port(struct cpsw_priv *priv)
{
+ u32 control_reg;
+
/* soft reset the controller and initialize ale */
soft_reset("cpsw", &priv->regs->soft_reset);
cpsw_ale_start(priv->ale);
/* switch to vlan unaware mode */
- cpsw_ale_control_set(priv->ale, 0, ALE_VLAN_AWARE, 0);
+ cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
+CPSW_ALE_VLAN_AWARE);
+ control_reg = readl(&priv->regs->control);
+ control_reg |= CPSW_VLAN_AWARE;
+ writel(control_reg, &priv->regs->control);
/* setup host port priority mapping */
__raw_writel(CPDMA_TX_PRIORITY_MAP,
@@ -650,6 +680,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpsw_init_host_port(priv);
for_each_slave(priv, cpsw_slave_open, priv);
+ /* Add default VLAN */
+ cpsw_add_default_vlan(priv);
+
/* setup tx dma to fixed prio and zero offset */
cpdma_control_set(priv->dma, CPDMA_TX_PRIO_FIXED, 1);
cpdma_control_set(priv->dma, CPDMA_RX_BUFFER_OFFSET, 0);
@@ -933,6 +966,73 @@ static void cpsw_ndo_poll_controller(struct net_device
*ndev)
}
#endif
+static inline int cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
+ unsigned short vid)
+{
+ int ret;
+
+ ret = cpsw_ale_add_vlan(priv->ale, vid,
+ ALE_ALL_PORTS << priv->host_port,
+ 0, ALE_ALL_PORTS << priv->host_port,
+ (ALE_PORT_1 | ALE_PORT_2) << priv->host_port);
+ if (ret != 0)
+ return ret;
+
+ ret = cpsw_ale_add_ucast(priv->ale, priv->mac_addr,
+priv->host_port, ALE_VLAN, vid);
+ if (ret != 0)
+ goto clean_vid;
+
+ ret = cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
+ALE_ALL_PORTS << priv->host_port,
+ALE_VLAN, vid, 0);
+ if (ret != 0)
+ goto clean_vlan_ucast;
+ return 0;
+
+clean_vlan_ucast:
+ cpsw_ale_del_ucast(priv->ale, priv->mac_addr,
+ priv->host_port, ALE_VLAN, vid);
+clean_vid:
+ cpsw_ale_del_vlan(priv->ale, vid, 0);
+ return ret;
+}
+
+static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
+ return cpsw_add_vlan_ale_entry(priv, vid);
+}
+
+static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+ int ret;
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
+ ret = cpsw_ale_del_vlan(priv->ale, vid, 0);
+ if (ret != 0)
+ return ret;
+
+ ret = cpsw_ale_del_ucast(priv->ale, priv->mac_addr,
+priv->host_port, ALE_VLAN, vid);
+ if
[PATCH v4 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
Add helper functions for VLAN ALE implementations for Add, Delete
Dump VLAN related ALE entries
Signed-off-by: Mugunthan V N
---
drivers/net/ethernet/ti/cpsw.c |8 +--
drivers/net/ethernet/ti/cpsw_ale.c | 107
drivers/net/ethernet/ti/cpsw_ale.h | 20 +--
3 files changed, 113 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 9e63bff..534bf7b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -345,7 +345,7 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
/* program multicast address list into ALE register */
netdev_for_each_mc_addr(ha, ndev) {
cpsw_ale_add_mcast(priv->ale, (u8 *)ha->addr,
- ALE_ALL_PORTS << priv->host_port, 0, 0);
+ ALE_ALL_PORTS << priv->host_port, 0, 0, 0);
}
}
}
@@ -592,7 +592,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
slave_port = cpsw_get_slave_port(priv, slave->slave_num);
cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- 1 << slave_port, 0, ALE_MCAST_FWD_2);
+ 1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
&cpsw_adjust_link, slave->data->phy_if);
@@ -624,9 +624,9 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
cpsw_ale_control_set(priv->ale, priv->host_port,
ALE_PORT_STATE, ALE_PORT_STATE_FORWARD);
- cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, 0);
+ cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, 0, 0);
cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- 1 << priv->host_port, 0, ALE_MCAST_FWD_2);
+ 1 << priv->host_port, 0, 0, ALE_MCAST_FWD_2);
}
static int cpsw_ndo_open(struct net_device *ndev)
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c
b/drivers/net/ethernet/ti/cpsw_ale.c
index 0e9ccc2..7fa60d6 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -148,7 +148,7 @@ static int cpsw_ale_write(struct cpsw_ale *ale, int idx,
u32 *ale_entry)
return idx;
}
-static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr)
+int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS];
int type, idx;
@@ -160,6 +160,8 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8
*addr)
type = cpsw_ale_get_entry_type(ale_entry);
if (type != ALE_TYPE_ADDR && type != ALE_TYPE_VLAN_ADDR)
continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) != vid)
+ continue;
cpsw_ale_get_addr(ale_entry, entry_addr);
if (memcmp(entry_addr, addr, 6) == 0)
return idx;
@@ -167,6 +169,22 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8
*addr)
return -ENOENT;
}
+int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS];
+ int type, idx;
+
+ for (idx = 0; idx < ale->params.ale_entries; idx++) {
+ cpsw_ale_read(ale, idx, ale_entry);
+ type = cpsw_ale_get_entry_type(ale_entry);
+ if (type != ALE_TYPE_VLAN)
+ continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) == vid)
+ return idx;
+ }
+ return -ENOENT;
+}
+
static int cpsw_ale_match_free(struct cpsw_ale *ale)
{
u32 ale_entry[ALE_ENTRY_WORDS];
@@ -274,19 +292,32 @@ int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask)
return 0;
}
-int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags)
+static inline void cpsw_ale_set_vlan_entry_type(u32 *ale_entry,
+ int flags, u16 vid)
+{
+ if (flags & ALE_VLAN) {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+ } else {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ }
+}
+
+int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ cpsw_ale_set_vlan_entry_type(ale_entry, flags, vid);
+
cpsw_ale_set_addr(ale_entry, addr);
cpsw_ale_set_ucast_type(ale_entry, ALE_UCAST_PERSISTANT);
cpsw_ale_set_secure(ale_entry, (flags & ALE_SECURE) ? 1 : 0);
cpsw_ale_set_blocked(ale_entry, (flags & ALE_BLOCKED) ? 1 : 0);
cpsw_ale_set_port_num(
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
* Felipe Balbi [130204 07:46]: > > Current DMA abstraction is quite poor, for example there's no way to > compile support for multiple DMA engines. Code also makes certain, IMO > unnecessary, assumptions about the underlying DMA engine (abstraction is > poor, as said above but it we could follow MUSB's programming guide when > it comes to programming DMA transfers). > > Considering all of the above, it's far better to use DMA engine and get > rid of all the mess. How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM using PIO while sorting out the DMA related issues. 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown wrote: > On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > >> For IRQ mode, use the completion callback to push each cookie >> to NAPI, and thus let the IRQ drive the traffic. > > The whole purpose of NAPI is to avoid taking interrupts for completion > of transfers. Anything that generates interrupts when NAPI is in > polling mode is defeating the point. So what I was trying to get across is that when you're in polling mode you do not set DMA_PREP_INTERRUPT on your transfers, just throw the obtained struct dma_async_tx_descriptor on some list and then when polling use dma_async_is_tx_complete() on the channel and the cookie inside the descriptor. I was trying to describe that you can move from IRQ mode to polling mode and back again by selectively choosing to set/not set the DMA_PREP_INTERRUPT flag. If polling is all you want you never set it. Then there is the fact that the transfer needs to have been flagged complete and it is indeed something that needs to be set in some bytes somewhere. By something. But it doesn't have to be an interrupt from the DMA controller. In such cases we use dma_async_is_tx_complete() with channel and cookies as parameter. This will call down into the driver chan->device->device_tx_status() and there we can actually poll the hardware to see if the transfer happens to be complete, and if it is flag it complete. Which is likely what we want. No interrupts, only function calls as far as I can see. (I bet Russell will poke a hole in my reasoning, but it's worth a try.) Yours, Linus Walleij -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 6:14 PM, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote: >> So put them on a wait list? Surely you will have a list of pending >> cookies and pick from the front of the queue if there isn't a hole on >> queue position 0. > > Not quite. The key is the cookie system DMA engine employs to indicate > when a cookie is complete. > > Cookies between the "issued sequence" and "completed sequence" are defined > to be in progress, everything else is defined to be completed. > > This means that if "completed sequence" is 1, and "issued sequence" is 5, > then cookies with values 2, 3, 4, 5 are in progress. You can't mark > sequence 4 as being complete until 2 and 3 have completed. Yes that is true. DMA transfers on a certain channel are defined as progressing linearly per-cookie. I wonder if that is a problem in this case though (actually it seems the reverse, this helps in Cyril's case.) > If we need out-of-order completion, then that's a problem for the DMA > engine API, because you'd need to radically change the way "completion" > is marked. True. I wonder if this usecase is ever going to be applicable however. It could maybe be useful in some instances of memcpy() I could dream up, whereas for device transfers it seems unlikely to me. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM part of USB patches
On Tue, Feb 05, 2013 at 10:19:47AM -0800, Tony Lindgren wrote: > * gre...@linuxfoundation.org [130205 09:28]: > > On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: > > > Hi Tony, Greg, > > > > > > On Tuesday 05 February 2013 08:54 PM, kishon wrote: > > > >Hi Tony, > > > > > > > >As discussed, I'm sending a pull request for the arch/arm part of my USB > > > >patches. These patches are necessary to get MUSB functional in both dt > > > >and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch > > > >series *depends* on some of the patches which are merged in usb-next. > > > > > > This patch series should go in only after USB. Or else it will break > > > compilation. > > > > Then it probably should go through the USB tree, right? We don't want > > to break bisectability. > > Looks like this branch needs to be based on at least 01658f0f (usb: phy: > add a new driver for usb part of control module) to compile. Probably > needs other USB patches too to make sense. > > This branch has a high likelihood of conflicting with .dts files, so > Kishon, I suggest you do two branches: > > 1. A branch for Greg based on top of the USB changes > >This branch should contain: > >ARM: OMAP4: remove control module address space from PHY and OTG >ARM: OMAP: devices: create device for usb part of control module >ARM: OMAP2: MUSB: Specify omap4 has mailbox >ARM: OMAP: USB: Add phy binding information > >Naturally please make sure they compile and boot on their own. >Looks like this will only cause few trivial include merge conflicts >with what I have queued up. > >You can add my Acked-by: Tony Lindgren for those. If that happens, please send me patches in email, I don't take git pull requests, especially for something as small as 4 patches. 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: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
* Peter Ujfalusi [130205 01:49]:
> Hi Tony,
>
> On 02/04/2013 08:52 PM, Tony Lindgren wrote:
> > Looks like this now adds some new section warnings:
> >
> > WARNING: vmlinux.o(.text+0x34124): Section mismatch in reference from the
> > function sdp3430_twl_gpio_setup() to the function
> > .init.text:omap_twl4030_audio_init()
> > The function sdp3430_twl_gpio_setup() references
> > the function __init omap_twl4030_audio_init().
> > This is often because sdp3430_twl_gpio_setup lacks a __init
> > annotation or the annotation of omap_twl4030_audio_init is wrong.
> >
> > WARNING: vmlinux.o(.text+0x34b8c): Section mismatch in reference from the
> > function zoom_twl_gpio_setup() to the function
> > .init.text:omap_twl4030_audio_init()
> > The function zoom_twl_gpio_setup() references
> > the function __init omap_twl4030_audio_init().
> > This is often because zoom_twl_gpio_setup lacks a __init
> > annotation or the annotation of omap_twl4030_audio_init is wrong.
>
> For some reason the CONFIG_DEBUG_SECTION_MISMATCH got disabled in my rolling
> kernel config...
At least gcc version 4.3.5 (Debian 4.3.5-4) shows them. What's
the compiler you have?
> > These can be fixed with the following patch, but I suspect some
> > of these cannot be __init/__initdata if the driver reprobes.
> >
> > Can you please check this? I'll hold on sendinf off
> > this branch until it's been checked and fixed properly.
>
> I think this is not the correct way. the *_twl_gpio_setup() is called from the
> gpio-twl4030 driver's platform_driver probe function which if I'm not mistaken
> is not __init.
>
> I think we should remove the __init from the omap_twl4030_audio_init() in
> twl-common.c
> With this change I do not have section mismatch either.
Yes let's do that rather than start copying things around. I'll apply
the following fix to the omap-for-v3.9/twl branch.
Regards,
Tony
From: Tony Lindgren
Date: Tue, 5 Feb 2013 10:36:21 -0800
Subject: [PATCH] ARM: OMAP2+: Fix twl section warnings related to
omap_twl4030_audio_init
With the recent twl related changes we can now get:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15f88): Section mismatch in
reference from the function sdp3430_twl_gpio_setup() to the function
.init.text:omap_twl4030_audio_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap_twl4030_audio_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap_twl4030_audio_init is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x16968): Section mismatch in
reference from the function zoom_twl_gpio_setup() to the function
.init.text:omap_twl4030_audio_init()
The function zoom_twl_gpio_setup() references
the function __init omap_twl4030_audio_init().
This is often because zoom_twl_gpio_setup lacks a __init
annotation or the annotation of omap_twl4030_audio_init is wrong.
Fix this by removing __init from omap_twl4030_audio_init() as
suggested by Peter Ujfalusi .
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -536,7 +536,7 @@ static struct platform_device audio_device = {
.id = -1,
};
-void __init omap_twl4030_audio_init(char *card_name,
+void omap_twl4030_audio_init(char *card_name,
struct omap_tw4030_pdata *pdata)
{
if (!pdata)
@@ -549,7 +549,7 @@ void __init omap_twl4030_audio_init(char *card_name,
}
#else /* SOC_OMAP_TWL4030 */
-void __init omap_twl4030_audio_init(char *card_name,
+void omap_twl4030_audio_init(char *card_name,
struct omap_tw4030_pdata *pdata)
{
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
* Russell King - ARM Linux [130205 04:34]:
> On Mon, Feb 04, 2013 at 11:52:51AM -0800, Tony Lindgren wrote:
> > @@ -245,7 +245,7 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
> > return 0;
> > }
> >
> > -static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
> > +static struct twl4030_gpio_platform_data __initdata sdp3430_gpio_data = {
> > .pulldowns = BIT(2) | BIT(6) | BIT(8) | BIT(13)
> > | BIT(16) | BIT(17),
> > .setup = sdp3430_twl_gpio_setup,
>
> Seeing platform data marked with __initdata makes me extremely nervous.
> Are you _absolutely_ _sure_ that this data either:
>
> (a) gets copied before use, or
> (b) is not used after kernel init
>
> ?
No, and that's why I said "I suspect some of these cannot be
__init/__initdata" and asked Peter to verify it :)
> Normally, platform data is passed via a pointer in struct device to
> drivers, and drivers either store a pointer to it, or if the driver is
> unbound/rebound, they can access it well after init time.
Yes it's not worth adding any copying of it in the twl-common.c.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM:omap2: using strlcpy instead of strncpy
* Chen Gang [130204 18:22]: > 于 2013年02月05日 02:18, Tony Lindgren 写道: > > * Peter Ujfalusi [130204 01:04]: > >> > Hi Tony, > >> > > >> > I can create a branch for you in our gitorious tree > >> > (git://gitorious.org/omap-audio/linux-audio.git) for this patch. But I > >> > think > >> > for now it would be best if you could take this via linux-omap (the file > >> > is > >> > under arch/arm/mach-omap2 anyways) > > OK thanks I'll apply with your ack to omap-for-v3.9/fixes-noncritical. > > > > Tony > > > > Does it mean: we need not sync MAINTAINERS file for twl-*, recently ? > > :-) No we should still do it. 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: DSS errors in linux next when booted with DTB append
* Tomi Valkeinen [130205 04:40]: > Hi, > > On 2013-01-16 21:08, Tony Lindgren wrote: > > Hi Tomi, > > > > Looks like omap_dss_init() goes crazy on panda es when booted with > > PANEL_TAAL and DTB append enabled, see below. Does not seem to happen when > > booted on blaze. Noticed this after enabling all the panels, my modified > > omap2plus_defconfig attached. > > Hmm, looks odd. The log shows it's trying to use Taal panel, even if > Panda doesn't have such a panel. Who's adding the Taal device? Are you > booting Panda with Blaze's dtb? Hmm yeah I might have had Blaze's dtb there, need to check. That certainly would explain it. > That said, I have seen similar circular locking warnings related to > omapfb/omapdss, but I haven't been able to resolve them, or even to > really find out why the warning happens. I haven't seen any problems > though, it's just a warning. > > So my guess is that you're seeing two unrelated problems, one related to > dtbs or such, and the other related to locks. Yeah the locks related one could be caused by spurious interrupts by some other device if I had Blaze's .dtb in use. 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 1/2] ARM: dts: OMAP3: Add GPMC controller
On Tue, Feb 5, 2013 at 6:23 PM, Florian Vaussard wrote: > Hi Javier, > Hi Florian, > On 02/04/2013 12:57 PM, Javier Martinez Canillas wrote: > > [...] > > >> >> Yes, I saw on the list that Tony asked you too extend the GPMC DT >> support. Flash support is on my TODO list too but I don't know if I'm >> going to have time to work on this in the next few weeks. >> >> Since you are thinking to change the binding, there is something I >> want to discuss with you. >> >> We have two different version for each IGEP board, one that uses NAND >> memory and another that has OneNAND. >> >> With board files this is easy because the flash memory type is >> hardcoded (in hardware) using sysboot pins [3]. So we check the >> sysboot value and call board_nand_init() or board_onenand_init() >> accordingly and pass the same static struct mtd_partition >> igep_flash_partitions[] in both cases. >> >> But with DT this is a little bit trickier since you have to define >> either a nand@0 or onenand@0 child node for the gpmc device node. So, >> we will have to create lots of dts and dtsi to handle each combination >> (IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc). >> >> I wonder if we could just have a generic gpmc-flash binding and maybe >> use a "gpmc, flash_type" property or something like that to decide if >> gpmc_onenand_init() or gpmc_nand_init() has to be called. >> > > This boils down to the problem where you have an "if" statement in > your board file, and I think no general solution exists. > Yes, this is a general issue since DT uses a declarative paradigm. I was just pointing out that I found that particular issue with the flash memory type on IGEP boards. > In your suggestion, having a property will force you anyway to write > distinct DT files to account for the two versions, so it won't really > help if I understand correctly. We would need conditional > section inside device trees, at least to test for simple parameters. > Or a way to generate several DT blobs based on a single DT source file. > Well you will still need a different dtb for each combination but it could make your device trees smaller and simpler since you can define your GPMC flash child node on a dtsi where you set all the partition and sizes and export that device node to your boards dts that only set the "gpmc, flash_type" property to nand or onenand (assuming both your NAND and OneNAND version have the same partition layout and sizes). Otherwise you would have to define the complete onenand or nand child node on your board dts having duplicated definition for your flash partition layouts. > Another hackish solution would be to write a meta component, whose > probe section would do your test. But this is just a stripped down version > of the board file, far from being generic... > Yes, and that doesn't fit on the DT model too well. I still don't know what's the best way to do it. > I will think on it during my holidays :) > great, I hope you enjoy your holidays :-) > Regards, > > Florian > 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: OMAP4 PM bootloader dependency problems
Hi Paul,
On 01/21/2013 08:42 PM, Paul Walmsley wrote:
>
> Hi Tero, Rajendra, Santosh,
>
> As we've discussed, there are known bootloader dependencies with the OMAP4
> PM retention idle code, introduced in v3.8. Boards booted with u-boot
> versions even as recent as 2011 won't enter retention idle correctly; for
> example:
>
>
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
>
> The right thing for you all to do is what was done for OMAP3: to add code
> to correctly reset and initialize these on-chip devices. However, since
> it's already late in the v3.8-rc cycle, this seems unlikely to happen in
> time for the v3.8 release -- and that's assuming that you guys are working
> on this, which I'm unsure of.
I noticed on my OMAP4430 SDP that in suspend L3INIT was failing to enter
retention state. I am not sure if this is the same problem that you are
seeing or not. However, I found that the reason the L3INIT was not entering
retention on this board was because the USB DPLL was not locked by the
bootloader on this board. On my panda the USB DPLL is locked the L3INIT
is entering suspend.
I crafted the following which is working on my omap4430 panda, sdp and
omap4460 panda. Let me know what you think ...
Cheers
Jon
>From 3bfe708af8e91564bc78c79111f9080a35fb5b88 Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Tue, 5 Feb 2013 13:27:57 -0600
Subject: [PATCH] ARM: OMAP4: Fix low power in kernel suspend
Some versions of the u-boot bootloader do not lock the USB DPLL and
when the USB DPLL is not locked, then it is observed that the L3INIT
power domain does not transition to retention state during kernel
suspend on OMAP4 devices. Fix this by locking the USB DPLL at 960 MHz
on kernel boot.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/cclock44xx_data.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index e71a19c..2c811d9 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -48,6 +48,13 @@
*/
#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * "3.6.3.9.5 DPLL_USB Preferred Settings" shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ 96000
+
/* Root clocks */
DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
@@ -2045,5 +2052,13 @@ int __init omap4xxx_clk_init(void)
if (rc)
pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+ /*
+* Lock USB DPLL on OMAP4 devices so that the L3INIT power
+* domain can transition to retention state when not in use.
+*/
+ rc = clk_set_rate(&dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ);
+ if (rc)
+ pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On 02/05/2013 01:29 PM, Linus Walleij wrote: On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown wrote: On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: For IRQ mode, use the completion callback to push each cookie to NAPI, and thus let the IRQ drive the traffic. The whole purpose of NAPI is to avoid taking interrupts for completion of transfers. Anything that generates interrupts when NAPI is in polling mode is defeating the point. So what I was trying to get across is that when you're in polling mode you do not set DMA_PREP_INTERRUPT on your transfers, just throw the obtained struct dma_async_tx_descriptor on some list and then when polling use dma_async_is_tx_complete() on the channel and the cookie inside the descriptor. I was trying to describe that you can move from IRQ mode to polling mode and back again by selectively choosing to set/not set the DMA_PREP_INTERRUPT flag. This does not work. At prep/submit time, the network driver does not know if a particular packet buffer needs an interrupt or not. It queues up a whole bunch of receive buffers upfront. These buffers simply sit on the hardware queue/ring until the NIC receives traffic. The driver throttles the receive processing rate by dynamically switching between interrupt and poll behaviors on the completion side, not on the submission side. If polling is all you want you never set it. Another point here is that it is not simply a polling vs. interrupt problem. The system needs to dynamically switch between the two behaviors depending on offered load conditions. This dynamic switching is key to balancing latency (under low load) and throughput (at high rates). It cannot be one or the other, it must be both. Once again, I'm fairly sure that suitably reworking or extending the dma-engine interfaces will allow network DMAs to fit in nicely. However, I'd also appreciate inputs on the alternative approach of using virtio devices as an interface to packet oriented DMA hardware. From my perspective this offers the following advantages, some of which I've already mentioned in earlier postings: 1. The virtqueue interface is nice and clean, it fits very well with networking concepts such as NAPI. In comparison, the dma-engine API will need extensions and/or rework to fit network DMAs. 2. Advantages from leveraging the virtio infrastructure. For example, if a DMA pipe to a remote processor is exposed as a virtio device, something like rpmsg could very naturally fit on top of this without any other added glue. 3. Advantages from leveraging the driver model for binding dma clients to dma hardware, instead of resorting to name lookups and such. Thanks -- Cyril. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
Grant Likely writes: > On Fri, 14 Dec 2012 18:05:53 +1100, NeilBrown wrote: >> On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman >> wrote: >> >> >> > OK thanks, I'll queue this up for v3.6-rc as this should qualify as a >> > regression. >> >> I don't think this did actually get queued. At least I'm still seeing the >> bug in 3.7 and I cannot see a patch in the git history that looks right. >> But then I don't remember what we ended up with - it was 3 months ago!!! >> >> This is the last thing I can find in my email history - it still seems to >> apply and still seems to work. >> >> NeilBrown > > Kevin, let me know if I need to do anything here. Since you might have > it in one of you're trees, I'm not going to do anything unless I hear > from you. oops, just stumbled across this one. Sorry for the lag. Grant, feel free to apply. Seems this one never made it into my queue. 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, RFC] default machine descriptor for multiplatform
On 01/31/2013 11:51 AM, Arnd Bergmann wrote:
> This is what I think it would look like to do a default platform
> with an empty machine descriptor on ARM. It makes the few required
> entries in the descriptor optional by using the new irqchip_init()
> and clocksource_of_init() functions as defaults, and adds
> a fallback for the DT case to customize_machine to probe all
> the default devices.
>
> For the case that CONFIG_MULTIPLATFORM is enabled, it then
> adds a machine descriptor that never matches any machine but
> is used as a fallback if nothing else matches.
>
> Signed-off-by: Arnd Bergmann
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3e3444e..8ff1d38 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -979,7 +979,6 @@ config ARCH_MULTI_V7
> bool "ARMv7 based platforms (Cortex-A, PJ4, Krait)"
> default y
> select ARCH_MULTI_V6_V7
> - select ARCH_VEXPRESS
> select CPU_V7
>
> config ARCH_MULTI_V6_V7
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 70f1bde..e6e34ba 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned
> int dt_phys)
> unsigned long dt_root;
> const char *model;
>
> + if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
> + DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> + MACHINE_END
I assume this works, but it looks a bit strange declared here.
> +
> + mdesc_best = (struct machine_desc *)&__mach_desc_GENERIC_DT;
> + }
> +
> if (!dt_phys)
> return NULL;
>
> @@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned
> int dt_phys)
> mdesc_score = score;
> }
> }
> - if (!mdesc_best) {
> + if (!mdesc_best && !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
> const char *prop;
> long size;
>
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 8e4ef4c..df6f9a1 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
>
> void __init init_IRQ(void)
> {
> - machine_desc->init_irq();
> + if (machine_desc->init_irq)
> + machine_desc->init_irq();
> + else
> + irqchip_init();
> }
>
> #ifdef CONFIG_MULTI_IRQ_HANDLER
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2..1d40c9d 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -640,9 +641,17 @@ struct screen_info screen_info = {
>
> static int __init customize_machine(void)
> {
> - /* customizes platform devices, or adds new ones */
> + /*
> + * customizes platform devices, or adds new ones
> + * On DT based machines, we fall back to populating the
> + * machine from the device tree, if no callback is provided,
> + * otherwise we would always need an init_machine callback.
> + */
> if (machine_desc->init_machine)
> machine_desc->init_machine();
> + else
> + of_platform_populate(NULL, of_default_bus_match_table,
> + NULL, NULL);
Could this be unconditional? It should be safe to call multiple times
if a platform calls this first because ordering matters or there are
custom match tables. I would guess any ordering requirements need to
happen before this call anyway.
Rob
--
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
DSS build breakage
Hi Tomi, DSS doesn't build with allyesconfig: drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div': drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function) drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [drivers/video/omap2/dss/dss.o] Error 1 Found when debugging another problem reported by Arnd. -- balbi signature.asc Description: Digital signature
Re: [PATCH, RFC] default machine descriptor for multiplatform
On Thu, Jan 31, 2013 at 9:51 AM, Arnd Bergmann wrote: > This is what I think it would look like to do a default platform > with an empty machine descriptor on ARM. It makes the few required > entries in the descriptor optional by using the new irqchip_init() > and clocksource_of_init() functions as defaults, and adds > a fallback for the DT case to customize_machine to probe all > the default devices. > > For the case that CONFIG_MULTIPLATFORM is enabled, it then > adds a machine descriptor that never matches any machine but > is used as a fallback if nothing else matches. > > Signed-off-by: Arnd Bergmann Nice! Acked-by: Olof Johansson (Besides what Stephen already pointed out) -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest additional build warnings
On Tue, Feb 05, 2013 at 09:51:26AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [130205 06:25]: > > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type > > or storage class > > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in > > declaration of 'omap_postcore_initcall' > > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without > > types) in function declaration > > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' > > defined but not used > > Thanks looks like I missed that one somehow. Here's a fix for > it. > > Arnd & Olof, care to apply this directly into the arm-soc multiplatform > branch? > > Regards, > > Tony > > > From: Tony Lindgren > Date: Tue, 5 Feb 2013 09:48:08 -0800 > Subject: [PATCH] ARM: OMAP2+: Fix warning for hwspinlock > omap_postcore_initcall > > Commit 816a65ef4 (ARM: OMAP2+: Limit omap initcalls to omap only on > multiplatform kernels) fixed up things for multiplatform booting > but failed to include soc.h causing a new warning: > > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: data definition has no type > or storage class > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: type defaults to 'int' in > declaration of 'omap_postcore_initcall' > arch/arm/mach-omap2/hwspinlock.c:60:1: warning: parameter names (without > types) in function declaration > arch/arm/mach-omap2/hwspinlock.c:31:122: warning: 'hwspinlocks_init' defined > but not used > > Reported-by: Signed-off-by: Russell King > Signed-off-by: Tony Lindgren Applied to next/multiplatform with the reported-by line fixed up. -Olof -- 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, RFC] default machine descriptor for multiplatform
On Tuesday 05 February 2013, Rob Herring wrote:
> >
> > + if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
> > + DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> > + MACHINE_END
>
> I assume this works, but it looks a bit strange declared here.
Yes, I was wondering whether it should be global instead, but that
would require an #ifdef, or enabling it for all DT-based builds, not
just those with ARCH_MULTIPLATFORM.
> > static int __init customize_machine(void)
> > {
> > - /* customizes platform devices, or adds new ones */
> > + /*
> > + * customizes platform devices, or adds new ones
> > + * On DT based machines, we fall back to populating the
> > + * machine from the device tree, if no callback is provided,
> > + * otherwise we would always need an init_machine callback.
> > + */
> > if (machine_desc->init_machine)
> > machine_desc->init_machine();
> > + else
> > + of_platform_populate(NULL, of_default_bus_match_table,
> > + NULL, NULL);
>
> Could this be unconditional? It should be safe to call multiple times
> if a platform calls this first because ordering matters or there are
> custom match tables. I would guess any ordering requirements need to
> happen before this call anyway.
Yes, possible, but that needs more testing to avoid potential regressions.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/4] omap non-critical fixes for v3.9 merge window
On Mon, Feb 04, 2013 at 11:55:46AM -0800, Tony Lindgren wrote: > The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: > > Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.9/fixes-non-critical-signed-v2 Pulled 1-4. -Olof -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tuesday 05 February 2013, Tony Lindgren wrote: > * Felipe Balbi [130204 07:46]: > > > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). > > > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. > > How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? > That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM > using PIO while sorting out the DMA related issues. Sounds ok to me. Someone still needs to do the work to make the non-DMA variants of MUSB coexist in one kernel, but as we discussed erlier, that should be much simpler. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
* Jon Hunter [130204 14:49]: > > On 02/04/2013 04:12 PM, Jon Hunter wrote: > > > > On 02/01/2013 03:51 PM, Tony Lindgren wrote: > > > >> How about let's fix this properly to start with so we don't add > >> more blockers moving this code to drivers/bus? > >> > >> Looks like gpmc_mem_init() gets called from gpmc_probe() so > >> we can pass that information in pdev. > > > > I have re-worked this a bit to use platform data. I have also update > > the logic for testing internal/external boot on omap2430 which is > > different from omap2420 (according to the TRM). However, I have only > > boot tested on omap2420. > > > > Do you know why this was changed in the first place? See below ... > > > > http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931 > > > > Heres what I have now ... > > Updated patch (I was missing a kfree()). By the way, this is based > upon the apollon removal patch. I understand probably needs to be > rebased on your latest gpmc series too. Yeah makes sense to me thanks. I'll figure out where to apply this so we don't get too many dependencies. 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 1/2] ARM: OMAP2+: SoC name and revision unification
* Ruslan Bilovol [130131 11:28]: > This is a long story where for each new generation of > OMAP we used different approaches for creating > strings for SoCs names and revisions that this patch > fixes. It makes future exporting of this information > to SoC infrastructure easier. Maybe use name soc_name and soc_rev instead and make cpu_name and cpu_rev local to the functions? That would reduce some churn here. Also this does not apply to my omap-for-v3.9/soc branch. Care to update this (and possibly the second one) against that? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
On 02/05/2013 05:34 PM, Tony Lindgren wrote: > * Jon Hunter [130204 14:49]: >> >> On 02/04/2013 04:12 PM, Jon Hunter wrote: >>> >>> On 02/01/2013 03:51 PM, Tony Lindgren wrote: >>> How about let's fix this properly to start with so we don't add more blockers moving this code to drivers/bus? Looks like gpmc_mem_init() gets called from gpmc_probe() so we can pass that information in pdev. >>> >>> I have re-worked this a bit to use platform data. I have also update >>> the logic for testing internal/external boot on omap2430 which is >>> different from omap2420 (according to the TRM). However, I have only >>> boot tested on omap2420. >>> >>> Do you know why this was changed in the first place? See below ... >>> >>> http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931 >>> >>> Heres what I have now ... >> >> Updated patch (I was missing a kfree()). By the way, this is based >> upon the apollon removal patch. I understand probably needs to be >> rebased on your latest gpmc series too. > > Yeah makes sense to me thanks. I'll figure out where to apply this > so we don't get too many dependencies. Actually, let me look into this a bit more. It appears that for all omap2+ devices NOR should be mapped to CS0 at 0x0800. So I am wondering if the boot-loader is re-mapping the CS0 space. If it is then may be we can avoid having such hacks in the kernel by fixing the bootloader. To date only the apollon board has really had this problem and I need to check what I have on my H4 (which has been hacked by me ;-) Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM:omap2: using strlcpy instead of strncpy
于 2013年02月06日 02:56, Tony Lindgren 写道: > * Chen Gang [130204 18:22]: >> > Does it mean: we need not sync MAINTAINERS file for twl-*, recently ? >> > >> > :-) > No we should still do it. > > Tony > ok, thanks. if necessary (no other members do it), I should perform. if really should I do: requirements: A) I should succeed provide at least 3 valuable patches to twl-* (or I am not qualified to provide the sync MAINTAINERS patch) B) relative member need give strictly checking for the patch. (so can evaluate whether I have been qualified) C) it is necessary to be monitored by the relative mailing lists. I should try: A) need mainly focus on the omap2, specially for twl-* B) the patch type should be for bug fixing: (I am not familiar with omap2, so can not for new features) i. memory override. ii. resource management. iii. others (compiling issue, type cast, ...) C) should provide 3 twl-* valuable patches within 1 month. (have finished one: strlcpy, in Jan 30 2013) (so need finish the other 2 patches, before Feb 28 2013) hope I can succeed. welcome any members to provide suggestions and completions. thanks. :-) -- Chen Gang Asianux Corporation -- 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: DT GPMC SRAM and NOR flash support ?
Hi Jon, On Tue, Feb 05, 2013 at 22:05:20, Hunter, Jon wrote: > On 02/05/2013 10:16 AM, Mark Jackson wrote: > There's plenty of DT support going in for NAND flash, but is there any > work going on to support NOR > flash ? > >> If you'd anything in the pipeline, I'm glad to help in any testing. I've > >> created a custom cape board > >> for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not > >> waiting for the new > >> hardware to arrive. > Sorry for the delay. I personally don't have anything in the pipe. > > Afzal, do you know of anyone looking at this? I am not aware of anyone working on it. Regards Afzal
RE: [GIT PULL] ARM part of USB patches
On Tue, Feb 05, 2013 at 23:49:47, Tony Lindgren wrote: > * gre...@linuxfoundation.org [130205 09:28]: > > On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote: > > > Hi Tony, Greg, > > > > > > On Tuesday 05 February 2013 08:54 PM, kishon wrote: > > > >Hi Tony, > > > > > > > >As discussed, I'm sending a pull request for the arch/arm part of my USB > > > >patches. These patches are necessary to get MUSB functional in both dt > > > >and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch > > > >series *depends* on some of the patches which are merged in usb-next. > > > > > > This patch series should go in only after USB. Or else it will break > > > compilation. > > > > Then it probably should go through the USB tree, right? We don't want > > to break bisectability. > > Looks like this branch needs to be based on at least 01658f0f (usb: phy: > add a new driver for usb part of control module) to compile. Probably > needs other USB patches too to make sense. > > This branch has a high likelihood of conflicting with .dts files, so > Kishon, I suggest you do two branches: > > 1. A branch for Greg based on top of the USB changes > >This branch should contain: > >ARM: OMAP4: remove control module address space from PHY and OTG >ARM: OMAP: devices: create device for usb part of control module >ARM: OMAP2: MUSB: Specify omap4 has mailbox >ARM: OMAP: USB: Add phy binding information > >Naturally please make sure they compile and boot on their own. >Looks like this will only cause few trivial include merge conflicts >with what I have queued up. > >You can add my Acked-by: Tony Lindgren for those. > > 2. A branch for Benoit based on v3.8-rc6 > >That branch should contain all the .dts changes as those will >most likely cause nasty merge conflicts otherwise with what >Benoit has queued up. > Tony/Benoit, There are few AM33xx DTS patches pending from long time, how do you want to take it forward? You want me to put it into one branch and share? OR just provide the list of all patches to you? Thanks, Vaibhav > Regards, > > Tony > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- 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 2/3] omap: craneboard: support the TPS65910 PMU
> Thanks applying 1 and 2 into omap-for-v3.9/board. Did not > see patch 3 of this anywhere? Thank you. The third patch is for the TPS65910 PMU on the Craneboard. It was already applied. https://lkml.org/lkml/2012/11/30/192 Regards, Milo -- 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 5/5] usb: omap_control_usb: fix compile warning
From: Felipe Balbi
When CONFIG_OMAP_CONTROL_USB isn't enabled,
there's a compile warning stating that a
particular function isn't a prototype.
Fix it.
Signed-off-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
include/linux/usb/omap_control_usb.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index f306db7..27b5b8c 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -70,7 +70,7 @@ extern void omap_control_usb3_phy_power(struct device *dev,
bool on);
extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
#else
-static inline struct device *omap_get_control_dev()
+static inline struct device *omap_get_control_dev(void)
{
return ERR_PTR(-ENODEV);
}
--
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
[PATCH 0/5] ARM: OMAP: arm part of usb patches
Hi Greg, Here is the patch series that includes the arch/arm part to get MUSB working in OMAP platforms. As discussed in the other mail thread with Tony, this patch series should go into usb-next. This patch series also contains a patch by Felipe to fix compilation warning in usb-next when CONFIG_OMAP_CONTROL_USB is not set. Boot tested panda board. Felipe Balbi (1): usb: omap_control_usb: fix compile warning Kishon Vijay Abraham I (4): ARM: OMAP4: remove control module address space from PHY and OTG ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox ARM: OMAP: USB: Add phy binding information arch/arm/mach-omap2/board-2430sdp.c |2 ++ arch/arm/mach-omap2/board-3430sdp.c |2 ++ arch/arm/mach-omap2/board-4430sdp.c |2 ++ arch/arm/mach-omap2/board-cm-t35.c |2 ++ arch/arm/mach-omap2/board-devkit8000.c |2 ++ arch/arm/mach-omap2/board-igep0020.c |2 ++ arch/arm/mach-omap2/board-ldp.c |2 ++ arch/arm/mach-omap2/board-omap3beagle.c |2 ++ arch/arm/mach-omap2/board-omap3evm.c |2 ++ arch/arm/mach-omap2/board-omap3logic.c |2 ++ arch/arm/mach-omap2/board-omap3pandora.c |2 ++ arch/arm/mach-omap2/board-omap3stalker.c |2 ++ arch/arm/mach-omap2/board-omap3touchbook.c |2 ++ arch/arm/mach-omap2/board-omap4panda.c |2 ++ arch/arm/mach-omap2/board-overo.c|2 ++ arch/arm/mach-omap2/board-rm680.c|2 ++ arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++ arch/arm/mach-omap2/devices.c| 45 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 arch/arm/mach-omap2/usb-musb.c |3 ++ include/linux/usb/musb.h |2 ++ include/linux/usb/omap_control_usb.h |2 +- 22 files changed, 85 insertions(+), 14 deletions(-) -- 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
[PATCH 4/5] ARM: OMAP: USB: Add phy binding information
This is w.r.t the changes in PHY library to support adding and getting
multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done here for OMAP platforms.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-2430sdp.c |2 ++
arch/arm/mach-omap2/board-3430sdp.c |2 ++
arch/arm/mach-omap2/board-4430sdp.c |2 ++
arch/arm/mach-omap2/board-cm-t35.c |2 ++
arch/arm/mach-omap2/board-devkit8000.c |2 ++
arch/arm/mach-omap2/board-igep0020.c |2 ++
arch/arm/mach-omap2/board-ldp.c |2 ++
arch/arm/mach-omap2/board-omap3beagle.c |2 ++
arch/arm/mach-omap2/board-omap3evm.c |2 ++
arch/arm/mach-omap2/board-omap3logic.c |2 ++
arch/arm/mach-omap2/board-omap3pandora.c |2 ++
arch/arm/mach-omap2/board-omap3stalker.c |2 ++
arch/arm/mach-omap2/board-omap3touchbook.c |2 ++
arch/arm/mach-omap2/board-omap4panda.c |2 ++
arch/arm/mach-omap2/board-overo.c|2 ++
arch/arm/mach-omap2/board-rm680.c|2 ++
arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
17 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 4815ea6..1337f2c 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -263,6 +264,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..8a2e242 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -579,6 +580,7 @@ static void __init omap_3430sdp_init(void)
omap_ads7846_init(1, gpio_pendown, 310, NULL);
omap_serial_init();
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1cc6696..8e8efcc 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -696,6 +697,7 @@ static void __init omap_4430sdp_init(void)
omap4_sdp4430_wifi_init();
omap4_twl6030_hsmmc_init(mmc);
+ usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
usb_musb_init(&musb_board_data);
status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..f1172f2 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -724,6 +725,7 @@ static void __init cm_t3x_common_init(void)
cm_t35_init_display();
omap_twl4030_audio_init("cm-t3x");
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
cm_t35_init_usbh();
cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 12865af..77cade52 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -622,6 +623,7 @@ static void __init devkit8000_init(void)
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..15e5881 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -625,6 +626,7 @@ static void __init igep_init(void)
omap_serial_init();
omap_sdrc_init(m65kam_sdrc_params,
m65kam_sdrc_params);
+ usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
igep_flash_init();
diff --git a/arch/arm/mach-omap2/board-ldp.c b/
[PATCH 1/5] ARM: OMAP4: remove control module address space from PHY and OTG
Now that we have a separate driver for the control module,
stop populating the control module device data in other modules
(PHY and OTG) device info.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 793f54a..624a7e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2702,13 +2702,6 @@ static struct resource omap44xx_usb_phy_and_pll_addrs[]
= {
.end= 0x4a0ae000,
.flags = IORESOURCE_MEM,
},
- {
- /* XXX: Remove this once control module driver is in place */
- .name = "ctrl_dev",
- .start = 0x4a002300,
- .end= 0x4a002303,
- .flags = IORESOURCE_MEM,
- },
{ }
};
@@ -6156,12 +6149,6 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
- {
- /* XXX: Remove this once control module driver is in place */
- .pa_start = 0x4a00233c,
- .pa_end = 0x4a00233f,
- .flags = ADDR_TYPE_RT
- },
{ }
};
--
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
[PATCH 2/5] ARM: OMAP: devices: create device for usb part of control module
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)
#endif
}
+#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+ .type = 1,
+};
+
+struct resource omap4_control_usb_res[] = {
+ {
+ .name = "control_dev_conf",
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "otghs_control",
+ .start = 0x4a00233c,
+ .end= 0x4a00233f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap4_control_usb = {
+ .name = "omap-control-usb",
+ .id = -1,
+ .dev = {
+ .platform_data = &omap4_control_usb_pdata,
+ },
+ .num_resources = 2,
+ .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+ if (!cpu_is_omap44xx())
+ return;
+
+ if (platform_device_register(&omap4_control_usb))
+ pr_err("Error registering omap_control_usb device\n");
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
{
@@ -721,6 +765,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+ omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
--
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
[PATCH 3/5] ARM: OMAP2: MUSB: Specify omap4 has mailbox
Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/usb-musb.c |3 +++
include/linux/usb/musb.h |2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7b33b37..9d27e3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
+ if (cpu_is_omap44xx())
+ musb_plat.has_mailbox = true;
+
if (soc_is_am35xx()) {
oh_name = "am35x_otg_hs";
name = "musb-am35x";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..053c268 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,8 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
+ u8 has_mailbox:1;
+
/* for clk_get() */
const char *clock;
--
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: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
On 02/05/2013 07:40 PM, Tony Lindgren wrote: >> For some reason the CONFIG_DEBUG_SECTION_MISMATCH got disabled in my rolling >> kernel config... > > At least gcc version 4.3.5 (Debian 4.3.5-4) shows them. What's > the compiler you have? It show for me as well now that I have enabled the CONFIG_DEBUG_SECTION_MISMATCH in my config. My GCC is: armv7a-hardfloat-linux-gnueabi-gcc (Gentoo 4.7.2 p1.3, pie-0.5.5) 4.7.2 > Yes let's do that rather than start copying things around. I'll apply > the following fix to the omap-for-v3.9/twl branch. Cool, thanks Tony. I will drop my patch and pick the one from omap-for-v3.9/twl. Thanks, Péter -- 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 v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 10:26:30PM +, Arnd Bergmann wrote: > On Tuesday 05 February 2013, Tony Lindgren wrote: > > * Felipe Balbi [130204 07:46]: > > > > > > Current DMA abstraction is quite poor, for example there's no way to > > > compile support for multiple DMA engines. Code also makes certain, IMO > > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > > poor, as said above but it we could follow MUSB's programming guide when > > > it comes to programming DMA transfers). > > > > > > Considering all of the above, it's far better to use DMA engine and get > > > rid of all the mess. > > > > How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? > > That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM > > using PIO while sorting out the DMA related issues. > > Sounds ok to me. Someone still needs to do the work to make the non-DMA > variants of MUSB coexist in one kernel, but as we discussed erlier, that > should be much simpler. Yeah, I'm cooking some patches to at least make it buildable. Dropping unnecessary dependencies and marking da8xx and davinci as depending on BROKEN seems to be the easiest way; those two glues hasn't seen a real patch since 2010 or so. -- balbi signature.asc Description: Digital signature
