Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion
On 02/28/2014 08:33 PM, Tony Lindgren wrote: * Tero Kristo [140228 10:21]: Hmm, some clock node is broken, might be missing a name or parent name for some reason. Can you try to boot with DEBUG enabled so you get pr_debug:s out and see which clock is being initialized during the crash? ... [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: core_d18_ck [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_mux_fck [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_fck [0.00] Unable to handle kernel NULL pointer dereference at virtual address ... We really should be registering the clocks lazily as needed BTW. That leaves out the dependency to DEBUG_LL for seeing any kind of decent error messages during the booting. Regards, Tony Hey Tony, Can you retry with the branch? I just pushed one patch there, seems the parents for the vlynq_mux_fck were somewhat broken (there are holes in the valid mux values list, which hasn't happened with any other mux-clock so far.) If this works, I will rework the series a bit and send v2 out. Alternatively I need to add extra debug info. -Tero -- 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 7/7] v4l: ti-vpe: Add crop support in VPE driver
Hi, On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote: Hi Archit! On 03/03/2014 08:33 AM, Archit Taneja wrote: Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type. For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the whole image itself, hence making crop dimensions same as the pix dimensions. Setting the crop successfully should result in re-configuration of those registers which are affected when either source or destination dimensions change, set_srcdst_params() is called for this purpose. Some standard crop parameter checks are done in __vpe_try_crop(). Please use the selection ops instead: if you implement cropping with those then you'll support both the selection API and the old cropping API will be implemented by the v4l2 core using the selection ops. Two for the price of one... Thanks for the feedback. I'll use selection ops here. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/8] ARM: dts: omap3-overo: Use complete poweroff
On 02/27/2014 10:07 PM, Nishanth Menon wrote: > +devicetree list. > > On 02/27/2014 02:48 PM, Florian Vaussard wrote: >> On 02/27/2014 09:38 PM, Nishanth Menon wrote: >>> On 02/27/2014 02:30 PM, Florian Vaussard wrote: Currently, the TWL4030 PMIC does not completely poweroff the processor. Commit b0fc1da4d0359d3cce8f12e0f014aed0704ae202 introduced the necessary binding to do this, so use it. Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi index aea64c0..018e1e0 100644 --- a/arch/arm/boot/dts/omap3-overo.dtsi +++ b/arch/arm/boot/dts/omap3-overo.dtsi @@ -73,6 +73,11 @@ codec { }; }; + + twl_power: power { + compatible = "ti,twl4030-power"; + ti,use_poweroff; + }; }; }; >>> Urrgh.. this slipped past.. :( >>> >>> ti,system-power-controller is traditionally used for other PMICs from >>> TI to indicate that poweroff functionality will be provided by the >>> PMIC driver. similar approach is taken by Maxim as well.. I know the >>> commit introducing the binding has been around for long, but >>> considering that we do not have a single dts using this yet, should we >>> consider adding "ti,system-power-controller"(as against removing >>> ti,use_poweroff - so that older down stream dtbs still work) and using >>> it in the new code? >>> >> >> It does make sense, so I am not against it. My only concern is that I >> find the name to be slightly less easy to understand, but I can live >> with it :-) > :) > >> >> I do not remember if DT maintainers came up with a clear policy to >> deprecate a binding. > I dont think we can depreciate a binding [1] - as you mentioned - > renaming the property is probably what is appropriate, but introducing > a new one which has the same behavior as the old one does'nt seem > covered either.. considering potential downstream kernel usage, I'd > suggest additional property inline with today's convention. > Ok, so I will drop this patch from the series, so that the other patches can hopefully go into 3.15. I will address this issue separately. Thank you for pointing out this binding issue. 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
[PATCH v3 7/7] ARM: dts: omap3-tobi: Add AT24C01 EEPROM
Add the AT24C01 EEPROM node populated on most Gumstix expansion board. Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi index caddb8c..b5e1b15 100644 --- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi +++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi @@ -60,6 +60,13 @@ pinctrl-names = "default"; pinctrl-0 = <&i2c3_pins>; clock-frequency = <10>; + + /* optional 1K EEPROM with revision information */ + eeprom@51 { + compatible = "atmel,24c01"; + reg = <0x51>; + pagesize = <8>; + }; }; &mmc3 { -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] ARM: dts: omap3-tobi: Use include file omap-gpmc-smsc9221
Use the timings provided by omap-gpmc-smsc9221. This does not change the timings, but it avoids code duplication. Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 30 +++--- 1 file changed, 3 insertions(+), 27 deletions(-) diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi index da7d85b..caddb8c 100644 --- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi +++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi @@ -44,39 +44,15 @@ }; }; +#include "omap-gpmc-smsc9221.dtsi" + &gpmc { ranges = <5 0 0x2c00 0x100>;/* CS5 */ - ethernet@5,0 { - compatible = "smsc,lan9221", "smsc,lan9115"; + ethernet@gpmc { reg = <5 0 0xff>; - bank-width = <2>; - - gpmc,mux-add-data; - gpmc,cs-on-ns = <0>; - gpmc,cs-rd-off-ns = <42>; - gpmc,cs-wr-off-ns = <36>; - gpmc,adv-on-ns = <6>; - gpmc,adv-rd-off-ns = <12>; - gpmc,adv-wr-off-ns = <12>; - gpmc,oe-on-ns = <0>; - gpmc,oe-off-ns = <42>; - gpmc,we-on-ns = <0>; - gpmc,we-off-ns = <36>; - gpmc,rd-cycle-ns = <60>; - gpmc,wr-cycle-ns = <54>; - gpmc,access-ns = <36>; - gpmc,page-burst-access-ns = <0>; - gpmc,bus-turnaround-ns = <0>; - gpmc,cycle2cycle-delay-ns = <0>; - gpmc,wr-data-mux-bus-ns = <18>; - gpmc,wr-access-ns = <42>; - gpmc,cycle2cycle-samecsen; - gpmc,cycle2cycle-diffcsen; - interrupt-parent = <&gpio6>; interrupts = <16 IRQ_TYPE_LEVEL_LOW>; /* GPIO 176 */ - reg-io-width = <4>; }; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] ARM: dts: omap3-overo: Enable WiFi/BT combo
MMC2 is used by the on-board WiFi module populated on some boards (based on Marvell Libertas 8688 SDIO). The Bluetooth is connected to UART2. Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 8 arch/arm/boot/dts/omap3-overo-tobi.dts | 8 arch/arm/boot/dts/omap3-overo.dtsi | 58 3 files changed, 74 insertions(+) diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts index 966b5c9..2033b52 100644 --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts @@ -20,3 +20,11 @@ compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap36xx", "ti,omap3"; }; +&omap3_pmx_core2 { + w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { + pinctrl-single,pins = < + OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) /* etk_d2.gpio_16 */ + >; + }; +}; + diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts b/arch/arm/boot/dts/omap3-overo-tobi.dts index de5653e..21de31d 100644 --- a/arch/arm/boot/dts/omap3-overo-tobi.dts +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts @@ -20,3 +20,11 @@ compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"; }; +&omap3_pmx_core2 { + w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { + pinctrl-single,pins = < + OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) /* etk_d2.gpio_16 */ + >; + }; +}; + diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi index aea64c0..07467cc 100644 --- a/arch/arm/boot/dts/omap3-overo.dtsi +++ b/arch/arm/boot/dts/omap3-overo.dtsi @@ -29,6 +29,38 @@ ti,mcbsp = <&mcbsp2>; ti,codec = <&twl_audio>; }; + + /* Regulator to trigger the nPoweron signal of the Wifi module */ + w3cbw003c_npoweron: regulator-w3cbw003c-npoweron { + compatible = "regulator-fixed"; + regulator-name = "regulator-w3cbw003c-npoweron"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + gpio = <&gpio2 22 GPIO_ACTIVE_HIGH>;/* gpio_54: nPoweron */ + enable-active-high; + }; + + /* Regulator to trigger the nReset signal of the Wifi module */ + w3cbw003c_wifi_nreset: regulator-w3cbw003c-wifi-nreset { + pinctrl-names = "default"; + pinctrl-0 = <&w3cbw003c_pins &w3cbw003c_2_pins>; + compatible = "regulator-fixed"; + regulator-name = "regulator-w3cbw003c-wifi-nreset"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>;/* gpio_16: WiFi nReset */ + startup-delay-us = <1>; + }; + + /* Regulator to trigger the nReset signal of the Bluetooth module */ + w3cbw003c_bt_nreset: regulator-w3cbw003c-bt-nreset { + compatible = "regulator-fixed"; + regulator-name = "regulator-w3cbw003c-bt-nreset"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + gpio = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* gpio_164: BT nReset */ + startup-delay-us = <1>; + }; }; &omap3_pmx_core { @@ -56,6 +88,25 @@ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat3.sdmmc1_dat3 */ >; }; + + mmc2_pins: pinmux_mmc2_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk.sdmmc2_clk */ + OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd.sdmmc2_cmd */ + OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0.sdmmc2_dat0 */ + OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1.sdmmc2_dat1 */ + OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2.sdmmc2_dat2 */ + OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3.sdmmc2_dat3 */ + >; + }; + + /* WiFi/BT combo */ + w3cbw003c_pins: pinmux_w3cbw003c_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x20b4, PIN_OUTPUT | MUX_MODE4) /* gpmc_ncs3.gpio_54 */ + OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4) /* uart3_rts_sd.gpio_164 */ + >; + }; }; &i2c1 { @@ -94,7 +145,14 @@ /* optional on board WiFi
[PATCH v3 5/7] ARM: dts: omap: Add common file for SMSC9221
Some devices (SMSC9217, SMSC9218 and SMSC9221 at least) have better timings, allowing a higher transfer speed. Create a common file with these timings. Performance results with iperf: - omap-gpmc-smsc911x.dtsi => 54.9 Mbps - omap-gpmc-smsc9221.dtsi => 92.7 Mbps Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi | 58 +++ 1 file changed, 58 insertions(+) create mode 100644 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi diff --git a/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi b/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi new file mode 100644 index 000..73e272f --- /dev/null +++ b/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi @@ -0,0 +1,58 @@ +/* + * Common file for GPMC connected smsc9221 on omaps + * + * Compared to smsc911x, smsc9221 (and others like smsc9217 + * or smsc 9218) has faster timings, leading to higher + * bandwidth. + * + * Note that the board specifc DTS file needs to specify + * ranges, pinctrl, reg, interrupt parent and interrupts. + */ + +/ { + vddvario: regulator-vddvario { + compatible = "regulator-fixed"; + regulator-name = "vddvario"; + regulator-always-on; + }; + + vdd33a: regulator-vdd33a { + compatible = "regulator-fixed"; + regulator-name = "vdd33a"; + regulator-always-on; + }; +}; + +&gpmc { + ethernet@gpmc { + compatible = "smsc,lan9221","smsc,lan9115"; + bank-width = <2>; + + gpmc,mux-add-data; + gpmc,cs-on-ns = <0>; + gpmc,cs-rd-off-ns = <42>; + gpmc,cs-wr-off-ns = <36>; + gpmc,adv-on-ns = <6>; + gpmc,adv-rd-off-ns = <12>; + gpmc,adv-wr-off-ns = <12>; + gpmc,oe-on-ns = <0>; + gpmc,oe-off-ns = <42>; + gpmc,we-on-ns = <0>; + gpmc,we-off-ns = <36>; + gpmc,rd-cycle-ns = <60>; + gpmc,wr-cycle-ns = <54>; + gpmc,access-ns = <36>; + gpmc,page-burst-access-ns = <0>; + gpmc,bus-turnaround-ns = <0>; + gpmc,cycle2cycle-delay-ns = <0>; + gpmc,wr-data-mux-bus-ns = <18>; + gpmc,wr-access-ns = <42>; + gpmc,cycle2cycle-samecsen; + gpmc,cycle2cycle-diffcsen; + + vddvario-supply = <&vddvario>; + vdd33a-supply = <&vdd33a>; + reg-io-width = <4>; + smsc,save-mac-address; + }; +}; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] ARM: dts: omap3-overo: Add missing pinctrl
Add missing pinctrl entries for: - i2c1 - mmc1 Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo.dtsi | 40 +- 1 file changed, 31 insertions(+), 9 deletions(-) diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi index 5970999..aea64c0 100644 --- a/arch/arm/boot/dts/omap3-overo.dtsi +++ b/arch/arm/boot/dts/omap3-overo.dtsi @@ -31,7 +31,36 @@ }; }; +&omap3_pmx_core { + uart3_pins: pinmux_uart3_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ + OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */ + >; + }; + + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; + + mmc1_pins: pinmux_mmc1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */ + OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_cmd.sdmmc1_cmd */ + OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat0.sdmmc1_dat0 */ + OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat1.sdmmc1_dat1 */ + OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat2.sdmmc1_dat2 */ + OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc1_dat3.sdmmc1_dat3 */ + >; + }; +}; + &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <260>; twl: twl@48 { @@ -57,6 +86,8 @@ /* on board microSD slot */ &mmc1 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins>; vmmc-supply = <&vmmc1>; bus-width = <4>; }; @@ -79,15 +110,6 @@ power = <50>; }; -&omap3_pmx_core { - uart3_pins: pinmux_uart3_pins { - pinctrl-single,pins = < - 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ - 0x170 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx */ - >; - }; -}; - &uart3 { pinctrl-names = "default"; pinctrl-0 = <&uart3_pins>; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] ARM: dts: Better support for Gumstix Overo (for 3.15?)
Hello Tony, Benoit, This is the third version of my Overo series. No major changes since v2, I just dropped the patch related to the "ti,use_poweroff" binding, and will address this issue later. Most patches are pretty obvious. Patch 5 adds some specific timings for LAN9221 into a generic file. By using shorter timing, it is possible to double the Ethernet bandwidth. Thus is may interest people using a similar chip. I tested this series with both the OMAP35xx Overo and the OMAP36xx Overo. Wifi is functional, HSUSB works. Note: I hope that this can go into 3.15, since the patches were first posted before the 3.14 merge window. They add a number of useful peripherals, so this would be much appreciated. Regards, Florian Florian Vaussard (7): ARM: dts: omap3-tobi: Add missing pinctrl ARM: dts: omap3-overo: Add missing pinctrl ARM: dts: omap3-overo: Enable WiFi/BT combo ARM: dts: omap3-overo: Add HSUSB PHY ARM: dts: omap: Add common file for SMSC9221 ARM: dts: omap3-tobi: Use include file omap-gpmc-smsc9221 ARM: dts: omap3-tobi: Add AT24C01 EEPROM arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi | 58 +++ arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 24 + arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 48 - arch/arm/boot/dts/omap3-overo-tobi.dts | 24 + arch/arm/boot/dts/omap3-overo.dtsi | 138 +++-- 5 files changed, 258 insertions(+), 34 deletions(-) create mode 100644 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY
Add the High-Speed USB PHY. Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++ arch/arm/boot/dts/omap3-overo-tobi.dts | 16 ++ arch/arm/boot/dts/omap3-overo.dtsi | 44 3 files changed, 76 insertions(+) diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts index 2033b52..eb93e3a 100644 --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts @@ -21,6 +21,22 @@ }; &omap3_pmx_core2 { + pinctrl-names = "default"; + pinctrl-0 = < + &hsusb2_2_pins + >; + + hsusb2_2_pins: pinmux_hsusb2_2_pins { + pinctrl-single,pins = < + OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) /* etk_d10.hsusb2_clk */ + OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) /* etk_d11.hsusb2_stp */ + OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d12.hsusb2_dir */ + OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d13.hsusb2_nxt */ + OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d14.hsusb2_data0 */ + OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d15.hsusb2_data1 */ + >; + }; + w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { pinctrl-single,pins = < OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) /* etk_d2.gpio_16 */ diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts b/arch/arm/boot/dts/omap3-overo-tobi.dts index 21de31d..e77be26 100644 --- a/arch/arm/boot/dts/omap3-overo-tobi.dts +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts @@ -21,6 +21,22 @@ }; &omap3_pmx_core2 { + pinctrl-names = "default"; + pinctrl-0 = < + &hsusb2_2_pins + >; + + hsusb2_2_pins: pinmux_hsusb2_2_pins { + pinctrl-single,pins = < + OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) /* etk_d10.hsusb2_clk */ + OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) /* etk_d11.hsusb2_stp */ + OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d12.hsusb2_dir */ + OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d13.hsusb2_nxt */ + OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d14.hsusb2_data0 */ + OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3)/* etk_d15.hsusb2_data1 */ + >; + }; + w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { pinctrl-single,pins = < OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) /* etk_d2.gpio_16 */ diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi index 07467cc..8f810db 100644 --- a/arch/arm/boot/dts/omap3-overo.dtsi +++ b/arch/arm/boot/dts/omap3-overo.dtsi @@ -30,6 +30,24 @@ ti,codec = <&twl_audio>; }; + /* HS USB Port 2 Power */ + hsusb2_power: hsusb2_power_reg { + compatible = "regulator-fixed"; + regulator-name = "hsusb2_vbus"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + gpio = <&gpio6 8 0>;/* gpio_168: vbus enable */ + startup-delay-us = <7>; + enable-active-high; + }; + + /* HS USB Host PHY on PORT 2 */ + hsusb2_phy: hsusb2_phy { + compatible = "usb-nop-xceiv"; + reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>; /* gpio_183 */ + vcc-supply = <&hsusb2_power>; + }; + /* Regulator to trigger the nPoweron signal of the Wifi module */ w3cbw003c_npoweron: regulator-w3cbw003c-npoweron { compatible = "regulator-fixed"; @@ -64,6 +82,11 @@ }; &omap3_pmx_core { + pinctrl-names = "default"; + pinctrl-0 = < + &hsusb2_pins + >; + uart3_pins: pinmux_uart3_pins { pinctrl-single,pins = < OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ @@ -107,6 +130,19 @@ OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4) /* uart3_rts_sd.gpio_164 */ >; }; + + hsusb2_pins: pinmux_hsusb2_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi1_cs3.hsusb2_data2 */ +
[PATCH v3 1/7] ARM: dts: omap3-tobi: Add missing pinctrl
Add missing pinctrl entries: - i2c3 Signed-off-by: Florian Vaussard --- arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi index 4edc013..da7d85b 100644 --- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi +++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi @@ -35,6 +35,15 @@ }; }; +&omap3_pmx_core { + i2c3_pins: pinmux_i2c3_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0) /* i2c3_scl.i2c3_scl */ + OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0) /* i2c3_sda.i2c3_sda */ + >; + }; +}; + &gpmc { ranges = <5 0 0x2c00 0x100>;/* CS5 */ @@ -72,6 +81,8 @@ }; &i2c3 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c3_pins>; clock-frequency = <10>; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM
Hi Tony, On 03/01/2014 12:56 AM, Tony Lindgren wrote: > * Roger Quadros [140227 06:21]: >> Hi, >> >> This patchset brings up USB Host ports and Ethernet port on >> the OMAP5 uEVM board. >> >> It also does some cleanup with respect to DT clock binding >> for the mfd/omap-usb-host driver. >> >> Please queue these for -next. >> >> Lee, >> >> I've folded some platform data dependent patches with mfd patches >> so that they don't break functionality when applied individually. >> You can safely pull in all MFD patches (1 to 6). >> >> Tony & Benoit, >> >> Can you please accept patches 7, 8 and 9? > > Are 7, 8 and 9 safe to queue separately from the MFD changes > or do they need to wait for the MFD changes to get merged > first? > They are safe to queue separately. 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
Help needed USB hub disconnected at resume
Hi, I am using the latest stable 3.4.80 kernel with some changes to get the EMAC Phy to initialise correctly after a suspend/resume. The platform is AM3517 with most of the system working nice and smoothly. I have 1 issue though and need some advice/help to get the system to use the USB hub I have connected to the EHCI controller after a suspend to memory and resume. At boot all is recognised; [1.486816] usbcore: registered new interface driver cdc_ether [1.493255] usbcore: registered new interface driver cdc_ncm [1.499450] usbcore: registered new interface driver qmi_wwan [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.574035] usb usb1: Product: OMAP-EHCI Host Controller [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd [2.585296] usb usb1: SerialNumber: ehci-omap.0 [2.591278] hub 1-0:1.0: USB hub found [2.595306] hub 1-0:1.0: 3 ports detected And I can see everything OK. # lsusb Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. # # # echo mem > /sys/power/state [ 73.736572] PM: Syncing filesystems ... done. [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle [ 73.968872] PM: suspend of devices complete after 170.410 msecs [ 73.975433] PM: late suspend of devices complete after 0.305 msecs [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 [ 83.436737] Could not enter target state in pm_suspend [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs [ 83.450164] PM: early resume of devices complete after 0.274 msecs [ 83.457336] <6>Waiting for PHY clock good... [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 84.771881] PM: resume of devices complete after 1315.185 msecs [ 84.778472] Restarting tasks ... [ 84.782379] usb 1-1: USB disconnect, device number 2 [ 84.790557] done. [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device ermitted [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full # # # lsusb Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # Is there any relevant patch out there that would address the issue that I see ? Kind Regards Marc -- 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: Add support for OMAP4 Gumstix DuoVero/Parlor
Hi Tony, Benoit, On 02/24/2014 06:07 PM, Florian Vaussard wrote: > Gumstix DuoVero is an OMAP4430-based Computer On Module. > Parlor is one of the available expansion board. > > Tested features: > - GPMC ethernet > - HSUSB2 and OTG > - Audio out > - WiFi and Bluetooth (w2cbw0015 SDIO module) > - LED and button > Can this patch go into 3.15? The other one (HDMI support) can wait for the DSS support to be merged, but I would like to give to this DTS a wider exposure to testing opportunities. Regards, Florian > Signed-off-by: Florian Vaussard > --- > .../devicetree/bindings/arm/omap/omap.txt | 3 + > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/omap4-duovero-parlor.dts | 146 > arch/arm/boot/dts/omap4-duovero.dtsi | 252 > + > 4 files changed, 402 insertions(+) > create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts > create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi > > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt > b/Documentation/devicetree/bindings/arm/omap/omap.txt > index af9b4a0..95b1372 100644 > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt > @@ -99,6 +99,9 @@ Boards: > - OMAP4 PandaBoard : Low cost community board >compatible = "ti,omap4-panda", "ti,omap4430" > > +- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board > + compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", > "ti,omap4430", "ti,omap4"; > + > - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x >compatible = "ti,omap3-evm", "ti,omap3" > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 0320303..8b23abb 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -215,6 +215,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ > omap3-igep0020.dtb \ > omap3-igep0030.dtb \ > omap3-zoom3.dtb \ > + omap4-duovero-parlor.dtb \ > omap4-panda.dtb \ > omap4-panda-a4.dtb \ > omap4-panda-es.dtb \ > diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts > b/arch/arm/boot/dts/omap4-duovero-parlor.dts > new file mode 100644 > index 000..96f51d8 > --- /dev/null > +++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts > @@ -0,0 +1,146 @@ > +/* > + * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > +/dts-v1/; > + > +#include "omap4-duovero.dtsi" > + > +#include > + > +/ { > + model = "OMAP4430 Gumstix Duovero on Parlor"; > + compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", > "ti,omap4430", "ti,omap4"; > + > + leds { > + compatible = "gpio-leds"; > + led0 { > + label = "duovero:blue:led0"; > + gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>; /* gpio_122 */ > + linux,default-trigger = "heartbeat"; > + }; > + }; > + > + gpio_keys { > + compatible = "gpio-keys"; > + #address-cells = <1>; > + #size-cells = <0>; > + button0@121 { > + label = "button0"; > + linux,code = ; > + gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;/* gpio_121 */ > + gpio-key,wakeup; > + }; > + }; > +}; > + > +&omap4_pmx_core { > + pinctrl-0 = < > + &led_pins > + &button_pins > + &smsc_pins > + >; > + > + led_pins: pinmux_led_pins { > + pinctrl-single,pins = < > + 0xd6 (PIN_OUTPUT | MUX_MODE3) /* > abe_dmic_din3.gpio_122 */ > + >; > + }; > + > + button_pins: pinmux_button_pins { > + pinctrl-single,pins = < > + 0xd4 (PIN_INPUT_PULLUP | MUX_MODE3) /* > abe_dmic_din2.gpio_121 */ > + >; > + }; > + > + i2c2_pins: pinmux_i2c2_pins { > + pinctrl-single,pins = < > + 0xe6 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c2_scl */ > + 0xe8 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c2_sda */ > + >; > + }; > + > + i2c3_pins: pinmux_i2c3_pins { > + pinctrl-single,pins = < > + 0xea (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c3_scl */ > + 0xec (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c3_sda */ > + >; > + }; > + > + smsc_pins: pinmux_smsc_pins { > + pinctrl-single,pins = < > + 0x28 (PIN_INPUT | MUX_MODE3)/* > gpmc_a20.gpio_44: IRQ */ > + 0x2a (PIN_INPUT_PULLUP | MUX_MODE3)
Re: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm
Hi! > > > Just to convey that is_battery_full is a local function and not generic. > > > You > > > can find similar usage in power_supply_core.c > > > (__power_supply_changed_work) > > > and in other drivers. Isn't it advised to have __ prefixes? > > > > It is static; everybody sees it is local. __ prefix usually means > > something else. > > Agreed, I will remove the __ prefix in next patchset. Meanwhile I would > appreciate if anyone could help me to understand what __ prefix > really means. If you have __foo() and foo(), the __foo() is typically worker function, where foo() provides locking around it etc. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] net: cpsw: fix cpdma rx descriptor leak on down interface
From: Schuyler Patton This patch fixes a CPDMA RX Descriptor leak that occurs after taking the interface down when the CPSW is in Dual MAC mode. Previously the CPSW_ALE port was left open up which causes packets to be received and processed by the RX interrupt handler and were passed to the non active network interface where they were ignored. The fix is for the slave_stop function of the selected interface to disable the respective CPSW_ALE Port from forwarding packets. This blocks traffic from being received on the inactive interface. Signed-off-by: Schuyler Patton Reviewed-by: Felipe Balbi Signed-off-by: Mugunthan V N --- drivers/net/ethernet/ti/cpsw.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 651087b..ffd4d12 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -1164,11 +1164,17 @@ static void cpsw_init_host_port(struct cpsw_priv *priv) static void cpsw_slave_stop(struct cpsw_slave *slave, struct cpsw_priv *priv) { + u32 slave_port; + + slave_port = cpsw_get_slave_port(priv, slave->slave_num); + if (!slave->phy) return; phy_stop(slave->phy); phy_disconnect(slave->phy); slave->phy = NULL; + cpsw_ale_control_set(priv->ale, slave_port, +ALE_PORT_STATE, ALE_PORT_STATE_DISABLE); } static int cpsw_ndo_open(struct net_device *ndev) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY
Hi Florian, On 03/03/2014 11:34 AM, Florian Vaussard wrote: > Add the High-Speed USB PHY. > > Signed-off-by: Florian Vaussard > --- > arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++ > arch/arm/boot/dts/omap3-overo-tobi.dts | 16 ++ > arch/arm/boot/dts/omap3-overo.dtsi | 44 > > 3 files changed, 76 insertions(+) > > diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts > b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts > index 2033b52..eb93e3a 100644 > --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts > +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts > @@ -21,6 +21,22 @@ > }; > > &omap3_pmx_core2 { > + pinctrl-names = "default"; > + pinctrl-0 = < > + &hsusb2_2_pins > + >; > + > + hsusb2_2_pins: pinmux_hsusb2_2_pins { > + pinctrl-single,pins = < > + OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) > /* etk_d10.hsusb2_clk */ > + OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) > /* etk_d11.hsusb2_stp */ > + OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d12.hsusb2_dir */ > + OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d13.hsusb2_nxt */ > + OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d14.hsusb2_data0 */ > + OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d15.hsusb2_data1 */ > + >; > + }; > + > w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { > pinctrl-single,pins = < > OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) > /* etk_d2.gpio_16 */ > diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts > b/arch/arm/boot/dts/omap3-overo-tobi.dts > index 21de31d..e77be26 100644 > --- a/arch/arm/boot/dts/omap3-overo-tobi.dts > +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts > @@ -21,6 +21,22 @@ > }; > > &omap3_pmx_core2 { > + pinctrl-names = "default"; > + pinctrl-0 = < > + &hsusb2_2_pins > + >; > + > + hsusb2_2_pins: pinmux_hsusb2_2_pins { > + pinctrl-single,pins = < > + OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) > /* etk_d10.hsusb2_clk */ > + OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) > /* etk_d11.hsusb2_stp */ > + OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d12.hsusb2_dir */ > + OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d13.hsusb2_nxt */ > + OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d14.hsusb2_data0 */ > + OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | > MUX_MODE3)/* etk_d15.hsusb2_data1 */ > + >; > + }; > + > w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { > pinctrl-single,pins = < > OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) > /* etk_d2.gpio_16 */ > diff --git a/arch/arm/boot/dts/omap3-overo.dtsi > b/arch/arm/boot/dts/omap3-overo.dtsi > index 07467cc..8f810db 100644 > --- a/arch/arm/boot/dts/omap3-overo.dtsi > +++ b/arch/arm/boot/dts/omap3-overo.dtsi > @@ -30,6 +30,24 @@ > ti,codec = <&twl_audio>; > }; > > + /* HS USB Port 2 Power */ > + hsusb2_power: hsusb2_power_reg { > + compatible = "regulator-fixed"; > + regulator-name = "hsusb2_vbus"; > + regulator-min-microvolt = <500>; > + regulator-max-microvolt = <500>; > + gpio = <&gpio6 8 0>;/* gpio_168: > vbus enable */ > + startup-delay-us = <7>; > + enable-active-high; > + }; > + > + /* HS USB Host PHY on PORT 2 */ > + hsusb2_phy: hsusb2_phy { > + compatible = "usb-nop-xceiv"; > + reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>; /* gpio_183 */ > + vcc-supply = <&hsusb2_power>; > + }; > + > /* Regulator to trigger the nPoweron signal of the Wifi module */ > w3cbw003c_npoweron: regulator-w3cbw003c-npoweron { > compatible = "regulator-fixed"; > @@ -64,6 +82,11 @@ > }; > > &omap3_pmx_core { > + pinctrl-names = "default"; > + pinctrl-0 = < > + &hsusb2_pins > + >; > + > uart3_pins: pinmux_uart3_pins { > pinctrl-single,pins = < > OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | > PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ > @@ -107,6 +130,19 @@ > OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4) > /* uart3_rts_sd.gpio_164 */ > >; > }; > + > + hsusb2_pins:
Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling
On Sun, 2014-03-02 at 09:37 -0800, Tony Lindgren wrote: > * Sørensen, Stefan [140301 02:02]: > > On Fri, 2014-02-28 at 09:11 -0800, Tony Lindgren wrote: > > > * Stefan Sørensen [140224 02:12]: > > > > Currently INTC interrupts are handled using handle_level_irq which > > > > will acknowledge the interrupt before running the handler. If a second > > > > interrupt is then asserted and this interrupt is disabled while > > > > running the first handler, the INTC will be brought into an > > > > inconsistent state. > > > > > > Hmm care to explain a bit more here if the second interrupt you're > > > talking about is the same interrupt or any interrupt in the same > > > interrupt bank? Is this limited to GPIO interrupts? > > > > I am seeing it with the cpsw driver on a custom board and on the > > beaglebone. When a tx irq is handled the cpsw irq handler disables both > > the tx and the rx irqs, and if the rx irq was also asserted (i.e. duplex > > traffic), this bug will trigger. Reproducing it is very simple, just hit > > a beaglebone with a flood ping and watch a function trace. > > OK so it's for the same interrupt. And that sounds like a good test :) No, the tx and rx are separate interrupts, but the cpsw driver has a common handler. > > > The reason I'm asking is because of the issues we've seen earlier > > > with not flushing posted writes from the interrupt handlers. In > > > those case the interrupt on the device gets acked too late without > > > the read back call. > > > > I am not very familiar with the low level details of the irq handling, > > but am335x TRM states that a data synchronization barrier should be used > > after the ACK is posted to the INTC, and I don't see that anywhere in > > the code. Is this related? > > Well sort of, except DSB won't do it as it won't guarantee the write > gets to the device on the bus. So a readback from the device is needed > as only the order of reads and writes is guaranteed. I think that we are talking about two different scenarios, what I am seeing is that an interrupt is disabled while active on the INTC. 1. CPSW device asserts TX IRQ 2. CPSW device asserts RX IRQ 3. INTC interrupts CPU, TX IRQ marked as active 4. omap_intc_handle_irq ACKs TX IRQ on the INTC 5. INTC marks RX IRQ as active 6. omap_intc_handle_irq calls cpsw_interrupt 7. cpsw_interrupt disables RX+TX IRQ in CPSW device 8. cpsw_interrupt disables RX+TX IRQ in INTC (the IRQs are masked) 9.. omap_intc_handle_irq sees no unmasked IRQs are pending and returns 10. INTC interrupts CPU, RX IRQ marked as pending 11. omap_intc_handle_irq sees no unmasked IRQs are pending and returns 12. Go to step 10 The problem arises in step 8 where an active IRQ is masked. This will not make it inactive in the INTC but it will be cleared from the pending IRQ registers - this is the register that omap_intc_handle_irq uses to decide which IRQ is active. > A good sanity check would be to find the related interrupt handler(s) > in the cpsw driver that do the write to the cpsw registers to ack > interrupts. > > Then check if there's a readback in the cpsw interrupt handler(s) of > some harmless cpsw register after acking the interrupt(s) and before > doing return IRQ_HANDLED. > > If this fixes things without your patch, then we know it's a driver > issue and there's no need to debug it further :) The missing flush of > posted write usually shows up as a spurious interrupts with no status > in the device, but depending on the driver code handling of spurious > interrupts it may also have other side effects. > > I'm not too familiar with the cpsw driver so I can't do a test patch > without digging into it further sorry. For similar examples, you > may want to grep for "flush posted write" and "OCP barrier" in the > kernel code. I tried this with an assortment of different CPSW registers - no change. Stefan
Re: Help needed USB hub disconnected at resume
Hi Marc, On 03/03/2014 12:04 PM, Marc Murphy wrote: > Hi, > I am using the latest stable 3.4.80 kernel with some changes to get the EMAC > Phy to initialise correctly after a suspend/resume. The platform is AM3517 > with most of the system working nice and smoothly. I have 1 issue though and > need some advice/help to get the system to use the USB hub I have connected > to the EHCI controller after a suspend to memory and resume. > > At boot all is recognised; > > [1.486816] usbcore: registered new interface driver cdc_ether > [1.493255] usbcore: registered new interface driver cdc_ncm > [1.499450] usbcore: registered new interface driver qmi_wwan > [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator > [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller > [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus > number 1 > [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 > [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 > [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [2.574035] usb usb1: Product: OMAP-EHCI Host Controller > [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd > [2.585296] usb usb1: SerialNumber: ehci-omap.0 > [2.591278] hub 1-0:1.0: USB hub found > [2.595306] hub 1-0:1.0: 3 ports detected > > And I can see everything OK. > > # lsusb > Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub > Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. > # > # > # echo mem > /sys/power/state > [ 73.736572] PM: Syncing filesystems ... done. > [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. > [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) > done. > [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle > [ 73.968872] PM: suspend of devices complete after 170.410 msecs > [ 73.975433] PM: late suspend of devices complete after 0.305 msecs > [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs > [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 > [ 83.436737] Could not enter target state in pm_suspend > [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs > [ 83.450164] PM: early resume of devices complete after 0.274 msecs > [ 83.457336] <6>Waiting for PHY clock good... > [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller > [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] > (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) > [ 84.771881] PM: resume of devices complete after 1315.185 msecs > [ 84.778472] Restarting tasks ... > [ 84.782379] usb 1-1: USB disconnect, device number 2 > [ 84.790557] done. > [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz > sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 > Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister > 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device > ermitted > [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz > [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full > # > # > # lsusb > Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > # > > Is there any relevant patch out there that would address the issue that I see > ? Does this happen because of OFF mode? Can you please try the tests with off mode disabled? e.g. mount -t debugfs none /sys/kernel/debug echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode suspend & resume Also please send the output of /sys/kernel/debug/pm_debug/count before suspend and after resume. 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: [PATCH 1/3] mfd: twl6040: Select i2c fast mode as default with regmap patch
On 02/28/2014 05:07 PM, Nishanth Menon wrote: > On 02/28/2014 08:26 AM, Peter Ujfalusi wrote: >> On 02/28/2014 03:30 PM, Nishanth Menon wrote: >>> TWL6030 can do 3.3MHz by default and there are no speed registers to >>> configure. >> >> According to the datasheet the speed of twl6030 is limited to 2.4MHz. I have >> not seen registers or pins to select the speed. As the documentation puts >> this: High-speed mode (limited to 2.4Mbit/s maximum) > > Aye, you are correct, the latest data sheet does show this - i made > the mistake of opening an older spec doc :(.. As a note: I tried first with 3.4MHz bus speed (who reads documentation?) twl6030 was working fine as far as I can tell. But the TRM is really expressing that 2.4MHz is the limit for twl6030. > I do however suggest that you put one of those i2c analyser on the > rail to see what is happening. else, we'd be doing a lot of guessing here. If I would have access to one... >> If I have fast mode configured to the controller, I can still communicate >> with >> twl6040 even if it is set to normal mode. > >> >> I still think that this patch is safe for now. We could try to figure out how >> to increase the i2c speed on the bus for twl6030 and twl6040. This has to be >> done in the same series. > > ?? you mean set i2c bus speed to full speed on PandaBoard? it is > already full speed[1]! No, I was thinking of Fast+ or HighSpeed but I have doubts that it can be done. >> Now after several boots: >> It seams if I set the i2c to 2.4MHz and I can not communicate with twl6040 >> right after cold power on. >> So if the i2c bus is already set to 2.4GHz I can not set the twl6040 ACCCTL >> register. But the content of ACCCTL register seams to be preserved between >> reboots and this is why I saw that the 2.4MHz bus speed might be even >> possible. > > This observation is the key. > > Are you power cycling the regulators for TWL6040 as part of your > shutdown handler? When the mfd driver is removed, yes powers are asked to be turned off but in reality at least vio is always on in all of the boards I have seen. > Did you read the ACCTL register after a reboot to > see if the register contents are still the same as before? Yes I did. after reboot the ACCCTL register is the same in u-boot as I set previously, before the reboot. Disconnect power + Power the board the ACCCTL is as it has been specified in the datasheet. > Based on this observation, I suggest switching [1] to 100KHz. After several power cycle, reboot, cold boot etc. I think we can leave the i2c speed at 400KHz and configure the twl6040 to Fast mode as the first thing when the driver probes or the chip is powering on (regmap patch functionality). I have not seen a single case when this failed on me and the the 4x bandwidth does matter for twl6030 IMHO. > > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap4-panda-common.dtsi#n291 > -- 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
[PATCH v5 3/6] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3 driver in drivers/usb/phy to drivers/phy and also renamed the file to phy-ti-pipe3 since this same driver will be used for SATA PHY and PCIE PHY. Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} | 240 drivers/usb/phy/Kconfig| 11 - drivers/usb/phy/Makefile |1 - 5 files changed, 158 insertions(+), 106 deletions(-) rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index c7a551c..e3ec7d1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -40,6 +40,17 @@ config OMAP_USB2 The USB OTG controller communicates with the comparator using this driver. +config TI_PIPE3 + tristate "TI PIPE3 PHY Driver" + depends on ARCH_OMAP2PLUS || COMPILE_TEST + select GENERIC_PHY + select OMAP_CONTROL_USB + help + Enable this to support the PIPE3 PHY that is part of TI SOCs. This + driver takes care of all the PHY functionality apart from comparator. + This driver interacts with the "OMAP Control PHY Driver" to power + on/off the PHY. + config TWL4030_USB tristate "TWL4030 USB Transceiver Driver" depends on TWL4030_CORE && REGULATOR_TWL4030 && USB_MUSB_OMAP2PLUS diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index b57c253..32e3f94 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -8,4 +8,5 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o +obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-ti-pipe3.c similarity index 54% rename from drivers/usb/phy/phy-omap-usb3.c rename to drivers/phy/phy-ti-pipe3.c index 0c6ba29..67b189d 100644 --- a/drivers/usb/phy/phy-omap-usb3.c +++ b/drivers/phy/phy-ti-pipe3.c @@ -1,5 +1,5 @@ /* - * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP. + * phy-ti-pipe3 - PIPE3 PHY driver. * * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com * This program is free software; you can redistribute it and/or modify @@ -19,10 +19,11 @@ #include #include #include -#include +#include #include #include #include +#include #include #include #include @@ -52,17 +53,34 @@ /* * This is an Empirical value that works, need to confirm the actual - * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status - * to be correctly reflected in the USB3PHY_PLL_STATUS register. + * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status + * to be correctly reflected in the PIPE3PHY_PLL_STATUS register. */ # define PLL_IDLE_TIME 100; -struct usb_dpll_map { +struct pipe3_dpll_params { + u16 m; + u8 n; + u8 freq:3; + u8 sd; + u32 mf; +}; + +struct ti_pipe3 { + void __iomem*pll_ctrl_base; + struct device *dev; + struct device *control_dev; + struct clk *wkupclk; + struct clk *sys_clk; + struct clk *optclk; +}; + +struct pipe3_dpll_map { unsigned long rate; - struct usb_dpll_params params; + struct pipe3_dpll_params params; }; -static struct usb_dpll_map dpll_map[] = { +static struct pipe3_dpll_map dpll_map[] = { {1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */ {1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */ {1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */ @@ -71,7 +89,18 @@ static struct usb_dpll_map dpll_map[] = { {3840, {3125, 47, 4, 20, 92843} }, /* 38.4 MHz */ }; -static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate) +static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset) +{ + return __raw_readl(addr + offset); +} + +static inline void ti_pipe3_writel(void __iomem *addr, unsigned offset, + u32 data) +{ + __raw_writel(data, addr + offset); +} + +static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate) { int i; @@ -83,110 +112,123 @@ static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate) return NULL; } -static int omap_usb3_suspend(struct usb_phy *x, int suspend) +static int ti_pipe3_power_off(struct phy *x) +{ + struct ti_pipe3 *phy = phy_get_drvdata(x); + int val; + int timeout = PLL_IDLE_TIME; + + val = ti_
[PATCH v5 6/6] arm/dts: added dt properties to adapt to the new phy framwork
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt and Documentation/devicetree/bindings/phy/ti-phy.txt. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/omap5.dtsi |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index a72813a..1c68558 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -732,7 +732,8 @@ compatible = "snps,dwc3"; reg = <0x4a03 0x1>; interrupts = ; - usb-phy = <&usb2_phy>, <&usb3_phy>; + phys = <&usb2_phy>, <&usb3_phy>; + phy-names = "usb2-phy", "usb3-phy"; dr_mode = "peripheral"; tx-fifo-resize; }; @@ -749,6 +750,7 @@ compatible = "ti,omap-usb2"; reg = <0x4a084000 0x7c>; ctrl-module = <&omap_control_usb2phy>; + #phy-cells = <0>; }; usb3_phy: usb3phy@4a084400 { @@ -758,6 +760,7 @@ <0x4a084c00 0x40>; reg-names = "phy_rx", "phy_tx", "pll_ctrl"; ctrl-module = <&omap_control_usb3phy>; + #phy-cells = <0>; }; }; -- 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 v5 5/6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/. Also removed the unused members of struct omap_usb (after phy-omap-pipe3 started using it's own header file) Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/phy-omap-usb2.c |2 +- include/linux/{usb => phy}/omap_usb.h |3 --- 2 files changed, 1 insertion(+), 4 deletions(-) rename include/linux/{usb => phy}/omap_usb.h (95%) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index 705af5a..9c3f056 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -21,7 +21,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h similarity index 95% rename from include/linux/usb/omap_usb.h rename to include/linux/phy/omap_usb.h index 6ae2936..19d343c3 100644 --- a/include/linux/usb/omap_usb.h +++ b/include/linux/phy/omap_usb.h @@ -33,13 +33,10 @@ struct usb_dpll_params { struct omap_usb { struct usb_phy phy; struct phy_companion*comparator; - void __iomem*pll_ctrl_base; struct device *dev; struct device *control_dev; struct clk *wkupclk; - struct clk *sys_clk; struct clk *optclk; - u8 is_suspended:1; }; #definephy_to_omapusb(x) container_of((x), struct omap_usb, phy) -- 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 v5 0/6] Make dwc3 use Generic PHY Framework
Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3 should be programmed. While this can be considered as a temporary fix, a long term solution would be to add 'nop' PHY for platforms that does not have programmable PHY. Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to be used for SATA and PCIE too. Changes from v4: (sending the entire patch series again) * check the return values of phy_init and phy_power_on * print errors if power_on or power_off of PHY fails. Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) * avoided using quirks and rely on the return values of PHY APIs to find the presence of PHY. Changes from v2: * added a couple of fixes. One is invoking phy_resume after phy_init and the other is power off phy in error patch * used quirks to identify if a particular platform does not have PHYs * removed using separate header for pipe3 driver and also removed all referencs to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers. Changes from v1: * The logic in which the driver detects the presence of PHYs has changed. * patch ordering has changed * udelay is replaced with usleep_range * A patch to remove set_suspend callback which was deferred from Generic PHY Framework series has been included. Kishon Vijay Abraham I (6): usb: dwc3: core: support optional PHYs usb: dwc3: adapt dwc3 core to use Generic PHY Framework drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ arm/dts: added dt properties to adapt to the new phy framwork Documentation/devicetree/bindings/usb/dwc3.txt |6 +- arch/arm/boot/dts/omap5.dtsi |5 +- drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-omap-usb2.c| 27 +-- .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} | 240 drivers/usb/dwc3/core.c| 116 +++--- drivers/usb/dwc3/core.h|7 + drivers/usb/phy/Kconfig| 11 - drivers/usb/phy/Makefile |1 - include/linux/{usb => phy}/omap_usb.h |3 - 11 files changed, 264 insertions(+), 164 deletions(-) rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%) rename include/linux/{usb => phy}/omap_usb.h (95%) -- 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 v5 4/6] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
Now that omap-usb2 is adapted to the new generic PHY framework, *set_suspend* ops can be removed from omap-usb2 driver. Signed-off-by: Kishon Vijay Abraham I Acked-by: Felipe Balbi Reviewed-by: Sylwester Nawrocki --- drivers/phy/phy-omap-usb2.c | 25 - 1 file changed, 25 deletions(-) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index 7699752..705af5a 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -98,28 +98,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg, return 0; } -static int omap_usb2_suspend(struct usb_phy *x, int suspend) -{ - struct omap_usb *phy = phy_to_omapusb(x); - int ret; - - if (suspend && !phy->is_suspended) { - omap_control_usb_phy_power(phy->control_dev, 0); - pm_runtime_put_sync(phy->dev); - phy->is_suspended = 1; - } else if (!suspend && phy->is_suspended) { - ret = pm_runtime_get_sync(phy->dev); - if (ret < 0) { - dev_err(phy->dev, "get_sync failed with err %d\n", ret); - return ret; - } - omap_control_usb_phy_power(phy->control_dev, 1); - phy->is_suspended = 0; - } - - return 0; -} - static int omap_usb_power_off(struct phy *x) { struct omap_usb *phy = phy_get_drvdata(x); @@ -173,7 +151,6 @@ static int omap_usb2_probe(struct platform_device *pdev) phy->phy.dev= phy->dev; phy->phy.label = "omap-usb2"; - phy->phy.set_suspend= omap_usb2_suspend; phy->phy.otg= otg; phy->phy.type = USB_PHY_TYPE_USB2; @@ -190,8 +167,6 @@ static int omap_usb2_probe(struct platform_device *pdev) } phy->control_dev = &control_pdev->dev; - - phy->is_suspended = 1; omap_control_usb_phy_power(phy->control_dev, 0); otg->set_host = omap_usb_set_host; -- 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 v5 1/6] usb: dwc3: core: support optional PHYs
Since PHYs for dwc3 is optional (not all SoCs having PHYs for DWC3 should be programmed), do not return from probe if the USB PHY library returns -ENODEV as that indicates the platform does not have a programmable PHY. While this can be considered as a temporary fix, a long term solution would be to add 'nop' PHY for platforms that does not have programmable PHY. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Roger Quadros --- drivers/usb/dwc3/core.c | 34 ++ 1 file changed, 14 insertions(+), 20 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 7d0cb34..225a4d6 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -529,32 +529,26 @@ static int dwc3_probe(struct platform_device *pdev) if (IS_ERR(dwc->usb2_phy)) { ret = PTR_ERR(dwc->usb2_phy); - - /* -* if -ENXIO is returned, it means PHY layer wasn't -* enabled, so it makes no sense to return -EPROBE_DEFER -* in that case, since no PHY driver will ever probe. -*/ - if (ret == -ENXIO) + if (ret == -ENXIO || ret == -ENODEV) { + dwc->usb2_phy = NULL; + } else if (ret == -EPROBE_DEFER) { return ret; - - dev_err(dev, "no usb2 phy configured\n"); - return -EPROBE_DEFER; + } else { + dev_err(dev, "no usb2 phy configured\n"); + return ret; + } } if (IS_ERR(dwc->usb3_phy)) { ret = PTR_ERR(dwc->usb3_phy); - - /* -* if -ENXIO is returned, it means PHY layer wasn't -* enabled, so it makes no sense to return -EPROBE_DEFER -* in that case, since no PHY driver will ever probe. -*/ - if (ret == -ENXIO) + if (ret == -ENXIO || ret == -ENODEV) { + dwc->usb3_phy = NULL; + } else if (ret == -EPROBE_DEFER) { return ret; - - dev_err(dev, "no usb3 phy configured\n"); - return -EPROBE_DEFER; + } else { + dev_err(dev, "no usb3 phy configured\n"); + return ret; + } } dwc->xhci_resources[0].start = res->start; -- 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 v5 2/6] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit, power_on and power_off the following APIs are used phy_init(), phy_exit(), phy_power_on() and phy_power_off(). However using the old USB phy library wont be removed till the PHYs of all other SoC's using dwc3 core is adapted to the Generic PHY Framework. Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/usb/dwc3.txt |6 +- drivers/usb/dwc3/core.c| 86 +--- drivers/usb/dwc3/core.h|7 ++ 3 files changed, 89 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index e807635..471366d 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,11 +6,13 @@ Required properties: - compatible: must be "snps,dwc3" - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. + +Optional properties: - usb-phy : array of phandle for the PHY device. The first element in the array is expected to be a handle to the USB2/HS PHY and the second element is expected to be a handle to the USB3/SS PHY - -Optional properties: + - phys: from the *Generic PHY* bindings + - phy-names: from the *Generic PHY* bindings - tx-fifo-resize: determines if the FIFO *has* to be reallocated. This is usually a subnode to DWC3 glue to which it is connected. diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 225a4d6..497234a 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -61,9 +61,10 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode) * dwc3_core_soft_reset - Issues core soft reset and PHY reset * @dwc: pointer to our context structure */ -static void dwc3_core_soft_reset(struct dwc3 *dwc) +static int dwc3_core_soft_reset(struct dwc3 *dwc) { u32 reg; + int ret; /* Before Resetting PHY, put Core in Reset */ reg = dwc3_readl(dwc->regs, DWC3_GCTL); @@ -82,6 +83,15 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc) usb_phy_init(dwc->usb2_phy); usb_phy_init(dwc->usb3_phy); + ret = phy_init(dwc->usb2_generic_phy); + if (ret < 0) + return ret; + + ret = phy_init(dwc->usb3_generic_phy); + if (ret < 0) { + phy_exit(dwc->usb2_generic_phy); + return ret; + } mdelay(100); /* Clear USB3 PHY reset */ @@ -100,6 +110,8 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc) reg = dwc3_readl(dwc->regs, DWC3_GCTL); reg &= ~DWC3_GCTL_CORESOFTRESET; dwc3_writel(dwc->regs, DWC3_GCTL, reg); + + return 0; } /** @@ -381,7 +393,9 @@ static int dwc3_core_init(struct dwc3 *dwc) cpu_relax(); } while (true); - dwc3_core_soft_reset(dwc); + ret = dwc3_core_soft_reset(dwc); + if (ret) + goto err0; reg = dwc3_readl(dwc->regs, DWC3_GCTL); reg &= ~DWC3_GCTL_SCALEDOWN_MASK; @@ -446,6 +460,8 @@ err2: err1: usb_phy_shutdown(dwc->usb2_phy); usb_phy_shutdown(dwc->usb3_phy); + phy_exit(dwc->usb2_generic_phy); + phy_exit(dwc->usb3_generic_phy); err0: return ret; @@ -453,14 +469,12 @@ err0: static void dwc3_core_exit(struct dwc3 *dwc) { - if (!IS_ERR(dwc->usb2_phy)) - usb_phy_shutdown(dwc->usb2_phy); - if (!IS_ERR(dwc->usb3_phy)) - usb_phy_shutdown(dwc->usb3_phy); - dwc3_free_scratch_buffers(dwc); usb_phy_shutdown(dwc->usb2_phy); usb_phy_shutdown(dwc->usb3_phy); + phy_exit(dwc->usb2_generic_phy); + phy_exit(dwc->usb3_generic_phy); + } #define DWC3_ALIGN_MASK(16 - 1) @@ -551,6 +565,32 @@ static int dwc3_probe(struct platform_device *pdev) } } + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy"); + if (IS_ERR(dwc->usb2_generic_phy)) { + ret = PTR_ERR(dwc->usb2_generic_phy); + if (ret == -ENOSYS || ret == -ENODEV) { + dwc->usb2_generic_phy = NULL; + } else if (ret == -EPROBE_DEFER) { + return ret; + } else { + dev_err(dev, "no usb2 phy configured\n"); + return ret; + } + } + + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy"); + if (IS_ERR(dwc->usb3_generic_phy)) { + ret = PTR_ERR(dwc->usb3_generic_phy); + if (ret == -ENOSYS || ret == -ENODEV) { + dwc->usb3_generic_phy = NULL; + } else if (ret == -EPROBE_DEFER) { + return ret; + } else { + dev_err(dev, "no usb3 phy configured\n"); + re
[PATCH] OMAPDSS: convert pixel clock to common videomode style
omapdss has its own video-timings struct, but we want to move the common videomode. The first step is to change the omapdss's pixelclock unit from kHz to Hz. Also, omapdss uses "pixel_clock" field name, whereas the common videomode uses "pixelclock" field name. This patch changes the field name also, as that makes it easy to spot any non-converted pixel_clock uses. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_connector.c | 6 +- .../video/omap2/displays-new/connector-analog-tv.c | 2 +- drivers/video/omap2/displays-new/connector-dvi.c | 2 +- drivers/video/omap2/displays-new/connector-hdmi.c | 2 +- drivers/video/omap2/displays-new/panel-dsi-cm.c| 2 +- .../omap2/displays-new/panel-lgphilips-lb035q02.c | 2 +- .../omap2/displays-new/panel-nec-nl8048hl11.c | 4 +- .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 2 +- .../omap2/displays-new/panel-sony-acx565akm.c | 2 +- .../omap2/displays-new/panel-tpo-td028ttec1.c | 2 +- .../omap2/displays-new/panel-tpo-td043mtea1.c | 2 +- drivers/video/omap2/dss/dispc.c| 8 +-- drivers/video/omap2/dss/display-sysfs.c| 4 +- drivers/video/omap2/dss/display.c | 4 +- drivers/video/omap2/dss/dpi.c | 25 drivers/video/omap2/dss/dsi.c | 16 ++--- drivers/video/omap2/dss/hdmi4.c| 9 +-- drivers/video/omap2/dss/hdmi_common.c | 74 +++--- drivers/video/omap2/dss/sdi.c | 15 ++--- drivers/video/omap2/dss/venc.c | 4 +- drivers/video/omap2/dss/venc_panel.c | 2 +- drivers/video/omap2/omapfb/omapfb-main.c | 8 +-- include/video/omapdss.h| 4 +- 23 files changed, 100 insertions(+), 101 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c index 912759daf562..86f4ead0441d 100644 --- a/drivers/gpu/drm/omapdrm/omap_connector.c +++ b/drivers/gpu/drm/omapdrm/omap_connector.c @@ -37,7 +37,7 @@ struct omap_connector { void copy_timings_omap_to_drm(struct drm_display_mode *mode, struct omap_video_timings *timings) { - mode->clock = timings->pixel_clock; + mode->clock = timings->pixelclock / 1000; mode->hdisplay = timings->x_res; mode->hsync_start = mode->hdisplay + timings->hfp; @@ -68,7 +68,7 @@ void copy_timings_omap_to_drm(struct drm_display_mode *mode, void copy_timings_drm_to_omap(struct omap_video_timings *timings, struct drm_display_mode *mode) { - timings->pixel_clock = mode->clock; + timings->pixelclock = mode->clock * 1000; timings->x_res = mode->hdisplay; timings->hfp = mode->hsync_start - mode->hdisplay; @@ -220,7 +220,7 @@ static int omap_connector_mode_valid(struct drm_connector *connector, if (!r) { /* check if vrefresh is still valid */ new_mode = drm_mode_duplicate(dev, mode); - new_mode->clock = timings.pixel_clock; + new_mode->clock = timings.pixelclock / 1000; new_mode->vrefresh = 0; if (mode->vrefresh == drm_mode_vrefresh(new_mode)) ret = MODE_OK; diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c b/drivers/video/omap2/displays-new/connector-analog-tv.c index ccd9073f706f..27f33ef8fca1 100644 --- a/drivers/video/omap2/displays-new/connector-analog-tv.c +++ b/drivers/video/omap2/displays-new/connector-analog-tv.c @@ -31,7 +31,7 @@ struct panel_drv_data { static const struct omap_video_timings tvc_pal_timings = { .x_res = 720, .y_res = 574, - .pixel_clock= 13500, + .pixelclock = 1350, .hsw= 64, .hfp= 12, .hbp= 68, diff --git a/drivers/video/omap2/displays-new/connector-dvi.c b/drivers/video/omap2/displays-new/connector-dvi.c index b6c50904038e..d18e4b8c0731 100644 --- a/drivers/video/omap2/displays-new/connector-dvi.c +++ b/drivers/video/omap2/displays-new/connector-dvi.c @@ -23,7 +23,7 @@ static const struct omap_video_timings dvic_default_timings = { .x_res = 640, .y_res = 480, - .pixel_clock= 23500, + .pixelclock = 2350, .hfp= 48, .hsw= 32, diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c b/drivers/video/omap2/displays-new/connector-hdmi.c index 9abe2c039ae9..9393e2d6473d 100644 --- a/drivers/video/omap2/displays-new/connector-hdmi.c +++ b/drivers/video/omap2/displays-new/connector-hdmi.c @@ -21,7 +21,7 @@ static const struct omap_video_timings hdmic_default_timings = { .x_res = 640, .y_res = 480, - .pixel_clock= 25175, + .pixelclock = 25175000, .hsw
RE: [PATCH 5/7] v4l: ti-vpe: Allow usage of smaller images
Hi Archit, > From: Archit Taneja [mailto:arc...@ti.com] > Sent: Monday, March 03, 2014 8:33 AM > > The minimum width and height for VPE input/output was kept as 128 > pixels. VPE doesn't have a constraint on the image height, it requires > the image width to be atleast 16 bytes. "16 bytes" - shouldn't it be pixels? (also "at least" :) ) I can correct it when applying the patch if the above is the case. > Change the minimum supported dimensions to 32x32. This allows us to de- > interlace qcif content. A smaller image size than 32x32 didn't make > much sense, so stopped at this. > > Signed-off-by: Archit Taneja Best wishes, -- Kamil Debski Samsung R&D Institute Poland > --- > drivers/media/platform/ti-vpe/vpe.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/platform/ti-vpe/vpe.c > b/drivers/media/platform/ti-vpe/vpe.c > index 915029b..3a610a6 100644 > --- a/drivers/media/platform/ti-vpe/vpe.c > +++ b/drivers/media/platform/ti-vpe/vpe.c > @@ -49,8 +49,8 @@ > #define VPE_MODULE_NAME "vpe" > > /* minimum and maximum frame sizes */ > -#define MIN_W128 > -#define MIN_H128 > +#define MIN_W32 > +#define MIN_H32 > #define MAX_W1920 > #define MAX_H1080 > > -- > 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help needed USB hub disconnected at resume
On 03/03/14 13:06, Roger Quadros wrote: > Hi Marc, > > On 03/03/2014 12:04 PM, Marc Murphy wrote: >> Hi, >> I am using the latest stable 3.4.80 kernel with some changes to get the EMAC >> Phy to initialise correctly after a suspend/resume. The platform is AM3517 >> with most of the system working nice and smoothly. I have 1 issue though and >> need some advice/help to get the system to use the USB hub I have connected >> to the EHCI controller after a suspend to memory and resume. >> >> At boot all is recognised; >> >> [1.486816] usbcore: registered new interface driver cdc_ether >> [1.493255] usbcore: registered new interface driver cdc_ncm >> [1.499450] usbcore: registered new interface driver qmi_wwan >> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver >> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator >> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller >> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus >> number 1 >> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 >> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 >> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 >> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, >> SerialNumber=1 >> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller >> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd >> [2.585296] usb usb1: SerialNumber: ehci-omap.0 >> [2.591278] hub 1-0:1.0: USB hub found >> [2.595306] hub 1-0:1.0: 3 ports detected >> >> And I can see everything OK. >> >> # lsusb >> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub >> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. >> # >> # >> # echo mem > /sys/power/state >> [ 73.736572] PM: Syncing filesystems ... done. >> [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. >> [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) >> done. >> [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle >> [ 73.968872] PM: suspend of devices complete after 170.410 msecs >> [ 73.975433] PM: late suspend of devices complete after 0.305 msecs >> [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs >> [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 >> [ 83.436737] Could not enter target state in pm_suspend >> [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs >> [ 83.450164] PM: early resume of devices complete after 0.274 msecs >> [ 83.457336] <6>Waiting for PHY clock good... >> [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller >> [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] >> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) >> [ 84.771881] PM: resume of devices complete after 1315.185 msecs >> [ 84.778472] Restarting tasks ... >> [ 84.782379] usb 1-1: USB disconnect, device number 2 >> [ 84.790557] done. >> [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz >> sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 >> Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister >> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device >> ermitted >> [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz >> [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full >> # >> # >> # lsusb >> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> # >> >> Is there any relevant patch out there that would address the issue that I >> see ? > > Does this happen because of OFF mode? > Can you please try the tests with off mode disabled? > > e.g. > mount -t debugfs none /sys/kernel/debug > echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > suspend & resume AFAIK, AM3517 does not have OFF mode. We had something similar with runtime pm... It might be useful to know which hub is this and how is it connected... > > Also please send the output of /sys/kernel/debug/pm_debug/count > before suspend and after resume. Thanks. -- 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 7/7] v4l: ti-vpe: Add crop support in VPE driver
Hi Archit, > From: Archit Taneja [mailto:arc...@ti.com] > Sent: Monday, March 03, 2014 9:26 AM > > Hi, > > On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote: > > Hi Archit! > > > > On 03/03/2014 08:33 AM, Archit Taneja wrote: > >> Add crop ioctl ops. For VPE, cropping only makes sense with the > input > >> to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type. > >> > >> For the CAPTURE type, a S_CROP ioctl results in setting the crop > >> region as the whole image itself, hence making crop dimensions same > as the pix dimensions. > >> > >> Setting the crop successfully should result in re-configuration of > >> those registers which are affected when either source or destination > >> dimensions change, set_srcdst_params() is called for this purpose. > >> > >> Some standard crop parameter checks are done in __vpe_try_crop(). > > > > Please use the selection ops instead: if you implement cropping with > > those then you'll support both the selection API and the old cropping > > API will be implemented by the v4l2 core using the selection ops. Two > for the price of one... > > > > Thanks for the feedback. I'll use selection ops here. >From your reply I understand that you will send a v2 of these patches, right? If so, please correct the typos I mentioned in the patch 5/7. Also, it is quite late for v3.15. I did already send a pull request to Mauro, However I have one patch pending. Could you tell me when are you planning to post v2 of these patches? I want to decide whether should I wait for your patchset or should I send the second pull request with the pending patch as soon as possible. Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- 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 v5 0/6] Make dwc3 use Generic PHY Framework
Hi Kishon, Which tree are these patches based on? cheers, -roger On 03/03/2014 01:38 PM, Kishon Vijay Abraham I wrote: > Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3 > should be programmed. While this can be considered as a temporary fix, > a long term solution would be to add 'nop' PHY for platforms that does > not have programmable PHY. > Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the > name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to > be used for SATA and PCIE too. > > Changes from v4: (sending the entire patch series again) > * check the return values of phy_init and phy_power_on > * print errors if power_on or power_off of PHY fails. > > Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) > * avoided using quirks and rely on the return values of PHY APIs to find the > presence of PHY. > > Changes from v2: > * added a couple of fixes. One is invoking phy_resume after phy_init and the > other is power off phy in error patch > * used quirks to identify if a particular platform does not have PHYs > * removed using separate header for pipe3 driver and also removed all > referencs > to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers. > > Changes from v1: > * The logic in which the driver detects the presence of PHYs has changed. > * patch ordering has changed > * udelay is replaced with usleep_range > * A patch to remove set_suspend callback which was deferred from Generic > PHY Framework series has been included. > > Kishon Vijay Abraham I (6): > usb: dwc3: core: support optional PHYs > usb: dwc3: adapt dwc3 core to use Generic PHY Framework > drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework > usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 > phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ > arm/dts: added dt properties to adapt to the new phy framwork > > Documentation/devicetree/bindings/usb/dwc3.txt |6 +- > arch/arm/boot/dts/omap5.dtsi |5 +- > drivers/phy/Kconfig| 11 + > drivers/phy/Makefile |1 + > drivers/phy/phy-omap-usb2.c| 27 +-- > .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} | 240 > > drivers/usb/dwc3/core.c| 116 +++--- > drivers/usb/dwc3/core.h|7 + > drivers/usb/phy/Kconfig| 11 - > drivers/usb/phy/Makefile |1 - > include/linux/{usb => phy}/omap_usb.h |3 - > 11 files changed, 264 insertions(+), 164 deletions(-) > rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%) > rename include/linux/{usb => phy}/omap_usb.h (95%) > -- 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 7/7] v4l: ti-vpe: Add crop support in VPE driver
Hi, On Monday 03 March 2014 05:51 PM, Kamil Debski wrote: Hi Archit, From: Archit Taneja [mailto:arc...@ti.com] Sent: Monday, March 03, 2014 9:26 AM Hi, On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote: Hi Archit! On 03/03/2014 08:33 AM, Archit Taneja wrote: Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type. For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the whole image itself, hence making crop dimensions same as the pix dimensions. Setting the crop successfully should result in re-configuration of those registers which are affected when either source or destination dimensions change, set_srcdst_params() is called for this purpose. Some standard crop parameter checks are done in __vpe_try_crop(). Please use the selection ops instead: if you implement cropping with those then you'll support both the selection API and the old cropping API will be implemented by the v4l2 core using the selection ops. Two for the price of one... Thanks for the feedback. I'll use selection ops here. From your reply I understand that you will send a v2 of these patches, right? If so, please correct the typos I mentioned in the patch 5/7. Also, it is quite late for v3.15. I did already send a pull request to Mauro, However I have one patch pending. Could you tell me when are you planning to post v2 of these patches? I want to decide whether should I wait for your patchset or should I send the second pull request with the pending patch as soon as possible. I'll post a v2 of this set by tomorrow(India time). I have worked on a patch which converts it to selection ioctls, but I need to test it, and get some comments on whether I have implemented the selection ops correctly. Thanks, Archit -- 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 v5 0/6] Make dwc3 use Generic PHY Framework
Roger, On Monday 03 March 2014 05:51 PM, Roger Quadros wrote: Hi Kishon, Which tree are these patches based on? mainline + Felipe's testing/next + Revert "usb: dwc3: core: enable Suspend bit for USB2/3 PHYs" + Revert "usb: dwc3: preparation for adapting dwc3 to generic phy framework" Thanks Kishon cheers, -roger On 03/03/2014 01:38 PM, Kishon Vijay Abraham I wrote: Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3 should be programmed. While this can be considered as a temporary fix, a long term solution would be to add 'nop' PHY for platforms that does not have programmable PHY. Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to be used for SATA and PCIE too. Changes from v4: (sending the entire patch series again) * check the return values of phy_init and phy_power_on * print errors if power_on or power_off of PHY fails. Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) * avoided using quirks and rely on the return values of PHY APIs to find the presence of PHY. Changes from v2: * added a couple of fixes. One is invoking phy_resume after phy_init and the other is power off phy in error patch * used quirks to identify if a particular platform does not have PHYs * removed using separate header for pipe3 driver and also removed all referencs to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers. Changes from v1: * The logic in which the driver detects the presence of PHYs has changed. * patch ordering has changed * udelay is replaced with usleep_range * A patch to remove set_suspend callback which was deferred from Generic PHY Framework series has been included. Kishon Vijay Abraham I (6): usb: dwc3: core: support optional PHYs usb: dwc3: adapt dwc3 core to use Generic PHY Framework drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ arm/dts: added dt properties to adapt to the new phy framwork Documentation/devicetree/bindings/usb/dwc3.txt |6 +- arch/arm/boot/dts/omap5.dtsi |5 +- drivers/phy/Kconfig| 11 + drivers/phy/Makefile |1 + drivers/phy/phy-omap-usb2.c| 27 +-- .../phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} | 240 drivers/usb/dwc3/core.c| 116 +++--- drivers/usb/dwc3/core.h|7 + drivers/usb/phy/Kconfig| 11 - drivers/usb/phy/Makefile |1 - include/linux/{usb => phy}/omap_usb.h |3 - 11 files changed, 264 insertions(+), 164 deletions(-) rename drivers/{usb/phy/phy-omap-usb3.c => phy/phy-ti-pipe3.c} (54%) rename include/linux/{usb => phy}/omap_usb.h (95%) -- 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 5/7] v4l: ti-vpe: Allow usage of smaller images
Hi, On Monday 03 March 2014 05:44 PM, Kamil Debski wrote: Hi Archit, From: Archit Taneja [mailto:arc...@ti.com] Sent: Monday, March 03, 2014 8:33 AM The minimum width and height for VPE input/output was kept as 128 pixels. VPE doesn't have a constraint on the image height, it requires the image width to be atleast 16 bytes. "16 bytes" - shouldn't it be pixels? (also "at least" :) ) I can correct it when applying the patch if the above is the case. VPDMA IP requires the line stride of the input/output images to be at least 16 bytes in total. This can safely result in a minimum width of 16 pixels(NV12 has the least bpp with 1 byte per pixel). But we don't really have any need to support such small image resolutions. So I picked up 32x32 as the minimum size, and tested VPE with that. Thanks, Archit -- 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 4/7] ARM: dts: omap3-overo: Add HSUSB PHY
Hi Roger, On 03/03/2014 12:03 PM, Roger Quadros wrote: > Hi Florian, > > > On 03/03/2014 11:34 AM, Florian Vaussard wrote: >> Add the High-Speed USB PHY. >> >> Signed-off-by: Florian Vaussard >> --- >> arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++ >> arch/arm/boot/dts/omap3-overo-tobi.dts | 16 ++ >> arch/arm/boot/dts/omap3-overo.dtsi | 44 >> >> 3 files changed, 76 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >> b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >> index 2033b52..eb93e3a 100644 >> --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >> @@ -21,6 +21,22 @@ >> }; >> >> &omap3_pmx_core2 { >> +pinctrl-names = "default"; >> +pinctrl-0 = < >> +&hsusb2_2_pins >> +>; >> + >> +hsusb2_2_pins: pinmux_hsusb2_2_pins { >> +pinctrl-single,pins = < >> +OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) >> /* etk_d10.hsusb2_clk */ >> +OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) >> /* etk_d11.hsusb2_stp */ >> +OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d12.hsusb2_dir */ >> +OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d13.hsusb2_nxt */ >> +OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d14.hsusb2_data0 */ >> +OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d15.hsusb2_data1 */ >> +>; >> +}; >> + >> w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { >> pinctrl-single,pins = < >> OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) >> /* etk_d2.gpio_16 */ >> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts >> b/arch/arm/boot/dts/omap3-overo-tobi.dts >> index 21de31d..e77be26 100644 >> --- a/arch/arm/boot/dts/omap3-overo-tobi.dts >> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts >> @@ -21,6 +21,22 @@ >> }; >> >> &omap3_pmx_core2 { >> +pinctrl-names = "default"; >> +pinctrl-0 = < >> +&hsusb2_2_pins >> +>; >> + >> +hsusb2_2_pins: pinmux_hsusb2_2_pins { >> +pinctrl-single,pins = < >> +OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) >> /* etk_d10.hsusb2_clk */ >> +OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) >> /* etk_d11.hsusb2_stp */ >> +OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d12.hsusb2_dir */ >> +OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d13.hsusb2_nxt */ >> +OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d14.hsusb2_data0 */ >> +OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | >> MUX_MODE3)/* etk_d15.hsusb2_data1 */ >> +>; >> +}; >> + >> w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { >> pinctrl-single,pins = < >> OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) >> /* etk_d2.gpio_16 */ >> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi >> b/arch/arm/boot/dts/omap3-overo.dtsi >> index 07467cc..8f810db 100644 >> --- a/arch/arm/boot/dts/omap3-overo.dtsi >> +++ b/arch/arm/boot/dts/omap3-overo.dtsi >> @@ -30,6 +30,24 @@ >> ti,codec = <&twl_audio>; >> }; >> >> +/* HS USB Port 2 Power */ >> +hsusb2_power: hsusb2_power_reg { >> +compatible = "regulator-fixed"; >> +regulator-name = "hsusb2_vbus"; >> +regulator-min-microvolt = <500>; >> +regulator-max-microvolt = <500>; >> +gpio = <&gpio6 8 0>;/* gpio_168: >> vbus enable */ >> +startup-delay-us = <7>; >> +enable-active-high; >> +}; >> + >> +/* HS USB Host PHY on PORT 2 */ >> +hsusb2_phy: hsusb2_phy { >> +compatible = "usb-nop-xceiv"; >> +reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>; /* gpio_183 */ >> +vcc-supply = <&hsusb2_power>; >> +}; >> + >> /* Regulator to trigger the nPoweron signal of the Wifi module */ >> w3cbw003c_npoweron: regulator-w3cbw003c-npoweron { >> compatible = "regulator-fixed"; >> @@ -64,6 +82,11 @@ >> }; >> >> &omap3_pmx_core { >> +pinctrl-names = "default"; >> +pinctrl-0 = < >> +&hsusb2_pins >> +>; >> + >> uart3_pins: pinmux_uart3_pins { >> pinctrl-single,pins = < >> OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | >> PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ >> @@ -107,6 +130,19 @@ >> OMAP3_CORE1_IOPAD(0x219c
Re: [PATCH v3 4/7] ARM: dts: omap3-overo: Add HSUSB PHY
On 03/03/2014 02:48 PM, Florian Vaussard wrote: > Hi Roger, > > On 03/03/2014 12:03 PM, Roger Quadros wrote: >> Hi Florian, >> >> >> On 03/03/2014 11:34 AM, Florian Vaussard wrote: >>> Add the High-Speed USB PHY. >>> >>> Signed-off-by: Florian Vaussard >>> --- >>> arch/arm/boot/dts/omap3-overo-storm-tobi.dts | 16 ++ >>> arch/arm/boot/dts/omap3-overo-tobi.dts | 16 ++ >>> arch/arm/boot/dts/omap3-overo.dtsi | 44 >>> >>> 3 files changed, 76 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >>> b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >>> index 2033b52..eb93e3a 100644 >>> --- a/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >>> +++ b/arch/arm/boot/dts/omap3-overo-storm-tobi.dts >>> @@ -21,6 +21,22 @@ >>> }; >>> >>> &omap3_pmx_core2 { >>> + pinctrl-names = "default"; >>> + pinctrl-0 = < >>> + &hsusb2_2_pins >>> + >; >>> + >>> + hsusb2_2_pins: pinmux_hsusb2_2_pins { >>> + pinctrl-single,pins = < >>> + OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) >>> /* etk_d10.hsusb2_clk */ >>> + OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) >>> /* etk_d11.hsusb2_stp */ >>> + OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d12.hsusb2_dir */ >>> + OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d13.hsusb2_nxt */ >>> + OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d14.hsusb2_data0 */ >>> + OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d15.hsusb2_data1 */ >>> + >; >>> + }; >>> + >>> w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { >>> pinctrl-single,pins = < >>> OMAP3630_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) >>> /* etk_d2.gpio_16 */ >>> diff --git a/arch/arm/boot/dts/omap3-overo-tobi.dts >>> b/arch/arm/boot/dts/omap3-overo-tobi.dts >>> index 21de31d..e77be26 100644 >>> --- a/arch/arm/boot/dts/omap3-overo-tobi.dts >>> +++ b/arch/arm/boot/dts/omap3-overo-tobi.dts >>> @@ -21,6 +21,22 @@ >>> }; >>> >>> &omap3_pmx_core2 { >>> + pinctrl-names = "default"; >>> + pinctrl-0 = < >>> + &hsusb2_2_pins >>> + >; >>> + >>> + hsusb2_2_pins: pinmux_hsusb2_2_pins { >>> + pinctrl-single,pins = < >>> + OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3) >>> /* etk_d10.hsusb2_clk */ >>> + OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3) >>> /* etk_d11.hsusb2_stp */ >>> + OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d12.hsusb2_dir */ >>> + OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d13.hsusb2_nxt */ >>> + OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d14.hsusb2_data0 */ >>> + OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | >>> MUX_MODE3)/* etk_d15.hsusb2_data1 */ >>> + >; >>> + }; >>> + >>> w3cbw003c_2_pins: pinmux_w3cbw003c_2_pins { >>> pinctrl-single,pins = < >>> OMAP3430_CORE2_IOPAD(0x25e0, PIN_OUTPUT | MUX_MODE4) >>> /* etk_d2.gpio_16 */ >>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi >>> b/arch/arm/boot/dts/omap3-overo.dtsi >>> index 07467cc..8f810db 100644 >>> --- a/arch/arm/boot/dts/omap3-overo.dtsi >>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi >>> @@ -30,6 +30,24 @@ >>> ti,codec = <&twl_audio>; >>> }; >>> >>> + /* HS USB Port 2 Power */ >>> + hsusb2_power: hsusb2_power_reg { >>> + compatible = "regulator-fixed"; >>> + regulator-name = "hsusb2_vbus"; >>> + regulator-min-microvolt = <500>; >>> + regulator-max-microvolt = <500>; >>> + gpio = <&gpio6 8 0>;/* gpio_168: >>> vbus enable */ >>> + startup-delay-us = <7>; >>> + enable-active-high; >>> + }; >>> + >>> + /* HS USB Host PHY on PORT 2 */ >>> + hsusb2_phy: hsusb2_phy { >>> + compatible = "usb-nop-xceiv"; >>> + reset-gpios = <&gpio6 23 GPIO_ACTIVE_LOW>; /* gpio_183 */ >>> + vcc-supply = <&hsusb2_power>; >>> + }; >>> + >>> /* Regulator to trigger the nPoweron signal of the Wifi module */ >>> w3cbw003c_npoweron: regulator-w3cbw003c-npoweron { >>> compatible = "regulator-fixed"; >>> @@ -64,6 +82,11 @@ >>> }; >>> >>> &omap3_pmx_core { >>> + pinctrl-names = "default"; >>> + pinctrl-0 = < >>> + &hsusb2_pins >>> + >; >>> + >>> uart3_pins: pinmux_uart3_pins { >>> pinctrl-single,pins = < >>> OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | >>> PIN_OFF_WAKEUPENABLE
[PATCH 5/5] doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue
Add the compatible "ti,am437x-dwc3" for dwc3 glue driver. Signed-off-by: George Cherian --- Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index c495135..1d38569 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be "ti,dwc3" + - compatible : Should be + * "ti,dwc3" for OMAP5 and DRA7 + * "ti,am437x-dwc3" for AM437x - ti,hwmods : Should be "usb_otg_ss" - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: dts: am43x-epos-evm: Enable USB
Enable - ocp2scp - USB PHY control module - USB PHY - dwc3_omap - USB for am43x-epos-evm Signed-off-by: George Cherian --- arch/arm/boot/dts/am43x-epos-evm.dts | 44 1 file changed, 44 insertions(+) diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index a7d0db1..165026b 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -251,3 +251,47 @@ pinctrl-0 = <&spi1_pins>; status = "okay"; }; + +&am43xx_control_usb2phy1 { + status = "okay"; +}; + +&ocp2scp0 { + status = "okay"; +}; + +&usb2_phy1 { + status = "okay"; +}; + +&dwc3_1 { + status = "okay"; +}; + +&usb1 { + dr_mode = "peripheral"; + maximum-speed = "high-speed"; + status = "okay"; +}; + +&am43xx_control_usb2phy2 { + status = "okay"; +}; + +&ocp2scp1 { + status = "okay"; +}; + +&usb2_phy2 { + status = "okay"; +}; + +&dwc3_2 { + status = "okay"; +}; + +&usb2 { + dr_mode = "host"; + maximum-speed = "high-speed"; + status = "okay"; +}; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: dts: am437x-gp-evm: Enable USB
Enable - ocp2scp - USB PHY control module - USB PHY - dwc3_omap - USB for am437x-gp-evm Signed-off-by: George Cherian --- arch/arm/boot/dts/am437x-gp-evm.dts | 44 + 1 file changed, 44 insertions(+) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index 4eb72b8..89e08cd 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -98,3 +98,47 @@ &gpio4 { status = "okay"; }; + +&am43xx_control_usb2phy1 { + status = "okay"; +}; + +&ocp2scp0 { + status = "okay"; +}; + +&usb2_phy1 { + status = "okay"; +}; + +&dwc3_1 { + status = "okay"; +}; + +&usb1 { + dr_mode = "peripheral"; + maximum-speed = "high-speed"; + status = "okay"; +}; + +&am43xx_control_usb2phy2 { + status = "okay"; +}; + +&ocp2scp1 { + status = "okay"; +}; + +&usb2_phy2 { + status = "okay"; +}; + +&dwc3_2 { + status = "okay"; +}; + +&usb2 { + dr_mode = "host"; + maximum-speed = "high-speed"; + status = "okay"; +}; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: dts: AM4372: Add USB nodes
Add nodes for 2 instances each of - ocp2scp - USB PHY control module - USB PHY - dwc3_omap - USB for AM43xx. Signed-off-by: George Cherian --- arch/arm/boot/dts/am4372.dtsi | 99 +++ 1 file changed, 99 insertions(+) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index 5a7cc38..90408b3 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -698,6 +698,105 @@ <&edma 11>; dma-names = "tx", "rx"; }; + + am43xx_control_usb2phy1: control-phy@44e10620 { + compatible = "ti,control-phy-am437usb2"; + reg = <0x44e10620 0x4>; + reg-names = "power"; + status = "disabled"; + }; + + am43xx_control_usb2phy2: control-phy@0x44e10628 { + compatible = "ti,control-phy-am437usb2"; + reg = <0x44e10628 0x4>; + reg-names = "power"; + status = "disabled"; + }; + + ocp2scp0: ocp2scp@483a8000 { + compatible = "ti,omap-ocp2scp"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "ocp2scp0"; + status = "disabled"; + + usb2_phy1: usb2phy1@483a8000 { + compatible = "ti,am437x-usb2"; + reg = <0x483a8000 0x8000>; + ctrl-module = <&am43xx_control_usb2phy1>; + clocks = <&clk_32768_ck>, +<&usb_otg_ss0_refclk960m>; + clock-names = "usb_phy_cm_clk32k", + "usb_otg_ss_refclk960m"; + #phy-cells = <0>; + status = "disabled"; + }; + }; + + ocp2scp1: ocp2scp@483e8000 { + compatible = "ti,omap-ocp2scp"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + ti,hwmods = "ocp2scp1"; + status = "disabled"; + + usb2_phy2: usb2phy2@483e8000 { + compatible = "ti,am437x-usb2"; + reg = <0x483e8000 0x8000>; + ctrl-module = <&am43xx_control_usb2phy2>; + clocks = <&clk_32768_ck>, +<&usb_otg_ss1_refclk960m>; + clock-names = "usb_phy_cm_clk32k", + "usb_otg_ss_refclk960m"; + #phy-cells = <0>; + status = "disabled"; + }; + }; + + dwc3_1: omap_dwc3_1@4838 { + compatible = "ti,am437x-dwc3"; + ti,hwmods = "usb_otg_ss0"; + reg = <0x4838 0x1>; + interrupts = ; + #address-cells = <1>; + #size-cells = <1>; + utmi-mode = <1>; + ranges; + status = "disabled"; + + usb1: usb@4839 { + compatible = "synopsys,dwc3"; + reg = <0x4839 0x17000>; + interrupts = ; + usb-phy = <&usb2_phy1>; + phy-names = "usb2-phy"; + status = "disabled"; + }; + }; + + dwc3_2: omap_dwc3_2@483c { + compatible = "ti,am437x-dwc3"; + ti,hwmods = "usb_otg_ss1"; + reg = <0x483c 0x1>; + interrupts = ; + #address-cells = <1>; + #size-cells = <1>; + utmi-mode = <1>; + ranges; + status = "disabled"; + + usb2: usb@483d { + compatible = "synopsys,dwc3"; + reg = <0x483d 0x17000>; + interrupts = ; + usb-phy = <&usb2_phy2>; + phy-names = "usb2-phy"; + status = "disabled"; + }; + }; + }; }; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsu
[PATCH 1/5] ARM: dts: am43xx clock data
Add USB reference clock data Signed-off-by: George Cherian --- arch/arm/boot/dts/am43xx-clocks.dtsi | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi b/arch/arm/boot/dts/am43xx-clocks.dtsi index 142009c..506d036 100644 --- a/arch/arm/boot/dts/am43xx-clocks.dtsi +++ b/arch/arm/boot/dts/am43xx-clocks.dtsi @@ -653,4 +653,21 @@ clocks = <&clk_32768_ck>, <&clk_32k_tpm_ck>; reg = <0x4260>; }; + + usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m { + #clock-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&dpll_per_clkdcoldo>; + ti,bit-shift = <8>; + reg = <0x8a60>; + }; + + usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m { + #clock-cells = <0>; + compatible = "ti,gate-clock"; + clocks = <&dpll_per_clkdcoldo>; + ti,bit-shift = <8>; + reg = <0x8a68>; + }; + }; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Add USB nodes for am43xx epos and gp evm
The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with Benoit's for_3.15 + following patches https://patchwork.kernel.org/patch/3600821/ https://patchwork.kernel.org/patch/3600831/ https://patchwork.kernel.org/patch/3600851/ https://patchwork.kernel.org/patch/3600841/ George Cherian (5): ARM: dts: am43xx clock data ARM: dts: AM4372: Add USB nodes ARM: dts: am437x-gp-evm: Enable USB ARM: dts: am43x-epos-evm: Enable USB doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 99 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 44 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 44 ++ arch/arm/boot/dts/am43xx-clocks.dtsi | 17 5 files changed, 207 insertions(+), 1 deletion(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Help needed USB hub disconnected at resume
Hi Igor The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port via the DUP_P and DUP_N pins. There is a reset applied to the chip at power on. Regards Marc From: Igor Grinberg [grinb...@compulab.co.il] Sent: 03 March 2014 12:16 To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org Subject: Re: Help needed USB hub disconnected at resume On 03/03/14 13:06, Roger Quadros wrote: > Hi Marc, > > On 03/03/2014 12:04 PM, Marc Murphy wrote: >> Hi, >> I am using the latest stable 3.4.80 kernel with some changes to get the EMAC >> Phy to initialise correctly after a suspend/resume. The platform is AM3517 >> with most of the system working nice and smoothly. I have 1 issue though and >> need some advice/help to get the system to use the USB hub I have connected >> to the EHCI controller after a suspend to memory and resume. >> >> At boot all is recognised; >> >> [1.486816] usbcore: registered new interface driver cdc_ether >> [1.493255] usbcore: registered new interface driver cdc_ncm >> [1.499450] usbcore: registered new interface driver qmi_wwan >> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver >> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator >> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller >> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus >> number 1 >> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 >> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 >> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 >> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, >> SerialNumber=1 >> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller >> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd >> [2.585296] usb usb1: SerialNumber: ehci-omap.0 >> [2.591278] hub 1-0:1.0: USB hub found >> [2.595306] hub 1-0:1.0: 3 ports detected >> >> And I can see everything OK. >> >> # lsusb >> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub >> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. >> # >> # >> # echo mem > /sys/power/state >> [ 73.736572] PM: Syncing filesystems ... done. >> [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. >> [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) >> done. >> [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle >> [ 73.968872] PM: suspend of devices complete after 170.410 msecs >> [ 73.975433] PM: late suspend of devices complete after 0.305 msecs >> [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs >> [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 >> [ 83.436737] Could not enter target state in pm_suspend >> [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs >> [ 83.450164] PM: early resume of devices complete after 0.274 msecs >> [ 83.457336] <6>Waiting for PHY clock good... >> [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller >> [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] >> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) >> [ 84.771881] PM: resume of devices complete after 1315.185 msecs >> [ 84.778472] Restarting tasks ... >> [ 84.782379] usb 1-1: USB disconnect, device number 2 >> [ 84.790557] done. >> [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz >> sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 >> Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister >> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device >> ermitted >> [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz >> [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full >> # >> # >> # lsusb >> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> # >> >> Is there any relevant patch out there that would address the issue that I >> see ? > > Does this happen because of OFF mode? > Can you please try the tests with off mode disabled? > > e.g. > mount -t debugfs none /sys/kernel/debug > echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > suspend & resume AFAIK, AM3517 does not have OFF mode. We had something similar with runtime pm... It might be useful to know which hub is this and how is it connected... > > Also please send the output of /sys/kernel/debug/pm_debug/count > before suspend and after resume. Thanks. -- Regards, Igor. -- To unsubscribe from this
Re: [PATCH RESEND v11 6/7] ARM: OMAP: enable SYSCON and REGULATOR_PBIAS in omap2plus_defconfig
On Wednesday 26 February 2014 10:31 PM, Tony Lindgren wrote: * Balaji T K [140219 07:00]: Enable REGULATOR_PBIAS needed for SD card on most OMAPs. Signed-off-by: Balaji T K I belive this is the only one missing my ack: Acked-by: Tony Lindgren Thanks Tony Probably best that this all gets queued along with other MMC related patches by Balaji and Chris. Hi Chris, Can you please pull this patch series for 3.15? Thanks and Regards, Balaji T K --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 3a0b53d..e4fec1c 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -169,6 +169,7 @@ CONFIG_DRA752_THERMAL=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y @@ -180,6 +181,7 @@ CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y +CONFIG_REGULATOR_PBIAS=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
[RESEND Patch 6/9] ARM: dts: DRA7: Add device nodes for ABB
From: Nishanth Menon Add ABB device nodes for DRA7 family of devices. Data is based on DRA7 Technical Reference Manual revision I (Sept 2013) Signed-off-by: Nishanth Menon Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/dra7.dtsi | 132 1 file changed, 132 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 499974a..9e3caf3 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -578,6 +578,138 @@ status = "disabled"; }; + abb_mpu: regulator-abb-mpu { + compatible = "ti,abb-v3"; + regulator-name = "abb_mpu"; + #address-cells = <0>; + #size-cells = <0>; + clocks = <&sys_clkin1>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + + reg = <0x4ae07ddc 0x4>, <0x4ae07de0 0x4>, + <0x4ae06014 0x4>, <0x4a003b20 0x8>, + <0x4ae0c158 0x4>; + reg-names = "setup-address", "control-address", + "int-address", "efuse-address", + "ldo-address"; + ti,tranxdone-status-mask = <0x80>; + /* LDOVBBMPU_FBB_MUX_CTRL */ + ti,ldovbb-override-mask = <0x400>; + /* LDOVBBMPU_FBB_VSET_OUT */ + ti,ldovbb-vset-mask = <0x1F>; + + /* +* NOTE: only FBB mode used but actual vset will +* determine final biasing +*/ + ti,abb_info = < + /*uVABB efuse rbb_m fbb_m vset_m*/ + 106 0 0x0 0 0x0200 0x01F0 + 116 0 0x4 0 0x0200 0x01F0 + 121 0 0x8 0 0x0200 0x01F0 + >; + }; + + abb_ivahd: regulator-abb-ivahd { + compatible = "ti,abb-v3"; + regulator-name = "abb_ivahd"; + #address-cells = <0>; + #size-cells = <0>; + clocks = <&sys_clkin1>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + + reg = <0x4ae07e34 0x4>, <0x4ae07e24 0x4>, + <0x4ae06010 0x4>, <0x4a0025cc 0x8>, + <0x4a002470 0x4>; + reg-names = "setup-address", "control-address", + "int-address", "efuse-address", + "ldo-address"; + ti,tranxdone-status-mask = <0x4000>; + /* LDOVBBIVA_FBB_MUX_CTRL */ + ti,ldovbb-override-mask = <0x400>; + /* LDOVBBIVA_FBB_VSET_OUT */ + ti,ldovbb-vset-mask = <0x1F>; + + /* +* NOTE: only FBB mode used but actual vset will +* determine final biasing +*/ + ti,abb_info = < + /*uVABB efuse rbb_m fbb_m vset_m*/ + 1055000 0 0x0 0 0x0200 0x01F0 + 115 0 0x4 0 0x0200 0x01F0 + 125 0 0x8 0 0x0200 0x01F0 + >; + }; + + abb_dspeve: regulator-abb-dspeve { + compatible = "ti,abb-v3"; + regulator-name = "abb_dspeve"; + #address-cells = <0>; + #size-cells = <0>; + clocks = <&sys_clkin1>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + + reg = <0x4ae07e30 0x4>, <0x4ae07e20 0x4>, + <0x4ae06010 0x4>, <0x4a0025e0 0x8>, + <0x4a00246c 0x4>; + reg-names = "setup-address", "control-address", + "int-address", "efuse-address", + "ldo-address"; + ti,tranxdone-status-mask = <0x2000>; + /* LDOVBBDSPEVE_FBB_MUX_CTRL */ + ti,ldovbb-override-mask = <0x400>; + /* LDOVBBDSPEVE_FBB_VSET_OUT */ + ti,ldovbb-vset-mask = <0x1F>; + + /* +* NOTE: only FBB mode used but actual vset will +
[RESEND Patch 9/9] ARM: DTS: DRA7: Add routable-irqs property for gic node
From: Sricharan R There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The gic provides the support for such IPs in the form of routable-irqs. So adding the property here to gic node. Cc: Benoit Cousson Cc: Santosh Shilimkar Cc: Rajendra Nayak Cc: Tony Lindgren Signed-off-by: Sricharan R Acked-by: Santosh Shilimkar Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/dra7.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 2bd3a9a..824e316 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -72,6 +72,7 @@ compatible = "arm,cortex-a15-gic"; interrupt-controller; #interrupt-cells = <3>; + arm,routable-irqs = <160>; reg = <0x48211000 0x1000>, <0x48212000 0x1000>, <0x48214000 0x2000>, -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 8/9] ARM: DTS: DRA7: Replace peripheral interrupt numbers with crossbar inputs
From: Sricharan R Now with the crossbar IP in picture, the peripherals do not have the fixed interrupt lines. Instead they rely on the crossbar irqchip to allocate and map a free interrupt line to its crossbar input. So replacing all the peripheral interrupt numbers with its fixed crossbar input lines. Cc: Benoit Cousson Cc: Santosh Shilimkar Cc: Rajendra Nayak Cc: Tony Lindgren Signed-off-by: Sricharan R Acked-by: Santosh Shilimkar Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/dra7.dtsi | 86 ++--- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 88fc2eb..2bd3a9a 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -166,10 +166,10 @@ sdma: dma-controller@4a056000 { compatible = "ti,omap4430-sdma"; reg = <0x4a056000 0x1000>; - interrupts = , -, -, -; + interrupts = , +, +, +; #dma-cells = <1>; #dma-channels = <32>; #dma-requests = <127>; @@ -178,7 +178,7 @@ gpio1: gpio@4ae1 { compatible = "ti,omap4-gpio"; reg = <0x4ae1 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio1"; gpio-controller; #gpio-cells = <2>; @@ -189,7 +189,7 @@ gpio2: gpio@48055000 { compatible = "ti,omap4-gpio"; reg = <0x48055000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio2"; gpio-controller; #gpio-cells = <2>; @@ -200,7 +200,7 @@ gpio3: gpio@48057000 { compatible = "ti,omap4-gpio"; reg = <0x48057000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio3"; gpio-controller; #gpio-cells = <2>; @@ -211,7 +211,7 @@ gpio4: gpio@48059000 { compatible = "ti,omap4-gpio"; reg = <0x48059000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio4"; gpio-controller; #gpio-cells = <2>; @@ -222,7 +222,7 @@ gpio5: gpio@4805b000 { compatible = "ti,omap4-gpio"; reg = <0x4805b000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio5"; gpio-controller; #gpio-cells = <2>; @@ -233,7 +233,7 @@ gpio6: gpio@4805d000 { compatible = "ti,omap4-gpio"; reg = <0x4805d000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio6"; gpio-controller; #gpio-cells = <2>; @@ -244,7 +244,7 @@ gpio7: gpio@48051000 { compatible = "ti,omap4-gpio"; reg = <0x48051000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio7"; gpio-controller; #gpio-cells = <2>; @@ -255,7 +255,7 @@ gpio8: gpio@48053000 { compatible = "ti,omap4-gpio"; reg = <0x48053000 0x200>; - interrupts = ; + interrupts = ; ti,hwmods = "gpio8"; gpio-controller; #gpio-cells = <2>; @@ -266,7 +266,7 @@ uart1: serial@4806a000 { compatible = "ti,omap4-uart"; reg = <0x4806a000 0x100>; - interrupts = ; + interrupts = ; ti,hwmods = "uart1"; clock-frequency = <4800>; status = "disabled"; @@ -275,7 +275,7 @@ uart2: serial@4806c000 { compatible = "ti,omap4-uart"; reg = <0x4806c000 0x100>; - interrupts = ; + interrupts = ;
[RESEND Patch 5/9] ARM: dts: OMAP4: Add device nodes for ABB
From: "Andrii.Tseglytskyi" Add ABB device nodes for OMAP443x family of devices. abb_iva is populated, but disabled as it is not used on current OMAP443x family, but the node is used on OMAP446x family. Data is based on OMAP443x Technical Reference Manual revision AN (April 2013). ABB device nodes for OMAP4460 device Data is based on OMAP4460 Technical Reference Manual revision Z (April 2013) [n...@ti.com: co-developer] Signed-off-by: Nishanth Menon Signed-off-by: Andrii.Tseglytskyi Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/omap4.dtsi| 26 ++ arch/arm/boot/dts/omap443x.dtsi | 26 ++ arch/arm/boot/dts/omap4460.dtsi | 37 + 3 files changed, 89 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index afa23bc..c18f0fd 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -776,6 +776,32 @@ dmas = <&sdma 117>, <&sdma 116>; dma-names = "tx", "rx"; }; + + abb_mpu: regulator-abb-mpu { + compatible = "ti,abb-v2"; + regulator-name = "abb_mpu"; + #address-cells = <0>; + #size-cells = <0>; + ti,tranxdone-status-mask = <0x80>; + clocks = <&sys_clkin_ck>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + + status = "disabled"; + }; + + abb_iva: regulator-abb-iva { + compatible = "ti,abb-v2"; + regulator-name = "abb_iva"; + #address-cells = <0>; + #size-cells = <0>; + ti,tranxdone-status-mask = <0x8000>; + clocks = <&sys_clkin_ck>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + + status = "disabled"; + }; }; }; diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index 8c1cfad..0adfa1d 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -43,6 +43,32 @@ #thermal-sensor-cells = <0>; }; }; + + ocp { + abb_mpu: regulator-abb-mpu { + status = "okay"; + + reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>; + reg-names = "base-address", "int-address"; + + ti,abb_info = < + /*uVABB efuse rbb_m fbb_m vset_m*/ + 1025000 0 0 0 0 0 + 120 0 0 0 0 0 + 1313000 0 0 0 0 0 + 1375000 1 0 0 0 0 + 1389000 1 0 0 0 0 + >; + }; + + /* Default unused, just provide register info for record */ + abb_iva: regulator-abb-iva { + reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>; + reg-names = "base-address", "int-address"; + }; + + }; + }; /include/ "omap443x-clocks.dtsi" diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 6b32f52..194f9ef 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -50,7 +50,44 @@ #thermal-sensor-cells = <0>; }; + + abb_mpu: regulator-abb-mpu { + status = "okay"; + + reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>, + <0x4A002268 0x4>; + reg-names = "base-address", "int-address", + "efuse-address"; + + ti,abb_info = < + /*uVABB efuse rbb_m fbb_m vset_m*/ + 1025000 0 0 0 0 0 + 120 0 0 0 0 0 + 1313000 0 0 0x10 0x4 0 + 1375000 1 0 0 0 0 + 1389000 1 0 0 0 0 + >; + }; + + abb_iva: regulator-abb-iva { + status = "okay"; + + reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>, + <0x4A002268 0x4>; + reg-names = "base-address", "int-address", + "efuse-address"; + +
[RESEND Patch 7/9] ARM: DTS: DRA7: Add crossbar device binding
From: Sricharan R This adds the irq crossbar device node. There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The Peripheral irq requests are connected to only one crossbar input and the output of the crossbar is connected to only one controller's input line. The crossbar device is used to map a peripheral input to a free mpu's interrupt controller line. Cc: Benoit Cousson Cc: Santosh Shilimkar Cc: Rajendra Nayak Cc: Tony Lindgren Signed-off-by: Sricharan R Acked-by: Santosh Shilimkar Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/dra7.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 9e3caf3..88fc2eb 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -773,6 +773,14 @@ status = "disabled"; }; }; + + crossbar_mpu: crossbar@4a02 { + compatible = "ti,irq-crossbar"; + reg = <0x4a002a48 0x130>; + ti,max-irqs = <160>; + ti,reg-size = <2>; + ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>; + }; }; /include/ "dra7xx-clocks.dtsi" -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 0/9] dts pending patches for TI omap
Benoit/Tony Here I am send all the pending dt patches that can go into 3.15 merge window, all the patches were already posted to mailing list and has beed reviewed. I have rebased the patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.15/dt and fixed all the merge conflicts. Pasting the mail archive for the patches series * Add ABB device nodes http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html * MMC hot plug support http://mail.blameitonlove.com/lists/linux-omap/msg101933.html Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as this is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a * DRA7 Cross bar DTS patches Cross bar driver has been pulled for next merge, so the dts patches can also be pulled for next merge window. Here is the pull request for the same patch series. The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84: Merge tag 'for_3.15/dts_signed' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.15/dt (2014-03-02 14:22:03 -0800) are available in the git repository at: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15 for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4: ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 19:53:25 +0530) Andrii.Tseglytskyi (2): ARM: dts: OMAP36xx: Add device node for ABB ARM: dts: OMAP4: Add device nodes for ABB Balaji T K (3): ARM: dts: am437x gp-evm: add sd card dt nodes ARM: dts: am335x-evm: add SD card hotplug support ARM: dts: am43x-epos-evm: add SD card hotplug support Nishanth Menon (1): ARM: dts: DRA7: Add device nodes for ABB Sricharan R (3): ARM: DTS: DRA7: Add crossbar device binding ARM: DTS: DRA7: Replace peripheral interrupt numbers with crossbar inputs ARM: DTS: DRA7: Add routable-irqs property for gic node arch/arm/boot/dts/am335x-evm.dts | 9 ++ arch/arm/boot/dts/am4372.dtsi| 1 + arch/arm/boot/dts/am437x-gp-evm.dts | 27 + arch/arm/boot/dts/am43x-epos-evm.dts | 9 ++ arch/arm/boot/dts/dra7.dtsi | 227 --- arch/arm/boot/dts/omap36xx.dtsi | 20 +++ arch/arm/boot/dts/omap4.dtsi | 26 arch/arm/boot/dts/omap443x.dtsi | 26 arch/arm/boot/dts/omap4460.dtsi | 37 ++ 9 files changed, 339 insertions(+), 43 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 4/9] ARM: dts: OMAP36xx: Add device node for ABB
From: "Andrii.Tseglytskyi" Add ABB device node for OMAP36xx family of devices. Data is based on OMAP36XX Technical Reference Manual revision AB (Dec 2012). [n...@ti.com: co-developer] Signed-off-by: Nishanth Menon Signed-off-by: Andrii.Tseglytskyi Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/omap36xx.dtsi | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi index 7e8dee9..ba077cd 100644 --- a/arch/arm/boot/dts/omap36xx.dtsi +++ b/arch/arm/boot/dts/omap36xx.dtsi @@ -39,6 +39,26 @@ clock-frequency = <4800>; }; + abb_mpu_iva: regulator-abb-mpu { + compatible = "ti,abb-v1"; + regulator-name = "abb_mpu_iva"; + #address-cell = <0>; + #size-cells = <0>; + reg = <0x483072f0 0x8>, <0x48306818 0x4>; + reg-names = "base-address", "int-address"; + ti,tranxdone-status-mask = <0x400>; + clocks = <&sys_ck>; + ti,settling-time = <30>; + ti,clock-cycles = <8>; + ti,abb_info = < + /*uVABB efuse rbb_m fbb_m vset_m*/ + 1012500 0 0 0 0 0 + 120 0 0 0 0 0 + 1325000 0 0 0 0 0 + 1375000 1 0 0 0 0 + >; + }; + omap3_pmx_core2: pinmux@480025a0 { compatible = "ti,omap3-padconf", "pinctrl-single"; reg = <0x480025a0 0x5c>; -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 2/9] ARM: dts: am335x-evm: add SD card hotplug support
From: Balaji T K Add card detect gpio for SD card slot Signed-off-by: Balaji T K Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/am335x-evm.dts | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 07d61bb..28ae040 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -260,6 +260,12 @@ >; }; + mmc1_pins: pinmux_mmc1_pins { + pinctrl-single,pins = < + 0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */ + >; + }; + lcd_pins_s0: lcd_pins_s0 { pinctrl-single,pins = < 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT | MODE1 */ @@ -644,6 +650,9 @@ status = "okay"; vmmc-supply = <&vmmc_reg>; bus-width = <4>; + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins>; + cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; }; &sham { -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 3/9] ARM: dts: am43x-epos-evm: add SD card hotplug support
From: Balaji T K Add card detect gpio for SD card slot and include dt gpio header. Signed-off-by: Balaji T K Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/am4372.dtsi| 1 + arch/arm/boot/dts/am43x-epos-evm.dts | 9 + 2 files changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index b687869..36d523a 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -8,6 +8,7 @@ * kind, whether express or implied. */ +#include #include #include "skeleton.dtsi" diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index a3a53ce..167dbc8 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -132,6 +132,12 @@ 0x19c (PIN_OUTPUT | MUX_MODE3) /* mcasp0_ahclkr.spi1_cs0 */ >; }; + + mmc1_pins: pinmux_mmc1_pins { + pinctrl-single,pins = < + 0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */ + >; + }; }; matrix_keypad: matrix_keypad@0 { @@ -179,6 +185,9 @@ status = "okay"; vmmc-supply = <&vmmcsd_fixed>; bus-width = <4>; + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins>; + cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; }; &mac { -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 0/9] dts pending patches for TI omap
Benoit/Tony Here I am send all the pending patches that can go into 3.15 merge window, all the patches were already posted to mailing list and has beed reviewed. Here I am rebasing the patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.15/dt and fixed all the merge conflicts. Here I am pasting the mail archieve for the patches series * Add ABB device nodes http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-ARM-dts-OMAP3630-Add-ABB-device-nodes-td794852.html * MMC hot plug support http://mail.blameitonlove.com/lists/linux-omap/msg101933.html Dropped [PATCH 2/3] ARM: dts: am335x-evmsk: add SD card hotplug support as this is already merged with commit id 29ea5efb0bb612d352aa360de26e2095cb230e4a * DRA7 Cross bar DTS patches Cross bar driver has been pulled for next merge, so the dts patches can also be pulled for next merge window. Here is the pull request for the same set. The following changes since commit f777ba1780584b100ab9664cc06d04f3bb273a84: Merge tag 'for_3.15/dts_signed' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.15/dt (2014-03-02 14:22:03 -0800) are available in the git repository at: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git omapdt-for-3.15 for you to fetch changes up to 5f78b45aa45c5b2c4de895c3b0740fda4684dae4: ARM: DTS: DRA7: Add routable-irqs property for gic node (2014-03-03 19:53:25 +0530) Andrii.Tseglytskyi (2): ARM: dts: OMAP36xx: Add device node for ABB ARM: dts: OMAP4: Add device nodes for ABB Balaji T K (3): ARM: dts: am437x gp-evm: add sd card dt nodes ARM: dts: am335x-evm: add SD card hotplug support ARM: dts: am43x-epos-evm: add SD card hotplug support Nishanth Menon (1): ARM: dts: DRA7: Add device nodes for ABB Sricharan R (3): ARM: DTS: DRA7: Add crossbar device binding ARM: DTS: DRA7: Replace peripheral interrupt numbers with crossbar inputs ARM: DTS: DRA7: Add routable-irqs property for gic node arch/arm/boot/dts/am335x-evm.dts | 9 ++ arch/arm/boot/dts/am4372.dtsi| 1 + arch/arm/boot/dts/am437x-gp-evm.dts | 27 + arch/arm/boot/dts/am43x-epos-evm.dts | 9 ++ arch/arm/boot/dts/dra7.dtsi | 227 --- arch/arm/boot/dts/omap36xx.dtsi | 20 +++ arch/arm/boot/dts/omap4.dtsi | 26 arch/arm/boot/dts/omap443x.dtsi | 26 arch/arm/boot/dts/omap4460.dtsi | 37 ++ 9 files changed, 339 insertions(+), 43 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND Patch 1/9] ARM: dts: am437x gp-evm: add sd card dt nodes
From: Balaji T K enable sd card slot on am437x-gp-evm Signed-off-by: Balaji T K Signed-off-by: Mugunthan V N --- arch/arm/boot/dts/am437x-gp-evm.dts | 27 +++ 1 file changed, 27 insertions(+) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index 4eb72b8..df8798e 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -19,6 +19,14 @@ model = "TI AM437x GP EVM"; compatible = "ti,am437x-gp-evm","ti,am4372","ti,am43"; + vmmcsd_fixed: fixedregulator-sd { + compatible = "regulator-fixed"; + regulator-name = "vmmcsd_fixed"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + enable-active-high; + }; + backlight { compatible = "pwm-backlight"; pwms = <&ecap0 0 5 PWM_POLARITY_INVERTED>; @@ -62,6 +70,12 @@ >; }; + mmc1_pins: pinmux_mmc1_pins { + pinctrl-single,pins = < + 0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */ + >; + }; + ecap0_pins: backlight_pins { pinctrl-single,pins = < 0x164 MUX_MODE0 /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */ @@ -91,6 +105,10 @@ pinctrl-0 = <&ecap0_pins>; }; +&gpio0 { + status = "okay"; +}; + &gpio3 { status = "okay"; }; @@ -98,3 +116,12 @@ &gpio4 { status = "okay"; }; + +&mmc1 { + status = "okay"; + vmmc-supply = <&vmmcsd_fixed>; + bus-width = <4>; + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_pins>; + cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; +}; -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] phy: ti-pipe3: streamline PHY operations
Limit .power_on() and .power_off() to just control the PHY power and not the DPLL. The DPLL will be enabled in .init() and idled in .exit(). Don't reprogram the DPLL if it has been already locked by the bootloader. This fixes a problem with SATA, where it fails if SATA was used by the bootloader. Signed-off-by: Roger Quadros --- drivers/phy/phy-ti-pipe3.c | 114 + 1 file changed, 63 insertions(+), 51 deletions(-) diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c index ee8871d..d3c085a 100644 --- a/drivers/phy/phy-ti-pipe3.c +++ b/drivers/phy/phy-ti-pipe3.c @@ -47,7 +47,8 @@ #definePLL_SD_MASK 0x0003FC00 #definePLL_SD_SHIFT10 #defineSET_PLL_GO 0x1 -#definePLL_TICOPWDN0x1 +#define PLL_LDOPWDNBIT(15) +#define PLL_TICOPWDN BIT(16) #definePLL_LOCK0x2 #definePLL_IDLE0x1 @@ -56,7 +57,8 @@ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status * to be correctly reflected in the PIPE3PHY_PLL_STATUS register. */ -# define PLL_IDLE_TIME 100; +#define PLL_IDLE_TIME 100 /* in milliseconds */ +#define PLL_LOCK_TIME 100 /* in milliseconds */ struct pipe3_dpll_params { u16 m; @@ -132,24 +134,6 @@ static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(struct ti_pipe3 *phy) static int ti_pipe3_power_off(struct phy *x) { struct ti_pipe3 *phy = phy_get_drvdata(x); - int val; - int timeout = PLL_IDLE_TIME; - - val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2); - val |= PLL_IDLE; - ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val); - - do { - val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS); - if (val & PLL_TICOPWDN) - break; - udelay(5); - } while (--timeout); - - if (!timeout) { - dev_err(phy->dev, "power off failed\n"); - return -EBUSY; - } omap_control_phy_power(phy->control_dev, 0); @@ -159,44 +143,34 @@ static int ti_pipe3_power_off(struct phy *x) static int ti_pipe3_power_on(struct phy *x) { struct ti_pipe3 *phy = phy_get_drvdata(x); - int val; - int timeout = PLL_IDLE_TIME; - - val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2); - val &= ~PLL_IDLE; - ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val); - do { - val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS); - if (!(val & PLL_TICOPWDN)) - break; - udelay(5); - } while (--timeout); - - if (!timeout) { - dev_err(phy->dev, "power on failed\n"); - return -EBUSY; - } + omap_control_phy_power(phy->control_dev, 1); return 0; } -static void ti_pipe3_dpll_relock(struct ti_pipe3 *phy) +static int ti_pipe3_dpll_wait_lock(struct ti_pipe3 *phy) { u32 val; unsigned long timeout; - ti_pipe3_writel(phy->pll_ctrl_base, PLL_GO, SET_PLL_GO); - - timeout = jiffies + msecs_to_jiffies(20); + timeout = jiffies + msecs_to_jiffies(PLL_LOCK_TIME); do { + cpu_relax(); val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS); if (val & PLL_LOCK) break; - } while (!WARN_ON(time_after(jiffies, timeout))); + } while (!time_after(jiffies, timeout)); + + if (!(val & PLL_LOCK)) { + dev_err(phy->dev, "DPLL failed to lock\n"); + return -EBUSY; + } + + return 0; } -static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy) +static int ti_pipe3_dpll_program(struct ti_pipe3 *phy) { u32 val; struct pipe3_dpll_params *dpll_params; @@ -230,27 +204,65 @@ static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy) val |= dpll_params->sd << PLL_SD_SHIFT; ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION3, val); - ti_pipe3_dpll_relock(phy); + ti_pipe3_writel(phy->pll_ctrl_base, PLL_GO, SET_PLL_GO); - return 0; + return ti_pipe3_dpll_wait_lock(phy); } static int ti_pipe3_init(struct phy *x) { struct ti_pipe3 *phy = phy_get_drvdata(x); - int ret; + u32 val; + int ret = 0; - ret = ti_pipe3_dpll_lock(phy); - if (ret) - return ret; + /* Bring it out of IDLE if it is IDLE */ + val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2); + if (val & PLL_IDLE) { + val &= ~PLL_IDLE; + ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val); + ret = ti_pipe3_dpll_wait_lock(phy); + } - omap_control_phy_power(phy->control_dev, 1); + /* Program the DPLL only if not locked
[PATCH 08/12] ARM: dts: omap5: add sata node
From: Balaji T K Add support for sata. [Roger Q] Clean up. CC: Benoit Cousson CC: Tony Lindgren Signed-off-by: Balaji T K Signed-off-by: Roger Quadros --- arch/arm/boot/dts/omap5.dtsi | 40 1 file changed, 40 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index a7f5930..8e55e97 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -806,6 +806,46 @@ #thermal-sensor-cells = <1>; }; + + omap_control_sata: control-phy@4a002374 { + compatible = "ti,control-phy-pipe3"; + reg = <0x4a002374 0x4>; + reg-names = "power"; + clocks = <&sys_clkin>; + clock-names = "sysclk"; + }; + + /* OCP2SCP3 */ + ocp2scp@4a09 { + compatible = "ti,omap-ocp2scp"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x4a09 0x20>; + ranges; + ti,hwmods = "ocp2scp3"; + sata_phy: phy@4a096000 { + compatible = "ti,phy-pipe3-sata"; + reg = <0x4A096000 0x80>, /* phy_rx */ + <0x4A096400 0x64>, /* phy_tx */ + <0x4A096800 0x40>; /* pll_ctrl */ + reg-names = "phy_rx", "phy_tx", "pll_ctrl"; + ctrl-module = <&omap_control_sata>; + clocks = <&sys_clkin>; + clock-names = "sysclk"; + #phy-cells = <0>; + }; + }; + + sata: sata@4a141100 { + compatible = "snps,dwc-ahci"; + reg = <0x4a14 0x1100>, <0x4a141100 0x7>; + interrupts = ; + phys = <&sata_phy>; + phy-names = "sata-phy"; + clocks = <&sata_ref_clk>; + ti,hwmods = "sata"; + }; + }; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] ARM: dts: dra7: add OCP2SCP3 and SATA nodes
From: Balaji T K Add nodes for OCP2SCP3 bus, SATA controller and SATA PHY. [Roger Q] Clean up. CC: Benoit Cousson Signed-off-by: Balaji T K Signed-off-by: Roger Quadros --- arch/arm/boot/dts/dra7.dtsi | 39 +++ 1 file changed, 39 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 1fd75aa..74e44bc 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -621,6 +621,45 @@ dma-names = "tx0", "rx0"; status = "disabled"; }; + + omap_control_sata: control-phy@4a002374 { + compatible = "ti,control-phy-pipe3"; + reg = <0x4a002374 0x4>; + reg-names = "power"; + clocks = <&sys_clkin1>; + clock-names = "sysclk"; + }; + + /* OCP2SCP3 */ + ocp2scp@4a09 { + compatible = "ti,omap-ocp2scp"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + reg = <0x4a09 0x20>; + ti,hwmods = "ocp2scp3"; + sata_phy: phy@4A096000 { + compatible = "ti,phy-pipe3-sata"; + reg = <0x4A096000 0x80>, /* phy_rx */ + <0x4A096400 0x64>, /* phy_tx */ + <0x4A096800 0x40>; /* pll_ctrl */ + reg-names = "phy_rx", "phy_tx", "pll_ctrl"; + ctrl-module = <&omap_control_sata>; + clocks = <&sys_clkin1>; + clock-names = "sysclk"; + #phy-cells = <0>; + }; + }; + + sata: sata@4a141100 { + compatible = "snps,dwc-ahci"; + reg = <0x4a14 0x1100>, <0x4a141100 0x7>; + interrupts = ; + phys = <&sata_phy>; + phy-names = "sata-phy"; + clocks = <&sata_ref_clk>; + ti,hwmods = "sata"; + }; }; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
From: Nikhil Devshatwar Add hwmods for ocp2scp3 and sata modules. [Roger Q] Clean up. CC: Benoit Cousson CC: Paul Walmsley Signed-off-by: Balaji T K Signed-off-by: Nikhil Devshatwar Signed-off-by: Roger Quadros --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++ 1 file changed, 36 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index 18f333c..c180b54 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -1215,6 +1215,40 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = { }, }; +/* ocp2scp3 */ +static struct omap_hwmod dra7xx_ocp2scp3_hwmod; +static struct omap_hwmod_addr_space dra7xx_ocp2scp3_addrs[] = { + { + .name = "ocp2scp3", + .pa_start = 0x4a09, + .pa_end = 0x4a09001f, + .flags = ADDR_TYPE_RT + }, + { } +}; + +/* l4_cfg -> ocp2scp3 */ +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = { + .master = &dra7xx_l4_cfg_hwmod, + .slave = &dra7xx_ocp2scp3_hwmod, + .clk= "l4_root_clk_div", + .addr = dra7xx_ocp2scp3_addrs, + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = { + .name = "ocp2scp3", + .class = &dra7xx_ocp2scp_hwmod_class, + .clkdm_name = "l3init_clkdm", + .prcm = { + .omap4 = { + .clkctrl_offs = DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET, + .context_offs = DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET, + .modulemode = MODULEMODE_HWCTRL, + }, + }, +}; + /* * 'qspi' class * @@ -1268,9 +1302,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = { }; /* sata */ -static struct omap_hwmod_opt_clk sata_opt_clks[] = { - { .role = "ref_clk", .clk = "sata_ref_clk" }, -}; static struct omap_hwmod dra7xx_sata_hwmod = { .name = "sata", @@ -1278,6 +1309,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = { .clkdm_name = "l3init_clkdm", .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY, .main_clk = "func_48m_fclk", + .mpu_rt_idx = 1, .prcm = { .omap4 = { .clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET, @@ -1285,8 +1317,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = { .modulemode = MODULEMODE_SWCTRL, }, }, - .opt_clks = sata_opt_clks, - .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks), }; /* @@ -2683,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_per1__mmc4, &dra7xx_l4_cfg__mpu, &dra7xx_l4_cfg__ocp2scp1, + &dra7xx_l4_cfg__ocp2scp3, &dra7xx_l3_main_1__qspi, &dra7xx_l4_cfg__sata, &dra7xx_l4_cfg__smartreflex_core, -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] phy: ti-pipe3: Fix suspend/resume and module reload
Due to Errata i783, SATA breaks if its DPLL is idled. The recommeded workaround to issue a softreset to the SATA controller doesn't seem to work. Here we just prevent SATA DPLL from Idling and hence avoid the issue altogether. Signed-off-by: Roger Quadros --- drivers/phy/phy-ti-pipe3.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c index d3c085a..611f7c3 100644 --- a/drivers/phy/phy-ti-pipe3.c +++ b/drivers/phy/phy-ti-pipe3.c @@ -238,6 +238,10 @@ static int ti_pipe3_exit(struct phy *x) u32 val; unsigned long timeout; + /* SATA DPLL can't be powered down due to Errata i783 */ + if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata")) + return 0; + /* Put DPLL in IDLE mode */ val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2); val |= PLL_IDLE; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] phy: omap-control: Update DT binding information
Move omap-control binding information to the right location. Signed-off-by: Roger Quadros --- Documentation/devicetree/bindings/phy/ti-phy.txt | 25 ++ Documentation/devicetree/bindings/usb/omap-usb.txt | 24 - 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 207e14c..41dc132 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -1,5 +1,30 @@ TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs +OMAP CONTROL PHY + +Required properties: + - compatible: Should be one of + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4. + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register +e.g. USB2_PHY on OMAP5. + "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control +e.g. USB3 PHY and SATA PHY on OMAP5. + "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on +DRA7 platform. + "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on +AM437 platform. + - reg : Address and length of the register set for the device. It contains + the address of "otghs_control" for control-phy-otghs or "power" register + for other types. + - reg-names: should be "otghs_control" control-phy-otghs and "power" for + other types. + +omap_control_usb: omap-control-usb@4a002300 { +compatible = "ti,control-phy-otghs"; +reg = <0x4a00233c 0x4>; +reg-names = "otghs_control"; +}; + OMAP USB2 PHY Required properties: diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index c495135..38b2fae 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -76,27 +76,3 @@ omap_dwc3 { ranges; }; -OMAP CONTROL USB - -Required properties: - - compatible: Should be one of - "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4. - "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register - e.g. USB2_PHY on OMAP5. - "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control - e.g. USB3 PHY and SATA PHY on OMAP5. - "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on - DRA7 platform. - "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on - AM437 platform. - - reg : Address and length of the register set for the device. It contains - the address of "otghs_control" for control-phy-otghs or "power" register - for other types. - - reg-names: should be "otghs_control" control-phy-otghs and "power" for - other types. - -omap_control_usb: omap-control-usb@4a002300 { - compatible = "ti,control-phy-otghs"; - reg = <0x4a00233c 0x4>; - reg-names = "otghs_control"; -}; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] phy: rename struct omap_control_usb to struct omap_control_phy
From: Kishon Vijay Abraham I Rename struct omap_control_usb to struct omap_control_phy since it can be used to control PHY of USB, SATA and PCIE. Also move the driver and include files under *phy* and made the corresponding changes in the users of phy-omap-control. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Roger Quadros --- drivers/phy/Kconfig | 14 +- drivers/phy/Makefile | 1 + drivers/phy/phy-omap-control.c | 320 +++ drivers/phy/phy-omap-usb2.c | 8 +- drivers/phy/phy-ti-pipe3.c | 8 +- drivers/usb/musb/omap2430.c | 2 +- drivers/usb/phy/Kconfig | 10 -- drivers/usb/phy/Makefile | 1 - drivers/usb/phy/phy-omap-control.c | 319 -- include/linux/phy/omap_control_phy.h | 89 ++ include/linux/usb/omap_control_usb.h | 89 -- 11 files changed, 431 insertions(+), 430 deletions(-) create mode 100644 drivers/phy/phy-omap-control.c delete mode 100644 drivers/usb/phy/phy-omap-control.c create mode 100644 include/linux/phy/omap_control_phy.h delete mode 100644 include/linux/usb/omap_control_usb.h diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index bb238d4..2f02ec8 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -28,12 +28,22 @@ config PHY_MVEBU_SATA depends on OF select GENERIC_PHY +config OMAP_CONTROL_PHY + tristate "OMAP CONTROL PHY Driver" + help + Enable this to add support for the PHY part present in the control + module. This driver has API to power on the USB2 PHY and to write to + the mailbox. The mailbox is present only in omap4 and the register to + power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an + additional register to power on USB3 PHY/SATA PHY/PCIE PHY + (PIPE3 PHY). + config OMAP_USB2 tristate "OMAP USB2 PHY Driver" depends on ARCH_OMAP2PLUS depends on USB_PHY select GENERIC_PHY - select OMAP_CONTROL_USB + select OMAP_CONTROL_PHY help Enable this to support the transceiver that is part of SOC. This driver takes care of all the PHY functionality apart from comparator. @@ -44,7 +54,7 @@ config TI_PIPE3 tristate "TI PIPE3 PHY Driver" depends on ARCH_OMAP2PLUS || COMPILE_TEST select GENERIC_PHY - select OMAP_CONTROL_USB + select OMAP_CONTROL_PHY help Enable this to support the PIPE3 PHY that is part of TI SOCs. This driver takes care of all the PHY functionality apart from comparator. diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index 32e3f94..7518497 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -10,3 +10,4 @@ obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o +obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c new file mode 100644 index 000..17fc200 --- /dev/null +++ b/drivers/phy/phy-omap-control.c @@ -0,0 +1,320 @@ +/* + * omap-control-phy.c - The PHY part of control module. + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Author: Kishon Vijay Abraham I + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/** + * omap_control_phy_power - power on/off the phy using control module reg + * @dev: the control module device + * @on: 0 or 1, based on powering on or off the PHY + */ +void omap_control_phy_power(struct device *dev, int on) +{ + u32 val; + unsigned long rate; + struct omap_control_phy *control_phy; + + if (IS_ERR(dev) || !dev) { + pr_err("%s: invalid device\n", __func__); + return; + } + + control_phy = dev_get_drvdata(dev); + if (!control_phy) { + dev_err(dev, "%s: invalid control phy device\n", __func__); + return; + } + + if (control_phy->type == OMAP_CTRL_TYPE_OTGHS) + return; + + val = readl(control_phy->power); + + switch (control_phy->type) { + case OMAP_CTRL_TYPE_USB2: +
[PATCH 05/12] phy: ti-pipe3: Add SATA DPLL support
USB and SATA DPLLs need different settings. Provide the SATA DPLL settings and use the proper DPLL settings based on device tree node's compatible_id. Update the DT binding information. Signed-off-by: Roger Quadros --- Documentation/devicetree/bindings/phy/ti-phy.txt | 3 +- drivers/phy/phy-ti-pipe3.c | 76 +--- 2 files changed, 57 insertions(+), 22 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 41dc132..6a65081 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -49,7 +49,8 @@ usb2phy@4a0ad080 { TI PIPE3 PHY Required properties: - - compatible: Should be "ti,phy-usb3". "ti,omap-usb3" is deprecated. + - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata". + "ti,omap-usb3" is deprecated. - reg : Address and length of the register set for the device. - reg-names: The names of the register addresses corresponding to the registers filled in "reg". diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c index 3662e28..ee8871d 100644 --- a/drivers/phy/phy-ti-pipe3.c +++ b/drivers/phy/phy-ti-pipe3.c @@ -66,6 +66,11 @@ struct pipe3_dpll_params { u32 mf; }; +struct pipe3_dpll_map { + unsigned long rate; + struct pipe3_dpll_params params; +}; + struct ti_pipe3 { void __iomem*pll_ctrl_base; struct device *dev; @@ -73,20 +78,27 @@ struct ti_pipe3 { struct clk *wkupclk; struct clk *sys_clk; struct clk *optclk; + struct pipe3_dpll_map *dpll_map; }; -struct pipe3_dpll_map { - unsigned long rate; - struct pipe3_dpll_params params; -}; - -static struct pipe3_dpll_map dpll_map[] = { +static struct pipe3_dpll_map dpll_map_usb[] = { {1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */ {1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */ {1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */ {2000, {1000, 7, 4, 10, 0} }, /* 20 MHz */ {2600, {1250, 12, 4, 20, 0} }, /* 26 MHz */ {3840, {3125, 47, 4, 20, 92843} }, /* 38.4 MHz */ + { },/* Terminator */ +}; + +static struct pipe3_dpll_map dpll_map_sata[] = { + {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */ + {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */ + {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */ + {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */ + {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */ + {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */ + { },/* Terminator */ }; static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset) @@ -100,15 +112,20 @@ static inline void ti_pipe3_writel(void __iomem *addr, unsigned offset, __raw_writel(data, addr + offset); } -static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate) +static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(struct ti_pipe3 *phy) { - int i; + unsigned long rate; + struct pipe3_dpll_map *dpll_map = phy->dpll_map; - for (i = 0; i < ARRAY_SIZE(dpll_map); i++) { - if (rate == dpll_map[i].rate) - return &dpll_map[i].params; + rate = clk_get_rate(phy->sys_clk); + + for (; dpll_map->rate; dpll_map++) { + if (rate == dpll_map->rate) + return &dpll_map->params; } + dev_err(phy->dev, "No DPLL configuration for %lu Hz SYS CLK\n", rate); + return NULL; } @@ -182,16 +199,11 @@ static void ti_pipe3_dpll_relock(struct ti_pipe3 *phy) static int ti_pipe3_dpll_lock(struct ti_pipe3 *phy) { u32 val; - unsigned long rate; struct pipe3_dpll_params *dpll_params; - rate = clk_get_rate(phy->sys_clk); - dpll_params = ti_pipe3_get_dpll_params(rate); - if (!dpll_params) { - dev_err(phy->dev, - "No DPLL configuration for %lu Hz SYS CLK\n", rate); + dpll_params = ti_pipe3_get_dpll_params(phy); + if (!dpll_params) return -EINVAL; - } val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION1); val &= ~PLL_REGN_MASK; @@ -244,6 +256,10 @@ static struct phy_ops ops = { .owner = THIS_MODULE, }; +#ifdef CONFIG_OF +static const struct of_device_id ti_pipe3_id_table[]; +#endif + static int ti_pipe3_probe(struct platform_device *pdev) { struct ti_pipe3 *phy; @@ -253,8 +269,10 @@ static int ti_pipe3_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; struct device_node *control_node; struct platform_device *control_p
[PATCH 06/12] phy: omap: Select OMAP_OCP2SCP bus driver
The OMAP_USB2 and OMAP_PIP3 phy devices will not be detected if the OMAP_OCP2SCP driver is not present. So select it. Signed-off-by: Roger Quadros --- drivers/phy/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2f02ec8..afdab3e 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -44,6 +44,7 @@ config OMAP_USB2 depends on USB_PHY select GENERIC_PHY select OMAP_CONTROL_PHY + select OMAP_OCP2SCP help Enable this to support the transceiver that is part of SOC. This driver takes care of all the PHY functionality apart from comparator. @@ -55,6 +56,7 @@ config TI_PIPE3 depends on ARCH_OMAP2PLUS || COMPILE_TEST select GENERIC_PHY select OMAP_CONTROL_PHY + select OMAP_OCP2SCP help Enable this to support the PIPE3 PHY that is part of TI SOCs. This driver takes care of all the PHY functionality apart from comparator. -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] ARM: OMAP: SATA support for OMAP5 & DRA7
Hi, This series adds SATA support for OMAP5 uevm and DRA7-evm boards. - Cleans up the ti-pipe3 PHY driver - Adds SATA DPLL support to ti-pipe3 PHY driver - Adds SATA nodes to hwmod and SoC DT data Patches are based on [1]. To test SATA you will also need [2]. [1] - http://article.gmane.org/gmane.linux.kernel/1658825 [2] - http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7285 cheers, -roger --- Balaji T K (2): ARM: dts: omap5: add sata node ARM: dts: dra7: add OCP2SCP3 and SATA nodes Keshava Munegowda (1): ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods Kishon Vijay Abraham I (1): phy: rename struct omap_control_usb to struct omap_control_phy Nikhil Devshatwar (1): ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods Roger Quadros (7): phy: omap-control: Update DT binding information phy: ti-pipe3: cleanup clock handling ARM: dts: omap5: Add clocks to usb3_phy node phy: ti-pipe3: Add SATA DPLL support phy: omap: Select OMAP_OCP2SCP bus driver phy: ti-pipe3: streamline PHY operations phy: ti-pipe3: Fix suspend/resume and module reload Documentation/devicetree/bindings/phy/ti-phy.txt | 28 +- Documentation/devicetree/bindings/usb/omap-usb.txt | 24 -- arch/arm/boot/dts/dra7.dtsi| 39 +++ arch/arm/boot/dts/omap5.dtsi | 42 +++ arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 ++- drivers/phy/Kconfig| 16 +- drivers/phy/Makefile | 1 + drivers/phy/phy-omap-control.c | 320 + drivers/phy/phy-omap-usb2.c| 8 +- drivers/phy/phy-ti-pipe3.c | 257 ++--- drivers/usb/musb/omap2430.c| 2 +- drivers/usb/phy/Kconfig| 10 - drivers/usb/phy/Makefile | 1 - drivers/usb/phy/phy-omap-control.c | 319 include/linux/phy/omap_control_phy.h | 89 ++ include/linux/usb/omap_control_usb.h | 89 -- 17 files changed, 798 insertions(+), 561 deletions(-) create mode 100644 drivers/phy/phy-omap-control.c delete mode 100644 drivers/usb/phy/phy-omap-control.c create mode 100644 include/linux/phy/omap_control_phy.h delete mode 100644 include/linux/usb/omap_control_usb.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] ARM: dts: omap5: Add clocks to usb3_phy node
The pipe3-phy driver expects certain named clocks. Provide the necessary clocks. CC: Benoît Cousson CC: Tony Lindgren Signed-off-by: Roger Quadros --- arch/arm/boot/dts/omap5.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 1c68558..a7f5930 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -760,6 +760,8 @@ <0x4a084c00 0x40>; reg-names = "phy_rx", "phy_tx", "pll_ctrl"; ctrl-module = <&omap_control_usb3phy>; + clocks = <&usb_phy_cm_clk32k>, <&sys_clkin>; + clock-names = "wkupclk", "sysclk"; #phy-cells = <0>; }; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] phy: ti-pipe3: cleanup clock handling
As this driver is no longer USB specific, use generic clock names. - Fix PLL_SD_SHIFT from 9 to 10 - As optclk and wkupclk may not be always required, don't bail out if they aren't available. - Don't separate prepare/unprepare clock from enable/disable. This ensures optimal power savings. Signed-off-by: Roger Quadros --- drivers/phy/phy-ti-pipe3.c | 57 ++ 1 file changed, 27 insertions(+), 30 deletions(-) diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c index 54859fc..3662e28 100644 --- a/drivers/phy/phy-ti-pipe3.c +++ b/drivers/phy/phy-ti-pipe3.c @@ -45,7 +45,7 @@ #definePLL_SELFREQDCO_MASK 0x000E #definePLL_SELFREQDCO_SHIFT0x1 #definePLL_SD_MASK 0x0003FC00 -#definePLL_SD_SHIFT0x9 +#definePLL_SD_SHIFT10 #defineSET_PLL_GO 0x1 #definePLL_TICOPWDN0x1 #definePLL_LOCK0x2 @@ -270,23 +270,17 @@ static int ti_pipe3_probe(struct platform_device *pdev) phy->dev= &pdev->dev; - phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k"); - if (IS_ERR(phy->wkupclk)) { - dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n"); - return PTR_ERR(phy->wkupclk); - } - clk_prepare(phy->wkupclk); + phy->wkupclk = devm_clk_get(phy->dev, "wkupclk"); + if (IS_ERR(phy->wkupclk)) + dev_dbg(&pdev->dev, "unable to get wkupclk\n"); - phy->optclk = devm_clk_get(phy->dev, "usb_otg_ss_refclk960m"); - if (IS_ERR(phy->optclk)) { - dev_err(&pdev->dev, "unable to get usb_otg_ss_refclk960m\n"); - return PTR_ERR(phy->optclk); - } - clk_prepare(phy->optclk); + phy->optclk = devm_clk_get(phy->dev, "optclk"); + if (IS_ERR(phy->optclk)) + dev_dbg(&pdev->dev, "unable to get optclk\n"); - phy->sys_clk = devm_clk_get(phy->dev, "sys_clkin"); + phy->sys_clk = devm_clk_get(phy->dev, "sysclk"); if (IS_ERR(phy->sys_clk)) { - pr_err("%s: unable to get sys_clkin\n", __func__); + dev_err(&pdev->dev, "unable to get sysclk\n"); return -EINVAL; } @@ -326,10 +320,6 @@ static int ti_pipe3_probe(struct platform_device *pdev) static int ti_pipe3_remove(struct platform_device *pdev) { - struct ti_pipe3 *phy = platform_get_drvdata(pdev); - - clk_unprepare(phy->wkupclk); - clk_unprepare(phy->optclk); if (!pm_runtime_suspended(&pdev->dev)) pm_runtime_put(&pdev->dev); pm_runtime_disable(&pdev->dev); @@ -343,8 +333,10 @@ static int ti_pipe3_runtime_suspend(struct device *dev) { struct ti_pipe3 *phy = dev_get_drvdata(dev); - clk_disable(phy->wkupclk); - clk_disable(phy->optclk); + if (!IS_ERR(phy->wkupclk)) + clk_disable_unprepare(phy->wkupclk); + if (!IS_ERR(phy->optclk)) + clk_disable_unprepare(phy->optclk); return 0; } @@ -354,22 +346,27 @@ static int ti_pipe3_runtime_resume(struct device *dev) u32 ret = 0; struct ti_pipe3 *phy = dev_get_drvdata(dev); - ret = clk_enable(phy->optclk); - if (ret) { - dev_err(phy->dev, "Failed to enable optclk %d\n", ret); - goto err1; + if (!IS_ERR(phy->optclk)) { + ret = clk_prepare_enable(phy->optclk); + if (ret) { + dev_err(phy->dev, "Failed to enable optclk %d\n", ret); + goto err1; + } } - ret = clk_enable(phy->wkupclk); - if (ret) { - dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret); - goto err2; + if (!IS_ERR(phy->wkupclk)) { + ret = clk_prepare_enable(phy->wkupclk); + if (ret) { + dev_err(phy->dev, "Failed to enable wkupclk %d\n", ret); + goto err2; + } } return 0; err2: - clk_disable(phy->optclk); + if (!IS_ERR(phy->optclk)) + clk_disable_unprepare(phy->optclk); err1: return ret; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
From: Keshava Munegowda Create hwmods for ocp2scp3 and sata modules. [Roger Q] Clean up. CC: Benoit Cousson CC: Paul Walmsley CC: Tony Lindgren Signed-off-by: Balaji T K Signed-off-by: Roger Quadros --- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 ++ 1 file changed, 73 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c index e297d62..227a69f 100644 --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c @@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = { }, }; +/* + * 'ocp2scp' class + * bridge to transform ocp interface protocol to scp (serial control port) + * protocol + */ +/* ocp2scp3 */ +static struct omap_hwmod omap54xx_ocp2scp3_hwmod; +/* l4_cfg -> ocp2scp3 */ +static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = { + .master = &omap54xx_l4_cfg_hwmod, + .slave = &omap54xx_ocp2scp3_hwmod, + .clk= "l4_root_clk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +static struct omap_hwmod omap54xx_ocp2scp3_hwmod = { + .name = "ocp2scp3", + .class = &omap54xx_ocp2scp_hwmod_class, + .clkdm_name = "l3init_clkdm", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET, + .context_offs = OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET, + .modulemode = MODULEMODE_HWCTRL, + }, + }, +}; + +/* + * 'sata' class + * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx) + */ + +static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = { + .sysc_offs = 0x, + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO | + MSTANDBY_SMART | MSTANDBY_SMART_WKUP), + .sysc_fields= &omap_hwmod_sysc_type2, +}; + +static struct omap_hwmod_class omap54xx_sata_hwmod_class = { + .name = "sata", + .sysc = &omap54xx_sata_sysc, +}; + +/* sata */ +static struct omap_hwmod omap54xx_sata_hwmod = { + .name = "sata", + .class = &omap54xx_sata_hwmod_class, + .clkdm_name = "l3init_clkdm", + .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY, + .main_clk = "func_48m_fclk", + .mpu_rt_idx = 1, + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET, + .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET, + .modulemode = MODULEMODE_SWCTRL, + }, + }, +}; + +/* l4_cfg -> sata */ +static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = { + .master = &omap54xx_l4_cfg_hwmod, + .slave = &omap54xx_sata_hwmod, + .clk= "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; /* * Interfaces @@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = { &omap54xx_l4_cfg__usb_tll_hs, &omap54xx_l4_cfg__usb_otg_ss, &omap54xx_l4_wkup__wd_timer2, + &omap54xx_l4_cfg__ocp2scp3, + &omap54xx_l4_cfg__sata, NULL, }; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/6] Make dwc3 use Generic PHY Framework
Hi, On Mon, Mar 03, 2014 at 05:08:09PM +0530, Kishon Vijay Abraham I wrote: > Added support for optional PHY in dwc3 as not all SoCs having PHYs for DWC3 > should be programmed. While this can be considered as a temporary fix, > a long term solution would be to add 'nop' PHY for platforms that does > not have programmable PHY. > Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also changed the > name of USB3 PHY driver to PIPE3 PHY driver since the same driver has to > be used for SATA and PCIE too. > > Changes from v4: (sending the entire patch series again) > * check the return values of phy_init and phy_power_on > * print errors if power_on or power_off of PHY fails. > > Changes from v3: (Sent only adapt dwc3 core to use Generic PHY Framework) > * avoided using quirks and rely on the return values of PHY APIs to find the > presence of PHY. > > Changes from v2: > * added a couple of fixes. One is invoking phy_resume after phy_init and the > other is power off phy in error patch > * used quirks to identify if a particular platform does not have PHYs > * removed using separate header for pipe3 driver and also removed all > referencs > to SATA and PCIe in pipe3 driver since it's not yet adapted for those drivers. > > Changes from v1: > * The logic in which the driver detects the presence of PHYs has changed. > * patch ordering has changed > * udelay is replaced with usleep_range > * A patch to remove set_suspend callback which was deferred from Generic > PHY Framework series has been included. > > Kishon Vijay Abraham I (6): > usb: dwc3: core: support optional PHYs > usb: dwc3: adapt dwc3 core to use Generic PHY Framework > drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework > usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 > phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ > arm/dts: added dt properties to adapt to the new phy framwork patches 1 and 2 are in my testing/next, I guess 3,4,5 and 6 have no direct dependency on those, right ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling
* Sørensen, Stefan [140303 03:08]: > On Sun, 2014-03-02 at 09:37 -0800, Tony Lindgren wrote: > > * Sørensen, Stefan [140301 02:02]: > > > On Fri, 2014-02-28 at 09:11 -0800, Tony Lindgren wrote: > > > > * Stefan Sørensen [140224 02:12]: > > > > > Currently INTC interrupts are handled using handle_level_irq which > > > > > will acknowledge the interrupt before running the handler. If a second > > > > > interrupt is then asserted and this interrupt is disabled while > > > > > running the first handler, the INTC will be brought into an > > > > > inconsistent state. > > > > > > > > Hmm care to explain a bit more here if the second interrupt you're > > > > talking about is the same interrupt or any interrupt in the same > > > > interrupt bank? Is this limited to GPIO interrupts? > > > > > > I am seeing it with the cpsw driver on a custom board and on the > > > beaglebone. When a tx irq is handled the cpsw irq handler disables both > > > the tx and the rx irqs, and if the rx irq was also asserted (i.e. duplex > > > traffic), this bug will trigger. Reproducing it is very simple, just hit > > > a beaglebone with a flood ping and watch a function trace. > > > > OK so it's for the same interrupt. And that sounds like a good test :) > > No, the tx and rx are separate interrupts, but the cpsw driver has a > common handler. Oh OK sounds like that's where the problem is :) > > > > The reason I'm asking is because of the issues we've seen earlier > > > > with not flushing posted writes from the interrupt handlers. In > > > > those case the interrupt on the device gets acked too late without > > > > the read back call. > > > > > > I am not very familiar with the low level details of the irq handling, > > > but am335x TRM states that a data synchronization barrier should be used > > > after the ACK is posted to the INTC, and I don't see that anywhere in > > > the code. Is this related? > > > > Well sort of, except DSB won't do it as it won't guarantee the write > > gets to the device on the bus. So a readback from the device is needed > > as only the order of reads and writes is guaranteed. > > I think that we are talking about two different scenarios, what I am > seeing is that an interrupt is disabled while active on the INTC. Yes sounds like these are different issues. > 1. CPSW device asserts TX IRQ > 2. CPSW device asserts RX IRQ > 3. INTC interrupts CPU, TX IRQ marked as active > 4. omap_intc_handle_irq ACKs TX IRQ on the INTC > 5. INTC marks RX IRQ as active > 6. omap_intc_handle_irq calls cpsw_interrupt > 7. cpsw_interrupt disables RX+TX IRQ in CPSW device > 8. cpsw_interrupt disables RX+TX IRQ in INTC (the IRQs are masked) > 9.. omap_intc_handle_irq sees no unmasked IRQs are pending and returns > 10. INTC interrupts CPU, RX IRQ marked as pending > 11. omap_intc_handle_irq sees no unmasked IRQs are pending and returns > 12. Go to step 10 > > The problem arises in step 8 where an active IRQ is masked. This will > not make it inactive in the INTC but it will be cleared from the > pending IRQ registers - this is the register that omap_intc_handle_irq > uses to decide which IRQ is active. OK thanks for the info. Looking at your trace above it seems like the two separate TX and RX INTC interrupts are not really treated as separate interrupts in the cpsw driver. It seems the real fix is to fix up the cpsw interrupt handler so it's not racy. It seems that at least step 7 and 8 above should be handled separately for TX and RX based on the INTC interrupts. >From the INTC point of view we should just have standard level IRQ handling for each interrupt, right? INTC does not need to know about driver specific coordination between two separate interrupts. > > A good sanity check would be to find the related interrupt handler(s) > > in the cpsw driver that do the write to the cpsw registers to ack > > interrupts. > > > > Then check if there's a readback in the cpsw interrupt handler(s) of > > some harmless cpsw register after acking the interrupt(s) and before > > doing return IRQ_HANDLED. > > > > If this fixes things without your patch, then we know it's a driver > > issue and there's no need to debug it further :) The missing flush of > > posted write usually shows up as a spurious interrupts with no status > > in the device, but depending on the driver code handling of spurious > > interrupts it may also have other side effects. > > > > I'm not too familiar with the cpsw driver so I can't do a test patch > > without digging into it further sorry. For similar examples, you > > may want to grep for "flush posted write" and "OCP barrier" in the > > kernel code. > > I tried this with an assortment of different CPSW registers - no change. OK thanks for trying. Based on your description above it seems that the problem you found is not related to flushing posted writes even though that issue might be there also once race issue is fixe
Re: [PATCH] sound: omap: n810: fix init with DT boot
On 03/01/2014 08:08 PM, Aaro Koskinen wrote: > Since 3.14-rc1 only DT boot has been supported on N810. Make a minimal > fix to retain functionality. This file should be properly converted > to DT in longer term. > > Signed-off-by: Aaro Koskinen > --- > sound/soc/omap/n810.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Right, so there is actually regression. Can you get codec to probe? I get this when drivers are modules: tlv320aic3x-codec: probe of 1-0018 failed with error -16 I don't see quickly from where this -EBUSY comes but arch/arm/mach-omap2/board-n8x0.c seems to register it since module is loaded. With your patch basic n810 machine driver probing works again although audio card is not registered for me due failing codec probe. Please resend you fix and cc maintainers Mark Brown and Liam Girdwood . You can add my ack Acked-by: Jarkko Nikula -- 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: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
Ohad, On 03/02/2014 02:19 PM, Bjorn Andersson wrote: On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen wrote: On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna wrote: On 02/07/2014 04:49 PM, Bjorn Andersson wrote: It seems to be standard practice to pass the error value back to the consumer, so you should return ERR_PTR(ret); here instead of the NULL... I have modelled the return values in this function based on the return values in the existing hwspin_lock_request interfaces. I would need to change those functions as well. Ohad, Do you have any objections to the return code convention change? Unless strictly needed, I prefer we don't switch to the ERR_PTR code convention, as it reduces code readability and increases chances of user bugs. From a current user/client perspectives, I didn't find any clients of hwspinlock within the kernel. So, this is probably the right time to change the return code convention. In our case, switching to ERR_PTR and friends seems only to optimize a few error paths, and I'm not sure it's a big win over simplicity. The usage on the clients will also not become too complicated. The only change on the clients is mostly the base error check change from if (!hwlock) to if (IS_ERR(hwlock)). regards Suman When introducing the ability to reference a hwspin lock via a phandle in device tree it makes a big difference to be able to differ between the case of "initialization failed" or "device not yet probed"; so that the client knows if it should fail or retry later. Regards, Bjorn -- 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/12] ARM: OMAP2 DT clock conversion
* Tero Kristo [140303 00:20]: > On 02/28/2014 08:33 PM, Tony Lindgren wrote: > >* Tero Kristo [140228 10:21]: > >> > >>Hmm, some clock node is broken, might be missing a name or parent > >>name for some reason. Can you try to boot with DEBUG enabled so you > >>get pr_debug:s out and see which clock is being initialized during > >>the crash? > > > >... > >[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: > >initializing: core_d18_ck > >[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: > >initializing: vlynq_mux_fck > >[0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: > >initializing: vlynq_fck > >[0.00] Unable to handle kernel NULL pointer dereference at virtual > >address > >... > > > >We really should be registering the clocks lazily as needed BTW. That > >leaves out the dependency to DEBUG_LL for seeing any kind of decent > >error messages during the booting. > > > >Regards, > > > >Tony > > > > Hey Tony, > > Can you retry with the branch? I just pushed one patch there, seems > the parents for the vlynq_mux_fck were somewhat broken (there are > holes in the valid mux values list, which hasn't happened with any > other mux-clock so far.) > > If this works, I will rework the series a bit and send v2 out. > Alternatively I need to add extra debug info. Still getting this without omap3: drivers/built-in.o: In function `of_ti_dpll_setup': /home/tmlind/src/linux-2.6/drivers/clk/ti/dpll.c:235: undefined reference to `clkhwops_omap3_dpll' drivers/built-in.o:(.rodata+0x1d7a0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0x1d7a4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0x1d7b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1d7c4): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0x1d808): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1d84c): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1d860): undefined reference to `omap3_noncore_dpll_set_rate' and after enabling omap3 getting this without 2430: drivers/built-in.o: In function `of_ti_omap2430_interface_clk_setup': /home/tmlind/src/linux-2.6/drivers/clk/ti/interface.c:129: undefined reference to `clkhwops_omap2430_i2chs_wait' But after enabling those, it now boots on n8x0. The dmesg is below. Care to post a patch to try dropping the legacy clock data as it should now work with the DT clocks only for omap2? Regards, Tony [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-rc5-00014-g2297f72-dirty (tmlind@muffinssi) (gcc version 4.3.5 (Debian 4.3.5-4) ) #388 Mon Mar 3 10:38:58 PST 2014 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387d [0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Nokia N800 [0.00] bootconsole [earlycon0] enabled [0.00] debug: ignoring loglevel setting. [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 32512 [0.00] free_area_init_node: node 0, pgdat c07969a8, node_mem_map c7df9000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32512 pages, LIFO batch:7 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP2420 [0.00] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk ignore_loglevel [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 115492K/130048K available (5098K kernel code, 457K rwdata, 1884K rodata, 304K init, 5485K bss, 14556K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06d9e10 (6984 kB) [0.00] .init : 0xc06da000 - 0xc072601c ( 305 kB) [0.00] .data : 0xc0728000 - 0xc079a690 ( 458 kB) [0.00].bss : 0xc079a690 - 0xc0cf5b10 (5486 kB) [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96 inte
Re: [PATCH 06/12] phy: omap: Select OMAP_OCP2SCP bus driver
* Roger Quadros [140303 07:11]: > The OMAP_USB2 and OMAP_PIP3 phy devices will not be > detected if the OMAP_OCP2SCP driver is not present. > So select it. Selecting drivers like this will easily lead into missing dependencies. Especially it's bad for tristate driver options that people may want to have as loadable modules. How about instead depends on OMAP_OCP2SCP? Regards, Tony > Signed-off-by: Roger Quadros > --- > drivers/phy/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 2f02ec8..afdab3e 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -44,6 +44,7 @@ config OMAP_USB2 > depends on USB_PHY > select GENERIC_PHY > select OMAP_CONTROL_PHY > + select OMAP_OCP2SCP > help > Enable this to support the transceiver that is part of SOC. This > driver takes care of all the PHY functionality apart from comparator. > @@ -55,6 +56,7 @@ config TI_PIPE3 > depends on ARCH_OMAP2PLUS || COMPILE_TEST > select GENERIC_PHY > select OMAP_CONTROL_PHY > + select OMAP_OCP2SCP > help > Enable this to support the PIPE3 PHY that is part of TI SOCs. This > driver takes care of all the PHY functionality apart from comparator. > -- > 1.8.3.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion
On 03/03/2014 08:46 PM, Tony Lindgren wrote: * Tero Kristo [140303 00:20]: On 02/28/2014 08:33 PM, Tony Lindgren wrote: * Tero Kristo [140228 10:21]: Hmm, some clock node is broken, might be missing a name or parent name for some reason. Can you try to boot with DEBUG enabled so you get pr_debug:s out and see which clock is being initialized during the crash? ... [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: core_d18_ck [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_mux_fck [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_fck [0.00] Unable to handle kernel NULL pointer dereference at virtual address ... We really should be registering the clocks lazily as needed BTW. That leaves out the dependency to DEBUG_LL for seeing any kind of decent error messages during the booting. Regards, Tony Hey Tony, Can you retry with the branch? I just pushed one patch there, seems the parents for the vlynq_mux_fck were somewhat broken (there are holes in the valid mux values list, which hasn't happened with any other mux-clock so far.) If this works, I will rework the series a bit and send v2 out. Alternatively I need to add extra debug info. Still getting this without omap3: drivers/built-in.o: In function `of_ti_dpll_setup': /home/tmlind/src/linux-2.6/drivers/clk/ti/dpll.c:235: undefined reference to `clkhwops_omap3_dpll' drivers/built-in.o:(.rodata+0x1d7a0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0x1d7a4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0x1d7b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1d7c4): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0x1d808): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1d84c): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1d860): undefined reference to `omap3_noncore_dpll_set_rate' and after enabling omap3 getting this without 2430: drivers/built-in.o: In function `of_ti_omap2430_interface_clk_setup': /home/tmlind/src/linux-2.6/drivers/clk/ti/interface.c:129: undefined reference to `clkhwops_omap2430_i2chs_wait' Yea, I didn't fix these with the patch I pushed, just the boot problem. I will fix these with the next version of the set, in addition to the issues reported by Nishanth. But after enabling those, it now boots on n8x0. The dmesg is below. This is good, so the culprit was only the vlynq fck. Care to post a patch to try dropping the legacy clock data as it should now work with the DT clocks only for omap2? Yes, I can post patches for this for omap2/omap3 also tomorrow. -Tero Regards, Tony [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.14.0-rc5-00014-g2297f72-dirty (tmlind@muffinssi) (gcc version 4.3.5 (Debian 4.3.5-4) ) #388 Mon Mar 3 10:38:58 PST 2014 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387d [0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Nokia N800 [0.00] bootconsole [earlycon0] enabled [0.00] debug: ignoring loglevel setting. [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 32512 [0.00] free_area_init_node: node 0, pgdat c07969a8, node_mem_map c7df9000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32512 pages, LIFO batch:7 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP2420 [0.00] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk ignore_loglevel [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 115492K/130048K available (5098K kernel code, 457K rwdata, 1884K rodata, 304K init, 5485K bss, 14556K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06d9e10 (6984 kB) [0.00] .init : 0xc06da000 - 0xc072601c (
Re: [PATCH 02/12] phy: omap-control: Update DT binding information
* Roger Quadros [140303 07:10]: > Move omap-control binding information to the right location. > > Signed-off-by: Roger Quadros > --- > Documentation/devicetree/bindings/phy/ti-phy.txt | 25 > ++ > Documentation/devicetree/bindings/usb/omap-usb.txt | 24 - > 2 files changed, 25 insertions(+), 24 deletions(-) > > diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt > b/Documentation/devicetree/bindings/phy/ti-phy.txt > index 207e14c..41dc132 100644 > --- a/Documentation/devicetree/bindings/phy/ti-phy.txt > +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt > @@ -1,5 +1,30 @@ > TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs > > +OMAP CONTROL PHY > + > +Required properties: > + - compatible: Should be one of > + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on > OMAP4. > + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf > register > +e.g. USB2_PHY on OMAP5. > + "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control > +e.g. USB3 PHY and SATA PHY on OMAP5. > + "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on > +DRA7 platform. > + "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on > +AM437 platform. To me it seems that you can leave out all the above. You can set these falgs flags directly in the driver based on the compatible flag. Then just initialize the .data in the driver based on the compatible flag. > + - reg : Address and length of the register set for the device. It contains > + the address of "otghs_control" for control-phy-otghs or "power" register > + for other types. > + - reg-names: should be "otghs_control" control-phy-otghs and "power" for > + other types. > + > +omap_control_usb: omap-control-usb@4a002300 { > +compatible = "ti,control-phy-otghs"; > +reg = <0x4a00233c 0x4>; > +reg-names = "otghs_control"; > +}; Then you would instead have something like this: compatible = "ti,am347-control-phy-otghs"; That way you can initialize things without a need for custom bindings. 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
Ethernet controller not starting
I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now the latest LTS kernel). I found that Ethernet controller on the board no longer comes up on linux-3.12. I was able to bisect the issue I'm having to the following commit: > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit > commit 45f0a85c8258741d11bda25c0a5669c06267204a > Author: Rafael J. Wysocki > Date: Mon Jun 3 21:49:52 2013 +0200 > > PM / Runtime: Rework the "runtime idle" helper routine > > The "runtime idle" helper routine, rpm_idle(), currently ignores > return values from .runtime_idle() callbacks executed by it. > However, it turns out that many subsystems use > pm_generic_runtime_idle() which checks the return value of the > driver's callback and executes pm_runtime_suspend() for the device > unless that value is not 0. If that logic is moved to rpm_idle() > instead, pm_generic_runtime_idle() can be dropped and its users > will not need any .runtime_idle() callbacks any more. > > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and > ata_port_runtime_idle(), respectively, as well as a few drivers' > ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has > been returned by the .runtime_idle() callback executed by it. > > To reduce overall code bloat, make the changes described above. > > Tested-by: Mika Westerberg > Tested-by: Kevin Hilman > Signed-off-by: Rafael J. Wysocki > Acked-by: Kevin Hilman > Reviewed-by: Ulf Hansson > Acked-by: Alan Stern Can anyone offer any suggestions on what I should be looking for to fix this on my board? Thanks, 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: [GIT PULL] ARM: OMAP: Device Tree for 3.15
On 02/03/2014 23:17, Tony Lindgren wrote: * Benoit Cousson [140302 12:45]: Hi Tony, Please pull the following commits for OMAP Device Tree for v3.15. Thanks pulling into omap-for-v3.15/dt. Thank you Tony. Regards, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
On 28/02/2014 23:17, Tony Lindgren wrote: * Jack Mitchell [140122 03:09]: From: Jack Mitchell Devicetree include file for setting up the am335x mcasp bus, i2c-2 bus, and audio codec required for a functioning BeagleBone Audio Cape. Signed-off-by: Jack Mitchell Signed-off-by: Matt Porter --- arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 + arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++ 2 files changed, 138 insertions(+) create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi new file mode 100644 index 000..b8ec3dc --- /dev/null +++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi @@ -0,0 +1,124 @@ +/* + * Copyright (C) 2014 Jack Mitchell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * In order to enable the BeagleBone Audio Cape this dtsi must be + * incuded in the top level dts. On BeagleBone Black hardware the + * status of the HDMI dts node must also be set to "disabled". Seems like this is unsafe to merge then? This probably also needs comments from Peter Ujfalusi, added him to Cc. Maybe, we'd better define a new DTS board (like am335x-boneblack-audio.dts) if we cannot use audio cape without losing the HDMI. Since we don't have mechanism like overlay, we don't have the choice but defining several boards for each cape variant. BTW, what is the conflict source with HDMI? At some point I remember that the mcasp for audio cape was broken because of changes in the mcasp for the HDMI, but it is not the case anymore, thanks to the cleanup from Jyri. + * --- a/arch/arm/boot/dts/am335x-bone.dts + * +++ b/arch/arm/boot/dts/am335x-bone.dts + * @@ -9,6 +9,7 @@ + * + * #include "am33xx.dtsi" + * #include "am335x-bone-common.dtsi" + * +#include "am335x-bone-audio-cape-reva.dtsi" + * + * &ldo3_reg { + * regulator-min-microvolt = <180>; + * + * On BeagleBone Black hardware the status of the HDMI dts node must + * also be set to "disabled" + * + * --- a/arch/arm/boot/dts/am335x-boneblack.dts + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts + * @@ -73,6 +74,6 @@ + * pinctrl-names = "default", "off"; + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>; + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; + * - status = "okay"; + * + status = "disabled"; + * }; + * }; + */ + +/ { + sound { + compatible = "ti,da830-evm-audio"; + ti,model = "AM335x BeagleBone Audio Cape Rev. A"; + ti,audio-codec = <&tlv320aic3106>; + ti,mcasp-controller = <&mcasp0>; + ti,codec-clock-rate = <1200>; + ti,audio-routing = + "Headphone Jack", "HPLOUT", + "Headphone Jack", "HPROUT", + "LINE1L", "Line In", + "LINE1R", "Line In"; + }; + + audio-cape-gpio-leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&bone_audio_cape_led_pins>; + + audio-led0 { + label = "audio:green:usr0"; + gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; + default-state = "off"; + }; + + audio-led1 { + label = "audio:green:usr1"; + gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "mmc0"; + default-state = "off"; + }; + }; +}; + +&am33xx_pinmux { + bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins { + pinctrl-single,pins = < + 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a2.gpio1_18 */ + 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a3.gpio1_19 */ + >; + }; + + bone_audio_cape_pins: bone_audio_cape_pins { + pinctrl-single,pins = < + 0x190 (PIN_INPUT_PULLUP | MUX_MODE0)/* mcasp0_aclkx.mcasp0_aclkx */ + 0x194 (PIN_INPUT_PULLUP | MUX_MODE0)/* mcasp0_fsx.mcasp0_fsx */ + 0x19c (PIN_INPUT_PULLUP | MUX_MODE2)/* mcasp0_ahclkr.mcasp0_axr2 */ + 0x1ac (PIN_INPUT_PULLUP | MUX_MODE2)/* mcasp0_ahclkx.mcasp0_axr3 */ + >; + }; +}; + +&i2c2 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c2_pins>; + + status = "okay"; + clock-frequency = <10>; + + tlv320aic3106: tlv320aic3106@1b { A more generic name will be prefered here. Re
Re: [PATCH 1/1] net: cpsw: fix cpdma rx descriptor leak on down interface
From: Mugunthan V N Date: Mon, 3 Mar 2014 16:19:06 +0530 > From: Schuyler Patton > > This patch fixes a CPDMA RX Descriptor leak that occurs after taking > the interface down when the CPSW is in Dual MAC mode. Previously > the CPSW_ALE port was left open up which causes packets to be received > and processed by the RX interrupt handler and were passed to the > non active network interface where they were ignored. > > The fix is for the slave_stop function of the selected interface > to disable the respective CPSW_ALE Port from forwarding packets. This > blocks traffic from being received on the inactive interface. > > Signed-off-by: Schuyler Patton > Reviewed-by: Felipe Balbi > Signed-off-by: Mugunthan V N Applied. -- 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 RESEND] mmc: omap_hsmmc: support more DT properties
This should probably be done implicitly through mmc_of_parse(), but that doesn't play well along with the multi-slot model the hsmmc driver features. Hence, for now, do it manually. The properties are already documented in Documentation/devicetree/bindings/mmc/mmc.txt. Signed-off-by: Daniel Mack Acked-by: Balaji T K --- This is a resend of a patch that was already acked by Balaji T K: http://www.spinics.net/lists/linux-mmc/msg25029.html drivers/mmc/host/omap_hsmmc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2815de6..a5a38cc 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev) if (of_find_property(np, "ti,needs-special-hs-handling", NULL)) pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT; + if (of_find_property(np, "keep-power-in-suspend", NULL)) + pdata->slots[0].pm_caps |= MMC_PM_KEEP_POWER; + + if (of_find_property(np, "enable-sdio-wakeup", NULL)) + pdata->slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ; + return pdata; } #else -- 1.8.5.3 -- 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 RESEND] sound: omap: n810: fix init with DT boot
Since 3.14-rc1 only DT boot has been supported on N810, so this file fails to init. Make a minimal fix to retain functionality. This file should be properly converted to DT in longer term. There seems to be still other unresolved issues with N810 audio support, but this patch is needed at minimum as otherwise the machine driver probing would completely fail. Signed-off-by: Aaro Koskinen Acked-by: Jarkko Nikula --- Previous discussion: http://marc.info/?l=linux-omap&m=139387208426122&w=2 sound/soc/omap/n810.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c index 3fde9e4..d163e18 100644 --- a/sound/soc/omap/n810.c +++ b/sound/soc/omap/n810.c @@ -305,7 +305,9 @@ static int __init n810_soc_init(void) int err; struct device *dev; - if (!(machine_is_nokia_n810() || machine_is_nokia_n810_wimax())) + if (!of_have_populated_dt() || + (!of_machine_is_compatible("nokia,n810") && +!of_machine_is_compatible("nokia,n810-wimax"))) return -ENODEV; n810_snd_device = platform_device_alloc("soc-audio", -1); -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ethernet controller not starting
On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: > I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now > the latest LTS kernel). > I found that Ethernet controller on the board no longer comes up on > linux-3.12. > I was able to bisect the issue I'm having to the following commit: > > > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit > > commit 45f0a85c8258741d11bda25c0a5669c06267204a > > Author: Rafael J. Wysocki > > Date: Mon Jun 3 21:49:52 2013 +0200 > > > > PM / Runtime: Rework the "runtime idle" helper routine > > > > The "runtime idle" helper routine, rpm_idle(), currently ignores > > return values from .runtime_idle() callbacks executed by it. > > However, it turns out that many subsystems use > > pm_generic_runtime_idle() which checks the return value of the > > driver's callback and executes pm_runtime_suspend() for the device > > unless that value is not 0. If that logic is moved to rpm_idle() > > instead, pm_generic_runtime_idle() can be dropped and its users > > will not need any .runtime_idle() callbacks any more. > > > > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() > > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and > > ata_port_runtime_idle(), respectively, as well as a few drivers' > > ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has > > been returned by the .runtime_idle() callback executed by it. > > > > To reduce overall code bloat, make the changes described above. > > > > Tested-by: Mika Westerberg > > Tested-by: Kevin Hilman > > Signed-off-by: Rafael J. Wysocki > > Acked-by: Kevin Hilman > > Reviewed-by: Ulf Hansson > > Acked-by: Alan Stern > > Can anyone offer any suggestions on what I should be looking for to > fix this on my board? Any pointers to the driver in question? Rafael -- 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: Ethernet controller not starting
On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki wrote: > On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: >> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now >> the latest LTS kernel). >> I found that Ethernet controller on the board no longer comes up on >> linux-3.12. >> I was able to bisect the issue I'm having to the following commit: >> >> > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit >> > commit 45f0a85c8258741d11bda25c0a5669c06267204a >> > Author: Rafael J. Wysocki >> > Date: Mon Jun 3 21:49:52 2013 +0200 >> > >> > PM / Runtime: Rework the "runtime idle" helper routine >> > >> > The "runtime idle" helper routine, rpm_idle(), currently ignores >> > return values from .runtime_idle() callbacks executed by it. >> > However, it turns out that many subsystems use >> > pm_generic_runtime_idle() which checks the return value of the >> > driver's callback and executes pm_runtime_suspend() for the device >> > unless that value is not 0. If that logic is moved to rpm_idle() >> > instead, pm_generic_runtime_idle() can be dropped and its users >> > will not need any .runtime_idle() callbacks any more. >> > >> > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() >> > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and >> > ata_port_runtime_idle(), respectively, as well as a few drivers' >> > ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has >> > been returned by the .runtime_idle() callback executed by it. >> > >> > To reduce overall code bloat, make the changes described above. >> > >> > Tested-by: Mika Westerberg >> > Tested-by: Kevin Hilman >> > Signed-off-by: Rafael J. Wysocki >> > Acked-by: Kevin Hilman >> > Reviewed-by: Ulf Hansson >> > Acked-by: Alan Stern >> >> Can anyone offer any suggestions on what I should be looking for to >> fix this on my board? > > Any pointers to the driver in question? drivers/net/ethernet/ti/davinci_emac.c I also get the following output: Starting Network Manager Wait Online... [ 30.946509] davinci_mdio davinci_mdio.0: resetting idled controller [ 30.953220] net net0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready [ 31.082087] genirq: Flags mismatch irq 33. (net0) vs. (net0) [ 31.089425] CPU: 0 PID: 679 Comm: NetworkManager Not tainted 3.12.13-fs1-003-g5ae24fe-dirty+ #1218 [ 31.098496] Function entered at [] from [] [ 31.104398] Function entered at [] from [] [ 31.110292] Function entered at [] from [] [ 31.116180] Function entered at [] from [] [ 31.122069] Function entered at [] from [] [ 31.127958] Function entered at [] from [] [ 31.133852] Function entered at [] from [] [ 31.139741] Function entered at [] from [] [ 31.145630] Function entered at [] from [] [ 31.151523] Function entered at [] from [] [ 31.157412] Function entered at [] from [] [ 31.163303] Function entered at [] from [] [ 31.169193] Function entered at [] from [] [ 31.175080] Function entered at [] from [] [ 31.180969] Function entered at [] from [] [ 31.186857] Function entered at [] from [] [ 31.192747] Function entered at [] from [] [ 31.198637] Function entered at [] from [] [ 31.204528] Function entered at [] from [] [ 31.210600] net net0: DaVinci EMAC: devm_request_irq() failed [FAILED] Failed to start Network Manager Wait Online. Putting a breakpoint on the genirq message, the backtrace is: #0 __setup_irq (irq=irq@entry=33, desc=desc@entry=0xc0d24b10 , new=new@entry=0xc0a6a320) at kernel/irq/manage.c:1177 #1 0xc0042fa4 in request_threaded_irq (irq=irq@entry=33, handler=handler@entry=0xc02a6bbc , thread_fn=thread_fn@entry=0x0 <__vectors_start>, irqflags=0, irqflags@entry=3234987536, devname=0xc2f87000 \"net0\", devname@entry=0xc02a7954 \"\", dev_id=dev_id@entry=0xc2f87000) at kernel/irq/manage.c:1438 #2 0xc0044794 in devm_request_threaded_irq (dev=0xc0d1e688 , irq=irq@entry=33, handler=handler@entry=0xc02a6bbc , thread_fn=thread_fn@entry=0x0 <__vectors_start>, irqflags=irqflags@entry=0, devname=devname@entry=0xc2f87000 \"net0\", dev_id=dev_id@entry=0xc2f87000) at kernel/irq/devres.c:60 #3 0xc02a7954 in devm_request_irq (dev_id=0xc2f87000, devname=0xc2f87000 \"net0\", irqflags=0, handler=0xc02a6bbc , irq=33, dev=) at include/linux/interrupt.h:158 #4 emac_dev_open (ndev=0xc2f87000) at drivers/net/ethernet/ti/davinci_emac.c:1569 #5 0xc03289b8 in __dev_open (dev=0xc2f87000) at net/core/dev.c:1256 #6 0xc0328bd8 in __dev_change_flags (dev=dev@entry=0xc2f87000, flags=4099) at net/core/dev.c:5042 #7 0xc0328ce4 in dev_change_flags (dev=dev@entry=0xc2f87000, flags=) at net/core/dev.c:5103 #8 0xc03340fc in do_setlink (dev=dev@entry=0xc2f87000, ifm=ifm@entry=0xc2e67ed0, tb=tb@entry=0xc0a5dc64, if
Re: [PATCH RESEND] sound: omap: n810: fix init with DT boot
On Tue, Mar 04, 2014 at 12:45:18AM +0200, Aaro Koskinen wrote: > Since 3.14-rc1 only DT boot has been supported on N810, so this > file fails to init. Make a minimal fix to retain functionality. > This file should be properly converted to DT in longer term. Applied, please remember to use subject lines consistent with those for the rest of the subsystem. signature.asc Description: Digital signature
Re: Help needed USB hub disconnected at resume
On 03/03/14 16:11, Marc Murphy wrote: > Hi Igor > > The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port > via the DUP_P and DUP_N pins. There is a reset applied to the chip at power > on. > If the reset signal is sw controllable, you might want to toggle it before the EHCI controller resumes. There is also a USB phy on the way from EHCI controller to the hub. You might also want to check if the phy resumes correctly. Which phy do you use and how is it reset? > Regards > Marc > > From: Igor Grinberg [grinb...@compulab.co.il] > Sent: 03 March 2014 12:16 > To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org > Subject: Re: Help needed USB hub disconnected at resume > > On 03/03/14 13:06, Roger Quadros wrote: >> Hi Marc, >> >> On 03/03/2014 12:04 PM, Marc Murphy wrote: >>> Hi, >>> I am using the latest stable 3.4.80 kernel with some changes to get the >>> EMAC Phy to initialise correctly after a suspend/resume. The platform is >>> AM3517 with most of the system working nice and smoothly. I have 1 issue >>> though and need some advice/help to get the system to use the USB hub I >>> have connected to the EHCI controller after a suspend to memory and resume. >>> >>> At boot all is recognised; >>> >>> [1.486816] usbcore: registered new interface driver cdc_ether >>> [1.493255] usbcore: registered new interface driver cdc_ncm >>> [1.499450] usbcore: registered new interface driver qmi_wwan >>> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver >>> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator >>> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller >>> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus >>> number 1 >>> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 >>> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 >>> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 >>> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, >>> SerialNumber=1 >>> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller >>> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd >>> [2.585296] usb usb1: SerialNumber: ehci-omap.0 >>> [2.591278] hub 1-0:1.0: USB hub found >>> [2.595306] hub 1-0:1.0: 3 ports detected >>> >>> And I can see everything OK. >>> >>> # lsusb >>> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub >>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. >>> # >>> # >>> # echo mem > /sys/power/state >>> [ 73.736572] PM: Syncing filesystems ... done. >>> [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) >>> done. >>> [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 >>> seconds) done. >>> [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle >>> [ 73.968872] PM: suspend of devices complete after 170.410 msecs >>> [ 73.975433] PM: late suspend of devices complete after 0.305 msecs >>> [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs >>> [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 >>> [ 83.436737] Could not enter target state in pm_suspend >>> [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs >>> [ 83.450164] PM: early resume of devices complete after 0.274 msecs >>> [ 83.457336] <6>Waiting for PHY clock good... >>> [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller >>> [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] >>> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) >>> [ 84.771881] PM: resume of devices complete after 1315.185 msecs >>> [ 84.778472] Restarting tasks ... >>> [ 84.782379] usb 1-1: USB disconnect, device number 2 >>> [ 84.790557] done. >>> [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz >>> sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 >>> Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister >>> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device >>> ermitted >>> [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz >>> [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full >>> # >>> # >>> # lsusb >>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> # >>> >>> Is there any relevant patch out there that would address the issue that I >>> see ? >> >> Does this happen because of OFF mode? >> Can you please try the tests with off mode disabled? >> >> e
[PATCHv7 0/4] power_supply: Introduce power supply charging driver
v1: introduced feature as a framework within power supply class driver with separate files for battid framework and charging framework v2: fixed review comments, moved macros and inline functions to power_supply.h v3: moved the feature as a separate driver, combined battid framework and charging framework inside the power supply charging driver. Moved charger specific properties to power_supply_charger.h and plugged the driver with power supply subsystem using power_supply_notifier introduced in my previous patch. Also a sample charger chip driver (bq24261) patch added to give more idea on the psy charging driver usage v4: Fixed review comments, no major design changes. v5: Fixed makefile inconsistencies, removed unused pdata callbacks v6: Fixed nested loops, commenting style v7: added kerneldocs for structs and minor fixes The Power Supply charging driver connects multiple subsystems to do charging in a generic way. The subsystems involves power_supply, thermal and battery communication subsystems (1wire).With this the charging is handled in a generic way. The driver makes use of different new features - Battery Identification interfaces, pluggable charging algorithms, charger cable arbitrations etc. The patch also introduces generic interface for charger cable notifications. Charger cable events and capabilities can be notified using the generic power_supply_notifier chain. Overall this driver removes the charging logic out of the charger chip driver and the charger chip driver can just listen to the request from the power supply charging driver to set the charger properties. This can be implemented by exposing get_property and set property callbacks. Jenny TC (4): power_supply: Add inlmt,iterm, min/max temp props power_supply: Introduce generic psy charging driver power_supply: Introduce PSE compliant algorithm power_supply: bq24261 charger driver Documentation/power/power_supply_charger.txt | 353 +++ Documentation/power/power_supply_class.txt |6 + drivers/power/Kconfig| 31 + drivers/power/Makefile |3 + drivers/power/bq24261-charger.c | 1350 ++ drivers/power/charging_algo_pse.c| 204 drivers/power/power_supply_charger.c | 1186 ++ drivers/power/power_supply_charger.h | 218 + drivers/power/power_supply_core.c|3 + drivers/power/power_supply_sysfs.c |4 + include/linux/power/bq24261-charger.h| 25 + include/linux/power/power_supply_charger.h | 341 +++ include/linux/power_supply.h | 164 13 files changed, 3888 insertions(+) create mode 100644 Documentation/power/power_supply_charger.txt create mode 100644 drivers/power/bq24261-charger.c create mode 100644 drivers/power/charging_algo_pse.c create mode 100644 drivers/power/power_supply_charger.c create mode 100644 drivers/power/power_supply_charger.h create mode 100644 include/linux/power/bq24261-charger.h create mode 100644 include/linux/power/power_supply_charger.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 4/4] power_supply: bq24261 charger driver
This patch introduces BQ24261 charger driver. The driver makes use of power supply charging driver to setup charging. So the driver does hardware abstraction and handles h/w specific corner cases. The charging logic resides with power supply charging driver Signed-off-by: Jenny TC --- drivers/power/Kconfig | 10 + drivers/power/Makefile|1 + drivers/power/bq24261-charger.c | 1350 + include/linux/power/bq24261-charger.h | 25 + 4 files changed, 1386 insertions(+) create mode 100644 drivers/power/bq24261-charger.c create mode 100644 include/linux/power/bq24261-charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 913ec36..a1c2780 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -409,6 +409,16 @@ config BATTERY_GOLDFISH Say Y to enable support for the battery and AC power in the Goldfish emulator. +config CHARGER_BQ24261 + tristate "BQ24261 charger driver" + select POWER_SUPPLY_CHARGER + depends on I2C + help + Say Y to include support for BQ24261 Charger driver. This driver + makes use of power supply charging driver. So the driver gives + the charger hardware abstraction only. Charging logic is abstracted + in the power supply charging driver. + source "drivers/power/reset/Kconfig" endif # POWER_SUPPLY diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 77535fd..9dde895 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o +obj-$(CONFIG_CHARGER_BQ24261) += bq24261-charger.o obj-$(CONFIG_POWER_RESET) += reset/ diff --git a/drivers/power/bq24261-charger.c b/drivers/power/bq24261-charger.c new file mode 100644 index 000..187c1fe --- /dev/null +++ b/drivers/power/bq24261-charger.c @@ -0,0 +1,1350 @@ +/* + * bq24261-charger.c - BQ24261 Charger I2C client driver + * + * Copyright (C) 2011 Intel Corporation + * + * ~~ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU + * General Public License for more details. + * + * ~~ + * Author: Jenny TC + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define DEV_NAME "bq24261_charger" +#define MODEL_NAME_SIZE 8 + +#define EXCEPTION_MONITOR_DELAY (60 * HZ) +#define WDT_RESET_DELAY (15 * HZ) + +/* BQ24261 registers */ +#define BQ24261_STAT_CTRL0_ADDR0x00 +#define BQ24261_CTRL_ADDR 0x01 +#define BQ24261_BATT_VOL_CTRL_ADDR 0x02 +#define BQ24261_VENDOR_REV_ADDR0x03 +#define BQ24261_TERM_FCC_ADDR 0x04 +#define BQ24261_VINDPM_STAT_ADDR 0x05 +#define BQ24261_ST_NTC_MON_ADDR0x06 + +#define BQ24261_RESET_MASK (0x01 << 7) +#define BQ24261_RESET_ENABLE (0x01 << 7) + +#define BQ24261_FAULT_MASK 0x07 +#define BQ24261_STAT_MASK (0x03 << 4) +#define BQ24261_BOOST_MASK (0x01 << 6) +#define BQ24261_TMR_RST_MASK (0x01 << 7) +#define BQ24261_TMR_RST(0x01 << 7) + +#define BQ24261_ENABLE_BOOST (0x01 << 6) + +#define BQ24261_VOVP 0x01 +#define BQ24261_LOW_SUPPLY 0x02 +#define BQ24261_THERMAL_SHUTDOWN 0x03 +#define BQ24261_BATT_TEMP_FAULT0x04 +#define BQ24261_TIMER_FAULT0x05 +#define BQ24261_BATT_OVP 0x06 +#define BQ24261_NO_BATTERY 0x07 +#define BQ24261_STAT_READY 0x00 + +#define BQ24261_STAT_CHRG_PRGRSS (0x01 << 4) +#define BQ24261_STAT_CHRG_DONE (0x02 << 4) +#define BQ24261_STAT_FAULT (0x03 << 4) + +#define BQ24261_CE_MASK(0x01 << 1) +#define BQ24261_CE_DISABLE (0x01 << 1) + +#define BQ24261_HZ_MASK(0x01) +#define BQ24261_HZ_ENABLE (0x01) + +#define BQ24261_ICHRG_MASK (0x1F << 3) +#define BQ24261_MIN_CC 500 /* 500mA */ +#define BQ24261_MAX_CC 3000 /* 3A */ + +#define BQ24261_ITERM_MASK (0x03) +#define BQ24261_MIN_ITERM 50 /* 50 mA */ +#define BQ24261_MAX_ITERM 300 /* 300
[PATCH v7 1/4] power_supply: Add inlmt,iterm, min/max temp props
Add new power supply properties for input current, charge termination current, min and max temperature POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates the input current for a charging source. POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect the end of charge condition Signed-off-by: Jenny TC --- Documentation/power/power_supply_class.txt |6 ++ drivers/power/power_supply_sysfs.c |4 include/linux/power_supply.h |4 3 files changed, 14 insertions(+) diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index 89a8816..48cff88 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt @@ -118,6 +118,10 @@ relative, time-based measurements. CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger. CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the power supply object. +INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates +the current drawn from a charging source. +CHARGE_TERM_CURRENT - Charge termination current used to detect the end of charge +condition. CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger. CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the @@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert. TEMP_AMBIENT - ambient temperature. TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert. TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert. +TEMP_MIN - minimum operatable temperature +TEMP_MAX - maximum operatable temperature TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load) diff --git a/drivers/power/power_supply_sysfs.c b/drivers/power/power_supply_sysfs.c index 44420d1..750a202 100644 --- a/drivers/power/power_supply_sysfs.c +++ b/drivers/power/power_supply_sysfs.c @@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = { POWER_SUPPLY_ATTR(constant_charge_voltage_max), POWER_SUPPLY_ATTR(charge_control_limit), POWER_SUPPLY_ATTR(charge_control_limit_max), + POWER_SUPPLY_ATTR(input_current_limit), POWER_SUPPLY_ATTR(energy_full_design), POWER_SUPPLY_ATTR(energy_empty_design), POWER_SUPPLY_ATTR(energy_full), @@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = { POWER_SUPPLY_ATTR(capacity_alert_max), POWER_SUPPLY_ATTR(capacity_level), POWER_SUPPLY_ATTR(temp), + POWER_SUPPLY_ATTR(temp_max), + POWER_SUPPLY_ATTR(temp_min), POWER_SUPPLY_ATTR(temp_alert_min), POWER_SUPPLY_ATTR(temp_alert_max), POWER_SUPPLY_ATTR(temp_ambient), @@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = { POWER_SUPPLY_ATTR(time_to_full_avg), POWER_SUPPLY_ATTR(type), POWER_SUPPLY_ATTR(scope), + POWER_SUPPLY_ATTR(charge_term_current), /* Properties of type `const char *' */ POWER_SUPPLY_ATTR(model_name), POWER_SUPPLY_ATTR(manufacturer), diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h index c9dc4e0..0278600 100644 --- a/include/linux/power_supply.h +++ b/include/linux/power_supply.h @@ -120,6 +120,7 @@ enum power_supply_property { POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX, POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT, POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX, + POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN, POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN, POWER_SUPPLY_PROP_ENERGY_FULL, @@ -131,6 +132,8 @@ enum power_supply_property { POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */ POWER_SUPPLY_PROP_CAPACITY_LEVEL, POWER_SUPPLY_PROP_TEMP, + POWER_SUPPLY_PROP_TEMP_MAX, + POWER_SUPPLY_PROP_TEMP_MIN, POWER_SUPPLY_PROP_TEMP_ALERT_MIN, POWER_SUPPLY_PROP_TEMP_ALERT_MAX, POWER_SUPPLY_PROP_TEMP_AMBIENT, @@ -142,6 +145,7 @@ enum power_supply_property { POWER_SUPPLY_PROP_TIME_TO_FULL_AVG, POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */ POWER_SUPPLY_PROP_SCOPE, + POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT, /* Properties of type `const char *' */ POWER_SUPPLY_PROP_MODEL_NAME, POWER_SUPPLY_PROP_MANUFACTURER, -- 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
[PATCHv7 3/4] power_supply: Introduce PSE compliant algorithm
As per Product Safety Engineering (PSE) specification for battery charging, the battery characteristics and thereby the charging rates can vary on different temperature zones. This patch introduces a PSE compliant charging algorithm with maintenance charging support. The algorithm can be selected by the power supply charging driver based on the type of the battery charging profile. Signed-off-by: Jenny TC --- drivers/power/Kconfig | 13 ++ drivers/power/Makefile |1 + drivers/power/charging_algo_pse.c | 204 include/linux/power/power_supply_charger.h | 63 + 4 files changed, 281 insertions(+) create mode 100644 drivers/power/charging_algo_pse.c diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index f679f82..913ec36 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER drivers to keep the charging logic outside and the charger driver just need to abstract the charger hardware. +config POWER_SUPPLY_CHARGING_ALGO_PSE + bool "PSE compliant charging algorithm" + help + Say Y here to select Product Safety Engineering (PSE) compliant + charging algorithm. As per PSE standard the battery characteristics + and thereby the charging rates can vary on different temperature + zones. This config will enable PSE compliant charging algorithm with + maintenance charging support. At runtime the algorithm will be + selected by the psy charger driver based on the type of the battery + charging profile. + + depends on POWER_SUPPLY_CHARGER + config PDA_POWER tristate "Generic PDA/phone power driver" depends on !S390 diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 405f0f4..77535fd 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY) += power_supply.o obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o +obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o obj-$(CONFIG_PDA_POWER)+= pda_power.o obj-$(CONFIG_APM_POWER)+= apm_power.o obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o diff --git a/drivers/power/charging_algo_pse.c b/drivers/power/charging_algo_pse.c new file mode 100644 index 000..ac95885 --- /dev/null +++ b/drivers/power/charging_algo_pse.c @@ -0,0 +1,204 @@ +/* + * Copyright (C) 2012 Intel Corporation + * + * ~~ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU + * General Public License for more details. + * + * ~~ + * Author: Jenny TC + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "power_supply.h" +#include "power_supply_charger.h" + +/* 98% of CV is considered as voltage to detect Full */ +#define FULL_CV_MIN 98 + +/* + * Offset to exit from maintenance charging. In maintenance charging + * if the volatge is less than the (maintenance_lower_threshold - + * MAINT_EXIT_OFFSET) then system can switch to normal charging + */ + +#define MAINT_EXIT_OFFSET 50 /* mV */ + +static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof, + int temp) +{ + int i = 0; + int temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges, + BATT_TEMP_NR_RNG); + + if ((temp < pse_mod_bprof->temp_low_lim) || + (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim)) + return -EINVAL; + + for (i = 0; i < temp_range_cnt; ++i) + if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim) + break; + return i-1; +} + +static inline bool is_charge_terminated(long volt, long cur, + long iterm, unsigned long cv) +{ + pr_devel("%s:current=%ld pse_mod_bprof->chrg_term_mA =%ld voltage_now=%ld full_cond=%ld", + __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv)); + + return (cur > 0) && (cur <= iterm) && + ((volt * 100) >= (FULL_CV_MIN * cv)); + +} + +static inline bool is_battery_full(struct psy_batt_props bat_prop, + struct psy_pse_chrg_prof *pse_mod_bprof, unsigned long cv) +{ + + int i; + + /* + * Software full detection. Check
Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver
Hi Hans, On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote: Hi Archit! On 03/03/2014 08:33 AM, Archit Taneja wrote: Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type. For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the whole image itself, hence making crop dimensions same as the pix dimensions. Setting the crop successfully should result in re-configuration of those registers which are affected when either source or destination dimensions change, set_srcdst_params() is called for this purpose. Some standard crop parameter checks are done in __vpe_try_crop(). Please use the selection ops instead: if you implement cropping with those then you'll support both the selection API and the old cropping API will be implemented by the v4l2 core using the selection ops. Two for the price of one... When using selection API, I was finding issues using the older cropping API. The v4l_s_crop() ioctl func assumes that "crop means compose for output devices". However, for a m2m device. It probably makes sense to provide the following configuration: for V4L2_BUF_TYPE_VIDEO_OUTPUT (input to the mem to mem HW), use CROP target(to crop the input buffer) and, for V4L2_BUF_TYPE_VIDEO_CAPTURE(output of the mem to mem HW), use COMPOSE target(to place the HW output into a larger region) Don't you think forcing OUTPUT devices to 'COMPOSE' for older cropping API is a bit limiting? Thanks, Archit -- 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 7/7] v4l: ti-vpe: Add crop support in VPE driver
On 03/04/2014 08:38 AM, Archit Taneja wrote: > Hi Hans, > > On Monday 03 March 2014 01:20 PM, Hans Verkuil wrote: >> Hi Archit! >> >> On 03/03/2014 08:33 AM, Archit Taneja wrote: >>> Add crop ioctl ops. For VPE, cropping only makes sense with the input to >>> VPE, or >>> the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type. >>> >>> For the CAPTURE type, a S_CROP ioctl results in setting the crop region as >>> the >>> whole image itself, hence making crop dimensions same as the pix dimensions. >>> >>> Setting the crop successfully should result in re-configuration of those >>> registers which are affected when either source or destination dimensions >>> change, set_srcdst_params() is called for this purpose. >>> >>> Some standard crop parameter checks are done in __vpe_try_crop(). >> >> Please use the selection ops instead: if you implement cropping with those >> then you'll >> support both the selection API and the old cropping API will be implemented >> by the v4l2 >> core using the selection ops. Two for the price of one... > > > When using selection API, I was finding issues using the older cropping > API. The v4l_s_crop() ioctl func assumes that "crop means compose for > output devices". However, for a m2m device. It probably makes sense to > provide the following configuration: > > for V4L2_BUF_TYPE_VIDEO_OUTPUT (input to the mem to mem HW), use CROP > target(to crop the input buffer) > > and, for V4L2_BUF_TYPE_VIDEO_CAPTURE(output of the mem to mem HW), use > COMPOSE target(to place the HW output into a larger region) > > Don't you think forcing OUTPUT devices to 'COMPOSE' for older cropping > API is a bit limiting? Yes, and that's why the selection API was created to work around that limitation :-) The old cropping API was insufficiently flexible for modern devices, so we came up with this replacement. Another reason why you have to implement the selection API: it's the only way to implement your functionality. Regards, Hans -- 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