| Message ID | 20230518230626.404068-1-aford173@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: bridge: samsung-dsim: Support variable clocking | expand |
Hi Adam, On Thu, May 18, 2023 at 8:06 PM Adam Ford <aford173@gmail.com> wrote: > > This series fixes the blanking pack size and the PMS calculation. It then > adds support to allows the DSIM to dynamically DPHY clocks, and support > non-burst mode while allowing the removal of the hard-coded clock values > for the PLL for imx8m mini/nano/plus, and it allows the removal of the > burst-clock device tree entry when burst-mode isn't supported by connected > devices like an HDMI brige. In that event, the HS clock is set to the > value requested by the bridge chip. > > This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should > work on i.MX8M Mini as well. Marek Szyprowski has tested it on various > Exynos boards. > > Adam Ford (5): > drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] > drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically > drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY > drm: bridge: samsung-dsim: Dynamically configure DPHY timing > drm: bridge: samsung-dsim: Support non-burst mode > > Lucas Stach (1): > drm: bridge: samsung-dsim: fix blanking packet size calculation > > drivers/gpu/drm/bridge/Kconfig | 1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 142 +++++++++++++++++++++----- > include/drm/bridge/samsung-dsim.h | 4 + > 3 files changed, 124 insertions(+), 23 deletions(-) > > V7: Move messages indicating the optional device tree items are going > to be automatically read elsewhere was move to dev_dbg instead of > dev_info. Cleaned up some of the comments to be a bit more clear. > Eliminated a double variable assignement accidentally introduced > in V6 when some of the items were moved from patch 6 to patch 5. It seems you missed addressing one previous comment from Lucas: "Same as with the earlier patch, this needs to be documented in the DT binding by moving "samsung,burst-clock-frequency" to be a optional property."
On Thu, May 18, 2023 at 7:29 PM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Adam, > > On Thu, May 18, 2023 at 8:06 PM Adam Ford <aford173@gmail.com> wrote: > > > > This series fixes the blanking pack size and the PMS calculation. It then > > adds support to allows the DSIM to dynamically DPHY clocks, and support > > non-burst mode while allowing the removal of the hard-coded clock values > > for the PLL for imx8m mini/nano/plus, and it allows the removal of the > > burst-clock device tree entry when burst-mode isn't supported by connected > > devices like an HDMI brige. In that event, the HS clock is set to the > > value requested by the bridge chip. > > > > This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should > > work on i.MX8M Mini as well. Marek Szyprowski has tested it on various > > Exynos boards. > > > > Adam Ford (5): > > drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] > > drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically > > drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY > > drm: bridge: samsung-dsim: Dynamically configure DPHY timing > > drm: bridge: samsung-dsim: Support non-burst mode > > > > Lucas Stach (1): > > drm: bridge: samsung-dsim: fix blanking packet size calculation > > > > drivers/gpu/drm/bridge/Kconfig | 1 + > > drivers/gpu/drm/bridge/samsung-dsim.c | 142 +++++++++++++++++++++----- > > include/drm/bridge/samsung-dsim.h | 4 + > > 3 files changed, 124 insertions(+), 23 deletions(-) > > > > V7: Move messages indicating the optional device tree items are going > > to be automatically read elsewhere was move to dev_dbg instead of > > dev_info. Cleaned up some of the comments to be a bit more clear. > > Eliminated a double variable assignement accidentally introduced > > in V6 when some of the items were moved from patch 6 to patch 5. > > It seems you missed addressing one previous comment from Lucas: > > "Same as with the earlier patch, this needs to be documented in the DT > binding by moving "samsung,burst-clock-frequency" to be a optional > property." Aargh! I can't believe I did that. Inki, Can I do a single patch to which references this one and have you apply them together when the time is right, or do you want me to resend the whole series with an additional patch at the end making the two device tree items optional? I totally forgot, and I'm sorry. adam A
On Thu, May 18, 2023 at 8:34 PM Adam Ford <aford173@gmail.com> wrote: > > On Thu, May 18, 2023 at 7:29 PM Fabio Estevam <festevam@gmail.com> wrote: > > > > Hi Adam, > > > > On Thu, May 18, 2023 at 8:06 PM Adam Ford <aford173@gmail.com> wrote: > > > > > > This series fixes the blanking pack size and the PMS calculation. It then > > > adds support to allows the DSIM to dynamically DPHY clocks, and support > > > non-burst mode while allowing the removal of the hard-coded clock values > > > for the PLL for imx8m mini/nano/plus, and it allows the removal of the > > > burst-clock device tree entry when burst-mode isn't supported by connected > > > devices like an HDMI brige. In that event, the HS clock is set to the > > > value requested by the bridge chip. > > > > > > This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should > > > work on i.MX8M Mini as well. Marek Szyprowski has tested it on various > > > Exynos boards. > > > > > > Adam Ford (5): > > > drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] > > > drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically > > > drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY > > > drm: bridge: samsung-dsim: Dynamically configure DPHY timing > > > drm: bridge: samsung-dsim: Support non-burst mode > > > > > > Lucas Stach (1): > > > drm: bridge: samsung-dsim: fix blanking packet size calculation > > > > > > drivers/gpu/drm/bridge/Kconfig | 1 + > > > drivers/gpu/drm/bridge/samsung-dsim.c | 142 +++++++++++++++++++++----- > > > include/drm/bridge/samsung-dsim.h | 4 + > > > 3 files changed, 124 insertions(+), 23 deletions(-) > > > > > > V7: Move messages indicating the optional device tree items are going > > > to be automatically read elsewhere was move to dev_dbg instead of > > > dev_info. Cleaned up some of the comments to be a bit more clear. > > > Eliminated a double variable assignement accidentally introduced > > > in V6 when some of the items were moved from patch 6 to patch 5. > > > > It seems you missed addressing one previous comment from Lucas: > > > > "Same as with the earlier patch, this needs to be documented in the DT > > binding by moving "samsung,burst-clock-frequency" to be a optional > > property." > > Aargh! > I can't believe I did that. > > Inki, > > Can I do a single patch to which references this one and have you > apply them together when the time is right, or do you want me to > resend the whole series with an additional patch at the end making the > two device tree items optional? Inki, I haven't heard back from you on whether or not you want the bindings patch to be included with me resending the series as V7 or if you're OK with a single, stand-alone patch. Will you let me know? I have the patch standing by waiting for instructions. If you're not the right person to ask, please let me know who the right person is. thanks adam > I totally forgot, and I'm sorry. > > adam > > A
Hi Adam, On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: > Inki, > > I haven't heard back from you on whether or not you want the bindings > patch to be included with me resending the series as V7 or if you're > OK with a single, stand-alone patch. > Will you let me know? I have the patch standing by waiting for > instructions. If you're not the right person to ask, please let me > know who the right person is. Neil has also been collecting samsung-dsim patches. Maybe he can clarify.
On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Adam, > > On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: > > > Inki, > > > > I haven't heard back from you on whether or not you want the bindings > > patch to be included with me resending the series as V7 or if you're > > OK with a single, stand-alone patch. > > Will you let me know? I have the patch standing by waiting for > > instructions. If you're not the right person to ask, please let me > > know who the right person is. > > Neil has also been collecting samsung-dsim patches. Maybe he can clarify. If it matters, my preference all along was to do the bindings as a separate thing once the driver updates were merged into the tree. Since the bindings can be done in different ways, I was hoping to have a separate discussion on the right way to do the bindings. If they need to be part of the series, I can do that. adam
On 24/05/2023 14:49, Adam Ford wrote: > On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: >> >> Hi Adam, >> >> On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: >> >>> Inki, >>> >>> I haven't heard back from you on whether or not you want the bindings >>> patch to be included with me resending the series as V7 or if you're >>> OK with a single, stand-alone patch. >>> Will you let me know? I have the patch standing by waiting for >>> instructions. If you're not the right person to ask, please let me >>> know who the right person is. >> >> Neil has also been collecting samsung-dsim patches. Maybe he can clarify. > > If it matters, my preference all along was to do the bindings as a > separate thing once the driver updates were merged into the tree. > Since the bindings can be done in different ways, I was hoping to have > a separate discussion on the right way to do the bindings. If they > need to be part of the series, I can do that. If you don't introduce compatibles, no need to send bindings, it can be send separately. Can I apply this serie and 20230503163313.2640898-2-frieder@fris.de ? seems all has been reviewed. Neil > > adam
On Thu, May 25, 2023 at 10:39 AM Neil Armstrong <neil.armstrong@linaro.org> wrote: > > On 24/05/2023 14:49, Adam Ford wrote: > > On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: > >> > >> Hi Adam, > >> > >> On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: > >> > >>> Inki, > >>> > >>> I haven't heard back from you on whether or not you want the bindings > >>> patch to be included with me resending the series as V7 or if you're > >>> OK with a single, stand-alone patch. > >>> Will you let me know? I have the patch standing by waiting for > >>> instructions. If you're not the right person to ask, please let me > >>> know who the right person is. > >> > >> Neil has also been collecting samsung-dsim patches. Maybe he can clarify. > > > > If it matters, my preference all along was to do the bindings as a > > separate thing once the driver updates were merged into the tree. > > Since the bindings can be done in different ways, I was hoping to have > > a separate discussion on the right way to do the bindings. If they > > need to be part of the series, I can do that. > > If you don't introduce compatibles, no need to send bindings, it can > be send separately. This series doesn't change any compatibility. > > Can I apply this serie and 20230503163313.2640898-2-frieder@fris.de ? seems all has been reviewed. Looking at the driver, it looks like linux-next has some newer features added into the driver since I started, so this series might need a re-base. If that's the case, let me know, and I'll do the re-base. adam > > Neil > > > > > adam >
On 25/05/2023 17:57, Adam Ford wrote: > On Thu, May 25, 2023 at 10:39 AM Neil Armstrong > <neil.armstrong@linaro.org> wrote: >> >> On 24/05/2023 14:49, Adam Ford wrote: >>> On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: >>>> >>>> Hi Adam, >>>> >>>> On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: >>>> >>>>> Inki, >>>>> >>>>> I haven't heard back from you on whether or not you want the bindings >>>>> patch to be included with me resending the series as V7 or if you're >>>>> OK with a single, stand-alone patch. >>>>> Will you let me know? I have the patch standing by waiting for >>>>> instructions. If you're not the right person to ask, please let me >>>>> know who the right person is. >>>> >>>> Neil has also been collecting samsung-dsim patches. Maybe he can clarify. >>> >>> If it matters, my preference all along was to do the bindings as a >>> separate thing once the driver updates were merged into the tree. >>> Since the bindings can be done in different ways, I was hoping to have >>> a separate discussion on the right way to do the bindings. If they >>> need to be part of the series, I can do that. >> >> If you don't introduce compatibles, no need to send bindings, it can >> be send separately. > > This series doesn't change any compatibility. > >> >> Can I apply this serie and 20230503163313.2640898-2-frieder@fris.de ? seems all has been reviewed. > > Looking at the driver, it looks like linux-next has some newer > features added into the driver since I started, so this series might > need a re-base. If that's the case, let me know, and I'll do the > re-base. Ok I'll pull the other bits and let you know if this one needs a rebase. Neil > > adam > >> >> Neil >> >>> >>> adam >>
On 25/05/2023 18:15, neil.armstrong@linaro.org wrote: > On 25/05/2023 17:57, Adam Ford wrote: >> On Thu, May 25, 2023 at 10:39 AM Neil Armstrong >> <neil.armstrong@linaro.org> wrote: >>> >>> On 24/05/2023 14:49, Adam Ford wrote: >>>> On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: >>>>> >>>>> Hi Adam, >>>>> >>>>> On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: >>>>> >>>>>> Inki, >>>>>> >>>>>> I haven't heard back from you on whether or not you want the bindings >>>>>> patch to be included with me resending the series as V7 or if you're >>>>>> OK with a single, stand-alone patch. >>>>>> Will you let me know? I have the patch standing by waiting for >>>>>> instructions. If you're not the right person to ask, please let me >>>>>> know who the right person is. >>>>> >>>>> Neil has also been collecting samsung-dsim patches. Maybe he can clarify. >>>> >>>> If it matters, my preference all along was to do the bindings as a >>>> separate thing once the driver updates were merged into the tree. >>>> Since the bindings can be done in different ways, I was hoping to have >>>> a separate discussion on the right way to do the bindings. If they >>>> need to be part of the series, I can do that. >>> >>> If you don't introduce compatibles, no need to send bindings, it can >>> be send separately. >> >> This series doesn't change any compatibility. >> >>> >>> Can I apply this serie and 20230503163313.2640898-2-frieder@fris.de ? seems all has been reviewed. >> >> Looking at the driver, it looks like linux-next has some newer >> features added into the driver since I started, so this series might >> need a re-base. If that's the case, let me know, and I'll do the >> re-base. > > Ok I'll pull the other bits and let you know if this one needs a rebase. Indeed, starting at patch 3 it fails to apply, a rebase on drm-misc-next is welcome! Neil > > Neil > >> >> adam >> >>> >>> Neil >>> >>>> >>>> adam >>> >
On Thu, May 25, 2023 at 11:19 AM Neil Armstrong <neil.armstrong@linaro.org> wrote: > > On 25/05/2023 18:15, neil.armstrong@linaro.org wrote: > > On 25/05/2023 17:57, Adam Ford wrote: > >> On Thu, May 25, 2023 at 10:39 AM Neil Armstrong > >> <neil.armstrong@linaro.org> wrote: > >>> > >>> On 24/05/2023 14:49, Adam Ford wrote: > >>>> On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: > >>>>> > >>>>> Hi Adam, > >>>>> > >>>>> On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: > >>>>> > >>>>>> Inki, > >>>>>> > >>>>>> I haven't heard back from you on whether or not you want the bindings > >>>>>> patch to be included with me resending the series as V7 or if you're > >>>>>> OK with a single, stand-alone patch. > >>>>>> Will you let me know? I have the patch standing by waiting for > >>>>>> instructions. If you're not the right person to ask, please let me > >>>>>> know who the right person is. > >>>>> > >>>>> Neil has also been collecting samsung-dsim patches. Maybe he can clarify. > >>>> > >>>> If it matters, my preference all along was to do the bindings as a > >>>> separate thing once the driver updates were merged into the tree. > >>>> Since the bindings can be done in different ways, I was hoping to have > >>>> a separate discussion on the right way to do the bindings. If they > >>>> need to be part of the series, I can do that. > >>> > >>> If you don't introduce compatibles, no need to send bindings, it can > >>> be send separately. > >> > >> This series doesn't change any compatibility. > >> > >>> > >>> Can I apply this serie and 20230503163313.2640898-2-frieder@fris.de ? seems all has been reviewed. > >> > >> Looking at the driver, it looks like linux-next has some newer > >> features added into the driver since I started, so this series might > >> need a re-base. If that's the case, let me know, and I'll do the > >> re-base. > > > > Ok I'll pull the other bits and let you know if this one needs a rebase. > > Indeed, starting at patch 3 it fails to apply, a rebase on drm-misc-next is welcome! I'll do it when I get home tonight and have the next rev. adam > > Neil > > > > > Neil > > > >> > >> adam > >> > >>> > >>> Neil > >>> > >>>> > >>>> adam > >>> > > >
On Thu, May 25, 2023 at 11:19 AM Neil Armstrong <neil.armstrong@linaro.org> wrote: > > On 25/05/2023 18:15, neil.armstrong@linaro.org wrote: > > On 25/05/2023 17:57, Adam Ford wrote: > >> On Thu, May 25, 2023 at 10:39 AM Neil Armstrong > >> <neil.armstrong@linaro.org> wrote: > >>> > >>> On 24/05/2023 14:49, Adam Ford wrote: > >>>> On Wed, May 24, 2023 at 7:45 AM Fabio Estevam <festevam@gmail.com> wrote: > >>>>> > >>>>> Hi Adam, > >>>>> > >>>>> On Tue, May 23, 2023 at 8:49 PM Adam Ford <aford173@gmail.com> wrote: > >>>>> > >>>>>> Inki, > >>>>>> > >>>>>> I haven't heard back from you on whether or not you want the bindings > >>>>>> patch to be included with me resending the series as V7 or if you're > >>>>>> OK with a single, stand-alone patch. > >>>>>> Will you let me know? I have the patch standing by waiting for > >>>>>> instructions. If you're not the right person to ask, please let me > >>>>>> know who the right person is. > >>>>> > >>>>> Neil has also been collecting samsung-dsim patches. Maybe he can clarify. > >>>> > >>>> If it matters, my preference all along was to do the bindings as a > >>>> separate thing once the driver updates were merged into the tree. > >>>> Since the bindings can be done in different ways, I was hoping to have > >>>> a separate discussion on the right way to do the bindings. If they > >>>> need to be part of the series, I can do that. > >>> > >>> If you don't introduce compatibles, no need to send bindings, it can > >>> be send separately. > >> > >> This series doesn't change any compatibility. > >> > >>> > >>> Can I apply this serie and 20230503163313.2640898-2-frieder@fris.de ? seems all has been reviewed. > >> > >> Looking at the driver, it looks like linux-next has some newer > >> features added into the driver since I started, so this series might > >> need a re-base. If that's the case, let me know, and I'll do the > >> re-base. > > > > Ok I'll pull the other bits and let you know if this one needs a rebase. > > Indeed, starting at patch 3 it fails to apply, a rebase on drm-misc-next is welcome! Neil, I rebased and I added the dt-bindings as an additional patch to the series. If people are unhappy with the bindings, I am hoping you can apply the first 6 since they don't seem to break any backwards compatibility, and we can discuss the bindings separately if necessary. adam > > Neil > > > > > Neil > > > >> > >> adam > >> > >>> > >>> Neil > >>> > >>>> > >>>> adam > >>> > > >
Hi, On Thu, 18 May 2023 18:06:20 -0500, Adam Ford wrote: > This series fixes the blanking pack size and the PMS calculation. It then > adds support to allows the DSIM to dynamically DPHY clocks, and support > non-burst mode while allowing the removal of the hard-coded clock values > for the PLL for imx8m mini/nano/plus, and it allows the removal of the > burst-clock device tree entry when burst-mode isn't supported by connected > devices like an HDMI brige. In that event, the HS clock is set to the > value requested by the bridge chip. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/6] drm: bridge: samsung-dsim: fix blanking packet size calculation https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a617b33f7e513f25becf843bc97f8f1658c16337 [2/6] drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=54f1a83c72250b182fa7722b0c5f6eb5e769598d [3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically https://cgit.freedesktop.org/drm/drm-misc/commit/?id=33d8d14c83bf67aa0d262961a6fda9c40f3c1052 [4/6] drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY https://cgit.freedesktop.org/drm/drm-misc/commit/?id=171b3b1e0f8b8c894f2388e1cf765a56f831ee5e [5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing https://cgit.freedesktop.org/drm/drm-misc/commit/?id=89691775f5735fca9dc40e119edcbb52a25b9612 [6/6] drm: bridge: samsung-dsim: Support non-burst mode https://cgit.freedesktop.org/drm/drm-misc/commit/?id=bb0e13b9e223b218c9f242f8d340a332b4381042
Hi, On 26/05/2023 09:22, Neil Armstrong wrote: > Hi, > > On Thu, 18 May 2023 18:06:20 -0500, Adam Ford wrote: >> This series fixes the blanking pack size and the PMS calculation. It then >> adds support to allows the DSIM to dynamically DPHY clocks, and support >> non-burst mode while allowing the removal of the hard-coded clock values >> for the PLL for imx8m mini/nano/plus, and it allows the removal of the >> burst-clock device tree entry when burst-mode isn't supported by connected >> devices like an HDMI brige. In that event, the HS clock is set to the >> value requested by the bridge chip. >> >> [...] > > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) > > [1/6] drm: bridge: samsung-dsim: fix blanking packet size calculation > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a617b33f7e513f25becf843bc97f8f1658c16337 > [2/6] drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=54f1a83c72250b182fa7722b0c5f6eb5e769598d > [3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=33d8d14c83bf67aa0d262961a6fda9c40f3c1052 > [4/6] drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=171b3b1e0f8b8c894f2388e1cf765a56f831ee5e > [5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=89691775f5735fca9dc40e119edcbb52a25b9612 > [6/6] drm: bridge: samsung-dsim: Support non-burst mode > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=bb0e13b9e223b218c9f242f8d340a332b4381042 > Unlike what b4 determined, I applied v8 patches 1-6, I'll wait for comments on the bindings patch. Thanks, Neil
This series fixes the blanking pack size and the PMS calculation. It then adds support to allows the DSIM to dynamically DPHY clocks, and support non-burst mode while allowing the removal of the hard-coded clock values for the PLL for imx8m mini/nano/plus, and it allows the removal of the burst-clock device tree entry when burst-mode isn't supported by connected devices like an HDMI brige. In that event, the HS clock is set to the value requested by the bridge chip. This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should work on i.MX8M Mini as well. Marek Szyprowski has tested it on various Exynos boards. Adam Ford (5): drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY drm: bridge: samsung-dsim: Dynamically configure DPHY timing drm: bridge: samsung-dsim: Support non-burst mode Lucas Stach (1): drm: bridge: samsung-dsim: fix blanking packet size calculation drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/samsung-dsim.c | 142 +++++++++++++++++++++----- include/drm/bridge/samsung-dsim.h | 4 + 3 files changed, 124 insertions(+), 23 deletions(-) V7: Move messages indicating the optional device tree items are going to be automatically read elsewhere was move to dev_dbg instead of dev_info. Cleaned up some of the comments to be a bit more clear. Eliminated a double variable assignement accidentally introduced in V6 when some of the items were moved from patch 6 to patch 5. V6: Squash-in an additional error fix from Lucas Stach regarding the DPHY calcuations. Remove the dynamic_dphy variable and let everyone use the new calculations. Move the hs_clock caching from patch 6 to patch 5 to go along with the DPHY calcuations since they are now based on the recorded hs_clock rate. V5: Update error message to dev_info and change them to indicate what is happening without sounding like an error when optional device tree entries are missing. V4: Undo some accidental whitespace changes, rename PS_TO_CYCLE variables to ps and hz from PS and MHz. Remove if check before the samsung_dsim_set_phy_ctrl call since it's unnecessary. Added additional tested-by and reviewed-by comments. Squash patches 6 and 7 together since the supporting non-burst (patch 6) mode doesn't really work until patch 7 was applied. V3: When checking if the bust-clock is present, only check for it in the device tree, and don't check the presence of the MIPI_DSI_MODE_VIDEO_BURST flag as it breaks an existing Exynos board. Add a new patch to the series to select GENERIC_PHY_MIPI_DPHY in Kconfig otherwise the build breaks on the 32-bit Exynos. Change vco_min variable name to min_freq Added tested-by from Chen-Yu Tsai V2: Instead of using my packet blanking calculation, this integrates on from Lucas Stach which gets modified later in the series to cache the value of the HS-clock instead of having to do the calucations again. Instead of completely eliminating the PLL clock frequency from the device tree, this makes it optional to avoid breaking some Samsung devices. When the samsung,pll-clock-frequency is not found, it reads the value of the clock named "sclk_mipi" This also maintains backwards compatibility with older device trees. This also changes the DPHY calcuation from a Look-up table, a reverse engineered algorithm which uses phy_mipi_dphy_get_default_config to determine the standard nominal values and calculates the cycles necessary to update the DPHY timings accordingly.