Re: [PATCH 15/19] ARM: dts: omap: replace legacy *,wakeup property with wakeup-source

[Sudeep Holla]

On 21/10/15 11:10, Sudeep Holla wrote:

Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup
source, "wakeup-source" is the new standard binding.

This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Cc: "Benoît Cousson" 
Cc: Tony Lindgren 


Ping, do you prefer taking via your tree or should I send to armsoc
directly ?

--
Regards,
Sudeep
--
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/19] ARM: dts: am335x: replace gpio-key,wakeup with wakeup-source property

[Sudeep Holla]

On 21/10/15 11:10, Sudeep Holla wrote:

Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Cc: "Benoît Cousson" 
Cc: Tony Lindgren 


Ping, do you prefer taking via your tree or should I send to armsoc
directly ?

--
Regards,
Sudeep
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Nicolas Pitre]

On Tue, 15 Dec 2015, Russell King - ARM Linux wrote:

> On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote:
> > So am I understand correctly that solution would be to hack
> > arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?
> 
> That's completely unnecessary: there are enough platform hooks to cope
> with whatever the platform requires.

Indeed.  I didn't notice that mdesc->reserve() exists these days and is 
perfect for this purpose as you say.


Nicolas

[PATCH v3 5/9] phy: ti-pipe3: use ti_pipe3_power_off to power off the PHY during probe

[Kishon Vijay Abraham I]

No functional change. Previously omap_control_phy_power() was used to power
off the PHY during probe. But once PIPE3 driver is adapted to use syscon,
omap_control_phy_power() cannot be used. Hence used ti_pipe3_power_off
to power off the PHY.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Roger Quadros 
---
 drivers/phy/phy-ti-pipe3.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 1991efd..0ce4194 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -475,8 +475,6 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   omap_control_phy_power(phy->control_dev, 0);
-
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
 
@@ -495,6 +493,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
return PTR_ERR(generic_phy);
 
phy_set_drvdata(generic_phy, phy);
+
+   ti_pipe3_power_off(generic_phy);
+
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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/9] phy: ti-pipe3: move clk initialization to a separate function

[Kishon Vijay Abraham I]

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

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |  127 +---
 1 file changed, 72 insertions(+), 55 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index c511105..3379a4d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -308,48 +308,11 @@ static const struct phy_ops ops = {
 
 static const struct of_device_id ti_pipe3_id_table[];
 
-static int ti_pipe3_probe(struct platform_device *pdev)
+static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
 {
-   struct ti_pipe3 *phy;
-   struct phy *generic_phy;
-   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 clk *clk;
-   struct device *dev = >dev;
-
-   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
-   if (!phy)
-   return -ENOMEM;
-
-   phy->dev= dev;
-
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   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(dev, "no DPLL data\n");
-   return -EINVAL;
-   }
-
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "pll_ctrl");
-   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(dev, "sysclk");
-   if (IS_ERR(phy->sys_clk)) {
-   dev_err(dev, "unable to get sysclk\n");
-   return -EINVAL;
-   }
-   }
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
 
phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
@@ -369,25 +332,17 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
} else {
phy->wkupclk = ERR_PTR(-ENODEV);
-   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,
-  >dpll_reset_reg)) {
-   dev_err(dev,
-   "couldn't get pllreset reg. offset\n");
-   return -EINVAL;
-   }
+   }
+
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   phy->sys_clk = devm_clk_get(dev, "sysclk");
+   if (IS_ERR(phy->sys_clk)) {
+   dev_err(dev, "unable to get sysclk\n");
+   return -EINVAL;
}
}
 
if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-
clk = devm_clk_get(dev, "dpll_ref");
if (IS_ERR(clk)) {
dev_err(dev, "unable to get dpll ref clk\n");
@@ -418,6 +373,68 @@ static int ti_pipe3_probe(struct platform_device *pdev)
phy->div_clk = ERR_PTR(-ENODEV);
}
 
+   return 0;
+}
+
+static int ti_pipe3_probe(struct platform_device *pdev)
+{
+   struct ti_pipe3 *phy;
+   struct phy *generic_phy;
+   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 = >dev;
+   int ret;
+
+   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+   if (!phy)
+   return -ENOMEM;
+
+   phy->dev= dev;
+
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   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) {
+   

[PATCH v3 4/9] phy: ti-pipe3: move mem resource initialization to a separate function

[Kishon Vijay Abraham I]

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

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/phy/phy-ti-pipe3.c |   52 
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 3154da0..1991efd 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -418,14 +418,42 @@ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
+{
+   struct resource *res;
+   const struct of_device_id *match;
+   struct device *dev = phy->dev;
+   struct device_node *node = dev->of_node;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   if (of_device_is_compatible(node, "ti,phy-pipe3-pcie"))
+   return 0;
+
+   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(dev, "no DPLL data\n");
+   return -EINVAL;
+   }
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "pll_ctrl");
+   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(phy->pll_ctrl_base))
+   return PTR_ERR(phy->pll_ctrl_base);
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
struct phy *generic_phy;
struct phy_provider *phy_provider;
-   struct resource *res;
struct device_node *node = pdev->dev.of_node;
-   const struct of_device_id *match;
struct device *dev = >dev;
int ret;
 
@@ -435,23 +463,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 
phy->dev= dev;
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   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(dev, "no DPLL data\n");
-   return -EINVAL;
-   }
-
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(phy->pll_ctrl_base))
-   return PTR_ERR(phy->pll_ctrl_base);
-   }
+   ret = ti_pipe3_get_pll_base(phy);
+   if (ret)
+   return ret;
 
ret = ti_pipe3_get_sysctrl(phy);
if (ret)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node

[Kishon Vijay Abraham I]

Add "syscon-phy-power" property and "syscon-pcs" property which can
be used to perform the control module initializations and remove
the deprecated "ctrl-module" property from PCIe PHY dt nodes.

Phandle to "sysclk" clock node is also added to the PCIe PHY node
since some of the syscon initializations is based on system clock
frequency.

Since "omap_control_pcie1phy" and "omap_control_pcie2phy" devicetree
nodes are no longer used, remove it.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |   33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e38f63f..156d735 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1204,16 +1204,18 @@
reg = <0x4a094000 0x80>, /* phy_rx */
  <0x4a094400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie1phy>;
+   syscon-phy-power = <_conf_pcie 0x1c>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy1_32khz>,
 <_pciephy1_clk>,
 <_pciephy1_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
};
 
@@ -1222,16 +1224,18 @@
reg = <0x4a095000 0x80>, /* phy_rx */
  <0x4a095400 0x64>; /* phy_tx */
