Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1291963 > unrolled thread

[PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Kishon Vijay Abraham I <kishon@ti.com> - 2015-12-15 10:20 +0100
    [PATCH v3 1/9] phy: ti-pipe3: introduce local struct device* in probe Kishon Vijay Abraham I <kishon@ti.com> - 2015-12-15 10:30 +0100
    [PATCH v3 3/9] phy: ti-pipe3: move sysctrl initialization to a separate function Kishon Vijay Abraham I <kishon@ti.com> - 2015-12-15 10:30 +0100
    Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Arnd Bergmann <arnd@arndb.de> - 2015-12-15 12:00 +0100
      Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Kishon Vijay Abraham I <kishon@ti.com> - 2015-12-15 12:20 +0100
        Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Arnd Bergmann <arnd@arndb.de> - 2015-12-15 13:00 +0100
          Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Kishon Vijay Abraham I <kishon@ti.com> - 2015-12-15 13:50 +0100
            Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Tony Lindgren <tony@atomide.com> - 2015-12-15 16:30 +0100
              Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg Kishon Vijay Abraham I <kishon@ti.com> - 2015-12-18 11:20 +0100

#1291963 — [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

This series is basically to deprecate using phy-omap-control and use
syscon APIs to program the control module registers.

Changes from v2:
No changes.

Changes from v1:
*) cleanup ti_pipe3_probe in multiple steps
*) other minor cleanups

Changes from [1] in PHY patches include
*) cleanup ti_pipe3_probe
*) have mask, power_on and power_off values in usb_phy_data for
   omap-usb2 phy

The patches have been pushed to
	git://git.ti.com/linux-phy/linux-phy.git syscon

[1] -> https://lkml.org/lkml/2015/6/23/189

All the testing was done both before applying the dt patches and after
applying the dt patches (dt patches will be posted shortly).

Logs with SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025205/
DRA7 EVM  : http://pastebin.ubuntu.com/14025212/
AM43XX EVM: http://pastebin.ubuntu.com/14025222/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025228/

Logs without SYSCON DT

DRA72 EVM : http://pastebin.ubuntu.com/14025233/
DRA7 EVM  : http://pastebin.ubuntu.com/14025238/
AM43XX EVM: http://pastebin.ubuntu.com/14025329/
OMAP5 UEVM: http://pastebin.ubuntu.com/14025248/

The config I used: http://pastebin.ubuntu.com/14025336/

Kishon Vijay Abraham I (9):
  phy: ti-pipe3: introduce local struct device* in probe
  phy: ti-pipe3: move clk initialization to a separate function
  phy: ti-pipe3: move sysctrl initialization to a separate function
  phy: ti-pipe3: move mem resource initialization to a separate
    function
  phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during
    probe
  phy: ti-pipe3: use *syscon* framework API to power on/off the PHY
  phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY
  phy: omap-usb2: use omap_usb_power_off to power off the PHY during
    probe
  phy: omap-usb2: use *syscon* framework API to power on/off the PHY

 Documentation/devicetree/bindings/phy/ti-phy.txt |   20 +-
 drivers/phy/phy-omap-usb2.c                      |   96 +++++--
 drivers/phy/phy-ti-pipe3.c                       |  304 ++++++++++++++++------
 include/linux/phy/omap_usb.h                     |   23 ++
 4 files changed, 340 insertions(+), 103 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1291969 — [PATCH v3 1/9] phy: ti-pipe3: introduce local struct device* in probe

No functional change. Introduce local struct device pointer in
probe and replace using &pdev->dev/phy->dev with the local
device pointer. This is in preparation to split ti_pipe3_probe
and add separate functions for getting mem resource, getting
sysctrl and getting clocks.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |   54 ++++++++++++++++++++++----------------------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 93bc112..c511105 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -319,40 +319,41 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	struct platform_device *control_pdev;
 	const struct of_device_id *match;
 	struct clk *clk;
+	struct device *dev = &pdev->dev;
 
-	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
+	phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy)
 		return -ENOMEM;
 
-	phy->dev		= &pdev->dev;
+	phy->dev		= dev;
 
 	if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-		match = of_match_device(ti_pipe3_id_table, &pdev->dev);
+		match = of_match_device(ti_pipe3_id_table, dev);
 		if (!match)
 			return -EINVAL;
 
 		phy->dpll_map = (struct pipe3_dpll_map *)match->data;
 		if (!phy->dpll_map) {
-			dev_err(&pdev->dev, "no DPLL data\n");
+			dev_err(dev, "no DPLL data\n");
 			return -EINVAL;
 		}
 
 		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 						   "pll_ctrl");
