RE: [PATCH v6 1/4] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
Hi All, So, based on feedbacks from everyone, I could come to following conclusions. Please confirm, if those are acceptable ? From: Mark Rutland [mailto:mark.rutl...@arm.com] On Thu, Sep 26, 2013 at 11:54:39AM +0100, Gupta, Pekon wrote: From: Rob Herring [mailto:robherri...@gmail.com] From: Pekon Gupta [mailto:pe...@ti.com] diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index df338cb..958e5d5 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -21,11 +21,8 @@ Optional properties: is wired that way. If not specified, a bus width of 8 is assumed. - - ti,nand-ecc-opt:A string setting the ECC layout to use. One of: - - swSoftware method (default) - hwHardware method - hw-romcodegpmc hamming mode method romcode layout + - ti,nand-ecc-scheme: A string setting the ECC layout to use. One of: + ham1 1-bit Hamming ecc code As has been pointed out, this breaks compatibility which should be avoided unless you know the state of use of this binding. I fail to see the advantage of using scheme over opt. You could simply add ham1 here and maintain compatibility. Instead of removing sw, hw, etc. you can simply deprecate them or decide that the kernel doesn't support those options. Renaming 'ti,nand-ecc-opt' to 'ti,nand-ecc-scheme' was as per earlier comments from Olof. So either way is fine with me. Should I revert it back to 'ti,nand-ecc-opt' ? I think that if the binding is already in use then we shouldn't break it, unless you're _definitely_ the only user. Agreed, would revert back to 'ti,nand-ecc-scheme' Also, sw, hw_romcode have been deprecated, they are no longer supported in driver. So shouldn't they be removed from the documentation ? Deprecated properties should be marked as deprecated, but continue to be documented. That at least prevents the names being repurposed in an incompatible way, and explains to anyone who looks at the document that the proeprty is deprecated rather than simply undocumented. Agreed. - keep existing values in documentation (sw, hw, hw_romcode) but mark them as deprecated. - add new values (ham1, bch4, bch8,..) However, since you are willing to break compatibility, then you should the generic NAND binding and use nand-ecc-mode adding the values you need. Documentation/devicetree/bindings/mtd/nand.txt: * MTD generic binding - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. Yes I can use generic 'nand-ecc-mode', But the binding values like soft, hw, soft_bch are too generic to describe the hardware. - BCH ECC scheme can itself be of multiple types, bch4/bch8/bch16 so soft_bch is ambiguous. It does indeed seem like the generic properties are not generic enough, at least from my quick look other them. However, I am not familiar with NAND, so I may have misunderstood. Would not use generic 'nand-ecc-mode' property, instead continue with 'ti,nand-ecc-opt'. - Similarly soft and hw do not determine the algorithm used like Hamming or BCH. (a) Should I update the generic binding values (if no one else is using) ? like sw - ham1_sw hw - ham1_hw soft_bch- soft_bch4, soft_bch8 What do the current property names actually correspond to logically? If we did this and there are existing users, the old DTs need to continue functioning. OR (b) Should I add newer ones to it (like ham1, bch4, bch8, bch16) ? keeping the old ones intact. And how should I handle un-supported values, (Is pr_err during kernel probe enough ?). I think something like this, but with the names from (a) would be preferrable. As Brian pointed, implementation of ecc-scheme can be very different from vendor to vendor, and even SoC to SoC within same vendor, Thus its difficult to generalize as common DT binding for everyone. - Even if we try to do, there would be too many values, out of which only selectable would be applicable for a given SoC. - And some platforms might need extra DT information to get driver working, because h/w was designed that way. So it would be mess. So, its better not to have a generic ecc-scheme binding, instead let every vendor define it specifically. So for TI OMAP NAND driver, I'm continuing to use 'ti,nand-ecc-opt' as described above. Is this acceptable ? [...] - - elm_id: Specifies elm device node. This is required to support BCH -
[PATCH v12 3/7] usb: phy: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed. Also twl4030-usb driver is moved
to drivers/phy/.
However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/phy/Kconfig | 11 ++
drivers/phy/Makefile|1 +
drivers/{usb = }/phy/phy-twl4030-usb.c | 56 +--
drivers/usb/phy/Kconfig | 10 --
drivers/usb/phy/Makefile|1 -
include/linux/i2c/twl.h |2 ++
6 files changed, 67 insertions(+), 14 deletions(-)
rename drivers/{usb = }/phy/phy-twl4030-usb.c (95%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 38c3477..ac239ac 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,4 +27,15 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config TWL4030_USB
+ tristate TWL4030 USB Transceiver Driver
+ depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS
+ select GENERIC_PHY
+ select USB_PHY
+ help
+ Enable this to support the USB OTG transceiver on TWL4030
+ family chips (including the TWL5030 and TPS659x0 devices).
+ This transceiver supports high and full speed devices plus,
+ in host mode, low speed.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index ed5b088..0dd8a98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
similarity index 95%
rename from drivers/usb/phy/phy-twl4030-usb.c
rename to drivers/phy/phy-twl4030-usb.c
index 90730c8..d02913f 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/usb/otg.h
+#include linux/phy/phy.h
#include linux/usb/musb-omap.h
#include linux/usb/ulpi.h
#include linux/i2c/twl.h
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl,
int controller_off)
dev_dbg(twl-dev, %s\n, __func__);
}
+static int twl4030_phy_power_off(struct phy *phy)
+{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+ twl4030_phy_suspend(twl, 0);
+ return 0;
+}
+
static void __twl4030_phy_resume(struct twl4030_usb *twl)
{
twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
}
}
+static int twl4030_phy_power_on(struct phy *phy)
+{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+ twl4030_phy_resume(twl);
+ return 0;
+}
+
static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
{
/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
status = twl4030_usb_linkstat(twl);
twl-linkstat = status;
- if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+ if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl-linkstat);
+ twl4030_phy_resume(twl);
+ }
sysfs_notify(twl-dev-kobj, NULL, vbus);
return 0;
}
+static int twl4030_phy_init(struct phy *phy)
+{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+ return twl4030_usb_phy_init(twl-phy);
+}
+
static int twl4030_set_suspend(struct usb_phy *x, int suspend)
{
struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,23 @@ static int twl4030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static const struct phy_ops ops = {
+ .init = twl4030_phy_init,
+ .power_on = twl4030_phy_power_on,
+ .power_off = twl4030_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
static int twl4030_usb_probe(struct platform_device *pdev)
{
struct twl4030_usb_data *pdata = dev_get_platdata(pdev-dev);
struct twl4030_usb *twl;
+ struct phy *phy;
int status, err;
struct usb_otg *otg;
struct device_node *np = pdev-dev.of_node;
+ struct phy_provider *phy_provider;
+ struct phy_init_data
[PATCH v12 0/7] PHY framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing I'll create a new branch *next* once this patch series is finalized. All the PHY driver development that depends on PHY framework can be based on this branch. Did USB enumeration testing in panda and beagle after applying [1] (needed for non-dt) Changes from v11: * rebased to 3.12-rc2 * dropped usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 patch. It will be added in the patch series that adapts dwc3 to generic phy framework. * Fixed checkpatch warning that shows up newly for having extern in header file. Changes from v10: * fixed a mistake in devm_of_phy_provider_register macro which was carried over from earlier version. * used ida_simple_get for obtaining the id. Changes from v9: * Fixed Greg's concern on having *find PHY by string* and changed it to Tomasz pseudo code. * move omap-usb2 phy and twl4030-usb phy to drivers/phy * made all the dependent drivers select GENERIC_PHY instead of having depends on * Made PHY core to assign the id's (so changed the phy_create API). * Adapted twl4030-usb to the new design. Changes from v8: * Added phy_set_drvdata and phy_get_drvdata in phy.h. * Changed phy_create API not to take void *priv. private data should now be set using phy_set_drvdata now. Changes from v7: * Fixed Documentation * Added to_phy, of_phy_provider_register and devm_of_phy_provider_register * modified runtime_pm usage in phy_init, phy_exit, phy_power_on and phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will disable the clocks. * pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail * modified other patches to adhere to the changes in the PHY framework * removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will be merged separately. * reference counting has been added to protect phy ops when the PHY is shared by multiple consumers. Changes from v6 * corrected few typos in Documentation * Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when PHY Subsystem is kept as module and the dependent modules are built-in) * Added if pm_runtime_enabled check before runtime pm calls. Changes from v5: * removed the new sysfs entries as it dint have any new information other than what is already there in /sys/devices/... * removed a bunch of APIs added to get the PHY and now only phy_get and devm_phy_get are used. * Added new APIs to register/unregister the PHY provider. This is needed for dt boot case. * Enabled pm runtime and incorporated the comments given by Alan Stern in a different patch series by Gautam. * Removed the *phy_bind* API. Now the phy binding information should be passed using the platform data to the controller devices. * Fixed a few typos. Changes from v4: * removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers* should use their custom implementation of of_xlate or use of_phy_xlate to get *phy instance* from *phy providers*. * Added of_phy_xlate to be used by *phy providers* if it provides only one PHY. * changed phy_core from having subsys_initcall to module_init. * other minor fixes. Changes from v3: * Changed the return value of PHY APIs to ENOSYS * Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting PHYs if the same IP implements multiple PHYs. * modified phy_bind API so that the binding information can now be _updated_. In effect of this removed the binding information added in board files and added only in usb-musb.c. If a particular board uses a different phy binding, it can update it in board file after usb_musb_init(). * Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding information. Changes from v2: * removed phy_descriptor structure completely so changed the APIs which were taking phy_descriptor as parameters * Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used by PHY user drivers which has *phy* and *phy-names* binding in the dt data * Fixed a few typos * Removed phy_list and
[PATCH v12 7/7] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops
Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/phy/phy-twl4030-usb.c | 57 ++---
1 file changed, 13 insertions(+), 44 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index d02913f..e0212d8 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl,
int on)
}
}
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
if (twl-asleep)
- return;
+ return 0;
twl4030_phy_power(twl, 0);
twl-asleep = 1;
dev_dbg(twl-dev, %s\n, __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
- struct twl4030_usb *twl = phy_get_drvdata(phy);
-
- twl4030_phy_suspend(twl, 0);
return 0;
}
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
{
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
twl4030_i2c_access(twl, 0);
}
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
{
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
+
if (!twl-asleep)
- return;
- __twl4030_phy_resume(twl);
+ return 0;
+ __twl4030_phy_power_on(twl);
twl-asleep = 0;
dev_dbg(twl-dev, %s\n, __func__);
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
cancel_delayed_work(twl-id_workaround_work);
schedule_delayed_work(twl-id_workaround_work, HZ);
}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
- struct twl4030_usb *twl = phy_get_drvdata(phy);
-
- twl4030_phy_resume(twl);
return 0;
}
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct
*work)
}
}
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
{
- struct twl4030_usb *twl = phy_to_twl(phy);
+ struct twl4030_usb *twl = phy_get_drvdata(phy);
enum omap_musb_vbus_id_status status;
/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
omap_musb_mailbox(twl-linkstat);
- twl4030_phy_resume(twl);
+ twl4030_phy_power_on(phy);
}
sysfs_notify(twl-dev-kobj, NULL, vbus);
return 0;
}
-static int twl4030_phy_init(struct phy *phy)
-{
- struct twl4030_usb *twl = phy_get_drvdata(phy);
-
- return twl4030_usb_phy_init(twl-phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
- struct twl4030_usb *twl = phy_to_twl(x);
-
- if (suspend)
- twl4030_phy_suspend(twl, 1);
- else
- twl4030_phy_resume(twl);
-
- return 0;
-}
-
static int twl4030_set_peripheral(struct usb_otg *otg,
struct usb_gadget *gadget)
{
@@ -719,8 +690,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.label = twl4030;
twl-phy.otg= otg;
twl-phy.type = USB_PHY_TYPE_USB2;
- twl-phy.set_suspend= twl4030_set_suspend;
- twl-phy.init = twl4030_usb_phy_init;
otg-phy= twl-phy;
otg-set_host = twl4030_set_host;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v12 5/7] ARM: dts: omap: update usb_otg_hs data
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
Documentation/devicetree/bindings/usb/usb-phy.txt |6 ++
arch/arm/boot/dts/omap3-beagle-xm.dts |2 ++
arch/arm/boot/dts/omap3-evm.dts|2 ++
arch/arm/boot/dts/omap3-overo.dtsi |2 ++
arch/arm/boot/dts/omap4.dtsi |3 +++
arch/arm/boot/dts/twl4030.dtsi |1 +
7 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 9088ab0..661cb06 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply up to
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phy* phandle.
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
num-eps = 16;
ram-bits = 12;
ctrl-module = omap_control_usb;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
};
Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be ti,omap-usb2
- reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
+ - #phy-cells: determine the number of cells that should be given in the
+ phandle while referencing this phy.
Optional properties:
- ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..8483846 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
+ phys = usb2_phy;
+ phy-names = usb2-phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
ctrl-module = omap_control_usb;
+ #phy-cells = 0;
};
};
@@ -658,6 +659,8 @@
[PATCH v12 4/7] arm: omap3: twl: add phy consumer data in twl4030_usb_data
The PHY framework uses the phy consumer data populated in platform data in the
case of non-dt boot to return the reference to the PHY when the controller
(PHY consumer) requests for it. So populated the phy consumer data in the
platform
data of twl usb.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index c05898f..b0d54da 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -24,6 +24,7 @@
#include linux/i2c/twl.h
#include linux/gpio.h
#include linux/string.h
+#include linux/phy/phy.h
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
@@ -90,8 +91,18 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
+struct phy_consumer consumers[] = {
+ PHY_CONSUMER(musb-hdrc.0, usb),
+};
+
+struct phy_init_data init_data = {
+ .consumers = consumers,
+ .num_consumers = ARRAY_SIZE(consumers),
+};
+
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
+ .init_data = init_data,
};
static int omap3_batt_table[] = {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v12 1/7] drivers: phy: add generic PHY framework
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.
PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Cc: Tomasz Figa t.f...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/phy/phy-bindings.txt | 66 ++
Documentation/phy.txt | 166 +
MAINTAINERS|8 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 18 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 698
include/linux/phy/phy.h| 270
9 files changed, 1235 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg = ...;
+.
+.
+#phy-cells = 1;
+.
+.
+};
+
+That node describes an IP block (PHY provider) that implements 2 different
PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should
be
+given while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = usb2_phy, usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = xxx;
+reg = xxx;
+.
+.
+phys = phys 1;
+phy-names = usbphy;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+1 to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..0103e4b
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,166 @@
+ PHY SUBSYSTEM
+ Kishon Vijay Abraham I kis...@ti.com
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the
[PATCH v12 2/7] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile |1 +
drivers/{usb = }/phy/phy-omap-usb2.c | 45 ++---
drivers/usb/phy/Kconfig | 11
drivers/usb/phy/Makefile |1 -
5 files changed, 54 insertions(+), 16 deletions(-)
rename drivers/{usb = }/phy/phy-omap-usb2.c (88%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 349bef2..38c3477 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,4 +15,16 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of this
framework should select this config.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on ARCH_OMAP2PLUS
+ select GENERIC_PHY
+ select USB_PHY
+ select OMAP_CONTROL_USB
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..ed5b088 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
similarity index 88%
rename from drivers/usb/phy/phy-omap-usb2.c
rename to drivers/phy/phy-omap-usb2.c
index d266861..4d7b4e5 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/usb/omap_control_usb.h
+#include linux/phy/phy.h
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -118,10 +119,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_power_off(struct phy *x)
+{
+ struct omap_usb *phy = phy_get_drvdata(x);
+
+ omap_control_usb_phy_power(phy-control_dev, 0);
+
+ return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+ struct omap_usb *phy = phy_get_drvdata(x);
+
+ omap_control_usb_phy_power(phy-control_dev, 1);
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .power_on = omap_usb_power_on,
+ .power_off = omap_usb_power_off,
+ .owner = THIS_MODULE,
+};
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
+ struct phy *generic_phy;
struct usb_otg *otg;
+ struct phy_provider *phy_provider;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -143,6 +170,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
+ phy_provider = devm_of_phy_provider_register(phy-dev,
+ of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
phy-control_dev = omap_get_control_dev();
if (IS_ERR(phy-control_dev)) {
dev_dbg(pdev-dev, Failed to get control device\n);
@@ -158,6 +190,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg-start_srp = omap_usb_start_srp;
otg-phy= phy-phy;
+ platform_set_drvdata(pdev, phy);
+ pm_runtime_enable(phy-dev);
+
+ generic_phy = devm_phy_create(phy-dev, ops, NULL);
+ if (IS_ERR(generic_phy))
+ return PTR_ERR(generic_phy);
+
+ phy_set_drvdata(generic_phy, phy);
+
phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
if (IS_ERR(phy-wkupclk)) {
dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
@@ -173,10 +214,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
usb_add_phy_dev(phy-phy);
- platform_set_drvdata(pdev, phy);
-
- pm_runtime_enable(phy-dev);
-
return 0;
}
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d5589f9..508e915 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -66,17 +66,6 @@ config
[PATCH v12 6/7] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.
musb-xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/Kconfig |1 +
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 26 --
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index c258a97..0440e28 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -75,6 +75,7 @@ config USB_MUSB_TUSB6010
config USB_MUSB_OMAP2PLUS
tristate OMAP2430 and onwards
depends on ARCH_OMAP2PLUS
+ select GENERIC_PHY
config USB_MUSB_AM35X
tristate AM35x
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 65f3917..d408a99 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include linux/usb.h
#include linux/usb/otg.h
#include linux/usb/musb.h
+#include linux/phy/phy.h
struct musb;
struct musb_hw_ep;
@@ -341,6 +342,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 59d2245..d0fc4d9 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev-parent-of_node)
+ if (dev-parent-of_node) {
+ musb-phy = devm_phy_get(dev-parent, usb2-phy);
+
+ /* We can't totally remove musb-xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
- else
+ } else {
musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-phy = devm_phy_get(dev, usb);
+ }
if (IS_ERR(musb-xceiv)) {
status = PTR_ERR(musb-xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
return -EPROBE_DEFER;
}
+ if (IS_ERR(musb-phy)) {
+ pr_err(HS USB OTG: no PHY configured\n);
+ return PTR_ERR(musb-phy);
+ }
musb-isr = omap2430_musb_interrupt;
status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
if (glue-status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
- usb_phy_init(musb-xceiv);
+ phy_init(musb-phy);
pm_runtime_put_noidle(musb-controller);
return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
del_timer_sync(musb_idle_timer);
omap2430_low_level_exit(musb);
+ phy_exit(musb-phy);
return 0;
}
@@ -638,7 +653,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
omap2430_low_level_exit(musb);
- usb_phy_set_suspend(musb-xceiv, 1);
+ phy_power_off(musb-phy);
}
return 0;
@@ -653,8 +668,7 @@ static int omap2430_runtime_resume(struct device *dev)
omap2430_low_level_init(musb);
musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
-
- usb_phy_set_suspend(musb-xceiv, 0);
+ phy_power_on(musb-phy);
}
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 2/8] usb: phy: omap-usb2: use the new generic PHY framework
Hi Greg,
On Friday 27 September 2013 12:21 AM, Greg KH wrote:
On Wed, Aug 21, 2013 at 11:16:07AM +0530, Kishon Vijay Abraham I wrote:
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
The omap-usb2 driver is also moved to driver/phy.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile |1 +
drivers/{usb = }/phy/phy-omap-usb2.c | 45
++---
drivers/usb/phy/Kconfig | 10
drivers/usb/phy/Makefile |1 -
5 files changed, 54 insertions(+), 15 deletions(-)
rename drivers/{usb = }/phy/phy-omap-usb2.c (88%)
I tried to apply this to my USB branch, but it fails.
Kishon, you were going to refresh this patch series, right? Please do,
because as-is, I can't take it.
Just sent.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: omap_hsmmc: Enable SDIO interrupt
2013/9/26 Tony Lindgren t...@atomide.com:
Hi,
* Andreas Fenkart afenk...@gmail.com [130926 01:34]:
2013/9/26 Tony Lindgren t...@atomide.com:
@@ -463,27 +469,34 @@ static void omap_hsmmc_stop_clock(struct
omap_hsmmc_host *host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
This is wrong. SDIO IRQ must not be disabled upon host initiated transfer.
see omap_hsmmc_request_done
It's what Balaji already pointed out.
+ /* no transfer running, need to signal cirq if */
+ if (host-sdio_irq_en)
+ irq_mask |= CIRQ_EN;
omap_hsmmc_request_done calls omap_hsmmc_disable_irq
imagine this case:
1. host issues transfer from host-card (e.g. get RSSI)
2. at end of this transfer, SDIO IRQ are being masked
3. card wants to reply, raises an SDIO IRQ
4. nothing happens, since in 2. SDIO IRQ are masked
I verified this with my 88W8787 card. It is a problem
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1040,8 +1053,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1556,6 +1573,43 @@ static void omap_hsmmc_init_card(struct mmc_host
*mmc, struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq_nolock(struct omap_hsmmc_host
*host,
+int enable)
+{
+ u32 irq_mask;
+
+ if (enable)
+ host-flags |= HSMMC_SDIO_IRQ_ENABLED;
+ else
+ host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
+
+ /* SDIO IRQ will be enabled as appropriate in runtime resume */
+ if (host-flags HSMMC_RUNTIME_SUSPENDED)
+ goto out;
Not sure here, will the module still come out of suspend even with
SDIO IRQ disabled?
Otherwise nak, sdio irq must enabled independent of pm runtime state. In the
worst case need pm_runtime_get().
Well this handling is similar to what's done in sdhci.c and
seems to work for me for off-idle on 3730. In that case the
whole MMC block is powered off and the wake up follows the
dedicated io chain path. For the am33xx off-idle case, the
wake-up path would be remuxed to the GPIO in the first GPIO
bank that's always on, so again the whole MMC block is off.
Something like this but shorter as a comment:
/*
* Must not touch registers while fclk if off, otherwise SIGBUS.
* Card will still wake up upon SDIO IRQ, and we'll complete
* the request in pm_runtime_resume
*/
Another interpretation of your code could be:
/* Sorry I'm having Siesta right now, try later */
Maybe try to test this with your case with some additional
patches?
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1608,7 +1662,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
.init_card = omap_hsmmc_init_card,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
What about am335x, if this patch goes in, it will break that platform.
quirk flag via device tree?
I think it should still work, except the wake-up won't work for
the off-idle
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/27/2013 01:18 AM, Stephen Warren wrote: On 09/24/2013 01:58 AM, Javier Martinez Canillas wrote: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. FWIW, the concept of this patch, Acked-by: Stephen Warren swar...@nvidia.com I didn't review the code; just skimmed it to see where the new functionality was implemented. Thanks Stephen, I split the changes as suggested by Tony and posted as a patch-set and not an RFC anymore: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately [1] [PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ [2] Linus, Could you please add Stephen Acked-by when taking the patches and also George Cherian Tested-by that sent for this RFC. George it would be great if you can also comment on which OMAP platform you had tested. I cc'ed Aaro Koskinen and Paul Walmsley now which seems to have OMAP1 platforms to test. Could you please test [1] and [2] on a OMAP1 board? These patches solves a long standing issue we have on OMAP2+ when booting with DT and it would be great if you can check that it does not cause regressions on OMAP1 based boards. Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2937351/ [2]: https://patchwork.kernel.org/patch/2937371/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 9/27/2013 5:58 AM, Joel Fernandes wrote: On 09/26/2013 06:13 PM, Olof Johansson wrote: On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. Sorry about this. :-( This is indeed v6. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. When I started looking at EDMA in June, I noticed that a lot had already been merged. EDMA DMA Engine driver itself was merged last year, no worries there. but the long pending list of fixes to be made to the driver had to written and rewritten multiple times which took a long time. Due to this, the EDMA device tree entries could not be merged in fear that doing so would cause problems such as MMC/SD corruption etc. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) Thank you! :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? I think a little on both sides can be improved. For TI, a bit more work toward explaining patches better in change logs so that maintainers understand and are willing to help to get the code upstream would help. A lot of improvement to internal policies have been made for developing on upstream, and that's certainly a good thing but there's still more room for improvement. For maintainers, EDMA code would have been kept breathing all these months (atleast 8 months) if those temporary fixes mentioned above would have been merged into the kernel instead of not applied. With those fixes in place, dts could have been enabled and EDMA would be fully working all these months. This would have certainly made things a lot easier. Rewriting stuff the right way is OK but if it is a _lot_ of effort, then to keep things alive, merging stuff for now specially if they are one-liners could be made acceptable. Joel, can you give a link to the one-liner temporary fix that was was not merged? I am unable to put it in context. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe 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: dts: dra7-evm: Add mmc2 node for eMMC support
On 9/25/2013 9:47 PM, Balaji T K wrote:
On Tuesday 24 September 2013 03:11 PM, Benoit Cousson wrote:
+ Sekhar
Hi Balaji,
On 26/08/2013 15:53, Balaji T K wrote:
Add mmc2 dt node to dra7-evm board
and model eMMC vcc as fixed regulator.
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts
b/arch/arm/boot/dts/dra7-evm.dts
index a59bbd0..2062724 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,13 @@
device_type = memory;
reg = 0x8000 0x6000; /* 1536 MB */
};
+
+mmc2_3v3: fixedregulator-mmc2 {
+compatible = regulator-fixed;
+regulator-name = mmc2_3v3;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+};
};
dra7_pmx_core {
@@ -257,3 +264,10 @@
vmmc-supply = ldo1_reg;
bus-width = 4;
};
+
+mmc2 {
+status = okay;
+vmmc-supply = mmc2_3v3;
+bus-width = 8;
+ti,non-removable;
Sekhar just posted a series to replace that with a non-TI attribute:
non-removable.
I'm not sure if this got merged, but it might be good to use the
standard attribute instead.
Hi Benoit,
Those patches are not merged yet, standard attribute is good, but few
cleanups are needed
before ti,non-removable can be replaced by standard non-removable,
no_regulator_off_init flag set under ti,non-removable is needed to
detect eMMC
during boot on OMAP4 devices to keep regulator ON during init. Given
that eMMC on dra7-evm
is powered by always ON regulator, ti,non-removable and standard
attribute will behave same
way. Let me know if you want to remove ti,non-removable attribute from
this patch.
I dont think its an issue if ti,non-removable and non-removable behave
exactly the same. In fact, it will be confusing if they behave differently.
I understand there is a need to clean-up the code around
no_regulator_off_init, but I am hoping that can be kept separate from
moving to a generic binding. The two clean-ups can be done independent
of each other.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/51] DMA mask changes
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote: 2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks [PATCH 14/51] DMA-API: net: b43: (...) [PATCH 15/51] DMA-API: net: b43legacy: (...) ;) I believe Joe has some nice script for doing it that way. When fixing some coding style / formatting, he sends only related patches to the given ML. If I did that, then the mailing lists would not get the first patch, because almost none of the lists would be referred to by patch 1. Moreover, people complain when they don't have access to the full patch series - they assume patches are missing for some reason, and they ask for the rest of the series. -- To unsubscribe from this list: send the line unsubscribe 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: Odd behavior with dpll4_m4x2_ck on omap3 + DT
On 13/09/13 14:34, Kristo, Tero wrote: On 09/13/2013 10:51 AM, Stefan Roese wrote: On 11.09.2013 09:21, Tomi Valkeinen wrote: On 10/09/13 16:17, Tero Kristo wrote: In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) rate = parent_rate; else rate = parent_rate * 2; + return rate; } Stefan, are you able to test the above? I'd rather have a proper fix for this, than hack omapdss =). Okay, I finally found some time to test this. The patch above generates this warning: arch/arm/mach-omap2/dpll3xxx.c: In function 'omap3_clkoutx2_recalc': arch/arm/mach-omap2/dpll3xxx.c:663:6: warning: passing argument 1 of '__clk_get_rate' from incompatible pointer type [enabled by default] include/linux/clk-provider.h:423:15: note: expected 'struct clk *' but argument is of type 'struct clk_hw_omap *' Yea sorry about that, I just quickly hacked the patch together without testing it at all. :P I then changed it (not 100% sure if correctly) to this version: + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk-hw.clk)) And this seems to work. At least the clock rate mismatch warning does not appear with this patch applied (and without the clk_enable) in the bootlog any more. Yea, looks good to me, however I guess I would like second opinion on this also. Tero, can you queue this patch? Or who should handle this? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 9/27/2013 5:58 AM, Joel Fernandes wrote: On 09/26/2013 06:13 PM, Olof Johansson wrote: On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. Sorry about this. :-( This is indeed v6. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. When I started looking at EDMA in June, I noticed that a lot had already been merged. EDMA DMA Engine driver itself was merged last year, no worries there. but the long pending list of fixes to be made to the driver had to written and rewritten multiple times which took a long time. Due to this, the EDMA device tree entries could not be merged in fear that doing so would cause problems such as MMC/SD corruption etc. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) Thank you! :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? I think a little on both sides can be improved. Since we are in lessons learnt mode, I think as developers we need to learn to prioritize fixes over other features we are working on. I went back to the chronology of this patch series. 22nd July 2013: v2 posted 29th July 2013: Discussion on whether the patch can wait till *v3.12* merge window. 29th July 2013: comments given on v2 22nd Aug 2013: Pull request's sent by Sekhar for v3.12 24th Aug 2013: another v2 posted (all comments given earlier not addressed, received some comments on build warnings) 27th Aug 2013: another v3 posted (all comments given on 29th July not addressed) 10th Sept 2013: another v3 posted (all comments given on 29th July not addressed) [some discussion on comments and why this cannot wait until v3.13] 17th Sept 2013: Final version ready for merge posted. 26th Sept 2013: Another v3 posted, this time for Olof to send into v3.12-rc See, early on, the patch was actually in consideration for v3.12 merge. The barrier of entry into -rc cycle is pretty high. So if you have an opportunity to hit a merge window, utilize that by prioritizing this work over anything else you may be doing. I know you got busy with adding support for SG lists and all, but clearly this patch is critical in your mind. Plus the comments were not tough to fix. There is a need to keep looking at what provides the
Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
On 09/27/2013 11:41 AM, Tomi Valkeinen wrote: On 13/09/13 14:34, Kristo, Tero wrote: On 09/13/2013 10:51 AM, Stefan Roese wrote: On 11.09.2013 09:21, Tomi Valkeinen wrote: On 10/09/13 16:17, Tero Kristo wrote: In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) rate = parent_rate; else rate = parent_rate * 2; + return rate; } Stefan, are you able to test the above? I'd rather have a proper fix for this, than hack omapdss =). Okay, I finally found some time to test this. The patch above generates this warning: arch/arm/mach-omap2/dpll3xxx.c: In function 'omap3_clkoutx2_recalc': arch/arm/mach-omap2/dpll3xxx.c:663:6: warning: passing argument 1 of '__clk_get_rate' from incompatible pointer type [enabled by default] include/linux/clk-provider.h:423:15: note: expected 'struct clk *' but argument is of type 'struct clk_hw_omap *' Yea sorry about that, I just quickly hacked the patch together without testing it at all. :P I then changed it (not 100% sure if correctly) to this version: + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk-hw.clk)) And this seems to work. At least the clock rate mismatch warning does not appear with this patch applied (and without the clk_enable) in the bootlog any more. Yea, looks good to me, however I guess I would like second opinion on this also. Tero, can you queue this patch? Or who should handle this? I can't queue anything as I don't have maintainership on any of this stuff. Paul / Tony should go with this. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: am335x-evm, am335x-evmsdk: switch mmc1 to 4-bit mode
set bus-width to make SD card operate in 4 bit mode.
Signed-off-by: Balaji T K balaj...@ti.com
---
based on
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.13/dts
arch/arm/boot/dts/am335x-evm.dts |1 +
arch/arm/boot/dts/am335x-evmsk.dts |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 23b0a3e..028ca09 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -521,4 +521,5 @@
mmc1 {
status = okay;
vmmc-supply = vmmc_reg;
+ bus-width = 4;
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index bc93895..563a2b1 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -423,4 +423,5 @@
mmc1 {
status = okay;
vmmc-supply = vmmc_reg;
+ bus-width = 4;
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: am335x-bone-common: correct mux mode for cmd line
pinmux_emmc_pins: mux mode for cmd line should be MODE2
to detect eMMC on beagle bone black and beagle bone white + eMMC cape.
Signed-off-by: Balaji T K balaj...@ti.com
Tested-by: Felipe Balbi ba...@ti.com
---
based on
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.13/dts
arch/arm/boot/dts/am335x-bone-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index ff5c3ca..51f6a99 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -153,7 +153,7 @@
emmc_pins: pinmux_emmc_pins {
pinctrl-single,pins =
0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk */
- 0x84 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_csn2.mmc1_cmd */
+ 0x84 (PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn2.mmc1_cmd */
0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad0.mmc1_dat0 */
0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad1.mmc1_dat1 */
0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_ad2.mmc1_dat2 */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
On 23:13-20130926, Eduardo Valentin wrote:
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
- cpu@0 {
+ cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points =
/* kHzuV */
@@ -25,9 +25,15 @@
};
};
- bandgap {
+ thermal-zones{
+ #include omap4-cpu-thermal.dtsi
+ };
+
+ bandgap: bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+
+ #thermal-sensor-cells = 0;
2 cents:
we might want to move bandgap under ocp?
};
};
--
1.8.2.1.342.gfa7285d
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] OMAP/serial: Fix division by zero exception on 3M+ baud rates
Sorry for HTML mail, resend
On Fri, Sep 27, 2013 at 3:37 PM, Alexey Pelykh alexey.pel...@gmail.com wrote:
Hi Russel,
Probably then it would be great if you could summarize that in a patch to
replace mine, since basically mine is totally improper.
Thanks,
Alexey
On Sat, Sep 21, 2013 at 1:42 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Sat, Sep 21, 2013 at 03:43:44AM -0400, Alexey Pelykh wrote:
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 816d1a2..808a880 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,8 +240,8 @@ serial_omap_baud_is_mode16(struct uart_port *port,
unsigned int baud)
{
unsigned int n13 = port-uartclk / (13 * baud);
unsigned int n16 = port-uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port-uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port-uartclk / (16 * n16));
+ int baudAbsDiff13 = n13 ? (baud - (port-uartclk / (13 * n13))) :
INT_MAX;
+ int baudAbsDiff16 = n16 ? (baud - (port-uartclk / (16 * n16))) :
INT_MAX;
if(baudAbsDiff13 0)
baudAbsDiff13 = -baudAbsDiff13;
if(baudAbsDiff16 0)
So, this code is trying to work out whether it's better to use a prescaler
of 13 or 16? In which case, the above code is rather buggy in many ways.
Let's take an example - what if port-uartclk is 19MHz?
n13 = 19M / 13 * 115200 = 1
n16 = 19M / 16 * 115200 = 1
baudAbsDiff13 = 115200 - (19M / 13 * 1) = 115200 - 146153 = -30953 -
30953
baudAbsDiff16 = 115200 - (19M / 16 * 1) = 115200 - 118750 = -3550 - 3350
return (baudAbsDiff13 baudAbsDiff16); - 1
That seems like it's right.
Now, what if it's 18MHz?
n13 = 18M / 13 * 115200 = 1
n16 = 18M / 16 * 115200 = 0
baudAbsDiff13 = 115200 - (18M / 13 * 1) = 115200 - 146153 = -23261 -
23261
baudAbsDiff16 = 115200 - (18M / 16 * 0) = 115200 - 118750 = INT_MAX
return (baudAbsDiff13 baudAbsDiff16); - 0
Now, consider the question: with a 18MHz clock, which produces a more
accurate 115200 baud rate - a prescaler of 16 or 13? Let's go back to
the math.
115200 * 13 = 1497600
115200 * 16 = 1843200
So, choosing a prescaler of 16 will give a slower baud rate, but it's
a lot closer to 115200 than using the prescaler of 13. Yet, the code
will select the latter.
I'd suggest that this code gets rewritten to do what it says on the tin
a bit better:
unsigned n13 = DIV_ROUND_CLOSEST(port-uartclk, 13 * baud);
unsigned n16 = DIV_ROUND_CLOSEST(port-uartclk, 16 * baud);
int delta_clk_13 = 13 * baud * n13 - port-uartclk;
int delta_clk_16 = 16 * baud * n16 - port-uartclk;
if (delta_clk_13 0)
delta_clk_13 = -delta_clk_13;
if (delta_clk_16 0)
delta_clk_16 = -delta_clk_16;
return delta_clk_13 delta_clk_16;
Note that baud will never be larger than port-uartclk / 13, so n13
will always be greater than 1. n16 may be zero though, and in this
case, at the point of the test, delta_clk_16 becomes much larger than
delta_clk_13, so the above calculation returns false, meaning we
correctly use a prescaler of 13.
Not only does this avoid the problem with the divider being zero, but
it also selects the prescaler which gives us the closest baud rate to
the one which is being requested.
Finally, serial_omap_get_divisor should also use DIV_ROUND_CLOSEST() -
or for extra points, integrate this into serial_omap_get_divisor(),
and have it also return the prescaler too.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: drop explicit selection of HAVE_CLK and CLKDEV_LOOKUP
On Tue, Sep 24, 2013 at 7:41 PM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: CLKDEV_LOOKUP selects HAVE_CLK and COMMON_CLK selects CLKDEV_LOOKUP. So all symbols that select at least two of these symbols can be simplified. For imx, omap2 and ux500 some rearrangements were necessary before the simplification. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de arch/arm/mach-u300/Kconfig | 1 - arch/arm/mach-ux500/Kconfig| 29 - I am worried that the ux500 stuff may conflict with other stuff destined for the ARM SoC tree, so if you coordinate with the ARM SoC folks: Acked-by: Linus Walleij linus.wall...@linaro.org for these two. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
On 27-09-2013 08:24, Nishanth Menon wrote:
On 23:13-20130926, Eduardo Valentin wrote:
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi
b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
-cpu@0 {
+cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points =
/* kHzuV */
@@ -25,9 +25,15 @@
};
};
-bandgap {
+thermal-zones{
+#include omap4-cpu-thermal.dtsi
+};
+
+bandgap: bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+
+#thermal-sensor-cells = 0;
2 cents:
we might want to move bandgap under ocp?
Yes, agreed. But I don't think this change is related to this patch or
to this series.
Tks Nishanth
};
};
--
1.8.2.1.342.gfa7285d
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
On 27-09-2013 08:24, Nishanth Menon wrote:
On 23:13-20130926, Eduardo Valentin wrote:
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi
b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
-cpu@0 {
+cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points =
/* kHzuV */
@@ -25,9 +25,15 @@
};
};
-bandgap {
+thermal-zones{
+#include omap4-cpu-thermal.dtsi
+};
+
+bandgap: bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+
+#thermal-sensor-cells = 0;
2 cents:
we might want to move bandgap under ocp?
Yes, agreed. But I don't think this change is related to this patch or
to this series.
Correct - this comment is not related to the current patch, hence my 2
cents ;) - will be nice to have it cleaned up though..
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] arm: Fix build error with context tracking calls
On Wed, Sep 25, 2013 at 10:38:58AM -0700, Kevin Hilman wrote: Frederic Weisbecker fweis...@gmail.com writes: 2013/9/14, Russell King - ARM Linux li...@arm.linux.org.uk: On Fri, Sep 13, 2013 at 07:03:34PM +0200, Frederic Weisbecker wrote: diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c index 247091b..859c8df 100644 --- a/kernel/context_tracking.c +++ b/kernel/context_tracking.c @@ -51,6 +51,15 @@ void context_tracking_user_enter(void) unsigned long flags; /* + * Repeat the user_enter() check here because some archs may be calling + * this from asm and if no CPU needs context tracking, they shouldn't + * go further. We can remove that check here once these archs support the static key + * check. The only (minor) comment on this is that the above would fail checkpatch, but that's not a good enough reason to respin it if you've already applied it IMHO. Ah I haven't yet pushed that patch anywhere so I can definetly fix that. Thanks for the review. BTW, I initially first thought this fix could go through your tree but if you prefer I can push it through Ingo to the context tracking bits. Just tell me either way. Frederic, I suggest you queue it directly for v3.12-rc. Thanks, Ok, I'm doing that then, thanks you! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 11/18] arm: dts: add omap4430 thermal data
On 27-09-2013 09:26, Nishanth Menon wrote:
On Fri, Sep 27, 2013 at 8:20 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
On 27-09-2013 08:24, Nishanth Menon wrote:
On 23:13-20130926, Eduardo Valentin wrote:
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap443x.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap443x.dtsi
b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..e9c97d6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -12,7 +12,7 @@
/ {
cpus {
-cpu@0 {
+cpu0: cpu@0 {
/* OMAP443x variants OPP50-OPPNT */
operating-points =
/* kHzuV */
@@ -25,9 +25,15 @@
};
};
-bandgap {
+thermal-zones{
+#include omap4-cpu-thermal.dtsi
+};
+
+bandgap: bandgap {
reg = 0x4a002260 0x4
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
+
+#thermal-sensor-cells = 0;
2 cents:
we might want to move bandgap under ocp?
Yes, agreed. But I don't think this change is related to this patch or
to this series.
Correct - this comment is not related to the current patch, hence my 2
cents ;) - will be nice to have it cleaned up though..
Yes, it will be cleaned. ;-) Tks.
Regards,
Nishanth Menon
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: am335x-boneblack: move fixed regulator to board level
On Friday 20 September 2013 09:51 PM, Felipe Balbi wrote: On Thu, Sep 19, 2013 at 12:12:44PM -0500, Nishanth Menon wrote: 3.3V fixed regulator does not belong to TPS node - as a result the fixed regulator is never probed and MMC is continually deferred due to lack of regulator. Move the fixed regulator to be at root of platform. Signed-off-by: Nishanth Menon n...@ti.com Tested-by: Felipe Balbi ba...@ti.com Tested-by: Balaji T K balaj...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
On Friday 27 September 2013 02:36:52, Javier Martinez Canillas wrote: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk For both patches: Tested-by: Lars Poeschel poesc...@lemonage.de on an am3359 (which is DT booting). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 09/27/2013 02:49 AM, Sekhar Nori wrote: On 9/27/2013 5:58 AM, Joel Fernandes wrote: On 09/26/2013 06:13 PM, Olof Johansson wrote: On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. Sorry about this. :-( This is indeed v6. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. When I started looking at EDMA in June, I noticed that a lot had already been merged. EDMA DMA Engine driver itself was merged last year, no worries there. but the long pending list of fixes to be made to the driver had to written and rewritten multiple times which took a long time. Due to this, the EDMA device tree entries could not be merged in fear that doing so would cause problems such as MMC/SD corruption etc. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) Thank you! :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? I think a little on both sides can be improved. For TI, a bit more work toward explaining patches better in change logs so that maintainers understand and are willing to help to get the code upstream would help. A lot of improvement to internal policies have been made for developing on upstream, and that's certainly a good thing but there's still more room forard improvement. For maintainers, EDMA code would have been kept breathing all these months (atleast 8 months) if those temporary fixes mentioned above would have been merged into the kernel instead of not applied. With those fixes in place, dts could have been enabled and EDMA would be fully working all these months. This would have certainly made things a lot easier. Rewriting stuff the right way is OK but if it is a _lot_ of effort, then to keep things alive, merging stuff for now specially if they are one-liners could be made acceptable. Joel, can you give a link to the one-liner temporary fix that was was not merged? I am unable to put it in context. Sure, not exactly a one-line but maybe couple of lines (see below). Also wasn't referring to anything you're maintaining. I was just continuing the original discussion of where we can improve as a community. My point was very trivial changes that keep things working such as this one should be merged in time to keep things working:
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 09/27/2013 04:04 AM, Sekhar Nori wrote: On 9/27/2013 5:58 AM, Joel Fernandes wrote: On 09/26/2013 06:13 PM, Olof Johansson wrote: On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. Sorry about this. :-( This is indeed v6. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. When I started looking at EDMA in June, I noticed that a lot had already been merged. EDMA DMA Engine driver itself was merged last year, no worries there. but the long pending list of fixes to be made to the driver had to written and rewritten multiple times which took a long time. Due to this, the EDMA device tree entries could not be merged in fear that doing so would cause problems such as MMC/SD corruption etc. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) Thank you! :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? I think a little on both sides can be improved. Since we are in lessons learnt mode, I think as developers we need to learn to prioritize fixes over other features we are working on. I went back to the chronology of this patch series. Sure, I agree with this. Will definitely work on it. 22nd July 2013: v2 posted 29th July 2013: Discussion on whether the patch can wait till *v3.12* merge window. 29th July 2013: comments given on v2 22nd Aug 2013:Pull request's sent by Sekhar for v3.12 24th Aug 2013:another v2 posted (all comments given earlier not addressed, received some comments on build warnings) 27th Aug 2013:another v3 posted (all comments given on 29th July not addressed) 10th Sept 2013: another v3 posted (all comments given on 29th July not addressed) [some discussion on comments and why this cannot wait until v3.13] 17th Sept 2013: Final version ready for merge posted. 26th Sept 2013: Another v3 posted, this time for Olof to send into v3.12-rc See, early on, the patch was actually in consideration for v3.12 merge. The barrier of entry into -rc cycle is pretty high. So if you have an opportunity to hit a merge window, utilize that by prioritizing this work over anything else you may be doing. I know you got busy with adding support for SG lists and all, but
Re: [PATCHv2 0/9] omap hwspinlock dt support
On 09/17/2013 02:30 PM, Suman Anna wrote: Hi, This is an updated series for adding the device tree support to the OMAP hwspinlock driver. The series is based on 3.12-rc1, and includes patches on hwspinlock driver, OMAP hwmod data files and OMAP DTS files. The updated series adds new patches to enable the hwspinlock driver on OMAP5 and AM335x SoCs as well. Tested this on Panda4, BeagleBone Black and OMAP5 uEVM (with out-of-tree clock patches from Tero). Ohad, Benoit, A gentle reminder - can you please provide your review comments on these patches. I am hoping that this series can make it to 3.13. Paul, The hwmod data patches needs to be merged only after the respective DT node patches are merged, without which the hwmod entry will not have a base address while enabling and idling (using sysc) the hwmod during hwmod initialization. regards Suman Changes new in v2: - Added a new common DT binding documentation and OF helpers (Patch1), addressing the review comments from v1 [2]. The MSM support [1] needs to be reworked on top of this common patch. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node (Patches 4, 5) - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup (Patches 6, 7) - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335 (Patches 8, 9). The sysc patch is not essential for AM335 spinlock functionality, but is needed for smart-idling the IP when the module is enabled. - OMAP4 DT node patch is unchanged (Patch 3) v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 [1] https://lkml.org/lkml/2013/8/14/528 [2] http://marc.info/?t=13782309035r=1w=2 Suman Anna (9): hwspinlock/core: add common dt bindings and OF helpers hwspinlock/omap: add support for dt nodes ARM: dts: OMAP4: Add hwspinlock node ARM: OMAP5: hwmod data: Add spinlock data ARM: dts: OMAP5: Add hwspinlock node hwspinlock/omap: support AM33xx hwspinlock/omap: enable module before reading SYSSTATUS register ARM: dts: AM33XX: Add hwspinlock node ARM: AM33xx: hwmod_data: add the sysc configuration for spinlock .../devicetree/bindings/hwlock/hwlock.txt | 26 + .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++ arch/arm/boot/dts/am33xx.dtsi | 6 +++ arch/arm/boot/dts/omap4.dtsi | 6 +++ arch/arm/boot/dts/omap5.dtsi | 6 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 - arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 13 + arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 44 drivers/hwspinlock/Kconfig | 2 +- drivers/hwspinlock/hwspinlock_core.c | 61 +- drivers/hwspinlock/omap_hwspinlock.c | 44 include/linux/hwspinlock.h | 11 ++-- 13 files changed, 233 insertions(+), 80 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The documentation and OF helpers to
retrieve these common properties have been added to the driver core.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 26 +
drivers/hwspinlock/hwspinlock_core.c | 61 +-
include/linux/hwspinlock.h | 11 ++--
3 files changed, 93 insertions(+), 5 deletions(-)
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..789930e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,26 @@
+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 driver
+implementation to another. Look through the individual hwlock driver
+binding documentations for identifying which are mandatory and which are
+optional for that specific driver.
+
+Common properties:
+- hwlock-base-id:Base Id for the locks for a particular hwlock device.
+ This property is used for representing a set of locks
+ present in a hwlock device with a unique base id in
+ the driver core. This property is mandatory ONLY if a
+ SoC has several hwlock devices.
+
+ See documentation on struct hwspinlock_pdata in
+ linux/hwspinlock.h for more details.
+
+- 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.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..aec32e7 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -1,7 +1,7 @@
/*
* Hardware spinlock framework
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Ohad Ben-Cohen o...@wizery.com
*
@@ -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
@@ -308,6 +309,64 @@ out:
}
/**
+ * 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, -ENODEV on generic failure 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 = -ENODEV;
+
+#ifdef CONFIG_OF
+ if (!dn)
+ return -ENODEV;
Checking !dn is done in of_property_read_u32, so you don't need to duplicate
+
+ ret = of_property_read_u32(dn, hwlock-base-id, val);
+ if (!ret)
+ ret = val;
+#endif
+
+ return ret;
+}
+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
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ * failure or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_locks(struct device_node *dn)
+{
+ unsigned int val;
+ int ret = -ENODEV;
+
+#ifdef CONFIG_OF
+ if (!dn)
+ return -ENODEV;
Checking !dn is done in of_property_read_u32, so you don't need to duplicate
+
+ ret = of_property_read_u32(dn, hwlock-num-locks, val);
+ if (!ret)
+ ret = val ? val : -ENODEV;
+#endif
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_locks);
+
+/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the
Re: [PATCHv2 2/9] hwspinlock/omap: add support for dt nodes
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
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
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60 --
drivers/hwspinlock/omap_hwspinlock.c | 23 +++--
4 files changed, 50 insertions(+), 67 deletions(-)
create mode 100644
Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..235b7c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,31 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible:Currently supports only ti,omap4-hwspinlock
for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock register address range
(base
+ address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+
+Common hwlock properties:
+The following describes the usage of the common hwlock properties (defined in
+Documentation/devicetree/bindings/hwlock/hwlock.txt) on OMAP.
+
+- hwlock-base-id:There are currently no OMAP SoCs with multiple
+ hwspinlock devices. The OMAP driver uses a default
+ base id value of 0 for the locks present within the
+ single hwspinlock device on all SoCs.
+- hwlock-num-locks: This property is not required on OMAP SoCs, since the
+ number of locks present within a device can be deduced
+ from the SPINLOCK_SYSSTATUS device register.
If you are going to be explicit about this properties, you should probably be a
bit more clear about them NOT being in the OMAP dts because of the reasons you
specify.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+};
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/9] hwspinlock/omap: add support for dt nodes
On 09/27/2013 11:06 AM, Kumar Gala wrote: On Sep 17, 2013, at 2:30 PM, Suman Anna wrote: 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 --- .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 23 +++-- 4 files changed, 50 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt new file mode 100644 index 000..235b7c5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt @@ -0,0 +1,31 @@ +OMAP4+ HwSpinlock Driver + + +Required properties: +- compatible: Currently supports only ti,omap4-hwspinlock for +OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs +- reg: Contains the hwspinlock register address range (base +address and length) +- ti,hwmods:Name of the hwmod associated with the hwspinlock device + +Common hwlock properties: +The following describes the usage of the common hwlock properties (defined in +Documentation/devicetree/bindings/hwlock/hwlock.txt) on OMAP. + +- hwlock-base-id: There are currently no OMAP SoCs with multiple +hwspinlock devices. The OMAP driver uses a default +base id value of 0 for the locks present within the +single hwspinlock device on all SoCs. +- hwlock-num-locks: This property is not required on OMAP SoCs, since the +number of locks present within a device can be deduced +from the SPINLOCK_SYSSTATUS device register. If you are going to be explicit about this properties, you should probably be a bit more clear about them NOT being in the OMAP dts because of the reasons you specify. You mean on the hwlock-base-id? I wanted to document how these properties (do not) apply for OMAP, I will revise the text to be a bit more explicit. Thanks for the review. regards Suman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers
Kumar,
On 09/27/2013 11:04 AM, Kumar Gala wrote:
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The documentation and OF helpers to
retrieve these common properties have been added to the driver core.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 26 +
drivers/hwspinlock/hwspinlock_core.c | 61
+-
include/linux/hwspinlock.h | 11 ++--
3 files changed, 93 insertions(+), 5 deletions(-)
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..789930e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,26 @@
+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 driver
+implementation to another. Look through the individual hwlock driver
+binding documentations for identifying which are mandatory and which are
+optional for that specific driver.
+
+Common properties:
+- hwlock-base-id: Base Id for the locks for a particular hwlock device.
+This property is used for representing a set of locks
+present in a hwlock device with a unique base id in
+the driver core. This property is mandatory ONLY if a
+SoC has several hwlock devices.
+
+See documentation on struct hwspinlock_pdata in
+linux/hwspinlock.h for more details.
+
+- 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.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..aec32e7 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -1,7 +1,7 @@
/*
* Hardware spinlock framework
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated -
http://www.ti.com
*
* Contact: Ohad Ben-Cohen o...@wizery.com
*
@@ -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
@@ -308,6 +309,64 @@ out:
}
/**
+ * 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, -ENODEV on generic failure 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 = -ENODEV;
+
+#ifdef CONFIG_OF
+if (!dn)
+return -ENODEV;
Checking !dn is done in of_property_read_u32, so you don't need to duplicate
I have added this specifically since my intention is to differentiate
the validity of the node vs the presence of the property within a node.
This property may be optional for some platforms and a must for some
others, and differentiating would allow the individual driver
implementations to make the distinction.
+
+ret = of_property_read_u32(dn, hwlock-base-id, val);
+if (!ret)
+ret = val;
+#endif
+
+return ret;
+}
+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
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ * failure or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_locks(struct device_node *dn)
+{
+unsigned int val;
+int ret = -ENODEV;
+
+#ifdef CONFIG_OF
+if (!dn)
+return -ENODEV;
Checking !dn is done in
Re: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers
On Sep 27, 2013, at 11:48 AM, Suman Anna wrote:
Kumar,
On 09/27/2013 11:04 AM, Kumar Gala wrote:
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The documentation and OF helpers to
retrieve these common properties have been added to the driver core.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 26 +
drivers/hwspinlock/hwspinlock_core.c | 61
+-
include/linux/hwspinlock.h | 11 ++--
3 files changed, 93 insertions(+), 5 deletions(-)
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..789930e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,26 @@
+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 driver
+implementation to another. Look through the individual hwlock driver
+binding documentations for identifying which are mandatory and which are
+optional for that specific driver.
+
+Common properties:
+- hwlock-base-id: Base Id for the locks for a particular hwlock device.
+ This property is used for representing a set of locks
+ present in a hwlock device with a unique base id in
+ the driver core. This property is mandatory ONLY if a
+ SoC has several hwlock devices.
+
+ See documentation on struct hwspinlock_pdata in
+ linux/hwspinlock.h for more details.
+
+- 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.
Was meaning to say this before, another reason for hwlock-num-locks is to limit
the # of locks available to the processors running linux vs what other
processors in the SoC might be using.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..aec32e7 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -1,7 +1,7 @@
/*
* Hardware spinlock framework
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated -
http://www.ti.com
*
* Contact: Ohad Ben-Cohen o...@wizery.com
*
@@ -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
@@ -308,6 +309,64 @@ out:
}
/**
+ * 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, -ENODEV on generic failure 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 = -ENODEV;
+
+#ifdef CONFIG_OF
+ if (!dn)
+ return -ENODEV;
Checking !dn is done in of_property_read_u32, so you don't need to duplicate
I have added this specifically since my intention is to differentiate
the validity of the node vs the presence of the property within a node.
This property may be optional for some platforms and a must for some
others, and differentiating would allow the individual driver
implementations to make the distinction.
Maybe add a comment for both cases.
+
+ ret = of_property_read_u32(dn, hwlock-base-id, val);
+ if (!ret)
+ ret = val;
+#endif
+
+ return ret;
+}
+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
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ *
Re: [PATCHv2 2/9] hwspinlock/omap: add support for dt nodes
On Sep 27, 2013, at 11:21 AM, Suman Anna wrote: On 09/27/2013 11:06 AM, Kumar Gala wrote: On Sep 17, 2013, at 2:30 PM, Suman Anna wrote: 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 --- .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 23 +++-- 4 files changed, 50 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt new file mode 100644 index 000..235b7c5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt @@ -0,0 +1,31 @@ +OMAP4+ HwSpinlock Driver + + +Required properties: +- compatible: Currently supports only ti,omap4-hwspinlock for + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs +- reg: Contains the hwspinlock register address range (base + address and length) +- ti,hwmods: Name of the hwmod associated with the hwspinlock device + +Common hwlock properties: +The following describes the usage of the common hwlock properties (defined in +Documentation/devicetree/bindings/hwlock/hwlock.txt) on OMAP. + +- hwlock-base-id: There are currently no OMAP SoCs with multiple + hwspinlock devices. The OMAP driver uses a default + base id value of 0 for the locks present within the + single hwspinlock device on all SoCs. +- hwlock-num-locks:This property is not required on OMAP SoCs, since the + number of locks present within a device can be deduced + from the SPINLOCK_SYSSTATUS device register. If you are going to be explicit about this properties, you should probably be a bit more clear about them NOT being in the OMAP dts because of the reasons you specify. You mean on the hwlock-base-id? I wanted to document how these properties (do not) apply for OMAP, I will revise the text to be a bit more explicit. Thanks for the review. I meant for both, I think slightly revised text will help. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
Javier Martinez Canillas javier.marti...@collabora.co.uk writes: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk I'm fine with this appproach. For both patches: Reviewed-by: Kevin Hilman khil...@linaro.org Also, I gave it a spin across a handful of OMAP boards using v3.12-rc2 + these 2 patches. Boot tested successfully with DT boot: omap3530/beagle omap3730/beagle-xm omap3530/overo (Tobi w/GPIO IRQ networking) omap3730/overo STORM (w/GPIO IRQ for networking) am335x/beaglebone am335x/beaglebone black omap4430/panda omap4460/panda-es omap5912/OSK (omap1) I also verified non-DT boot on the OMAP3 platforms that still support legacy boot. So feel free to also add Tested-by: Kevin Hilman khil...@linaro.org Thanks for your persistence in getting a fix for this upstream. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: musb: am35x: use SIMPLE_DEV_PM_OPS
On 25.09.2013 15:48, Felipe Balbi wrote:
On Tue, Sep 24, 2013 at 08:57:08AM +0200, Daniel Mack wrote:
On 23.09.2013 23:20, Felipe Balbi wrote:
On Sun, Sep 22, 2013 at 01:46:58PM +0200, Daniel Mack wrote:
-static struct dev_pm_ops am35x_pm_ops = {
- .suspend= am35x_suspend,
- .resume = am35x_resume,
-};
+static SIMPLE_DEV_PM_OPS(am35x_pm_ops, am35x_suspend, am35x_resume);
you could as well remove the DEV_PM_OPS trickery. Ditto for all other
patches
Yes, I noticed that too. That's why I sent out a v2 of the series :)
Awesome :-) Thanks dude
So are you happy with this v2?
It's just a cosmetic cleanup after all ...
Thanks,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
On 9/27/2013 1:05 PM, Javier Martinez Canillas wrote: On 09/27/2013 01:18 AM, Stephen Warren wrote: On 09/24/2013 01:58 AM, Javier Martinez Canillas wrote: The OMAP GPIO controller HW requires a pin to be configured in GPIO input mode in order to operate as an interrupt input. Since drivers should not be aware of whether an interrupt pin is also a GPIO or not, the HW should be fully configured/enabled as an IRQ if a driver solely uses IRQ APIs such as request_irq(), and never calls any GPIO-related APIs. As such, add the missing HW setup to the OMAP GPIO controller's irq_chip driver. Since this bypasses the GPIO subsystem we have to ensure that another caller won't be able to request the same GPIO pin that is used as an IRQ and set its direction as output. Requesting the GPIO and setting its direction as input is allowed though. FWIW, the concept of this patch, Acked-by: Stephen Warren swar...@nvidia.com I didn't review the code; just skimmed it to see where the new functionality was implemented. Thanks Stephen, I split the changes as suggested by Tony and posted as a patch-set and not an RFC anymore: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately [1] [PATCH 2/2] gpio/omap: auto-setup a GPIO when used as an IRQ [2] Linus, Could you please add Stephen Acked-by when taking the patches and also George Cherian Tested-by that sent for this RFC. George it would be great if you can also comment on which OMAP platform you had tested. Tested on dra7xx/evm with GPIO interrupt for pcf gpio expander. Tested-by: George Cherian george.cher...@ti.com I cc'ed Aaro Koskinen and Paul Walmsley now which seems to have OMAP1 platforms to test. Could you please test [1] and [2] on a OMAP1 board? These patches solves a long standing issue we have on OMAP2+ when booting with DT and it would be great if you can check that it does not cause regressions on OMAP1 based boards. Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2937351/ [2]: https://patchwork.kernel.org/patch/2937371/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- -George -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers
Kumar,
On 09/27/2013 11:04 AM, Kumar Gala wrote:
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The documentation and OF helpers to
retrieve these common properties have been added to the driver core.
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 26 +
drivers/hwspinlock/hwspinlock_core.c | 61
+-
include/linux/hwspinlock.h | 11 ++--
3 files changed, 93 insertions(+), 5 deletions(-)
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..789930e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,26 @@
+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 driver
+implementation to another. Look through the individual hwlock driver
+binding documentations for identifying which are mandatory and which are
+optional for that specific driver.
+
+Common properties:
+- hwlock-base-id: Base Id for the locks for a particular hwlock device.
+ This property is used for representing a set of locks
+ present in a hwlock device with a unique base id in
+ the driver core. This property is mandatory ONLY if a
+ SoC has several hwlock devices.
+
+ See documentation on struct hwspinlock_pdata in
+ linux/hwspinlock.h for more details.
+
+- 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.
Was meaning to say this before, another reason for hwlock-num-locks is to
limit the # of locks available to the processors running linux vs what other
processors in the SoC might be using.
Yes, I understand the usecase/scenario since we had a similar need on
our product. That said, I guess this should be left to the individual
driver implementation/integration/documentation since this can be
achieved in different ways and depends on how you partition the
resources on your system (static partition vs resource reservation at
linux init time). Mentioning that here begs the question if you are
gonna use the starting 'n' locks, ending 'n' locks or range of 'n' locks
beginning in the middle. It would also imply it has to work together
with the hwlock-base-id as well in the last case. I would prefer to keep
the documentation generic here.
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..aec32e7 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -1,7 +1,7 @@
/*
* Hardware spinlock framework
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2013 Texas Instruments Incorporated -
http://www.ti.com
*
* Contact: Ohad Ben-Cohen o...@wizery.com
*
@@ -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
@@ -308,6 +309,64 @@ out:
}
/**
+ * 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, -ENODEV on generic failure 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 = -ENODEV;
+
+#ifdef CONFIG_OF
+ if (!dn)
+ return -ENODEV;
Checking !dn is done in of_property_read_u32, so you don't need to duplicate
I have added this specifically since my intention is to differentiate
the validity of the node vs the presence of the property within a node.
This property may be optional for some platforms and a must for some
others, and differentiating would allow the individual driver
implementations to make the distinction.
Maybe add a comment for both
Re: [PATCH 1/2] gpio/omap: maintain GPIO and IRQ usage separately
On Tuesday 24 September 2013 08:36 PM, Javier Martinez Canillas wrote: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Considering GPIO core maintainer is fine with this approach, am fine with both of your patches. Again thanks a lot for fixing the long nagging issue. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
Hi! On Thu 2013-09-26 17:48:29, Rob Landley wrote: On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote: On Wed, 25 Sep 2013, Rob Landley wrote: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Gnuism? Let me quote the ARM ARchitecture Reference Manual, version 7 revision C, section A8.8.44 (sorry for the whitespace dammage): Globally changing the binutils requirement for all architectures, as the doc patch at the start of this thread proposed doing, would mean gnuisms in common code (ext2 and such) wouldn't get caught, giving llvm and pcc and such a moving target when trying to build the kernel with non-gnu toolchains. That's what I meant by gnuisms breeding. Well. I did the docs patch, but my preferred solution would actually be to get the patches reverted so that it still works with old binutils. (So far, I updated one machine with new cross environment, two more to go.) Anyway, it should be solved _somehow_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
Hi, On Fri, Sep 27, 2013 at 09:35:33AM +0200, Javier Martinez Canillas wrote: I cc'ed Aaro Koskinen and Paul Walmsley now which seems to have OMAP1 platforms to test. Could you please test [1] and [2] on a OMAP1 board? [...] [1]: https://patchwork.kernel.org/patch/2937351/ [2]: https://patchwork.kernel.org/patch/2937371/ Tested-by: Aaro Koskinen aaro.koski...@iki.fi I applied these patches on top of 3.12-rc2 and tested them on Nokia 770 (OMAP1, Touchscreen Retu powerbutton GPIO IRQs) and N800 (OMAP2, Retu powerbutton). Seems to work fine on both boards. A. -- To unsubscribe from this list: send the line unsubscribe 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] gpio/omap: maintain GPIO and IRQ usage separately
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130924 17:45]: The GPIO OMAP controller pins can be used as IRQ and GPIO independently so is necessary to keep track GPIO pins and IRQ lines usage separately to make sure that the bank will always be enabled while being used. Also move gpio_is_input() definition in preparation for the next patch that setups the controller's irq_chip driver when a caller requests an interrupt line. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Thanks both of these look good to me for fixing the regression: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: omap_hsmmc: Enable SDIO interrupt
* Andreas Fenkart afenk...@gmail.com [130926 23:46]:
It's what Balaji already pointed out.
+ /* no transfer running, need to signal cirq if */
+ if (host-sdio_irq_en)
+ irq_mask |= CIRQ_EN;
omap_hsmmc_request_done calls omap_hsmmc_disable_irq
imagine this case:
1. host issues transfer from host-card (e.g. get RSSI)
2. at end of this transfer, SDIO IRQ are being masked
3. card wants to reply, raises an SDIO IRQ
4. nothing happens, since in 2. SDIO IRQ are masked
I verified this with my 88W8787 card. It is a problem
OK thanks makes sense.
Something like this but shorter as a comment:
/*
* Must not touch registers while fclk if off, otherwise SIGBUS.
* Card will still wake up upon SDIO IRQ, and we'll complete
* the request in pm_runtime_resume
*/
Another interpretation of your code could be:
/* Sorry I'm having Siesta right now, try later */
Well the clocking issue should be already handled by the
runtime PM, otherwise we have a bug somewhere. I'm almost
certain that no special handling is needed for register
access beyond runtime PM, but it would probably be best
if you could test it.
Compatible section you mean, that sounds to good to me.
But do we know platform have the deficiency?
There used to be an if statement like this in one of your previous
patches.
+ if (match) {
+ mmc-caps |= MMC_CAP_SDIO_IRQ;
+ if (of_find_property(host-dev-of_node,
+ti,quirk-swakeup-missing, NULL)) {
+ /* no wakeup from deeper power states, use polling */
+ mmc-caps = ~MMC_CAP_SDIO_IRQ;
+ }
+ }
Either or is needed, otherwise existing platforms will break, and will have
to apply patches on top of yours to reenable polling (e.g. beaglebone)
Yes, let's merge the necessary tweaks to this patch before
applying. The SDIO interrupt should work during runtime
for all omaps, so maybe we should just ensure that runtime
PM keeps those omaps from going to deeper idle modes for
now.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 0/7] PHY framework
On Fri, Sep 27, 2013 at 11:53:24AM +0530, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing I'll create a new branch *next* once this patch series is finalized. All the PHY driver development that depends on PHY framework can be based on this branch. Did USB enumeration testing in panda and beagle after applying [1] (needed for non-dt) All now applied to my usb-next branch. Thanks for redoing this many times and sticking with it. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] ARM: dts: am335x-bone: add CD for mmc1
On Thu, Sep 12, 2013 at 2:35 PM, Koen Kooi k...@dominion.thruhere.net wrote:
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
Acked-by: Jason Kridner j...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 1 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..0d95d54 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,12 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +266,11 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..0d63348 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -17,6 +17,5 @@
};
mmc1 {
- status = okay;
vmmc-supply = ldo3_reg;
};
--
1.8.2.1
___
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