reg-names = "phy_rx", "phy_tx";
-   ctrl-module = <_control_pcie2phy>;
+   syscon-phy-power = <_conf_pcie 0x20>;
+   syscon-pcs = <_conf_pcie 0x10>;
clocks = <_pcie_ref_ck>,
 <_pcie_ref_m2ldo_ck>,
 <_pciephy2_32khz>,
 <_pciephy2_clk>,
 <_pciephy2_div_clk>,
-<_pciephy_div>;
+<_pciephy_div>,
+<_clkin1>;
clock-names = "dpll_ref", "dpll_ref_m2",
  "wkupclk", "refclk",
- "div-clk", "phy-div";
+ "div-clk", "phy-div", "sysclk";
#phy-cells = <0>;
status = "disabled";
};
@@ -1247,23 +1251,6 @@
ti,hwmods = "sata";
};
 
-   omap_control_pcie1phy: control-phy@0x4a003c40 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
-   omap_control_pcie2phy: control-pcie@0x4a003c44 {
-   compatible = "ti,control-phy-pcie";
-   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
-   reg-names = "power", "control_sma", "pcie_pcs";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   status = "disabled";
-   };
-
rtc: rtc@48838000 {
compatible = "ti,am3352-rtc";
reg = <0x48838000 0x100>;
-- 
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Pali Rohár]

On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote:
> On Mon, 30 Nov 2015, Pali Rohár wrote:
> 
> > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > > * Pali Rohár  [151129 16:16]:
> > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > > > > > Good. And Arnd likes the idea too. So we might be converging at
> > > > > > > last which is a good thing.
> > > > > > 
> > > > > > I disagree with the idea that there is convergence.  There might be
> > > > > > convergence towards an idea, but... Here's a mail extract, from
> > > > > > July 7th, from earlier in this very thread:
> > > > > > 
> > > > > > Pali:
> > > > > > > Me:
> > > > > > > > Are the ATAGs at a fixed address on the N900?
> > > > > > > 
> > > > > > > Yes, in board-rx51.c is:
> > > > > > > 
> > > > > > > .atag_offset= 0x100
> > > > > > > 
> > > > > > > and Nokia Bootloader (proprietary) store them to that address.
> > > > > > > 
> > > > > > > > Can that be handled in
> > > > > > > > some kind of legacy file for the N900 which calls save_atags()
> > > > > > > > on it, so we don't end up introducing yet more stuff that we
> > > > > > > > have to maintain into the distant future?  If not, what about
> > > > > > > > copying a known working atag structure into a legacy file for
> > > > > > > > the N900?
> > > > > > > 
> > > > > > > I already asked question if it is possible to read ATAGs from DT
> > > > > > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > > > > > that it is not possible and it can be done in that uncompress
> > > > > > > code.
> > > > > 
> > > > > Who is that somebody? If ever it happened to be me then objection is
> > > > > withdrawn. Otherwise that somebody should come forth and speak up
> > > > > again.
> > > > > 
> > > > 
> > > > ... do not remember ... this discussion were in more email threads and 
> > > > takes more then one year... sorry but my memory is not excellent
> > > 
> > > Yes this certainly seems like the best solution. I think we got into
> > > the atags-to-dt track as some of the atags are already being translated.
> > > 
> > > In this case there's no need to translate them AFAIK. You can just
> > > parse them and have them available for the user space. So as long as
> > > nothing trashes the atags at the atag_offset, you should be able to
> > > call a function to parse them in the n900 specific init_machine.
> > > 
> > > Regards,
> > > 
> > > Tony
> > 
> > In arch/arm/kernel/setup.c is function setup_arch() and it calls:
> > 
> >   mdesc = setup_machine_fdt(__atags_pointer);
> >   if (!mdesc)
> >   mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> > 
> > So it looks like that on atags address is stored either atags structure
> > or DT structure... so it is truth kernel uncompress code put DT blob to
> > same offset where is expected atags structure?
> 
> No.  It doesn't put it anywhere. Those functions read DT/ATAGs from the 
> passed address.  But you know this address won't be the one you want for 
> the legacy ATAGs.
> 
> What you should do is to add a init_early hook to your mdesc structure 
> and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100.
> 
> Now I suspect paging_init() marks the point where the ATAGs will be 
> overwritten.  To prevent this, you might have to add an additional tweak 
> in arm_mm_memblock_reserve() similar to the one already present for 
> CONFIG_SA. Something like:
> 
>   memblock_reserve(PHYS_OFFSET, PAGE_SIZE);
> 
> And later on you can return that page back to the system.
> 
> 
> Nicolas

So am I understand correctly that solution would be to hack
arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?

And should be this just when when we detect Nokia N900 in DT? Or for all
OMAP2 boards? Or all ARM boards?

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/4] ARM: dts: use syscon property instead of ctrl-module

[Kishon Vijay Abraham I]

This series is basically to deprecate using ctrl-module property and use
corresponding syscon properties to program the control module registers.

Changes from v2:
No changes.

Changes from v1:
*) Squashed the patches that replaces "ctrl-module" with
   "syscon-phy-power"
*) Added "syscon-phy-power" for SATA dt node in OMAP5 which was missed
   earlier
*) removed _ARM: dts: omap4: Use "syscon-otghs" instead of "ctrl-module"
   in USB node_. It will be done later.

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

This series should be merged only after [2]

[2] -> http://www.spinics.net/lists/kernel/msg2144510.html

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 (4):
  ARM: dts: dra7: Add dt node for the sycon pcie
  ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY
node
  ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2
PHY2
  ARM: dts: : Use "syscon-phy-power" instead of
"ctrl-module"

 arch/arm/boot/dts/am4372.dtsi |   16 ++---
 arch/arm/boot/dts/dra7.dtsi   |   75 -
 arch/arm/boot/dts/omap5.dtsi  |   26 ++
 3 files changed, 26 insertions(+), 91 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Kishon Vijay Abraham I]

Deprecate using phy-omap-control driver to power on/off the PHY,
and use *syscon* framework to do the same. This handles
powering on/off the PHY for the USB2 PHYs used in various TI SoCs.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
 drivers/phy/phy-omap-usb2.c  |   94 ++
 include/linux/phy/omap_usb.h |   23 ++
 3 files changed, 107 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 49e5b0c..a3b3945 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -31,6 +31,8 @@ OMAP USB2 PHY
 
 Required properties:
  - compatible: Should be "ti,omap-usb2"
