Re: [PATCH 51/97] ARM: l2c: remove platforms/SoCs setting early BRESP
On Tue, Apr 29, 2014 at 10:17:01AM -0600, Stephen Warren wrote: On 04/28/2014 06:02 PM, Simon Horman wrote: On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote: Since we now automatically enable early BRESP in core L2C-310 code when we detect a Cortex-A9, we don't need platforms/SoCs to set this bit explicitly. Instead, they should seek to preserve the value of bit 30 in the auxiliary control register. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk I would prefer if this patch was broken out into individual patches for each board or SoC file and that they were then picked up by their respective platform maintainers. Likewise for patch 66/97. Although it is only for shmobile I would prefer it broken out. There are far too many dependencies in this series to break out the board file patches to be merged separately; it'd take either a whole bunch of kernel releases to merge it all that way, or a twisty maze of tiny topic branches cross-merged all over the place. Neither option is realistic. Understood, that seems reasonable to me. For the shmobile portions this patch and 66/97. Acked-by: Simon Horman horms+rene...@verge.net.au -- To unsubscribe from this list: send the line unsubscribe 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 06/23] ARM: OMAP: add OMAP5 DSI muxing
On 29/04/14 20:38, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140429 09:33]: On 29/04/14 19:19, Tomi Valkeinen wrote: On 29/04/14 18:05, Tony Lindgren wrote: omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it. That would be probably best set up the same way we have already set up for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can access it using regmap, see how drivers/regulator/pbias-regulator.c sets up the pbias regulator with regmap for MMC. Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong? I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver. Anything using the system control module registers should be a separate driver. And it should ideally be implemeting some Linux generic framework that the consumer driver can then use. That leaves out the need to export custom functions. Ok. I guess we don't have a PHY framework for displays though, so how about just a separate minimal driver under drivers/video/omap2 that uses the syscon? Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register is not in the DSI PHY block, but in the control module, and it is used to enable/disable the pins (for omap4/5) and to set pull up/down for the pins (only for omap4). Oddly, for omap5, there's also a normal padconfig register for the DSI pins, but not so for omap4. To me it looks like a pad config register. I don't know why there's a separate odd register for it and it's not using the normal padconfig system. I'd like to use the pinctrl framework for it, but the pinctrl-single cannot handle such a funny register. So, if Anything using the system control module registers should be a separate driver, then I guess I need to write a pinctrl driver for this single register? Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver. Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5? We do use different compatible strings for different major versions of the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could be used on some other SoC, with different control stuff. We could use separate compatible string for each SoC that uses DSS, but then we're really encoding the SoC version into the compatible string, not DSS version. Of course, if there will be a separate driver managing the CONTROL_DSIPHY register, then that one should use compatible string specific to the SoC, as it's not a DSS driver at all. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] ARM: dts: Add support for OMAP4 Variscite OM44 family
On 30/04/14 04:24, Joachim Eastwood wrote: Do you plan to push the patch that add hpd-gpios to the hdmi-connector for 3.16? (nodes for my board below) https://patchwork.kernel.org/patch/4006021/ Also in the patch set I am using your DT bindings for panel-dpi. See patch [2 of 4] for nodes. https://patchwork.kernel.org/patch/4047241/ Will this patch be upstream in 3.16? Yes, they are both planned to be in 3.16. The patches are still under work, though. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 3/7] phy: omap-usb2: Use generic clock names wkupclk and refclk
On 04/29/2014 07:16 PM, Felipe Balbi 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. If backward compatibility is not the real worry then we could avoid the synchronization/bisectability issue by squashing the dts changes with this patch. 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: [RFC 01/11] drivers: reset: TI: SoC reset controller support.
Hi Dan,
Am Dienstag, den 29.04.2014, 15:19 -0500 schrieb Dan Murphy:
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 | 58
drivers/reset/ti/reset-ti.c | 195
++
include/linux/reset_ti.h | 25 +
7 files changed, 289 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
create mode 100644 include/linux/reset_ti.h
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..6afdf37
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,58 @@
+/*
+ * 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/of_device.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 {
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u8 rstctrl_bit;
+ u8 rstst_bit;
You are only ever using these as (1 rstctrl_bit) and as
(1 rstst_bit). You could store the mask here directly,
like the regulator framework does.
+};
+
+/**
+ * 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.
+ *
trailing whitespace
+ */
+struct ti_reset_data {
+ struct ti_reset_reg_data *reg_data;
+ struct
Re: [PATCH] fbdev: omap2: Fix format string mismatch in display-sysfs.c
On 28/04/14 14:17, Jingoo Han wrote:
On Monday, April 28, 2014 7:54 PM, Masanari Iida wrote:
Fix two format string mismatch in display-sysfs.c
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/video/fbdev/omap2/dss/display-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c
b/drivers/video/fbdev/omap2/dss/display-
sysfs.c
index 5a2095a..5928bc9 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -184,7 +184,7 @@ static ssize_t display_rotate_show(struct device *dev,
if (!dssdev-driver-get_rotate)
return -ENOENT;
rotate = dssdev-driver-get_rotate(dssdev);
According to 'struct omap_dss_driver', get_rotate() returns 'u8'.
Then, how about changing the type of 'rotate' variable from 'int'
to 'u8' as below?
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -180,7 +180,7 @@ static ssize_t display_rotate_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
- int rotate;
+ u8 rotate;
if (!dssdev-driver-get_rotate)
return -ENOENT;
rotate = dssdev-driver-get_rotate(dssdev);
Best regards,
Jingoo Han
-return snprintf(buf, PAGE_SIZE, %u\n, rotate);
+return snprintf(buf, PAGE_SIZE, %d\n, rotate);
}
static ssize_t display_rotate_store(struct device *dev,
@@ -215,7 +215,7 @@ static ssize_t display_mirror_show(struct device *dev,
if (!dssdev-driver-get_mirror)
return -ENOENT;
mirror = dssdev-driver-get_mirror(dssdev);
-return snprintf(buf, PAGE_SIZE, %u\n, mirror);
+return snprintf(buf, PAGE_SIZE, %d\n, mirror);
}
And get_mirror returns a bool, not int, so I guess that could be fixed also.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: OMAP5: Redo THUMB mode switch on secondary CPU
On Tue, Apr 29, 2014 at 09:53:47PM -0500, Joel Fernandes wrote: 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 Looks OK to me. This also makes omap5 consistent with omap3/4 here. Reviewed-by: Dave Martin dave.mar...@arm.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. 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 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe 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.
Confirm your Donation of £2,000.000.00 Contact Kindly contact claims office via Email: neiltro...@qq.com-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: ti: clk-54xx: Set the rate for dpll_abe_m2x2_ck
In order to get correct clock dividers for AESS/ABE we need to set the dpll_abe_m2x2_ck rate to be double of dpll_abe_ck. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/clk/ti/clk-54xx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c index 08f3d1b915b3..5e183993e3ec 100644 --- a/drivers/clk/ti/clk-54xx.c +++ b/drivers/clk/ti/clk-54xx.c @@ -240,6 +240,12 @@ int __init omap5xxx_dt_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); + abe_dpll = clk_get_sys(NULL, dpll_abe_m2x2_ck); + if (!rc) + rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ * 2); + if (rc) + pr_err(%s: failed to configure ABE m2x2 DPLL!\n, __func__); + usb_dpll = clk_get_sys(NULL, dpll_usb_ck); rc = clk_set_rate(usb_dpll, OMAP5_DPLL_USB_DEFFREQ); if (rc) -- 1.9.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 1/2] ARM: DTS: omap54xx-clocks: remove the autoidle properties for clock nodes
In OMAP5 bit 8 in PRCM registers are not defined (Reserved) unlike their
counterpart in OMAP4.
It is better to not write to these bits.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 48 --
1 file changed, 48 deletions(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..d784ff5d3904 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -120,10 +120,8 @@
compatible = ti,divider-clock;
clocks = dpll_abe_x2_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x01f0;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
abe_24m_fclk: abe_24m_fclk {
@@ -164,10 +162,8 @@
compatible = ti,divider-clock;
clocks = dpll_abe_x2_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x01f4;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_ck: dpll_core_ck {
@@ -188,10 +184,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0150;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
c2c_fclk: c2c_fclk {
@@ -215,10 +209,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0138;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h12x2_ck: dpll_core_h12x2_ck {
@@ -226,10 +218,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x013c;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h13x2_ck: dpll_core_h13x2_ck {
@@ -237,10 +227,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0140;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h14x2_ck: dpll_core_h14x2_ck {
@@ -248,10 +236,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0144;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h22x2_ck: dpll_core_h22x2_ck {
@@ -259,10 +245,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0154;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h23x2_ck: dpll_core_h23x2_ck {
@@ -270,10 +254,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0158;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h24x2_ck: dpll_core_h24x2_ck {
@@ -281,10 +263,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x015c;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_m2_ck: dpll_core_m2_ck {
@@ -292,10 +272,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x0130;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_m3x2_ck: dpll_core_m3x2_ck {
@@ -303,10 +281,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x0134;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
iva_dpll_hs_clk_div: iva_dpll_hs_clk_div {
@@ -335,10 +311,8 @@
compatible = ti,divider-clock;
clocks = dpll_iva_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x01b8;
ti,index-starts-at-one;
-
[PATCH 2/2] ARM: DTS: omap54xx-clocks: Correct abe_iclk clock node
abe_iclk's parent is aess_fclk and not abe_clk.
Also correct the parameters for clock rate calculation as used for OMAP4
since in PRCM level there's no difference between the two platform
regarding to AESS/ABE clocking.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d784ff5d3904..86fc507a0567 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -143,10 +143,11 @@
abe_iclk: abe_iclk {
#clock-cells = 0;
- compatible = fixed-factor-clock;
- clocks = abe_clk;
- clock-mult = 1;
- clock-div = 2;
+ compatible = ti,divider-clock;
+ clocks = aess_fclk;
+ ti,bit-shift = 24;
+ reg = 0x0528;
+ ti,dividers = 2, 1;
};
abe_lp_clk_div: abe_lp_clk_div {
--
1.9.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 1/2] ARM: omap5: hwmod_data: Update McPDM hwmod's flags
Add HWMOD_SWSUP_SIDLE to flags.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 892317294fdc..e829664e6a6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -895,7 +895,7 @@ static struct omap_hwmod omap54xx_mcpdm_hwmod = {
* current exception.
*/
- .flags = HWMOD_EXT_OPT_MAIN_CLK,
+ .flags = HWMOD_EXT_OPT_MAIN_CLK | HWMOD_SWSUP_SIDLE,
.main_clk = pad_clks_ck,
.prcm = {
.omap4 = {
--
1.9.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 2/2] ARM: omap5: hwmod_data: Add AESS related data
Add the needed hwmod entries which is needed for AESS (Audio Engine
SubSystem) and ABE.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e829664e6a6c..3e20c025b5a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -146,6 +146,7 @@ static struct omap_hwmod omap54xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP54XX_CM_ABE_L4_ABE_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
},
},
@@ -211,6 +212,42 @@ static struct omap_hwmod omap54xx_mpu_private_hwmod = {
};
/*
+ * 'aess' class
+ * audio engine sub system
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_aess_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_aess_hwmod_class = {
+ .name = aess,
+ .sysc = omap54xx_aess_sysc,
+ .enable_preprogram = omap_hwmod_aess_preprogram,
+};
+
+/* aess */
+static struct omap_hwmod omap54xx_aess_hwmod = {
+ .name = aess,
+ .class = omap54xx_aess_hwmod_class,
+ .clkdm_name = abe_clkdm,
+ .main_clk = aess_fclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_ABE_AESS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'counter' class
* 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
*/
@@ -1892,6 +1929,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* aess - l4_abe */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_aess__l4_abe = {
+ .master = omap54xx_aess_hwmod,
+ .slave = omap54xx_l4_abe_hwmod,
+ .clk= abe_iclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 - l4_abe */
static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_abe = {
.master = omap54xx_l3_main_1_hwmod,
@@ -1966,6 +2011,22 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__dma_system = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_abe - aess */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess = {
+ .master = omap54xx_l4_abe_hwmod,
+ .slave = omap54xx_aess_hwmod,
+ .clk= abe_iclk,
+ .user = OCP_USER_MPU,
+};
+
+/* l4_abe - aess (dma) */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess_dma = {
+ .master = omap54xx_l4_abe_hwmod,
+ .slave = omap54xx_aess_hwmod,
+ .clk= abe_iclk,
+ .user = OCP_USER_SDMA,
+};
+
/* l4_abe - dmic */
static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = {
.master = omap54xx_l4_abe_hwmod,
@@ -2417,6 +2478,9 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l3_main_1__l3_main_3,
omap54xx_l3_main_2__l3_main_3,
omap54xx_l4_cfg__l3_main_3,
+ omap54xx_l4_abe__aess,
+ omap54xx_l4_abe__aess_dma,
+ omap54xx_aess__l4_abe,
omap54xx_l3_main_1__l4_abe,
omap54xx_mpu__l4_abe,
omap54xx_l3_main_1__l4_cfg,
--
1.9.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 v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
On Mon, Apr 28, 2014 at 9:40 AM, Andreas Fenkart afenk...@gmail.com wrote:
@@ -2201,11 +2346,16 @@ static int omap_hsmmc_suspend(struct device *dev)
pm_runtime_get_sync(host-dev);
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER)) {
- omap_hsmmc_disable_irq(host);
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
}
+ if (host-wake_irq !(host-mmc-pm_flags MMC_PM_WAKE_SDIO_IRQ))
+ disable_irq(host-wake_irq);
+
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
@@ -2231,6 +2381,9 @@ static int omap_hsmmc_resume(struct device *dev)
omap_hsmmc_protect_card(host);
+ if (host-wake_irq !(host-mmc-pm_flags MMC_PM_WAKE_SDIO_IRQ))
+ enable_irq(host-wake_irq);
+
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
return 0;
Maybe I misunderstand something here but shouldn't
disable_irq/enable_irq be swapped here?
regards
Andreas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: DTS: omap54xx-clocks: remove the autoidle properties for clock nodes
On 04/30/2014 02:41 PM, Peter Ujfalusi wrote:
In OMAP5 bit 8 in PRCM registers are not defined (Reserved) unlike their
counterpart in OMAP4.
It is better to not write to these bits.
Yeah, looks like this bug was copied over from the legacy clock data.
Acked-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 48 --
1 file changed, 48 deletions(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..d784ff5d3904 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -120,10 +120,8 @@
compatible = ti,divider-clock;
clocks = dpll_abe_x2_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x01f0;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
abe_24m_fclk: abe_24m_fclk {
@@ -164,10 +162,8 @@
compatible = ti,divider-clock;
clocks = dpll_abe_x2_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x01f4;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_ck: dpll_core_ck {
@@ -188,10 +184,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0150;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
c2c_fclk: c2c_fclk {
@@ -215,10 +209,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0138;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h12x2_ck: dpll_core_h12x2_ck {
@@ -226,10 +218,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x013c;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h13x2_ck: dpll_core_h13x2_ck {
@@ -237,10 +227,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0140;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h14x2_ck: dpll_core_h14x2_ck {
@@ -248,10 +236,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0144;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h22x2_ck: dpll_core_h22x2_ck {
@@ -259,10 +245,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0154;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h23x2_ck: dpll_core_h23x2_ck {
@@ -270,10 +254,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x0158;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_h24x2_ck: dpll_core_h24x2_ck {
@@ -281,10 +263,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 63;
- ti,autoidle-shift = 8;
reg = 0x015c;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_m2_ck: dpll_core_m2_ck {
@@ -292,10 +272,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x0130;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
dpll_core_m3x2_ck: dpll_core_m3x2_ck {
@@ -303,10 +281,8 @@
compatible = ti,divider-clock;
clocks = dpll_core_x2_ck;
ti,max-div = 31;
- ti,autoidle-shift = 8;
reg = 0x0134;
ti,index-starts-at-one;
- ti,invert-autoidle-bit;
};
iva_dpll_hs_clk_div: iva_dpll_hs_clk_div {
@@ -335,10 +311,8 @@
compatible = ti,divider-clock;
clocks = dpll_iva_x2_ck;
Re: [PATCH 2/2] ARM: DTS: omap54xx-clocks: Correct abe_iclk clock node
On 04/30/2014 02:41 PM, Peter Ujfalusi wrote:
abe_iclk's parent is aess_fclk and not abe_clk.
Also correct the parameters for clock rate calculation as used for OMAP4
since in PRCM level there's no difference between the two platform
regarding to AESS/ABE clocking.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d784ff5d3904..86fc507a0567 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -143,10 +143,11 @@
abe_iclk: abe_iclk {
#clock-cells = 0;
- compatible = fixed-factor-clock;
- clocks = abe_clk;
- clock-mult = 1;
- clock-div = 2;
+ compatible = ti,divider-clock;
+ clocks = aess_fclk;
+ ti,bit-shift = 24;
+ reg = 0x0528;
+ ti,dividers = 2, 1;
};
abe_lp_clk_div: abe_lp_clk_div {
--
To unsubscribe from this list: send the line unsubscribe 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] ARM: dts: AM43xx: Touchscreen support
Hi Benoit Tony, These patches add I2C touch screen support for am43x-epos-evm and am437x-gp-evm. Relevant driver side changes are here. http://thread.gmane.org/gmane.linux.kernel.input/35803 Please queue this for -next (3.16). Thanks. cheers, -roger --- Roger Quadros (1): ARM: dts: am43x-epos-evm: Correct Touch controller info Sekhar Nori (1): ARM: dts: AM437x: Add touchscreen support for GP EVM arch/arm/boot/dts/am437x-gp-evm.dts | 20 arch/arm/boot/dts/am43x-epos-evm.dts | 12 ++-- 2 files changed, 30 insertions(+), 2 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 1/2] ARM: dts: am43x-epos-evm: Correct Touch controller info
Fixup Y resolution and add default pin state. Also update
the compatible id.
CC: Benoit Cousson bcous...@baylibre.com
CC: Tony Lindgren t...@atomide.com
CC: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..3a067e6 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -138,6 +138,12 @@
0x160 (PIN_INPUT | MUX_MODE7) /*
spi0_cs1.gpio0_6 */
;
};
+
+ pixcir_ts_pins: pixcir_ts_pins {
+ pinctrl-single,pins =
+ 0x44 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_a1.gpio1_17 */
+ ;
+ };
};
matrix_keypad: matrix_keypad@0 {
@@ -226,7 +232,9 @@
};
pixcir_ts@5c {
- compatible = pixcir,pixcir_ts;
+ compatible = pixcir,pixcir_tangoc;
+ pinctrl-names = default;
+ pinctrl-0 = pixcir_ts_pins;
reg = 0x5c;
interrupt-parent = gpio1;
interrupts = 17 0;
@@ -234,7 +242,7 @@
attb-gpio = gpio1 17 GPIO_ACTIVE_HIGH;
x-size = 1024;
- y-size = 768;
+ y-size = 600;
};
};
--
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 2/2] ARM: dts: AM437x: Add touchscreen support for GP EVM
From: Sekhar Nori nsek...@ti.com
Add touchscreen support for AM437x GP EVM using pixcir
touchscreen controller.
CC: Benoit Cousson bcous...@baylibre.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Acked-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..bc9889f 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,12 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ pixcir_ts_pins: pixcir_ts_pins {
+ pinctrl-single,pins =
+ 0x264 (PIN_INPUT_PULLUP | MUX_MODE7) /*
spi2_d0.gpio3_22 */
+ ;
+ };
};
i2c0 {
@@ -93,6 +99,20 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
+
+ pixcir_ts@5c {
+ compatible = pixcir,pixcir_tangoc;
+ pinctrl-names = default;
+ pinctrl-0 = pixcir_ts_pins;
+ reg = 0x5c;
+ interrupt-parent = gpio3;
+ interrupts = 22 0;
+
+ attb-gpio = gpio3 22 GPIO_ACTIVE_HIGH;
+
+ x-size = 1024;
+ y-size = 600;
+ };
};
epwmss0 {
--
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 3/7] phy: omap-usb2: Use generic clock names wkupclk and refclk
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 + + 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. 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 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
Hi Mike/Paul,
(sorry for top-posting)
any comments here, what do we do ? Do we split this patch ? Use v1 ? Use
v2 ?
cheers
On Wed, Mar 05, 2014 at 03:50:33PM +0200, Tomi Valkeinen wrote:
On 20/02/14 21:30, Paul Walmsley wrote:
On Wed, 19 Feb 2014, Paul Walmsley wrote:
On Fri, 17 Jan 2014, Tomi Valkeinen wrote:
This patch adds a simple method of rounding: during the iteration, the
code keeps track of the closest rate match. If no exact match is found,
the closest is returned.
So that's one possible rounding policy; maybe it works fine for a display
interface PLL, at least for some values of closest rate. But another
might be only allow a selection from a set of pre-determined rates
characterized by the silicon validation team. Or another rounding
function might need to select a more distant rate that minimizes jitter,
EMI, or power consumption.
Thought about this some more. Do you only need this for the DSS PLL, or
do you need it for one of the core OMAP PLLs?
If the former, then how about modifying your patch to create a separate
round_rate function that's only used for the DSS PLL that implements the
behavior that you want?
That would eliminate any risk of impacting other users on the system. And
would also allow this change to get into the codebase much faster, since
there's no need for clk API changes, etc.
How about this one:
From f5a78303411e9192899a6a681acac37f09f4cc3b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Wed, 15 Jan 2014 11:45:07 +0200
Subject: [PATCH] ARM: OMAP2+: fix dpll round_rate() to actually round
omap2_dpll_round_rate() doesn't actually round the given rate, even if
the name and the description so hints. Instead it only tries to find an
exact rate match, or if that fails, return ~0 as an error.
What this basically means is that the user of the clock needs to know
what rates the dpll can support, which obviously isn't right.
This patch adds a simple method of rounding: during the iteration, the
code keeps track of the closest rate match. If no exact match is found,
the closest is returned.
However, as it is unclear whether current drivers rely on the current
behavior, the rounding functionality not enabled by default, but by
setting DPLL_USE_ROUNDED_RATE for the DPLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c | 23 ++-
drivers/clk/ti/dpll.c | 3 +++
include/linux/clk/ti.h | 1 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 2649ce445845..fed7538e1eed 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -298,6 +298,8 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
struct dpll_data *dd;
unsigned long ref_rate;
const char *clk_name;
+ unsigned long diff, closest_diff = ~0;
+ bool use_rounding = clk-flags DPLL_USE_ROUNDED_RATE;
if (!clk || !clk-dpll_data)
return ~0;
@@ -345,20 +347,31 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
pr_debug(clock: %s: m = %d: n = %d: new_rate = %lu\n,
clk_name, m, n, new_rate);
- if (target_rate == new_rate) {
+ diff = max(target_rate, new_rate) - min(target_rate, new_rate);
+
+ if ((use_rounding diff closest_diff) ||
+ (!use_rounding diff == 0)) {
+ closest_diff = diff;
+
dd-last_rounded_m = m;
dd-last_rounded_n = n;
- dd-last_rounded_rate = target_rate;
- break;
+ dd-last_rounded_rate = new_rate;
+
+ if (diff == 0)
+ break;
}
}
- if (target_rate != new_rate) {
+ if (closest_diff == ~0) {
pr_debug(clock: %s: cannot round to rate %lu\n,
clk_name, target_rate);
return ~0;
}
- return target_rate;
+ if (closest_diff 0)
+ pr_debug(clock: %s: rounded rate %lu to %lu\n,
+ clk_name, target_rate, dd-last_rounded_rate);
+
+ return dd-last_rounded_rate;
}
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a44f97d..c5858c46b58c 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -265,6 +265,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dpll_mode)
dd-modes = dpll_mode;
+ if (of_property_read_bool(node, ti,round-rate))
+ clk_hw-flags |= DPLL_USE_ROUNDED_RATE;
+
ti_clk_register_dpll(clk_hw-hw, node);
return;
diff --git
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
Tomi,
On Wed, Mar 5, 2014 at 7:50 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
[...]
From f5a78303411e9192899a6a681acac37f09f4cc3b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Wed, 15 Jan 2014 11:45:07 +0200
Subject: [PATCH] ARM: OMAP2+: fix dpll round_rate() to actually round
omap2_dpll_round_rate() doesn't actually round the given rate, even if
the name and the description so hints. Instead it only tries to find an
exact rate match, or if that fails, return ~0 as an error.
What this basically means is that the user of the clock needs to know
what rates the dpll can support, which obviously isn't right.
This patch adds a simple method of rounding: during the iteration, the
code keeps track of the closest rate match. If no exact match is found,
the closest is returned.
However, as it is unclear whether current drivers rely on the current
behavior, the rounding functionality not enabled by default, but by
setting DPLL_USE_ROUNDED_RATE for the DPLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clkt_dpll.c | 23 ++-
drivers/clk/ti/dpll.c | 3 +++
include/linux/clk/ti.h | 1 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 2649ce445845..fed7538e1eed 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -298,6 +298,8 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
struct dpll_data *dd;
unsigned long ref_rate;
const char *clk_name;
+ unsigned long diff, closest_diff = ~0;
+ bool use_rounding = clk-flags DPLL_USE_ROUNDED_RATE;
if (!clk || !clk-dpll_data)
return ~0;
@@ -345,20 +347,31 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned
long target_rate,
pr_debug(clock: %s: m = %d: n = %d: new_rate = %lu\n,
clk_name, m, n, new_rate);
- if (target_rate == new_rate) {
+ diff = max(target_rate, new_rate) - min(target_rate,
new_rate);
+
+ if ((use_rounding diff closest_diff) ||
+ (!use_rounding diff == 0)) {
+ closest_diff = diff;
+
dd-last_rounded_m = m;
dd-last_rounded_n = n;
- dd-last_rounded_rate = target_rate;
- break;
+ dd-last_rounded_rate = new_rate;
+
+ if (diff == 0)
+ break;
}
}
- if (target_rate != new_rate) {
+ if (closest_diff == ~0) {
pr_debug(clock: %s: cannot round to rate %lu\n,
clk_name, target_rate);
return ~0;
}
- return target_rate;
+ if (closest_diff 0)
+ pr_debug(clock: %s: rounded rate %lu to %lu\n,
+clk_name, target_rate, dd-last_rounded_rate);
+
+ return dd-last_rounded_rate;
}
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a44f97d..c5858c46b58c 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -265,6 +265,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dpll_mode)
dd-modes = dpll_mode;
+ if (of_property_read_bool(node, ti,round-rate))
+ clk_hw-flags |= DPLL_USE_ROUNDED_RATE;
binding is missing here - Further, I'd suggest this be two patches:
a) introducing ti,round-rate (ti/dpll.c, clk/ti.h)
b) use it in clkt_dpll.c
+
ti_clk_register_dpll(clk_hw-hw, node);
return;
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 092b64168d7f..c9ed8b6b8513 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -155,6 +155,7 @@ struct clk_hw_omap {
#define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2 (1 5)
#define MEMMAP_ADDRESSING (1 6)
+#define DPLL_USE_ROUNDED_RATE (1 7)/* dpll's round_rate()
returns rounded rate */
/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
#define DPLL_LOW_POWER_STOP0x1
--
1.8.3.2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe 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] usb: dwc3: debugfs: add snapshot to dump requests trbs events
Hi,
On Tue, Apr 29, 2014 at 11:10:42AM -0500, Felipe Balbi wrote:
Hi,
On Tue, Apr 29, 2014 at 05:21:42PM -0400, Zhuang Jin Can wrote:
On Mon, Apr 28, 2014 at 10:55:36AM -0500, Felipe Balbi wrote:
On Mon, Apr 28, 2014 at 04:49:23PM -0400, Zhuang Jin Can wrote:
Adds a debugfs file snapshot to dump dwc3 requests, trbs and events.
you need to explain what are you trying to provide to our users here.
What problem are you trying to solve ?
The interface enables users to easily peek into requests, trbs and
events to know the current transfer state of each request.
If an transfer is stuck, user can use the interface to check why it's
stuck (e.g. Is it because a gadget doesn't queued the request? Or it's
queued but it's not primed to the controller? Or It's primed to the
controller but the TRBs and events indicate the transfer never completes?).
User can immediately narrow down the issue without enabling verbose log or
reproduce the issue again. It's helpful when we need to deal with some
hard-to-reproduce bugs or timing sensitive bugs can't be reproduced with
verbose log enabled.
this should be part of the commit log in some shape or form.
Yes.
As ep0 requests are more complex than others. It's not included in this
patch.
For ep0, you could at least print the endpoint phase we are currently
in and if we have requests in flight or not.
Agree. Will add it in [PATCH v2].
tks
+ seq_puts(s, busy_slot--|\n);
+ seq_puts(s,\\\n);
+ }
+ if (i == (dep-free_slot DWC3_TRB_MASK)) {
+ seq_puts(s, free_slot--|\n);
+ seq_puts(s,\\\n);
+ }
+ seq_printf(s, trb[%02d](dma@0x%pad): %08x(bpl),
%08x(bph), %08x(size), %08x(ctrl)\n,
I'm not sure you need to print out the TRB address. bpl, bph, size and
ctrl are desired though.
printing out the TRB DMA address helps user to locate the start TRB of a
request. I admit that we can achive the same purose using the start_slot
of the request. I'll remove it in [PATCH v2].
thanks
+ i, dep-trb_pool_dma + i * sizeof(*trb),
+ trb-bpl, trb-bph, trb-size, trb-ctrl);
this will be pretty difficult to parse by a human. I would rather see
you creating one directory per TRB (and also one directory per
endpoint) which holds the details for that entity, so that it looks
like:
dwc3
|-- current_state (or perhaps a better name, but snapshot isn't very good
either)
Actually, it's hard to find a perfect name. current_state or snapshot
doesn't
make too much difference to me. If current_state makes more sense to you,
I
can change to use this name. Or let me know if you have a better suggestion.
the name is important as we will have to deal with it for the next 50
years. We also need to think about someone starting out on dwc3 5 years
from now or a QA engineer in whatever OEM trying to provide details of
the failure for the development team. It needs to be well thought out.
I don't have a better idea but snapshot gives me the idea that we will
end up with a copy of everything which we can revisit at any time and
that's not true. If we read this file twice there's no guarantee it'll
contain the same information.
Let's discuss the name later after I explain more about the motivation.
[Motivation]
The patch is inspired from echi-dbg.c debugfs. It contains four files
async, bandwidth, periodic and registers.
The registers functions as what regdump does in dwc3. And the patch
implements
a snapshot to do the similar things done by async and periodic.
Because a way to inspect the content of data structures (i.e. TRBs, Events)
interacting with the controller is really important for debugging,
especially for HW issues. It just simply provides you a interface to check
what's currently in TRBs and event buffers (and nothing more, no more
guarantees).
In EHCI, async and periodic also can't guarantee you the reliable data, as
you can't prevent the controller from writing the interacting data
structures (unless you stop it). It's developer's decision to how to analyze
the data. They're not perfect, but simple and helpful.
As far as I see, it's useful for below senarios:
1. Bugs can't be reproduced with VERBOSE_DEBUG, as printk introduces
timing effect. Some HW bugs are timing sensitive, even a single printk
will prevent you from reproducing the issue.
With snapshot, we can check the TRBs, events, requests to see the
final status to get more clues to triage an issue.
2. Some bugs are hard to reproduce, and can be seen once or
twice after many devices running for a long time. (e.g. MTBF runing with
ADB). And they most often uses the builds with debugfs available, ask
them to turn on VERBOSE_DEBUG and run the
Re: [PATCH] usb: dwc3: debugfs: add snapshot to dump requests trbs events
Hi,
On Thu, May 01, 2014 at 01:06:25AM -0400, Zhuang Jin Can wrote:
Hi,
On Tue, Apr 29, 2014 at 11:10:42AM -0500, Felipe Balbi wrote:
Hi,
On Tue, Apr 29, 2014 at 05:21:42PM -0400, Zhuang Jin Can wrote:
On Mon, Apr 28, 2014 at 10:55:36AM -0500, Felipe Balbi wrote:
On Mon, Apr 28, 2014 at 04:49:23PM -0400, Zhuang Jin Can wrote:
Adds a debugfs file snapshot to dump dwc3 requests, trbs and events.
you need to explain what are you trying to provide to our users here.
What problem are you trying to solve ?
The interface enables users to easily peek into requests, trbs and
events to know the current transfer state of each request.
If an transfer is stuck, user can use the interface to check why it's
stuck (e.g. Is it because a gadget doesn't queued the request? Or it's
queued but it's not primed to the controller? Or It's primed to the
controller but the TRBs and events indicate the transfer never
completes?).
User can immediately narrow down the issue without enabling verbose log or
reproduce the issue again. It's helpful when we need to deal with some
hard-to-reproduce bugs or timing sensitive bugs can't be reproduced with
verbose log enabled.
this should be part of the commit log in some shape or form.
Yes.
As ep0 requests are more complex than others. It's not included in
this
patch.
For ep0, you could at least print the endpoint phase we are currently
in and if we have requests in flight or not.
Agree. Will add it in [PATCH v2].
tks
+ seq_puts(s, busy_slot--|\n);
+ seq_puts(s,\\\n);
+ }
+ if (i == (dep-free_slot DWC3_TRB_MASK)) {
+ seq_puts(s, free_slot--|\n);
+ seq_puts(s,\\\n);
+ }
+ seq_printf(s, trb[%02d](dma@0x%pad): %08x(bpl),
%08x(bph), %08x(size), %08x(ctrl)\n,
I'm not sure you need to print out the TRB address. bpl, bph, size and
ctrl are desired though.
printing out the TRB DMA address helps user to locate the start TRB of a
request. I admit that we can achive the same purose using the start_slot
of the request. I'll remove it in [PATCH v2].
thanks
+ i, dep-trb_pool_dma + i * sizeof(*trb),
+ trb-bpl, trb-bph, trb-size, trb-ctrl);
this will be pretty difficult to parse by a human. I would rather see
you creating one directory per TRB (and also one directory per
endpoint) which holds the details for that entity, so that it looks
like:
dwc3
|-- current_state (or perhaps a better name, but snapshot isn't
very good either)
Actually, it's hard to find a perfect name. current_state or snapshot
doesn't
make too much difference to me. If current_state makes more sense to
you, I
can change to use this name. Or let me know if you have a better
suggestion.
the name is important as we will have to deal with it for the next 50
years. We also need to think about someone starting out on dwc3 5 years
from now or a QA engineer in whatever OEM trying to provide details of
the failure for the development team. It needs to be well thought out.
I don't have a better idea but snapshot gives me the idea that we will
end up with a copy of everything which we can revisit at any time and
that's not true. If we read this file twice there's no guarantee it'll
contain the same information.
Let's discuss the name later after I explain more about the motivation.
[Motivation]
The patch is inspired from echi-dbg.c debugfs. It contains four files
async, bandwidth, periodic and registers.
The registers functions as what regdump does in dwc3. And the patch
implements
a snapshot to do the similar things done by async and periodic.
Because a way to inspect the content of data structures (i.e. TRBs, Events)
interacting with the controller is really important for debugging,
especially for HW issues. It just simply provides you a interface to check
what's currently in TRBs and event buffers (and nothing more, no more
guarantees).
In EHCI, async and periodic also can't guarantee you the reliable data, as
you can't prevent the controller from writing the interacting data
structures (unless you stop it). It's developer's decision to how to analyze
the data. They're not perfect, but simple and helpful.
As far as I see, it's useful for below senarios:
1. Bugs can't be reproduced with VERBOSE_DEBUG, as printk introduces
timing effect. Some HW bugs are timing sensitive, even a single printk
will prevent you from reproducing the issue.
With snapshot, we can check the TRBs, events, requests to see the
final status to get more clues to triage an issue.
2. Some bugs are hard to reproduce, and can be seen once or
Re: [PATCH] usb: dwc3: debugfs: add snapshot to dump requests trbs events
On Wed, Apr 30, 2014 at 12:14:42PM -0500, Felipe Balbi wrote: sorry but your patch is not good for acceptance in mainline. Thanks your time. Jincan -- To unsubscribe from this list: send the line unsubscribe 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 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
* 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.
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 01/11] drivers: reset: TI: SoC reset controller support.
Philipp and Arnd
Thank you for the comments
On 04/30/2014 03:20 AM, Philipp Zabel wrote:
Hi Dan,
Am Dienstag, den 29.04.2014, 15:19 -0500 schrieb Dan Murphy:
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 | 58
drivers/reset/ti/reset-ti.c | 195
++
include/linux/reset_ti.h | 25 +
7 files changed, 289 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
create mode 100644 include/linux/reset_ti.h
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..6afdf37
--- /dev/null
+++ b/drivers/reset/ti/reset-ti-data.h
@@ -0,0 +1,58 @@
+/*
+ * 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/of_device.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 {
+u32 rstctrl_offs;
+u32 rstst_offs;
+u8 rstctrl_bit;
+u8 rstst_bit;
You are only ever using these as (1 rstctrl_bit) and as
(1 rstst_bit). You could store the mask here directly,
like the regulator framework does.
Yes we can store the mask as opposed to the bit.
I will look into it for v2.
+};
+
+/**
+ * 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
+ *
Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
* Tomi Valkeinen tomi.valkei...@ti.com [140429 23:14]: On 29/04/14 20:38, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140429 09:33]: On 29/04/14 19:19, Tomi Valkeinen wrote: On 29/04/14 18:05, Tony Lindgren wrote: omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it. That would be probably best set up the same way we have already set up for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can access it using regmap, see how drivers/regulator/pbias-regulator.c sets up the pbias regulator with regmap for MMC. Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong? I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver. Anything using the system control module registers should be a separate driver. And it should ideally be implemeting some Linux generic framework that the consumer driver can then use. That leaves out the need to export custom functions. Ok. I guess we don't have a PHY framework for displays though, so how about just a separate minimal driver under drivers/video/omap2 that uses the syscon? Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register is not in the DSI PHY block, but in the control module, and it is used to enable/disable the pins (for omap4/5) and to set pull up/down for the pins (only for omap4). Oddly, for omap5, there's also a normal padconfig register for the DSI pins, but not so for omap4. To me it looks like a pad config register. I don't know why there's a separate odd register for it and it's not using the normal padconfig system. I'd like to use the pinctrl framework for it, but the pinctrl-single cannot handle such a funny register. So, if Anything using the system control module registers should be a separate driver, then I guess I need to write a pinctrl driver for this single register? Have you checked out pinctrl-single,bits binding? That should allow you to map random bits in a single register to a pinctrl driver instance. Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver. Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5? We do use different compatible strings for different major versions of the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could be used on some other SoC, with different control stuff. We could use separate compatible string for each SoC that uses DSS, but then we're really encoding the SoC version into the compatible string, not DSS version. Of course, if there will be a separate driver managing the CONTROL_DSIPHY register, then that one should use compatible string specific to the SoC, as it's not a DSS driver at all. Yeah probably using pinctrl-single,bits, or a separate driver with syscon makes most sense here. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/11] ARM: dts: am33xx: Add prcm_resets node
Tony and Arnd
Thanks for the comments
On 04/29/2014 07:22 PM, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140429 13:35]:
On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote:
+ * AM33xx reset index for PRCM Module
+ *
+ * Copyright 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H
+#define _DT_BINDINGS_RESET_TI_AM33XX_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_GFX_RESET1
+#define RESET_PER_RESET2
+
+#endif
Interfaces like this should only be used if you can't use hardware
numbers, in general. If these numbers are in the data sheet, just
put them directly into the dts file, as we do for interrupt numbers,
gpio numbers, register offsets etc.
If you have made them up to define an interface between the driver
and DT because there is no usable hardare ID, I'd suggest just using
a single file across all SoCs that have this driver, and have
a unified name space.
Also, it's a bit unclear how the reset controller phandle is used
referenced and used by the consumer device.. Maybe setting that up
first in a Linux generic way is a good point starting point.
Maybe something like this along the same way as clocks are set up
(completely untested):
reset1 {
iva_reset: reset1 {
reg = /bits/ 8 0;
};
gfx_reset: reset1 {
reg = /bits/ 8 1;
};
...
};
iva {
compatible = ti,ivahd;
resets = reset1 1;
...
};
I had something very similar to this when I was developing this driver but
moved away from this.
Following the clocks implementation I had a separate dtsi for resets for each
device and had the data defined like so
for each SoC.
prcm_resets {
device_reset: device_reset {
rstctrl_offs = 0x1104;
ctrl_bit-shift = 0;
rstst_offs = 0x1114;
sts_bit-shift = 0;
};
gpu_reset: gpu_reset {
rstctrl_offs = 0x0D00;
ctrl_bit-shift = 3;
rstst_offs = 0x0D0C;
sts_bit-shift = 5;
};
};
And then any client interested in a specific reset driver would include this
resets = prcm_resets gpu_reset;
reset-names = gpu_reset;
Our reset code would then retrieve the register data through the phandle
instead of an index.
Thoughts?
Dan
Regards,
Tony
--
--
Dan Murphy
--
To unsubscribe from this list: send the line unsubscribe 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 08/11] ARM: dts: am33xx: Add prcm_resets node
* Dan Murphy dmur...@ti.com [140430 11:00]:
Tony and Arnd
Thanks for the comments
On 04/29/2014 07:22 PM, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140429 13:35]:
On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote:
+ * AM33xx reset index for PRCM Module
+ *
+ * Copyright 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H
+#define _DT_BINDINGS_RESET_TI_AM33XX_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_GFX_RESET1
+#define RESET_PER_RESET2
+
+#endif
Interfaces like this should only be used if you can't use hardware
numbers, in general. If these numbers are in the data sheet, just
put them directly into the dts file, as we do for interrupt numbers,
gpio numbers, register offsets etc.
If you have made them up to define an interface between the driver
and DT because there is no usable hardare ID, I'd suggest just using
a single file across all SoCs that have this driver, and have
a unified name space.
Also, it's a bit unclear how the reset controller phandle is used
referenced and used by the consumer device.. Maybe setting that up
first in a Linux generic way is a good point starting point.
Maybe something like this along the same way as clocks are set up
(completely untested):
reset1 {
iva_reset: reset1 {
reg = /bits/ 8 0;
};
gfx_reset: reset1 {
reg = /bits/ 8 1;
};
...
};
iva {
compatible = ti,ivahd;
resets = reset1 1;
...
};
I had something very similar to this when I was developing this driver but
moved away from this.
Following the clocks implementation I had a separate dtsi for resets for each
device and had the data defined like so
for each SoC.
prcm_resets {
device_reset: device_reset {
rstctrl_offs = 0x1104;
ctrl_bit-shift = 0;
rstst_offs = 0x1114;
sts_bit-shift = 0;
};
gpu_reset: gpu_reset {
rstctrl_offs = 0x0D00;
ctrl_bit-shift = 3;
rstst_offs = 0x0D0C;
sts_bit-shift = 5;
};
};
And then any client interested in a specific reset driver would include this
resets = prcm_resets gpu_reset;
reset-names = gpu_reset;
Our reset code would then retrieve the register data through the phandle
instead of an index.
Thoughts?
Using phandles makes sense here because it avoids the indexing. Indexing
has a problem of needing to be in sync with the .dts files and the
device driver(s). Using an index also easily causes misuse of virtual
indexes being added that no longer describe the hardware at all.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/11] ARM: dts: am33xx: Add prcm_resets node
Tony
On 04/30/2014 01:10 PM, Tony Lindgren wrote:
* Dan Murphy dmur...@ti.com [140430 11:00]:
Tony and Arnd
Thanks for the comments
On 04/29/2014 07:22 PM, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140429 13:35]:
On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote:
+ * AM33xx reset index for PRCM Module
+ *
+ * Copyright 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H
+#define _DT_BINDINGS_RESET_TI_AM33XX_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_GFX_RESET1
+#define RESET_PER_RESET2
+
+#endif
Interfaces like this should only be used if you can't use hardware
numbers, in general. If these numbers are in the data sheet, just
put them directly into the dts file, as we do for interrupt numbers,
gpio numbers, register offsets etc.
If you have made them up to define an interface between the driver
and DT because there is no usable hardare ID, I'd suggest just using
a single file across all SoCs that have this driver, and have
a unified name space.
Also, it's a bit unclear how the reset controller phandle is used
referenced and used by the consumer device.. Maybe setting that up
first in a Linux generic way is a good point starting point.
Maybe something like this along the same way as clocks are set up
(completely untested):
reset1 {
iva_reset: reset1 {
reg = /bits/ 8 0;
};
gfx_reset: reset1 {
reg = /bits/ 8 1;
};
...
};
iva {
compatible = ti,ivahd;
resets = reset1 1;
...
};
I had something very similar to this when I was developing this driver but
moved away from this.
Following the clocks implementation I had a separate dtsi for resets for
each device and had the data defined like so
for each SoC.
prcm_resets {
device_reset: device_reset {
rstctrl_offs = 0x1104;
ctrl_bit-shift = 0;
rstst_offs = 0x1114;
sts_bit-shift = 0;
};
gpu_reset: gpu_reset {
rstctrl_offs = 0x0D00;
ctrl_bit-shift = 3;
rstst_offs = 0x0D0C;
sts_bit-shift = 5;
};
};
And then any client interested in a specific reset driver would include this
resets = prcm_resets gpu_reset;
reset-names = gpu_reset;
Our reset code would then retrieve the register data through the phandle
instead of an index.
Thoughts?
Using phandles makes sense here because it avoids the indexing. Indexing
has a problem of needing to be in sync with the .dts files and the
device driver(s). Using an index also easily causes misuse of virtual
indexes being added that no longer describe the hardware at all.
Thanks. What about placing register data in the dts files? Is there any issue
with this concept?
Dan
Regards,
Tony
--
--
Dan Murphy
--
To unsubscribe from this list: send the line unsubscribe 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] usb: dwc3: gadget: giveback request if start transfer fail
At least we should giveback the current request to the gadget. Otherwise, the gadget will be stuck without knowing anything. It was oberved that the failure can happen if the request is queued when the run/stop bit of controller is not set. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com --- drivers/usb/dwc3/gadget.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 70715ee..8d0c3c7 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1000,9 +1000,7 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep, u16 cmd_param, * here and stop, unmap, free and del each of the linked * requests instead of what we do now. */ - usb_gadget_unmap_request(dwc-gadget, req-request, - req-direction); - list_del(req-list); + dwc3_gadget_giveback(dep, req, -ESHUTDOWN); return ret; } -- 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] usb: dwc3: gadget: fix burst size corruption
endpoint.maxburst may be 0 if a gadget doesn't call config_ep_by_speed()
to update it from the companion descriptor.
And endpoint.maxburst - 1 returns 1b which wrongly sets bit
26 of endpoint parameter 0.
This sets a wrong endpoint state and will cause Get Endpoint State
command can't get the corret endpoint state and Set Endpoint Config
command can't restore the correct endpoint state during hibernation
resume flow.
Thus, when endpoint.maxburst is 0, we should set burst as 0 directly.
Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
---
drivers/usb/dwc3/gadget.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 70715ee..44eca95 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -440,7 +440,8 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
struct dwc3_ep *dep,
/* Burst size is only needed in SuperSpeed mode */
if (dwc-gadget.speed == USB_SPEED_SUPER) {
- u32 burst = dep-endpoint.maxburst - 1;
+ u32 burst = dep-endpoint.maxburst ?
+ dep-endpoint.maxburst - 1 : 0;
params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst);
}
--
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] usb: dwc3: gadget: giveback request if start transfer fail
Hi, On Thu, May 01, 2014 at 02:36:08AM -0400, Zhuang Jin Can wrote: At least we should giveback the current request to the gadget. Otherwise, the gadget will be stuck without knowing anything. It was oberved that the failure can happen if the request is queued when the run/stop bit of controller is not set. why is your gadget queueing any requests before calling -udc_start() ? A better question, what modification have you done to udc-core.c which broke this ? udc-core *always* calls -udc_start() by the time you load a gadget driver so this case will *never* happen. Whatever modification you did, broke this assumption and I will *not* accept this patch because the bug is elsewhere and *not* in mainline kernel. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com --- drivers/usb/dwc3/gadget.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 70715ee..8d0c3c7 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1000,9 +1000,7 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep, u16 cmd_param, * here and stop, unmap, free and del each of the linked * requests instead of what we do now. */ - usb_gadget_unmap_request(dwc-gadget, req-request, - req-direction); - list_del(req-list); + dwc3_gadget_giveback(dep, req, -ESHUTDOWN); return ret; } -- 1.7.9.5 -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: dwc3: gadget: fix burst size corruption
On Thu, May 01, 2014 at 03:16:04AM -0400, Zhuang Jin Can wrote:
endpoint.maxburst may be 0 if a gadget doesn't call config_ep_by_speed()
to update it from the companion descriptor.
And endpoint.maxburst - 1 returns 1b which wrongly sets bit
26 of endpoint parameter 0.
This sets a wrong endpoint state and will cause Get Endpoint State
command can't get the corret endpoint state and Set Endpoint Config
command can't restore the correct endpoint state during hibernation
resume flow.
Thus, when endpoint.maxburst is 0, we should set burst as 0 directly.
Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
---
drivers/usb/dwc3/gadget.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 70715ee..44eca95 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -440,7 +440,8 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
struct dwc3_ep *dep,
/* Burst size is only needed in SuperSpeed mode */
if (dwc-gadget.speed == USB_SPEED_SUPER) {
- u32 burst = dep-endpoint.maxburst - 1;
+ u32 burst = dep-endpoint.maxburst ?
+ dep-endpoint.maxburst - 1 : 0;
again, you found a bug on the gadget driver. Fix that. composite.c
guarantees that for those functions which don't pass bMaxBurst,
gadget-maxburst will be set to *at least* 1.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v10 1/5] mmc: omap_hsmmc: Enable SDIO interrupt
Hi Andreas,
2014-04-30 14:23 GMT+02:00 Andreas Müller schnitzelt...@googlemail.com:
On Mon, Apr 28, 2014 at 9:40 AM, Andreas Fenkart afenk...@gmail.com wrote:
@@ -2201,11 +2346,16 @@ static int omap_hsmmc_suspend(struct device *dev)
pm_runtime_get_sync(host-dev);
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER)) {
- omap_hsmmc_disable_irq(host);
+ OMAP_HSMMC_WRITE(host-base, ISE, 0);
+ OMAP_HSMMC_WRITE(host-base, IE, 0);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
}
+ if (host-wake_irq !(host-mmc-pm_flags MMC_PM_WAKE_SDIO_IRQ))
+ disable_irq(host-wake_irq);
+
I think it says, Do you want to wake up from deep power states when
an SDIO IRQ is pending
Will try to bring this more to the point
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
@@ -2231,6 +2381,9 @@ static int omap_hsmmc_resume(struct device *dev)
omap_hsmmc_protect_card(host);
+ if (host-wake_irq !(host-mmc-pm_flags MMC_PM_WAKE_SDIO_IRQ))
you're right should be ''
+ enable_irq(host-wake_irq);
+
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
return 0;
Maybe I misunderstand something here but shouldn't
disable_irq/enable_irq be swapped here?
/Andreas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Hi Ulf and Geert, On Thursday 24 April 2014 15:11:24 Ulf Hansson wrote: On 24 April 2014 12:13, Geert Uytterhoeven geert+rene...@glider.be wrote: When adding a device from DT, check if its clocks are suitable for Runtime PM, and register them with the PM core. If Runtime PM is disabled, just enable the clock. This allows the PM core to automatically manage gate clocks of devices for Runtime PM. Normally I don't think it's a good idea to automatically manage clocks from PM core or any other place but from the driver (and possibly the subsystem). The reason is simply that we hide things that normally is supposed to be handled by the driver. Typically a cross SOC driver should work fine both with and without a pm_domain. It should also not rely on CONFIG_PM_RUNTIME. That's a very good point. Geert, what do you think should happen if CONFIG_PM_RUNTIME is not set ? I don't have a strong opinion (yet) on whether we could require CONFIG_PM_RUNTIME, but it would indeed be nice to support both cases. One option would be to keep the clocks enabled unconditionally in that case, as not setting CONFIG_PM_RUNTIME means that the user doesn't care (or cares less) about power consumption. Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On Tuesday 29 April 2014 14:16:10 Grant Likely wrote: On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman khil...@linaro.org wrote: Geert Uytterhoeven geert+rene...@glider.be writes: When adding a device from DT, check if its clocks are suitable for Runtime PM, and register them with the PM core. If Runtime PM is disabled, just enable the clock. This allows the PM core to automatically manage gate clocks of devices for Runtime PM. ...unless the device is already in an existing pm_domain, right? I like this approach, and it extends nicely what we already do on platforms using drivers/base/power/clock_ops.c into DT land. My only concern is how this will interact if it's used along with devices that have existing pm_domains. I don't have any specific concerns (yet, because it's Friday, and my brain is turing off), but it just made me wonder if this will be potentially confusing. I have big concerns about this approach. First, it will only work if a clock is available at deivce creation time. The conversion of irq controllers to normal device drivers has already shown that is a bad idea. I also don't like that it tries to set up every clock, but there is no guarantee that the driver will even use it. I would rather see this behaviour linked into the function that obtains the clock at driver .probe() time. That way it can handle deferred probe correctly and it only sets up clocks that are actually used by the driver. I like the idea, as it gives an opt-in approach to the problem: drivers could decide whether they want the runtime PM core to handle clocks automatically (which should cover most cases), but would have the option of handling clocks manually if needed for special purposes. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core
Hi Geert, On Thursday 24 April 2014 12:13:19 Geert Uytterhoeven wrote: On SoCs like ARM/SH-mobile, gate clocks are available for modules, allowing Runtime PM for a device controlled by a gate clock. On legacy shmobile kernels, this is handled by the PM runtime code in drivers/sh/pm_runtime.c, which installs a clock notifier for the platform bus, registering the NULL clock of each platform device with the PM core. This approach is also used on davinci, keystone, and omap1. This requires the device to have the MSTP clock defined as the first clock in its DT node. I'm not against that, but the requirement should be clearly documented, and we need to check existing DT bindings to make sure they comply with that. I'd like to also take this as an opportunity to discuss how we should name clocks in DT bindings for Renesas devices. Most devices have a single MSTP clock, in which case we don't specify a name. Other devices need several clocks. Names for the non-MSTP clocks will obviously be device-dependent, but how should the MSTP clock be called in that time ? Should it have an empty name (a string in DT) ? Should it have a standard name ? Maybe fck for functional clock ? On multi-platform shmobile kernels, this was not handled at all, leading to spurious disabled clocks on drivers relying on Runtime PM, depending on implicit reset state, or on the bootloader. A first solution, enabling the PM runtime code in drivers/sh/pm_runtime.c in a multi-platform-safe way, was provided by the patch series [PATCH v2 00/17] ARM: shmobile: Enable drivers/sh/pm_runtime.c on multi-platform (http://www.spinics.net/lists/linux-sh/msg30887.html). Here is an alternative approach, avoiding the reliance on C board files, which are being phased out. This is also related to a patch series by Felipe Balbi ([RFC/PATCH] base: platform: add generic clock handling for platform-bus, https://lkml.org/lkml/2014/1/31/290) This series: 1. Lets the MSTP clock driver indicate that its clocks are suitable for Runtime PM, 2. Lets the DT code retrieve clock information when adding a device (it already retrieves information for resources (registers, irq) --- unfortunately clocks are not resources), and registering clocks suitable for Runtime PM with the PM core. If Runtime PM is disabled, the clocks are just enabled. Note that this works for devices instantiated from DT only. Fortunately the drivers for the remaining platform devices (SCI and CMT) handle clocks theirselves, without Runtime PM, so they get properly enabled. Patches: - [1/4] clk: Add CLK_RUNTIME_PM and clk_may_runtime_pm() - [2/4] PM / clock_ops: Add pm_clk_add_clk() - [3/4] of/clk: Register clocks suitable for Runtime PM with the - [4/4] clk: shmobile: mstp: Set CLK_RUNTIME_PM flag This series was tested on Renesas r8a7791, using the Koelsch development board. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 30/04/14 14:25, Laurent Pinchart wrote: On Tuesday 29 April 2014 14:16:10 Grant Likely wrote: On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman khil...@linaro.org wrote: Geert Uytterhoeven geert+rene...@glider.be writes: When adding a device from DT, check if its clocks are suitable for Runtime PM, and register them with the PM core. If Runtime PM is disabled, just enable the clock. This allows the PM core to automatically manage gate clocks of devices for Runtime PM. ...unless the device is already in an existing pm_domain, right? I like this approach, and it extends nicely what we already do on platforms using drivers/base/power/clock_ops.c into DT land. My only concern is how this will interact if it's used along with devices that have existing pm_domains. I don't have any specific concerns (yet, because it's Friday, and my brain is turing off), but it just made me wonder if this will be potentially confusing. I have big concerns about this approach. First, it will only work if a clock is available at deivce creation time. The conversion of irq controllers to normal device drivers has already shown that is a bad idea. I also don't like that it tries to set up every clock, but there is no guarantee that the driver will even use it. I would rather see this behaviour linked into the function that obtains the clock at driver .probe() time. That way it can handle deferred probe correctly and it only sets up clocks that are actually used by the driver. I like the idea, as it gives an opt-in approach to the problem: drivers could decide whether they want the runtime PM core to handle clocks automatically (which should cover most cases), but would have the option of handling clocks manually if needed for special purposes. If drivers could have a field to say that they allow the driver-core or the pm-runtime would mean that drivers could easily be change without having to deal with what the SoC/SoC family have to care about this. It would also mean that we could change drivers without having to make any changes to the SoC to say that it has to opt-in to the support. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Hi Kevin,
On Sat, Apr 26, 2014 at 1:44 AM, Kevin Hilman khil...@linaro.org wrote:
Geert Uytterhoeven geert+rene...@glider.be writes:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
...unless the device is already in an existing pm_domain, right?
At this point in the kernel boot process, the device cannot be in a
pm_domain yet.
I like this approach, and it extends nicely what we already do on
platforms using drivers/base/power/clock_ops.c into DT land.
My only concern is how this will interact if it's used along with
devices that have existing pm_domains. I don't have any specific
concerns (yet, because it's Friday, and my brain is turing off), but it
just made me wonder if this will be potentially confusing.
Adding devices to pm_domains is done later, so it can be overridden.
Also...
[...]
+static int of_clk_register(struct device *dev, struct clk *clk)
+{
+ int error;
+
+ if (!dev-pm_domain) {
+ error = pm_clk_create(dev);
+ if (error)
+ return error;
+
+ dev-pm_domain = of_clk_pm_domain;
+ }
+
+ dev_dbg(dev, Setting up clock for runtime PM management\n);
+ return pm_clk_add_clk(dev, clk);
I would've expected these 2 lines to be inside the pm_domain check.
What's the reason for doing the pm_clk_add() when the pm_domain isn't
going to be used? I suppose it's harmless, but it's a bit confusing.
Sorry, the !dev-pm_domain check does deserve a comment explaining this.
If there are multiple clocks suitable for pm_runtime, the pm_clk_create(dev)
should be done only once.
Currently e.g. davinci registers 3 clocks with pm_clk (fck,
master, and slave).
Omap has 2 (fck and ick).
BTW, keystone doesn't seem to set pm_clk_notifier_block.con_ids. From a quick
look, this will crash with a NULL-pointer dereference in pm_clk_notify()? Or am
I missing something here?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Hi Grant,
On Tue, Apr 29, 2014 at 3:16 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman khil...@linaro.org wrote:
Geert Uytterhoeven geert+rene...@glider.be writes:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
...unless the device is already in an existing pm_domain, right?
I like this approach, and it extends nicely what we already do on
platforms using drivers/base/power/clock_ops.c into DT land.
My only concern is how this will interact if it's used along with
devices that have existing pm_domains. I don't have any specific
concerns (yet, because it's Friday, and my brain is turing off), but it
just made me wonder if this will be potentially confusing.
I have big concerns about this approach. First, it will only work if
a clock is available at deivce creation time. The conversion of irq
controllers to normal device drivers has already shown that is a bad
idea.
That's indeed a valid concern that needs to be addressed.
I also don't like that it tries to set up every clock, but there is no
guarantee that the driver will even use it. I would rather see this
behaviour linked into the function that obtains the clock at driver
.probe() time. That way it can handle deferred probe correctly and it
only sets up clocks that are actually used by the driver.
Not every clock. Only the clocks that are advertised by the clock driver as
being suitable for runtime_pm management. These are typically module
clocks, that must be enabled for the module to work. The driver doesn't
always want to handle these explicitly.
In fact we have one case on shmobile where the module clock for an IP
core (rcar-gpio) is enabled unconditionally in one SoC, while it became
controllable through a gate clock in a later SoC.
With my patch, just adding the clock to the DT node is sufficient to make
it work.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
Hi Laurent,
On Wed, Apr 30, 2014 at 11:23 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Thursday 24 April 2014 15:11:24 Ulf Hansson wrote:
On 24 April 2014 12:13, Geert Uytterhoeven geert+rene...@glider.be wrote:
When adding a device from DT, check if its clocks are suitable for Runtime
PM, and register them with the PM core.
If Runtime PM is disabled, just enable the clock.
This allows the PM core to automatically manage gate clocks of devices for
Runtime PM.
Normally I don't think it's a good idea to automatically manage
clocks from PM core or any other place but from the driver (and
possibly the subsystem).
The reason is simply that we hide things that normally is supposed to
be handled by the driver. Typically a cross SOC driver should work
fine both with and without a pm_domain. It should also not rely on
CONFIG_PM_RUNTIME.
That's a very good point. Geert, what do you think should happen if
CONFIG_PM_RUNTIME is not set ? I don't have a strong opinion (yet) on whether
we could require CONFIG_PM_RUNTIME, but it would indeed be nice to support
both cases. One option would be to keep the clocks enabled unconditionally in
that case, as not setting CONFIG_PM_RUNTIME means that the user doesn't care
(or cares less) about power consumption.
This is already handled by my patch. If CONFIG_PM_RUNTIME is disabled,
the clocks are enabled by calling clk_prepare_enabled().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core
Hi Laurent,
On Wed, Apr 30, 2014 at 11:29 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Thursday 24 April 2014 12:13:19 Geert Uytterhoeven wrote:
On SoCs like ARM/SH-mobile, gate clocks are available for modules, allowing
Runtime PM for a device controlled by a gate clock.
On legacy shmobile kernels, this is handled by the PM runtime code in
drivers/sh/pm_runtime.c, which installs a clock notifier for the platform
bus, registering the NULL clock of each platform device with the PM core.
This approach is also used on davinci, keystone, and omap1.
This requires the device to have the MSTP clock defined as the first clock in
its DT node. I'm not against that, but the requirement should be clearly
documented, and we need to check existing DT bindings to make sure they comply
with that.
Being the first clock is only required for the NULL clock. And that
is only done
for legacy shmobile kernels, not for multi-platform.
In this patch series, the clock would be chosen based on the presence of the
CLK_RUNTIME_PM flag, to be set by the clock driver. I.e. DT is not involved
directly (for a change... why does everybody think the whole world revolves
around DT these days ? :-)
I'd like to also take this as an opportunity to discuss how we should name
clocks in DT bindings for Renesas devices. Most devices have a single MSTP
clock, in which case we don't specify a name. Other devices need several
clocks. Names for the non-MSTP clocks will obviously be device-dependent, but
how should the MSTP clock be called in that time ? Should it have an empty
name (a string in DT) ? Should it have a standard name ? Maybe fck for
functional clock ?
Empty names should not be used if there can be multiple clocks, right?
Grepping in arch/*/boot/dts/, fck seems to be popular (only) for TI SoCs.
Stadardizing across SoCs and architectures would be nice, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe 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 08/11] ARM: dts: am33xx: Add prcm_resets node
* Dan Murphy dmur...@ti.com [140430 11:14]:
On 04/30/2014 01:10 PM, Tony Lindgren wrote:
* Dan Murphy dmur...@ti.com [140430 11:00]:
Tony and Arnd
Thanks for the comments
On 04/29/2014 07:22 PM, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [140429 13:35]:
On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote:
+ * AM33xx reset index for PRCM Module
+ *
+ * Copyright 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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_TI_AM33XX_H
+#define _DT_BINDINGS_RESET_TI_AM33XX_H
+
+#define RESET_DEVICE_RESET 0
+#define RESET_GFX_RESET1
+#define RESET_PER_RESET2
+
+#endif
Interfaces like this should only be used if you can't use hardware
numbers, in general. If these numbers are in the data sheet, just
put them directly into the dts file, as we do for interrupt numbers,
gpio numbers, register offsets etc.
If you have made them up to define an interface between the driver
and DT because there is no usable hardare ID, I'd suggest just using
a single file across all SoCs that have this driver, and have
a unified name space.
Also, it's a bit unclear how the reset controller phandle is used
referenced and used by the consumer device.. Maybe setting that up
first in a Linux generic way is a good point starting point.
Maybe something like this along the same way as clocks are set up
(completely untested):
reset1 {
iva_reset: reset1 {
reg = /bits/ 8 0;
};
gfx_reset: reset1 {
reg = /bits/ 8 1;
};
...
};
iva {
compatible = ti,ivahd;
resets = reset1 1;
...
};
I had something very similar to this when I was developing this driver but
moved away from this.
Following the clocks implementation I had a separate dtsi for resets for
each device and had the data defined like so
for each SoC.
prcm_resets {
device_reset: device_reset {
rstctrl_offs = 0x1104;
ctrl_bit-shift = 0;
rstst_offs = 0x1114;
sts_bit-shift = 0;
};
gpu_reset: gpu_reset {
rstctrl_offs = 0x0D00;
ctrl_bit-shift = 3;
rstst_offs = 0x0D0C;
sts_bit-shift = 5;
};
};
And then any client interested in a specific reset driver would include
this
resets = prcm_resets gpu_reset;
reset-names = gpu_reset;
Our reset code would then retrieve the register data through the phandle
instead of an index.
Thoughts?
Using phandles makes sense here because it avoids the indexing. Indexing
has a problem of needing to be in sync with the .dts files and the
device driver(s). Using an index also easily causes misuse of virtual
indexes being added that no longer describe the hardware at all.
Thanks. What about placing register data in the dts files? Is there any
issue with this concept?
I don't have issues with that but others may. In this case it seems
like you should get away just defining few different types of reset
controllers without adding any any custom properties?
In your example above, the rstctrl_offs should be just standard
reg entry as an offset from the prcm_resets base address. Then you
you only really need the bit shift and the type of the reset
controller? And the type could be the compatible flag?
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
[PATCHv5 RFC 10/15] hwspinlock/core: prepare core to support reserved locks
The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.
This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwlock to
identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() variants or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 14 --
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index ed47e77..c2063bc 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
/* radix tree tags */
#define HWSPINLOCK_UNUSED (0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED(1) /* tags an hwspinlock as reserved */
/*
* A radix tree is used to maintain the available hwspinlock instances.
@@ -326,7 +327,7 @@ static int hwspin_lock_register_single(struct hwspinlock
*hwlock, int id)
}
/* mark this hwspinlock as available */
- tmp = radix_tree_tag_set(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+ tmp = radix_tree_tag_set(hwspinlock_tree, id, hwlock-type);
/* self-sanity check which should never fail */
WARN_ON(tmp != hwlock);
@@ -344,7 +345,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock
*hwlock, int id)
mutex_lock(hwspinlock_tree_lock);
/* make sure the hwspinlock is not in use (tag is set) */
- if (!radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
+ if (!radix_tree_tag_get(hwspinlock_tree, id, hwlock-type)) {
pr_err(hwspinlock %d still in use (or not present)\n, id);
ret = -EBUSY;
goto out;
@@ -467,6 +468,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
+ hwlock-type = HWSPINLOCK_UNUSED;
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -551,7 +553,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
/* mark hwspinlock as used, should not fail */
tmp = radix_tree_tag_clear(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
/* self-sanity check that should never fail */
WARN_ON(tmp != hwlock);
@@ -650,7 +652,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned
int id)
WARN_ON(hwlock_to_id(hwlock) != id);
/* make sure this hwspinlock is unused */
- ret = radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+ ret = radix_tree_tag_get(hwspinlock_tree, id, hwlock-type);
if (ret == 0) {
pr_warn(hwspinlock %u is already in use\n, id);
hwlock = NULL;
@@ -741,7 +743,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
/* make sure the hwspinlock is used */
ret = radix_tree_tag_get(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
if (ret == 1) {
dev_err(dev, %s: hwlock is already free\n, __func__);
dump_stack();
@@ -756,7 +758,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
/* mark this hwspinlock as available */
tmp = radix_tree_tag_set(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
/* sanity check (this shouldn't happen) */
WARN_ON(tmp != hwlock);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h
b/drivers/hwspinlock/hwspinlock_internal.h
index 5e42613..1be32ca 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -47,11 +47,13 @@ struct hwspinlock_ops {
* struct hwspinlock - this struct represents a single hwspinlock instance
* @bank: the hwspinlock_device structure which owns this lock
* @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
* @priv: private data, owned by the underlying platform-specific hwspinlock
drv
*/
struct hwspinlock {
struct hwspinlock_device *bank;
spinlock_t lock;
+ unsigned int type;
void *priv;
};
--
1.9.2
[PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api
The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular client api functions are
also modified to check for an invalid hwlock handle.
The consumers MUST check using IS_ERR() when requesting hwlocks
going forward to determine a valid hwlock.
Signed-off-by: Suman Anna s-a...@ti.com
---
TODO: Move this patch before the Patch4,
hwspinlock/core: add common OF helpers
if accepted to go with the current series
---
Documentation/hwspinlock.txt | 12 ++--
drivers/hwspinlock/hwspinlock_core.c | 25 ++---
2 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 903d477..bf1c7e46 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -35,15 +35,15 @@ independent, drivers.
2. User API
struct hwspinlock *hwspin_lock_request(void);
- - dynamically assign an hwspinlock and return its address, or NULL
- in case an unused hwspinlock isn't available. Users of this
+ - dynamically assign a hwspinlock and return its address, or an equivalent
+ ERR_PTR() in case an unused hwspinlock isn't available. Users of this
API will usually want to communicate the lock's id to the remote core
before it can be used to achieve synchronization.
Should be called from a process context (might sleep).
struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
- - assign a specific hwspinlock id and return its address, or NULL
- if that hwspinlock is already in use. Usually board code will
+ - assign a specific hwspinlock id and return its address, or an equivalent
+ ERR_PTR() if that hwspinlock is already in use. Usually board code will
be calling this function in order to reserve specific hwspinlock
ids for predefined purposes.
Should be called from a process context (might sleep).
@@ -172,7 +172,7 @@ int hwspinlock_example1(void)
/* dynamically assign a hwspinlock */
hwlock = hwspin_lock_request();
- if (!hwlock)
+ if (IS_ERR(hwlock))
...
id = hwspin_lock_get_id(hwlock);
@@ -208,7 +208,7 @@ int hwspinlock_example2(void)
* by board init code.
*/
hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID);
- if (!hwlock)
+ if (IS_ERR(hwlock))
...
/* try to take it, but don't spin on it */
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index e74b55b..56c4303 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -96,7 +96,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
{
int ret;
- BUG_ON(!hwlock);
+ BUG_ON(IS_ERR_OR_NULL(hwlock));
BUG_ON(!flags mode == HWLOCK_IRQSTATE);
/*
@@ -235,7 +235,7 @@ EXPORT_SYMBOL_GPL(__hwspin_lock_timeout);
*/
void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
{
- BUG_ON(!hwlock);
+ BUG_ON(IS_ERR_OR_NULL(hwlock));
BUG_ON(!flags mode == HWLOCK_IRQSTATE);
/*
@@ -600,7 +600,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
*/
int hwspin_lock_get_id(struct hwspinlock *hwlock)
{
- if (!hwlock) {
+ if (IS_ERR_OR_NULL(hwlock)) {
pr_err(invalid hwlock\n);
return -EINVAL;
}
@@ -620,7 +620,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_get_id);
*
* Should be called from a process context (might sleep)
*
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent ERR_PTR()
+ * on error
*/
struct hwspinlock *hwspin_lock_request(void)
{
@@ -634,7 +635,7 @@ struct hwspinlock *hwspin_lock_request(void)
0, 1, HWSPINLOCK_UNUSED);
if (ret == 0) {
pr_warn(a free hwspinlock is not available\n);
- hwlock = NULL;
+ hwlock = ERR_PTR(-ENXIO);
goto out;
}
@@ -644,7 +645,7 @@ struct hwspinlock *hwspin_lock_request(void)
/* mark as used and power up */
ret = __hwspin_lock_request(hwlock);
if (ret 0)
- hwlock = NULL;
+ hwlock = ERR_PTR(ret);
out:
mutex_unlock(hwspinlock_tree_lock);
@@ -663,7 +664,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request);
*
* Should be called from a process context (might sleep)
*
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
*/
struct hwspinlock
[PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get reserved locks
Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/omap_hwspinlock.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 1d0c78e..0dad783 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -143,6 +143,12 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = bank-lock[0]; i num_locks; i++, hwlock++)
hwlock-priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
+ reserved_locks = of_hwspin_lock_get_num_reserved_locks(node);
+ if (reserved_locks 0) {
+ ret = -EINVAL;
+ goto iounmap_base;
+ }
+
ret = hwspin_lock_register(bank, pdev-dev, omap_hwspinlock_ops,
base_id, num_locks, reserved_locks);
if (ret)
--
1.9.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
[PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific
Changed the return statements to return an ERR_PTR instead of NULL in case of an error. This patch helps with deferred probing of any client users if the corresponding hwspinlock bank is not yet registered with the hwspinlock core. Signed-off-by: Suman Anna s-a...@ti.com --- TODO: Collapse into Patch4, hwspinlock/core: add common OF helpers if accepted to go with the current series --- Documentation/hwspinlock.txt | 4 ++-- drivers/hwspinlock/hwspinlock_core.c | 9 + 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt index bf1c7e46..10d7ecc 100644 --- a/Documentation/hwspinlock.txt +++ b/Documentation/hwspinlock.txt @@ -50,8 +50,8 @@ independent, drivers. struct hwspinlock *of_hwspin_lock_request_specific( struct device_node *np, const char *propname, int index); - - assign a specific hwspinlock id and return its address, or NULL - if that hwspinlock is already in use. This function is the OF + - assign a specific hwspinlock id and return its address, or an equivalent + ERR_PTR() if that hwspinlock is already in use. This function is the OF equivalent of hwspin_lock_request_specific() function, and provides a means for users of the hwspinlock module to request a specific hwspinlock using the phandle of the hwspinlock device. diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c index 56c4303..a838dbd 100644 --- a/drivers/hwspinlock/hwspinlock_core.c +++ b/drivers/hwspinlock/hwspinlock_core.c @@ -722,7 +722,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific); * lock number is indexed relative to the hwspinlock device, unlike the * hwspin_lock_request_specific() which is an absolute lock number. * - * Returns the address of the assigned hwspinlock, or NULL on error + * Returns the address of the assigned hwspinlock, or an equivalent + * ERR_PTR() on error */ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np, const char *propname, @@ -736,7 +737,7 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np, ret = of_parse_phandle_with_args(np, propname, #hwlock-cells, index, args); if (ret) - return NULL; + return ERR_PTR(ret); mutex_lock(hwspinlock_tree_lock); list_for_each_entry(bank, hwspinlock_devices, list) @@ -744,11 +745,11 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np, break; mutex_unlock(hwspinlock_tree_lock); if (bank-list == hwspinlock_devices) - return NULL; + return ERR_PTR(-EPROBE_DEFER); id = bank-ops-of_xlate(bank, args); if (id 0 || id = bank-num_locks) - return NULL; + return ERR_PTR(-EINVAL); id += bank-base_id; return hwspin_lock_request_specific(id); -- 1.9.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
[PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx
HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC device families as well. The IPs are identical to that of OMAP4/OMAP5, except for the number of locks. Add a depends on to the above family of SoCs to enable the build support for OMAP hwspinlock driver for any of the above SoC configs. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/hwspinlock/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig index 70637d2..3612cb5 100644 --- a/drivers/hwspinlock/Kconfig +++ b/drivers/hwspinlock/Kconfig @@ -10,7 +10,7 @@ menu Hardware Spinlock drivers config HWSPINLOCK_OMAP tristate OMAP Hardware Spinlock device - depends on ARCH_OMAP4 || SOC_OMAP5 + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX select HWSPINLOCK help Say y here to support the OMAP Hardware Spinlock device (firstly -- 1.9.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
[PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks
Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 37 +++-
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 4be1664..ed47e77 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -336,29 +336,33 @@ out:
return 0;
}
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
{
- struct hwspinlock *hwlock = NULL;
- int ret;
+ struct hwspinlock *tmp = NULL;
+ int ret = 0;
mutex_lock(hwspinlock_tree_lock);
/* make sure the hwspinlock is not in use (tag is set) */
- ret = radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
- if (ret == 0) {
+ if (!radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
pr_err(hwspinlock %d still in use (or not present)\n, id);
+ ret = -EBUSY;
goto out;
}
- hwlock = radix_tree_delete(hwspinlock_tree, id);
- if (!hwlock) {
+ tmp = radix_tree_delete(hwspinlock_tree, id);
+ if (!tmp) {
pr_err(failed to delete hwspinlock %d\n, id);
+ ret = -EIO;
goto out;
}
+ /* self-sanity check that should never fail */
+ WARN_ON(tmp != hwlock);
+
out:
mutex_unlock(hwspinlock_tree_lock);
- return hwlock;
+ return ret;
}
/**
@@ -472,8 +476,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
return 0;
reg_failed:
- while (--i = 0)
- hwspin_lock_unregister_single(base_id + i);
+ while (--i = 0) {
+ hwlock = bank-lock[i];
+ hwspin_lock_unregister_single(hwlock, base_id + i);
+ }
mutex_lock(hwspinlock_tree_lock);
list_del(bank-list);
mutex_unlock(hwspinlock_tree_lock);
@@ -494,18 +500,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
*/
int hwspin_lock_unregister(struct hwspinlock_device *bank)
{
- struct hwspinlock *hwlock, *tmp;
- int i;
+ struct hwspinlock *hwlock;
+ int i, ret;
for (i = 0; i bank-num_locks; i++) {
hwlock = bank-lock[i];
- tmp = hwspin_lock_unregister_single(bank-base_id + i);
- if (!tmp)
+ ret = hwspin_lock_unregister_single(hwlock, bank-base_id + i);
+ if (ret)
return -EBUSY;
-
- /* self-sanity check that should never fail */
- WARN_ON(tmp != hwlock);
}
mutex_lock(hwspinlock_tree_lock);
--
1.9.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
[PATCHv5 RFC 11/15] hwspinlock/core: add support for reserved locks
The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.
The HwSpinlock core has been enhanced to:
1. allow the platform implementations to register a set of 'reserved'
locks
2. restrict the anonymous hwspin_lock_request() API to allocate only
from non-reserved locks
3. limit these reserved locks to be allocated only using the
_request_specific() API variants.
The existing platform implementations have also been updated to adjust
for the change of the registration API.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 20
drivers/hwspinlock/hwspinlock_internal.h | 3 +++
drivers/hwspinlock/omap_hwspinlock.c | 4 ++--
drivers/hwspinlock/u8500_hsem.c | 3 ++-
include/linux/hwspinlock.h | 10 +++---
5 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..e05cea8 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -432,6 +432,8 @@ static int hwspinlock_device_add(struct hwspinlock_device
*bank)
* @ops: hwspinlock handlers for this device
* @base_id: id of the first hardware spinlock in this bank
* @num_locks: number of hwspinlocks provided by this device
+ * @num_reserved_locks: number of reserved hwspinlocks starting from @base_id
+ * on this device
*
* This function should be called from the underlying platform-specific
* implementation, to register a new hwspinlock device instance.
@@ -441,13 +443,15 @@ static int hwspinlock_device_add(struct hwspinlock_device
*bank)
* Returns 0 on success, or an appropriate error code on failure
*/
int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
- const struct hwspinlock_ops *ops, int base_id, int num_locks)
+ const struct hwspinlock_ops *ops, int base_id, int num_locks,
+ int num_reserved_locks)
{
struct hwspinlock *hwlock;
int ret = 0, i;
if (!bank || !ops || !dev || !num_locks || !ops-trylock ||
- !ops-unlock || (dev-of_node !ops-of_xlate)) {
+ !ops-unlock || (dev-of_node !ops-of_xlate) ||
+ (num_locks num_reserved_locks)) {
pr_err(invalid parameters\n);
return -EINVAL;
}
@@ -456,6 +460,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
bank-ops = ops;
bank-base_id = base_id;
bank-num_locks = num_locks;
+ bank-num_reserved_locks = num_reserved_locks;
mutex_lock(hwspinlock_tree_lock);
ret = hwspinlock_device_add(bank);
@@ -468,7 +473,8 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
- hwlock-type = HWSPINLOCK_UNUSED;
+ hwlock-type = (i num_reserved_locks ?
+ HWSPINLOCK_RESERVED : HWSPINLOCK_UNUSED);
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -651,7 +657,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned
int id)
/* sanity check (this shouldn't happen) */
WARN_ON(hwlock_to_id(hwlock) != id);
- /* make sure this hwspinlock is unused */
+ if (hwlock-type != HWSPINLOCK_RESERVED) {
+ pr_warn(hwspinlock %u is not a reserved lock\n, id);
+ hwlock = NULL;
+ goto out;
+ }
+
+ /* make sure this hwspinlock is an unused reserved lock */
ret = radix_tree_tag_get(hwspinlock_tree, id, hwlock-type);
if (ret == 0) {
pr_warn(hwspinlock %u is already in use\n, id);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h
b/drivers/hwspinlock/hwspinlock_internal.h
index 1be32ca..570e876 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -64,6 +64,8 @@ struct hwspinlock {
* @ops: platform-specific hwspinlock handlers
* @base_id: id index of the first lock in this device
* @num_locks: number of locks in this device
+ * @num_reserved_locks: number of reserved locks in this device starting
+ * from @base_id
* @lock: dynamically allocated array of 'struct hwspinlock'
*/
struct hwspinlock_device {
@@ -72,6 +74,7 @@ struct hwspinlock_device {
const struct hwspinlock_ops *ops;
int base_id;
int num_locks;
+ int num_reserved_locks;
struct hwspinlock lock[0];
};
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 7764291..1d0c78e 100644
---
[PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/omap_hwspinlock.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
if (!io_base)
return -ENOMEM;
+ /*
+* make sure the module is enabled and clocked before reading
+* the module SYSSTATUS register
+*/
+ pm_runtime_enable(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (ret 0) {
+ pm_runtime_put_noidle(pdev-dev);
+ goto iounmap_base;
+ }
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i = SPINLOCK_NUMLOCKS_BIT_OFFSET;
+ /*
+* runtime PM will make sure the clock of this module is
+* enabled again iff at least one lock is requested
+*/
+ ret = pm_runtime_put_sync(pdev-dev);
+ if (ret 0)
+ goto iounmap_base;
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i 0xf) != 1 || i 8) {
ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = bank-lock[0]; i num_locks; i++, hwlock++)
hwlock-priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
- /*
-* runtime PM will make sure the clock of this module is
-* enabled iff at least one lock is requested
-*/
- pm_runtime_enable(pdev-dev);
-
ret = hwspin_lock_register(bank, pdev-dev, omap_hwspinlock_ops,
base_id, num_locks);
if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
return 0;
reg_fail:
- pm_runtime_disable(pdev-dev);
kfree(bank);
iounmap_base:
+ pm_runtime_disable(pdev-dev);
iounmap(io_base);
return ret;
}
--
1.9.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
[PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
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.
Hwlock Users:
=
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 3966c0c..4be1664 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -264,6 +264,27 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
EXPORT_SYMBOL_GPL(__hwspin_unlock);
/**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, or an appropriate error code
+ * as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+ unsigned int val;
+ int ret;
+
+ ret = of_property_read_u32(dn, hwlock-base-id, val);
+ return ret ? ret : val;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
+
+/**
* 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 068e628..4857728 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -64,6 +64,7 @@ struct hwspinlock_pdata {
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 hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
const struct hwspinlock_ops *ops, int base_id, int num_locks);
--
1.9.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
[PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.
Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 52 ++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells: Specifies the number of cells needed to represent a
+ specific lock.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0 3;
+ ...
+ };
--
1.9.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
[PATCHv5 04/15] hwspinlock/core: add common OF helpers
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common helper
function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a simple default
translator function for hwspinlock provider implementations
that use a single cell number for requesting a specific lock
(relatively indexed) within a hwlock bank.
3. The of_hwspin_lock_request_specific() API can be used by
hwspinlock clients to request a specific lock using the
phandle + args specifier. This function relies on the
implementation providing back a relative hwlock id within
the bank from the args specifier.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 34 ++-
drivers/hwspinlock/hwspinlock_core.c | 100 ++-
drivers/hwspinlock/hwspinlock_internal.h | 4 ++
include/linux/hwspinlock.h | 22 ++-
4 files changed, 155 insertions(+), 5 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..903d477 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,15 @@ independent, drivers.
ids for predefined purposes.
Should be called from a process context (might sleep).
+ struct hwspinlock *of_hwspin_lock_request_specific(
+ struct device_node *np, const char *propname, int index);
+ - assign a specific hwspinlock id and return its address, or NULL
+ if that hwspinlock is already in use. This function is the OF
+ equivalent of hwspin_lock_request_specific() function, and provides
+ a means for users of the hwspinlock module to request a specific
+ hwspinlock using the phandle of the hwspinlock device.
+ Should be called from a process context (might sleep).
+
int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +252,23 @@ int hwspinlock_example2(void)
Returns the address of hwspinlock on success, or NULL on error (e.g.
if the hwspinlock is still in use).
+ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+ const struct of_phandle_args *hwlock_spec);
+ - is a simple default OF translate helper function that can be plugged in
+ as the underlying vendor-specific implementation's of_xlate ops function.
+ This can be used by implementations that use a single integer argument in
+ the DT node argument specifier, that indicates the hwlock index number.
+ Returns a hwlock index within a bank, or appropriate error code on
+ failure.
+
+ int of_hwspin_lock_get_num_locks(struct device_node *dn);
+ - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the number of locks supported within a hwspinlock
+ bank as a device tree node property. This function should be called by
+ needed implementations before registering a hwspinlock device with the
+ core.
+
5. Important structs
struct hwspinlock_device is a device which usually contains a bank
@@ -288,12 +314,14 @@ initialized by the hwspinlock core itself.
6. Implementation callbacks
-There are three possible callbacks defined in 'struct hwspinlock_ops':
+There are four possible callbacks defined in 'struct hwspinlock_ops':
struct hwspinlock_ops {
int (*trylock)(struct hwspinlock *lock);
void (*unlock)(struct hwspinlock *lock);
void (*relax)(struct hwspinlock *lock);
+ int (*of_xlate)(struct hwspinlock_device *bank,
+ const struct of_phandle_args *hwlock_spec);
};
The first two callbacks are mandatory:
@@ -307,3 +335,7 @@ may _not_ sleep.
The -relax() callback is optional. It is called by hwspinlock core while
spinning on a lock, and can be used by the underlying implementation to force
a delay between two successive invocations of -trylock(). It may _not_ sleep.
+
+The -of_xlate() callback is mandatory to support requesting hwlocks through
+device-tree nodes. It is called by hwspinlock core to retrieve the relative
+lock index within a bank from the underlying implementation.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..3966c0c 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock);
+/**
[PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.
The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 2 ++
drivers/hwspinlock/hwspinlock_core.c | 51
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
3 files changed, 55 insertions(+)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
/**
* struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
* @dev: underlying device, will be used to invoke runtime PM api
* @ops: platform-specific hwspinlock handlers
* @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
* @lock: dynamically allocated array of 'struct hwspinlock'
*/
struct hwspinlock_device {
+ struct list_head list;
struct device *dev;
const struct hwspinlock_ops *ops;
int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
*/
static DEFINE_MUTEX(hwspinlock_tree_lock);
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
/**
* __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
return hwlock;
}
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+ struct list_head *entry = hwspinlock_devices;
+ struct hwspinlock_device *_bank;
+ int ret = 0;
+
+ list_for_each(entry, hwspinlock_devices) {
+ _bank = list_entry(entry, struct hwspinlock_device, list);
+ if (_bank-base_id = bank-base_id + bank-num_locks)
+ break;
+ }
+
+ if (entry != hwspinlock_devices
+ entry-prev != hwspinlock_devices) {
+ _bank = list_entry(entry-prev, struct hwspinlock_device, list);
+ if (_bank-base_id + _bank-num_locks bank-base_id) {
+ dev_err(bank-dev, hwlock space overlap, cannot add
device\n);
+ ret = -EBUSY;
+ }
+ }
+
+ if (!ret)
+ list_add_tail(bank-list, entry);
+
+ return ret;
+}
+
/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
bank-base_id = base_id;
bank-num_locks = num_locks;
+ mutex_lock(hwspinlock_tree_lock);
+ ret = hwspinlock_device_add(bank);
+ mutex_unlock(hwspinlock_tree_lock);
+ if (ret)
+ return ret;
+
for (i = 0; i num_locks; i++) {
hwlock = bank-lock[i];
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
reg_failed:
while (--i = 0)
hwspin_lock_unregister_single(base_id + i);
+ mutex_lock(hwspinlock_tree_lock);
+ list_del(bank-list);
+ mutex_unlock(hwspinlock_tree_lock);
return ret;
}
EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
WARN_ON(tmp != hwlock);
}
+ mutex_lock(hwspinlock_tree_lock);
+
[PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren t...@atomide.com
---
MAINTAINERS | 1 -
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
drivers/hwspinlock/omap_hwspinlock.c | 18 ---
4 files changed, 14 insertions(+), 68 deletions(-)
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..5147902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,7 +6355,6 @@ M:Ohad Ben-Cohen o...@wizery.com
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
OMAP MMC SUPPORT
M: Jarkko Lavinen jarkko.lavi...@nokia.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38..9f4b6dd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -289,9 +289,6 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que s...@ti.com
- * Hari Kanigeri h-kanige...@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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/err.h
-#include linux/hwspinlock.h
-
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = spinlock;
- const char *dev_name = omap_hwspinlock;
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err(Can't build omap_device for %s:%s\n, dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..9f56fb2 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que s...@ti.com
* Hari Kanigeri h-kanige...@ti.com
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/spinlock.h
#include linux/hwspinlock.h
+#include linux/of_device.h
#include linux/platform_device.h
#include hwspinlock_internal.h
@@ -76,18 +77,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
.trylock = omap_hwspinlock_trylock,
.unlock = omap_hwspinlock_unlock,
.relax = omap_hwspinlock_relax,
+ .of_xlate = of_hwspin_lock_simple_xlate,
};
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node *node =
[PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be ti,omap4-hwspinlock for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells: Should be 1. The OMAP hwspinlock users will use a
+ 0-indexed relative hwlock number as the argument
+ specifier value for requesting a specific hwspinlock
+ within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ #hwlock-cells = 1;
+};
--
1.9.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
[PATCHv5 00/15] hwspinlock/omap dt support
Hi Ohad, This is a refresh/update of the hwspinlock dt support series. The series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to handle various discussion points arised on v4. Following are the main changes in v5: - Base DT patches (Patches 1 to 7, except for 4) are identical to v4. Patch4 is updated to remove some traces and fix --strict checkpatch warnings. - Patch 8 brings back the DT-based hwlock-base-id property, for registration purposes. Based on v4 discussion [1]. - Patches 9 through 13 introduce the concept of reserved locks, again based on the discussion in v4 [1]. The approach taken here is simplistic, each hwlock is assigned a type attribute during registration, with the _request_ apis honoring the lock type attribute. - Staged patches 14 15 for converting return convention to better support deferred probing of client drivers. I do think that it is still a good idea to return ERR_PTRs (unconcluded discussion in v4 [2]). The main advantage is to support deferred probing for DT boots. The original argument/change for returning NULL pointers pre-dates both the deferred driver probe mechanism and DT-based boot, so it may be moot on the current kernel. I have marked the new patches as RFC, and should ideally be dealt with as a separate series. I have added these to this series as they also add couple of DT-based properties, as well as maintain the discussion context from the previous series. I am ok for the reserved lock patches to be left out for 3.16 merge window if these patches still need some work. I am hoping to have the first 7 or 8 patches (and finalized return code changes) to make it to 3.16. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://slexy.org/view/s2MMyLZTiH OMAP5 - http://slexy.org/view/s20U2ElygK DRA74x - http://slexy.org/view/s20fAoWJ84 AM33xx - http://slexy.org/view/s2HLj2b406 AM43xx - http://slexy.org/view/s2JNrJSWLm The above logs are generated with some additional test patches staged here for reference (not for merging) https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5 https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5-test regards Suman [1] http://marc.info/?l=linux-omapm=139510004009415w=2 [2] http://marc.info/?l=linux-omapm=139490475424338w=2 --- v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells - Fixed a registration issue with repeated module installation and removal. - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions. The OMAP adaptation patch is updated to use the default translate function - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. - Added build support for AM335x, AM43xx and DRA7xx http://marc.info/?l=linux-omapm=138965904015225w=2 v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omapm=138143992932197w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 --- Suman Anna (15): Documentation: dt: add common bindings for hwspinlock Documentation: dt: add the omap hwspinlock bindings document hwspinlock/core: maintain a list of registered hwspinlock banks hwspinlock/core: add common OF helpers hwspinlock/omap: add support for dt nodes hwspinlock/omap: enable module before reading SYSSTATUS register hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx hwspinlock/core: add support for base id in DT hwspinlock/core: prepare unregister code to support reserved locks hwspinlock/core: prepare core to support reserved locks hwspinlock/core: add support for reserved locks hwspinlock/core: add OF helper to parse reserved locks hwspinlock/omap: use OF helper to get reserved locks hwspinlock/core: return ERR_PTRs on failure in _request_ api hwspinlock/core: change return codes of_hwspin_lock_request_specific .../devicetree/bindings/hwlock/hwlock.txt | 61 + .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++ Documentation/hwspinlock.txt | 48 +++- MAINTAINERS| 1 -
Re: [patch V2 0/6] dma: edma: Provide granular residue accounting
On Wed, Apr 30, 2014 at 12:08 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, Apr 29, 2014 at 11:25:02PM -0500, Joel Fernandes wrote: On 04/29/2014 03:46 AM, Vinod Koul wrote: [..] commit 770f0f3a20188b7e17db2790803b9da925dc0b94 Author: Thomas Gleixner t...@linutronix.de Date: Mon Apr 28 10:49:43 2014 + dmaengine: edma: Make reading the position of active channels work As Joel pointed out, edma_read_position() uses memcpy_fromio() to read the parameter ram. That's not synchronized with the internal update as it does a byte by byte copy. We need to do a 32bit read to get a consistent value. Further reading destination and source is pointless. In DEV_TO_MEM transfers we are only interested in the destination, in MEM_TO_DEV we care about the source. In MEM_TO_MEM it really does not matter which one you read. Simple solution: Remove the pointers, select dest/source via a bool and return the read value. Remove the export of this function while at it. The only potential user is the dmaengine and that's always builtin. Signed-off-by: Thomas Gleixner t...@linutronix.de You s-o-b missing in this one, also ack from Sekhar missing. Do you want to redo this or prefer me to cherry-pick patches adding acks and your s-o-b, since I already fetched your branch Either way is fine with me... If its Ok with you, it would great if you could add my Ack and Sob. Thanks a lot. Let me know if you'd want me to do anything else here. Done, The changes are getting pushed, pls do verify Sorry for the late reply as I'm at a conference. Thanks, I verified and it looks OK. Regards, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
