Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names wkupclk and refclk
On 04/30/2014 06:20 PM, Nishanth Menon wrote: On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi ba...@ti.com wrote: On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: +Nishant Hi, On 04/28/2014 07:03 PM, Felipe Balbi wrote: Hi, On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: As clocks might be named differently on multiple platforms, use a generic name in the driver and allow device tree node to specify the platform specific clock name. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/phy/phy-omap-usb2.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index a2205a8..fb5e515 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) if (IS_ERR(phy_provider)) return PTR_ERR(phy_provider); -phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k); +phy-wkupclk = devm_clk_get(phy-dev, wkupclk); doesn't this patch cause a regression ? I mean, you're changing the clock name before fixing DTS. Also, that DTS has been in a major version of the kernel, so we need to maintain compatibility with it. How about: I'm changing the DTS in Patch 4, but I prefer to do it in this patch to prevent synchronization issues in -next. About backward compatibility, I agree with you but at the same time I don't think anyone using TI SoCs burns the DTB to ROM and needs backward compatibility. We supply our BSPs/SDKs with the updated DTBs. Do you feel strict backward compatibility is worth the effort for TI specific blocks? dunno, but it would, at least, avoid synchronization issues with linux-next :-) and the bisectability issue. I agree - we cannot drop backward compatibility for DTBs http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 That says backward compatibility for stable bindings. In this case, the binding that I changed doesn't even exist in Documentation/devicetree/bindings, so it never was a stable binding. + + 3) Bindings can be augmented, but the driver shouldn't break when given + the old binding. ie. add additional properties, but don't change the + meaning of an existing property. For drivers, default to the original + behaviour when a newly added property is missing. 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: [PATCHv3] arm: dts: am43x-clock: add tbclk data for ehrpwm.
On 05/01/2014 10:00 PM, Mike Turquette wrote:
Quoting Tero Kristo (2014-04-29 07:51:14)
On 04/29/2014 05:15 PM, Sourav Poddar wrote:
We need tbclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Looks good to me.
Tero, just to be clear, are you planning on batching up OMAPish clock
patches and sending a pull request (once they have been reviewed on the
list)?
No, I haven't been planning on sending a pull-req, as I believe you
still want to ack the TI related clock driver patches yourself also. If
you want to change the setup I am of course willing to negotiate the
terms. :)
-Tero
Thanks,
Mike
---
v2-v3
- correct bitshifting
arch/arm/boot/dts/am43xx-clocks.dtsi | 48
++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..42d7b1f 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 0;
+ reg = 0x0664;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 1;
+ reg = 0x0664;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 4;
+ reg = 0x0664;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 5;
+ reg = 0x0664;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 6;
+ reg = 0x0664;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm3_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm4_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm5_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe 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 3.14 012/158] ARM: dts: am33xx: correcting dt node unit address for usb
On Sun, May 04, 2014 at 11:38:41AM -0400, Greg Kroah-Hartman wrote:
3.14-stable review patch. If anyone has any objections, please let me know.
This one should not be backported without commit
a2f8d6b30321 (ARM: dts: am335x: update USB DT references)
which is in Linus' tree but is not marked for stable (or USB will be
disabled for the boards relying on the old node addresses).
Thanks,
Johan
--
From: Mugunthan V N mugunthan...@ti.com
commit 8abcdd680d543fb582371e146e62ba9f2af8a816 upstream.
DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.
Acked-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
arch/arm/boot/dts/am33xx.dtsi |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -448,7 +448,7 @@
ti,hwmods = usb_otg_hs;
status = disabled;
- usb_ctrl_mod: control@44e1 {
+ usb_ctrl_mod: control@44e10620 {
compatible = ti,am335x-usb-ctrl-module;
reg = 0x44e10620 0x10
0x44e10648 0x4;
@@ -551,7 +551,7 @@
tx14, tx15;
};
- cppi41dma: dma-controller@07402000 {
+ cppi41dma: dma-controller@47402000 {
compatible = ti,am3359-cppi41;
reg = 0x4740 0x1000
0x47402000 0x1000
--
To unsubscribe 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/7] phy: omap-usb2: Use generic clock names wkupclk and refclk
On 05/05/2014 10:23 AM, Roger Quadros wrote: On 04/30/2014 06:20 PM, Nishanth Menon wrote: On Tue, Apr 29, 2014 at 11:16 AM, Felipe Balbi ba...@ti.com wrote: On Tue, Apr 29, 2014 at 11:14:20AM -0500, Felipe Balbi wrote: On Tue, Apr 29, 2014 at 10:50:39AM +0300, Roger Quadros wrote: +Nishant Hi, On 04/28/2014 07:03 PM, Felipe Balbi wrote: Hi, On Mon, Apr 28, 2014 at 05:01:23PM +0300, Roger Quadros wrote: As clocks might be named differently on multiple platforms, use a generic name in the driver and allow device tree node to specify the platform specific clock name. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/phy/phy-omap-usb2.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index a2205a8..fb5e515 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -275,16 +275,16 @@ static int omap_usb2_probe(struct platform_device *pdev) if (IS_ERR(phy_provider)) return PTR_ERR(phy_provider); -phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k); +phy-wkupclk = devm_clk_get(phy-dev, wkupclk); doesn't this patch cause a regression ? I mean, you're changing the clock name before fixing DTS. Also, that DTS has been in a major version of the kernel, so we need to maintain compatibility with it. How about: I'm changing the DTS in Patch 4, but I prefer to do it in this patch to prevent synchronization issues in -next. About backward compatibility, I agree with you but at the same time I don't think anyone using TI SoCs burns the DTB to ROM and needs backward compatibility. We supply our BSPs/SDKs with the updated DTBs. Do you feel strict backward compatibility is worth the effort for TI specific blocks? dunno, but it would, at least, avoid synchronization issues with linux-next :-) and the bisectability issue. I agree - we cannot drop backward compatibility for DTBs http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 That says backward compatibility for stable bindings. In this case, the binding that I changed doesn't even exist in Documentation/devicetree/bindings, so it never was a stable binding. Forgot to mention, I'm sending a revised version based on your and Felipe's suggestion. 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
[PATCH v3 0/7] USB support for DRA7-evm
Hi, This series enables the 2 USB ports on the DRA7-evm. NOTE: USB1 port is hard coded to work in peripheral mode and USB2 port in host mode. This is due to missing ID pin interrupt in pre ver.E boards. USB1 port doesn't in peripheral mode out of the box due to missing VBUS detection and mailbox write. To test this I had to do a manual write to enable VBUSVALID in the USB_UTMI_OTG_STATUS register. omapconf set bit 0x48880084 1 USB2 port works well in host mode. Patches are based on 3.15-rc3. cheers, -roger Changelog: v3: -Rearraged patches. PHY related stuff first. -Addressed backward compatibility issue for phy-omap-usb2. v2: -Rebased on v3.15-rc3 --- Roger Quadros (7): phy: omap-usb2: Use generic clock names wkupclk and refclk phy: omap-usb2: Add clock names to Documentation binding ARM: dts: omap4+: Add clocks to USB2 PHY node ARM: dts: dra7-clock: Add l3init_960m_gfclk clock gate ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss ARM: dts: dra7: Add USB related nodes dts: dra7-evm: add USB support Documentation/devicetree/bindings/phy/ti-phy.txt | 7 ++ arch/arm/boot/dts/dra7-evm.dts | 24 arch/arm/boot/dts/dra7.dtsi | 149 +++ arch/arm/boot/dts/dra7xx-clocks.dtsi | 12 +- arch/arm/boot/dts/omap4.dtsi | 2 + arch/arm/boot/dts/omap5.dtsi | 2 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 22 ++-- drivers/phy/phy-omap-usb2.c | 30 +++-- 8 files changed, 229 insertions(+), 19 deletions(-) -- 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: dra7-clock: Add l3init_960m_gfclk clock gate
This clock gate description is missing in the older Reference manuals.
It is present on the SoC to provide 960MHz reference clock to the
internal USB PHYs.
Reference: DRA75x_DRA74x_ES1.1_NDA_TRM_vO.pdf, pg. 900,
Table 3-812. CM_COREAON_L3INIT_60M_GFCLK_CLKCTRL
Use l3init_960m_gfclk as parent of usb_otg_ss1_refclk960m and
usb_otg_ss2_refclk960m.
CC: Benoît Cousson bcous...@baylibre.com
CC: Tero Kristo t-kri...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..c767687 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1386,6 +1386,14 @@
ti,dividers = 1, 8;
};
+ l3init_960m_gfclk: l3init_960m_gfclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_usb_clkdcoldo;
+ ti,bit-shift = 8;
+ reg = 0x06c0;
+ };
+
dss_32khz_clk: dss_32khz_clk {
#clock-cells = 0;
compatible = ti,gate-clock;
@@ -1533,7 +1541,7 @@
usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
#clock-cells = 0;
compatible = ti,gate-clock;
- clocks = dpll_usb_clkdcoldo;
+ clocks = l3init_960m_gfclk;
ti,bit-shift = 8;
reg = 0x13f0;
};
@@ -1541,7 +1549,7 @@
usb_otg_ss2_refclk960m: usb_otg_ss2_refclk960m {
#clock-cells = 0;
compatible = ti,gate-clock;
- clocks = dpll_usb_clkdcoldo;
+ clocks = l3init_960m_gfclk;
ti,bit-shift = 8;
reg = 0x1340;
};
--
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] phy: omap-usb2: Add clock names to Documentation binding
Add wkupclk and refclk information to DT binding information.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 788fb0f..9ce458f 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -32,6 +32,11 @@ Required properties:
- reg : Address and length of the register set for the device.
- #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
+ - clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+ - clock-names: should include:
+ * wkupclk - wakeup clock.
+ * refclk - reference clock (optional).
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -44,6 +49,8 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
#phy-cells = 0;
+ clocks = usb_phy_cm_clk32k, usb_otg_ss_refclk960m;
+ clock-names = wkupclk, refclk;
};
TI PIPE3 PHY
--
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 1/7] phy: omap-usb2: Use generic clock names wkupclk and refclk
As clocks might be named differently on multiple platforms, use a generic
name in the driver and allow device tree node to specify the platform
specific clock name.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index a2205a8..7007c11 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -275,18 +275,34 @@ static int omap_usb2_probe(struct platform_device *pdev)
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
- phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
+ phy-wkupclk = devm_clk_get(phy-dev, wkupclk);
if (IS_ERR(phy-wkupclk)) {
- dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
- return PTR_ERR(phy-wkupclk);
+ dev_warn(pdev-dev, unable to get wkupclk, trying old
name\n);
+ 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);
+ } else {
+ dev_warn(pdev-dev,
+found usb_phy_cm_clk32k, please fix DTS\n);
+ }
}
clk_prepare(phy-wkupclk);
- phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
- if (IS_ERR(phy-optclk))
- dev_vdbg(pdev-dev, unable to get refclk960m\n);
- else
+ phy-optclk = devm_clk_get(phy-dev, refclk);
+ if (IS_ERR(phy-optclk)) {
+ dev_dbg(pdev-dev, unable to get refclk, trying old name\n);
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_dbg(pdev-dev,
+ unable to get usb_otg_ss_refclk960m\n);
+ } else {
+ dev_warn(pdev-dev,
+found usb_otg_ss_refclk960m, please fix
DTS\n);
+ }
+ } else {
clk_prepare(phy-optclk);
+ }
usb_add_phy_dev(phy-phy);
--
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 7/7] dts: dra7-evm: add USB support
Add USB pinmux information and USB modes
for the USB controllers.
CC: Benoît Cousson bcous...@baylibre.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..1d77815 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,18 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ usb1_pins: pinmux_usb1_pins {
+pinctrl-single,pins =
+ 0x280 0xc /* usb1_drvvbus, SLOW_SLEW | PULLUPEN |
MODE0 */
+;
+};
+
+ usb2_pins: pinmux_usb2_pins {
+pinctrl-single,pins =
+ 0x284 0xc /* usb2_drvvbus, SLOW_SLEW | PULLUPEN |
MODE0 */
+;
+};
};
i2c1 {
@@ -273,3 +285,15 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+usb1 {
+ dr_mode = peripheral;
+ pinctrl-names = default;
+ pinctrl-0 = usb1_pins;
+};
+
+usb2 {
+ dr_mode = host;
+ pinctrl-names = default;
+ pinctrl-0 = usb2_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 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
Add the sysconfig class bits for the Super Speed USB
controllers
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 810c205..067d322 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1731,8 +1731,20 @@ static struct omap_hwmod dra7xx_uart6_hwmod = {
*
*/
+static struct omap_hwmod_class_sysconfig dra7xx_usb_otg_ss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_DMADISABLE | 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 dra7xx_usb_otg_ss_hwmod_class = {
.name = usb_otg_ss,
+ .sysc = dra7xx_usb_otg_ss_sysc,
};
/* usb_otg_ss1 */
--
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: dra7: Add USB related nodes
Add nodes for the Super Speed USB controllers, omap-control-usb,
USB2 PHY and USB3 PHY devices.
Remove ocp2scp1 address space from hwmod data as it is
now provided via device tree.
CC: Benoît Cousson bcous...@baylibre.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 149 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 --
2 files changed, 149 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..4535e54 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,155 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ omap_control_usb2phy1: control-phy@4a002300 {
+ compatible = ti,control-phy-usb2;
+ reg = 0x4a002300 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usb3phy1: control-phy@4a002370 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002370 0x4;
+ reg-names = power;
+ };
+
+ omap_control_usb2phy2: control-phy@0x4a002e74 {
+ compatible = ti,control-phy-usb2-dra7;
+ reg = 0x4a002e74 0x4;
+ reg-names = power;
+ };
+
+ /* OCP2SCP1 */
+ ocp2scp@4a08 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ reg = 0x4a08 0x20;
+ ti,hwmods = ocp2scp1;
+
+ usb2_phy1: phy@4a084000 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a084000 0x400;
+ ctrl-module = omap_control_usb2phy1;
+ clocks = usb_phy1_always_on_clk32k,
+usb_otg_ss1_refclk960m;
+ clock-names = wkupclk,
+ refclk;
+ #phy-cells = 0;
+ };
+
+ usb2_phy2: phy@4a085000 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a085000 0x400;
+ ctrl-module = omap_control_usb2phy2;
+ clocks = usb_phy2_always_on_clk32k,
+usb_otg_ss2_refclk960m;
+ clock-names = wkupclk,
+ refclk;
+ #phy-cells = 0;
+ };
+
+ usb3_phy1: phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40;
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_usb3phy1;
+ clocks = usb_phy3_always_on_clk32k,
+sys_clkin1,
+usb_otg_ss1_refclk960m;
+ clock-names = wkupclk,
+ sysclk,
+ refclk;
+ #phy-cells = 0;
+ };
+ };
+
+ omap_dwc3_1@4888 {
+ compatible = ti,dwc3;
+ ti,hwmods = usb_otg_ss1;
+ reg = 0x4888 0x1;
+ interrupts = 0 77 4;
+ #address-cells = 1;
+ #size-cells = 1;
+ utmi-mode = 2;
+ ranges;
+ usb1: usb@4889 {
+ compatible = snps,dwc3;
+ reg = 0x4889 0x17000;
+ interrupts = 0 76 4;
+ phys = usb2_phy1, usb3_phy1;
+ phy-names = usb2-phy, usb3-phy;
+ tx-fifo-resize;
+ maximum-speed = super-speed;
+ dr_mode = otg;
+ };
+ };
+
+ omap_dwc3_2@488c {
+ compatible = ti,dwc3;
+ ti,hwmods = usb_otg_ss2;
+ reg = 0x488c 0x1;
+ interrupts = 0 92 4;
+ #address-cells
[PATCH v3 3/7] ARM: dts: omap4+: Add clocks to USB2 PHY node
The USB2 PHY driver expects named clocks for wakeup clock and reference clock. Provide this information for USB2 PHY nodes in OMAP4 and OMAP5 SoC DTS. CC: Benoît Cousson bcous...@baylibre.com Reviewed-by: Felipe Balbi ba...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4.dtsi | 2 ++ arch/arm/boot/dts/omap5.dtsi | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 649b5cd..f866de9 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -642,6 +642,8 @@ compatible = ti,omap-usb2; reg = 0x4a0ad080 0x58; ctrl-module = omap_control_usb2phy; + clocks = usb_phy_cm_clk32k; + clock-names = wkupclk; #phy-cells = 0; }; }; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index f8c9855..47b714c 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -803,6 +803,8 @@ compatible = ti,omap-usb2; reg = 0x4a084000 0x7c; ctrl-module = omap_control_usb2phy; + clocks = usb_phy_cm_clk32k, usb_otg_ss_refclk960m; + clock-names = wkupclk, refclk; #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
Re: [PATCH v2 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk
On 05/02/2014 09:32 AM, George Cherian wrote:
cpsw_cpts_rft_clk has got the choice of 3 clocksources
-dpll_core_m4_ck
-dpll_core_m5_ck
-dpll_disp_m2_ck
By default dpll_core_m4_ck is selected, witn this as clock
source the CPTS doesnot work properly. It gives clockcheck errors
while running PTP.
clockcheck: clock jumped backward or running slower than expected!
By selecting dpll_core_m5_ck as the clocksource fixes this issue.
In AM335x dpll_core_m5_ck is the default clocksource.
Signed-off-by: George Cherian george.cher...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/ti/clk-43xx.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..b4877e0 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -110,9 +110,25 @@ static struct ti_dt_clk am43xx_clks[] = {
int __init am43xx_dt_clk_init(void)
{
+ struct clk *clk1, *clk2;
+
ti_dt_clocks_register(am43xx_clks);
omap2_clk_disable_autoidle_all();
+ /*
+* cpsw_cpts_rft_clk has got the choice of 3 clocksources
+* dpll_core_m4_ck, dpll_core_m5_ck and dpll_disp_m2_ck.
+* By default dpll_core_m4_ck is selected, witn this as clock
+* source the CPTS doesnot work properly. It gives clockcheck errors
+* while running PTP.
+* clockcheck: clock jumped backward or running slower than expected!
+* By selecting dpll_core_m5_ck as the clocksource fixes this issue.
+* In AM335x dpll_core_m5_ck is the default clocksource.
+*/
+ clk1 = clk_get_sys(NULL, cpsw_cpts_rft_clk);
+ clk2 = clk_get_sys(NULL, dpll_core_m5_ck);
+ clk_set_parent(clk1, clk2);
+
return 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: [jenny...@intel.com: [RFC] power_supply: Introduce generic psy charging driver]
Hi!
(Only part of original cc-list preserved.)
RFC: Fixed comments for patch v8, removed sorting and string comparisons
Ok, its better now.
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.
Signed-off-by: Jenny TC jenny...@intel.com
---
Documentation/power/power_supply_charger.txt | 350 +
drivers/power/Kconfig|8 +
drivers/power/Makefile |1 +
drivers/power/power_supply_charger.c | 1066
++
drivers/power/power_supply_charger.h | 226 ++
drivers/power/power_supply_core.c|3 +
include/linux/power/power_supply_charger.h | 304
include/linux/power_supply.h | 161
8 files changed, 2119 insertions(+)
create mode 100644 Documentation/power/power_supply_charger.txt
create mode 100644 drivers/power/power_supply_charger.c
create mode 100644 drivers/power/power_supply_charger.h
create mode 100644 include/linux/power/power_supply_charger.h
diff --git a/Documentation/power/power_supply_charger.txt
b/Documentation/power/power_supply_charger.txt
new file mode 100644
index 000..1bb8cb4
--- /dev/null
+++ b/Documentation/power/power_supply_charger.txt
@@ -0,0 +1,350 @@
+1. Introduction
+===
+
+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
Space after '.'.
+static struct charger_cable cable_list[] = {
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_USB_SDP,
+ },
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_USB_CDP,
+ },
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_USB_DCP,
+ },
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_USB_ACA,
+ },
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_ACA_DOCK,
+ },
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_SE1,
+ },
+ {
+ .psy_cable_type = PSY_CHARGER_CABLE_TYPE_AC,
+ },
+};
Can we get rid of this?
+struct usb_phy *otg_xceiver;
+static int handle_event_notification(struct notifier_block *nb,
+unsigned long event, void *data);
+struct notifier_block nb = {
+.notifier_call = handle_event_notification,
+ };
You need to add way more statics.
+static void update_supplied_to_psy(struct power_supply *psy)
+{
+ WARN_ON(charger_context == NULL);
Useless.
+ for (i = 0; i psy-num_supplicants; i++) {
+ charger_context-supplied_to_psy[cnt++] =
+ power_supply_get_by_name(psy-supplied_to[i]);
+ charger_context-supplied_to_psy[cnt] = NULL;
+ }
+}
Still some name lookups to be killed.
+ for (i = 0; i pst-num_supplicants; i++) {
+ psb = power_supply_get_by_name(pst-supplied_to[i]);
+ if (psb == psy) {
+ batt_context-supplied_by_psy[cnt++] = pst;
+ batt_context-supplied_by_psy[cnt] = NULL;
+ break;
+ }
+ }
+ }
And here.
+ WARN_ON(psy-data == NULL);
Useless.
+ charger_context = (struct psy_charger_context *)psy-data;
+static inline bool is_supplied_to_has_ext_pwr_changed(struct power_supply
*psy)
+{
+ int i;
+ struct power_supply *psb;
+ bool is_pwr_changed_defined = true;
+
+ for (i = 0; i psy-num_supplicants; i++) {
+ psb =
+ power_supply_get_by_name(psy-
+ supplied_to[i]);
+ if (psb !psb-external_power_changed)
+ is_pwr_changed_defined = false;
+ }
You did not really get rid of the name lookups..
= false. Bad idea.
+static int trigger_algo(struct power_supply *psy)
+{
+ unsigned long cc = 0, cv = 0, cc_min;
+ struct psy_batt_context *batt_context;
+ struct psy_charging_algo *algo;
+ struct
[PATCH 0/2] PM / OPP: move cpufreq specific helpers out of OPP layer
CPUFreq usage of OPP should be independent of the ordering of type of data storage inside OPP layer. The current operations can equally be performed by generic operations. [RFC]: https://patchwork.kernel.org/patch/4100811/ Series based on: v3.15-rc1 Nishanth Menon (2): PM / OPP: Remove cpufreq wrapper dependency on internal data organization PM / OPP: Move cpufreq specific OPP functions out of generic OPP library Documentation/cpu-freq/core.txt | 29 +++ Documentation/power/opp.txt | 40 ++ drivers/base/power/opp.c| 91 drivers/cpufreq/Makefile|2 + drivers/cpufreq/cpufreq_opp.c | 110 +++ include/linux/cpufreq.h | 21 include/linux/pm_opp.h | 20 --- 7 files changed, 167 insertions(+), 146 deletions(-) create mode 100644 drivers/cpufreq/cpufreq_opp.c -- 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 1/2] PM / OPP: Remove cpufreq wrapper dependency on internal data organization
CPUFREQ custom functions for OPP (Operating Performance Points)
currently exist inside the OPP library. These custom functions currently
depend on internal data structures to pick up OPP information to create
the cpufreq table. For example, the cpufreq table is created precisely
in the same order of how OPP entries are stored inside the list implementation.
This kind of tight interdependency is purely artificial since the same
functionality can be achieved using the generic OPP functions
meant to do the same. This interdependency also limits the independent
modification of cpufreq and OPP library.
So use the generic dev_pm_opp_find_freq_ceil function that achieves the
table organization as we currently use.
As a result of this, we dont need to use the internal device_opp
structure anymore, and we hence we can switch over to rcu lock instead
of the mutex holding the internal list lock.
This breaking of dependency on internal data structure imposes no change
to usage of these.
NOTE: This change is a precursor to moving this cpufreq specific logic
out of the generic library into cpufreq.
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: cpuf...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/base/power/opp.c | 55 +++---
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 2553867..38b43bb 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -617,53 +617,54 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
* the table if any of the mentioned functions have been invoked in the
interim.
*
* Locking: The internal device_opp and opp structures are RCU protected.
- * To simplify the logic, we pretend we are updater and hold relevant mutex
here
- * Callers should ensure that this function is *NOT* called under RCU
protection
- * or in contexts where mutex locking cannot be used.
+ * Since we just use the regular accessor functions to access the internal data
+ * structures, we use RCU read lock inside this function. As a result, users of
+ * this function DONOT need to use explicit locks for invoking.
*/
int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table)
{
- struct device_opp *dev_opp;
struct dev_pm_opp *opp;
- struct cpufreq_frequency_table *freq_table;
- int i = 0;
+ struct cpufreq_frequency_table *freq_table = NULL;
+ int i, max_opps, ret = 0;
+ unsigned long rate;
- /* Pretend as if I am an updater */
- mutex_lock(dev_opp_list_lock);
+ rcu_read_lock();
- dev_opp = find_device_opp(dev);
- if (IS_ERR(dev_opp)) {
- int r = PTR_ERR(dev_opp);
- mutex_unlock(dev_opp_list_lock);
- dev_err(dev, %s: Device OPP not found (%d)\n, __func__, r);
- return r;
+ max_opps = dev_pm_opp_get_opp_count(dev);
+ if (max_opps = 0) {
+ ret = max_opps ? max_opps : -ENODATA;
+ goto out;
}
- freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) *
-(dev_pm_opp_get_opp_count(dev) + 1), GFP_KERNEL);
+ freq_table = kzalloc(sizeof(*freq_table) * (max_opps + 1), GFP_KERNEL);
if (!freq_table) {
- mutex_unlock(dev_opp_list_lock);
- dev_warn(dev, %s: Unable to allocate frequency table\n,
- __func__);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
- list_for_each_entry(opp, dev_opp-opp_list, node) {
- if (opp-available) {
- freq_table[i].driver_data = i;
- freq_table[i].frequency = opp-rate / 1000;
- i++;
+ for (i = 0, rate = 0; i max_opps; i++, rate++) {
+ /* find next rate */
+ opp = dev_pm_opp_find_freq_ceil(dev, rate);
+ if (IS_ERR(opp)) {
+ ret = PTR_ERR(opp);
+ goto out;
}
+ freq_table[i].driver_data = i;
+ freq_table[i].frequency = rate / 1000;
}
- mutex_unlock(dev_opp_list_lock);
freq_table[i].driver_data = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
*table = freq_table[0];
- return 0;
+out:
+ rcu_read_unlock();
+ if (ret)
+ kfree(freq_table);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_opp_init_cpufreq_table);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
[PATCH 2/2] PM / OPP: Move cpufreq specific OPP functions out of generic OPP library
CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.
Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: cpuf...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
List of files impacted by this change detected by:
# check if pm_opp.h header is needed anymore:
git grep dev_pm_opp_init_cpufreq_table .|cut -d ':' -f1|sort|uniq|xargs
grep dev_pm_opp |grep -v cpufreq
# check if any file is missing cpufreq.h header is needed anymore:
git grep dev_pm_opp_init_cpufreq_table .|cut -d ':' -f1|sort|uniq|xargs
grep cpufreq.h
Documentation/cpu-freq/core.txt | 29 +++
Documentation/power/opp.txt | 40 ++
drivers/base/power/opp.c| 92
drivers/cpufreq/Makefile|2 +
drivers/cpufreq/cpufreq_opp.c | 110 +++
include/linux/cpufreq.h | 21
include/linux/pm_opp.h | 20 ---
7 files changed, 167 insertions(+), 147 deletions(-)
create mode 100644 drivers/cpufreq/cpufreq_opp.c
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index 0060d76..70933ea 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -20,6 +20,7 @@ Contents:
-
1. CPUFreq core and interfaces
2. CPUFreq notifiers
+3. CPUFreq Table Generation with Operating Performance Point (OPP)
1. General Information
===
@@ -92,3 +93,31 @@ values:
cpu- number of the affected CPU
old- old frequency
new- new frequency
+
+3. CPUFreq Table Generation with Operating Performance Point (OPP)
+==
+For details about OPP, see Documentation/power/opp.txt
+
+dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
+ cpufreq_frequency_table_cpuinfo which is provided with the list of
+ frequencies that are available for operation. This function provides
+ a ready to use conversion routine to translate the OPP layer's internal
+ information about the available frequencies into a format readily
+ providable to cpufreq.
+
+ WARNING: Do not use this function in interrupt context.
+
+ Example:
+soc_pm_init()
+{
+ /* Do things */
+ r = dev_pm_opp_init_cpufreq_table(dev, freq_table);
+ if (!r)
+ cpufreq_frequency_table_cpuinfo(policy, freq_table);
+ /* Do other things */
+}
+
+ NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
+ addition to CONFIG_PM_OPP.
+
+dev_pm_opp_free_cpufreq_table - Free up the table allocated by
dev_pm_opp_init_cpufreq_table
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index b8a907d..a9adad8 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -10,8 +10,7 @@ Contents
3. OPP Search Functions
4. OPP Availability Control Functions
5. OPP Data Retrieval Functions
-6. Cpufreq Table Generation
-7. Data Structures
+6. Data Structures
1. Introduction
===
@@ -72,7 +71,6 @@ operations until that OPP could be re-enabled if possible.
OPP library facilitates this concept in it's implementation. The following
operational functions operate only on available opps:
opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq,
dev_pm_opp_get_opp_count
-and dev_pm_opp_init_cpufreq_table
dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which
can then
be used for dev_pm_opp_enable/disable functions to make an opp available as
required.
@@ -96,10 +94,9 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
opp_get_{voltage, freq, opp_count} fall into this category.
opp_{add,enable,disable} are updaters which use mutex and implement it's own
-RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and
uses
-mutex to implment RCU updater strategy. These functions should *NOT* be called
-under RCU locks and other contexts that prevent blocking functions in RCU or
-mutex operations from working.
+RCU locking mechanisms. These functions should *NOT* be called under RCU locks
+and other contexts that prevent blocking functions in RCU or mutex operations
+from working.
2. Initial OPP List Registration
@@
Re: [PATCH] ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
Hi Illia, On 02/19/2014 07:53 PM, Paul Walmsley wrote: On Wed, 5 Feb 2014, Illia Smyrnov wrote: Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced softreset bit cleaning right after set one. It is caused L3 error for OMAP4 ISS because ISS register write occurs when ISS reset process is in progress. Avoid this situation by cleaning softreset bit later, when reset process is successfully finished. Signed-off-by: Illia Smyrnov illia.smyr...@globallogic.com Thanks, queued for v3.14-rc with notations from Grygorii and Roger. This hasn't made it to the stable kernels yet. Could you please send commit 01142519ffc0 to sta...@vger.kernel.org for v3.4+ kernels? 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
[PATCH 2/5] irqchip: crossbar: check for premapped crossbar before allocating
From: Nishanth Menon n...@ti.com
If irq_of_parse_and_map is executed twice, the same crossbar is mapped to two
different GIC interrupts. This is completely undesirable. Instead, check
if the requested crossbar event is pre-allocated and provide that GIC
mapping back to caller if already allocated.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 20105bc..51d4b87 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -51,6 +51,17 @@ static inline void crossbar_writeb(int irq_no, int cb_no)
writeb(cb_no, cb-crossbar_base + cb-register_offsets[irq_no]);
}
+static inline int get_prev_map_irq(int cb_no)
+{
+ int i;
+
+ for (i = 0; i cb-int_max; i++)
+ if (cb-irq_map[i] == cb_no)
+ return i;
+
+ return -ENODEV;
+}
+
static inline int allocate_free_irq(int cb_no)
{
int i;
@@ -88,11 +99,16 @@ static int crossbar_domain_xlate(struct irq_domain *d,
{
unsigned long ret;
+ ret = get_prev_map_irq(intspec[1]);
+ if (!IS_ERR_VALUE(ret))
+ goto found;
+
ret = allocate_free_irq(intspec[1]);
if (IS_ERR_VALUE(ret))
return ret;
+found:
*out_hwirq = ret + GIC_IRQ_START;
return 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 0/5] irqchip/dra7: crossbar bug fixes
These are fixes for the crossbar to handle two interrupts getting mapped twice to same crossbar and to skip some interrupts being used due to hardware bugs. Nishanth Menon (5): irqchip: crossbar: dont use '0' to mark reserved interrupts irqchip: crossbar: check for premapped crossbar before allocating irqchip: crossbar: Skip some irqs from getting mapped to crossbar irqchip: crossbar: Initialise the crossbar with a safe value irqchip: crossbar: Change allocation logic by reversing search for free irqs drivers/irqchip/irq-crossbar.c | 82 1 file changed, 74 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] irqchip: crossbar: dont use '0' to mark reserved interrupts
From: Nishanth Menon n...@ti.com
Today '0' is actually reserved, but may not be the same in the future.
So, use a flag to mark the GIC interrupts that are reserved.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 3d15d16..20105bc 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -17,6 +17,7 @@
#include linux/irqchip/arm-gic.h
#define IRQ_FREE -1
+#define IRQ_RESERVED -2
#define GIC_IRQ_START 32
/*
@@ -139,7 +140,7 @@ static int __init crossbar_of_init(struct device_node *node)
pr_err(Invalid reserved entry\n);
goto err3;
}
- cb-irq_map[entry] = 0;
+ cb-irq_map[entry] = IRQ_RESERVED;
}
}
@@ -170,7 +171,7 @@ static int __init crossbar_of_init(struct device_node *node)
* reserved irqs. so find and store the offsets once.
*/
for (i = 0; i max; i++) {
- if (!cb-irq_map[i])
+ if (cb-irq_map[i] == IRQ_RESERVED)
continue;
cb-register_offsets[i] = reserved;
--
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 5/5] irqchip: crossbar: Change allocation logic by reversing search for free irqs
From: Nishanth Menon n...@ti.com
Reverse the search algorithm to ensure that address mapping and IRQ
allocation logics are proper. This can open up new bugs which are
easily fixable rather than wait till allocation logic approaches
the limit to find new bugs.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 287d3ce..de021638 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -68,7 +68,7 @@ static inline int get_prev_map_irq(int cb_no)
{
int i;
- for (i = 0; i cb-int_max; i++)
+ for (i = cb-int_max - 1; i = 0; i--)
if (cb-irq_map[i] == cb_no)
return i;
@@ -79,7 +79,7 @@ static inline int allocate_free_irq(int cb_no)
{
int i;
- for (i = 0; i cb-int_max; i++) {
+ for (i = cb-int_max - 1; i = 0; i--) {
if (cb-irq_map[i] == IRQ_FREE) {
cb-irq_map[i] = cb_no;
return i;
--
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 4/5] irqchip: crossbar: Initialise the crossbar with a safe value
From: Nishanth Menon n...@ti.com
Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
a known 'safe' value.
b) When unmapping the interrupt, the safe value must be written to
ensure that the crossbar mapping matches with interrupt controller
usage.
So provide a safe value in the compatible data to map if
'0' is not safe for the platform and use it during init and unmap
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 847f6e3..287d3ce 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -44,6 +44,7 @@ struct crossbar_device {
struct crossbar_data {
const uint *irqs_unused;
const uint size;
+ const uint safe_map;
};
static struct crossbar_device *cb;
@@ -134,7 +135,7 @@ const struct irq_domain_ops routable_irq_domain_ops = {
static int __init crossbar_of_init(struct device_node *node,
const struct crossbar_data *data)
{
- int i, size, max, reserved = 0, entry;
+ int i, size, max, reserved = 0, entry, safe_map;
const __be32 *irqsr;
const int *irqsk = NULL;
@@ -212,6 +213,7 @@ static int __init crossbar_of_init(struct device_node *node,
if (data) {
irqsk = data-irqs_unused;
size = data-size;
+ safe_map = data-safe_map;
for (i = 0; i size; i++) {
entry = irqsk[i];
@@ -222,6 +224,14 @@ static int __init crossbar_of_init(struct device_node
*node,
}
cb-irq_map[entry] = IRQ_SKIP;
}
+
+ for (i = 0; i max; i++) {
+ if (cb-irq_map[i] == IRQ_RESERVED ||
+ cb-irq_map[i] == IRQ_SKIP)
+ continue;
+
+ cb-write(i, safe_map);
+ }
}
register_routable_domain_ops(routable_irq_domain_ops);
@@ -241,7 +251,7 @@ err1:
/* irq number 10 cannot be used because of hw bug */
int dra_irqs_unused[] = { 10 };
struct crossbar_data cb_dra_data = { dra_irqs_unused,
-ARRAY_SIZE(dra_irqs_unused) };
+ARRAY_SIZE(dra_irqs_unused), 0 };
static const struct of_device_id crossbar_match[] __initconst = {
{ .compatible = ti,irq-crossbar, .data = cb_dra_data },
--
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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
From: Nishanth Menon n...@ti.com
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 47
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 51d4b87..847f6e3 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -13,11 +13,13 @@
#include linux/io.h
#include linux/of_address.h
#include linux/of_irq.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/irqchip/arm-gic.h
#define IRQ_FREE -1
#define IRQ_RESERVED -2
+#define IRQ_SKIP -3
#define GIC_IRQ_START 32
/*
@@ -34,6 +36,16 @@ struct crossbar_device {
void (*write) (int, int);
};
+/**
+ * struct crossbar_data: Platform specific data
+ * @irqs_unused: array of irqs that cannot be used because of hw erratas
+ * @size: size of the irqs_unused array
+ */
+struct crossbar_data {
+ const uint *irqs_unused;
+ const uint size;
+};
+
static struct crossbar_device *cb;
static inline void crossbar_writel(int irq_no, int cb_no)
@@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops = {
.xlate = crossbar_domain_xlate
};
-static int __init crossbar_of_init(struct device_node *node)
+static int __init crossbar_of_init(struct device_node *node,
+ const struct crossbar_data *data)
{
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
+ const int *irqsk = NULL;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
@@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
*node)
reserved += size;
}
+ /* Skip the ones marked as unused */
+ if (data) {
+ irqsk = data-irqs_unused;
+ size = data-size;
+
+ for (i = 0; i size; i++) {
+ entry = irqsk[i];
+
+ if (entry max) {
+ pr_err(Invalid skip entry\n);
+ goto err3;
+ }
+ cb-irq_map[entry] = IRQ_SKIP;
+ }
+ }
+
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
@@ -208,18 +238,27 @@ err1:
return -ENOMEM;
}
+/* irq number 10 cannot be used because of hw bug */
+int dra_irqs_unused[] = { 10 };
+struct crossbar_data cb_dra_data = { dra_irqs_unused,
+ARRAY_SIZE(dra_irqs_unused) };
+
static const struct of_device_id crossbar_match[] __initconst = {
- { .compatible = ti,irq-crossbar },
+ { .compatible = ti,irq-crossbar, .data = cb_dra_data },
{}
};
int __init irqcrossbar_init(void)
{
struct device_node *np;
- np = of_find_matching_node(NULL, crossbar_match);
+ const struct of_device_id *of_id;
+ const struct crossbar_data *cdata;
+
+ np = of_find_matching_node_and_match(NULL, crossbar_match, of_id);
if (!np)
return -ENODEV;
- crossbar_of_init(np);
+ cdata = of_id-data;
+ crossbar_of_init(np, cdata);
return 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
Re: [PATCH 1/2] PM / OPP: Remove cpufreq wrapper dependency on internal data organization
On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote:
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table)
{
- struct device_opp *dev_opp;
struct dev_pm_opp *opp;
- struct cpufreq_frequency_table *freq_table;
- int i = 0;
+ struct cpufreq_frequency_table *freq_table = NULL;
+ int i, max_opps, ret = 0;
+ unsigned long rate;
- /* Pretend as if I am an updater */
- mutex_lock(dev_opp_list_lock);
What if opp is being added for some reason at the same time?
I hope we can surely see some awkward results, maybe some
NULL pointers invocations as well..
--
To unsubscribe 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 0/6] Add CPTS support for AM437x
On Friday 02 May 2014 12:01 PM, George Cherian wrote: The series adds CPTS support for AM4372. Patch 1 - DT changes w.r.t clock changes for AM33xx. Patch 2 - CPTS clock name harcoding in the driver is removed. Easier to pass the clock name from dt rather than hardcoding in driver. Also in prepration for DRA7x CPTS support. Patch 3 - Enable the CPTS support for both DRA7x and AM4372 in the driver. Patch 4 - Enable the Annexe F for L2 PTP for AM437x and DRA7x. Patch 5 - Change the default clocksource to dpll_core_m5 Patch 6 - DT changes for AM4372. v1 - v2 Patch 1 and 2 Re-ordering. Seperate TS_BITS define for Hw version V2 and V3 George Cherian (6): ARM: dts: am33xx: Add clock names for cpsw and cpts drivers: net: cpts: Remove hardcoded clock name for CPTS drivers: net: cpsw: Enable CPTS for DRA7xx and AM4372 drivers: net: cpsw: Enable Annexe F Time sync ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk ARM: dts: am4372: Add clock names for cpsw and cpts arch/arm/boot/dts/am33xx.dtsi | 2 ++ arch/arm/boot/dts/am4372.dtsi | 2 ++ drivers/clk/ti/clk-43xx.c | 16 drivers/net/ethernet/ti/cpsw.c | 56 +++--- drivers/net/ethernet/ti/cpts.c | 11 +++-- 5 files changed, 66 insertions(+), 21 deletions(-) Acked-by: Mugunthan V N mugunthan...@ti.com Regards Mugunthan V N -- To unsubscribe 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] PM / OPP: Remove cpufreq wrapper dependency on internal data organization
On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote: What if opp is being added for some reason at the same time? I hope we can surely see some awkward results, maybe some NULL pointers invocations as well.. we wont - rcu operations ensure that. -- To unsubscribe 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 4/4] omap crossbar support for v3.15
Hi Tony, On Tuesday 11 March 2014 06:11 PM, Sricharan R wrote: Tony, On Monday 10 March 2014 10:06 PM, Tony Lindgren wrote: * Olof Johansson o...@lixom.net [140308 23:36]: On Sun, Mar 02, 2014 at 03:14:49PM -0800, Tony Lindgren wrote: The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.15/crossbar-signed for you to fetch changes up to 9594274201ac3c67d5c569aae63792e58bcd33e6: Merge branch 'crossbar_3.14_rc1' of git://github.com/Sricharanti/sricharan into omap-for-v3.15/crossbar (2014-02-28 13:35:02 -0800) Add support for GIC crossbar that routes interrupts on newer omaps. Looks like people wanted these merged via the omap tree as it's the only user for the GIC crossbar. Sricharan R (4): DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number ARM: DRA: Enable Crossbar IP support for DRA7XX Whoa, lots of caps on those driver subjects. I don't think we need those in the future, lower case is just fine (and DRIVERS: usually isn't used). Oops yeah I had them as irqchip: crossbar and irqchip: irq-gic in my earlier branch for v3.14 that did not get merged, but this time I pulled from Sricharan. Scricharan, maybe use less yelling naming for any follow-up patches? Will make sure that there are no caps in the follow up patches. Regards, Sricharan I have pushed the below branch for the crossbar-dts data rebased on 3.15-rc4 g...@github.com:Sricharanti/sricharan.git branch: crossbar_dts_3.15_rc4 These patches are dependent on the crossbar driver fixes sent below. http://marc.info/?l=linux-omapm=139929963420299w=2 Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 4/4] omap crossbar support for v3.15
Hi, On Monday 05 May 2014 07:58 PM, Sricharan R wrote: Hi Tony, On Tuesday 11 March 2014 06:11 PM, Sricharan R wrote: Tony, On Monday 10 March 2014 10:06 PM, Tony Lindgren wrote: * Olof Johansson o...@lixom.net [140308 23:36]: On Sun, Mar 02, 2014 at 03:14:49PM -0800, Tony Lindgren wrote: The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.15/crossbar-signed for you to fetch changes up to 9594274201ac3c67d5c569aae63792e58bcd33e6: Merge branch 'crossbar_3.14_rc1' of git://github.com/Sricharanti/sricharan into omap-for-v3.15/crossbar (2014-02-28 13:35:02 -0800) Add support for GIC crossbar that routes interrupts on newer omaps. Looks like people wanted these merged via the omap tree as it's the only user for the GIC crossbar. Sricharan R (4): DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number ARM: DRA: Enable Crossbar IP support for DRA7XX Whoa, lots of caps on those driver subjects. I don't think we need those in the future, lower case is just fine (and DRIVERS: usually isn't used). Oops yeah I had them as irqchip: crossbar and irqchip: irq-gic in my earlier branch for v3.14 that did not get merged, but this time I pulled from Sricharan. Scricharan, maybe use less yelling naming for any follow-up patches? Will make sure that there are no caps in the follow up patches. Regards, Sricharan I have pushed the below branch for the crossbar-dts data rebased on 3.15-rc4 g...@github.com:Sricharanti/sricharan.git branch: crossbar_dts_3.15_rc4 These patches are dependent on the crossbar driver fixes sent below. http://marc.info/?l=linux-omapm=139929963420299w=2 Regards, Sricharan Sorry, please ignore this. Used a wrong thread. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] PM / OPP: Move cpufreq specific OPP functions out of generic OPP library
On 5 May 2014 19:03, Nishanth Menon n...@ti.com wrote: CPUFreq specific helper functions for OPP (Operating Performance Points) now use generic OPP functions that allow CPUFreq to be be moved back into CPUFreq framework. This allows for independent modifications or future enhancements as needed isolated to just CPUFreq framework alone. Here, we just move relevant code and documentation to make this part of CPUFreq infrastructure. Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Kevin Hilman khil...@deeprootsystems.com Cc: cpuf...@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe 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 V4 0/3] ARM: DTS: DRA7: Updates for adding crossbar device
Hi Tony, On Monday 30 December 2013 12:28 PM, Sricharan R wrote: Hi Benoit, On Thursday 14 November 2013 05:55 PM, Sricharan R wrote: Some socs have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt requests lines from the subsystems are not needed at the same time, so they have to be muxed to the controllers appropriately. In such places a interrupt controllers are preceded by an IRQ CROSSBAR that provides flexibility in muxing the device interrupt requests to the controller inputs. The driver support for the same was added here. http://marc.info/?l=linux-omapm=138443167321614w=2 The dts file update to support the crossbar device and convert peripheral irq numbers to crossbar number are added here. This series was originally a part of the series [1] and now split to keep the DTS updates separately as per comments from Santosh Shilimkar santosh.shilim...@ti.com Applied this series on top of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.13/dts [1] http://www.kernelhub.org/?msg=356470p=2 Sricharan R (3): ARM: DTS: DRA: Add crossbar device binding ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs ARM: DTS: DRA7: Add routable-irqs property for gic node arch/arm/boot/dts/dra7.dtsi | 95 +++ 1 file changed, 52 insertions(+), 43 deletions(-) I have pushed a branch with this series here git://github.com/Sricharanti/sricharan.git branch: crossbar_dts This is on top of your for_3.14/dts branch This series has a dependency with crossbar driver functional changes, which is yet to be pulled https://lkml.org/lkml/2013/12/30/9 Regards, Sricharan I have pushed the below branch for the crossbar-dts data rebased on 3.15-rc4 g...@github.com:Sricharanti/sricharan.git branch: crossbar_dts_3.15_rc4 These patches are dependent on the crossbar driver fixes sent below. http://marc.info/?l=linux-omapm=139929963420299w=2 Regards, Sricharan - -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] PM / OPP: Remove cpufreq wrapper dependency on internal data organization
On 5 May 2014 19:55, Nishanth Menon n...@ti.com wrote: On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org wrote: What if opp is being added for some reason at the same time? I hope we can surely see some awkward results, maybe some NULL pointers invocations as well.. we wont - rcu operations ensure that. Stupid !! Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe 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 V4 0/3] ARM: DTS: DRA7: Updates for adding crossbar device
On 05/05/2014 09:37 AM, Sricharan R wrote: [..] I have pushed the below branch for the crossbar-dts data rebased on 3.15-rc4 g...@github.com:Sricharanti/sricharan.git branch: crossbar_dts_3.15_rc4 These patches are dependent on the crossbar driver fixes sent below. http://marc.info/?l=linux-omapm=139929963420299w=2 I suggest reposting the DTS patches if there has been any changes since the last revision posted. -- Regards, Nishanth Menon -- To unsubscribe 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 0/6] Add CPTS support for AM437x
From: George Cherian george.cher...@ti.com Date: Fri, 2 May 2014 12:01:58 +0530 The series adds CPTS support for AM4372. Patch 1 - DT changes w.r.t clock changes for AM33xx. Patch 2 - CPTS clock name harcoding in the driver is removed. Easier to pass the clock name from dt rather than hardcoding in driver. Also in prepration for DRA7x CPTS support. Patch 3 - Enable the CPTS support for both DRA7x and AM4372 in the driver. Patch 4 - Enable the Annexe F for L2 PTP for AM437x and DRA7x. Patch 5 - Change the default clocksource to dpll_core_m5 Patch 6 - DT changes for AM4372. v1 - v2 Patch 1 and 2 Re-ordering. Seperate TS_BITS define for Hw version V2 and V3 Series applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] irqchip/dra7: crossbar bug fixes
Sricharan R r.sricha...@ti.com wrote on Mon [2014-May-05 19:48:42 +0530]: These are fixes for the crossbar to handle two interrupts getting mapped twice to same crossbar and to skip some interrupts being used due to hardware bugs. Nishanth Menon (5): irqchip: crossbar: dont use '0' to mark reserved interrupts irqchip: crossbar: check for premapped crossbar before allocating irqchip: crossbar: Skip some irqs from getting mapped to crossbar irqchip: crossbar: Initialise the crossbar with a safe value irqchip: crossbar: Change allocation logic by reversing search for free irqs Looks good! I tested this patch series (plus the necessary dts changes) on a DRA7xx-EVM with the work in progress VIP driver which needs a crossbar mapping otherwise it won't get any interrupts (using 3.15-rc4 kernel). It boots cleanly and interrupts are firing for VIP, so everything working for me. Without this patch series I can't even get the DRA7xx EVM to boot with IRQ crossbar support enabled so this is a big improvement. Tested-by: Darren Etheridge detheri...@ti.com drivers/irqchip/irq-crossbar.c | 82 1 file changed, 74 insertions(+), 8 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe 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 1/7] phy: omap-usb2: Use generic clock names wkupclk and refclk
On Mon, May 05, 2014 at 12:54:40PM +0300, Roger Quadros wrote:
As clocks might be named differently on multiple platforms, use a generic
name in the driver and allow device tree node to specify the platform
specific clock name.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/phy/phy-omap-usb2.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index a2205a8..7007c11 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -275,18 +275,34 @@ static int omap_usb2_probe(struct platform_device *pdev)
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
- phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
+ phy-wkupclk = devm_clk_get(phy-dev, wkupclk);
if (IS_ERR(phy-wkupclk)) {
- dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
- return PTR_ERR(phy-wkupclk);
+ dev_warn(pdev-dev, unable to get wkupclk, trying old
name\n);
+ 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);
+ } else {
+ dev_warn(pdev-dev,
+ found usb_phy_cm_clk32k, please fix DTS\n);
+ }
}
clk_prepare(phy-wkupclk);
- phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
- if (IS_ERR(phy-optclk))
- dev_vdbg(pdev-dev, unable to get refclk960m\n);
- else
+ phy-optclk = devm_clk_get(phy-dev, refclk);
+ if (IS_ERR(phy-optclk)) {
+ dev_dbg(pdev-dev, unable to get refclk, trying old name\n);
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_dbg(pdev-dev,
+ unable to get usb_otg_ss_refclk960m\n);
+ } else {
+ dev_warn(pdev-dev,
+ found usb_otg_ss_refclk960m, please fix
DTS\n);
+ }
+ } else {
clk_prepare(phy-optclk);
+ }
usb_add_phy_dev(phy-phy);
--
1.8.3.2
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
* Tony Lindgren t...@atomide.com [140430 10:48]:
* Joachim Eastwood manab...@gmail.com [140429 18:08]:
On 30 April 2014 01:52, Tony Lindgren t...@atomide.com wrote:
Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = vdds_dsi
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = vpll2.
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82
++
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +
arch/arm/boot/dts/omap3-evm-common.dtsi| 47 +
arch/arm/boot/dts/omap3-ldp.dts| 31 ++--
4 files changed, 205 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
diff --git a/arch/arm/boot/dts/omap3-ldp.dts
b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..50fdac9 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,7 @@
#include twl4030.dtsi
#include twl4030_omap3.dtsi
+#include omap-panel-sharp-ls037v7dw01.dtsi
i2c2 {
clock-frequency = 40;
@@ -173,6 +174,31 @@
clock-frequency = 40;
};
+lcd_3v3 {
+ gpio = twl_gpio 7 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+};
+
+lcd0 {
+ reset-gpios = gpio2 23 GPIO_ACTIVE_HIGH; /* gpio55, lcd
RESB */
+ gpios = gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
enable-gpios ?
Oops yes, changed from gpios to enable-gpios while reading the panel
binding doc, probably forgot to commit the change, will update.
Here's an updated version of this one.
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for
omap3-evm and ldp
Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = vdds_dsi
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = vpll2.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = gpio-backlight;
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = regulator-fixed;
+ regulator-name = lcd_3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ startup-delay-us = 7;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = sharp,ls037v7dw01;
+ label = lcd;
+ power-supply = lcd_3v3;
+ panel-timing {
+ clock-frequency = 540;
+ hback-porch = 39;
+ hactive = 240;
+ hfront-porch = 3;
+ hsync-len = 3;
+ vback-porch = 7;
+ vactive = 320;
+ vfront-porch = 2;
+ vsync-len = 1;
+ hsync-active = 0;
+ vsync-active = 0;
+
Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
* Tony Lindgren t...@atomide.com [140429 16:53]: Hi all, Here are few patches to add devicetree support for panel ls037v7dw01 that's found on many omap3 boards. They seem to be often mis-configured as various panel dpi entries, but really should be move to use panel ls037v7dw01 instead. This panel is found at least on the omap3 sdp, ldp, omap3 evm and few other development boards. Tomi, assuming no more comments, do you want to pick up the first three patches of this series? I can queue the .dts changes or you can also set up a separate .dts changes branch for DSS that I can merge in too. Tony Regards, Tony Tony Lindgren (4): OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630 OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod OMAPDSS: panel-sharp-ls037v7dw01: add device tree support ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp .../bindings/panel/sharp,ls037v7dw01.txt | 53 +++ .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++ arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++ arch/arm/boot/dts/omap3-evm-common.dtsi| 47 ++ arch/arm/boot/dts/omap3-ldp.dts| 31 +++- .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 176 ++--- drivers/video/fbdev/omap2/dss/dss.c| 5 +- 7 files changed, 379 insertions(+), 65 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi -- 1.8.1.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 -- To unsubscribe 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/5] Add USB nodes for am43xx epos and gp evm
* George Cherian george.cher...@ti.com [140505 01:04]: Hi Benoit, On 4/25/2014 9:49 PM, Felipe Balbi wrote: On Wed, Mar 19, 2014 at 03:39:58PM +0530, George Cherian wrote: The patch series adds USB dt nodes for am43xx epos and gp evm Boot tested with linux-next + Tony's omap-for-v3.15/dt Changes from v1 - v2 * Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue * Address v1 coments on ARM: dts: AM4372: Add USB nodes Changes from v2 - v3 * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts and am43x-epos-evm.dts Changes from v3 - v4 * Refreshed on top of Tony's omap-for-v3.15/dt tree * Added usb_phy0_always_on_clk32k and usb_phy1_always_on_clk32k Patch 2 * Used the above clocks in Patch 3 * Patch 4 and 5 edited the unwanted portions of commit log Changes from v4 - v5 * Address Roger's comment for the clock data George Cherian (5): doc: Add ti,am437x-dwc3 comaptible for dwc3 glue 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 Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- arch/arm/boot/dts/am4372.dtsi | 94 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 18 + arch/arm/boot/dts/am43x-epos-evm.dts | 18 + arch/arm/boot/dts/am43xx-clocks.dtsi | 32 5 files changed, 165 insertions(+), 1 deletion(-) Is this applied anywhere yet ? Benoit, are you taking this for v3.16 merge window ? Ping on this series. Applying these into omap-for-v3.16/dt as I'm applying patches today. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DTS: ARM: OMAP3-N900: Add WL1251 support
* Sebastian Reichel s...@debian.org [140313 15:03]:
Add device tree support for the wireless chip
built into the Nokia N900.
Signed-off-by: Sebastian Reichel s...@debian.org
Thanks applying into omap-for-v3.16/dt.
Tony
---
arch/arm/boot/dts/omap3-n900.dts | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index e91dae7..0f48b9b 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -148,6 +148,15 @@
;
};
+ mcspi4_pins: pinmux_mcspi4_pins {
+ pinctrl-single,pins =
+ 0x15c (PIN_INPUT_PULLDOWN | MUX_MODE1) /* mcspi4_clk */
+ 0x162 (PIN_INPUT_PULLDOWN | MUX_MODE1) /* mcspi4_somi */
+ 0x160 (PIN_OUTPUT | MUX_MODE1) /* mcspi4_simo */
+ 0x166 (PIN_OUTPUT | MUX_MODE1) /* mcspi4_cs0 */
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/* sdmmc1_clk */
@@ -203,6 +212,13 @@
0x15e (PIN_OUTPUT | MUX_MODE4) /* gpio 157 =
cmt_bsi */
;
};
+
+ wl1251_pins: pinmux_wl1251 {
+ pinctrl-single,pins =
+ 0x0ce (PIN_OUTPUT | MUX_MODE4) /* gpio 87 =
wl1251 enable */
+ 0x05a (PIN_INPUT | MUX_MODE4) /* gpio 42 =
wl1251 irq */
+ ;
+ };
};
i2c1 {
@@ -603,6 +619,30 @@
};
};
+mcspi4 {
+ pinctrl-names = default;
+ pinctrl-0 = mcspi4_pins;
+
+ wl1251@0 {
+ pinctrl-names = default;
+ pinctrl-0 = wl1251_pins;
+
+ vio-supply = vio;
+
+ compatible = ti,wl1251;
+ reg = 0;
+ spi-max-frequency = 4800;
+
+ spi-cpol;
+ spi-cpha;
+
+ ti,power-gpio = gpio3 23 GPIO_ACTIVE_HIGH; /* 87 */
+
+ interrupt-parent = gpio2;
+ interrupts = 10 IRQ_TYPE_NONE; /* gpio line 42 */
+ };
+};
+
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
--
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: [PATCHv3 00/14] OMAP SSI driver / N900 modem support
* Sebastian Reichel s...@kernel.org [140328 17:36]: Please send feedback (e.g. Tested-By or Reviewed-By :)), so that I can send a pull request for 3.16. You can either apply this patchset or use the n900-modem-support branch available on [1]. Sebastian, can you please do a separate pull request for the .dts changes for me once the driver changes are pulled? Otherwise we will be creating pointless merge conflicts. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/5] Input: add common DT binding for touchscreens
* Sebastian Reichel s...@kernel.org [140425 16:56]: Add common DT binding documentation for touchscreen devices and implement input_parse_touchscreen_of_params, which parses the common properties and configures the input device accordingly. The method currently does not interpret the axis inversion properties, since there is no matching flag in the generic linux input device. Signed-off-by: Sebastian Reichel s...@kernel.org --- .../bindings/input/touchscreen/touchscreen.txt | 27 + drivers/input/input.c | 34 ++ include/linux/input.h | 8 + 3 files changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt new file mode 100644 index 000..d8e0616 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt @@ -0,0 +1,27 @@ +General Touchscreen Properties: + +Optional properties for Touchscreens: + - touchscreen-size-x: horizontal resolution of touchscreen + (in pixels) + - touchscreen-size-y: vertical resolution of touchscreen + (in pixels) + - touchscreen-max-pressure : maximum reported pressure (arbitrary range + dependent on the controller) + - touchscreen-fuzz-x: horizontal noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-y: vertical noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-pressure : pressure noise value of the absolute input + device (arbitrary range dependent on the + controller) + - touchscreen-inverted-x: X axis is inverted (boolean) + - touchscreen-inverted-y: Y axis is inverted (boolean) We probably also need something to swap x and y depending on the display orientation in addition to the touchscreen-inverted-x and y. Just swapping x and y is not enough depending if we rotate by 270 degrees instead of 90 degrees. Naturally that part can be added later. Regards, That -- To unsubscribe 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: [PATCHv2 9/9] DTS: OMAP3-N900: Add sound support
* Mark Brown broo...@kernel.org [140501 11:41]: On Mon, Apr 28, 2014 at 04:07:27PM +0200, Sebastian Reichel wrote: This patch adds support for the Nokia N900's sound system. Reviewed-by: Mark Brown broo...@linaro.org Applying the last patch into omap-for-v3.16/dt branch thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/5] Input: add common DT binding for touchscreens
On Mon, May 05, 2014 at 12:41:26PM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@kernel.org [140425 16:56]: Add common DT binding documentation for touchscreen devices and implement input_parse_touchscreen_of_params, which parses the common properties and configures the input device accordingly. The method currently does not interpret the axis inversion properties, since there is no matching flag in the generic linux input device. Signed-off-by: Sebastian Reichel s...@kernel.org --- .../bindings/input/touchscreen/touchscreen.txt | 27 + drivers/input/input.c | 34 ++ include/linux/input.h | 8 + 3 files changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt new file mode 100644 index 000..d8e0616 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt @@ -0,0 +1,27 @@ +General Touchscreen Properties: + +Optional properties for Touchscreens: + - touchscreen-size-x : horizontal resolution of touchscreen + (in pixels) + - touchscreen-size-y : vertical resolution of touchscreen + (in pixels) + - touchscreen-max-pressure: maximum reported pressure (arbitrary range + dependent on the controller) + - touchscreen-fuzz-x : horizontal noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-y : vertical noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-pressure : pressure noise value of the absolute input + device (arbitrary range dependent on the + controller) Fuzz seems like linux-specific property, not generic one. + - touchscreen-inverted-x : X axis is inverted (boolean) + - touchscreen-inverted-y : Y axis is inverted (boolean) We probably also need something to swap x and y depending on the display orientation in addition to the touchscreen-inverted-x and y. Just swapping x and y is not enough depending if we rotate by 270 degrees instead of 90 degrees. Naturally that part can be added later. So far we've been relying on upper layers (such as tslib) to perform such transformations rather than re-implementing it in every driver. Are we saying that we need to implement this in input core? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] arm: n950: Add missing regulator definitions
* Sakari Ailus sakari.ai...@iki.fi [140503 17:20]:
The N950/N9 uses two additional regulators from the twl 4030 for CSI-2
receiver (vaux2) and cameras (vaux3).
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Thanks applying into omap-for-v3.16/dt.
Tony
---
arch/arm/boot/dts/omap3-n950-n9.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 5c26c18..7d64f30 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -67,6 +67,20 @@
ti,pulldowns= 0x008106; /* BIT(1) | BIT(2) | BIT(8) | BIT(15) */
};
+/* CSI-2 receiver */
+vaux2 {
+ regulator-name = vaux2;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+};
+
+/* Cameras */
+vaux3 {
+ regulator-name = vaux3;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+};
+
i2c2 {
clock-frequency = 40;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe 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] ARM: dts: OMAP5: add pmu node
* Nathan Lynch nathan_ly...@mentor.com [140319 08:50]:
Expose the PMU on OMAP5.
Tested with perf on OMAP5 uEVM.
Signed-off-by: Nathan Lynch nathan_ly...@mentor.com
Applying into omap-for-v3.16/dt thanks.
Tony
---
Changes since v1:
- Use symbolic constants.
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a9663e..ccb38944c85a 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -76,6 +76,12 @@
GIC_PPI 10 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_LOW);
};
+ pmu {
+ compatible = arm,cortex-a15-pmu;
+ interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH;
+ };
+
gic: interrupt-controller@48211000 {
compatible = arm,cortex-a15-gic;
interrupt-controller;
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: am437x-gp-evm: Add vtt_fixed regulator
The VTT regulator for DDR3 termination on the am437x-gp-evm is
controlled by a gpio. It is configured by the bootloader so here we
define an always-on, fixed voltage regulator to hold the gpio.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..6e61e42 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -27,6 +27,17 @@
enable-active-high;
};
+ vtt_fixed: fixedregulator-vtt {
+ compatible = regulator-fixed;
+ regulator-name = vtt_fixed;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = gpio5 7 GPIO_ACTIVE_HIGH;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
--
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 0/2] Add VTT regulators for DDR3 AMx3xx Boards
The am335x-evmsk and am437x-gp-evm both have a gpio controlled regulator for DDR3 VTT voltage. This is configured by boot loader and previously just left at that but it is better to define a fixed regulator to control the gpio so that the kernel is aware of it. Previous discussion here [1]. Original am437x-gp-evm patch has been updated to reflect actual voltage supplied by VTT regulator. Regards, Dave [1] http://marc.info/?l=linux-omapm=139819277623028w=2 Dave Gerlach (2): ARM: dts: am437x-gp-evm: Add vtt_fixed regulator ARM: dts: am335x-evmsk: Add vtt_fixed regulator arch/arm/boot/dts/am335x-evmsk.dts | 11 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 11 +++ 2 files changed, 22 insertions(+) -- 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 2/2] ARM: dts: am335x-evmsk: Add vtt_fixed regulator
The VTT regulator for DDR3 termination on the am335x-evmsk is
controlled by a gpio. It is configured by the bootloader so here we
define an always-on, fixed voltage regulator to hold the gpio.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab23885..d6b8acb 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -57,6 +57,17 @@
enable-active-high;
};
+ vtt_fixed: fixedregulator@3 {
+ compatible = regulator-fixed;
+ regulator-name = vtt;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ gpio = gpio0 7 GPIO_ACTIVE_HIGH;
+ regulator-always-on;
+ regulator-boot-on;
+ enable-active-high;
+ };
+
leds {
pinctrl-names = default;
pinctrl-0 = user_leds_s0;
--
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
[GIT PULL #2/2] ARM: dts: DRA7/AM437x l3noc dts updates
Hi Tony, Please pull the following to the dts support of AM437x and DRA7 support for l3_noc for the upcoming 3.16 window. This series was posted http://marc.info/?l=linux-omapm=139750288003978w=2 and the functionality enabled by the first pull request for driver. The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/l3noc/dts-fixes for you to fetch changes up to 2eeddb8a5356e088021a8dd84de870de89bf793d: ARM: dts: AM4372: add l3-noc information (2014-05-05 14:35:29 -0500) Afzal Mohammed (1): ARM: dts: AM4372: add l3-noc information Rajendra Nayak (1): ARM: dts: DRA7: Use dra7-l3-noc instead of omap4-l3-noc arch/arm/boot/dts/am4372.dtsi |6 +- arch/arm/boot/dts/dra7.dtsi |6 +++--- 2 files changed, 8 insertions(+), 4 deletions(-) -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2] TI Reset Driver adapted to the reset core
All I have made some big changes to this patchset so I did not put all the changes in the patches themselves. In brief - I removed the object data files for each SoC and moved the data into the DT. I updated the binding document as well - The DT implementation creates a parent reset node with the base offset for each reset and the children within that parent declares the bit mask - I created a xlate function in the reset driver to verify that reset data and that the phandle exists. The core xlate checks for the nr_resets which we don't care about since we are not indexed based. - Made the driver a platform driver as well so this removed the prm_common patch as well as the header file. I will add other TI devices once I feel comfortable that the design is acceptable. Dan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [v2 Patch 3/6] ARM: dts: am33xx: Add prcm_resets node
Add the prcm_resets node to the prcm parent node.
Add the am33xx_resets file to define the
am33xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/am33xx-resets.dtsi | 42 ++
arch/arm/boot/dts/am33xx.dtsi|7 ++
2 files changed, 49 insertions(+)
create mode 100644 arch/arm/boot/dts/am33xx-resets.dtsi
diff --git a/arch/arm/boot/dts/am33xx-resets.dtsi
b/arch/arm/boot/dts/am33xx-resets.dtsi
new file mode 100644
index 000..9260626
--- /dev/null
+++ b/arch/arm/boot/dts/am33xx-resets.dtsi
@@ -0,0 +1,42 @@
+/*
+ * Device Tree Source for AM33XX reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prcm_resets {
+ gfx_rstctrl {
+ reg = 0x1104,
+ 0x1114;
+
+ gfx_reset: gfx_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ per_rstctrl {
+ reg = 0xD00,
+ 0xD0C;
+
+ iva_reset: iva_reset {
+ control-bit = 0x04;
+ status-bit = 0x10;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0xf00,
+ 0xf08;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index cb6811e..6b1a6df 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -117,6 +117,12 @@
prcm_clockdomains: clockdomains {
};
+
+ prcm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
scrm: scrm@44e1 {
@@ -833,3 +839,4 @@
};
/include/ am33xx-clocks.dtsi
+/include/ am33xx-resets.dtsi
--
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
[RFC] [v2 Patch 4/6] ARM: dts: am4372: Add prcm_resets node
Add the prcm_resets node to the prcm parent node.
Add the am34xx_resets file to define the
am34xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/am4372.dtsi|7 +
arch/arm/boot/dts/am43xx-resets.dtsi | 52 ++
2 files changed, 59 insertions(+)
create mode 100644 arch/arm/boot/dts/am43xx-resets.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d1f8707..e1ba7ed 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -84,6 +84,12 @@
prcm_clockdomains: clockdomains {
};
+
+ prcm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
scrm: scrm@44e1 {
@@ -739,3 +745,4 @@
};
/include/ am43xx-clocks.dtsi
+/include/ am43xx-resets.dtsi
diff --git a/arch/arm/boot/dts/am43xx-resets.dtsi
b/arch/arm/boot/dts/am43xx-resets.dtsi
new file mode 100644
index 000..ef338ba
--- /dev/null
+++ b/arch/arm/boot/dts/am43xx-resets.dtsi
@@ -0,0 +1,52 @@
+/*
+ * Device Tree Source for AM43XX reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prcm_resets {
+ icss_rstctrl {
+ reg = 0x810,
+ 0x814;
+
+ icss_reset: icss_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ gfx_rstctrl {
+ reg = 0x410,
+ 0x414;
+
+ gfx_reset: gfx_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ per_rstctrl {
+ reg = 0x2010,
+ 0x2014;
+
+ iva_reset: iva_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0x4000,
+ 0x4004;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+};
--
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
[RFC] [v2 Patch 1/6] drivers: reset: TI: SoC reset controller support.
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy dmur...@ti.com
---
drivers/reset/Kconfig|1 +
drivers/reset/Makefile |1 +
drivers/reset/ti/Kconfig |8 ++
drivers/reset/ti/Makefile|1 +
drivers/reset/ti/reset-ti-data.h | 56
drivers/reset/ti/reset-ti.c | 267 ++
6 files changed, 334 insertions(+)
create mode 100644 drivers/reset/ti/Kconfig
create mode 100644 drivers/reset/ti/Makefile
create mode 100644 drivers/reset/ti/reset-ti-data.h
create mode 100644 drivers/reset/ti/reset-ti.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..a58d789 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source drivers/reset/sti/Kconfig
+source drivers/reset/ti/Kconfig
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4f60caf..1c8c444 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_RESET_TI) += ti/
diff --git a/drivers/reset/ti/Kconfig b/drivers/reset/ti/Kconfig
new file mode 100644
index 000..dcdce90
--- /dev/null
+++ b/drivers/reset/ti/Kconfig
@@ -0,0 +1,8 @@
+config RESET_TI
+ depends on RESET_CONTROLLER
+ bool TI reset controller
+ help
+ Reset controller support for TI SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x and OMAP SoC's like OMAP5 and DRA7
diff --git a/drivers/reset/ti/Makefile b/drivers/reset/ti/Makefile
new file mode 100644
index 000..55ab3f5
--- /dev/null
+++ b/drivers/reset/ti/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RESET_TI) += reset-ti.o
diff --git a/drivers/reset/ti/reset-ti-data.h b/drivers/reset/ti/reset-ti-data.h
new file mode 100644
index 000..4d2a6d5
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,56 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _RESET_TI_DATA_H_
+#define _RESET_TI_DATA_H_
+
+#include linux/kernel.h
+#include linux/reset-controller.h
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ * for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ * from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ * from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * This structure describes the reset register control and status offsets.
+ * The bits are also defined for the same.
+ */
+struct ti_reset_reg_data {
+ void __iomem *reg_base;
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u32 rstctrl_bit;
+ u32 rstst_bit;
+};
+
+/**
+ * struct ti_reset_data - Structure that contains the reset register data
+ * as well as the total number of resets for a particular SoC.
+ * @reg_data: Pointer to the register data structure.
+ * @nr_resets: Total number of resets for the SoC in the reset array.
+ *
+ * This structure contains a pointer to the register data and the modules
+ * register base. The number of resets and reset controller device data is
+ * stored within this structure.
+ *
+ */
+struct ti_reset_data {
+ struct ti_reset_reg_data *reg_data;
+ struct reset_controller_dev rcdev;
+};
+
+#endif
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
new file mode 100644
index 000..349f4fb
--- /dev/null
+++ b/drivers/reset/ti/reset-ti.c
@@ -0,0 +1,267 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of
[RFC] [v2 Patch 5/6] ARM: dts: dra7: Add prm_resets node
Add the prcm_resets node to the prm parent node.
Add the draxx_resets file to define the
dra7xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/dra7.dtsi |7 +++
arch/arm/boot/dts/dra7xx-resets.dtsi | 82 ++
2 files changed, 89 insertions(+)
create mode 100644 arch/arm/boot/dts/dra7xx-resets.dtsi
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b550..c008996 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,12 @@
prm_clockdomains: clockdomains {
};
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
cm_core_aon: cm_core_aon@4a005000 {
@@ -793,3 +799,4 @@
};
/include/ dra7xx-clocks.dtsi
+/include/ dra7xx-resets.dtsi
diff --git a/arch/arm/boot/dts/dra7xx-resets.dtsi
b/arch/arm/boot/dts/dra7xx-resets.dtsi
new file mode 100644
index 000..4c4966d
--- /dev/null
+++ b/arch/arm/boot/dts/dra7xx-resets.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Device Tree Source for DRA7XX reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x410,
+ 0x414;
+
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ dsp_mmu_reset: dsp_mmu_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+ };
+
+ ipu_rstctrl {
+ reg = 0x510,
+ 0x514;
+
+ ipu_cpu0_reset: ipu_cpu0_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ ipu_cpu1_reset: ipu_cpu1_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+
+ ipu_mmu_reset: ipu_mmu_reset {
+ control-bit = 0x04;
+ status-bit = 0x04;
+ };
+ };
+
+ iva_rstctrl {
+ reg = 0xf10,
+ 0xf14;
+
+ iva_reset: iva_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ pcie_rstctrl {
+ reg = 0x1310,
+ 0x1314;
+
+ pcie1_reset: pcie1_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ pcie2_reset: pcie2_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0x1D00,
+ 0x1D04;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+};
--
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
[GIT PULL #1/2] bus: omap_l3_noc: driver fixes and DRA7/AM437x support
Hi Tony, Please pull the following driver fixes based on V3 of l3noc fixes and support for DRA7 and AM437x for upcoming 3.16 window. http://marc.info/?l=linux-omapm=139869922030493w=2 This is part 1 of the pull request containing purely the driver updates. The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: https://github.com/nmenon/linux-2.6-playground.git pull/l3noc/driver-fixes for you to fetch changes up to 27b7d5f3cc49f2e5cd6c005d73696058b7140c5c: bus: omap_l3_noc: Add AM4372 interconnect error data (2014-05-05 14:34:37 -0500) Afzal Mohammed (2): bus: omap_l3_noc: ignore masked out unclearable targets bus: omap_l3_noc: Add AM4372 interconnect error data Nishanth Menon (14): bus: omap_l3_noc: Fix copyright information bus: omap_l3_noc: remove iclk from omap_l3 struct bus: omap_l3_noc: populate l3-dev and use it bus: omap_l3_noc: switch over to relaxed variants of readl/writel bus: omap_l3_noc: un-obfuscate l3_targ address computation bus: omap_l3_noc: move L3 master data structure out bus: omap_l3_noc: convert target information into a structure bus: omap_l3_noc: convert flagmux information into a structure bus: omap_l3_noc: fix masterid detection bus: omap_l3_noc: make error reporting and handling common bus: omap_l3_noc: improve readability by using helper for slave event parsing bus: omap_l3_noc: add information about the type of operation bus: omap_l3_noc: Add information about the context of operation bus: omap_l3_noc: introduce concept of submodule Peter Ujfalusi (5): drivers: bus: omap_l3: Convert to use devm_kzalloc drivers: bus: omap_l3: Convert to use devm_ioremap_resource() drivers: bus: omap_l3: Convert to use devm_request_irq() drivers: bus: omap_l3: Remove the platform driver's remove function drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails Rajendra Nayak (2): bus: omap_l3_noc: Add support for discountinous flag mux input numbers bus: omap_l3_noc: Add DRA7 interconnect error data Sricharan R (2): bus: omap_l3_noc: rename functions and data to omap_l3 bus: omap_l3_noc: use of_match_data to pick up SoC information .../devicetree/bindings/arm/omap/l3-noc.txt|2 + drivers/bus/omap_l3_noc.c | 406 --- drivers/bus/omap_l3_noc.h | 545 +++- 3 files changed, 653 insertions(+), 300 deletions(-) -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [v2 Patch 2/6] ARM: TI: Describe the ti reset DT entries
Describe the TI reset DT entries for TI SoC's.
Signed-off-by: Dan Murphy dmur...@ti.com
---
.../devicetree/bindings/reset/ti,reset.txt | 103
1 file changed, 103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
diff --git a/Documentation/devicetree/bindings/reset/ti,reset.txt
b/Documentation/devicetree/bindings/reset/ti,reset.txt
new file mode 100644
index 000..9d5c29c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,reset.txt
@@ -0,0 +1,103 @@
+Texas Instruments Reset Controller
+==
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Specifying the reset entries for the IP module
+==
+Parent module:
+This is the module node that contains the reset registers and bits.
+
+example:
+ prcm_resets: resets {
+ compatible = ti,dra7-resets;
+ #reset-cells = 1;
+ };
+
+Required parent properties:
+- compatible : Should be one of,
+ ti,omap4-prm for OMAP4 PRM instances
+ ti,omap5-prm for OMAP5 PRM instances
+ ti,dra7-prm for DRA7xx PRM instances
+ ti,am4-prcm for AM43xx PRCM instances
+ ti,am3-prcm for AM33xx PRCM instances
+
+Required child reset property:
+- compatible : Should be
+ resets for All TI SoCs
+
+example:
+ prm: prm@4ae06000 {
+ compatible = ti,omap5-prm;
+ reg = 0x4ae06000 0x3000;
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
+ };
+
+
+Reset node declaration
+==
+The reset node is declared in a parent child relationship. The main parent
+is the PRCM module which contains the base address. The first child within
+the reset parent declares the target modules reset name. This is followed by
+the control and status offsets.
+
+Within the first reset child node is a secondary child node which declares the
+reset signal of interest. Under this node the control and status bits
+are declared. These bits declare the bit mask for the target reset.
+
+
+Required properties:
+reg - This is the register offset from the PRCM parent.
+ This must be declared as:
+
+ reg = control register offset,
+ status register offset;
+
+control-bit - This is the bit within the register which controls the reset
+ of the target module. This is declared as a bit mask for the register.
+status-bit - This is the bit within the register which contains the status of
+ the reset of the target module.
+ This is declared as a bit mask for the register.
+
+example:
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
+
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+};
+
+
+
+Client Node Declaration
+==
+This is the consumer of the parent node to declare what resets this
+particular module is interested in.
+
+example:
+ src: src@55082000 {
+ resets = reset_src phandle;
+ reset-names = reset_name;
+ };
+
+Required Properties:
+reset_src - This is the parent DT entry for the reset controller
+phandle - This is the phandle of the specific reset to be used by the clien
+ driver.
+reset-names - This is the reset name of module that the device driver
+ needs to be able to reset. This value must correspond to a value within
+ the reset controller array.
+
+example:
+resets = prm_resets dsp_mmu_reset;
+reset-names = dsp_mmu_reset;
--
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
[RFC] [v2 Patch 6/6] ARM: dts: omap5: Add prm_resets node
Add the prm_resets node to the prm parent node.
Add the omap54xx_resets file to define the
omap5 reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |7
arch/arm/boot/dts/omap54xx-resets.dtsi | 66
2 files changed, 73 insertions(+)
create mode 100644 arch/arm/boot/dts/omap54xx-resets.dtsi
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f8c9855..b6e3c4c 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -134,6 +134,12 @@
prm_clockdomains: clockdomains {
};
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
cm_core_aon: cm_core_aon@4a004000 {
@@ -873,3 +879,4 @@
};
/include/ omap54xx-clocks.dtsi
+/include/ omap54xx-resets.dtsi
diff --git a/arch/arm/boot/dts/omap54xx-resets.dtsi
b/arch/arm/boot/dts/omap54xx-resets.dtsi
new file mode 100644
index 000..cba6f52
--- /dev/null
+++ b/arch/arm/boot/dts/omap54xx-resets.dtsi
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Source for OMAP5 reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
+
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ dsp_mmu_reset: dsp_mmu_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+ };
+
+ ipu_rstctrl {
+ reg = 0x910,
+ 0x914;
+
+ ipu_cpu0_reset: ipu_cpu0_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ ipu_cpu1_reset: ipu_cpu1_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+
+ ipu_mmu_reset: ipu_mmu_reset {
+ control-bit = 0x04;
+ status-bit = 0x04;
+ };
+ };
+
+ iva_rstctrl {
+ reg = 0x1210,
+ 0x1214;
+
+ iva_reset: iva_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/5] Input: add common DT binding for touchscreens
* Dmitry Torokhov dmitry.torok...@gmail.com [140505 12:52]: On Mon, May 05, 2014 at 12:41:26PM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@kernel.org [140425 16:56]: Add common DT binding documentation for touchscreen devices and implement input_parse_touchscreen_of_params, which parses the common properties and configures the input device accordingly. The method currently does not interpret the axis inversion properties, since there is no matching flag in the generic linux input device. Signed-off-by: Sebastian Reichel s...@kernel.org --- .../bindings/input/touchscreen/touchscreen.txt | 27 + drivers/input/input.c | 34 ++ include/linux/input.h | 8 + 3 files changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt new file mode 100644 index 000..d8e0616 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt @@ -0,0 +1,27 @@ +General Touchscreen Properties: + +Optional properties for Touchscreens: + - touchscreen-size-x: horizontal resolution of touchscreen + (in pixels) + - touchscreen-size-y: vertical resolution of touchscreen + (in pixels) + - touchscreen-max-pressure : maximum reported pressure (arbitrary range + dependent on the controller) + - touchscreen-fuzz-x: horizontal noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-y: vertical noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-pressure : pressure noise value of the absolute input + device (arbitrary range dependent on the + controller) Fuzz seems like linux-specific property, not generic one. + - touchscreen-inverted-x: X axis is inverted (boolean) + - touchscreen-inverted-y: Y axis is inverted (boolean) We probably also need something to swap x and y depending on the display orientation in addition to the touchscreen-inverted-x and y. Just swapping x and y is not enough depending if we rotate by 270 degrees instead of 90 degrees. Naturally that part can be added later. So far we've been relying on upper layers (such as tslib) to perform such transformations rather than re-implementing it in every driver. Are we saying that we need to implement this in input core? We seem to have that already partially implemented at least with ti,swap-xy in Documentation/devicetree/bindings/input/ads7846.txt. But that only works for the 90 degree rotation case as it's missing something similar to touchscreen-inverted-x I just noticed few days ago while trying to make some legacy code disappear :) No idea where rotation should be specified. But if the panel is rotated based on the DT property or kernel cmdline, probably the touchscreen should be too? In most cases touchscreens are integrated together with the LCD panel, and they are not separate like other input devices. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna s-a...@ti.com wrote: The HwSpinlock core requires a base id for registering a bank of hwspinlocks. This base id needs to be unique across multiple IP instances of a hwspinlock device, so that each hwlock can be represented uniquely in a system. Support has been added to represent this in DT through a common property 'hwlock-base-id', and retrieve the value through a core OF helper function, of_hwspin_lock_get_base_id(). The representation in DT provides a uniform way of assigning a fixed base value for a hwspinlock device across different SoCs. Signed-off-by: Suman Anna s-a...@ti.com --- Documentation/devicetree/bindings/hwlock/hwlock.txt | 6 ++ drivers/hwspinlock/hwspinlock_core.c| 21 + include/linux/hwspinlock.h | 1 + 3 files changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt index 32381cc..d538a9b 100644 --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -18,6 +18,12 @@ Common properties: property is needed on hwlock devices, where the number of supported locks within a hwlock device cannot be read from a register. +- hwlock-base-id: An unique base Id for the locks for a particular hwlock + device. This property is mandatory ONLY if a SoC has + several hwlock devices. + + See documentation on struct hwspinlock_pdata in + include/linux/hwspinlock.h for more details. The documentation cannot refer to kernel files. Generally, creating a global number space like this would not be accepted, but I don't really have any better idea here. Please put all binding docs in 1 patch and copy all the DT binding maintainers. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.14 012/158] ARM: dts: am33xx: correcting dt node unit address for usb
On Mon, May 05, 2014 at 10:37:57AM +0200, Johan Hovold wrote: On Sun, May 04, 2014 at 11:38:41AM -0400, Greg Kroah-Hartman wrote: 3.14-stable review patch. If anyone has any objections, please let me know. This one should not be backported without commit a2f8d6b30321 (ARM: dts: am335x: update USB DT references) which is in Linus' tree but is not marked for stable (or USB will be disabled for the boards relying on the old node addresses). Thanks for letting me know, I've now applied that patch as well. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [v2 Patch 1/6] drivers: reset: TI: SoC reset controller support.
Hi,
On Mon, May 05, 2014 at 03:09:22PM -0500, Dan Murphy wrote:
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
you should break your commit log at around 72 characters at most.
Signed-off-by: Dan Murphy dmur...@ti.com
---
drivers/reset/Kconfig|1 +
drivers/reset/Makefile |1 +
drivers/reset/ti/Kconfig |8 ++
drivers/reset/ti/Makefile|1 +
drivers/reset/ti/reset-ti-data.h | 56
drivers/reset/ti/reset-ti.c | 267
++
6 files changed, 334 insertions(+)
create mode 100644 drivers/reset/ti/Kconfig
create mode 100644 drivers/reset/ti/Makefile
create mode 100644 drivers/reset/ti/reset-ti-data.h
create mode 100644 drivers/reset/ti/reset-ti.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..a58d789 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
source drivers/reset/sti/Kconfig
+source drivers/reset/ti/Kconfig
this driver is so small that I'm not sure you need a directory for it.
diff --git a/drivers/reset/ti/Kconfig b/drivers/reset/ti/Kconfig
new file mode 100644
index 000..dcdce90
--- /dev/null
+++ b/drivers/reset/ti/Kconfig
@@ -0,0 +1,8 @@
+config RESET_TI
+ depends on RESET_CONTROLLER
don't you want to depend on ARCH_OMAP || COMPILE_TEST ?
diff --git a/drivers/reset/ti/reset-ti-data.h
b/drivers/reset/ti/reset-ti-data.h
new file mode 100644
index 000..4d2a6d5
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,56 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
this is not the TI aproved way for copyright notices. Yeah,
nit-picking...
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _RESET_TI_DATA_H_
+#define _RESET_TI_DATA_H_
+
+#include linux/kernel.h
+#include linux/reset-controller.h
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ * for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ * from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ * from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * This structure describes the reset register control and status offsets.
+ * The bits are also defined for the same.
+ */
+struct ti_reset_reg_data {
+ void __iomem *reg_base;
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u32 rstctrl_bit;
+ u32 rstst_bit;
this structure can be folded into struct ti_reset_data and all of that
can be initialized during probe.
+};
+
+/**
+ * struct ti_reset_data - Structure that contains the reset register data
+ * as well as the total number of resets for a particular SoC.
+ * @reg_data:Pointer to the register data structure.
+ * @nr_resets: Total number of resets for the SoC in the reset array.
+ *
+ * This structure contains a pointer to the register data and the modules
+ * register base. The number of resets and reset controller device data is
+ * stored within this structure.
+ *
+ */
+struct ti_reset_data {
+ struct ti_reset_reg_data *reg_data;
+ struct reset_controller_dev rcdev;
+};
+
+#endif
this entire file can be moved into the .c file. It's too small and the
only user for these new types is the .c driver anyway.
diff --git a/drivers/reset/ti/reset-ti.c b/drivers/reset/ti/reset-ti.c
new file mode 100644
index 000..349f4fb
--- /dev/null
+++ b/drivers/reset/ti/reset-ti.c
@@ -0,0 +1,267 @@
+/*
+ * PRCM reset driver for TI SoC's
+ *
+ * Copyright 2014 Texas Instruments Inc.
+ *
+ * Author: Dan Murphy dmur...@ti.com
fix copyright notice here too
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License
Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
Hi Rob, On 05/05/2014 03:37 PM, Rob Herring wrote: On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna s-a...@ti.com wrote: The HwSpinlock core requires a base id for registering a bank of hwspinlocks. This base id needs to be unique across multiple IP instances of a hwspinlock device, so that each hwlock can be represented uniquely in a system. Support has been added to represent this in DT through a common property 'hwlock-base-id', and retrieve the value through a core OF helper function, of_hwspin_lock_get_base_id(). The representation in DT provides a uniform way of assigning a fixed base value for a hwspinlock device across different SoCs. Signed-off-by: Suman Anna s-a...@ti.com --- Documentation/devicetree/bindings/hwlock/hwlock.txt | 6 ++ drivers/hwspinlock/hwspinlock_core.c| 21 + include/linux/hwspinlock.h | 1 + 3 files changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt index 32381cc..d538a9b 100644 --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -18,6 +18,12 @@ Common properties: property is needed on hwlock devices, where the number of supported locks within a hwlock device cannot be read from a register. +- hwlock-base-id: An unique base Id for the locks for a particular hwlock + device. This property is mandatory ONLY if a SoC has + several hwlock devices. + + See documentation on struct hwspinlock_pdata in + include/linux/hwspinlock.h for more details. The documentation cannot refer to kernel files. OK, good to know. There are couple of such existing references, so didn't think it was an issue. I will fold this patch and remove the kernel reference if this property is ok to add. Generally, creating a global number space like this would not be accepted, but I don't really have any better idea here. Please put all binding docs in 1 patch and copy all the DT binding maintainers. I have deliberately put these in separate patches (as RFC) as there doesn't seem to be a consensus on this. I had added this originally, dropped it and brought it back again based on discussion on the previous version. Intention was either to fold into the original patch if accepted or drop them and revisit later. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
Hi Rob,
On 04/30/2014 07:34 PM, Suman Anna wrote:
The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.
The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 3 +++
drivers/hwspinlock/hwspinlock_core.c | 25
++
include/linux/hwspinlock.h | 1 +
3 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
property is needed on hwlock devices, where the number
of supported locks within a hwlock device cannot be
read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+ specific locks. This value cannot exceed the value of
+ hwlock-num-locks.
Any suggestions here on the approach? This property falls into a gray
area as well, as the current approach is somewhat limiting (it doesn't
support sparse reserved locks, and expects them at the beginning of the
lock range).
regards
Suman
- hwlock-base-id:An unique base Id for the locks for a particular hwlock
device. This property is mandatory ONLY if a SoC has
several hwlock devices.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index e05cea8..e74b55b 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
/**
+ * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved
locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
platform
+ * specific implementations, to retrieve the number of locks to reserve from
+ * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
+ * property needs to be defined for requesting any DT-based locks.
+ *
+ * Returns a positive number of locks on success, a default value of 0 if the
+ * property is missing or an appropriate error code as returned by the OF
layer
+ */
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
+{
+ unsigned int val = 0;
+ int ret;
+
+ ret = of_property_read_u32(dn, hwlock-reserved-locks, val);
+ if (!ret || ret == -EINVAL)
+ ret = val;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
+
+/**
* of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
* @dn: device node pointer
*
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index d120035..d18431f 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device
*bank,
const struct of_phandle_args *hwlock_spec);
int of_hwspin_lock_get_base_id(struct device_node *dn);
int of_hwspin_lock_get_num_locks(struct device_node *dn);
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
const struct hwspinlock_ops *ops, int base_id, int num_locks,
int num_reserved_locks);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote: Hi Rob, On 04/30/2014 07:34 PM, Suman Anna wrote: The property 'hwlock-reserved-locks' will be used to represent the number of locks to be reserved for clients that would need to request/operate on specific locks. A new OF helper function, of_hwspin_lock_get_num_reserved_locks(), is added to minimize duplication in different platform implementations. The function will return a value of 0 if the property is not defined, so as to support a default behavior of marking all locks as unused and open for anonymous allocations. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/hwlock.txt | 3 +++ drivers/hwspinlock/hwspinlock_core.c | 25 ++ include/linux/hwspinlock.h | 1 + 3 files changed, 29 insertions(+) diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt index d538a9b..88d16d2 100644 --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -18,6 +18,9 @@ Common properties: property is needed on hwlock devices, where the number of supported locks within a hwlock device cannot be read from a register. +- hwlock-reserved-locks: Number of locks to reserve for clients requiring + specific locks. This value cannot exceed the value of + hwlock-num-locks. Any suggestions here on the approach? This property falls into a gray area as well, as the current approach is somewhat limiting (it doesn't support sparse reserved locks, and expects them at the beginning of the lock range). Is it possible to implement a pinctrl-like hogging approach, whereby the specific locks that need to be reserved are consumed by the controller itself? Josh -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [v2 Patch 2/6] ARM: TI: Describe the ti reset DT entries
* Dan Murphy dmur...@ti.com [140505 13:10]:
+
+Required parent properties:
+- compatible : Should be one of,
+ ti,omap4-prm for OMAP4 PRM instances
+ ti,omap5-prm for OMAP5 PRM instances
+ ti,dra7-prm for DRA7xx PRM instances
+ ti,am4-prcm for AM43xx PRCM instances
+ ti,am3-prcm for AM33xx PRCM instances
+
+Required child reset property:
+- compatible : Should be
+ resets for All TI SoCs
+
+example:
+ prm: prm@4ae06000 {
+ compatible = ti,omap5-prm;
+ reg = 0x4ae06000 0x3000;
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
+ };
The reg entries you have in the example below has different format
compared to this?
+Reset node declaration
+==
+The reset node is declared in a parent child relationship. The main parent
+is the PRCM module which contains the base address. The first child within
+the reset parent declares the target modules reset name. This is followed by
+the control and status offsets.
+
+Within the first reset child node is a secondary child node which declares
the
+reset signal of interest. Under this node the control and status bits
+are declared. These bits declare the bit mask for the target reset.
+
+
+Required properties:
+reg - This is the register offset from the PRCM parent.
+ This must be declared as:
+
+ reg = control register offset,
+ status register offset;
+
+control-bit - This is the bit within the register which controls the reset
+ of the target module. This is declared as a bit mask for the register.
+status-bit - This is the bit within the register which contains the status of
+ the reset of the target module.
+ This is declared as a bit mask for the register.
+
+example:
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
Shouldn't this be start and size instead of start and end here?
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+};
Are the control-bit and status-bit always the same? If so, you can
keep that knowlede private to the the driver.
And maybe you can have the bit offset in a reg property here to
avoid adding any custom properties? Something like:
dsp_reset: reset@1 {
reg = 1;
};
If reg is not suitable for that, it seems that some generic property
to describe the bit offset is needed by quite a few drivers
anyways, for things like clocks and regulators.
+Client Node Declaration
+==
+This is the consumer of the parent node to declare what resets this
+particular module is interested in.
+
+example:
+ src: src@55082000 {
+ resets = reset_src phandle;
+ reset-names = reset_name;
+ };
+
+Required Properties:
+reset_src - This is the parent DT entry for the reset controller
+phandle - This is the phandle of the specific reset to be used by the clien
+ driver.
+reset-names - This is the reset name of module that the device driver
+ needs to be able to reset. This value must correspond to a value within
+ the reset controller array.
+
+example:
+resets = prm_resets dsp_mmu_reset;
+reset-names = dsp_mmu_reset;
This part looks OK to me, not sure if we need the reset-names property
if we have one already why not.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] ARM: dts: sbc-t54: add support for sbc-t54 with cm-t54
* Dmitry Lifshitz lifsh...@compulab.co.il [140428 04:43]: Add support for CompuLab CM-T54 CoM and SBC-T54 board: http://compulab.co.il/products/computer-on-modules/cm-t54/ http://compulab.co.il/products/sbcs/sbc-t54/ SBC-T54 is a single board computer based on OMAP5432 CPU. It is implemented with a CM-T54 CoM providing most of the functions, and SB-T54 carrier board providing connectors and several additional functions. Changes from V1: * Used OMAP5_CORE_IOPAD macros for pimnux settings * Added CD and WP support for SD/MMC card on SB-T54 * Platform quirk for deasserting PDN and RST GPIOs of WiFi chip replaced by appropriate regulators in DT. Thanks applying into omap-for-v3.16/dt. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 00/14] OMAP SSI driver / N900 modem support
On Mon, May 05, 2014 at 12:31:30PM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@kernel.org [140328 17:36]: Please send feedback (e.g. Tested-By or Reviewed-By :)), so that I can send a pull request for 3.16. You can either apply this patchset or use the n900-modem-support branch available on [1]. Sebastian, can you please do a separate pull request for the .dts changes for me once the driver changes are pulled? Otherwise we will be creating pointless merge conflicts. That was my intention from the beginning. I only added those patches here to make reviewing the other patches easier. I'm still missing a reviewed by for the most important patches (ssi driver, modem protocol driver), though. Can somebody at least test the patches and provide a Tested-By? -- Sebastian signature.asc Description: Digital signature
Re: [PATCHv3 1/5] Input: add common DT binding for touchscreens
On Mon, May 05, 2014 at 12:51:39PM -0700, Dmitry Torokhov wrote: On Mon, May 05, 2014 at 12:41:26PM -0700, Tony Lindgren wrote: * Sebastian Reichel s...@kernel.org [140425 16:56]: Add common DT binding documentation for touchscreen devices and implement input_parse_touchscreen_of_params, which parses the common properties and configures the input device accordingly. The method currently does not interpret the axis inversion properties, since there is no matching flag in the generic linux input device. Signed-off-by: Sebastian Reichel s...@kernel.org --- .../bindings/input/touchscreen/touchscreen.txt | 27 + drivers/input/input.c | 34 ++ include/linux/input.h | 8 + 3 files changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt new file mode 100644 index 000..d8e0616 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt @@ -0,0 +1,27 @@ +General Touchscreen Properties: + +Optional properties for Touchscreens: + - touchscreen-size-x: horizontal resolution of touchscreen + (in pixels) + - touchscreen-size-y: vertical resolution of touchscreen + (in pixels) + - touchscreen-max-pressure : maximum reported pressure (arbitrary range + dependent on the controller) + - touchscreen-fuzz-x: horizontal noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-y: vertical noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-pressure : pressure noise value of the absolute input + device (arbitrary range dependent on the + controller) Fuzz seems like linux-specific property, not generic one. I don't know about the term fuzz, but the idea is pretty generic IMHO. It's similar to debouncing switches/buttons. + - touchscreen-inverted-x: X axis is inverted (boolean) + - touchscreen-inverted-y: Y axis is inverted (boolean) We probably also need something to swap x and y depending on the display orientation in addition to the touchscreen-inverted-x and y. Just swapping x and y is not enough depending if we rotate by 270 degrees instead of 90 degrees. Naturally that part can be added later. So far we've been relying on upper layers (such as tslib) to perform such transformations rather than re-implementing it in every driver. Are we saying that we need to implement this in input core? I would appreciate to add this later to move on with this patchset. Having the N900's touchscreen working via DT in 3.16 would be nice now that the display is working :) -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro
Hi, Sorry for dropping the ball on this one, got distracted with various other fixes for a while. * Joachim Eastwood manab...@gmail.com [140421 09:16]: On 21 April 2014 18:12, Joachim Eastwood manab...@gmail.com wrote: On 21 April 2014 17:35, Tony Lindgren t...@atomide.com wrote: * Joachim Eastwood manab...@gmail.com [140419 09:25]: On 19 April 2014 18:14, Joachim Eastwood manab...@gmail.com wrote: This was introduced in 43a348ea53eb5fd79 but hasn't caused any harm since it don't have any users yet. Or maybe I am confused about this macro. Tony which offset from the OMAP4 TRM should be used? Under section 18.6.8 there are is a column with address offset. Is this the number you want in the macro? Oh I see, the offsets in the TRM in this case are from the base of the wkup module padconf base instead of listing the physical address for the register. Ideally the value would be what the documentation lists in the Table 18-9. Device Wake-Up Control Module Pad Configuration Register Fields with 2 added to it for the upper registers as we're using 16-bit register address. In any case something that's relatively easy to verify against the documentation. But that seems to vary between the physical address and the offset, so we need to specify some mask there. Something like below (untested) should do the trick as long as we never have padconf reg areas larger than 0xfff. We may want to allow defining a custom mask for the macro if needed depending how the documentation is defining the mux tables for. --- a/include/dt-bindings/pinctrl/omap.h +++ b/include/dt-bindings/pinctrl/omap.h @@ -51,9 +51,9 @@ /* * Macros to allow using the absolute physical address instead of the - * padconf registers instead of the offset from padconf base. + * padconf register offset from padconf register base. */ -#define OMAP_IOPAD_OFFSET(pa, offset) (((pa) 0x) - (offset)) +#define OMAP_IOPAD_OFFSET(pa, offset) (((pa) 0xfff) - ((offset) 0xfff)) #define OMAP2420_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0030) (val) #define OMAP2430_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2030) (val) This give the same result as my patch so it's okay for me. Checked the resulting dtb's and they are equivalent. Your patch will also have an effect on some of the others macros but I assume that is okey. Yeah looks like the above won't work as the padconf value can easily be larger than the 0xfff masked offset.. For example OMAP3_CORE1_IOPAD at 0x48002030 would become 0x030 and the value for it can be up to 0x238. And we really want the macros to behave the same way for everything rather than obfuscate the calculation even further. I guess we could add few new macros, but looks like am335x is using yet another way of documenting these so it may be endless patching. For reference my var-som-om44.dtsi now looks like this: http://slexy.org/raw/s213OvSZfF OK sorry just noticed you're using it already while was about to apply your patches. Care to update that series again to not use the macro, or by adding the offsets? Will this be sent as a fix for 3.15? No since it won't work properly :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Support for Variscite OM44 modules and boards
* Joachim Eastwood manab...@gmail.com [140501 12:08]: Hello, This patch set adds support for Variscite OM44 series of system on modules and boards. There weren't many comments on v1 of this patch set so I hope this can make it into 3.16. Changes since v2: * Use OMAP IOPAD macros Patch 1: Add support for the SoM itself and the reference carrier board. Together these make the VAR-STK-OM44 dev kit. Patch 2: Add support for VAR-DVK-OM44 which is just the STK with a LCD display. Patch 3: Nodes for WLAN/BT support. Patch 4: Add quirks so that WLAN can be used. Still waiting for proper DT bindings. Since this patch set now uses the IOPAD macros a fix from Tony is need. See: https://patchwork.kernel.org/patch/4025421/ Just noted that the macro won't work while was about to apply these, sorry. So we're back to either using the existing OMAP4_WKUP_IOPAD or raw offset from the padconf area unless you have some great macro ideas. Note that patch 1 relies upon a patch from Tomi Valkeinen add hpd-gpio (hotplug detect) to the hdmi-connector. See: http://marc.info/?l=linux-omapm=139771947508021w=2 Patch 2 also relies upon a patch from Tomi that adds DT support to panel-dpi. See: http://marc.info/?l=devicetreem=139030201815380w=2 Maybe also leave out the DSS changes until Tomi has confirmed those? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Redo THUMB mode switch on secondary CPU
* Joel Fernandes jo...@ti.com [140429 19:54]: Here's a redo of the patch [1] that effectively does the same thing but is the right way to do things by using ENDPROC instead. The firmware correctly switches to THUMB before entry. The patch applies ontop of the earlier patch [1]. [1] https://lkml.org/lkml/2014/4/22/1044 Suggested-by: Dave Martin dave.mar...@arm.com Cc: Dave Martin dave.mar...@arm.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Nishanth Menon n...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Joel Fernandes jo...@ti.com --- Tony, the earlier patch went into your fixes, and can remain. This patch is just a simple redo of the same and can go in for v3.16, no problem. Thanks. OK thanks, applying into omap-for-v3.16/fixes-not-urgent. Tony arch/arm/mach-omap2/omap-headsmp.S |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S index 1809dce..bf36f26 100644 --- a/arch/arm/mach-omap2/omap-headsmp.S +++ b/arch/arm/mach-omap2/omap-headsmp.S @@ -31,10 +31,6 @@ * register AuxCoreBoot0. */ ENTRY(omap5_secondary_startup) -.arm -THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode. -THUMB( bx r9 ) @ If this is a Thumb-2 kernel, -THUMB( .thumb ) @ switch to Thumb now. wait:ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 ldr r0, [r2] mov r0, r0, lsr #5 @@ -43,7 +39,7 @@ wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 cmp r0, r4 bne wait b secondary_startup -END(omap5_secondary_startup) +ENDPROC(omap5_secondary_startup) /* * OMAP4 specific entry point for secondary CPU to jump from ROM * code. This routine also provides a holding flag into which -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: free use_gptimer_clksrc variable after boot
* Oussama Ghorbel ghor...@pivasoftware.com [140414 09:50]: The variable use_gptimer_clksrc is only used by two __init functions, So we can freely free it after boot. Signed-off-by: Oussama Ghorbel ghor...@pivasoftware.com Thanks applying into omap-for-v3.16/fixes-not-urgent. Tony --- arch/arm/mach-omap2/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 74044aa..d4a6abd 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -361,7 +361,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id, /* Clocksource code */ static struct omap_dm_timer clksrc; -static bool use_gptimer_clksrc; +static bool use_gptimer_clksrc __initdata; /* * clocksource -- 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] ARM: dts: am335x-boneblack: remove use of ti,vcc-aux-disable-is-sleep
* Johan Hovold jhov...@gmail.com [140425 06:37]:
Remove use of property ti,vcc-aux-disable-is-sleep, which does not
exist.
Signed-off-by: Johan Hovold jhov...@gmail.com
Thanks applying into omap-for-v3.16/fixes-not-urgent.
Tony
---
arch/arm/boot/dts/am335x-boneblack.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad95a5cf..305975d3f531 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -26,7 +26,6 @@
pinctrl-0 = emmc_pins;
bus-width = 8;
status = okay;
- ti,vcc-aux-disable-is-sleep;
};
am33xx_pinmux {
--
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 0/5] irqchip/dra7: crossbar bug fixes
* Sricharan R r.sricha...@ti.com [140505 07:20]: These are fixes for the crossbar to handle two interrupts getting mapped twice to same crossbar and to skip some interrupts being used due to hardware bugs. Nishanth Menon (5): irqchip: crossbar: dont use '0' to mark reserved interrupts irqchip: crossbar: check for premapped crossbar before allocating irqchip: crossbar: Skip some irqs from getting mapped to crossbar irqchip: crossbar: Initialise the crossbar with a safe value irqchip: crossbar: Change allocation logic by reversing search for free irqs drivers/irqchip/irq-crossbar.c | 82 1 file changed, 74 insertions(+), 8 deletions(-) Thanks applying all into omap-for-v3.16/crossbar. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
Hi, On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140420 22:16]: Hi, On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote: * Archit Taneja arc...@ti.com [140416 06:20]: Add DT node for the ctrl-core sub module of the DRA7 control module. We map the CTRL_MODULE_CORE address region up to 0x4a002d60, this region contains register fields which configure clocks. The remainder of the registers are related to pad configurations or cross-bar configurations, and therefore aren't mapped. Can you please check if this can just use the existing regmap syscon mapping: syscon = dra7_ctrl_general; See how the drivers/regulator/pbias-regulator.c is using the syscon to initialize a regulator and then omap_hsmmc.c just does the standard regulator calls. The thing is that this bit needs to be set before the the DSS hwmods are reset, and that happens very early. If we don't do this, DSS won't reset properly, and not get back to an idle state. I am not sure where I can configure the syscon register early enough that it happens before the hwmods are reset. With a syscon mapping, I guess we would access the register when the DSS driver is probed. But that's too late for us. Ideally, it would be much better to have a syscon mapping. Do you have any suggestions how this can be achieved very early in boot? It's best to move the reset and initialization of DSS happen later. I believe we already are resetting only some of the hwmods early on. I looked at this in some more detail. With the current hwmod flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP, it's just the reset part(ocp reset/custom reset and sysc register) or the disable part that is skipped. hwmod still tries to enable the IP. This again results in the same issue. One thing which wasn't clear was that why do we enable a hwmod in the first place, if we know that we are going to skip reset? 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 v4 0/5] ARM: DRA7: Add support for DRA72x devices
On Tuesday 29 April 2014 04:35 PM, Rajendra Nayak wrote: changes in v4: -1- used full SoC names in compatibles eg ti,dra742 and ti,dra722 -2- Created a seperate patch for replacing __initdata with __initconst changes in v3: Removed wildcards from compatible strings and duplicates from .dt_compat strings as suggested by Arnd DRA72x devices are single core Cortex A15 devices belonging to the DRA7 family (Similar to the DRA74x devices which are dual core Cortex A15 based) The patches (based off 3.15-rc3) add minimal DT/kernel modifications to add boot support on DRA722 device reusing all the kernel data for DRA742 device. Tony, Can this series be pulled in for 3.16? Patch 2/5 and 4/5 are acked by Arnd. Patch 5/5 can be dropped since there are no users for soc_is_dra7**() at the moment. Rajendra Nayak (5): ARM: dts: dra7-evm: Remove the wrong and undocumented compatible ARM: dts: Add support for DRA72x family of devices ARM: OMAP2+: Replace all __initdata with __initconst for const init ARM: OMAP2+: Add machine entry for dra72x devices ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients .../devicetree/bindings/arm/omap/omap.txt | 12 -- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts |6 +-- arch/arm/boot/dts/dra7.dtsi| 27 arch/arm/boot/dts/dra72-evm.dts| 24 +++ arch/arm/boot/dts/dra72x.dtsi | 25 +++ arch/arm/boot/dts/dra74x.dtsi | 41 ++ arch/arm/mach-omap2/board-generic.c| 45 ++-- arch/arm/mach-omap2/soc.h |7 +++ 9 files changed, 142 insertions(+), 48 deletions(-) create mode 100644 arch/arm/boot/dts/dra72-evm.dts create mode 100644 arch/arm/boot/dts/dra72x.dtsi create mode 100644 arch/arm/boot/dts/dra74x.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