+  Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
+  in DRA7x
  - reg : Address and length of the register set for the device.
  - #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
@@ -40,10 +42,14 @@ Required properties:
* "wkupclk" - wakeup clock.
* "refclk" - reference clock (optional).
 
-Optional properties:
+Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
the PHY.
 
+Recommended properies:
+- syscon-phy-power : phandle/offset pair. Phandle to the system control
+  module and the register offset to power on/off the PHY.
+
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb2phy@4a0ad080 {
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index c79633e..c9c04ff 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define USB2PHY_DISCON_BYP_LATCH (1 << 31)
@@ -97,22 +99,40 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
 }
 
-static int omap_usb_power_off(struct phy *x)
+static int omap_usb_phy_power(struct omap_usb *phy, int on)
 {
-   struct omap_usb *phy = phy_get_drvdata(x);
+   u32 val;
+   int ret;
 
-   omap_control_phy_power(phy->control_dev, 0);
+   if (phy->syscon_phy_power) {
+   if (on)
+   val = phy->power_on;
+   else
+   val = phy->power_off;
+
+   ret = regmap_update_bits(phy->syscon_phy_power, phy->power_reg,
+phy->mask, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, on);
+   }
 
return 0;
 }
 
-static int omap_usb_power_on(struct phy *x)
+static int omap_usb_power_off(struct phy *x)
 {
struct omap_usb *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 1);
+   return omap_usb_phy_power(phy, false);
+}
 
-   return 0;
+static int omap_usb_power_on(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+
+   return omap_usb_phy_power(phy, true);
 }
 
 static int omap_usb_init(struct phy *x)