-		phy->pll_ctrl_base = devm_ioremap_resource(&pdev->dev, res);
+		phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
 		if (IS_ERR(phy->pll_ctrl_base))
 			return PTR_ERR(phy->pll_ctrl_base);
 
-		phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
+		phy->sys_clk = devm_clk_get(dev, "sysclk");
 		if (IS_ERR(phy->sys_clk)) {
-			dev_err(&pdev->dev, "unable to get sysclk\n");
+			dev_err(dev, "unable to get sysclk\n");
 			return -EINVAL;
 		}
 	}
 
-	phy->refclk = devm_clk_get(phy->dev, "refclk");
+	phy->refclk = devm_clk_get(dev, "refclk");
 	if (IS_ERR(phy->refclk)) {
-		dev_err(&pdev->dev, "unable to get refclk\n");
+		dev_err(dev, "unable to get refclk\n");
 		/* older DTBs have missing refclk in SATA PHY
 		 * so don't bail out in case of SATA PHY.
 		 */
@@ -361,9 +362,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	}
 
 	if (!of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
-		phy->wkupclk = devm_clk_get(phy->dev, "wkupclk");
+		phy->wkupclk = devm_clk_get(dev, "wkupclk");
 		if (IS_ERR(phy->wkupclk)) {
-			dev_err(&pdev->dev, "unable to get wkupclk\n");
+			dev_err(dev, "unable to get wkupclk\n");
 			return PTR_ERR(phy->wkupclk);
 		}
 	} else {
@@ -371,14 +372,14 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 		phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
 							"syscon-pllreset");
 		if (IS_ERR(phy->dpll_reset_syscon)) {
-			dev_info(&pdev->dev,
+			dev_info(dev,
 				 "can't get syscon-pllreset, sata dpll won't idle\n");
 			phy->dpll_reset_syscon = NULL;
 		} else {
 			if (of_property_read_u32_index(node,
 						       "syscon-pllreset", 1,
 						       &phy->dpll_reset_reg)) {
-				dev_err(&pdev->dev,
+				dev_err(dev,
 					"couldn't get pllreset reg. offset\n");
 				return -EINVAL;
 			}
@@ -387,30 +388,30 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
 	if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
 
-		clk = devm_clk_get(phy->dev, "dpll_ref");
+		clk = devm_clk_get(dev, "dpll_ref");
 		if (IS_ERR(clk)) {
-			dev_err(&pdev->dev, "unable to get dpll ref clk\n");
+			dev_err(dev, "unable to get dpll ref clk\n");
 			return PTR_ERR(clk);
 		}
 		clk_set_rate(clk, 1500000000);
 
-		clk = devm_clk_get(phy->dev, "dpll_ref_m2");
+		clk = devm_clk_get(dev, "dpll_ref_m2");
 		if (IS_ERR(clk)) {
-			dev_err(&pdev->dev, "unable to get dpll ref m2 clk\n");
+			dev_err(dev, "unable to get dpll ref m2 clk\n");
 			return PTR_ERR(clk);
 		}
 		clk_set_rate(clk, 100000000);
 
-		clk = devm_clk_get(phy->dev, "phy-div");
+		clk = devm_clk_get(dev, "phy-div");
 		if (IS_ERR(clk)) {
-			dev_err(&pdev->dev, "unable to get phy-div clk\n");
+			dev_err(dev, "unable to get phy-div clk\n");
 			return PTR_ERR(clk);
 		}
 		clk_set_rate(clk, 100000000);
 
-		phy->div_clk = devm_clk_get(phy->dev, "div-clk");
+		phy->div_clk = devm_clk_get(dev, "div-clk");
 		if (IS_ERR(phy->div_clk)) {
-			dev_err(&pdev->dev, "unable to get div-clk\n");
+			dev_err(dev, "unable to get div-clk\n");
 			return PTR_ERR(phy->div_clk);
 		}
 	} else {
@@ -419,13 +420,13 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
 	control_node = of_parse_phandle(node, "ctrl-module", 0);
 	if (!control_node) {
-		dev_err(&pdev->dev, "Failed to get control device phandle\n");
+		dev_err(dev, "Failed to get control device phandle\n");
 		return -EINVAL;
 	}
 
 	control_pdev = of_find_device_by_node(control_node);
 	if (!control_pdev) {
-		dev_err(&pdev->dev, "Failed to get control device\n");
+		dev_err(dev, "Failed to get control device\n");
 		return -EINVAL;
 	}
 
@@ -434,7 +435,7 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	omap_control_phy_power(phy->control_dev, 0);
 
 	platform_set_drvdata(pdev, phy);
-	pm_runtime_enable(phy->dev);
+	pm_runtime_enable(dev);
 
 	/*
 	 * Prevent auto-disable of refclk for SATA PHY due to Errata i783
@@ -446,13 +447,12 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 		}
 	}
 
-	generic_phy = devm_phy_create(phy->dev, NULL, &ops);
+	generic_phy = devm_phy_create(dev, NULL, &ops);
 	if (IS_ERR(generic_phy))
 		return PTR_ERR(generic_phy);
 
 	phy_set_drvdata(generic_phy, phy);
-	phy_provider = devm_of_phy_provider_register(phy->dev,
-			of_phy_simple_xlate);
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
 	if (IS_ERR(phy_provider))
 		return PTR_ERR(phy_provider);
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291971 — [PATCH v3 3/9] phy: ti-pipe3: move sysctrl initialization to a separate function

No functional change. Moved sysctrl initialization done in probe to a
separate function as part of cleaning up ti_pipe3_probe.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 drivers/phy/phy-ti-pipe3.c |   78 +++++++++++++++++++++++++-------------------
 1 file changed, 45 insertions(+), 33 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3379a4d..3154da0 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -376,6 +376,48 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
 	return 0;
 }
 
+static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
+{
+	struct device *dev = phy->dev;
+	struct device_node *node = dev->of_node;
+	struct device_node *control_node;
+	struct platform_device *control_pdev;
+
+	control_node = of_parse_phandle(node, "ctrl-module", 0);
+	if (!control_node) {
+		dev_err(dev, "Failed to get control device phandle\n");
+		return -EINVAL;
+	}
+
+	control_pdev = of_find_device_by_node(control_node);
+	if (!control_pdev) {
+		dev_err(dev, "Failed to get control device\n");
+		return -EINVAL;
+	}
+
+	phy->control_dev = &control_pdev->dev;
+
+	if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
+		phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
+							"syscon-pllreset");
+		if (IS_ERR(phy->dpll_reset_syscon)) {
+			dev_info(dev,
+				 "can't get syscon-pllreset, sata dpll won't idle\n");
+			phy->dpll_reset_syscon = NULL;
+		} else {
+			if (of_property_read_u32_index(node,
+						       "syscon-pllreset", 1,
+						       &phy->dpll_reset_reg)) {
+				dev_err(dev,
+					"couldn't get pllreset reg. offset\n");
+				return -EINVAL;
+			}
+		}
+	}
+
+	return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
 	struct ti_pipe3 *phy;
@@ -383,8 +425,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	struct phy_provider *phy_provider;
 	struct resource *res;
 	struct device_node *node = pdev->dev.of_node;
-	struct device_node *control_node;
-	struct platform_device *control_pdev;
 	const struct of_device_id *match;
 	struct device *dev = &pdev->dev;
 	int ret;
@@ -413,42 +453,14 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 			return PTR_ERR(phy->pll_ctrl_base);
 	}
 
-	if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
-		phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
-							"syscon-pllreset");
-		if (IS_ERR(phy->dpll_reset_syscon)) {
-			dev_info(dev,
-				 "can't get syscon-pllreset, sata dpll won't idle\n");
-			phy->dpll_reset_syscon = NULL;
-		} else {
-			if (of_property_read_u32_index(node,
-						       "syscon-pllreset", 1,
-						       &phy->dpll_reset_reg)) {
-				dev_err(dev,
-					"couldn't get pllreset reg. offset\n");
-				return -EINVAL;
-			}
-		}
-	}
+	ret = ti_pipe3_get_sysctrl(phy);
+	if (ret)
+		return ret;
 
 	ret = ti_pipe3_get_clk(phy);
 	if (ret)
 		return ret;
 
-	control_node = of_parse_phandle(node, "ctrl-module", 0);
-	if (!control_node) {
-		dev_err(dev, "Failed to get control device phandle\n");
-		return -EINVAL;
-	}
-
-	control_pdev = of_find_device_by_node(control_node);
-	if (!control_pdev) {
-		dev_err(dev, "Failed to get control device\n");
-		return -EINVAL;
-	}
-
-	phy->control_dev = &control_pdev->dev;
-
 	omap_control_phy_power(phy->control_dev, 0);
 
 	platform_set_drvdata(pdev, phy);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292041

On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
> This series is basically to deprecate using phy-omap-control and use
> syscon APIs to program the control module registers.
> 
> Changes from v2:
> No changes.
> 
> Changes from v1:
> *) cleanup ti_pipe3_probe in multiple steps
> *) other minor cleanups
> 
> Changes from [1] in PHY patches include
> *) cleanup ti_pipe3_probe
> *) have mask, power_on and power_off values in usb_phy_data for
>    omap-usb2 phy
> 
> The patches have been pushed to
>         git://git.ti.com/linux-phy/linux-phy.git syscon
> 
> [1] -> https://lkml.org/lkml/2015/6/23/189
> 
> All the testing was done both before applying the dt patches and after
> applying the dt patches (dt patches will be posted shortly).
> 

Can you explain here what the conversion is good for? Why do you
prefer the syscon mapping over a high-level driver in this case?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292051

Hi Arnd,

On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
>> This series is basically to deprecate using phy-omap-control and use
>> syscon APIs to program the control module registers.
>>
>> Changes from v2:
>> No changes.
>>
>> Changes from v1:
>> *) cleanup ti_pipe3_probe in multiple steps
>> *) other minor cleanups
>>
>> Changes from [1] in PHY patches include
>> *) cleanup ti_pipe3_probe
>> *) have mask, power_on and power_off values in usb_phy_data for
>>    omap-usb2 phy
>>
>> The patches have been pushed to
>>         git://git.ti.com/linux-phy/linux-phy.git syscon
>>
>> [1] -> https://lkml.org/lkml/2015/6/23/189
>>
>> All the testing was done both before applying the dt patches and after
>> applying the dt patches (dt patches will be posted shortly).
>>
> 
> Can you explain here what the conversion is good for? Why do you
> prefer the syscon mapping over a high-level driver in this case?

phy-omap-control driver was added when there was no proper
infrastructure for doing control module initializations. The
phy-omap-control driver is not an 'actual' PHY driver and it
was just a hack to do PHY related control module initializations.
phy-omap-control is also getting unmanageable with the number of
platforms each having number of modules (like USB, SATA, PCIe),
using the same driver for control module initializations.

Now with SYSCON framework being added to the kernel, phy-omap-control
shouldn't be needed and it also provides a uniform API across all the
modules to program the control module.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292080

On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote:
> Hi Arnd,
> 
> On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> > On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
> >> This series is basically to deprecate using phy-omap-control and use
> >> syscon APIs to program the control module registers.
> >>
> >> Changes from v2:
> >> No changes.
> >>
> >> Changes from v1:
> >> *) cleanup ti_pipe3_probe in multiple steps
> >> *) other minor cleanups
> >>
> >> Changes from [1] in PHY patches include
> >> *) cleanup ti_pipe3_probe
> >> *) have mask, power_on and power_off values in usb_phy_data for
> >>    omap-usb2 phy
> >>
> >> The patches have been pushed to
> >>         git://git.ti.com/linux-phy/linux-phy.git syscon
> >>
> >> [1] -> https://lkml.org/lkml/2015/6/23/189
> >>
> >> All the testing was done both before applying the dt patches and after
> >> applying the dt patches (dt patches will be posted shortly).
> >>
> > 
> > Can you explain here what the conversion is good for? Why do you
> > prefer the syscon mapping over a high-level driver in this case?
> 
> phy-omap-control driver was added when there was no proper
> infrastructure for doing control module initializations. The
> phy-omap-control driver is not an 'actual' PHY driver and it
> was just a hack to do PHY related control module initializations.
> phy-omap-control is also getting unmanageable with the number of
> platforms each having number of modules (like USB, SATA, PCIe),
> using the same driver for control module initializations.
> 
> Now with SYSCON framework being added to the kernel, phy-omap-control
> shouldn't be needed and it also provides a uniform API across all the
> modules to program the control module.

Ok, so the "phy-control" devices were really just a few registers of
a system controller device that does a lot of other things as well, right?

Can you put your description above into the cover-letter for the series,
and the merge commit?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292126

Hi,

On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote:
>> Hi Arnd,
>>
>> On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
>>> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
>>>> This series is basically to deprecate using phy-omap-control and use
>>>> syscon APIs to program the control module registers.
>>>>
>>>> Changes from v2:
>>>> No changes.
>>>>
>>>> Changes from v1:
>>>> *) cleanup ti_pipe3_probe in multiple steps
>>>> *) other minor cleanups
>>>>
>>>> Changes from [1] in PHY patches include
>>>> *) cleanup ti_pipe3_probe
>>>> *) have mask, power_on and power_off values in usb_phy_data for
>>>>    omap-usb2 phy
>>>>
>>>> The patches have been pushed to
>>>>         git://git.ti.com/linux-phy/linux-phy.git syscon
>>>>
>>>> [1] -> https://lkml.org/lkml/2015/6/23/189
>>>>
>>>> All the testing was done both before applying the dt patches and after
>>>> applying the dt patches (dt patches will be posted shortly).
>>>>
>>>
>>> Can you explain here what the conversion is good for? Why do you
>>> prefer the syscon mapping over a high-level driver in this case?
>>
>> phy-omap-control driver was added when there was no proper
>> infrastructure for doing control module initializations. The
>> phy-omap-control driver is not an 'actual' PHY driver and it
>> was just a hack to do PHY related control module initializations.
>> phy-omap-control is also getting unmanageable with the number of
>> platforms each having number of modules (like USB, SATA, PCIe),
>> using the same driver for control module initializations.
>>
>> Now with SYSCON framework being added to the kernel, phy-omap-control
>> shouldn't be needed and it also provides a uniform API across all the
>> modules to program the control module.
> 
> Ok, so the "phy-control" devices were really just a few registers of
> a system controller device that does a lot of other things as well, right?

right.
> 
> Can you put your description above into the cover-letter for the series,
> and the merge commit?

Sure.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292259

* Kishon Vijay Abraham I <kishon@ti.com> [151215 04:47]:
> On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
> >>>
> >>> Can you explain here what the conversion is good for? Why do you
> >>> prefer the syscon mapping over a high-level driver in this case?
> >>
> >> phy-omap-control driver was added when there was no proper
> >> infrastructure for doing control module initializations. The
> >> phy-omap-control driver is not an 'actual' PHY driver and it
> >> was just a hack to do PHY related control module initializations.
> >> phy-omap-control is also getting unmanageable with the number of
> >> platforms each having number of modules (like USB, SATA, PCIe),
> >> using the same driver for control module initializations.
> >>
> >> Now with SYSCON framework being added to the kernel, phy-omap-control
> >> shouldn't be needed and it also provides a uniform API across all the
> >> modules to program the control module.
> > 
> > Ok, so the "phy-control" devices were really just a few registers of
> > a system controller device that does a lot of other things as well, right?
> 
> right.
> > 
> > Can you put your description above into the cover-letter for the series,
> > and the merge commit?

Just to confirm.. Seems like this series keeps USB working and the dts
changes can be done later after the driver changes have been merged?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1294638

Hi,

On Tuesday 15 December 2015 08:56 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon@ti.com> [151215 04:47]:
>> On Tuesday 15 December 2015 05:25 PM, Arnd Bergmann wrote:
>>>>>
>>>>> Can you explain here what the conversion is good for? Why do you
>>>>> prefer the syscon mapping over a high-level driver in this case?
>>>>
>>>> phy-omap-control driver was added when there was no proper
>>>> infrastructure for doing control module initializations. The
>>>> phy-omap-control driver is not an 'actual' PHY driver and it
>>>> was just a hack to do PHY related control module initializations.
>>>> phy-omap-control is also getting unmanageable with the number of
>>>> platforms each having number of modules (like USB, SATA, PCIe),
>>>> using the same driver for control module initializations.
>>>>
>>>> Now with SYSCON framework being added to the kernel, phy-omap-control
>>>> shouldn't be needed and it also provides a uniform API across all the
>>>> modules to program the control module.
>>>
>>> Ok, so the "phy-control" devices were really just a few registers of
>>> a system controller device that does a lot of other things as well, right?
>>
>> right.
>>>
>>> Can you put your description above into the cover-letter for the series,
>>> and the merge commit?
> 
> Just to confirm.. Seems like this series keeps USB working and the dts
> changes can be done later after the driver changes have been merged?

that's right Tony. Will merge this series by tomorrow if I don't get any review
comments.

Thanks
Kishon
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web