[net-next PATCH 0/8] add phy driver for Atheros AR8031 and CPSW phy-mode DT enhancement
This patch series adds the following feature * Atheros phy driver code cleanup * Add AT8031 phy driver to at803x driver * Add RGMII tx delay support via phy_if * Add phy_if DT enhancement to CPSW Driver and DT Mugunthan V N (8): drivers: net: phy: at803x code cleanup on register and unregister driver drivers: net: phy: at803x: seperate wol specific code to wol standard apis drivers: net: phy: at803x: add interface mode support drivers: net: phy: at803x: add support for AT8031 ARM: OMAP2+: omap2plus_defconfig: Enable Atheros support ARM: dts: AM33XX: Add CPSW phy_id device tree data to am335x-evmsk drivers: net: ethernet: cpsw: add phy-mode support to cpsw driver ARM: dts: AM33XX: Add phy-mode to CPSW node Documentation/devicetree/bindings/net/cpsw.txt |6 ++ arch/arm/boot/dts/am335x-bone.dts |2 + arch/arm/boot/dts/am335x-evm.dts |2 + arch/arm/boot/dts/am335x-evmsk.dts | 10 ++ arch/arm/configs/omap2plus_defconfig |1 + drivers/net/ethernet/ti/cpsw.c |2 + drivers/net/phy/at803x.c | 128 7 files changed, 111 insertions(+), 40 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 8/8] ARM: dts: AM33XX: Add phy-mode to CPSW node
Adding phy-mode to CPSW node for beaglebone, EVM and EVMsk.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
arch/arm/boot/dts/am335x-evm.dts |2 ++
arch/arm/boot/dts/am335x-evmsk.dts |2 ++
3 files changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5302f79..4b5a8e0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -131,8 +131,10 @@
cpsw_emac0 {
phy_id = davinci_mdio, 0;
+ phy-mode = mii;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
+ phy-mode = mii;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..814ee03 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -239,8 +239,10 @@
cpsw_emac0 {
phy_id = davinci_mdio, 0;
+ phy-mode = rgmii-txid;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
+ phy-mode = rgmii-txid;
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index acbcac3..4297899 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -251,8 +251,10 @@
cpsw_emac0 {
phy_id = davinci_mdio, 0;
+ phy-mode = rgmii-txid;
};
cpsw_emac1 {
phy_id = davinci_mdio, 1;
+ phy-mode = rgmii-txid;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 3/8] drivers: net: phy: at803x: add interface mode support
This patch adds support for RGMII TX delay configuration on Atheros 803X,
this can be enabled in debug registers. With this patch,
PHY_INTERFACE_MODE_RGMII_TXID modes are now supported.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 63444b7..dda07ed 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -27,6 +27,10 @@
#define AT803X_MMD_ACCESS_CONTROL 0x0D
#define AT803X_MMD_ACCESS_CONTROL_DATA 0x0E
#define AT803X_FUNC_DATA 0x4003
+#define AT803X_DEBUG_ADDR 0x1D
+#define AT803X_DEBUG_DATA 0x1E
+#define AT803X_DEBUG_SYSTEM_MODE_CTRL 0x05
+#define AT803X_DEBUG_RGMII_TX_CLK_DLY BIT(8)
MODULE_DESCRIPTION(Atheros 803x PHY driver);
MODULE_AUTHOR(Matus Ujhelyi);
@@ -99,6 +103,7 @@ static void at803x_get_wol(struct phy_device *phydev,
static int at803x_config_init(struct phy_device *phydev)
{
int val;
+ int ret;
u32 features;
features = SUPPORTED_TP | SUPPORTED_MII | SUPPORTED_AUI |
@@ -133,6 +138,17 @@ static int at803x_config_init(struct phy_device *phydev)
phydev-supported = features;
phydev-advertising = features;
+ if (phydev-interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ ret = phy_write(phydev, AT803X_DEBUG_ADDR,
+ AT803X_DEBUG_SYSTEM_MODE_CTRL);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, AT803X_DEBUG_DATA,
+ AT803X_DEBUG_RGMII_TX_CLK_DLY);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 2/8] drivers: net: phy: at803x: seperate wol specific code to wol standard apis
WOL is initilized in phy config_init, but there are standard apis
(set_wol/get_wol) for WOL in phy frame work. So this patch moves
WOL specific code from config_init to wol standard apis.
Cc: Matus Ujhelyi ujhely...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 64 ++
1 file changed, 48 insertions(+), 16 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index a1063e1..63444b7 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -32,10 +32,13 @@ MODULE_DESCRIPTION(Atheros 803x PHY driver);
MODULE_AUTHOR(Matus Ujhelyi);
MODULE_LICENSE(GPL);
-static void at803x_set_wol_mac_addr(struct phy_device *phydev)
+static int at803x_set_wol(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
{
struct net_device *ndev = phydev-attached_dev;
const u8 *mac;
+ int ret;
+ u32 value;
unsigned int i, offsets[] = {
AT803X_LOC_MAC_ADDR_32_47_OFFSET,
AT803X_LOC_MAC_ADDR_16_31_OFFSET,
@@ -43,30 +46,60 @@ static void at803x_set_wol_mac_addr(struct phy_device
*phydev)
};
if (!ndev)
- return;
+ return -ENODEV;
- mac = (const u8 *) ndev-dev_addr;
+ if (wol-wolopts WAKE_MAGIC) {
+ mac = (const u8 *) ndev-dev_addr;
- if (!is_valid_ether_addr(mac))
- return;
+ if (!is_valid_ether_addr(mac))
+ return -EFAULT;
- for (i = 0; i 3; i++) {
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
+ for (i = 0; i 3; i++) {
+ phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
AT803X_DEVICE_ADDR);
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
+ phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
offsets[i]);
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
+ phy_write(phydev, AT803X_MMD_ACCESS_CONTROL,
AT803X_FUNC_DATA);
- phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
+ phy_write(phydev, AT803X_MMD_ACCESS_CONTROL_DATA,
mac[(i * 2) + 1] | (mac[(i * 2)] 8));
+ }
+
+ value = phy_read(phydev, AT803X_INTR_ENABLE);
+ value |= AT803X_WOL_ENABLE;
+ ret = phy_write(phydev, AT803X_INTR_ENABLE, value);
+ if (ret)
+ return ret;
+ value = phy_read(phydev, AT803X_INTR_STATUS);
+ } else {
+ value = phy_read(phydev, AT803X_INTR_ENABLE);
+ value = (~AT803X_WOL_ENABLE);
+ ret = phy_write(phydev, AT803X_INTR_ENABLE, value);
+ if (ret)
+ return ret;
+ value = phy_read(phydev, AT803X_INTR_STATUS);
}
+
+ return ret;
+}
+
+static void at803x_get_wol(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
+{
+ u32 value;
+
+ wol-supported = WAKE_MAGIC;
+ wol-wolopts = 0;
+
+ value = phy_read(phydev, AT803X_INTR_ENABLE);
+ if (value AT803X_WOL_ENABLE)
+ wol-wolopts |= WAKE_MAGIC;
}
static int at803x_config_init(struct phy_device *phydev)
{
int val;
u32 features;
- int status;
features = SUPPORTED_TP | SUPPORTED_MII | SUPPORTED_AUI |
SUPPORTED_FIBRE | SUPPORTED_BNC;
@@ -100,11 +133,6 @@ static int at803x_config_init(struct phy_device *phydev)
phydev-supported = features;
phydev-advertising = features;
- /* enable WOL */
- at803x_set_wol_mac_addr(phydev);
- status = phy_write(phydev, AT803X_INTR_ENABLE, AT803X_WOL_ENABLE);
- status = phy_read(phydev, AT803X_INTR_STATUS);
-
return 0;
}
@@ -115,6 +143,8 @@ static struct phy_driver at803x_driver[] = {
.name = Atheros 8035 ethernet,
.phy_id_mask= 0xffef,
.config_init= at803x_config_init,
+ .set_wol= at803x_set_wol,
+ .get_wol= at803x_get_wol,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_aneg= genphy_config_aneg,
@@ -128,6 +158,8 @@ static struct phy_driver at803x_driver[] = {
.name = Atheros 8030 ethernet,
.phy_id_mask= 0xffef,
.config_init= at803x_config_init,
+ .set_wol= at803x_set_wol,
+ .get_wol= at803x_get_wol,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_aneg= genphy_config_aneg,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[net-next PATCH 1/8] drivers: net: phy: at803x code cleanup on register and unregister driver
Make use of phy_drivers_register/phy_drivers_unregister to register/unregister
multiple phy drivers in a single module.
Cc: Matus Ujhelyi ujhely...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 35 ++-
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 45cbc10..a1063e1 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -108,8 +108,9 @@ static int at803x_config_init(struct phy_device *phydev)
return 0;
}
-/* ATHEROS 8035 */
-static struct phy_driver at8035_driver = {
+static struct phy_driver at803x_driver[] = {
+{
+ /* ATHEROS 8035 */
.phy_id = 0x004dd072,
.name = Atheros 8035 ethernet,
.phy_id_mask= 0xffef,
@@ -121,10 +122,8 @@ static struct phy_driver at8035_driver = {
.driver = {
.owner = THIS_MODULE,
},
-};
-
-/* ATHEROS 8030 */
-static struct phy_driver at8030_driver = {
+}, {
+ /* ATHEROS 8030 */
.phy_id = 0x004dd076,
.name = Atheros 8030 ethernet,
.phy_id_mask= 0xffef,
@@ -136,32 +135,18 @@ static struct phy_driver at8030_driver = {
.driver = {
.owner = THIS_MODULE,
},
-};
+} };
static int __init atheros_init(void)
{
- int ret;
-
- ret = phy_driver_register(at8035_driver);
- if (ret)
- goto err1;
-
- ret = phy_driver_register(at8030_driver);
- if (ret)
- goto err2;
-
- return 0;
-
-err2:
- phy_driver_unregister(at8035_driver);
-err1:
- return ret;
+ return phy_drivers_register(at803x_driver,
+ ARRAY_SIZE(at803x_driver));
}
static void __exit atheros_exit(void)
{
- phy_driver_unregister(at8035_driver);
- phy_driver_unregister(at8030_driver);
+ return phy_drivers_unregister(at803x_driver,
+ ARRAY_SIZE(at803x_driver));
}
module_init(atheros_init);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 6/8] ARM: dts: AM33XX: Add CPSW phy_id device tree data to am335x-evmsk
Add phy_id device tree data to am335x-evmsk device to bring up CPSW
ethernet present on am335x starter kit.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f67c360..acbcac3 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -248,3 +248,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = davinci_mdio, 0;
+};
+
+cpsw_emac1 {
+ phy_id = davinci_mdio, 1;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 4/8] drivers: net: phy: at803x: add support for AT8031
This patch adds support for Atheros 8031 phy driver.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index dda07ed..1f7091b 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -183,6 +183,21 @@ static struct phy_driver at803x_driver[] = {
.driver = {
.owner = THIS_MODULE,
},
+}, {
+ /* ATHEROS 8031 */
+ .phy_id = 0x004dd074,
+ .name = Atheros 8031 ethernet,
+ .phy_id_mask= 0xffef,
+ .config_init= at803x_config_init,
+ .set_wol= at803x_set_wol,
+ .get_wol= at803x_get_wol,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg= genphy_config_aneg,
+ .read_status= genphy_read_status,
+ .driver = {
+ .owner = THIS_MODULE,
+ },
} };
static int __init atheros_init(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 7/8] drivers: net: ethernet: cpsw: add phy-mode support to cpsw driver
Adding phy-mode support to cpsw driver and updating the cpsw binding
documentation.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt |6 ++
drivers/net/ethernet/ti/cpsw.c |2 ++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 4f2ca6b..05d660e 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -28,6 +28,8 @@ Optional properties:
Slave Properties:
Required properties:
- phy_id : Specifies slave phy id
+- phy-mode : The interface between the SoC and the PHY (a string
+ that of_get_phy_mode() can understand)
- mac-address : Specifies slave MAC address
Optional properties:
@@ -58,11 +60,13 @@ Examples:
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
phy_id = davinci_mdio, 0;
+ phy-mode = rgmii-txid;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
phy_id = davinci_mdio, 1;
+ phy-mode = rgmii-txid;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
@@ -84,11 +88,13 @@ Examples:
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
phy_id = davinci_mdio, 0;
+ phy-mode = rgmii-txid;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
phy_id = davinci_mdio, 1;
+ phy-mode = rgmii-txid;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 89a4c40..a45f64e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1554,6 +1554,8 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
if (mac_addr)
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
+ slave_data-phy_if = of_get_phy_mode(slave_node);
+
if (data-dual_emac) {
if (of_property_read_u32(slave_node,
dual_emac_res_vlan,
prop)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 5/8] ARM: OMAP2+: omap2plus_defconfig: Enable Atheros support
Enable Atheros 803X phy driver support in defconfig which is present in AM335x EVM and EVM Starter Kit. Signed-off-by: Mugunthan V N mugunthan...@ti.com --- arch/arm/configs/omap2plus_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 435d69b..aa21009 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -283,3 +283,4 @@ CONFIG_SOC_OMAP5=y CONFIG_TI_DAVINCI_MDIO=y CONFIG_TI_DAVINCI_CPDMA=y CONFIG_TI_CPSW=y +CONFIG_AT803X_PHY=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/3] clk: fix clk_mux_get_parent return's signed value
clksel is an omap-centric term. How about:
clk_mux_get_parent should return an error if the value read from the
register is erroneous.
Make sense, will fix it.
The general approach looks good to me. Can you submit a V2 which
removes all of the clksel-isms and updates definitions for .get_parent
functions to avoid the warnings you mentioned in the cover letter? You
might find cocinelle useful for that last task.
Thanks!
Will fix them and add your ack to it?
Regards,
Mike
Currently if the value read is greater than the number of
available parents clk_mux_get_parent return's signed error
which will result in NULL pointer dereferencing in the
calling functions.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/clk/clk-mux.c|2 +-
drivers/clk/clk.c| 12 +++-
include/linux/clk-provider.h |4 ++--
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 25b1734..be0857e 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -29,7 +29,7 @@
#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
-static u8 clk_mux_get_parent(struct clk_hw *hw)
+static int clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
int num_parents = __clk_get_num_parents(hw-clk);
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 934cfd1..c187321 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1281,7 +1281,7 @@ EXPORT_SYMBOL_GPL(clk_get_parent);
static struct clk *__clk_init_parent(struct clk *clk)
{
struct clk *ret = NULL;
- u8 index;
+ int index;
/* handle the trivial cases */
@@ -1309,6 +1309,11 @@ static struct clk *__clk_init_parent(struct clk *clk)
*/
index = clk-ops-get_parent(clk-hw);
+ if (index 0) {
+ pr_err(%s: clk(%s) invalid parent clk_sel index(%d)\n,
+ __func__, clk-name, index);
+ goto out;
+ }
if (!clk-parents)
clk-parents =
@@ -1632,6 +1637,11 @@ int __clk_init(struct device *dev, struct clk *clk)
hlist_for_each_entry_safe(orphan, tmp2, clk_orphan_list,
child_node) {
if (orphan-ops-get_parent) {
i = orphan-ops-get_parent(orphan-hw);
+ if (i 0) {
+ pr_err(%s: orphan clk(%s) invalid parent\n,
+ __func__, orphan-name);
+ continue;
+ }
if (!strcmp(clk-name, orphan-parent_names[i]))
__clk_reparent(orphan, clk);
continue;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1186098..96337a1 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -80,7 +80,7 @@ struct clk_hw;
* supported by the clock.
*
* @get_parent:Queries the hardware to determine the parent of a
clock. The
- * return value is a u8 which specifies the index corresponding
to
+ * return value which specifies the index corresponding to
* the parent clock. This index can be applied to either the
* .parent_names or .parents arrays. In short, this function
* translates the parent value read from hardware into an array
@@ -127,7 +127,7 @@ struct clk_ops {
long(*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
+ int (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long,
unsigned long);
void(*init)(struct clk_hw *hw);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/3] clk: fix clk_mux_get_parent return's signed value
On Mon, Jun 3, 2013 at 11:27 PM, Ambresh K ambr...@ti.com wrote:
clksel is an omap-centric term. How about:
clk_mux_get_parent should return an error if the value read from the
register is erroneous.
Make sense, will fix it.
The general approach looks good to me. Can you submit a V2 which
removes all of the clksel-isms and updates definitions for .get_parent
functions to avoid the warnings you mentioned in the cover letter? You
might find cocinelle useful for that last task.
Thanks!
Will fix them and add your ack to it?
Great, thanks! Don't worry about the Ack. I'll take the patch
through the clk tree so it will have my SoB.
Regards,
Mike
Regards,
Mike
Currently if the value read is greater than the number of
available parents clk_mux_get_parent return's signed error
which will result in NULL pointer dereferencing in the
calling functions.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/clk/clk-mux.c|2 +-
drivers/clk/clk.c| 12 +++-
include/linux/clk-provider.h |4 ++--
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 25b1734..be0857e 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -29,7 +29,7 @@
#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
-static u8 clk_mux_get_parent(struct clk_hw *hw)
+static int clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
int num_parents = __clk_get_num_parents(hw-clk);
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 934cfd1..c187321 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1281,7 +1281,7 @@ EXPORT_SYMBOL_GPL(clk_get_parent);
static struct clk *__clk_init_parent(struct clk *clk)
{
struct clk *ret = NULL;
- u8 index;
+ int index;
/* handle the trivial cases */
@@ -1309,6 +1309,11 @@ static struct clk *__clk_init_parent(struct clk *clk)
*/
index = clk-ops-get_parent(clk-hw);
+ if (index 0) {
+ pr_err(%s: clk(%s) invalid parent clk_sel index(%d)\n,
+ __func__, clk-name, index);
+ goto out;
+ }
if (!clk-parents)
clk-parents =
@@ -1632,6 +1637,11 @@ int __clk_init(struct device *dev, struct clk *clk)
hlist_for_each_entry_safe(orphan, tmp2, clk_orphan_list,
child_node) {
if (orphan-ops-get_parent) {
i = orphan-ops-get_parent(orphan-hw);
+ if (i 0) {
+ pr_err(%s: orphan clk(%s) invalid
parent\n,
+ __func__, orphan-name);
+ continue;
+ }
if (!strcmp(clk-name, orphan-parent_names[i]))
__clk_reparent(orphan, clk);
continue;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1186098..96337a1 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -80,7 +80,7 @@ struct clk_hw;
* supported by the clock.
*
* @get_parent:Queries the hardware to determine the parent of a
clock. The
- * return value is a u8 which specifies the index
corresponding to
+ * return value which specifies the index corresponding to
* the parent clock. This index can be applied to either the
* .parent_names or .parents arrays. In short, this function
* translates the parent value read from hardware into an array
@@ -127,7 +127,7 @@ struct clk_ops {
long(*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
+ int (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long,
unsigned long);
void(*init)(struct clk_hw *hw);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 3/3] ARM: omap4: register DT clocks remove old data
Now that some of the OMAP4 PRCM clock data has been converted to a
DeviceTree representation it is no longer needed as static clock data.
Register the DT clocks first, followed by the remaining static clocks.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Joel A Fernandes joelag...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
arch/arm/mach-omap2/cclock44xx_data.c | 54 ---
1 file changed, 6 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 88e37a4..97fd65c 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/omap.h
#include soc.h
#include iomap.h
@@ -61,18 +62,12 @@
/* Root clocks */
-DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
-
DEFINE_CLK_FIXED_RATE(pad_clks_src_ck, CLK_IS_ROOT, 1200, 0x0);
DEFINE_CLK_GATE(pad_clks_ck, pad_clks_src_ck, pad_clks_src_ck, 0x0,
OMAP4430_CM_CLKSEL_ABE, OMAP4430_PAD_CLKS_GATE_SHIFT,
0x0, NULL);
-DEFINE_CLK_FIXED_RATE(pad_slimbus_core_clks_ck, CLK_IS_ROOT, 1200, 0x0);
-
-DEFINE_CLK_FIXED_RATE(secure_32k_clk_src_ck, CLK_IS_ROOT, 32768, 0x0);
-
DEFINE_CLK_FIXED_RATE(slimbus_src_clk, CLK_IS_ROOT, 1200, 0x0);
DEFINE_CLK_GATE(slimbus_clk, slimbus_src_clk, slimbus_src_clk, 0x0,
@@ -81,20 +76,6 @@ DEFINE_CLK_GATE(slimbus_clk, slimbus_src_clk,
slimbus_src_clk, 0x0,
DEFINE_CLK_FIXED_RATE(sys_32k_ck, CLK_IS_ROOT, 32768, 0x0);
-DEFINE_CLK_FIXED_RATE(virt_1200_ck, CLK_IS_ROOT, 1200, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_1300_ck, CLK_IS_ROOT, 1300, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_1680_ck, CLK_IS_ROOT, 1680, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_1920_ck, CLK_IS_ROOT, 1920, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2600_ck, CLK_IS_ROOT, 2600, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2700_ck, CLK_IS_ROOT, 2700, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_3840_ck, CLK_IS_ROOT, 3840, 0x0);
-
static const char *sys_clkin_ck_parents[] = {
virt_1200_ck, virt_1300_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
@@ -105,16 +86,6 @@ DEFINE_CLK_MUX(sys_clkin_ck, sys_clkin_ck_parents, NULL,
0x0,
OMAP4430_CM_SYS_CLKSEL, OMAP4430_SYS_CLKSEL_SHIFT,
OMAP4430_SYS_CLKSEL_WIDTH, CLK_MUX_INDEX_ONE, NULL);
-DEFINE_CLK_FIXED_RATE(tie_low_clock_ck, CLK_IS_ROOT, 0, 0x0);
-
-DEFINE_CLK_FIXED_RATE(utmi_phy_clkout_ck, CLK_IS_ROOT, 6000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60mhsp1_ck, CLK_IS_ROOT, 6000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60mhsp2_ck, CLK_IS_ROOT, 6000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60motg_ck, CLK_IS_ROOT, 6000, 0x0);
-
/* Module clocks and DPLL outputs */
static const char *abe_dpll_bypass_clk_mux_ck_parents[] = {
@@ -826,7 +797,7 @@ DEFINE_CLK_GATE(dss_sys_clk, syc_clk_div_ck,
syc_clk_div_ck, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL,
OMAP4430_OPTFCLKEN_SYS_CLK_SHIFT, 0x0, NULL);
-DEFINE_CLK_GATE(dss_tv_clk, extalt_clkin_ck, extalt_clkin_ck, 0x0,
+DEFINE_CLK_GATE(dss_tv_clk, extalt_clkin_ck, NULL, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL,
OMAP4430_OPTFCLKEN_TV_CLK_SHIFT, 0x0, NULL);
@@ -1051,7 +1022,7 @@ DEFINE_CLK_GATE(slimbus2_fclk_0, func_24mc_fclk,
func_24mc_fclk, 0x0,
OMAP4430_OPTFCLKEN_PER24MC_GFCLK_SHIFT, 0x0, NULL);
DEFINE_CLK_GATE(slimbus2_slimbus_clk, pad_slimbus_core_clks_ck,
- pad_slimbus_core_clks_ck, 0x0,
+ NULL, 0x0,
OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
OMAP4430_OPTFCLKEN_SLIMBUS_CLK_SHIFT, 0x0, NULL);
@@ -1442,27 +1413,11 @@ static struct omap_clk omap443x_clks[] = {
* clocks common to omap44xx
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck),
CLK(NULL, pad_clks_src_ck, pad_clks_src_ck),
CLK(NULL, pad_clks_ck, pad_clks_ck),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck),
CLK(NULL, slimbus_src_clk, slimbus_src_clk),
CLK(NULL, slimbus_clk, slimbus_clk),
CLK(NULL, sys_32k_ck, sys_32k_ck),
- CLK(NULL, virt_1200_ck, virt_1200_ck),
- CLK(NULL, virt_1300_ck, virt_1300_ck),
- CLK(NULL, virt_1680_ck, virt_1680_ck),
- CLK(NULL, virt_1920_ck, virt_1920_ck),
-
[PATCH RFC 2/3] ARM: dts: omap4 clock data
This is a first pass at creating a unique node for each clock in the
OMAP4 power, reset and clock manager (PRCM). So far I have only
converted mux clocks fixed-rate clocks, which coexist with the current
clock data in the kernel. The rest needs to be done but better to
publish early and often to see what others think of this approach.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Joel A Fernandes joelag...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
arch/arm/boot/dts/omap4-clocks.dtsi | 128
arch/arm/boot/dts/omap4.dtsi| 2 +
2 files changed, 130 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..664e100
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
@@ -0,0 +1,128 @@
+/*
+ * Copyright (C) 2013 Linaro Incorporated - http://www.linaro.org/
+ *
+ * Mike Turquette mturque...@linaro.org
+ *
+ * Data is automatically generated from the OMAP hardware databases. If
+ * changes need to be made, do not edit this file directly. Instead contact
+ * the following developers who will update the code generator:
+ *
+ * Benoit Cousson benoit.cous...@linaro.org
+ * Rajendra Nayak rna...@ti.com
+ * Mike Turquette mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* FIXME need to print the address directly */
+/*
+#include ../../mach-omap2/prm44xx.h
+#include ../../mach-omap2/cm2_44xx.h
+#include ../../mach-omap2/cm1_44xx.h
+*/
+
+
+/* Root clocks */
+
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 5900;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1300;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1680;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1920;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2600;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2700;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 3840;
+};
+
+sys_clkin_dt: sys_clkin_dt@4a306110 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = virt_1200_ck, virt_1300_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
virt_3840_ck;
+ reg = 0x4a306110 0x4;
+ mask = 0x7;
+ shift = 0;
+ index_one;
+};
+
+tie_low_clock_ck: tie_low_clock_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+utmi_phy_clkout_ck: utmi_phy_clkout_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60motg_ck: xclk60motg_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..70608db 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -106,6 +106,8 @@
ti,hwmods = counter_32k;
};
+ /include/ omap4-clocks.dtsi
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH RFC 1/3] clk: omap: introduce clock driver
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Joel A Fernandes joelag...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
This driver simply matches the basic bindings (so far). Eventually it
would match omap-specific bindings for DPLLs, CLKOUTX2 and strange leaf
clocks as well. This doesn't scale well since non-OMAP related clock
data (e.g. a pmic or discrete audio codec) will get grouped into this
driver if it matches on a basic clock type. Suggestions?
drivers/clk/Makefile | 1 +
drivers/clk/omap/Makefile | 1 +
drivers/clk/omap/clk.c| 55 +++
include/linux/clk/omap.h | 24 +
4 files changed, 81 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f51b52b..efd4f2a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..e9e5c95
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,55 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Linaro.org - http://www.linaro.org
+ * Mike Turquette mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/clk/omap.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+ {.compatible = fixed-clock, .data = of_fixed_clk_setup, },
+ {.compatible = mux-clock, .data = of_mux_clk_setup, },
+ {.compatible = fixed-factor-clock,
+ .data = of_fixed_factor_clk_setup, },
+ {},
+};
+
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ of_clk_init(clk_match);
+ return 0;
+}
+
+static struct platform_driver omap_clk_driver = {
+ .probe = omap_clk_probe,
+ .driver = {
+ .name = omap_clk,
+ .of_match_table = of_match_ptr(clk_match),
+ },
+};
+
+/* FIXME - need to initialize early; skip real driver registration probe */
+int __init dt_omap_clk_init(void)
+{
+ return omap_clk_probe(NULL);
+}
+
+MODULE_DESCRIPTION(OMAP Clock driver);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..504e838
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2010 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH RFC 0/3] first pass converting omap4 clock data to DT
This is a very incomplete conversion of a handful of OMAP4 PRCM clocks from the statically defined clock data in arch/arm/mach-omap2/cclock44xx_data.c to a new dts file in arch/arm/boot/dts/omap4-clocks.dtsi. I am not a DT expert so many of the choices here may be quite disgusting to look at, or may be on the right path. In particular I simply include the new omap4-clocks.dtsi from omap4.dtsi, which feels a bit kludgey. Also this series depends on the basic clock bindings RFC I posted earlier today[1]. I actually have an omap4-clock.dtsi file with many more clocks converted to the mux-clock, divider-clock, fixed-clock, fixed-factor and (unpublished) gate-clock bindings in my local repo, but it is not currently booting. I wanted to get this early preview out regardless. [1] http://article.gmane.org/gmane.linux.kernel/1501216 Mike Turquette (3): clk: omap: introduce clock driver ARM: dts: omap4 clock data ARM: omap4: register DT clocks remove old data arch/arm/boot/dts/omap4-clocks.dtsi | 128 ++ arch/arm/boot/dts/omap4.dtsi | 2 + arch/arm/mach-omap2/cclock44xx_data.c | 54 ++ drivers/clk/Makefile | 1 + drivers/clk/omap/Makefile | 1 + drivers/clk/omap/clk.c| 55 +++ include/linux/clk/omap.h | 24 +++ 7 files changed, 217 insertions(+), 48 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi create mode 100644 drivers/clk/omap/Makefile create mode 100644 drivers/clk/omap/clk.c create mode 100644 include/linux/clk/omap.h -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support
On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja gururaja.heb...@ti.com wrote: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Chris Ball c...@laptop.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org This is perfectly correct. Acked-by: Linus Walleij linus.wall...@linaro.org As the PM code seems to be similar across platforms I have had loose plans to move this to the device core as well, but right now I'm too busy with other things, and it can surely be refactored later. 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
[RESEND][PATCH 2/7] usb, dwc3: remove redundant D0 power state set
Pci_enable_device() will set device power state to D0, so it's no need to do it again in dwc3_pci_probe(). Signed-off-by: Yijing Wang wangyij...@huawei.com Cc: Felipe Balbi ba...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/usb/dwc3/dwc3-pci.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 227d4a7..c068608 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -133,7 +133,6 @@ static int dwc3_pci_probe(struct pci_dev *pci, return -ENODEV; } - pci_set_power_state(pci, PCI_D0); pci_set_master(pci); ret = dwc3_pci_register_phys(glue); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] USB: PHY: Improve PHY selection logic
On 06/03/2013 08:47 PM, Greg KH wrote: On Fri, May 31, 2013 at 02:29:01PM +0300, Roger Quadros wrote: Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. Felipe needs to take these, not I. Felipe, Could you please take these if appropriate? Thanks. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 3/3] clk: Avoid re-parenting orphan clk's having invalid parent index.
On Wednesday 29 May 2013 12:48 PM, Mike Turquette wrote:
Quoting Ambresh K (2013-05-01 23:25:29)
From: Ambresh K ambr...@ti.com
Add orhan clk nodes having invalid parent index to list and use
the list to skip re-parenting orphan clk having invalid parents.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/clk/clk.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f4d2c73..54d2aa3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -32,6 +32,7 @@ static int enable_refcnt;
static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
+static HLIST_HEAD(clk_orphan_invalid_parent);
Why not re-use the clk_orphan_list? Having an invalid value programmed
into the hardware for selecting a parent essetially orphans a clock
from a software point of view. Is there a specific need for the new
list?
Sorry for not being descriptive in commit message.
a) Avoids unnecessary re-parenting cycle for orphan clock's with invalid parent
for every clock
b) With patch [1/3], after a clk with invalid parent was encountered, for every
clk registered thereafter seeing following logs.
Snippet
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
[0.00] __clk_init: orphan clk(gpu_core_gclk_mux) invalid parent
Please advice, if can be handled better.
Thanks,
Ambresh
Regards,
Mike
static LIST_HEAD(clk_notifier_list);
/*** locking ***/
@@ -1532,8 +1533,8 @@ EXPORT_SYMBOL_GPL(clk_set_parent);
*/
int __clk_init(struct device *dev, struct clk *clk)
{
- int i, ret = 0;
- struct clk *orphan;
+ int i, ret = 0, skip = 0;
+ struct clk *orphan, *has_invalid_parent;
struct hlist_node *tmp2;
if (!clk)
@@ -1639,11 +1640,27 @@ int __clk_init(struct device *dev, struct clk *clk)
if (!strcmp(clk-name, orphan-name))
continue;
+ /* Skip iteration if orphan has invalid parent */
+ hlist_for_each_entry(has_invalid_parent,
+ clk_orphan_invalid_parent, child_node) {
+ if (!strcmp(orphan-name, has_invalid_parent-name))
{
+ skip = 1;
+ break;
+ }
+ }
+
+ if (skip) {
+ skip = 0;
+ continue;
+ }
+
if (orphan-ops-get_parent) {
i = orphan-ops-get_parent(orphan-hw);
if (i 0) {
pr_err(%s: orphan clk(%s) invalid parent\n,
__func__, orphan-name);
+ hlist_add_head(orphan-child_node,
+ clk_orphan_invalid_parent);
continue;
}
if (!strcmp(clk-name, orphan-parent_names[i]))
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support
On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij linus.wall...@linaro.org wrote: On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja gururaja.heb...@ti.com wrote: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Chris Ball c...@laptop.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org This is perfectly correct. Acked-by: Linus Walleij linus.wall...@linaro.org So please consider my other option given in patch 2 instead. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] i2c: omap: enhance pinctrl support
On Fri, May 31, 2013 at 8:07 PM, Kevin Hilman khil...@linaro.org wrote: But that brings up a bigger question about whether or not we should be doing the rest of this (idle/sleep) pin management in the drivers or in the driver core as well. I would much prefer it be handled by the driver core. Yes. See my suggestion in 2/11. In fact, since these are all PM related events, it should probably be handled by the PM core and seems pretty straight forward to do so. I can see a clean interface with three simple functions toward pinctrl/consumer.h for switching between the default, idle and sleep states, but you may see even further... 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
Request for OMAPDSS testing
Hi guys, I've made some big changes on the omapdss device model, which involves converting all the panel drivers. I've got only a bunch of boards, so I hope some of you can perhaps do some minimal tests on some other boards. I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43. The code can be found from the below git branch. It's based on 3.10-rc1. git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model All you need to do to get things working is to enable the new panel drivers from kernel config, under Device drivers/Graphics support/OMAP2+ Display Subsystem support/OMAP Display Device Drivers/ Thanks in advance! Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH 11/11] i2c: omap: enhance pinctrl support
On Fri, May 31, 2013 at 23:37:02, Kevin Hilman wrote:
+Linus Walleij (pinctrl maintainer)
Hebbar Gururaja gururaja.heb...@ti.com writes:
Amend the I2C omap pin controller to optionally take a pin control
handle and set the state of the pins to:
- default on boot, resume and before performing an i2c transfer
- idle after initial default, after resume default, and after each
i2c xfer
- sleep on suspend()
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- One is to minimize current leakage from pins and thus save power,
- second, we can prevent the IP from driving pins output in an
uncontrolled manner, which may happen if the power domain drops the
domain regulator.
Note:
A .suspend .resume callback is added which simply puts the pins to sleep
state upon suspend are moved to default idle state upon resume.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
(Changes based on i2c-nomadik.c)
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
[...]
@@ -1123,14 +1138,47 @@ omap_i2c_probe(struct platform_device *pdev)
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
}
- dev-pins = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(dev-pins)) {
- if (PTR_ERR(dev-pins) == -EPROBE_DEFER)
+ dev-pinctrl = devm_pinctrl_get(pdev-dev);
+ if (!IS_ERR(dev-pinctrl)) {
+ dev-pins_default = pinctrl_lookup_state(dev-pinctrl,
+PINCTRL_STATE_DEFAULT);
This part is already done by probe in driver core, why does it need to
be done again. dev-pins-default_state should already have this.
(c.f. pinctrl_bind_pins() in drivers/base/pinctrl.c)
But that brings up a bigger question about whether or not we should be
doing the rest of this (idle/sleep) pin management in the drivers or in
the driver core as well. I would much prefer it be handled by the
driver core.
In fact, since these are all PM related events, it should probably be
handled by the PM core and seems pretty straight forward to do so.
Let me pull out some info about these and come back
Kevin
Regards,
Gururaja
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support
On Tue, Jun 04, 2013 at 12:49:57, Linus Walleij wrote: On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij linus.wall...@linaro.org wrote: On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja gururaja.heb...@ti.com wrote: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Chris Ball c...@laptop.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org This is perfectly correct. Acked-by: Linus Walleij linus.wall...@linaro.org So please consider my other option given in patch 2 instead. I will check how I can be a part of this implementation Yours, Linus Walleij Regards, Gururaja -- To unsubscribe from this list: send the line unsubscribe 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 v2 1/2] PM / AVS: SmartReflex: use devm_* API to initialize SmartReflex
Use of of devm_* API for resource allocation provides benefits such
as auto handling of resource free. This reduces possibility have
memory leaks in case of wrong error handling. All direct release
calls should be removed to avoid races.
Reported-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
---
drivers/power/avs/smartreflex.c | 76 +++
1 file changed, 21 insertions(+), 55 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 6b2238b..fd71d5a 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -27,7 +27,7 @@
#include linux/pm_runtime.h
#include linux/power/smartreflex.h
-#define SMARTREFLEX_NAME_LEN 16
+#define SMARTREFLEX_NAME_LEN 32
#define NVALUE_NAME_LEN40
#define SR_DISABLE_TIMEOUT 200
@@ -207,12 +207,11 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
static int sr_late_init(struct omap_sr *sr_info)
{
struct omap_sr_data *pdata = sr_info-pdev-dev.platform_data;
- struct resource *mem;
int ret = 0;
if (sr_class-notify sr_class-notify_flags sr_info-irq) {
- ret = request_irq(sr_info-irq, sr_interrupt,
- 0, sr_info-name, sr_info);
+ ret = devm_request_irq(sr_info-pdev-dev, sr_info-irq,
+ sr_interrupt, 0, sr_info-name, sr_info);
if (ret)
goto error;
disable_irq(sr_info-irq);
@@ -224,14 +223,10 @@ static int sr_late_init(struct omap_sr *sr_info)
return ret;
error:
- iounmap(sr_info-base);
- mem = platform_get_resource(sr_info-pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start, resource_size(mem));
list_del(sr_info-node);
dev_err(sr_info-pdev-dev, %s: ERROR in registering
interrupt handler. Smartreflex will
not function as desired\n, __func__);
- kfree(sr_info);
return ret;
}
@@ -847,34 +842,33 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct dentry *nvalue_dir;
int i, ret = 0;
- sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
+ sr_info = devm_kzalloc(pdev-dev, sizeof(struct omap_sr), GFP_KERNEL);
if (!sr_info) {
dev_err(pdev-dev, %s: unable to allocate sr_info\n,
__func__);
return -ENOMEM;
}
+ sr_info-name = devm_kzalloc(pdev-dev,
+SMARTREFLEX_NAME_LEN, GFP_KERNEL);
+ if (!sr_info-name) {
+ dev_err(pdev-dev, %s: unable to allocate SR instance name\n,
+ __func__);
+ return -ENOMEM;
+ }
+
platform_set_drvdata(pdev, sr_info);
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
- ret = -EINVAL;
- goto err_free_devinfo;
+ return -EINVAL;
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, %s: no mem resource\n, __func__);
- ret = -ENODEV;
- goto err_free_devinfo;
- }
-
- mem = request_mem_region(mem-start, resource_size(mem),
- dev_name(pdev-dev));
- if (!mem) {
- dev_err(pdev-dev, %s: no mem region\n, __func__);
- ret = -EBUSY;
- goto err_free_devinfo;
+ sr_info-base = devm_ioremap_resource(pdev-dev, mem);
+ if (IS_ERR(sr_info-base)) {
+ dev_err(pdev-dev, %s: ioremap fail\n, __func__);
+ return PTR_ERR(sr_info-base);
}
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -882,13 +876,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
pm_runtime_enable(pdev-dev);
pm_runtime_irq_safe(pdev-dev);
- sr_info-name = kasprintf(GFP_KERNEL, %s, pdata-name);
- if (!sr_info-name) {
- dev_err(pdev-dev, %s: Unable to alloc SR instance name\n,
- __func__);
- ret = -ENOMEM;
- goto err_release_region;
- }
+ snprintf(sr_info-name, SMARTREFLEX_NAME_LEN, %s, pdata-name);
sr_info-pdev = pdev;
sr_info-srid = pdev-id;
@@ -905,13 +893,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-autocomp_active = false;
sr_info-ip_type = pdata-ip_type;
- sr_info-base = ioremap(mem-start, resource_size(mem));
- if (!sr_info-base) {
- dev_err(pdev-dev, %s: ioremap fail\n, __func__);
- ret = -ENOMEM;
- goto err_free_name;
- }
-
if (irq)
sr_info-irq = irq-start;
@@ -927,7 +908,7 @@ static int
Re: [PATCH 1/1] USB: ehci-omap: Reset dma_mask pointer on probe
On 06/03/2013 08:51 PM, Greg KH wrote: On Thu, May 23, 2013 at 05:46:44PM +0300, Roger Quadros wrote: On 05/23/2013 05:11 PM, Alan Stern wrote: On Thu, 23 May 2013, Roger Quadros wrote: Device tree probed devices don't get dma_mask set. Previously we were setting the dma_mask pointer only if it was NULL. However, the address of 'omap_ehci_dma_mask' would change each time the module is unloaded and loaded back thus causing the devices dma_mask pointer to be invalid on the next load. This will cause page faults if any driver tries to access the old dma_mask pointer. Unconditionally re-setting the dma_mask pointer fixes this problem. diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 3d1491b..b33e306 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -146,8 +146,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we have dma capability bindings this can go away. */ - if (!pdev-dev.dma_mask) - pdev-dev.dma_mask = omap_ehci_dma_mask; + pdev-dev.dma_mask = omap_ehci_dma_mask; Is this the solution that people have agreed on? There has been a lot of discussion on this topic. In particular, there has been talk about fixing it in the DT core. Fixing it in DT core would be best. Then please do that. It seems [1] went into 3.10-rc3 so this issue is fixed for 3.10. [1] https://patchwork.kernel.org/patch/2537021/ cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] PM / AVS: SmartReflex/class3: Fix order of initialization of SR class and SR driver
SmartReflex consists of three entities: SR device, SR class and
SR driver. SmartReflex driver depends on SmartReflex class, but
order of their initialization is not clear. They both use
late_initcall(), and order depends on Makefile calls.
Patch moves initialization of SR class to device_initcall(),
and removes redundant call of sr_late_init().
This provides predictable order of SmartReflex initcalls:
1. device_initcall() - SmartReflex class init
2. late_initcall() - SmartReflex driver init
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
drivers/power/avs/smartreflex.c |9 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index aee3c89..50523b8 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -59,4 +59,4 @@ static int __init sr_class3_init(void)
pr_info(SmartReflex Class3 initialized\n);
return sr_register_class(class3_data);
}
-omap_late_initcall(sr_class3_init);
+omap_device_initcall(sr_class3_init);
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index fd71d5a..42eed34 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -650,8 +650,6 @@ void sr_disable(struct voltagedomain *voltdm)
*/
int sr_register_class(struct omap_sr_class_data *class_data)
{
- struct omap_sr *sr_info;
-
if (!class_data) {
pr_warning(%s:, Smartreflex class data passed is NULL\n,
__func__);
@@ -666,13 +664,6 @@ int sr_register_class(struct omap_sr_class_data
*class_data)
sr_class = class_data;
- /*
-* Call into late init to do intializations that require
-* both sr driver and sr class driver to be initiallized.
-*/
- list_for_each_entry(sr_info, sr_list, node)
- sr_late_init(sr_info);
-
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] PM / AVS: SmartReflex: optimization series
The following patch series introduces a few optimizations for SmartReflex driver. 1. devm_* API usage for SmartReflex. Benefits: - auto handling of resources - allocation/auto free, map/auto unmap. - lot of error checks can be dropped. 2. Another small optimization resolves order of initialization between SmartReflex driver and SmartReflex class. Class is initialized before driver. Patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc4 Verified on OMAP4430. Boot - OK. SmartReflex registers debug dump - OK Series v2 contains: - spurious #define removed from PM / AVS: SmartReflex: use devm_* API to initialize SmartReflex - rebased to v3.10-rc4 Andrii Tseglytskyi (2): PM / AVS: SmartReflex: use devm_* API to initialize SmartReflex PM / AVS: SmartReflex/class3: Fix order of initialization of SR class and SR driver arch/arm/mach-omap2/smartreflex-class3.c |2 +- drivers/power/avs/smartreflex.c | 85 -- 2 files changed, 22 insertions(+), 65 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Hi, On 05/29/2013 07:38 AM, Kishon Vijay Abraham I wrote: On Wednesday 29 May 2013 04:07 AM, Sylwester Nawrocki wrote: On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote: 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 Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com Thanks for working on this. For the record, I plan to give this a try in the end of this week, with my simple MIPI CSI/DSI PHY driver. I might have some more comments then. For now just couple of remarks after reading the documentation. Thanks for reviewing. I'll wait for your comments before posting the next version. So I've used this API for the Exynos SoC MIPI CSI-2 and MIPI DSI DPHYs. I could remove all the local modifications, comparing to your v5, since this iteration already have what's needed, thanks! In my case the PHY provider was a platform device and so were the PHY consumer devices. Those PHYs are very simple, there is less than one register per PHY (some bits are shared across the MIPI CSI-2 receiver and MIPI DSI transmitter DPHYs), but having this generic PHY driver means, among others, there is a proper DT support. I could finally get rid of the the platform callback at arch/arm/plat-samsung/setup-mipiphy.c. I found this code useful as is, except previous minor comments I don't really have more remarks now. This API looks quite good, and it seems much lighter comparing to the original version. I assume, the way it is designed now, allows it to be used also with PHYs that hang off other buses, e.g. I2C. It would be nice to get this in 3.11. Hmm, actually I have some doubts, let me comment in other e-mail.. Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe 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 v6 1/9] drivers: phy: add generic PHY framework
On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote:
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
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/phy/phy-bindings.txt | 66 +++
Documentation/phy.txt | 123 +
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 539
include/linux/phy/phy.h| 248 +
9 files changed, 1005 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
+static inline int phy_init(struct phy *phy)
+{
+ pm_runtime_get_sync(phy-dev);
Hmm, no need to check return value here ? Also it looks a bit unexpected to
possibly have runtime_resume callback of a PHY device called before ops-init()
call ? It seems a bit unclear what the purpose of init() callback is.
+ if (phy-ops-init)
+ return phy-ops-init(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+ int ret = -EINVAL;
+
+ if (phy-ops-exit)
+ ret = phy-ops-exit(phy);
+
+ pm_runtime_put_sync(phy-dev);
+
+ return ret;
+}
Do phy_init/phy_exit need to be mandatory ? What if there is really
nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
returned if a callback is not implemented, so PHY users can recognize
such situation and proceed ?
+static inline int phy_power_on(struct phy *phy)
+{
+ if (phy-ops-power_on)
+ return phy-ops-power_on(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+ if (phy-ops-power_off)
+ return phy-ops-power_off(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_get(phy-dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_get_sync(phy-dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_put(phy-dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_put_sync(phy-dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return;
+
+ pm_runtime_allow(phy-dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return;
+
+ pm_runtime_forbid(phy-dev);
+}
Do we need to have all these runtime PM wrappers ? I guess you
intended to avoid referencing phy-dev from the PHY consumers ?
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 00/14] ARM: OMAP2+: AM43x initial support
Hi Tony, On Mon, May 27, 2013 at 20:03:27, Mohammed, Afzal wrote: This series adds initial support for AM43x based SoC's. To boot AM43x, in addition to these patches, PRCM support is also needed, which would be posted later as a separate series. DT sources doesn't have ti,hwmod entry - this would be added along with PRCM support. AM43x SoC's are based on ARM Cortex-A9 with one core. AM43x is similar to AM335x in it's peripheral capabilities, except a few additional ones, with many of the peripheral register mapping's similar. AM43x has a sync timer, which is being used as clocksource. Clockevent used is 1ms dmtimer. SoC has PL310 L2 cache, support for it would be added later. soc_is_am43xx() is introduced to handle AM43x specific details and soc_is_am437x() is a subclass of it - first member of the class. AM43x is currently in pre-silicon stage and currently there are no public documents. This has been tested on a pre-silicon platform that emulates AM43x SoC with additional changes on top of this. AM335x based board (AM335x EVM) has been verfied to boot as earlier with this series. Baseline: v3.10-rc3 Dependency: ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature by Vaibhav Hiremath hvaib...@ti.com If you have any comments on this series please let me know, else if you are okay with this, please consider patches 1-10 for inclusion in the coming merge window. Patch 14/14 has been taken by Benoit and patches 11-13 are to be dropped (as per discussion in 11/14 thread) Regards Afzal
Re: [PATCH] rtc: rtc-twl: ensure IRQ is wakeup enabled
Hi Kevin,
On 06/01/2013 01:37 AM, Kevin Hilman wrote:
Currently, the RTC IRQ is never wakeup-enabled so is not capable of
bringing the system out of suspend.
On OMAP platforms, we have gotten by without this because the TWL RTC
is on an I2C-connected chip which is capable of waking up the OMAP via
the IO ring when the OMAP is in low-power states.
However, if the OMAP suspends without hitting the low-power states
(and the IO ring is not enabled), RTC wakeups will not work because
the IRQ is not wakeup enabled.
As I understand, IRQ wake up capabilities are set/clear simultaneously with
IRQ unmasking/masking on OMAP4+ in omap-wakeupgen.c.
So, it should work without this patch on OMAP4+.
But if TWL is used on non OMAP4+ platform then it is needed.
(OMAP3: I haven't found the place where IRQ wakeup capabilities are
configured,
would be appreciate if you can point me on)
To fix, ensure the RTC IRQ is wakeup enabled whenever the RTC alarm is
set.
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: Andrew Morton a...@linux-foundation.org
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
drivers/rtc/rtc-twl.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 8751a52..bbda0fd 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -213,12 +213,24 @@ static int mask_rtc_irq_bit(unsigned char bit)
static int twl_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ int irq = platform_get_irq(pdev, 0);
+ static bool twl_rtc_wake_enabled;
int ret;
- if (enabled)
+ if (enabled) {
ret = set_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
- else
+ if (device_can_wakeup(dev) !twl_rtc_wake_enabled) {
+ enable_irq_wake(irq);
+ twl_rtc_wake_enabled = true;
+ }
+ } else {
ret = mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
+ if (twl_rtc_wake_enabled) {
+ disable_irq_wake(irq);
+ twl_rtc_wake_enabled = false;
+ }
+ }
return ret;
}
twl-rtc has suspend/resume callbacks implemented, so I think it's the
better place
for this code and twl_rtc_wake_enabled can be dropped.
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: omap: convert to module_platform_driver()
Hi Kevin,
On 06/03/2013 11:59 PM, Kevin Hilman wrote:
Grygorii Strashko grygorii.stras...@ti.com writes:
The OMAP I2C driver has a relation to pinctrl-single driver. As result,
its probe will be deferred during system boot until late init time,
because the pinctrl-single is initizalized as moudle/device init time.
This, in turn, will delay initialization of all I2C devices (like mfd,
I2C regulators and etc.) and cause boot delay (more over, it can broken
initialization of drivers which are not ready to use deferred probe
mechanism yet, for example DSS).
There are no sense to keep OMAP I2C initialization on subsys init layer
any more, hence shift it to module/device layer where the i2c --
pinctrl-single dependency is resolved in drivers/Makefile now.
Cc: Wolfram Sang w...@the-dreams.de
Cc: Ben Dooks (embedded platforms) ben-li...@fluff.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Testing this patch with PATCH 1/2, the twl_rtc driver fails to correctly
initialize on OMAP3:
twl_rtc rtc.22: hctosys: invalid date/time
instead of the expected result:
twl_rtc rtc.22: setting system clock to 2000-01-01 00:00:00 UTC
(946684800)
so something is still not right for the init sequence.
Kevin
I think, the root cause of the problem isn't this patch - it's just yet
another side effect
of using deferred probes :). I've taken a look on twl-rtc code and found
possible error place
static int __init twl_rtc_init(void)
{
if (twl_class_is_4030()) -- here,
rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
else
rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
return platform_driver_register(twl4030rtc_driver);
}
In drivers/Makefile:
obj-$(CONFIG_RTC_LIB)+= rtc/ -- RTC is placed before I2C
obj-y+= i2c/ media/ - and only here I2C bus
instantiates TWL-core device
and configures twl_priv-twl_id
Thats why it's working on my OMAP4/twl6030 board. Could you check if
below fix will work on OMAP3:
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 8751a52..aaa5015 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -469,6 +469,11 @@ static int twl_rtc_probe(struct platform_device *pdev)
if (irq = 0)
goto out1;
+ if (twl_class_is_4030())
+ rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
+ else
+ rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
+
ret = twl_rtc_read_u8(rd_reg, REG_RTC_STATUS_REG);
if (ret 0)
goto out1;
@@ -610,11 +615,6 @@ static struct platform_driver twl4030rtc_driver = {
static int __init twl_rtc_init(void)
{
- if (twl_class_is_4030())
- rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
- else
- rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
-
return platform_driver_register(twl4030rtc_driver);
}
module_init(twl_rtc_init);
Unfortunately, I have no OMAP3 HW and can't check it.
Regards,
-grygorii
--
To unsubscribe from this list: send the line unsubscribe 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 11/11] i2c: omap: enhance pinctrl support
Hi Kevin, Gururaja On 05/31/2013 08:34 PM, Kevin Hilman wrote: Hebbar Gururaja gururaja.heb...@ti.com writes: Amend the I2C omap pin controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing an i2c transfer - idle after initial default, after resume default, and after each i2c xfer - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. Note: A .suspend .resume callback is added which simply puts the pins to sleep state upon suspend are moved to default idle state upon resume. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. (Changes based on i2c-nomadik.c) Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Wolfram Sang w...@the-dreams.de Cc: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org [...] @@ -664,7 +673,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) out: pm_runtime_mark_last_busy(dev-dev); + pm_runtime_put_autosuspend(dev-dev); + /* Optionally let pins go into idle state */ + if (!IS_ERR(dev-pins_idle)) + if (pinctrl_select_state(dev-pinctrl, dev-pins_idle)) + dev_err(dev-dev, could not set pins to idle state\n); This is wrong. You're changing the muxing before the device actually goes idle. Anything you want to happen when the device actually idles for real has to be in runtime PM callbacks. Looking below, I see it's already in the callbacks, so why is it here also? I have two questions regarding this patch the whole series: 1) PM runtime suspend/resume Current sequence: - resume |- omap_hwmod_enable() |- _enable() |- omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED) |- enable module (syscclocks) |- omap_i2c_runtime_resume() - suspend |- omap_i2c_runtime_suspend() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) |- omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE); The new order will change this sequence - *Is it safe?*: - resume |- omap_hwmod_enable() |- _enable() |- enable module (syscclocks) Is it valid to enable module before PINs? |- omap_i2c_runtime_resume() |- PINs state set to DEFAULT - suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) Is it valid to disable module after PINs? 2) System suspend (OFF-mode) with assumption that noirq stage will be used for PINs cfg Current implementation: handled in the same way as PM runtime The new implementation: -- total mess is here((: - suspend_noirq - I2C device can be still active because of PM auto-suspend |-_od_suspend_noirq |- omap_i2c_suspend_noirq |- PINs state set to SLEEP |- pm_generic_runtime_suspend |- omap_i2c_runtime_suspend() |- PINs state set to IDLE --- *oops* PINs state is IDLE and not SLEEP |- omap_device_idle() |- omap_hwmod_idle() |- _idle() |- disbale module (syscclocks) - resume_noirq - I2C was active before suspend |-_od_resume_noirq |- omap_hwmod_enable() |- _enable() |- enable module (syscclocks) |- pm_generic_runtime_resume |- omap_i2c_runtime_resume() |- PINs state set to DEFAULT --- |- omap_i2c_resume_noirq |- PINs state set to DEFAULT |- PINs state set to IDLE--- *big oops* we have active module and its PINs state is IDLE All mentioned above, applicable for most of all patches in series. And It seems, that this functionality can't be implemented in such way ( - OMAP device FW and Driver core might handle PINs states changing and drivers (DT) should provide set of available states only. Am I wrong? Regards, -grygorii [...] @@ -1300,6 +1348,10 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + if (!IS_ERR(_dev-pins_idle)) + if (pinctrl_select_state(_dev-pinctrl, _dev-pins_idle)) + dev_err(dev, could not set pins to idle state\n); + return 0; } 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 -- To unsubscribe from this list: send the line
Re: [net-next PATCH 1/8] drivers: net: phy: at803x code cleanup on register and unregister driver
Hello.
On 04-06-2013 10:10, Mugunthan V N wrote:
Make use of phy_drivers_register/phy_drivers_unregister to register/unregister
multiple phy drivers in a single module.
Cc: Matus Ujhelyi ujhely...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 35 ++-
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 45cbc10..a1063e1 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -108,8 +108,9 @@ static int at803x_config_init(struct phy_device *phydev)
return 0;
}
-/* ATHEROS 8035 */
-static struct phy_driver at8035_driver = {
+static struct phy_driver at803x_driver[] = {
+{
+ /* ATHEROS 8035 */
.phy_id = 0x004dd072,
.name = Atheros 8035 ethernet,
.phy_id_mask= 0xffef,
That's improper indentation. Needs to be shifted by one tab.
@@ -136,32 +135,18 @@ static struct phy_driver at8030_driver = {
.driver = {
.owner = THIS_MODULE,
},
-};
+} };
Looks ugly...
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe 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 v6 1/9] drivers: phy: add generic PHY framework
Hi,
On Tuesday 04 June 2013 03:51 PM, Sylwester Nawrocki wrote:
On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote:
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
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/phy/phy-bindings.txt | 66 +++
Documentation/phy.txt | 123 +
MAINTAINERS|7 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 13 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 539
include/linux/phy/phy.h| 248 +
9 files changed, 1005 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
+static inline int phy_init(struct phy *phy)
+{
+ pm_runtime_get_sync(phy-dev);
Hmm, no need to check return value here ? Also it looks a bit unexpected to
I purposely dint check the return values in order to support platforms
that don’t enable pm_runtime.
possibly have runtime_resume callback of a PHY device called before ops-init()
call ? It seems a bit unclear what the purpose of init() callback is.
Not really. Anything that is used to initialize the PHY (internal
configuration) can go in phy_init. Usually in runtime_resume callback,
optional functional clocks are enabled and also in some cases context
restore is done. So it really makes sense to enable clocks/module
(pm_runtime_get_sync) before doing a PHY configuration (phy_init).
+ if (phy-ops-init)
+ return phy-ops-init(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+ int ret = -EINVAL;
+
+ if (phy-ops-exit)
+ ret = phy-ops-exit(phy);
+
+ pm_runtime_put_sync(phy-dev);
+
+ return ret;
+}
Do phy_init/phy_exit need to be mandatory ? What if there is really
No. phy_init/phy_exit is not mandatory at all.
nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
returned if a callback is not implemented, so PHY users can recognize
such situation and proceed ?
So currently these APIs return -EINVAL if these callbacks are not
populated which is good enough IMHO.
+static inline int phy_power_on(struct phy *phy)
+{
+ if (phy-ops-power_on)
+ return phy-ops-power_on(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+ if (phy-ops-power_off)
+ return phy-ops-power_off(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_get(phy-dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_get_sync(phy-dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_put(phy-dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return -EINVAL;
+
+ return pm_runtime_put_sync(phy-dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return;
+
+ pm_runtime_allow(phy-dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+ if (WARN(IS_ERR(phy), Invalid PHY reference\n))
+ return;
+
+ pm_runtime_forbid(phy-dev);
+}
Do we need to have all these runtime PM wrappers ? I guess you
intended to avoid referencing phy-dev from the PHY consumers ?
Yeah.. I dint want pm_runtime of phy core device to be called from PHY
consumers.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
Re: [PATCHv2 1/3] arm: introduce config HAS_BANDGAP
Fabio, On 31-05-2013 11:12, Fabio Estevam wrote: On Wed, May 15, 2013 at 11:58 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: Introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag is they feature a bandgap device. This config entry follows the same idea behind ARCH_HAS_CPUFREQ. It would be nice if you explain what BANDGAP means here, since you introduce this option in this patch. Yeah, I didnt do it because bandgap is a common term used in digital circuits [1,2]. Also, as in this patch we do not add term different from the common used bandgap term, I believe it is self explanatory. I any case, I am resending with minor explanation. [1] - http://en.wikipedia.org/wiki/Bandgap_voltage_reference [2] - http://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
[PATCHv3 1/3] arm: introduce config HAS_BANDGAP
Bandgap is a device used to measure temperature on electronic equipments. It is widely used in digital integrated circuits. It is based on the dependency between silicon voltage and temperature. This patch introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag if they feature a bandgap device. This config entry follows the same idea behind ARCH_HAS_CPUFREQ. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Fabio Stevam feste...@gmail.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/Kconfig| 3 +++ arch/arm/mach-omap2/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index d423d58..bcbdec9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -174,6 +174,9 @@ config ARCH_HAS_CPUFREQ and that the relevant menu configurations are displayed for it. +config ARCH_HAS_BANDGAP + bool + config GENERIC_HWEIGHT bool default y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..8620ab5 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -4,6 +4,7 @@ config ARCH_OMAP config ARCH_OMAP2PLUS bool TI OMAP2/3/4/5 SoCs with device tree support if (ARCH_MULTI_V6 || ARCH_MULTI_V7) select ARCH_HAS_CPUFREQ + select ARCH_HAS_BANDGAP select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line unsubscribe 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: [net-next PATCH 1/8] drivers: net: phy: at803x code cleanup on register and unregister driver
On 6/4/2013 5:32 PM, Sergei Shtylyov wrote:
Hello.
On 04-06-2013 10:10, Mugunthan V N wrote:
Make use of phy_drivers_register/phy_drivers_unregister to
register/unregister
multiple phy drivers in a single module.
Cc: Matus Ujhelyi ujhely...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 35 ++-
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 45cbc10..a1063e1 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -108,8 +108,9 @@ static int at803x_config_init(struct phy_device
*phydev)
return 0;
}
-/* ATHEROS 8035 */
-static struct phy_driver at8035_driver = {
+static struct phy_driver at803x_driver[] = {
+{
+/* ATHEROS 8035 */
.phy_id= 0x004dd072,
.name= Atheros 8035 ethernet,
.phy_id_mask= 0xffef,
That's improper indentation. Needs to be shifted by one tab.
This indentation is as per the coding style followed in all ethernet
phy drivers. If this need so to be changed, it must be a separate patch
for all the ethernet phy drivers.
@@ -136,32 +135,18 @@ static struct phy_driver at8030_driver = {
.driver= {
.owner = THIS_MODULE,
},
-};
+} };
Looks ugly...
This is also the same as per the style followed in ethernet phy drivers
Please refer the below grep output
$ grep -rnaI } }; drivers/net/phy/*
drivers/net/phy/at803x.c:201:} };
drivers/net/phy/bcm63xx.c:101:} };
drivers/net/phy/bcm87xx.c:217:} };
drivers/net/phy/broadcom.c:829:} };
drivers/net/phy/cicada.c:130:} };
drivers/net/phy/davicom.c:183:} };
drivers/net/phy/icplus.c:254:} };
drivers/net/phy/lxt.c:313:} };
drivers/net/phy/micrel.c:323:} };
drivers/net/phy/smsc.c:242:} };
drivers/net/phy/ste10Xp.c:113:} };
drivers/net/phy/vitesse.c:192:} };
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/3] first pass converting omap4 clock data to DT
Hi Mike, On Mon, 2013-06-03 at 23:39 -0700, Mike Turquette wrote: This is a very incomplete conversion of a handful of OMAP4 PRCM clocks from the statically defined clock data in arch/arm/mach-omap2/cclock44xx_data.c to a new dts file in arch/arm/boot/dts/omap4-clocks.dtsi. I gave a quick try for this set and it seems to be working nicely, so for at least me this approach is fine. Feel free to add tested-by me if you like (for the basic clock bindings also.) Can't comment much on the DT stuff though as my experience is rather limited on it. I am not a DT expert so many of the choices here may be quite disgusting to look at, or may be on the right path. In particular I simply include the new omap4-clocks.dtsi from omap4.dtsi, which feels a bit kludgey. Also this series depends on the basic clock bindings RFC I posted earlier today[1]. I actually have an omap4-clock.dtsi file with many more clocks converted to the mux-clock, divider-clock, fixed-clock, fixed-factor and (unpublished) gate-clock bindings in my local repo, but it is not currently booting. I wanted to get this early preview out regardless. Any way I can get access to your local tree? Can you push a branch somewhere? I could provide you debugging support on this at least, as I spent quite a bit of time earlier moving the clock data under drivers/clk... I guess you are probably seeing similar issues I faced. -Tero [1] http://article.gmane.org/gmane.linux.kernel/1501216 Mike Turquette (3): clk: omap: introduce clock driver ARM: dts: omap4 clock data ARM: omap4: register DT clocks remove old data arch/arm/boot/dts/omap4-clocks.dtsi | 128 ++ arch/arm/boot/dts/omap4.dtsi | 2 + arch/arm/mach-omap2/cclock44xx_data.c | 54 ++ drivers/clk/Makefile | 1 + drivers/clk/omap/Makefile | 1 + drivers/clk/omap/clk.c| 55 +++ include/linux/clk/omap.h | 24 +++ 7 files changed, 217 insertions(+), 48 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi create mode 100644 drivers/clk/omap/Makefile create mode 100644 drivers/clk/omap/clk.c create mode 100644 include/linux/clk/omap.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: [net-next PATCH 1/8] drivers: net: phy: at803x code cleanup on register and unregister driver
On 06/04/2013 04:43 PM, Mugunthan V N wrote:
Make use of phy_drivers_register/phy_drivers_unregister to
register/unregister
multiple phy drivers in a single module.
Cc: Matus Ujhelyi ujhely...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/phy/at803x.c | 35 ++-
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 45cbc10..a1063e1 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -108,8 +108,9 @@ static int at803x_config_init(struct phy_device
*phydev)
return 0;
}
-/* ATHEROS 8035 */
-static struct phy_driver at8035_driver = {
+static struct phy_driver at803x_driver[] = {
+{
+/* ATHEROS 8035 */
.phy_id= 0x004dd072,
.name= Atheros 8035 ethernet,
.phy_id_mask= 0xffef,
That's improper indentation. Needs to be shifted by one tab.
This indentation is as per the coding style followed in all ethernet
phy drivers. If this need so to be changed, it must be a separate patch
for all the ethernet phy drivers.
@@ -136,32 +135,18 @@ static struct phy_driver at8030_driver = {
.driver= {
.owner = THIS_MODULE,
},
-};
+} };
Looks ugly...
This is also the same as per the style followed in ethernet phy drivers
Please refer the below grep output
$ grep -rnaI } }; drivers/net/phy/*
drivers/net/phy/at803x.c:201:} };
drivers/net/phy/bcm63xx.c:101:} };
drivers/net/phy/bcm87xx.c:217:} };
drivers/net/phy/broadcom.c:829:} };
drivers/net/phy/cicada.c:130:} };
drivers/net/phy/davicom.c:183:} };
drivers/net/phy/icplus.c:254:} };
drivers/net/phy/lxt.c:313:} };
drivers/net/phy/micrel.c:323:} };
drivers/net/phy/smsc.c:242:} };
drivers/net/phy/ste10Xp.c:113:} };
drivers/net/phy/vitesse.c:192:} };
Sorry for the noise, coldn't imagine they're all that bad. :-)
Regards
Mugunthan V N
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe 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 v6 1/9] drivers: phy: add generic PHY framework
Hi,
On 06/04/2013 02:26 PM, Kishon Vijay Abraham I wrote:
+static inline int phy_init(struct phy *phy)
+{
+ pm_runtime_get_sync(phy-dev);
Hmm, no need to check return value here ? Also it looks a bit unexpected to
I purposely dint check the return values in order to support platforms
that don’t enable pm_runtime.
Then I guess this should be called conditionally and any errors returned
if runtime PM is enabled ? Not sure if pm_runtime_enabled() would be
helpful such situation.
possibly have runtime_resume callback of a PHY device called before
ops-init()
call ? It seems a bit unclear what the purpose of init() callback is.
Not really. Anything that is used to initialize the PHY (internal
configuration) can go in phy_init. Usually in runtime_resume callback,
optional functional clocks are enabled and also in some cases context
restore is done. So it really makes sense to enable clocks/module
(pm_runtime_get_sync) before doing a PHY configuration (phy_init).
OK, that makes sense. All PHY device resources must be prepared anyway
before a PHY object is registered with the PHY core.
+ if (phy-ops-init)
+ return phy-ops-init(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+ int ret = -EINVAL;
+
+ if (phy-ops-exit)
+ ret = phy-ops-exit(phy);
+
+ pm_runtime_put_sync(phy-dev);
+
+ return ret;
+}
Do phy_init/phy_exit need to be mandatory ? What if there is really
No. phy_init/phy_exit is not mandatory at all.
nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
returned if a callback is not implemented, so PHY users can recognize
such situation and proceed ?
So currently these APIs return -EINVAL if these callbacks are not
populated which is good enough IMHO.
But -EINVAL could be well returned from the callback function. Perhaps
ENOTSUPP could be used instead ?
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] dwc3: omap: adapt dwc3 to use extcon framework
Kishon, What is the expectation when there is no palmas tied to dwc3/dwc3-omap ? Thank you Regards Ruchika On 06/03/2013 11:13 AM, Kishon Vijay Abraham I wrote: The first three patches deals with cleanup of extcon inorder to get through compilation without any issues. It also adds an API to get extcon device from dt node which I felt was missing. The next two patches deals with adapt dwc3 to use extcon framework. The 4th patch (usb: dwc3: omap: improve error handling of dwc3_omap_probe) should have ideally been sent to Felipe, however since there will be merge conflicts with the 5th patch (usb: dwc3: use extcon fwrk to receive connect/disconnect) in this series, I've sent in the same series. Once this patch series get merged, dwc3 in omap would be functional in device mode. However there is still some discussion on modelling SMPS10 regulator. Once that gets finalized, dwc3 should be functional in host mode as well. Kishon Vijay Abraham I (5): extcon: Add an API to get extcon device from dt node extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions usb: dwc3: omap: improve error handling of dwc3_omap_probe usb: dwc3: use extcon fwrk to receive connect/disconnect Documentation/devicetree/bindings/usb/omap-usb.txt |5 + drivers/extcon/Kconfig |2 +- drivers/extcon/extcon-class.c | 42 +++ drivers/usb/dwc3/dwc3-omap.c | 133 include/linux/extcon.h |8 ++ include/linux/usb/dwc3-omap.h | 30 - 6 files changed, 168 insertions(+), 52 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.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 09/11] mmc: omap_hsmmc: enhance pinctrl support
* Hebbar Gururaja gururaja.heb...@ti.com [130531 03:19]: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. There's a similar patch in the [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode thread. It also makes the SDIO interrupts to work, so we need to consider that too. We can merge the dynamic pinmuxing parts separately, but they should be in a separate function like I posted later on in the thread above. 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 RFC 1/3] clk: omap: introduce clock driver
* Mike Turquette mturque...@linaro.org [130603 23:45]: Parses OMAP clock data from DT and registers those clocks with the clock framework. dt_omap_clk_init must be called early during boot for timer initialization so it is exported and called from the existing clock code instead of probing like a real driver. Thanks for doing this, makes sense to me. I have queued up patches to make omap4 DT only, so this is the way to go. --- /dev/null +++ b/include/linux/clk/omap.h @@ -0,0 +1,24 @@ +/* + * Copyright (C) 2010 Broadcom + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __LINUX_CLK_OMAP_H_ +#define __LINUX_CLK_OMAP_H_ + +int __init dt_omap_clk_init(void); + +#endif Maybe leave out the Broadcom copyright from this header? :) 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 RFC 2/3] ARM: dts: omap4 clock data
* Mike Turquette mturque...@linaro.org [130603 23:45]: This is a first pass at creating a unique node for each clock in the OMAP4 power, reset and clock manager (PRCM). So far I have only converted mux clocks fixed-rate clocks, which coexist with the current clock data in the kernel. The rest needs to be done but better to publish early and often to see what others think of this approach. +/* FIXME need to print the address directly */ +/* +#include ../../mach-omap2/prm44xx.h +#include ../../mach-omap2/cm2_44xx.h +#include ../../mach-omap2/cm1_44xx.h +*/ I don't think you're using the above includes any longer in this file? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: Let users disable Probe an I2C bus for certain devices
Currently the I2C devices instantiation Method 3 Probe an I2C bus for
certain devices (see Documentation/i2c/instantiating-devices) is always
enabled for all platforms (boards) and can't be disabled.
This feature introduces a system boot time delay for boards,
where I2C devices topology is explicitly defined in DT or platform code
(Method 1 and Method 2 are used only) and especially when i2c-gpio is used.
For example:
When CONFIG_SENSORS_LM75 option was enabled for omap4-sdp board -
it introduces 5-6 ms boot delay.
When CONFIG_SENSORS_LM75 option was enabled for omap5-uevm board,
where i2c-gpio is used for HDMI edid reading - it introduces up to 5 sec boot
delay.
Hence, introduce CONFIG_I2C_DISABLE_DEVICE_DETECTION configuration option
to allow disabling of I2C devices instantiation Method 3 Probe an I2C bus
for certain devices if it's not needed (usually for embedded systems).
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-omap@vger.kernel.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/Kconfig| 10 ++
drivers/i2c/i2c-core.c |6 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index e380c6e..f7b220b 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -124,4 +124,14 @@ config I2C_DEBUG_BUS
a problem with I2C support and want to see more of what is going
on.
+config I2C_DISABLE_DEVICE_DETECTION
+ bool I2C Disable device detection
+ default n
+ help
+ Say Y here, if you have explicitly defined I2C device topology in DT
+ or platform code and don't need to detect presence of supported I2C
+ devices automatically (Documentation/i2c/instantiating-devices -
+ Method 1 and Method 2 are used only). Enabling this option allows to
+ reduce system boot time, especially in case when i2c-gpio driver is
used.
+
endif # I2C
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 48e31ed..d5ab7a3 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -54,7 +54,9 @@ static DEFINE_MUTEX(core_lock);
static DEFINE_IDR(i2c_adapter_idr);
static struct device_type i2c_client_type;
+#ifndef CONFIG_I2C_DISABLE_DEVICE_DETECTION
static int i2c_detect(struct i2c_adapter *adapter, struct i2c_driver *driver);
+#endif
/* - */
@@ -958,7 +960,9 @@ static int i2c_do_add_adapter(struct i2c_driver *driver,
struct i2c_adapter *adap)
{
/* Detect supported devices on that bus, and instantiate them */
+#ifndef CONFIG_I2C_DISABLE_DEVICE_DETECTION
i2c_detect(adap, driver);
+#endif
/* Let legacy drivers scan this bus for matching devices */
if (driver-attach_adapter) {
@@ -1672,6 +1676,7 @@ static int i2c_default_probe(struct i2c_adapter *adap,
unsigned short addr)
return err = 0;
}
+#ifndef CONFIG_I2C_DISABLE_DEVICE_DETECTION
static int i2c_detect_address(struct i2c_client *temp_client,
struct i2c_driver *driver)
{
@@ -1760,6 +1765,7 @@ static int i2c_detect(struct i2c_adapter *adapter, struct
i2c_driver *driver)
kfree(temp_client);
return err;
}
+#endif
int i2c_probe_func_quick_read(struct i2c_adapter *adap, unsigned short addr)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtc: rtc-twl: ensure IRQ is wakeup enabled
Grygorii Strashko grygorii.stras...@ti.com writes:
Hi Kevin,
On 06/01/2013 01:37 AM, Kevin Hilman wrote:
Currently, the RTC IRQ is never wakeup-enabled so is not capable of
bringing the system out of suspend.
On OMAP platforms, we have gotten by without this because the TWL RTC
is on an I2C-connected chip which is capable of waking up the OMAP via
the IO ring when the OMAP is in low-power states.
However, if the OMAP suspends without hitting the low-power states
(and the IO ring is not enabled), RTC wakeups will not work because
the IRQ is not wakeup enabled.
As I understand, IRQ wake up capabilities are set/clear simultaneously with
IRQ unmasking/masking on OMAP4+ in omap-wakeupgen.c.
So, it should work without this patch on OMAP4+.
It might work on OMAP4 for wakeup from suspend, but without properly
declaring the IRQ as a wakeup source, it will not abort suspend if the
RTC fires during the suspend process. To abort suspend, the IRQ must be
declared as a wakeup IRQ.
But if TWL is used on non OMAP4+ platform then it is needed. (OMAP3:
I haven't found the place where IRQ wakeup capabilities are
configured, would be appreciate if you can point me on)
IRQ wakeup is a genirq feature that trickles into the irq_chip (in OMAP3
case, it's the twl4030 irq_chip.)
On OMAP3, as mentioned in the changelog, RTC wake has been working fine
without this because we default to CORE retention, so wakeup happens via
the IO ring. However, if you prevent retention during suspend, then
this IRQ will not wake the system.
Kevin
To fix, ensure the RTC IRQ is wakeup enabled whenever the RTC alarm is
set.
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: Andrew Morton a...@linux-foundation.org
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@linaro.org
---
drivers/rtc/rtc-twl.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 8751a52..bbda0fd 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -213,12 +213,24 @@ static int mask_rtc_irq_bit(unsigned char bit)
static int twl_rtc_alarm_irq_enable(struct device *dev, unsigned
enabled)
{
+struct platform_device *pdev = to_platform_device(dev);
+int irq = platform_get_irq(pdev, 0);
+static bool twl_rtc_wake_enabled;
int ret;
- if (enabled)
+if (enabled) {
ret = set_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
-else
+if (device_can_wakeup(dev) !twl_rtc_wake_enabled) {
+enable_irq_wake(irq);
+twl_rtc_wake_enabled = true;
+}
+} else {
ret = mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
+if (twl_rtc_wake_enabled) {
+disable_irq_wake(irq);
+twl_rtc_wake_enabled = false;
+}
+}
return ret;
}
twl-rtc has suspend/resume callbacks implemented, so I think it's the
better place
for this code and twl_rtc_wake_enabled can be dropped.
In theory, that might be the better place (and that's where I put these
at first), but unfortunately, it doesn't work that way because the
twl6030-irq core enables/diables the parent IRQ wake feature using PM
notifiers (which was done to avoid potential lock recursion[1].)
During suspend, the notifier runs at suspend_prepare() time, which is
well before the driver's -suspend() method is called. The result is
that the parents IRQ wakeup capabilies are never set.
Kevin
[1]
commit ab2b9260df67e29d5bd69d989f2f84f8c2ed4238
Author: Todd Poynor toddpoy...@google.com
Date: Tue Oct 4 11:52:29 2011 +0200
mfd: Fix twl6030 lockdep recursion warning on setting wake IRQs
LOCKDEP explicitly sets all irq_desc locks as a single lock-class,
causing possible recursive locking detected when the TWL RTC
driver calls through enable_irq_wake to twl6030_irq_set_wake,
which recursively calls irq_set_irq_wake. Although the
irq_desc and lock are different, LOCKDEP treats these as
equivalent, presumably due to problems that can be incurred
when locking more than one irq_desc, so best to avoid this.
Suspend/resume actions implemented as PM notifiers to avoid
touch the TWL core for this.
Signed-off-by: Todd Poynor toddpoy...@google.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Samuel Ortiz sa...@linux.intel.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] rtc: rtc-twl: ensure IRQ is wakeup enabled
Andrew Morton a...@linux-foundation.org writes:
On Fri, 31 May 2013 15:37:07 -0700 Kevin Hilman khil...@linaro.org wrote:
Currently, the RTC IRQ is never wakeup-enabled so is not capable of
bringing the system out of suspend.
On OMAP platforms, we have gotten by without this because the TWL RTC
is on an I2C-connected chip which is capable of waking up the OMAP via
the IO ring when the OMAP is in low-power states.
However, if the OMAP suspends without hitting the low-power states
(and the IO ring is not enabled), RTC wakeups will not work because
the IRQ is not wakeup enabled.
To fix, ensure the RTC IRQ is wakeup enabled whenever the RTC alarm is
set.
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -213,12 +213,24 @@ static int mask_rtc_irq_bit(unsigned char bit)
static int twl_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
{
+struct platform_device *pdev = to_platform_device(dev);
+int irq = platform_get_irq(pdev, 0);
+static bool twl_rtc_wake_enabled;
int ret;
-if (enabled)
+if (enabled) {
ret = set_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
-else
+if (device_can_wakeup(dev) !twl_rtc_wake_enabled) {
+enable_irq_wake(irq);
+twl_rtc_wake_enabled = true;
+}
+} else {
ret = mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
+if (twl_rtc_wake_enabled) {
+disable_irq_wake(irq);
+twl_rtc_wake_enabled = false;
+}
+}
Why do we need this (slightly racy) logic with twl_rtc_wake_enabled?
Other drivers don't do this.
I suspect the other drivers don't do this because they're making these
calls in their suspend/resume callbacks and can make assumptions about
the order and balance of the calls (e.g. the PM core will not call your
resume callback if your suspend callback hasn't been called.) What's
being protected against is imbalanced calling of the IRQ wake calls
(e.g. calling disable_irq_wake() on an IRQ where enable_irq_wake() has
not been called.)
In this patch, I'm using the rtc_alarm_irq_enable() function instead of
the suspend/resume functions because of some limitations of parent
device of this one (I described that at the end of a previous reponse to
this thread[1].) Because of that, I cannot make the same assumptions
about the ordering of enable/disable calls to this function.
Should we test device_may_wakeup() befre running disable_irq_wake()?
Most drivers seem to do this, but it's all a bit foggy.
I suppose I could've added that check too for symmetry, but it would be
redundant because the twl_rtc_wake_enabled flag can only be set when
device_can_wakeup() == true.
Kevin
[1] http://marc.info/?l=linux-omapm=137036801320665w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Let users disable Probe an I2C bus for certain devices
On Tue, Jun 04, 2013 at 08:33:42PM +0300, Grygorii Strashko wrote: Currently the I2C devices instantiation Method 3 Probe an I2C bus for certain devices (see Documentation/i2c/instantiating-devices) is always enabled for all platforms (boards) and can't be disabled. Not true. Set .class = 0 for your adapter. I always ask authors of new drivers if they really need to set .class to something. signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Jason Cooper ja...@lakedaemon.net writes:
On Mon, Jun 03, 2013 at 03:19:25PM -0700, Kevin Hilman wrote:
Florian Vaussard florian.vauss...@epfl.ch writes:
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Therefore, configure the defaults for the
SYS_NIRQ pin in the twl4030 DTS file.
Boards that hook up the twl4030 differently can easily override this
in their board-specific DTS file.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/twl4030.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi
b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..c7fe9f6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -13,6 +13,8 @@
compatible = ti,twl4030;
interrupt-controller;
#interrupt-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = twl4030_pins;
rtc {
compatible = ti,twl4030-rtc;
@@ -92,3 +94,18 @@
#pwm-cells = 2;
};
};
+
+omap3_pmx_core {
Here you are making the TWL4030 to explicitly depend on OMAP3. Could
this chip be used by another target? If the case, I would put this
piece of code in the files including twl4030. Otherwise it's ok here.
I talked this over with Tony before posting. In theorry, it could be
used on other platforms. In practice, it's only used on OMAP. We can
easily move this to board files if needed later, but thought it would be
simpler to put it here. I'll let Benoit decide.
What about omap boards that don't use the twl4030? eg I'm currently
tinkering with a board that uses a tps6507x...
Then you'll be inclding tps6507x.dtsi instead of twl4030.dtsi and won't
be affected by this patch at all.
Your board file should setup the muxing (using this as an example) for
how your board wires the TPS chip to the OMAP.
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 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
On Tue, Jun 04, 2013 at 10:58:46AM -0700, Kevin Hilman wrote:
Jason Cooper ja...@lakedaemon.net writes:
On Mon, Jun 03, 2013 at 03:19:25PM -0700, Kevin Hilman wrote:
Florian Vaussard florian.vauss...@epfl.ch writes:
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Therefore, configure the defaults for the
SYS_NIRQ pin in the twl4030 DTS file.
Boards that hook up the twl4030 differently can easily override this
in their board-specific DTS file.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/twl4030.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi
b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..c7fe9f6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -13,6 +13,8 @@
compatible = ti,twl4030;
interrupt-controller;
#interrupt-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = twl4030_pins;
rtc {
compatible = ti,twl4030-rtc;
@@ -92,3 +94,18 @@
#pwm-cells = 2;
};
};
+
+omap3_pmx_core {
Here you are making the TWL4030 to explicitly depend on OMAP3. Could
this chip be used by another target? If the case, I would put this
piece of code in the files including twl4030. Otherwise it's ok here.
I talked this over with Tony before posting. In theorry, it could be
used on other platforms. In practice, it's only used on OMAP. We can
easily move this to board files if needed later, but thought it would be
simpler to put it here. I'll let Benoit decide.
What about omap boards that don't use the twl4030? eg I'm currently
tinkering with a board that uses a tps6507x...
Then you'll be inclding tps6507x.dtsi instead of twl4030.dtsi and won't
be affected by this patch at all.
Gah! I saw omap3_pmx_core being modified and missed that the mod was in
twl4030.dtsi. Of course, you are right.
Your board file should setup the muxing (using this as an example) for
how your board wires the TPS chip to the OMAP.
Yes, that's the fun part, I'm trying to get a vanilla kernel to boot on
the Seagate Wireless Plus. They didn't exactly hand out schematics ;-)
thx,
Jason.
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: omap: convert to module_platform_driver()
Grygorii Strashko grygorii.stras...@ti.com writes:
Hi Kevin,
On 06/03/2013 11:59 PM, Kevin Hilman wrote:
Grygorii Strashko grygorii.stras...@ti.com writes:
The OMAP I2C driver has a relation to pinctrl-single driver. As result,
its probe will be deferred during system boot until late init time,
because the pinctrl-single is initizalized as moudle/device init time.
This, in turn, will delay initialization of all I2C devices (like mfd,
I2C regulators and etc.) and cause boot delay (more over, it can broken
initialization of drivers which are not ready to use deferred probe
mechanism yet, for example DSS).
There are no sense to keep OMAP I2C initialization on subsys init layer
any more, hence shift it to module/device layer where the i2c --
pinctrl-single dependency is resolved in drivers/Makefile now.
Cc: Wolfram Sang w...@the-dreams.de
Cc: Ben Dooks (embedded platforms) ben-li...@fluff.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Testing this patch with PATCH 1/2, the twl_rtc driver fails to correctly
initialize on OMAP3:
twl_rtc rtc.22: hctosys: invalid date/time
instead of the expected result:
twl_rtc rtc.22: setting system clock to 2000-01-01 00:00:00 UTC
(946684800)
so something is still not right for the init sequence.
Kevin
I think, the root cause of the problem isn't this patch - it's just
yet another side effect
of using deferred probes :). I've taken a look on twl-rtc code and
found possible error place
static int __init twl_rtc_init(void)
{
if (twl_class_is_4030()) -- here,
rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
else
rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
return platform_driver_register(twl4030rtc_driver);
}
In drivers/Makefile:
obj-$(CONFIG_RTC_LIB)+= rtc/ -- RTC is placed before I2C
obj-y+= i2c/ media/ - and only here I2C bus
instantiates TWL-core device
and configures twl_priv-twl_id
Thats why it's working on my OMAP4/twl6030 board. Could you check if
below fix will work on OMAP3:
Yes, your fix works. Thanks for digging into it.
Care to send a proper patch? Please be sure to send to Andrew Morton
also, since he'll be the one to queue the RTC patch.
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 8751a52..aaa5015 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -469,6 +469,11 @@ static int twl_rtc_probe(struct platform_device *pdev)
if (irq = 0)
goto out1;
+ if (twl_class_is_4030())
+ rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
+ else
+ rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
+
ret = twl_rtc_read_u8(rd_reg, REG_RTC_STATUS_REG);
if (ret 0)
goto out1;
@@ -610,11 +615,6 @@ static struct platform_driver twl4030rtc_driver = {
static int __init twl_rtc_init(void)
{
- if (twl_class_is_4030())
- rtc_reg_map = (u8 *) twl4030_rtc_reg_map;
- else
- rtc_reg_map = (u8 *) twl6030_rtc_reg_map;
-
return platform_driver_register(twl4030rtc_driver);
}
module_init(twl_rtc_init);
Unfortunately, I have no OMAP3 HW and can't check it.
I suggest you find a Beagle or Gumstix/Overo type board someplace.
There is an abundance of cheap OMAP3 hardware available.
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: [RFC 09/42] drivers/i2c/busses: don't check resource with devm_ioremap_resource
Wolfram Sang w...@the-dreams.de writes: devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: Wolfram Sang w...@the-dreams.de Acked-by: Kevin Hilman khil...@linaro.org # for i2c-omap.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: [PATCH RFC 2/3] ARM: dts: omap4 clock data
* Mike Turquette mturque...@linaro.org [130604 11:40]: Quoting Tony Lindgren (2013-06-04 07:55:43) * Mike Turquette mturque...@linaro.org [130603 23:45]: This is a first pass at creating a unique node for each clock in the OMAP4 power, reset and clock manager (PRCM). So far I have only converted mux clocks fixed-rate clocks, which coexist with the current clock data in the kernel. The rest needs to be done but better to publish early and often to see what others think of this approach. +/* FIXME need to print the address directly */ +/* +#include ../../mach-omap2/prm44xx.h +#include ../../mach-omap2/cm2_44xx.h +#include ../../mach-omap2/cm1_44xx.h +*/ I don't think you're using the above includes any longer in this file? Correct. I actually spotted this before emailing the patches out at midnight, but by then I didn't care to fix it. The benefits of marking a patch as RFC ;-) :) I had a mind to use the new preprocessor capabilities of dtc for the PRCM bit masks and shift values, but instead I ended up using the raw hex values. I've actually come to prefer using the raw hex values for DT, which I think makes more sense for a description of the hardware which is not tied to any Linux implementation. Agreed, especially if the value is only used once. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] USB: PHY: Improve PHY selection logic
Hi, On Tue, Jun 04, 2013 at 10:16:50AM +0300, Roger Quadros wrote: On 06/03/2013 08:47 PM, Greg KH wrote: On Fri, May 31, 2013 at 02:29:01PM +0300, Roger Quadros wrote: Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. Felipe needs to take these, not I. Felipe, Could you please take these if appropriate? Thanks. it's for v3.11 merge window, right ? I think I'll enjoy the rest of my vacations before taking these patches ;-) I'll be back on office next monday, cheers -- balbi signature.asc Description: Digital signature
Re: [net-next PATCH 0/8] add phy driver for Atheros AR8031 and CPSW phy-mode DT enhancement
From: Mugunthan V N mugunthan...@ti.com Date: Tue, 4 Jun 2013 11:40:03 +0530 This patch series adds the following feature * Atheros phy driver code cleanup * Add AT8031 phy driver to at803x driver * Add RGMII tx delay support via phy_if * Add phy_if DT enhancement to CPSW Driver and DT Series applied to net-next, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] dwc3: omap: adapt dwc3 to use extcon framework
Hi Ruchika, On Tuesday 04 June 2013 07:53 PM, Ruchika Kharwar wrote: Kishon, What is the expectation when there is no palmas tied to dwc3/dwc3-omap ? In the probe of dwc3-omap I have this check if (of_property_read_bool(node, extcon)) So If dwc3 node does not have extcon property, it wont try to get extcon device at all. You can refer this patch to see how its handled usb: dwc3: use extcon fwrk to receive connect/disconnect. 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 v6 1/9] drivers: phy: add generic PHY framework
Hi,
On Tuesday 04 June 2013 07:13 PM, Sylwester Nawrocki wrote:
Hi,
On 06/04/2013 02:26 PM, Kishon Vijay Abraham I wrote:
+static inline int phy_init(struct phy *phy)
+{
+ pm_runtime_get_sync(phy-dev);
Hmm, no need to check return value here ? Also it looks a bit unexpected to
I purposely dint check the return values in order to support platforms
that don’t enable pm_runtime.
Then I guess this should be called conditionally and any errors returned
if runtime PM is enabled ? Not sure if pm_runtime_enabled() would be
helpful such situation.
Indeed. I think it can be used.
possibly have runtime_resume callback of a PHY device called before ops-init()
call ? It seems a bit unclear what the purpose of init() callback is.
Not really. Anything that is used to initialize the PHY (internal
configuration) can go in phy_init. Usually in runtime_resume callback,
optional functional clocks are enabled and also in some cases context
restore is done. So it really makes sense to enable clocks/module
(pm_runtime_get_sync) before doing a PHY configuration (phy_init).
OK, that makes sense. All PHY device resources must be prepared anyway
before a PHY object is registered with the PHY core.
+ if (phy-ops-init)
+ return phy-ops-init(phy);
+
+ return -EINVAL;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+ int ret = -EINVAL;
+
+ if (phy-ops-exit)
+ ret = phy-ops-exit(phy);
+
+ pm_runtime_put_sync(phy-dev);
+
+ return ret;
+}
Do phy_init/phy_exit need to be mandatory ? What if there is really
No. phy_init/phy_exit is not mandatory at all.
nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
returned if a callback is not implemented, so PHY users can recognize
such situation and proceed ?
So currently these APIs return -EINVAL if these callbacks are not
populated which is good enough IMHO.
But -EINVAL could be well returned from the callback function. Perhaps
ENOTSUPP could be used instead ?
hmm.. could be..
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