@@ -147,21 +167,38 @@ static const struct phy_ops ops = {
 static const struct usb_phy_data omap_usb2_data = {
.label = "omap_usb2",
.flags = OMAP_USB2_HAS_START_SRP | OMAP_USB2_HAS_SET_VBUS,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
 };
 
 static const struct usb_phy_data omap5_usb2_data = {
.label = "omap5_usb2",
.flags = 0,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
 };
 
 static const struct usb_phy_data dra7x_usb2_data = {
.label = "dra7x_usb2",
.flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+   .mask = OMAP_DEV_PHY_PD,
+   .power_off = OMAP_DEV_PHY_PD,
+};
+
+static const struct usb_phy_data dra7x_usb2_phy2_data = {
+   .label = "dra7x_usb2_phy2",
+   .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+   .mask = OMAP_USB2_PHY_PD,
+   .power_off = OMAP_USB2_PHY_PD,
 };
 
 static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags =  0,
+   .mask = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD |
+   AM437X_USB2_OTGVDET_EN | AM437X_USB2_OTGSESSEND_EN,
+   .power_on = AM437X_USB2_OTGVDET_EN | AM437X_USB2_OTGSESSEND_EN,
+   .power_off = AM437X_USB2_PHY_PD | AM437X_USB2_OTG_PD,
 };
 
 static const struct of_device_id omap_usb2_id_table[] = {
@@ -178,6 +215,10 @@ static const struct of_device_id omap_usb2_id_table[] = {
.data = _usb2_data,
},
{
+   .compatible = "ti,dra7x-usb2-phy2",
+   .data = _usb2_phy2_data,
+   },
+   {
.compatible = "ti,am437x-usb2",
.data = _usb2_data,
},
@@ -219,6 +260,9 @@ static int omap_usb2_probe(struct 

[PATCH v3 8/9] phy: omap-usb2: use omap_usb_power_off to power off the PHY during probe

[Kishon Vijay Abraham I]

No functional change. Previously omap_control_phy_power() was used to power
off the PHY during probe. But once phy-omap-usb2 driver is adapted to
use syscon, omap_control_phy_power() cannot be used. Hence used
omap_usb_power_off to power off the PHY.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Roger Quadros 
---
 drivers/phy/phy-omap-usb2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 0fe8058..c79633e 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -241,7 +241,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy->control_dev = _pdev->dev;
-   omap_control_phy_power(phy->control_dev, 0);
 
otg->set_host   = omap_usb_set_host;
otg->set_peripheral = omap_usb_set_peripheral;
@@ -261,6 +260,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
 
phy_set_drvdata(generic_phy, phy);
+   omap_usb_power_off(generic_phy);
 
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
-- 
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 v3 1/9] phy: ti-pipe3: introduce local struct device* in probe

[Kishon Vijay Abraham I]

No functional change. Introduce local struct device pointer in
probe and replace using >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 
---
 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 = >dev;
 
-   phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   phy->dev= >dev;
+   phy->dev= dev;
 
if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
-   match = of_match_device(ti_pipe3_id_table, >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(>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(>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(>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(>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(>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(>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,
   >dpll_reset_reg)) {
-   dev_err(>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(>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, 15);
 
-   clk = devm_clk_get(phy->dev, "dpll_ref_m2");
+   clk = devm_clk_get(dev, 

[PATCH v3 3/4] ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2

[Kishon Vijay Abraham I]

The USB2 PHY2 has a different register map compared to USB2 PHY1
to power on/off the PHY. In order to handle it, use the new compatible
string "ti,dra7x-usb2-phy2" for the second instance of USB2 PHY.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 156d735..41545f9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1299,7 +1299,8 @@
};
 
usb2_phy2: phy@4a085000 {
-   compatible = "ti,omap-usb2";
+   compatible = "ti,dra7x-usb2-phy2",
+"ti,omap-usb2";
reg = <0x4a085000 0x400>;
ctrl-module = <_control_usb2phy2>;
clocks = <_phy2_always_on_clk32k>,
-- 
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 v3 4/4] ARM: dts: : Use "syscon-phy-power" instead of "ctrl-module"

[Kishon Vijay Abraham I]

Add "syscon-phy-power" property and remove the deprecated "ctrl-module"
property from SATA and USB PHY node. Also remove the unused control
module dt nodes.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am4372.dtsi |   16 ++--
 arch/arm/boot/dts/dra7.dtsi   |   34 --
 arch/arm/boot/dts/omap5.dtsi  |   26 +++---
 3 files changed, 9 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..f42d4a4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -853,18 +853,6 @@
status = "disabled";
};
 
-   am43xx_control_usb2phy1: control-phy@44e10620 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10620 0x4>;
-   reg-names = "power";
-   };
-
-   am43xx_control_usb2phy2: control-phy@0x44e10628 {
-   compatible = "ti,control-phy-usb2-am437";
-   reg = <0x44e10628 0x4>;
-   reg-names = "power";
-   };
-
ocp2scp0: ocp2scp@483a8000 {
compatible = "ti,am437x-ocp2scp", "ti,omap-ocp2scp";
#address-cells = <1>;
@@ -875,7 +863,7 @@
usb2_phy1: phy@483a8000 {
compatible = "ti,am437x-usb2";
reg = <0x483a8000 0x8000>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x620>;
clocks = <_phy0_always_on_clk32k>,
 <_otg_ss0_refclk960m>;
clock-names = "wkupclk", "refclk";
@@ -894,7 +882,7 @@
usb2_phy2: phy@483e8000 {
compatible = "ti,am437x-usb2";
reg = <0x483e8000 0x8000>;
-   ctrl-module = <_control_usb2phy2>;
+   syscon-phy-power = <_conf 0x628>;
clocks = <_phy1_always_on_clk32k>,
 <_otg_ss1_refclk960m>;
clock-names = "wkupclk", "refclk";
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 41545f9..8ce37e4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1170,14 +1170,6 @@
status = "disabled";
};
 
-   omap_control_sata: control-phy@4a002374 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002374 0x4>;
-   reg-names = "power";
-   clocks = <_clkin1>;
-   clock-names = "sysclk";
-   };
-
/* OCP2SCP3 */
ocp2scp@4a09 {
compatible = "ti,omap-ocp2scp";
@@ -1192,7 +1184,7 @@
  <0x4A096400 0x64>, /* phy_tx */
  <0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-   ctrl-module = <_control_sata>;
+   syscon-phy-power = <_conf 0x374>;
clocks = <_clkin1>, <_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <_conf 0x3fc>;
@@ -1260,24 +1252,6 @@
clocks = <_32k_ck>;
};
 
-   omap_control_usb2phy1: control-phy@4a002300 {
-   compatible = "ti,control-phy-usb2";
-   reg = <0x4a002300 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb3phy1: control-phy@4a002370 {
-   compatible = "ti,control-phy-pipe3";
-   reg = <0x4a002370 0x4>;
-   reg-names = "power";
-   };
-
-   omap_control_usb2phy2: control-phy@0x4a002e74 {
-   compatible = "ti,control-phy-usb2-dra7";
-   reg = <0x4a002e74 0x4>;
-   reg-names = "power";
-   };
-
/* OCP2SCP1 */
ocp2scp@4a08 {
compatible = "ti,omap-ocp2scp";
@@ -1290,7 +1264,7 @@
usb2_phy1: phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x400>;
-   ctrl-module = <_control_usb2phy1>;
+   syscon-phy-power = <_conf 0x300>;
clocks = 

[PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Kishon Vijay Abraham I]

Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {
+   compatible = "syscon";
+   reg = <0x1c24 0x0024>;
+   };
};
 
cm_core_aon: cm_core_aon@5000 {
-- 
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 v3 6/9] phy: ti-pipe3: use *syscon* framework API to power on/off the PHY

[Kishon Vijay Abraham I]

Deprecate using phy-omap-control driver to power on/off the PHY and
use *syscon* framework to do the same.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |   10 ++-
 drivers/phy/phy-ti-pipe3.c   |   90 ++
 2 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 9cf9446..e06f980 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -77,8 +77,6 @@ Required properties:
* "div-clk" - apll clock
 
 Optional properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
-   the PHY.
  - id: If there are multiple instance of the same type, in order to
differentiate between each instance "id" can be used (e.g., multi-lane PCIe
PHY). If "id" is not provided, it is set to default value of '1'.
@@ -86,6 +84,14 @@ Optional properties:
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
 
+Deprecated properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
+
+Recommended properies:
+ - syscon-phy-power : phandle/offset pair. Phandle to the system control
+   module and the register offset to power on/off the PHY.
+
 This is usually a subnode of ocp2scp to which it is connected.
 
 usb3phy@4a084400 {
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0ce4194..bc03625 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,15 @@
 
 #define SATA_PLL_SOFT_RESETBIT(18)
 
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK  0x003FC000
+#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
+
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK 0xFFC0
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
+
+#define PIPE3_PHY_TX_RX_POWERON0x3
+#define PIPE3_PHY_TX_RX_POWEROFF   0x0
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -86,8 +95,10 @@ struct ti_pipe3 {
struct clk  *refclk;
struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
+   struct regmap   *phy_power_syscon; /* ctrl. reg. acces */
struct regmap   *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
+   unsigned intpower_reg; /* power reg. index within syscon */
boolsata_refclk_enabled;
 };
 
@@ -144,18 +155,53 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy);
 
 static int ti_pipe3_power_off(struct phy *x)
 {
+   u32 val;
+   int ret;
struct ti_pipe3 *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 0);
+   if (phy->phy_power_syscon) {
+   val = PIPE3_PHY_TX_RX_POWEROFF <<
+   PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+
+   ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, 0);
+   }
 
return 0;
 }
 
 static int ti_pipe3_power_on(struct phy *x)
 {
+   u32 val;
+   u32 mask;
+   int ret;
+   unsigned long rate;
struct ti_pipe3 *phy = phy_get_drvdata(x);
 
-   omap_control_phy_power(phy->control_dev, 1);
+   if (phy->phy_power_syscon) {
+   rate = clk_get_rate(phy->sys_clk);
+   if (!rate) {
+   dev_err(phy->dev, "Invalid clock rate\n");
+   return -EINVAL;
+   }
+   rate = rate / 100;
+   mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
+ OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
+   val = PIPE3_PHY_TX_RX_POWERON <<
+   PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
+   val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
+
+   ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+mask, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_phy_power(phy->control_dev, 1);
+   }
 
return 0;
 }
@@ -334,7 +380,8 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
phy->wkupclk = ERR_PTR(-ENODEV);
}
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie") ||
+   phy->phy_power_syscon) {

[PATCH v3 7/9] phy: ti-pipe3: use *syscon* framework API to set PCS value of the PHY

[Kishon Vijay Abraham I]

Deprecate using phy-omap-control driver to set PCS value of the PHY
and start using *syscon* API to do the same.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
 drivers/phy/phy-ti-pipe3.c   |   34 +-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index e06f980..49e5b0c 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -83,6 +83,8 @@ Optional properties:
  - syscon-pllreset: Handle to system control region that contains the
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
+ - syscon-pcs : phandle/offset pair. Phandle to the system control module and 
the
+   register offset to write the PCS delay value.
 
 Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index bc03625..684d467 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -65,6 +65,9 @@
 #define PIPE3_PHY_TX_RX_POWERON0x3
 #define PIPE3_PHY_TX_RX_POWEROFF   0x0
 
+#define PCIE_PCS_MASK  0xFF
+#define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -96,9 +99,11 @@ struct ti_pipe3 {
struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
struct regmap   *phy_power_syscon; /* ctrl. reg. acces */
+   struct regmap   *pcs_syscon; /* ctrl. reg. acces */
struct regmap   *dpll_reset_syscon; /* ctrl. reg. acces */
unsigned intdpll_reset_reg; /* reg. index within syscon */
unsigned intpower_reg; /* power reg. index within syscon */
+   unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
boolsata_refclk_enabled;
 };
 
@@ -275,7 +280,16 @@ static int ti_pipe3_init(struct phy *x)
 * 18-1804.
 */
if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
-   omap_control_pcie_pcs(phy->control_dev, 0x96);
+   if (phy->pcs_syscon) {
+   val = 0x96 << OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT;
+   ret = regmap_update_bits(phy->pcs_syscon,
+phy->pcie_pcs_reg,
+PCIE_PCS_MASK, val);
+   if (ret < 0)
+   return ret;
+   } else {
+   omap_control_pcie_pcs(phy->control_dev, 0x96);
+   }
return 0;
}
 
@@ -461,6 +475,24 @@ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
phy->control_dev = _pdev->dev;
}
 
+   if (of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   phy->pcs_syscon = syscon_regmap_lookup_by_phandle(node,
+ "syscon-pcs");
+   if (IS_ERR(phy->pcs_syscon)) {
+   dev_dbg(dev,
+   "can't get syscon-pcs, using omap control\n");
+   phy->pcs_syscon = NULL;
+   } else {
+   if (of_property_read_u32_index(node,
+  "syscon-pcs", 1,
+  >pcie_pcs_reg)) {
+   dev_err(dev,
+   "couldn't get pcie pcs reg. offset\n");
+   return -EINVAL;
+   }
+   }
+   }
+
if (of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
phy->dpll_reset_syscon = syscon_regmap_lookup_by_phandle(node,
"syscon-pllreset");
-- 
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 v3 3/9] phy: ti-pipe3: move sysctrl initialization to a separate function

[Kishon Vijay Abraham I]

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 
---
 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 = _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,
+  >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 = >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,
-  >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 = _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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kishon Vijay Abraham I]

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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kishon Vijay Abraham I]

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-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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Russell King - ARM Linux]

