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 08:56 PM, Tony Lindgren wrote:
> * 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?

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

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

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