Message ID | cover.fbf0776c70c0cfb7b7fd88ce6a96b4597d620cac.1548085432.git-series.maxime.ripard@bootlin.com (mailing list archive) |
---|---|
Headers | show |
Series | phy: Add configuration interface for MIPI D-PHY devices | expand |
On 21/01/19 9:15 PM, Maxime Ripard wrote: > Hi, > > Here is a set of patches to allow the phy framework consumers to test and > apply runtime configurations. > > This is needed to support more phy classes that require tuning based on > parameters depending on the current use case of the device, in addition to > the power state management already provided by the current functions. > > A first test bed for that API are the MIPI D-PHY devices. There's a number > of solutions that have been used so far to support these phy, most of the > time being an ad-hoc driver in the consumer. > > That approach has a big shortcoming though, which is that this is quite > difficult to deal with consumers integrated with multiple variants of phy, > of multiple consumers integrated with the same phy. > > The latter case can be found in the Cadence DSI bridge, and the CSI > transceiver and receivers. All of them are integrated with the same phy, or > can be integrated with different phy, depending on the implementation. > > I've looked at all the MIPI DSI drivers I could find, and gathered all the > parameters I could find. The interface should be complete, and most of the > drivers can be converted in the future. The current set converts two of > them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > use them, and the Allwinner MIPI-DSI driver. Can the PHY changes go independently of the consumer drivers? or else I'll need ACKs from the GPU MAINTAINER. Thanks Kishon > > Let me know what you think, > Maxime > > Changes from v4: > - Removed regression on the variable calculation > - Fixed the wakeup unit > - Collected Sean Acked-by on the last patch > - Collected Sakari Reviewed-by on the first patch > > Changes from v3 > - Rebased on 5.0-rc1 > - Added the fixes suggested by Sakari > > Changes from v2: > - Rebased on next > - Changed the interface to accomodate for the new submodes > - Changed the timings units from nanoseconds to picoseconds > - Added minimum and maximum boundaries to the documentation > - Moved the clock enabling to phy_power_on in the Cadence DPHY driver > - Exported the phy_configure and phy_validate symbols > - Rework the phy pll divider computation in the cadence dphy driver > > Changes from v1: > - Rebased on top of 4.20-rc1 > - Removed the bus mode and timings parameters from the MIPI D-PHY > parameters, since that shouldn't have any impact on the PHY itself. > - Reworked the Cadence DSI and D-PHY drivers to take this into account. > - Remove the mode parameter from phy_configure > - Added phy_configure and phy_validate stubs > - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation > is not implemented > > Maxime Ripard (9): > phy: dphy: Remove unused header > phy: dphy: Change units of wakeup and init parameters > phy: dphy: Clarify lanes parameter documentation > sun6i: dsi: Convert to generic phy handling > phy: Move Allwinner A31 D-PHY driver to drivers/phy/ > drm/bridge: cdns: Separate DSI and D-PHY configuration > dt-bindings: phy: Move the Cadence D-PHY bindings > phy: Add Cadence D-PHY support > drm/bridge: cdns: Convert to phy framework > > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +- > Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +- > drivers/gpu/drm/bridge/Kconfig | 1 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 538 +------ > drivers/gpu/drm/sun4i/Kconfig | 3 +- > drivers/gpu/drm/sun4i/Makefile | 5 +- > drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 292 +---- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 31 +- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 17 +- > drivers/phy/allwinner/Kconfig | 12 +- > drivers/phy/allwinner/Makefile | 1 +- > drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 ++++- > drivers/phy/cadence/Kconfig | 13 +- > drivers/phy/cadence/Makefile | 1 +- > drivers/phy/cadence/cdns-dphy.c | 389 +++++- > drivers/phy/phy-core-mipi-dphy.c | 8 +- > include/linux/phy/phy-mipi-dphy.h | 13 +- > 17 files changed, 894 insertions(+), 789 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt > delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c > create mode 100644 drivers/phy/cadence/cdns-dphy.c > > base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c >
Hi Kishon, On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: > On 21/01/19 9:15 PM, Maxime Ripard wrote: > > Here is a set of patches to allow the phy framework consumers to test and > > apply runtime configurations. > > > > This is needed to support more phy classes that require tuning based on > > parameters depending on the current use case of the device, in addition to > > the power state management already provided by the current functions. > > > > A first test bed for that API are the MIPI D-PHY devices. There's a number > > of solutions that have been used so far to support these phy, most of the > > time being an ad-hoc driver in the consumer. > > > > That approach has a big shortcoming though, which is that this is quite > > difficult to deal with consumers integrated with multiple variants of phy, > > of multiple consumers integrated with the same phy. > > > > The latter case can be found in the Cadence DSI bridge, and the CSI > > transceiver and receivers. All of them are integrated with the same phy, or > > can be integrated with different phy, depending on the implementation. > > > > I've looked at all the MIPI DSI drivers I could find, and gathered all the > > parameters I could find. The interface should be complete, and most of the > > drivers can be converted in the future. The current set converts two of > > them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > > use them, and the Allwinner MIPI-DSI driver. > > Can the PHY changes go independently of the consumer drivers? or else I'll need > ACKs from the GPU MAINTAINER. At least for the Allwinner driver, they can go through through the drm-misc tree. Since we have a number of patches in flight for that driver, it would even be easier to handle there. For the cadence driver, since it doesn't really work on any system but simulators for now, I guess the wakeup regression isn't super important either. So I'd say we can have the phy related patches go through your tree, and the other through drm-misc. Would that work for you? Maxime
On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: > > > On 21/01/19 9:15 PM, Maxime Ripard wrote: > > Hi, > > > > Here is a set of patches to allow the phy framework consumers to test and > > apply runtime configurations. > > > > This is needed to support more phy classes that require tuning based on > > parameters depending on the current use case of the device, in addition to > > the power state management already provided by the current functions. > > > > A first test bed for that API are the MIPI D-PHY devices. There's a number > > of solutions that have been used so far to support these phy, most of the > > time being an ad-hoc driver in the consumer. > > > > That approach has a big shortcoming though, which is that this is quite > > difficult to deal with consumers integrated with multiple variants of phy, > > of multiple consumers integrated with the same phy. > > > > The latter case can be found in the Cadence DSI bridge, and the CSI > > transceiver and receivers. All of them are integrated with the same phy, or > > can be integrated with different phy, depending on the implementation. > > > > I've looked at all the MIPI DSI drivers I could find, and gathered all the > > parameters I could find. The interface should be complete, and most of the > > drivers can be converted in the future. The current set converts two of > > them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > > use them, and the Allwinner MIPI-DSI driver. > > Can the PHY changes go independently of the consumer drivers? or else I'll need > ACKs from the GPU MAINTAINER. Maxime is a gpu maintainer, so you're all good :-) -Daniel > > Thanks > Kishon > > > > > Let me know what you think, > > Maxime > > > > Changes from v4: > > - Removed regression on the variable calculation > > - Fixed the wakeup unit > > - Collected Sean Acked-by on the last patch > > - Collected Sakari Reviewed-by on the first patch > > > > Changes from v3 > > - Rebased on 5.0-rc1 > > - Added the fixes suggested by Sakari > > > > Changes from v2: > > - Rebased on next > > - Changed the interface to accomodate for the new submodes > > - Changed the timings units from nanoseconds to picoseconds > > - Added minimum and maximum boundaries to the documentation > > - Moved the clock enabling to phy_power_on in the Cadence DPHY driver > > - Exported the phy_configure and phy_validate symbols > > - Rework the phy pll divider computation in the cadence dphy driver > > > > Changes from v1: > > - Rebased on top of 4.20-rc1 > > - Removed the bus mode and timings parameters from the MIPI D-PHY > > parameters, since that shouldn't have any impact on the PHY itself. > > - Reworked the Cadence DSI and D-PHY drivers to take this into account. > > - Remove the mode parameter from phy_configure > > - Added phy_configure and phy_validate stubs > > - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation > > is not implemented > > > > Maxime Ripard (9): > > phy: dphy: Remove unused header > > phy: dphy: Change units of wakeup and init parameters > > phy: dphy: Clarify lanes parameter documentation > > sun6i: dsi: Convert to generic phy handling > > phy: Move Allwinner A31 D-PHY driver to drivers/phy/ > > drm/bridge: cdns: Separate DSI and D-PHY configuration > > dt-bindings: phy: Move the Cadence D-PHY bindings > > phy: Add Cadence D-PHY support > > drm/bridge: cdns: Convert to phy framework > > > > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +- > > Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +- > > drivers/gpu/drm/bridge/Kconfig | 1 +- > > drivers/gpu/drm/bridge/cdns-dsi.c | 538 +------ > > drivers/gpu/drm/sun4i/Kconfig | 3 +- > > drivers/gpu/drm/sun4i/Makefile | 5 +- > > drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 292 +---- > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 31 +- > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 17 +- > > drivers/phy/allwinner/Kconfig | 12 +- > > drivers/phy/allwinner/Makefile | 1 +- > > drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 ++++- > > drivers/phy/cadence/Kconfig | 13 +- > > drivers/phy/cadence/Makefile | 1 +- > > drivers/phy/cadence/cdns-dphy.c | 389 +++++- > > drivers/phy/phy-core-mipi-dphy.c | 8 +- > > include/linux/phy/phy-mipi-dphy.h | 13 +- > > 17 files changed, 894 insertions(+), 789 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt > > delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > > create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c > > create mode 100644 drivers/phy/cadence/cdns-dphy.c > > > > base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi, On 05/02/19 2:16 PM, Daniel Vetter wrote: > On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: >> >> >> On 21/01/19 9:15 PM, Maxime Ripard wrote: >>> Hi, >>> >>> Here is a set of patches to allow the phy framework consumers to test and >>> apply runtime configurations. >>> >>> This is needed to support more phy classes that require tuning based on >>> parameters depending on the current use case of the device, in addition to >>> the power state management already provided by the current functions. >>> >>> A first test bed for that API are the MIPI D-PHY devices. There's a number >>> of solutions that have been used so far to support these phy, most of the >>> time being an ad-hoc driver in the consumer. >>> >>> That approach has a big shortcoming though, which is that this is quite >>> difficult to deal with consumers integrated with multiple variants of phy, >>> of multiple consumers integrated with the same phy. >>> >>> The latter case can be found in the Cadence DSI bridge, and the CSI >>> transceiver and receivers. All of them are integrated with the same phy, or >>> can be integrated with different phy, depending on the implementation. >>> >>> I've looked at all the MIPI DSI drivers I could find, and gathered all the >>> parameters I could find. The interface should be complete, and most of the >>> drivers can be converted in the future. The current set converts two of >>> them: the above mentionned Cadence DSI driver so that the v4l2 drivers can >>> use them, and the Allwinner MIPI-DSI driver. >> >> Can the PHY changes go independently of the consumer drivers? or else I'll need >> ACKs from the GPU MAINTAINER. > > Maxime is a gpu maintainer, so you're all good :-) cool.. I've merged all the patches except drm/bridge. Please see if everything looks okay once it shows up in phy -next (give a day) Thanks Kishon > -Daniel > >> >> Thanks >> Kishon >> >>> >>> Let me know what you think, >>> Maxime >>> >>> Changes from v4: >>> - Removed regression on the variable calculation >>> - Fixed the wakeup unit >>> - Collected Sean Acked-by on the last patch >>> - Collected Sakari Reviewed-by on the first patch >>> >>> Changes from v3 >>> - Rebased on 5.0-rc1 >>> - Added the fixes suggested by Sakari >>> >>> Changes from v2: >>> - Rebased on next >>> - Changed the interface to accomodate for the new submodes >>> - Changed the timings units from nanoseconds to picoseconds >>> - Added minimum and maximum boundaries to the documentation >>> - Moved the clock enabling to phy_power_on in the Cadence DPHY driver >>> - Exported the phy_configure and phy_validate symbols >>> - Rework the phy pll divider computation in the cadence dphy driver >>> >>> Changes from v1: >>> - Rebased on top of 4.20-rc1 >>> - Removed the bus mode and timings parameters from the MIPI D-PHY >>> parameters, since that shouldn't have any impact on the PHY itself. >>> - Reworked the Cadence DSI and D-PHY drivers to take this into account. >>> - Remove the mode parameter from phy_configure >>> - Added phy_configure and phy_validate stubs >>> - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation >>> is not implemented >>> >>> Maxime Ripard (9): >>> phy: dphy: Remove unused header >>> phy: dphy: Change units of wakeup and init parameters >>> phy: dphy: Clarify lanes parameter documentation >>> sun6i: dsi: Convert to generic phy handling >>> phy: Move Allwinner A31 D-PHY driver to drivers/phy/ >>> drm/bridge: cdns: Separate DSI and D-PHY configuration >>> dt-bindings: phy: Move the Cadence D-PHY bindings >>> phy: Add Cadence D-PHY support >>> drm/bridge: cdns: Convert to phy framework >>> >>> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +- >>> Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +- >>> drivers/gpu/drm/bridge/Kconfig | 1 +- >>> drivers/gpu/drm/bridge/cdns-dsi.c | 538 +------ >>> drivers/gpu/drm/sun4i/Kconfig | 3 +- >>> drivers/gpu/drm/sun4i/Makefile | 5 +- >>> drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 292 +---- >>> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 31 +- >>> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 17 +- >>> drivers/phy/allwinner/Kconfig | 12 +- >>> drivers/phy/allwinner/Makefile | 1 +- >>> drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 ++++- >>> drivers/phy/cadence/Kconfig | 13 +- >>> drivers/phy/cadence/Makefile | 1 +- >>> drivers/phy/cadence/cdns-dphy.c | 389 +++++- >>> drivers/phy/phy-core-mipi-dphy.c | 8 +- >>> include/linux/phy/phy-mipi-dphy.h | 13 +- >>> 17 files changed, 894 insertions(+), 789 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt >>> delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c >>> create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c >>> create mode 100644 drivers/phy/cadence/cdns-dphy.c >>> >>> base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c >>> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >
Hi Kishon, On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote: > On 05/02/19 2:16 PM, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: > >> > >> > >> On 21/01/19 9:15 PM, Maxime Ripard wrote: > >>> Hi, > >>> > >>> Here is a set of patches to allow the phy framework consumers to test and > >>> apply runtime configurations. > >>> > >>> This is needed to support more phy classes that require tuning based on > >>> parameters depending on the current use case of the device, in addition to > >>> the power state management already provided by the current functions. > >>> > >>> A first test bed for that API are the MIPI D-PHY devices. There's a number > >>> of solutions that have been used so far to support these phy, most of the > >>> time being an ad-hoc driver in the consumer. > >>> > >>> That approach has a big shortcoming though, which is that this is quite > >>> difficult to deal with consumers integrated with multiple variants of phy, > >>> of multiple consumers integrated with the same phy. > >>> > >>> The latter case can be found in the Cadence DSI bridge, and the CSI > >>> transceiver and receivers. All of them are integrated with the same phy, or > >>> can be integrated with different phy, depending on the implementation. > >>> > >>> I've looked at all the MIPI DSI drivers I could find, and gathered all the > >>> parameters I could find. The interface should be complete, and most of the > >>> drivers can be converted in the future. The current set converts two of > >>> them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > >>> use them, and the Allwinner MIPI-DSI driver. > >> > >> Can the PHY changes go independently of the consumer drivers? or else I'll need > >> ACKs from the GPU MAINTAINER. > > > > Maxime is a gpu maintainer, so you're all good :-) > > cool.. I've merged all the patches except drm/bridge. > > Please see if everything looks okay once it shows up in phy -next (give a day) Thanks! If possible (and if that's still an option), it would be better if the sun6i related patches (patches 4 and 5) would go through the DRM tree (with your Acked-by of course). We have a number of patches in flight that have a decent chance to conflict with patch 4. Maxime
Hi, On 06/02/19 5:55 PM, Maxime Ripard wrote: > Hi Kishon, > > On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote: >> On 05/02/19 2:16 PM, Daniel Vetter wrote: >>> On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: >>>> >>>> >>>> On 21/01/19 9:15 PM, Maxime Ripard wrote: >>>>> Hi, >>>>> >>>>> Here is a set of patches to allow the phy framework consumers to test and >>>>> apply runtime configurations. >>>>> >>>>> This is needed to support more phy classes that require tuning based on >>>>> parameters depending on the current use case of the device, in addition to >>>>> the power state management already provided by the current functions. >>>>> >>>>> A first test bed for that API are the MIPI D-PHY devices. There's a number >>>>> of solutions that have been used so far to support these phy, most of the >>>>> time being an ad-hoc driver in the consumer. >>>>> >>>>> That approach has a big shortcoming though, which is that this is quite >>>>> difficult to deal with consumers integrated with multiple variants of phy, >>>>> of multiple consumers integrated with the same phy. >>>>> >>>>> The latter case can be found in the Cadence DSI bridge, and the CSI >>>>> transceiver and receivers. All of them are integrated with the same phy, or >>>>> can be integrated with different phy, depending on the implementation. >>>>> >>>>> I've looked at all the MIPI DSI drivers I could find, and gathered all the >>>>> parameters I could find. The interface should be complete, and most of the >>>>> drivers can be converted in the future. The current set converts two of >>>>> them: the above mentionned Cadence DSI driver so that the v4l2 drivers can >>>>> use them, and the Allwinner MIPI-DSI driver. >>>> >>>> Can the PHY changes go independently of the consumer drivers? or else I'll need >>>> ACKs from the GPU MAINTAINER. >>> >>> Maxime is a gpu maintainer, so you're all good :-) >> >> cool.. I've merged all the patches except drm/bridge. >> >> Please see if everything looks okay once it shows up in phy -next (give a day) > > Thanks! > > If possible (and if that's still an option), it would be better if the > sun6i related patches (patches 4 and 5) would go through the DRM tree > (with your Acked-by of course). > > We have a number of patches in flight that have a decent chance to > conflict with patch 4. Sure. Dropped patches 4 and 5 from my tree. Thanks Kishon
Hi Kishon, On Wed, Feb 06, 2019 at 06:00:19PM +0530, Kishon Vijay Abraham I wrote: > On 06/02/19 5:55 PM, Maxime Ripard wrote: > > On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote: > >> On 05/02/19 2:16 PM, Daniel Vetter wrote: > >>> On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: > >>>> > >>>> > >>>> On 21/01/19 9:15 PM, Maxime Ripard wrote: > >>>>> Hi, > >>>>> > >>>>> Here is a set of patches to allow the phy framework consumers to test and > >>>>> apply runtime configurations. > >>>>> > >>>>> This is needed to support more phy classes that require tuning based on > >>>>> parameters depending on the current use case of the device, in addition to > >>>>> the power state management already provided by the current functions. > >>>>> > >>>>> A first test bed for that API are the MIPI D-PHY devices. There's a number > >>>>> of solutions that have been used so far to support these phy, most of the > >>>>> time being an ad-hoc driver in the consumer. > >>>>> > >>>>> That approach has a big shortcoming though, which is that this is quite > >>>>> difficult to deal with consumers integrated with multiple variants of phy, > >>>>> of multiple consumers integrated with the same phy. > >>>>> > >>>>> The latter case can be found in the Cadence DSI bridge, and the CSI > >>>>> transceiver and receivers. All of them are integrated with the same phy, or > >>>>> can be integrated with different phy, depending on the implementation. > >>>>> > >>>>> I've looked at all the MIPI DSI drivers I could find, and gathered all the > >>>>> parameters I could find. The interface should be complete, and most of the > >>>>> drivers can be converted in the future. The current set converts two of > >>>>> them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > >>>>> use them, and the Allwinner MIPI-DSI driver. > >>>> > >>>> Can the PHY changes go independently of the consumer drivers? or else I'll need > >>>> ACKs from the GPU MAINTAINER. > >>> > >>> Maxime is a gpu maintainer, so you're all good :-) > >> > >> cool.. I've merged all the patches except drm/bridge. > >> > >> Please see if everything looks okay once it shows up in phy -next (give a day) > > > > Thanks! > > > > If possible (and if that's still an option), it would be better if the > > sun6i related patches (patches 4 and 5) would go through the DRM tree > > (with your Acked-by of course). > > > > We have a number of patches in flight that have a decent chance to > > conflict with patch 4. > > Sure. Dropped patches 4 and 5 from my tree. Thanks! I've pushed the rest into drm-misc. Maxime