On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote:
> So am I understand correctly that solution would be to hack
> arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?

That's completely unnecessary: there are enough platform hooks to cope
with whatever the platform requires.

If you want to reserve the memory, then you have the ->reserve callback,
where you can call:

memblock_reserve(PHYS_OFFSET, PAGE_SIZE);

if you wish to prevent the first page being overwritten.  You're then
responsible for freeing this page later in the boot sequence, or you
could just keep it around and refer to the atags in that page directly.

You could also just save_atags() in there, with a comment saying that
this is a work-around for N900 which needs the ATAGs saved, and this
is allowed in ->reserve as a special exception.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Arnd Bergmann]

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-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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Tuesday 15 December 2015 10:33:25 Pali Rohár wrote:
> On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote:
> > On Mon, 30 Nov 2015, Pali Rohár wrote:
> > > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > > > * Pali Rohár  [151129 16:16]:
> > > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > In arch/arm/kernel/setup.c is function setup_arch() and it calls:
> > > 
> > >   mdesc = setup_machine_fdt(__atags_pointer);
> > >   if (!mdesc)
> > >   mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> > > 
> > > So it looks like that on atags address is stored either atags structure
> > > or DT structure... so it is truth kernel uncompress code put DT blob to
> > > same offset where is expected atags structure?
> > 
> > No.  It doesn't put it anywhere. Those functions read DT/ATAGs from the 
> > passed address.  But you know this address won't be the one you want for 
> > the legacy ATAGs.
> > 
> > What you should do is to add a init_early hook to your mdesc structure 
> > and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100.
> > 
> > Now I suspect paging_init() marks the point where the ATAGs will be 
> > overwritten.  To prevent this, you might have to add an additional tweak 
> > in arm_mm_memblock_reserve() similar to the one already present for 
> > CONFIG_SA. Something like:
> > 
> >   memblock_reserve(PHYS_OFFSET, PAGE_SIZE);
> > 
> > And later on you can return that page back to the system.
> > 
> 
> So am I understand correctly that solution would be to hack
> arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?

I would think we can just copy the data from PAGE_OFFSET + 0x100
to a some other page from your init_early hook. IIRC you can't use
kmalloc there, but memblock_alloc() should work.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Arnd Bergmann]

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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.

Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to postcore_initcall".

Also note that this patch does not implement clk_set_rate for the
PLL, that will be posted later on when available.

Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
Changes from v2 to v3 are listed below, hopefully I addressed everybody's
comments,please check and let me know if I missed something.

After review, it is suggested that Tero applies this patch into an
immutable branch against v4.4-rc1 that then gets submitted as a pull
request along with other omap clock patches to Mike and Stephen. That
way I can merge the clock driver too into my omap-for-v4.5/soc branch.

Changes since v2:

Addressed comments from RMK:

- Use clkdev_create() and set up separate con id from name in format
  "pll260dcoclkldo" to avoid the MAX_CON_ID limitations

Addressed comments from Tero:

- Change register access to use offsets from d->regs instead of setting
  up separate void __iomem * registers

- Change ti_adpll_clkout_set_parent() to return -EAGAIN if unavailable
  parent is selected

Addressed comments from Matthijs:

- Standardize on "dcoclkldo" output name and use that name also for TRM
  "clkdcoldo"

- Use "bypass" name instead of "ulow" used in TRM 

- Use 16-bit register access in ti_adpll_recalc_rate() to simplify
  the code

- Use ti_adpll_set_idle_bypass() naming to make it clear it's the idle
  mode

- Check PLL lock for both ti_adpll_is_prepared() and ti_adpll_wait_lock()

---
 .../devicetree/bindings/clock/ti/adpll.txt |   43 +
 drivers/clk/Kconfig|1 +
 drivers/clk/ti/Kconfig |6 +
 drivers/clk/ti/Makefile|2 +
 drivers/clk/ti/adpll.c | 1003 
 drivers/clk/ti/clk-814x.c  |   53 ++
 6 files changed, 1108 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt 
b/Documentation/devicetree/bindings/clock/ti/adpll.txt
new file mode 100644
index 000..3c41aea
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -0,0 +1,43 @@
+Binding for Texas Instruments ADPLL clock.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped ADPLL with two to three selectable input clocks
+and three to four children..
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of "ti,dm814-adpll-s-clock" or
+  "ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks clkinp and clkinpulow, note
+  that the adpll-s-clock also has an optional clkinphif
+- reg : address and length of the register set for controlling the ADPLL.
+
+Examples:
+   adpll_mpu_ck: adpll@40 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-s-clock";
+   reg = <0x40 0x40>;
+   clocks = <_ck _ck _ck>;
+   clock-names = "clkinp", "clkinpulow", "clkinphif";
+   clock-indices = <0>, <1>, <2>, <3>;
+   clock-output-names = "481c5040.adpll.dcoclkldo",
+"481c5040.adpll.clkout",
+"481c5040.adpll.clkoutx2",
+"481c5040.adpll.clkouthif";
+   };
+
+   adpll_dsp_ck: adpll@80 {
+   #clock-cells = <1>;
+   compatible = "ti,dm814-adpll-lj-clock";
+   reg = <0x80 0x30>;
+   clocks = <_ck _ck>;
+   clock-names = "clkinp", "clkinpulow";
+   clock-indices = <0>, <1>, <2>;
+   clock-output-names = "481c5080.adpll.dcoclkldo",
+"481c5080.adpll.clkout",
+"481c5080.adpll.clkoutldo";
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c3e3a02f..c0c9868 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -190,6 +190,7 @@ config COMMON_CLK_CDCE706
 
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
+source "drivers/clk/ti/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 
 endmenu
diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
new file mode 100644
index 000..a9d5474
--- 

Re: [GIT PULL 1/2] omap fixes for 81xx for v4.5 merge window

[Arnd Bergmann]

On Thursday 10 December 2015 16:03:08 Tony Lindgren wrote:
> Fixes for ti81xx for v4.5 merge window. We have hp t410 already booting
> in mainline kernel with it's bootloader configured clocks.  However,
> trying to boot dm814x-evm uncovered all kind of issues with the timer
> clock. To keep t410 booting, these issues need to be fixed in a specific
> order and this branch contains both device tree and code changes.
> 
> To summarize the changes, we had missing ranges for clocks to probe,
> missing aliase for clocks, wrong registers for divder clocks, and bad
> address for the control module. All these went unnoticed earlier as
> things worked without errors by luck and I did not pay much attention
> to them until I got hold of a dm814x-evm and I noticed it did not boot.
> 
> As these are fixes for features that never worked, these can wait for
> v4.5 merge window no problem.
> 

Pulled into next/fixes-non-critical, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kishon Vijay Abraham I]

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-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] video:omap2:dss: fix timings for VENC to match what omapdrm expects

[Tomi Valkeinen]

On 13/12/15 20:41, H. Nikolaus Schaller wrote:

> Great that you did find the real reason of the problem.
> 
> I have tested it on the GTA04 and it also works.
> 
> Will the patches arrive in 4.5?

4.4, I hope.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: debugging

[Ryan]

Hi Felipe,

On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi  wrote:
>
> Hi,
>
> (please avoid top-posting)
>
> Ryan  writes:
>> Hi Tony,
>>
>> Thanks for your response. I dont see any prints. I suspect that it
>> might be hanging before the serial port is initialized
>>
>> All i see is after arch_reset is called. I can see that is mmc clk and
>> data signals toggling. This makes me think that boot rom has loaded
>> the xloader into sram.
>
> you might wanna consider openocd if your jtag interface is available
> somewhere on your pcb. Just keep in mind that you might have to fiddle a
> bit with some TCL config files to get openocd to behave correctly with
> your board.
>

I managed to connect a lauterbach debugger. to my target. This is what
i did to test

1. reset the board.  & stop at u-boot prompt
2. Do a system.attach on the T32 (Lauterbach says that system is ready)
3. I do a run on the T32. I see that the status changes on T32 to run.
4. Now, i try to play with the u-boot prompt and board does not respond.

Any idea what i am doing wrong? The PC is pointing to some address
0x28000 and does not change.
I expect the PC to be some address in the RAM since mmu is off.

Also, do i need to compile the x-loader and u-boot with some special
options & how do i tell the T32 to
pick the map file for x-loader and u-boot?

Thanks you,
ryan





> cheers
>
>> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>>> * Ryan  [151209 09:03]:
 Hello,

 On a custom 4460 board. The x-loader hangs at some place when we
 reboot. This happens occasionally on an android port by linaro.

 I just want to find out how to debug in this case. How can i get to
 know where the hang takes place. After boot rom, i can see the mmc clk
 toggling
 indicating that xloader is in sram when the hang takes place and not
 sure where the hang is.

 Do i need Lauterbach to debug - Is it possible to connect the emulator
 across reboot. If so, how? or is there any other way i can debug this

 Also, i want to check - If i can turn off the dplls? If so, how?

 I tried to do a disable on all the clocks in the clock list using
 clk_disable call just before reboot and that does not seem to help.
>>>
>>> You can add selected serial print statements very early into u-boot
>>> MLO (and probably x-loader). You need to keep them down to minimum
>>> so the image still fits into SRAM. If you enable debug, then that also
>>> needs to be limited to selected files only as enabling debug for the
>>> whole MLO/x-loader in the Makefile will make it too big.
>>>
>>> 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
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] ARM: dts: dra7: Add dt node for the sycon pcie

[Sergei Shtylyov]

Hello.

On 12/15/2015 12:39 PM, Kishon Vijay Abraham I wrote:


Add new device tree node for the control module register space where
PCIe registers are present.

Signed-off-by: Kishon Vijay Abraham I 
---
  arch/arm/boot/dts/dra7.dtsi |5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231..e38f63f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -155,6 +155,11 @@
compatible = "syscon";
reg = <0x1c04 0x0020>;
};
+
+   scm_conf_pcie: tisyscon@1c24 {


   Please use the generic node names as the ePAPR standard says.

[...]

MBR, 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 v2] irqchip: omap-intc: add support for spurious irq handling

[Sekhar Nori]

On Thursday 10 December 2015 08:46 PM, Sekhar Nori wrote:
> Hi Felipe,
> 
> On Tuesday 08 December 2015 07:15 PM, Felipe Balbi wrote:
>> Sekhar Nori  writes:
> 
>>> +   /*
>>> +* A spurious IRQ can result if interrupt that triggered the
>>> +* sorting is no longer active during the sorting (10 INTC
>>> +* functional clock cycles after interrupt assertion). Or a
>>> +* change in interrupt mask affected the result during sorting
>>> +* time. There is no special handling required except ignoring
>>> +* the SIR register value just read and retrying.
>>> +* See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
>>> +*
>>> +* Many a times, a spurious interrupt situation has been fixed
>>> +* by adding a flush for the posted write acking the IRQ in
>>> +* the device driver. Typically, this is going be the device
>>> +* driver whose interrupt was handled just before the spurious
>>> +* IRQ occurred. Pay attention to those device drivers if you
>>> +* run into hitting the spurious IRQ condition below.
>>> +*/
>>> +   if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
>>
>> sounds like unlikely() wouldn't hurt here.
> 
> I can add, but looks like it does not make a big difference. See below.
> 
>>
>>> +   pr_err_once("%s: spurious irq!\n", __func__);
>>> +   irq_err_count++;
>>> +   omap_ack_irq(NULL);
>>> +   return;
>>> +   }
>>> +
>>> irqnr &= ACTIVEIRQ_MASK;
>>> -   WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>>> handle_domain_irq(domain, irqnr, regs);
>>
>> care to run kernel function profiler against omap_intc_handle_irq()
>> before and after this patch ?
> 
> Before this patch I see average running time time of 34us. That
> increases to 37.8us after this patch. With unlikely() the number I got
> was 37.4us. So the benefit with unlikely() is in the noise range.
> 
> This was using AM335x EVM at 720 MHz.

Just sent a v3 with unlikely() and profiling information added to commit
message.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] irqchip: omap-intc: add support for spurious irq handling

[Sekhar Nori]

Under some conditions, irq sorting procedure used
by INTC can go wrong resulting in a spurious irq
getting reported.

If this condition is not handled, it results in
endless stream of:

unexpected IRQ trap at vector 00

messages from ack_bad_irq()

Handle the spurious interrupt condition in omap-intc
driver to prevent this.

Measurements using kernel function profiler on AM335x
EVM running at 720MHz show that after this patch
omap_intc_handle_irq() takes about 37.4us against
34us before this patch.

Signed-off-by: Sekhar Nori 
---
v3: add unlikely(), add profiling information
to commit message.

v2: increment error irq counter, use pr_err_once,
add a comment on tips to debug spurious irq
condition.

This patch results in a checkpatch warning about
extern definition of irq_err_count, but looks like
thats the prevalent method of accessing that counter.

 drivers/irqchip/irq-omap-intc.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 8587d0f8d8c0..f6cb1b8bb981 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -47,6 +47,7 @@
 #define INTC_ILR0  0x0100
 
 #define ACTIVEIRQ_MASK 0x7f/* omap2/3 active interrupt bits */
+#define SPURIOUSIRQ_MASK   (0x1ff << 7)
 #define INTCPS_NR_ILR_REGS 128
 #define INTCPS_NR_MIR_REGS 4
 
@@ -330,11 +331,35 @@ static int __init omap_init_irq(u32 base, struct 
device_node *node)
 static asmlinkage void __exception_irq_entry
 omap_intc_handle_irq(struct pt_regs *regs)
 {
+   extern unsigned long irq_err_count;
u32 irqnr;
 
irqnr = intc_readl(INTC_SIR);
+
+   /*
+* A spurious IRQ can result if interrupt that triggered the
+* sorting is no longer active during the sorting (10 INTC
+* functional clock cycles after interrupt assertion). Or a
+* change in interrupt mask affected the result during sorting
+* time. There is no special handling required except ignoring
+* the SIR register value just read and retrying.
+* See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
+*
+* Many a times, a spurious interrupt situation has been fixed
+* by adding a flush for the posted write acking the IRQ in
+* the device driver. Typically, this is going be the device
+* driver whose interrupt was handled just before the spurious
+* IRQ occurred. Pay attention to those device drivers if you
+* run into hitting the spurious IRQ condition below.
+*/
+   if (unlikely((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK)) {
+   pr_err_once("%s: spurious irq!\n", __func__);
+   irq_err_count++;
+   omap_ack_irq(NULL);
+   return;
+   }
+
irqnr &= ACTIVEIRQ_MASK;
-   WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
handle_domain_irq(domain, irqnr, regs);
 }
 
-- 
2.6.3

--
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: debugging

[Felipe Balbi]

Hi,

Ryan  writes:
> Hi Felipe,
>
> On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> (please avoid top-posting)
>>
>> Ryan  writes:
>>> Hi Tony,
>>>
>>> Thanks for your response. I dont see any prints. I suspect that it
>>> might be hanging before the serial port is initialized
>>>
>>> All i see is after arch_reset is called. I can see that is mmc clk and
>>> data signals toggling. This makes me think that boot rom has loaded
>>> the xloader into sram.
>>
>> you might wanna consider openocd if your jtag interface is available
>> somewhere on your pcb. Just keep in mind that you might have to fiddle a
>> bit with some TCL config files to get openocd to behave correctly with
>> your board.
>>
>
> I managed to connect a lauterbach debugger. to my target. This is what
> i did to test
>
> 1. reset the board.  & stop at u-boot prompt
> 2. Do a system.attach on the T32 (Lauterbach says that system is ready)
> 3. I do a run on the T32. I see that the status changes on T32 to run.
> 4. Now, i try to play with the u-boot prompt and board does not
> respond.

is CPU, perhaps, halted ?

> Any idea what i am doing wrong? The PC is pointing to some address
> 0x28000 and does not change.

yeah, it's halted. I don't know much about T32, you might wanna read its
documentation, though.

> I expect the PC to be some address in the RAM since mmu is off.
>
> Also, do i need to compile the x-loader and u-boot with some special
> options & how do i tell the T32 to pick the map file for x-loader and
> u-boot?

yeah, you gotta read T32's documentation. I can't help there :-p

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling

[Tony Lindgren]

* Sekhar Nori  [151215 06:26]:
> Under some conditions, irq sorting procedure used
> by INTC can go wrong resulting in a spurious irq
> getting reported.
> 
> If this condition is not handled, it results in
> endless stream of:
> 
> unexpected IRQ trap at vector 00
> 
> messages from ack_bad_irq()
> 
> Handle the spurious interrupt condition in omap-intc
> driver to prevent this.
> 
> Measurements using kernel function profiler on AM335x
> EVM running at 720MHz show that after this patch
> omap_intc_handle_irq() takes about 37.4us against
> 34us before this patch.
> 
> Signed-off-by: Sekhar Nori 

Looks good to me, probably should get tagged Cc stable when
committing:

Acked-by: Tony Lindgren 


> ---
> v3: add unlikely(), add profiling information
> to commit message.
> 
> v2: increment error irq counter, use pr_err_once,
> add a comment on tips to debug spurious irq
> condition.
> 
> This patch results in a checkpatch warning about
> extern definition of irq_err_count, but looks like
> thats the prevalent method of accessing that counter.
> 
>  drivers/irqchip/irq-omap-intc.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 8587d0f8d8c0..f6cb1b8bb981 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -47,6 +47,7 @@
>  #define INTC_ILR00x0100
>  
>  #define ACTIVEIRQ_MASK   0x7f/* omap2/3 active interrupt 
> bits */
> +#define SPURIOUSIRQ_MASK (0x1ff << 7)
>  #define INTCPS_NR_ILR_REGS   128
>  #define INTCPS_NR_MIR_REGS   4
>  
> @@ -330,11 +331,35 @@ static int __init omap_init_irq(u32 base, struct 
> device_node *node)
>  static asmlinkage void __exception_irq_entry
>  omap_intc_handle_irq(struct pt_regs *regs)
>  {
> + extern unsigned long irq_err_count;
>   u32 irqnr;
>  
>   irqnr = intc_readl(INTC_SIR);
> +
> + /*
> +  * A spurious IRQ can result if interrupt that triggered the
> +  * sorting is no longer active during the sorting (10 INTC
> +  * functional clock cycles after interrupt assertion). Or a
> +  * change in interrupt mask affected the result during sorting
> +  * time. There is no special handling required except ignoring
> +  * the SIR register value just read and retrying.
> +  * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
> +  *
> +  * Many a times, a spurious interrupt situation has been fixed
> +  * by adding a flush for the posted write acking the IRQ in
> +  * the device driver. Typically, this is going be the device
> +  * driver whose interrupt was handled just before the spurious
> +  * IRQ occurred. Pay attention to those device drivers if you
> +  * run into hitting the spurious IRQ condition below.
> +  */
> + if (unlikely((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK)) {
> + pr_err_once("%s: spurious irq!\n", __func__);
> + irq_err_count++;
> + omap_ack_irq(NULL);
> + return;
> + }
> +
>   irqnr &= ACTIVEIRQ_MASK;
> - WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>   handle_domain_irq(domain, irqnr, regs);
>  }
>  
> -- 
> 2.6.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

[Paul Gortmaker]

[Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*] On 
14/12/2015 (Mon 11:27) Arnd Bergmann wrote:

> On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > > Fixup region is in kernel region and this region if not updated when
> > > loading a module.
> > 
> > Interesting, I hadn't thought about that. I suppose this means that the
> > module will end up containing an unused section with the fixup code. It
> > might be useful to add a way for that to trigger a warning at build
> > time.
> > 
> > Perhaps to fix this a mechanism could be introduced to add a table of
> > fixups to a host controller driver and that will get applied to all
> > children of the bridge. It could be problematic to cover all of the
> > different fixup stages, though.
> > 
> 
> 
> I think a lot of the fixups shouldn't really be there in the first place,
> they are about stuff that we can fix up in the probe function, or that should
> be fixed up in the probe function with some appropriate core support added.

So, the feedback on this is a bit all over the map, leaving me unsure
what to do next.  And is the choice we make on a per board/bsp basis or
ideally across all platforms?  I see the choices as:

1) do nothing; which IMHO is least desirable as it leaves the code
misrepresenting itself as modular; one of the key issues I wanted to fix

2) use the patches I've sent ; then as they are genuinely made modular,
the person doing so essentially "patch -R" or reverts the change as
step one.  This has the advantage of solving the "we'll get to it
someday" issue if someday never comes.

3) make them all tristate;  beat it with a stick until it compiles [M]
and modposts -- leaving the fixups and functional testing to people with
the boards and low level knowledge to make it _work_ as a module.  The
downside here is the code is still kind of misrepresenting itself as
modularly functional -- a ban of unloading might mitigate that some.

Paul.
--

> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tony Lindgren]

* Kishon Vijay Abraham I  [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-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] drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY

[Markus Brunner]

On Monday 14 December 2015 13:04:46 David Rivshin wrote:
> On Sat, 12 Dec 2015 16:44:19 +0100
...
> > Your patch works fine on my board, which uses MII and dual_emac with
> > a fixed_phy and a real one.
> 
> Thanks for checking. The only dual_emac board I have available is the
> EVMSK, which has two real PHYs. I'm not sure of the usual etiquette
> (and Google was  unhelpful), should I add a Tested-by on the next
> version?
> 
Yes you can. Documentation/SubmittingPatches has some notes about it.

> > > Besides fixing the bug mentioned in the commit log, there are a few
> > > 
> > > other differences to note:
> > >  * If both "phy_id" and a "fixed-link" subnode are present this
> > > 
> > > patch will use the "phy_id" property. This should preserve current
> > > behavior with existing devicetrees that might incorrectly have
> > > both. This motivates the biggest difference in code organization
> > > from 1f71e8c96fc6.
> > > 
> > >  * Some error messages have been tweaked to reflect the slightly
> > > 
> > > changed meanings of the checks.
> > 
> > I wanted to keep changes small and didn't spend too much thinking
> > about already broken devicetrees. Since my patch is quite new, I
> 
> I'm honestly not sure it's an important consideration myself. Most
> patches I've seen in this area for this or other drivers do not take
> such behavior into account (e.g. the phy-handle parsing that went in
> to cpsw in 4.3).
> I would generally feel more comfortable with such a behavior tweak
> (minor as it is) before 4.4 is released, to avoid ping-ponging the
> behavior. But given how far along the cycle is, I'm not sure about
> the chances of that.
> 

Well I don't think compatibility for flawed DTs is such a high priority, 
especially if it is that unlikely that there are some affected.
Keep the focus on the other _real_ problems you have encountered and fix those 
like you see fit. 

> > don't see any problems with subtle changes like that. However you
> > should update the documentation as well.
> 
> Your patch already updated .../bindings/net/cpsw.txt, which this
> patch left alone. Are you referring to some other documentation,
> or do you think I should update the binding documentation to state
> that phy_id takes precedence over fixed-link? I figured that such
> devicetrees were still officially malformed, so I thought the
> existing text was appropriate.

"Either the properties phy_id and phy-mode, or the sub-node fixed-link can be 
specified"
One flaw of my patch was to ignore the phy-mode for a fixed link. Do not 
mention the precedence of the phy_id, because it is an undefined behavior.
Your patch should change it to:
"Either the property phy_id, or the sub-node fixed-link can be specified"


--
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