Re: [PATCH v9 1/6] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
On 02-04-24, 13:31, Paul Cercueil wrote:
> Hi Vinod,
>
> Le jeudi 28 mars 2024 à 11:53 +0530, Vinod Koul a écrit :
> > On 10-03-24, 13:48, Paul Cercueil wrote:
> > > This function can be used to initiate a scatter-gather DMA
> > > transfer,
> > > where the address and size of each segment is located in one entry
> > > of
> > > the dma_vec array.
> > >
> > > The major difference with dmaengine_prep_slave_sg() is that it
> > > supports
> > > specifying the lengths of each DMA transfer; as trying to override
> > > the
> > > length of the transfer with dmaengine_prep_slave_sg() is a very
> > > tedious
> > > process. The introduction of a new API function is also justified
> > > by the
> > > fact that scatterlists are on their way out.
> > >
> > > Note that dmaengine_prep_interleaved_dma() is not helpful either in
> > > that
> > > case, as it assumes that the address of each segment will be higher
> > > than
> > > the one of the previous segment, which we just cannot guarantee in
> > > case
> > > of a scatter-gather transfer.
> > >
> > > Signed-off-by: Paul Cercueil
> > > Signed-off-by: Nuno Sa
> > >
> > > ---
> > > v3: New patch
> > >
> > > v5: Replace with function dmaengine_prep_slave_dma_vec(), and
> > > struct
> > > 'dma_vec'.
> > > Note that at some point we will need to support cyclic
> > > transfers
> > > using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> > > parameter to the function?
> > >
> > > v7:
> > > - Renamed *device_prep_slave_dma_vec() ->
> > > device_prep_peripheral_dma_vec();
> > > - Added a new flag parameter to the function as agreed between
> > > Paul
> > > and Vinod. I renamed the first parameter to prep_flags as it's
> > > supposed to
> > > be used (I think) with enum dma_ctrl_flags. I'm not really sure
> > > how that API
> > > can grow but I was thinking in just having a bool cyclic
> > > parameter (as the
> > > first intention of the flags is to support cyclic transfers)
> > > but ended up
> > > "respecting" the previously agreed approach.
> > > ---
> > > include/linux/dmaengine.h | 27 +++
> > > 1 file changed, 27 insertions(+)
> > >
> > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > > index 752dbde4cec1..856df8cd9a4e 100644
> > > --- a/include/linux/dmaengine.h
> > > +++ b/include/linux/dmaengine.h
> > > @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> > > struct data_chunk sgl[];
> > > };
> > >
> > > +/**
> > > + * struct dma_vec - DMA vector
> > > + * @addr: Bus address of the start of the vector
> > > + * @len: Length in bytes of the DMA vector
> > > + */
> > > +struct dma_vec {
> > > + dma_addr_t addr;
> > > + size_t len;
> > > +};
> > > +
> > > /**
> > > * enum dma_ctrl_flags - DMA flags to augment operation
> > > preparation,
> > > * control completion, and communicate status.
> > > @@ -910,6 +920,10 @@ struct dma_device {
> > > struct dma_async_tx_descriptor
> > > *(*device_prep_dma_interrupt)(
> > > struct dma_chan *chan, unsigned long flags);
> > >
> > > + struct dma_async_tx_descriptor
> > > *(*device_prep_peripheral_dma_vec)(
> > > + struct dma_chan *chan, const struct dma_vec *vecs,
> > > + size_t nents, enum dma_transfer_direction
> > > direction,
> > > + unsigned long prep_flags, unsigned long flags);
> > > struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> > > struct dma_chan *chan, struct scatterlist *sgl,
> > > unsigned int sg_len, enum dma_transfer_direction
> > > direction,
> > > @@ -973,6 +987,19 @@ static inline struct dma_async_tx_descriptor
> > > *dmaengine_prep_slave_single(
> > > dir, flags,
> > > NULL);
> > > }
> > >
> > > +static inline struct dma_async_tx_descriptor
> > > *dmaengine_prep_peripheral_dma_vec(
> > > + struct dma_chan *chan, const struct dma_vec *vecs, size_t
> > > nents,
> > > + enum dma_transfer_direction dir, unsigned long prep_flags,
&g
Re: [PATCH v15 6/8] phy: freescale: Add DisplayPort/HDMI Combo-PHY driver for i.MX8MQ
On 06-03-24, 11:16, Alexander Stein wrote: > From: Sandor Yu > > Add Cadence HDP-TX DisplayPort and HDMI PHY driver for i.MX8MQ. > > Cadence HDP-TX PHY could be put in either DP mode or > HDMI mode base on the configuration chosen. > DisplayPort or HDMI PHY mode is configured in the driver. > > Signed-off-by: Sandor Yu > Signed-off-by: Alexander Stein > --- > drivers/phy/freescale/Kconfig| 10 + > drivers/phy/freescale/Makefile |1 + > drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c | 1402 ++ > 3 files changed, 1413 insertions(+) > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig > index 853958fb2c063..abacbe8ba8f46 100644 > --- a/drivers/phy/freescale/Kconfig > +++ b/drivers/phy/freescale/Kconfig > @@ -35,6 +35,16 @@ config PHY_FSL_IMX8M_PCIE > Enable this to add support for the PCIE PHY as found on > i.MX8M family of SOCs. > > +config PHY_FSL_IMX8MQ_HDPTX > + tristate "Freescale i.MX8MQ DP/HDMI PHY support" > + depends on OF && HAS_IOMEM > + depends on COMMON_CLK > + select GENERIC_PHY > + select CDNS_MHDP_HELPER > + help > + Enable this to support the Cadence HDPTX DP/HDMI PHY driver > + on i.MX8MQ SOC. > + > endif > > config PHY_FSL_LYNX_28G > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile > index cedb328bc4d28..17546a4da840a 100644 > --- a/drivers/phy/freescale/Makefile > +++ b/drivers/phy/freescale/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0-only > +obj-$(CONFIG_PHY_FSL_IMX8MQ_HDPTX) += phy-fsl-imx8mq-hdptx.o > obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o > obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c > b/drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c > new file mode 100644 > index 0..3bf92718f826a > --- /dev/null > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdptx.c > @@ -0,0 +1,1402 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Cadence DP/HDMI PHY driver > + * > + * Copyright (C) 2022-2024 NXP Semiconductor, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define ADDR_PHY_AFE 0x8 > + > +/* PHY registers */ > +#define CMN_SSM_BIAS_TMR 0x0022 > +#define CMN_PLLSM0_PLLEN_TMR 0x0029 > +#define CMN_PLLSM0_PLLPRE_TMR0x002a > +#define CMN_PLLSM0_PLLVREF_TMR 0x002b > +#define CMN_PLLSM0_PLLLOCK_TMR 0x002c > +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f > +#define CMN_PSM_CLK_CTRL 0x0061 > +#define CMN_CDIAG_REFCLK_CTRL0x0062 > +#define CMN_PLL0_VCOCAL_START0x0081 > +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084 > +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085 > +#define CMN_PLL0_INTDIV 0x0094 > +#define CMN_PLL0_FRACDIV 0x0095 > +#define CMN_PLL0_HIGH_THR0x0096 > +#define CMN_PLL0_DSM_DIAG0x0097 > +#define CMN_PLL0_SS_CTRL20x0099 > +#define CMN_ICAL_INIT_TMR0x00c4 > +#define CMN_ICAL_ITER_TMR0x00c5 > +#define CMN_RXCAL_INIT_TMR 0x00d4 > +#define CMN_RXCAL_ITER_TMR 0x00d5 > +#define CMN_TXPUCAL_CTRL 0x00e0 > +#define CMN_TXPUCAL_INIT_TMR 0x00e4 > +#define CMN_TXPUCAL_ITER_TMR 0x00e5 > +#define CMN_TXPDCAL_CTRL 0x00f0 > +#define CMN_TXPDCAL_INIT_TMR 0x00f4 > +#define CMN_TXPDCAL_ITER_TMR 0x00f5 > +#define CMN_ICAL_ADJ_INIT_TMR0x0102 > +#define CMN_ICAL_ADJ_ITER_TMR0x0103 > +#define CMN_RX_ADJ_INIT_TMR 0x0106 > +#define CMN_RX_ADJ_ITER_TMR 0x0107 > +#define CMN_TXPU_ADJ_CTRL0x0108 > +#define CMN_TXPU_ADJ_INIT_TMR0x010a > +#define CMN_TXPU_ADJ_ITER_TMR0x010b > +#define CMN_TXPD_ADJ_CTRL0x010c > +#define CMN_TXPD_ADJ_INIT_TMR0x010e > +#define CMN_TXPD_ADJ_ITER_TMR0x010f > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 > +#define CMN_DIAG_PLL0_OVRD 0x01c2 > +#define CMN_DIAG_PLL0_TEST_MODE 0x01c4 > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 > +#define CMN_DIAG_PLL0_CP_TUNE0x01c6 > +#define CMN_DIAG_PLL0_LF_PROG0x01c7 > +#define
Re: [PATCH v15 2/8] phy: Add HDMI configuration options
On 06-03-24, 15:48, Maxime Ripard wrote:
> Hi Alexander,
>
> On Wed, Mar 06, 2024 at 11:16:19AM +0100, Alexander Stein wrote:
> > From: Sandor Yu
> >
> > Allow HDMI PHYs to be configured through the generic
> > functions through a custom structure added to the generic union.
> >
> > The parameters added here are based on HDMI PHY
> > implementation practices. The current set of parameters
> > should cover the potential users.
> >
> > Signed-off-by: Sandor Yu
> > Reviewed-by: Dmitry Baryshkov
> > Acked-by: Vinod Koul
> > ---
> > include/linux/phy/phy-hdmi.h | 24
> > include/linux/phy/phy.h | 7 ++-
> > 2 files changed, 30 insertions(+), 1 deletion(-)
> > create mode 100644 include/linux/phy/phy-hdmi.h
> >
> > diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
> > new file mode 100644
> > index 0..b7de88e9090f0
> > --- /dev/null
> > +++ b/include/linux/phy/phy-hdmi.h
> > @@ -0,0 +1,24 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2022 NXP
> > + */
> > +
> > +#ifndef __PHY_HDMI_H_
> > +#define __PHY_HDMI_H_
> > +
> > +#include
> > +/**
> > + * struct phy_configure_opts_hdmi - HDMI configuration set
> > + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> > + * @bpc: Maximum bits per color channel.
> > + * @color_space: Colorspace in enum hdmi_colorspace.
> > + *
> > + * This structure is used to represent the configuration state of a HDMI
> > phy.
> > + */
> > +struct phy_configure_opts_hdmi {
> > + unsigned int pixel_clk_rate;
> > + unsigned int bpc;
> > + enum hdmi_colorspace color_space;
> > +};
>
> Does the PHY actually care about the pixel clock rate, color space and
> formats, or does it only care about the character rate?
Nope it should not
--
~Vinod
Re: [PATCH v9 1/6] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
On 10-03-24, 13:48, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
>
> Note that dmaengine_prep_interleaved_dma() is not helpful either in that
> case, as it assumes that the address of each segment will be higher than
> the one of the previous segment, which we just cannot guarantee in case
> of a scatter-gather transfer.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
>
> ---
> v3: New patch
>
> v5: Replace with function dmaengine_prep_slave_dma_vec(), and struct
> 'dma_vec'.
> Note that at some point we will need to support cyclic transfers
> using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> parameter to the function?
>
> v7:
> - Renamed *device_prep_slave_dma_vec() -> device_prep_peripheral_dma_vec();
> - Added a new flag parameter to the function as agreed between Paul
> and Vinod. I renamed the first parameter to prep_flags as it's supposed to
> be used (I think) with enum dma_ctrl_flags. I'm not really sure how that
> API
> can grow but I was thinking in just having a bool cyclic parameter (as the
> first intention of the flags is to support cyclic transfers) but ended up
> "respecting" the previously agreed approach.
> ---
> include/linux/dmaengine.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 752dbde4cec1..856df8cd9a4e 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> struct data_chunk sgl[];
> };
>
> +/**
> + * struct dma_vec - DMA vector
> + * @addr: Bus address of the start of the vector
> + * @len: Length in bytes of the DMA vector
> + */
> +struct dma_vec {
> + dma_addr_t addr;
> + size_t len;
> +};
> +
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> * control completion, and communicate status.
> @@ -910,6 +920,10 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_peripheral_dma_vec)(
> + struct dma_chan *chan, const struct dma_vec *vecs,
> + size_t nents, enum dma_transfer_direction direction,
> + unsigned long prep_flags, unsigned long flags);
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> @@ -973,6 +987,19 @@ static inline struct dma_async_tx_descriptor
> *dmaengine_prep_slave_single(
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor
> *dmaengine_prep_peripheral_dma_vec(
> + struct dma_chan *chan, const struct dma_vec *vecs, size_t nents,
> + enum dma_transfer_direction dir, unsigned long prep_flags,
> + unsigned long flags)
> +{
> + if (!chan || !chan->device ||
> !chan->device->device_prep_peripheral_dma_vec)
> + return NULL;
> +
> + return chan->device->device_prep_peripheral_dma_vec(chan, vecs, nents,
> + dir, prep_flags,
> + flags);
> +}
API looks good to me, thanks
Few nits though:
- Can we add kernel-doc for this new API please
- Also update the documentation adding this new api
- Lastly, we seem to have two flags, I know you have added a comment but
I dont seem to recall the discussion (looked at old threads for clue
as well), can you please remind me why we need both? And in your case,
what is the intended usage of these flags, i would prefer single
clean one...
--
~Vinod
Re: (subset) [PATCH 0/6] soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote: > Starting with 6.8-rc1 the internal display sometimes fails to come up on > machines like the Lenovo ThinkPad X13s and the logs indicate that this > is due to a regression in the DRM subsystem [1]. > > This series fixes a race in the pmic_glink_altmode driver which was > exposed / triggered by the transparent DRM bridges rework that went into > 6.8-rc1 and that manifested itself as a bridge failing to attach and > sometimes triggering a NULL-pointer dereference. > > [...] Applied, thanks! [5/6] phy: qcom-qmp-combo: fix drm bridge registration commit: d2d7b8e88023b75320662c2305d61779ff060950 [6/6] phy: qcom-qmp-combo: fix type-c switch registration commit: 47b412c1ea77112f1148b4edd71700a388c7c80f Best regards, -- ~Vinod
Re: [PATCH] phy: constify of_phandle_args in xlate
On Sat, 17 Feb 2024 10:39:37 +0100, Krzysztof Kozlowski wrote: > The xlate callbacks are supposed to translate of_phandle_args to proper > provider without modifying the of_phandle_args. Make the argument > pointer to const for code safety and readability. > > Applied, thanks! [1/1] phy: constify of_phandle_args in xlate commit: 00ca8a15dafa990d391abc37f2b8256ddf909b35 Best regards, -- ~Vinod
Re: [PATCH 6/6] phy: qcom-qmp-combo: fix type-c switch registration
On 17-02-24, 16:02, Johan Hovold wrote:
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> Move registration of the typec switch to after looking up clocks and
> other resources.
>
> Note that PHY creation can in theory also trigger a probe deferral when
> a 'phy' supply is used. This does not seem to affect the QMP PHY driver
> but the PHY subsystem should be reworked to address this (i.e. by
> separating initialisation and registration of the PHY).
Acked-by: Vinod Koul
--
~Vinod
Re: [PATCH 5/6] phy: qcom-qmp-combo: fix drm bridge registration
On 17-02-24, 16:02, Johan Hovold wrote:
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> This could potentially also trigger a bug in the DRM bridge
> implementation which does not expect bridges to go away even if device
> links may avoid triggering this (when enabled).
>
> Move registration of the DRM aux bridge to after looking up clocks and
> other resources.
>
> Note that PHY creation can in theory also trigger a probe deferral when
> a 'phy' supply is used. This does not seem to affect the QMP PHY driver
> but the PHY subsystem should be reworked to address this (i.e. by
> separating initialisation and registration of the PHY).
Acked-by: Vinod Koul
--
~Vinod
Re: [PATCH v5 2/2] phy: mtk-mipi-csi: add driver for CSI phy
On Thu, 11 Jan 2024 11:17:30 +0100, Julien Stephan wrote: > This is a new driver that supports the MIPI CSI CD-PHY version 0.5 > > The number of PHYs depend on the SoC. > Each PHY can support D-PHY only or CD-PHY configuration. > The driver supports only D-PHY mode, so CD-PHY > compatible PHY are configured in D-PHY mode. > > [...] Applied, thanks! [2/2] phy: mtk-mipi-csi: add driver for CSI phy commit: 673d70cb3c652ad6d97594e03225bbdf20226216 Best regards, -- ~Vinod
Re: [PATCH v5 0/2] phy: mtk-mipi-csi: add driver for CSI phy
On 11-01-24, 11:14, Julien Stephan wrote: > Adding a new driver for the MIPI CSI CD-PHY module v 0.5 embedded in > some Mediatek soc, such as the MT8365 You would want to fix the way you send patches, the series is disjoint. I had to apply them manually, but please fix your process -- ~Vinod
Re: [PATCH v6 1/6] dmaengine: Add API function dmaengine_prep_slave_dma_vec()
On 29-01-24, 18:01, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
>
> Note that dmaengine_prep_interleaved_dma() is not helpful either in that
> case, as it assumes that the address of each segment will be higher than
> the one of the previous segment, which we just cannot guarantee in case
> of a scatter-gather transfer.
>
> Signed-off-by: Paul Cercueil
>
> ---
> v3: New patch
>
> v5: Replace with function dmaengine_prep_slave_dma_vec(), and struct
> 'dma_vec'.
> Note that at some point we will need to support cyclic transfers
> using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> parameter to the function?
that would be better
> ---
> include/linux/dmaengine.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 3df70d6131c8..ee5931ddb42f 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> struct data_chunk sgl[];
> };
>
> +/**
> + * struct dma_vec - DMA vector
> + * @addr: Bus address of the start of the vector
> + * @len: Length in bytes of the DMA vector
> + */
> +struct dma_vec {
> + dma_addr_t addr;
> + size_t len;
> +};
> +
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> * control completion, and communicate status.
> @@ -910,6 +920,10 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_slave_dma_vec)(
> + struct dma_chan *chan, const struct dma_vec *vecs,
> + size_t nents, enum dma_transfer_direction direction,
> + unsigned long flags);
s/slave/peripheral
I had requested it a bit while ago as well
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> @@ -972,6 +986,17 @@ static inline struct dma_async_tx_descriptor
> *dmaengine_prep_slave_single(
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_dma_vec(
> + struct dma_chan *chan, const struct dma_vec *vecs, size_t nents,
> + enum dma_transfer_direction dir, unsigned long flags)
> +{
> + if (!chan || !chan->device || !chan->device->device_prep_slave_dma_vec)
> + return NULL;
> +
> + return chan->device->device_prep_slave_dma_vec(chan, vecs, nents,
> +dir, flags);
> +}
> +
> static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
> enum dma_transfer_direction dir, unsigned long flags)
> --
> 2.43.0
--
~Vinod
Re: [PATCH V2 2/2] phy: freescale: add Samsung HDMI PHY
Hi Adam,
On 06-01-24, 16:19, Adam Ford wrote:
> From: Lucas Stach
>
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Adam Ford
> ---
> V2: Fixed some whitespace found from checkpatch
> Change error handling when enabling apbclk to use dev_err_probe
> Rebase on Linux-Next
>
> I (Adam) tried to help move this along, so I took Lucas' patch and
> attempted to apply fixes based on feedback. I don't have
> all the history, so apologies for that.
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 853958fb2c06..5c2b73042dfc 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> Enable this to add support for the PCIE PHY as found on
> i.MX8M family of SOCs.
>
> +config PHY_FSL_SAMSUNG_HDMI_PHY
> + tristate "Samsung HDMI PHY support"
> + depends on OF && HAS_IOMEM
> + help
> + Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> +
> endif
>
> config PHY_FSL_LYNX_28G
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index cedb328bc4d2..dbcafdcc8751 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
> obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
> obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
> obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
> obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> new file mode 100644
> index ..54e93ea898f7
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -0,0 +1,1078 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + * Copyright 2022 Pengutronix, Lucas Stach
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define HDMI_TX_CONTROL0 0x200
> +#define HDMI_TX_CONTROL_PHY_PWRDWN BIT(3)
> +
> +#define PHY_REG_33 0x84
> +#define REG33_MODE_SET_DONE BIT(7)
> +#define REG33_FIX_DABIT(1)
> +
> +#define PHY_REG_34 0x88
> +#define REG34_PHY_READY BIT(7)
> +#define REG34_PLL_LOCK BIT(6)
> +#define REG34_PHY_CLK_READY BIT(5)
> +
> +
> +#define PHY_PLL_REGS_NUM 48
> +
> +struct phy_config {
> + u32 clk_rate;
> + u8 regs[PHY_PLL_REGS_NUM];
> +};
> +
> +const struct phy_config phy_pll_cfg[] = {
> + { 2225, {
> + 0x00, 0xD1, 0x4B, 0xF1, 0x89, 0x88, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
can we please have lower case hex values
> + },
> + }, {
> + 2375, {
> + 0x00, 0xD1, 0x50, 0xF1, 0x86, 0x85, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 2400, {
> + 0x00, 0xD1, 0x50, 0xF0, 0x00, 0x00, 0x80, 0x00,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 24024000, {
> + 0x00, 0xD1, 0x50, 0xF1, 0x99, 0x02, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x00, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 25175000, {
> + 0x00, 0xD1, 0x54, 0xFC, 0xCC, 0x91, 0x80, 0x40,
> + 0x4F,
Re: [Linaro-mm-sig] Re: [PATCH v5 3/8] dmaengine: Add API function dmaengine_prep_slave_dma_vec()
Hi Paul,
On 08-01-24, 13:20, Paul Cercueil wrote:
> Hi Vinod,
>
> Le jeudi 21 décembre 2023 à 20:44 +0530, Vinod Koul a écrit :
> > On 19-12-23, 18:50, Paul Cercueil wrote:
> > > This function can be used to initiate a scatter-gather DMA
> > > transfer,
> > > where the address and size of each segment is located in one entry
> > > of
> > > the dma_vec array.
> > >
> > > The major difference with dmaengine_prep_slave_sg() is that it
> > > supports
> > > specifying the lengths of each DMA transfer; as trying to override
> > > the
> > > length of the transfer with dmaengine_prep_slave_sg() is a very
> > > tedious
> > > process. The introduction of a new API function is also justified
> > > by the
> > > fact that scatterlists are on their way out.
> > >
> > > Note that dmaengine_prep_interleaved_dma() is not helpful either in
> > > that
> > > case, as it assumes that the address of each segment will be higher
> > > than
> > > the one of the previous segment, which we just cannot guarantee in
> > > case
> > > of a scatter-gather transfer.
> > >
> > > Signed-off-by: Paul Cercueil
> > >
> > > ---
> > > v3: New patch
> > >
> > > v5: Replace with function dmaengine_prep_slave_dma_vec(), and
> > > struct
> > > 'dma_vec'.
> > > Note that at some point we will need to support cyclic
> > > transfers
> > > using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> > > parameter to the function?
> > > ---
> > > include/linux/dmaengine.h | 25 +
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > > index 3df70d6131c8..ee5931ddb42f 100644
> > > --- a/include/linux/dmaengine.h
> > > +++ b/include/linux/dmaengine.h
> > > @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> > > struct data_chunk sgl[];
> > > };
> > >
> > > +/**
> > > + * struct dma_vec - DMA vector
> > > + * @addr: Bus address of the start of the vector
> > > + * @len: Length in bytes of the DMA vector
> > > + */
> > > +struct dma_vec {
> > > + dma_addr_t addr;
> > > + size_t len;
> > > +};
>
> I don't want to be pushy, but I'd like to know how to solve this now,
> otherwise I'll just send the same patches for my v6.
>
> > so you want to transfer multiple buffers, right? why not use
> > dmaengine_prep_slave_sg(). If there is reason for not using that one?
>
> The reason is that we want to have the possibility to transfer less
> than the total size of the scatterlist, and that's currently very hard
> to do - scatterlists were designed to not be tampered with.
>
> Christian König then suggested to introduce a "dma_vec" which had been
> on his TODO list for a while now.
Yeah for this interleaved seems overkill. Lets go with this api. I would
suggest change the name of the API replacing slave with peripheral
though
--
~Vinod
Re: [PATCH v5 3/8] dmaengine: Add API function dmaengine_prep_slave_dma_vec()
On 19-12-23, 18:50, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
>
> Note that dmaengine_prep_interleaved_dma() is not helpful either in that
> case, as it assumes that the address of each segment will be higher than
> the one of the previous segment, which we just cannot guarantee in case
> of a scatter-gather transfer.
>
> Signed-off-by: Paul Cercueil
>
> ---
> v3: New patch
>
> v5: Replace with function dmaengine_prep_slave_dma_vec(), and struct
> 'dma_vec'.
> Note that at some point we will need to support cyclic transfers
> using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> parameter to the function?
> ---
> include/linux/dmaengine.h | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 3df70d6131c8..ee5931ddb42f 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> struct data_chunk sgl[];
> };
>
> +/**
> + * struct dma_vec - DMA vector
> + * @addr: Bus address of the start of the vector
> + * @len: Length in bytes of the DMA vector
> + */
> +struct dma_vec {
> + dma_addr_t addr;
> + size_t len;
> +};
so you want to transfer multiple buffers, right? why not use
dmaengine_prep_slave_sg(). If there is reason for not using that one?
Furthermore I missed replying to your email earlier on use of
dmaengine_prep_interleaved_dma(), my apologies.
That can be made to work for you as well. Please see the notes where icg
can be ignored and it does not need icg value to be set
Infact, interleaved api can be made to work in most of these cases I can
think of...
> +
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> * control completion, and communicate status.
> @@ -910,6 +920,10 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_slave_dma_vec)(
> + struct dma_chan *chan, const struct dma_vec *vecs,
> + size_t nents, enum dma_transfer_direction direction,
> + unsigned long flags);
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> @@ -972,6 +986,17 @@ static inline struct dma_async_tx_descriptor
> *dmaengine_prep_slave_single(
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_dma_vec(
> + struct dma_chan *chan, const struct dma_vec *vecs, size_t nents,
> + enum dma_transfer_direction dir, unsigned long flags)
> +{
> + if (!chan || !chan->device || !chan->device->device_prep_slave_dma_vec)
> + return NULL;
> +
> + return chan->device->device_prep_slave_dma_vec(chan, vecs, nents,
> +dir, flags);
> +}
> +
> static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
> enum dma_transfer_direction dir, unsigned long flags)
> --
> 2.43.0
--
~Vinod
Re: (subset) [PATCH 0/4] drm/mediatek: support DSI output on MT8195
On Thu, 23 Nov 2023 14:37:45 +0100, Michael Walle wrote: > Add support for a DSI output on VDOSYS0. Luckily, there is a new > feature to support dynamic selections of the output (connector). > Use it to add support for a DSI output. > > Apart from that, this is pretty straghtforward by just adding new > compatibles and add the correct DSI nodes to the SoC dtsi. > > [...] Applied, thanks! [2/4] dt-bindings: phy: add compatible for Mediatek MT8195 commit: fa50920b4f82993941e0aac349eb8081ce11e38f Best regards, -- ~Vinod
Re: (subset) [PATCH v9 00/12] drm/meson: add support for MIPI DSI Display
On Fri, 24 Nov 2023 09:41:11 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Applied, thanks! [03/12] dt-bindings: phy: amlogic,meson-axg-mipi-pcie-analog: drop text about parent syscon and drop example commit: 130601d488fa06447283767e447909ce9e975e43 [04/12] dt-bindings: phy: amlogic,g12a-mipi-dphy-analog: drop unneeded reg property and example commit: 5f4a9a66f8a7582e90311fa8251da33a8d2111d7 Best regards, -- ~Vinod
Re: (subset) [PATCH 00/31] Fix and improve Rockchip RK3128 support
On Tue, 29 Aug 2023 19:16:16 +0200, Alex Bee wrote: > this series fixes some issues I found when testing my "new" RK3128 board > with the mainline kernel and adds some core functionality like SMP bringup, > usb and networking. > > The propably most distinctive change is the split up of the DTs for the > different SoCs of this platform: RK3126 and RK3128. Even if I'm not adding > a RK3126 board in this series: I think this change should be done as early > as possible in order to avoid issues in future. > Actually it should have been done like that in the first place. > > [...] Applied, thanks! [08/31] phy: rockchip-inno-usb2: Split ID interrupt phy registers commit: 2fda59099462ee700e424ba3ac928d13ad6389a8 [09/31] phy: phy-rockchip-inno-usb2: Add RK3128 support commit: 62ff41017e147472b07de6125c3be82ce02a8dd7 Best regards, -- ~Vinod
Re: [PATCH] phy: mediatek: mipi: mt8183: fix minimal supported frequency
On Thu, 23 Nov 2023 12:02:02 +0100, Michael Walle wrote: > The lowest supported clock frequency of the PHY is 125MHz (see also > mtk_mipi_tx_pll_enable()), but the clamping in .round_rate() has the > wrong minimal value, which will make the .enable() op return -EINVAL on > low frequencies. Fix the minimal clamping value. > > Applied, thanks! [1/1] phy: mediatek: mipi: mt8183: fix minimal supported frequency commit: 06f76e464ac81c6915430b7155769ea4ef16efe4 Best regards, -- ~Vinod
Re: [PATCH v8 2/7] phy: Add HDMI configuration options
On 21-09-23, 16:01, Vinod Koul wrote: > On 22-08-23, 20:22, Dmitry Baryshkov wrote: > > On 22/08/2023 16:54, Vinod Koul wrote: > > > On 17-08-23, 13:05, Dmitry Baryshkov wrote: > > >> On 08/08/2023 11:32, Sandor Yu wrote: > > >>> Allow HDMI PHYs to be configured through the generic > > >>> functions through a custom structure added to the generic union. > > >>> > > >>> The parameters added here are based on HDMI PHY > > >>> implementation practices. The current set of parameters > > >>> should cover the potential users. > > >>> > > >>> Signed-off-by: Sandor Yu > > >>> --- > > >>>include/linux/phy/phy-hdmi.h | 24 > > >>>include/linux/phy/phy.h | 7 ++- > > >>>2 files changed, 30 insertions(+), 1 deletion(-) > > >>>create mode 100644 include/linux/phy/phy-hdmi.h > > >> > > >> I think this looks good now, thank you! > > >> > > >> Reviewed-by: Dmitry Baryshkov > > > > > > Should this go thru drm or phy...? > > > > I'd say, PHY, together with the other PHY patches. If you can merge > > them into an immutable branch, then it can also be merged into > > drm-misc (?) to provide the dependency between drm and phy parts. > > phy/topic/hdmi should be pushed out in a bit for that Sorry we need the drm header, so best to merge thru drm tree: Acked-by: Vinod Koul -- ~Vinod
Re: (subset) [PATCH v9 0/7] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
On Thu, 07 Sep 2023 09:05:27 +0800, Sandor Yu wrote: > The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge > drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ. > > The patch set compose of DRM bridge drivers and PHY drivers. > > Both of them need the followed two patches to pass build. > drm: bridge: Cadence: convert mailbox functions to macro functions > phy: Add HDMI configuration options > > [...] Applied, thanks! [2/7] phy: Add HDMI configuration options commit: 7f90516edb5cbfa4108b92bb83cbc8ef35a4cccd [6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ commit: a2717f1d7c64660679441c407b96103abb7c4a8c [7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ commit: 8e36091a94d2d28e8dccb9bfda081b2e42e951ae Best regards, -- ~Vinod
Re: [PATCH v6 0/8] Initial support for Cadence MHDP8501(HDMI/DP) for i.MX8MQ
On Thu, 15 Jun 2023 09:38:10 +0800, Sandor Yu wrote: > The patch set initial support for Cadence MHDP8501(HDMI/DP) DRM bridge > drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ. > > The patch set compose of DRM bridge drivers and PHY drivers. > > Both of them need the followed two patches to pass build. > drm: bridge: Cadence: convert mailbox functions to macro functions > phy: Add HDMI configuration options > > [...] Applied, thanks! [1/8] drm: bridge: Cadence: convert mailbox functions to macro functions (no commit info) [2/8] dt-bindings: display: bridge: Add Cadence MHDP8501 HDMI and DP (no commit info) [3/8] drm: bridge: Cadence: Add MHDP8501 DP driver (no commit info) [4/8] phy: Add HDMI configuration options commit: 7f90516edb5cbfa4108b92bb83cbc8ef35a4cccd [5/8] drm: bridge: Cadence: Add MHDP8501 HDMI driver (no commit info) [6/8] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY (no commit info) [7/8] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ commit: a2717f1d7c64660679441c407b96103abb7c4a8c [8/8] phy: freescale: Add HDMI PHY driver for i.MX8MQ commit: 8e36091a94d2d28e8dccb9bfda081b2e42e951ae Best regards, -- ~Vinod
Re: [PATCH v8 2/7] phy: Add HDMI configuration options
On 22-08-23, 20:22, Dmitry Baryshkov wrote: > On 22/08/2023 16:54, Vinod Koul wrote: > > On 17-08-23, 13:05, Dmitry Baryshkov wrote: > >> On 08/08/2023 11:32, Sandor Yu wrote: > >>> Allow HDMI PHYs to be configured through the generic > >>> functions through a custom structure added to the generic union. > >>> > >>> The parameters added here are based on HDMI PHY > >>> implementation practices. The current set of parameters > >>> should cover the potential users. > >>> > >>> Signed-off-by: Sandor Yu > >>> --- > >>>include/linux/phy/phy-hdmi.h | 24 > >>>include/linux/phy/phy.h | 7 ++- > >>>2 files changed, 30 insertions(+), 1 deletion(-) > >>>create mode 100644 include/linux/phy/phy-hdmi.h > >> > >> I think this looks good now, thank you! > >> > >> Reviewed-by: Dmitry Baryshkov > > > > Should this go thru drm or phy...? > > I'd say, PHY, together with the other PHY patches. If you can merge > them into an immutable branch, then it can also be merged into > drm-misc (?) to provide the dependency between drm and phy parts. phy/topic/hdmi should be pushed out in a bit for that -- ~Vinod
Re: [PATCH 08/31] phy: rockchip-inno-usb2: Split ID interrupt phy registers
On 29-08-23, 19:16, Alex Bee wrote:
> Commit 51a9b2c03dd3 ("phy: rockchip-inno-usb2: Handle ID IRQ") added ID
> detection interrupt registers. However the current implementation assumes
> that falling and rising edge interrupt are always enabled in registers
> spaning over subsequent bits.
> That is not the case for RK312x's version of the phy and this
> implementation can't be used as-is, since there are bits with different
> purpose in between.
>
> This splits up the register definitions for id_det_en, id_det_en and
> id_det_clr registers in rising and falling edge variants.
> It's required as preparation to support RK312x's Innosilicon usb2 phy as
> well in this driver and matches pretty much to what the vendor does, so I'm
> not expecting issues for other SoCs with that change.
This fails to apply for phy/next
--
~Vinod
Re: [PATCH v8 2/7] phy: Add HDMI configuration options
On 17-08-23, 13:05, Dmitry Baryshkov wrote: > On 08/08/2023 11:32, Sandor Yu wrote: > > Allow HDMI PHYs to be configured through the generic > > functions through a custom structure added to the generic union. > > > > The parameters added here are based on HDMI PHY > > implementation practices. The current set of parameters > > should cover the potential users. > > > > Signed-off-by: Sandor Yu > > --- > > include/linux/phy/phy-hdmi.h | 24 > > include/linux/phy/phy.h | 7 ++- > > 2 files changed, 30 insertions(+), 1 deletion(-) > > create mode 100644 include/linux/phy/phy-hdmi.h > > I think this looks good now, thank you! > > Reviewed-by: Dmitry Baryshkov Should this go thru drm or phy...? > > -- > With best wishes > Dmitry -- ~Vinod
Re: [PATCH v4 2/3] phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE
On 17-08-23, 17:55, Dmitry Baryshkov wrote: > Switch to using the new DRM_AUX_BRIDGE helper to create the > transparent DRM bridge device instead of handcoding corresponding > functionality. Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH v7 6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
On 17-07-23, 16:03, Sandor Yu wrote: > Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ > > Cadence HDP-TX PHY could be put in either DP mode or > HDMI mode base on the configuration chosen. > DisplayPort PHY mode is configurated in the driver. > > Signed-off-by: Sandor Yu > --- > drivers/phy/freescale/Kconfig | 9 + > drivers/phy/freescale/Makefile| 1 + > drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 698 ++ > 3 files changed, 708 insertions(+) > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig > index 853958fb2c06..2999ba1e57d0 100644 > --- a/drivers/phy/freescale/Kconfig > +++ b/drivers/phy/freescale/Kconfig > @@ -35,6 +35,15 @@ config PHY_FSL_IMX8M_PCIE > Enable this to add support for the PCIE PHY as found on > i.MX8M family of SOCs. > > +config PHY_FSL_IMX8MQ_DP_PHY > + tristate "Freescale i.MX8MQ DP PHY support" > + depends on OF && HAS_IOMEM > + depends on COMMON_CLK > + select GENERIC_PHY > + help > + Enable this to support the Cadence HDPTX DP PHY driver > + on i.MX8MQ SOC. > + > endif > > config PHY_FSL_LYNX_28G > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile > index cedb328bc4d2..915a429d9fbc 100644 > --- a/drivers/phy/freescale/Makefile > +++ b/drivers/phy/freescale/Makefile > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += > phy-fsl-imx8qm-lvds-phy.o > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o > +obj-$(CONFIG_PHY_FSL_IMX8MQ_DP_PHY) += phy-fsl-imx8mq-dp.o > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > new file mode 100644 > index ..415273ac6aa5 > --- /dev/null > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > @@ -0,0 +1,698 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Cadence HDP-TX Display Port Interface (DP) PHY driver > + * > + * Copyright (C) 2022 NXP Semiconductor, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define ADDR_PHY_AFE 0x8 > + > +/* PHY registers */ > +#define CMN_SSM_BIAS_TMR0x0022 > +#define CMN_PLLSM0_PLLEN_TMR0x0029 > +#define CMN_PLLSM0_PLLPRE_TMR 0x002a > +#define CMN_PLLSM0_PLLVREF_TMR 0x002b > +#define CMN_PLLSM0_PLLLOCK_TMR 0x002c > +#define CMN_PLLSM0_USER_DEF_CTRL0x002f > +#define CMN_PSM_CLK_CTRL0x0061 > +#define CMN_PLL0_VCOCAL_START 0x0081 > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > +#define CMN_PLL0_INTDIV 0x0094 > +#define CMN_PLL0_FRACDIV0x0095 > +#define CMN_PLL0_HIGH_THR 0x0096 > +#define CMN_PLL0_DSM_DIAG 0x0097 > +#define CMN_PLL0_SS_CTRL2 0x0099 > +#define CMN_ICAL_INIT_TMR 0x00c4 > +#define CMN_ICAL_ITER_TMR 0x00c5 > +#define CMN_RXCAL_INIT_TMR 0x00d4 > +#define CMN_RXCAL_ITER_TMR 0x00d5 > +#define CMN_TXPUCAL_INIT_TMR0x00e4 > +#define CMN_TXPUCAL_ITER_TMR0x00e5 > +#define CMN_TXPDCAL_INIT_TMR0x00f4 > +#define CMN_TXPDCAL_ITER_TMR0x00f5 > +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 > +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 > +#define CMN_RX_ADJ_INIT_TMR 0x0106 > +#define CMN_RX_ADJ_ITER_TMR 0x0107 > +#define CMN_TXPU_ADJ_INIT_TMR 0x010a > +#define CMN_TXPU_ADJ_ITER_TMR 0x010b > +#define CMN_TXPD_ADJ_INIT_TMR 0x010e > +#define CMN_TXPD_ADJ_ITER_TMR 0x010f > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 > +#define CMN_DIAG_PLL0_OVRD 0x01c2 > +#define CMN_DIAG_PLL0_TEST_MODE 0x01c4 > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 > +#define CMN_DIAG_PLL0_CP_TUNE 0x01c6 > +#define CMN_DIAG_PLL0_LF_PROG 0x01c7 > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8 > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9 > +#define CMN_DIAG_HSCLK_SEL 0x01e0 > +#define CMN_DIAG_PER_CAL_ADJ0x01ec > +#define CMN_DIAG_CAL_CTRL 0x01ed > +#define CMN_DIAG_ACYA 0x01ff > +#define XCVR_PSM_RCTRL 0x4001 > +#define XCVR_PSM_CAL_TMR0x4002 > +#define XCVR_PSM_A0IN_TMR 0x4003 > +#define TX_TXCC_CAL_SCLR_MULT_0 0x4047 > +#define TX_TXCC_CPOST_MULT_00_0 0x404c > +#define XCVR_DIAG_PLLDRC_CTRL 0x40e0 > +#define XCVR_DIAG_PLLDRC_CTRL 0x40e0 > +#define XCVR_DIAG_HSCLK_SEL 0x40e1 > +#define
Re: [PATCH] phy: Explicitly include correct DT includes
On Fri, 14 Jul 2023 11:48:35 -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > [...] Applied, thanks! [1/1] phy: Explicitly include correct DT includes commit: 7559e7572c03e433efec7734af6a674fdd83dd68 Best regards, -- ~Vinod
Re: [PATCH v4 2/2] phy: mtk-mipi-csi: add driver for CSI phy
On 20-06-23, 14:18, Julien Stephan wrote: > From: Phi-bang Nguyen > > This is a new driver that supports the MIPI CSI CD-PHY version 0.5 > > The number of PHYs depend on the SoC. > Each PHY can support D-PHY only or CD-PHY configuration. > The driver supports only D-PHY mode, so CD-PHY > compatible PHY are configured in D-PHY mode. > > Signed-off-by: Louis Kuo > Signed-off-by: Phi-bang Nguyen > [Julien Stephan: refactor code] > [Julien Stephan: simplify driver model: one instance per phy vs one instance > for all phys] > Co-developed-by: Julien Stephan > Signed-off-by: Julien Stephan > --- > MAINTAINERS | 1 + > drivers/phy/mediatek/Kconfig | 12 + > drivers/phy/mediatek/Makefile | 2 + > .../mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h| 62 > drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c | 343 ++ > 5 files changed, 420 insertions(+) > create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h > create mode 100644 drivers/phy/mediatek/phy-mtk-mipi-csi-0-5.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 024d67eb7a94..4d9b6c9f6662 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -13189,6 +13189,7 @@ M:Julien Stephan > M: Andy Hsieh > S: Supported > F: Documentation/devicetree/bindings/phy/mediatek,mt8365-csi-rx.yaml > +F: drivers/phy/mediatek/phy-mtk-mipi-csi-0-5* > > MEDIATEK MMC/SD/SDIO DRIVER > M: Chaotian Jing > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig > index 3125ecb5d119..7088382ebc9e 100644 > --- a/drivers/phy/mediatek/Kconfig > +++ b/drivers/phy/mediatek/Kconfig > @@ -74,3 +74,15 @@ config PHY_MTK_DP > select GENERIC_PHY > help > Support DisplayPort PHY for MediaTek SoCs. > + > +config PHY_MTK_MIPI_CSI_0_5 Keep this sorted alphabetically pls > + tristate "MediaTek MIPI CSI CD-PHY v0.5 Driver" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + depends on OF > + select GENERIC_PHY > + help > + Enable this to support the MIPI CSI CD-PHY receiver version 0.5. > + The driver supports multiple CSI cdphy ports simultaneously. > + > + To compile this driver as a module, choose M here: the > + module will be called phy-mtk-mipi-csi-0-5. > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile > index c9a50395533e..63f2fa3ec7e5 100644 > --- a/drivers/phy/mediatek/Makefile > +++ b/drivers/phy/mediatek/Makefile > @@ -19,3 +19,5 @@ phy-mtk-mipi-dsi-drv-y := > phy-mtk-mipi-dsi.o > phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8173.o > phy-mtk-mipi-dsi-drv-y += phy-mtk-mipi-dsi-mt8183.o > obj-$(CONFIG_PHY_MTK_MIPI_DSI) += phy-mtk-mipi-dsi-drv.o > + > +obj-$(CONFIG_PHY_MTK_MIPI_CSI_0_5) += phy-mtk-mipi-csi-0-5.o This one too and no need of empty line > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h > b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h > new file mode 100644 > index ..97b4c27a1699 > --- /dev/null > +++ b/drivers/phy/mediatek/phy-mtk-mipi-csi-0-5-rx-reg.h > @@ -0,0 +1,62 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2023, MediaTek Inc. > + * Copyright (c) 2023, BayLibre Inc. > + */ > + > +#ifndef __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__ > +#define __PHY_MTK_MIPI_CSI_V_0_5_RX_REG_H__ > + > +/* > + * CSI1 and CSI2 are identical, and similar to CSI0. All CSIX macros are > + * applicable to the three PHYs. Where differences exist, they are denoted by > + * macro names using CSI0 and CSI1, the latter being applicable to CSI1 and > + * CSI2 alike. > + */ > + > +#define MIPI_RX_ANA00_CSIXA 0x > +#define RG_CSI0A_CPHY_EN BIT(0) > +#define RG_CSIXA_EQ_PROTECT_EN BIT(1) > +#define RG_CSIXA_BG_LPF_EN BIT(2) > +#define RG_CSIXA_BG_CORE_EN BIT(3) > +#define RG_CSIXA_DPHY_L0_CKMODE_EN BIT(5) > +#define RG_CSIXA_DPHY_L0_CKSEL BIT(6) > +#define RG_CSIXA_DPHY_L1_CKMODE_EN BIT(8) > +#define RG_CSIXA_DPHY_L1_CKSEL BIT(9) > +#define RG_CSIXA_DPHY_L2_CKMODE_EN BIT(11) > +#define RG_CSIXA_DPHY_L2_CKSEL BIT(12) > + > +#define MIPI_RX_ANA18_CSIXA 0x0018 > +#define RG_CSI0A_L0_T0AB_EQ_IS GENMASK(5, 4) > +#define RG_CSI0A_L0_T0AB_EQ_BW GENMASK(7, 6) > +#define RG_CSI0A_L1_T1AB_EQ_IS GENMASK(21, 20) > +#define RG_CSI0A_L1_T1AB_EQ_BW GENMASK(23, 22) > +#define RG_CSI0A_L2_T1BC_EQ_IS GENMASK(21, 20) > +#define RG_CSI0A_L2_T1BC_EQ_BW GENMASK(23, 22) > +#define RG_CSI1A_L0_EQ_ISGENMASK(5, 4) > +#define RG_CSI1A_L0_EQ_BWGENMASK(7, 6) > +#define RG_CSI1A_L1_EQ_IS
Re: [PATCH 0/3] MediaTek MIPI-DSI PHY: Cleanups
On Thu, 25 May 2023 13:52:55 +0200, AngeloGioacchino Del Regno wrote: > This series performs some cleanups to the MediaTek mipi-dsi PHY, used in > various MediaTek SoCs; in particular, it's migrating this driver to > register its clock as clk_hw provider instead and makes use of the devm > function for the same, allowing to remove a pointer to struct clk and > the whole .remove_new() callback, as it's not needed anymore. > This also cleans up the of_device_id table. > > [...] Applied, thanks! [1/3] phy: mediatek: mipi-dsi: Convert to register clk_hw commit: b1a34e7d196646a8fc0a6f91c2bf98943f3d440a [2/3] phy: mediatek: mipi-dsi: Use devm variant for of_clk_add_hw_provider() commit: e812c5b62a978ae67d23c5eb237959596734a86e [3/3] phy: mediatek: mipi-dsi: Compress of_device_id match entries commit: 5d295c1a20c747425c27dd9212ff091528136e55 Best regards, -- ~Vinod
Re: [PATCH] phy: mediatek: hdmi: mt8195: fix prediv bad upper limit test
On Tue, 30 May 2023 10:43:07 +0200, Guillaume Ranquet wrote: > The pll prediv calculus searchs for the smallest prediv that gets > the ns_hdmipll_ck in the range of 5 GHz to 12 GHz. > > A typo in the upper bound test was testing for 5Ghz to 1Ghz > > Applied, thanks! [1/1] phy: mediatek: hdmi: mt8195: fix prediv bad upper limit test commit: 059c78ebf1e94a825e27cc3ef8a9d77cef06827e Best regards, -- ~Vinod
Re: [PATCH] phy: phy-mtk-dp: Fix an error code in probe()
On Tue, 11 Jul 2023 09:13:25 +0300, Dan Carpenter wrote: > Negative -EINVAL was intended instead of positive EINVAL. > > Applied, thanks! [1/1] phy: phy-mtk-dp: Fix an error code in probe() commit: 03966c3950d36d6b671158be3794eb7211434faa Best regards, -- ~Vinod
Re: [PATCH 02/15] phy: qualcomm: add QMP HDMI PHY driver
On 23-05-23, 15:14, Dmitry Baryshkov wrote:
> Port Qualcomm QMP HDMI PHY to the generic PHY framework. Split the
> generic part and the msm8996 part. When adding support for msm8992/4 and
> msm8998 (which also employ QMP for HDMI PHY), one will have to provide
> the PLL programming part only.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/phy/qualcomm/Kconfig | 7 +
> drivers/phy/qualcomm/Makefile | 5 +
> drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 184
> .../phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 441 ++
> drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 75 +++
> 5 files changed, 712 insertions(+)
> create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
> create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c
> create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h
>
> diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
> index 4850d48f31fa..94fb5679df4a 100644
> --- a/drivers/phy/qualcomm/Kconfig
> +++ b/drivers/phy/qualcomm/Kconfig
> @@ -65,6 +65,13 @@ config PHY_QCOM_QMP_COMBO
> Enable this to support the QMP Combo PHY transceiver that is used
> with USB3 and DisplayPort controllers on Qualcomm chips.
>
> +config PHY_QCOM_QMP_HDMI
> + tristate "Qualcomm QMP HDMI PHY Driver"
> + default PHY_QCOM_QMP && DRM_MSM_HDMI
> + help
> + Enable this to support the QMP HDMI PHY transceiver that is used
> + with HDMI output on Qualcomm MSM8996 chips.
> +
> config PHY_QCOM_QMP_PCIE
> tristate "Qualcomm QMP PCIe PHY Driver"
> depends on PCI || COMPILE_TEST
> diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
> index de3dc9ccf067..b877d86ea0b1 100644
> --- a/drivers/phy/qualcomm/Makefile
> +++ b/drivers/phy/qualcomm/Makefile
> @@ -6,7 +6,12 @@ obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) +=
> phy-qcom-ipq4019-usb.o
> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o
>
> +phy-qcom-qmp-hdmi-y := \
> + phy-qcom-qmp-hdmi-base.o \
> + phy-qcom-qmp-hdmi-msm8996.o \
> +
> obj-$(CONFIG_PHY_QCOM_QMP_COMBO) += phy-qcom-qmp-combo.o
> +obj-$(CONFIG_PHY_QCOM_QMP_HDMI) += phy-qcom-qmp-hdmi.o
> obj-$(CONFIG_PHY_QCOM_QMP_PCIE) += phy-qcom-qmp-pcie.o
> obj-$(CONFIG_PHY_QCOM_QMP_PCIE_8996) += phy-qcom-qmp-pcie-msm8996.o
> obj-$(CONFIG_PHY_QCOM_QMP_UFS) += phy-qcom-qmp-ufs.o
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
> b/drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
> new file mode 100644
> index ..08132b3f82af
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Linaro Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "phy-qcom-qmp-hdmi.h"
> +
> +int qmp_hdmi_phy_init(struct phy *phy)
> +{
> + struct qmp_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
> +
> + return pm_runtime_resume_and_get(hdmi_phy->dev);
> +}
> +
> +int qmp_hdmi_phy_configure(struct phy *phy, union phy_configure_opts *opts)
> +{
> +const struct phy_configure_opts_hdmi *hdmi_opts = >hdmi;
> + struct qmp_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
wrong alignment
> +int ret = 0;
> +
> +memcpy(_phy->hdmi_opts, hdmi_opts, sizeof(*hdmi_opts));
> +
> +return ret;
drop ret, and return 0 here?
> +}
> +
> +int qmp_hdmi_phy_exit(struct phy *phy)
> +{
> + struct qmp_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
> +
> + pm_runtime_put_noidle(hdmi_phy->dev);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused qmp_hdmi_runtime_resume(struct device *dev)
> +{
> + struct qmp_hdmi_phy *hdmi_phy = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(hdmi_phy->supplies),
> hdmi_phy->supplies);
> + if (ret)
> + return ret;
> +
> + ret = clk_bulk_prepare_enable(ARRAY_SIZE(hdmi_phy->clks),
> hdmi_phy->clks);
> + if (ret)
> + goto out_disable_supplies;
> +
> + return 0;
> +
> +out_disable_supplies:
> + regulator_bulk_disable(ARRAY_SIZE(hdmi_phy->supplies),
> hdmi_phy->supplies);
> +
> + return ret;
> +}
> +
> +static int __maybe_unused qmp_hdmi_runtime_suspend(struct device *dev)
> +{
> + struct qmp_hdmi_phy *hdmi_phy = dev_get_drvdata(dev);
> +
> + clk_bulk_disable_unprepare(ARRAY_SIZE(hdmi_phy->clks), hdmi_phy->clks);
> + regulator_bulk_disable(ARRAY_SIZE(hdmi_phy->supplies),
> hdmi_phy->supplies);
> +
> + return 0;
> +}
> +
> +static int qmp_hdmi_probe(struct platform_device *pdev)
> +{
> + struct clk_init_data init = {
> + .name = "hdmipll",
> + .parent_data = (const struct clk_parent_data[]) {
> + { .fw_name =
Re: [PATCH] dt-bindings: cleanup DTS example whitespaces
On 02-07-23, 20:23, Krzysztof Kozlowski wrote: > The DTS code coding style expects spaces around '=' sign. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Rob, > > Maybe this could go via your tree? Rebased on your for-next: > v6.4-rc2-45-gf0ac35049606 > --- > .../bindings/arm/arm,coresight-cti.yaml| 18 +- > .../bindings/arm/keystone/ti,sci.yaml | 8 > .../devicetree/bindings/display/msm/gmu.yaml | 2 +- > .../display/panel/samsung,s6e8aa0.yaml | 2 +- > .../display/rockchip/rockchip-vop.yaml | 4 ++-- > .../bindings/iio/adc/ti,adc108s102.yaml| 2 +- > .../bindings/media/renesas,rzg2l-cru.yaml | 4 ++-- > .../devicetree/bindings/media/renesas,vin.yaml | 4 ++-- > .../devicetree/bindings/mtd/mtd-physmap.yaml | 2 +- > .../bindings/net/mediatek-dwmac.yaml | 2 +- > .../bindings/perf/amlogic,g12-ddr-pmu.yaml | 4 ++-- > .../bindings/phy/mediatek,dsi-phy.yaml | 2 +- Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH v6 8/8] phy: freescale: Add HDMI PHY driver for i.MX8MQ
On 15-06-23, 09:38, Sandor Yu wrote: > Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ. > > Cadence HDP-TX PHY could be put in either DP mode or > HDMI mode base on the configuration chosen. > HDMI PHY mode is configurated in the driver. > > Signed-off-by: Sandor Yu > --- > drivers/phy/freescale/Kconfig | 9 + > drivers/phy/freescale/Makefile | 1 + > drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 889 > 3 files changed, 899 insertions(+) > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig > index a99ee370eda6..e007e15e503a 100644 > --- a/drivers/phy/freescale/Kconfig > +++ b/drivers/phy/freescale/Kconfig > @@ -44,6 +44,15 @@ config PHY_CADENCE_DP_PHY > Enable this to support the Cadence HDPTX DP PHY driver > on NXP's i.MX8MQ SOC. > > +config PHY_CADENCE_HDMI_PHY > + tristate "Cadence HDPTX HDMI PHY Driver" > + depends on OF && HAS_IOMEM > + depends on COMMON_CLK > + select GENERIC_PHY > + help > + Enable this to support the Cadence HDPTX HDMI PHY driver. > + on NXP's i.MX8MQ SOC. > + > endif > > config PHY_FSL_LYNX_28G > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile > index c3bdf3fa2e72..d25fafd91c53 100644 > --- a/drivers/phy/freescale/Makefile > +++ b/drivers/phy/freescale/Makefile > @@ -5,3 +5,4 @@ obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += > phy-fsl-imx8-mipi-dphy.o > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o > obj-$(CONFIG_PHY_CADENCE_DP_PHY) += phy-fsl-imx8mq-dp.o > +obj-$(CONFIG_PHY_CADENCE_HDMI_PHY) += phy-fsl-imx8mq-hdmi.o Pls sort alphabetically (both Kconfig and Makefile) > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > new file mode 100644 > index ..65aeb9835bb9 > --- /dev/null > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c > @@ -0,0 +1,889 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Cadence High-Definition Multimedia Interface (HDMI) PHY driver > + * > + * Copyright (C) 2022 NXP Semiconductor, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define ADDR_PHY_AFE 0x8 > +/* PHY registers */ > +#define CMN_SSM_BIAS_TMR0x0022 > +#define CMN_PLLSM0_USER_DEF_CTRL0x002F > +#define CMN_PSM_CLK_CTRL0x0061 > +#define CMN_CDIAG_REFCLK_CTRL 0x0062 > +#define CMN_PLL0_VCOCAL_START 0x0081 > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > +#define CMN_TXPUCAL_CTRL0x00E0 > +#define CMN_TXPDCAL_CTRL0x00F0 > +#define CMN_TXPU_ADJ_CTRL 0x0108 > +#define CMN_TXPD_ADJ_CTRL 0x010c > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01C0 > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01C1 > +#define CMN_DIAG_PLL0_OVRD 0x01C2 > +#define CMN_DIAG_PLL0_TEST_MODE 0x01C4 > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01C5 > +#define CMN_DIAG_PLL0_CP_TUNE 0x01C6 > +#define CMN_DIAG_PLL0_LF_PROG 0x01C7 > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01C8 > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01C9 > +#define CMN_DIAG_PLL0_INCLK_CTRL0x01CA > +#define CMN_DIAG_PLL0_PXL_DIVH 0x01CB > +#define CMN_DIAG_PLL0_PXL_DIVL 0x01CC > +#define CMN_DIAG_HSCLK_SEL 0x01E0 > +#define XCVR_PSM_RCTRL 0x4001 > +#define TX_TXCC_CAL_SCLR_MULT_0 0x4047 > +#define TX_TXCC_CPOST_MULT_00_0 0x404C > +#define XCVR_DIAG_PLLDRC_CTRL 0x40E0 > +#define XCVR_DIAG_PLLDRC_CTRL 0x40E0 > +#define XCVR_DIAG_HSCLK_SEL 0x40E1 > +#define XCVR_DIAG_BIDI_CTRL 0x40E8 > +#define TX_PSC_A0 0x4100 > +#define TX_PSC_A1 0x4101 > +#define TX_PSC_A2 0x4102 > +#define TX_PSC_A3 0x4103 > +#define TX_DIAG_TX_CTRL 0x41E0 > +#define TX_DIAG_TX_DRV 0x41E1 > +#define TX_DIAG_BGREF_PREDRV_DELAY 0x41E7 > +#define TX_DIAG_ACYA_0 0x41FF > +#define TX_DIAG_ACYA_1 0x43FF > +#define TX_DIAG_ACYA_2 0x45FF > +#define TX_DIAG_ACYA_3 0x47FF > +#define TX_ANA_CTRL_REG_1 0x5020 > +#define TX_ANA_CTRL_REG_2 0x5021 > +#define TX_DIG_CTRL_REG_2 0x5024 > +#define TXDA_CYA_AUXDA_CYA 0x5025 > +#define TX_ANA_CTRL_REG_3 0x5026 > +#define TX_ANA_CTRL_REG_4 0x5027 > +#define TX_ANA_CTRL_REG_5 0x5029 > +#define RX_PSC_A0 0x8000 > +#define RX_PSC_CAL 0x8006 > +#define
Re: [PATCH v6 7/8] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
On 15-06-23, 09:38, Sandor Yu wrote: > Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ > > Cadence HDP-TX PHY could be put in either DP mode or > HDMI mode base on the configuration chosen. > DisplayPort PHY mode is configurated in the driver. > > Signed-off-by: Sandor Yu > --- > drivers/phy/freescale/Kconfig | 9 + > drivers/phy/freescale/Makefile| 1 + > drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 697 ++ > 3 files changed, 707 insertions(+) > create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig > index 853958fb2c06..a99ee370eda6 100644 > --- a/drivers/phy/freescale/Kconfig > +++ b/drivers/phy/freescale/Kconfig > @@ -35,6 +35,15 @@ config PHY_FSL_IMX8M_PCIE > Enable this to add support for the PCIE PHY as found on > i.MX8M family of SOCs. > > +config PHY_CADENCE_DP_PHY > + tristate "Cadence HDPTX DP PHY support" > + depends on OF && HAS_IOMEM > + depends on COMMON_CLK > + select GENERIC_PHY > + help > + Enable this to support the Cadence HDPTX DP PHY driver > + on NXP's i.MX8MQ SOC. > + > endif > > config PHY_FSL_LYNX_28G > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile > index cedb328bc4d2..c3bdf3fa2e72 100644 > --- a/drivers/phy/freescale/Makefile > +++ b/drivers/phy/freescale/Makefile > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += > phy-fsl-imx8qm-lvds-phy.o > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o > +obj-$(CONFIG_PHY_CADENCE_DP_PHY) += phy-fsl-imx8mq-dp.o > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > new file mode 100644 > index ..2bd6772a5d3b > --- /dev/null > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c > @@ -0,0 +1,697 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Cadence HDP-TX Display Port Interface (DP) PHY driver > + * > + * Copyright (C) 2022 NXP Semiconductor, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define ADDR_PHY_AFE 0x8 Is this always fixed for every phy generation? > + > +/* PHY registers */ > +#define CMN_SSM_BIAS_TMR0x0022 > +#define CMN_PLLSM0_PLLEN_TMR0x0029 > +#define CMN_PLLSM0_PLLPRE_TMR 0x002A > +#define CMN_PLLSM0_PLLVREF_TMR 0x002B > +#define CMN_PLLSM0_PLLLOCK_TMR 0x002C > +#define CMN_PLLSM0_USER_DEF_CTRL0x002F > +#define CMN_PSM_CLK_CTRL0x0061 > +#define CMN_PLL0_VCOCAL_START 0x0081 > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > +#define CMN_PLL0_INTDIV 0x0094 > +#define CMN_PLL0_FRACDIV0x0095 > +#define CMN_PLL0_HIGH_THR 0x0096 > +#define CMN_PLL0_DSM_DIAG 0x0097 > +#define CMN_PLL0_SS_CTRL2 0x0099 > +#define CMN_ICAL_INIT_TMR 0x00C4 > +#define CMN_ICAL_ITER_TMR 0x00C5 > +#define CMN_RXCAL_INIT_TMR 0x00D4 > +#define CMN_RXCAL_ITER_TMR 0x00D5 > +#define CMN_TXPUCAL_INIT_TMR0x00E4 > +#define CMN_TXPUCAL_ITER_TMR0x00E5 > +#define CMN_TXPDCAL_INIT_TMR0x00F4 > +#define CMN_TXPDCAL_ITER_TMR0x00F5 > +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 > +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 > +#define CMN_RX_ADJ_INIT_TMR 0x0106 > +#define CMN_RX_ADJ_ITER_TMR 0x0107 > +#define CMN_TXPU_ADJ_INIT_TMR 0x010A > +#define CMN_TXPU_ADJ_ITER_TMR 0x010B > +#define CMN_TXPD_ADJ_INIT_TMR 0x010E > +#define CMN_TXPD_ADJ_ITER_TMR 0x010F > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01C0 > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01C1 > +#define CMN_DIAG_PLL0_OVRD 0x01C2 > +#define CMN_DIAG_PLL0_TEST_MODE 0x01C4 > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01C5 > +#define CMN_DIAG_PLL0_CP_TUNE 0x01C6 > +#define CMN_DIAG_PLL0_LF_PROG 0x01C7 > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01C8 > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01C9 > +#define CMN_DIAG_HSCLK_SEL 0x01E0 > +#define CMN_DIAG_PER_CAL_ADJ0x01EC > +#define CMN_DIAG_CAL_CTRL 0x01ED > +#define CMN_DIAG_ACYA 0x01FF > +#define XCVR_PSM_RCTRL 0x4001 > +#define XCVR_PSM_CAL_TMR0x4002 > +#define XCVR_PSM_A0IN_TMR 0x4003 > +#define TX_TXCC_CAL_SCLR_MULT_0 0x4047 > +#define TX_TXCC_CPOST_MULT_00_0 0x404C > +#define XCVR_DIAG_PLLDRC_CTRL 0x40E0 > +#define XCVR_DIAG_PLLDRC_CTRL 0x40E0 > +#define
Re: [PATCH v6 4/8] phy: Add HDMI configuration options
On 15-06-23, 09:38, Sandor Yu wrote:
> Allow HDMI PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
>
> The parameters added here are based on HDMI PHY
> implementation practices. The current set of parameters
> should cover the potential users.
>
> Signed-off-by: Sandor Yu
> ---
> include/linux/phy/phy-hdmi.h | 38
> include/linux/phy/phy.h | 7 ++-
> 2 files changed, 44 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/phy/phy-hdmi.h
>
> diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
> new file mode 100644
> index ..5765aa5bc175
> --- /dev/null
> +++ b/include/linux/phy/phy-hdmi.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2022 NXP
> + */
> +
> +#ifndef __PHY_HDMI_H_
> +#define __PHY_HDMI_H_
> +
> +/**
> + * Pixel Encoding as HDMI Specification
> + * RGB, YUV422, YUV444:HDMI Specification 1.4a Section 6.5
> + * YUV420: HDMI Specification 2.a Section 7.1
> + */
> +enum hdmi_phy_colorspace {
> + HDMI_PHY_COLORSPACE_RGB,/* RGB 4:4:4 */
> + HDMI_PHY_COLORSPACE_YUV422, /* YCbCr 4:2:2 */
> + HDMI_PHY_COLORSPACE_YUV444, /* YCbCr 4:4:4 */
> + HDMI_PHY_COLORSPACE_YUV420, /* YCbCr 4:2:0 */
Better add this comments and above one as expected by kernel-doc for
enum..
> + HDMI_PHY_COLORSPACE_RESERVED4,
> + HDMI_PHY_COLORSPACE_RESERVED5,
> + HDMI_PHY_COLORSPACE_RESERVED6,
> +};
> +
> +/**
> + * struct phy_configure_opts_hdmi - HDMI configuration set
> + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> + * @bpc: Maximum bits per color channel.
> + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> + *
> + * This structure is used to represent the configuration state of a HDMI phy.
> + */
> +struct phy_configure_opts_hdmi {
> + unsigned int pixel_clk_rate;
> + unsigned int bpc;
> + enum hdmi_phy_colorspace color_space;
> +};
> +
> +#endif /* __PHY_HDMI_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 3a570bc59fc7..93d77d45b1d4 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -17,6 +17,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -42,7 +43,8 @@ enum phy_mode {
> PHY_MODE_MIPI_DPHY,
> PHY_MODE_SATA,
> PHY_MODE_LVDS,
> - PHY_MODE_DP
> + PHY_MODE_DP,
> + PHY_MODE_HDMI,
> };
>
> enum phy_media {
> @@ -60,11 +62,14 @@ enum phy_media {
> * the DisplayPort protocol.
> * @lvds:Configuration set applicable for phys supporting
> * the LVDS phy mode.
> + * @hdmi:Configuration set applicable for phys supporting
> + * the HDMI phy mode.
> */
> union phy_configure_opts {
> struct phy_configure_opts_mipi_dphy mipi_dphy;
> struct phy_configure_opts_dpdp;
> struct phy_configure_opts_lvds lvds;
> + struct phy_configure_opts_hdmi hdmi;
> };
>
> /**
> --
> 2.34.1
--
~Vinod
Re: [PATCH v2] phy: mediatek: rework the floating point comparisons to fixed point
On 02-05-23, 10:50, Tom Rix wrote: > gcc on aarch64 reports > drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c: In function > ‘mtk_hdmi_pll_set_rate’: > drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:240:52: error: > ‘-mgeneral-regs-only’ > is incompatible with the use of floating-point types > 240 | else if (tmds_clk >= 54 * MEGA && tmds_clk < 148.35 * MEGA) > > Floating point should not be used, so rework the floating point comparisons > to fixed point. Applied, thanks -- ~Vinod
Re: [PATCH v4 10/13] phy: amlogic: phy-meson-g12a-mipi-dphy-analog: fix CNTL2_DIF_TX_CTL0 value
On 12-05-23, 15:11, Neil Armstrong wrote: > Use the same CNTL2_DIF_TX_CTL0 value used by the vendor, it was reported > fixing timings issues. Applied to phy/fixes, thanks -- ~Vinod
Re: [PATCH] phy: mediatek: fix returning garbage
On 08-05-23, 10:24, Matthias Brugger wrote: > > > On 08/05/2023 09:48, Vinod Koul wrote: > > On 05-05-23, 17:37, Matthias Brugger wrote: > > > > > > > > > On 05/05/2023 11:28, Vinod Koul wrote: > > > > On 14-04-23, 08:22, Tom Rix wrote: > > > > > clang reports > > > > > drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable > > > > > 'ret' is uninitialized when used here [-Werror,-Wuninitialized] > > > > > if (ret) > > > > > ^~~ > > > > > ret should have been set by the preceding call to mtk_hdmi_pll_set_hw. > > > > > > > > I have applied "phy: mediatek: hdmi: mt8195: fix uninitialized variable > > > > usage in pll_calc" > > > > > > Thanks Vinod, that was on my list for today as well. I was a bit puzzled > > > because you took the patch that added it, but I wasn't sure if you would > > > take the fix. How do you want to handle things like this in the future? > > > > Fixes should be sent as Fixes patch > > > > I'm not sure what do you mean. Patch subject includes the word fix and the > patch has a fixes tag. What was missing here? > > Does this mean you will take fixes for this driver in the future or do you > want me to take care of them? Yes I would take the fixes as well for the drivers -- ~Vinod
Re: [PATCH] phy: mediatek: fix returning garbage
On 05-05-23, 17:37, Matthias Brugger wrote: > > > On 05/05/2023 11:28, Vinod Koul wrote: > > On 14-04-23, 08:22, Tom Rix wrote: > > > clang reports > > > drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable > > >'ret' is uninitialized when used here [-Werror,-Wuninitialized] > > > if (ret) > > > ^~~ > > > ret should have been set by the preceding call to mtk_hdmi_pll_set_hw. > > > > I have applied "phy: mediatek: hdmi: mt8195: fix uninitialized variable > > usage in pll_calc" > > Thanks Vinod, that was on my list for today as well. I was a bit puzzled > because you took the patch that added it, but I wasn't sure if you would > take the fix. How do you want to handle things like this in the future? Fixes should be sent as Fixes patch -- ~Vinod
Re: [PATCH] phy: mediatek: fix returning garbage
On 14-04-23, 08:22, Tom Rix wrote: > clang reports > drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable > 'ret' is uninitialized when used here [-Werror,-Wuninitialized] > if (ret) > ^~~ > ret should have been set by the preceding call to mtk_hdmi_pll_set_hw. I have applied "phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc" -- ~Vinod
Re: [PATCH 0/2] Fix mtk-hdmi-mt8195 unitialized variable usage and clock rate calculation
On 13-04-23, 14:46, Guillaume Ranquet wrote: > I've received a report from kernel test report [1] that a variable was used > unitialized in the mtk8195 hdmi phy code. > > I've upon fixing that issue found out that the clock rate calculation > was erroneous since the calculus was moved to div_u64. Applied both, thanks -- ~Vinod
Re: [PATCH] phy: mediatek: Remove unusued ret and check
On 04-05-23, 17:19, Palmer Dabbelt wrote:
> From: Palmer Dabbelt
>
> This trips up a maybe-uninitialized warning, but it's actually just not
> used.
Thanks but this is already fixed by 714dd3c29a22 ("phy: mediatek: hdmi:
mt8195: fix uninitialized variable usage in pll_calc") in phy/next and
should be in Linus's tree shortly
--
~Vinod
Re: [PATCH v3 01/11] dmaengine: Add API function dmaengine_prep_slave_dma_array()
On 03-04-23, 17:47, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer
> where the DMA addresses and lengths are located inside arrays.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
Do we need a new API for this? why not use device_prep_interleaved_dma?
>
> Signed-off-by: Paul Cercueil
>
> ---
> v3: New patch
> ---
> include/linux/dmaengine.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index c3656e590213..62efa28c009a 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -912,6 +912,11 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_slave_dma_array)(
> + struct dma_chan *chan, dma_addr_t *addrs,
> + size_t *lengths, size_t nb,
> + enum dma_transfer_direction direction,
> + unsigned long flags);
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> @@ -974,6 +979,17 @@ static inline struct dma_async_tx_descriptor
> *dmaengine_prep_slave_single(
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_dma_array(
> + struct dma_chan *chan, dma_addr_t *addrs, size_t *lengths,
> + size_t nb, enum dma_transfer_direction dir, unsigned long flags)
> +{
> + if (!chan || !chan->device ||
> !chan->device->device_prep_slave_dma_array)
> + return NULL;
> +
> + return chan->device->device_prep_slave_dma_array(chan, addrs, lengths,
> + nb, dir, flags);
> +}
> +
> static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
> enum dma_transfer_direction dir, unsigned long flags)
> --
> 2.39.2
--
~Vinod
[PATCH] drm/panel-edp: Add B133UAN01.0 edp panel entry
From: Bjorn Andersson
This panel is found in Lenovo Flex 5G laptop, so add the entry for it
Signed-off-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 01bfe0783304..926906ca2304 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1871,6 +1871,7 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, _200_500_e50,
"B133UAN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, _200_500_e50,
"B116XAK01.6"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, _b116xak01.delay,
"B116XAK01"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, _200_500_e50,
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, _200_500_e50,
"B116XAN06.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, _200_500_e50,
"B133UAN01.0"),
--
2.39.2
Re: [PATCH 00/31] phy: Convert to platform remove callback returning void
On 07-03-23, 12:58, Uwe Kleine-König wrote:
> Hello,
>
> this patch series adapts the platform drivers below drivers/phy to use the
> .remove_new() callback. Compared to the traditional .remove() callback
> .remove_new() returns no value. This is a good thing because the driver core
> doesn't (and cannot) cope for errors during remove. The only effect of a
> non-zero return value in .remove() is that the driver core emits a warning.
> The
> device is removed anyhow and an early return from .remove() usually yields a
> resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably assume any more that there is some kind of cleanup later.
>
> All drivers in drivers/spmi returned zero unconditionally in their remove
> callback, so they could all be converted trivially to .remove_new().
>
> Note that this series depends on commit 5c5a7680e67b ("platform: Provide
> a remove callback that returns no value") which is included in v6.3-rc1.
Applied, thanks
--
~Vinod
Re: [RFC PATCH 2/4] phy: rockchip: Add inno_is_valid_phy_mode
On 02-10-22, 08:45, Michael Trimarchi wrote:
> The function is used to avoid to enable clock on the hardware
> if the mode requested is invalid
>
> Signed-off-by: Michael Trimarchi
> ---
> .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
> b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
> index 630e01b5c19b..644cf73cfd53 100644
> --- a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
> @@ -217,6 +217,20 @@ static void phy_update_bits(struct inno_dsidphy *inno,
> writel(tmp, inno->phy_base + reg);
> }
>
> +static int inno_is_valid_phy_mode(struct inno_dsidphy *inno)
> +{
> + switch (inno->mode) {
> + case PHY_MODE_MIPI_DPHY:
> + break;
> + case PHY_MODE_LVDS:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +};
> +
> static unsigned long inno_dsidphy_pll_calc_rate(struct inno_dsidphy *inno,
> unsigned long rate)
> {
> @@ -495,6 +509,11 @@ static void inno_dsidphy_lvds_mode_enable(struct
> inno_dsidphy *inno)
> static int inno_dsidphy_power_on(struct phy *phy)
> {
> struct inno_dsidphy *inno = phy_get_drvdata(phy);
> + int ret = 0;
this initialization is superfluous
> +
> + ret = inno_is_valid_phy_mode(inno);
> + if (ret)
> + return ret;
>
> clk_prepare_enable(inno->pclk_phy);
> clk_prepare_enable(inno->ref_clk);
> --
> 2.34.1
--
~Vinod
Re: [PATCH v3 08/10] phy: cadence: Add driver for HDP-TX DisplyPort PHY
On 08-11-22, 21:00, Sandor Yu wrote: > Add Cadence HDP-TX DisplayPort PHY driver. > > Cadence HDP-TX PHY could be put in either DP mode or > HDMI mode base on the configuration chosen. > DisplayPort PHY mode is configurated in the driver. > > Signed-off-by: Sandor Yu > --- > drivers/phy/cadence/Kconfig| 8 + > drivers/phy/cadence/Makefile | 1 + > drivers/phy/cadence/phy-cadence-hdptx-dp.c | 774 + > 3 files changed, 783 insertions(+) > create mode 100644 drivers/phy/cadence/phy-cadence-hdptx-dp.c > > diff --git a/drivers/phy/cadence/Kconfig b/drivers/phy/cadence/Kconfig > index 1adde2d99ae7..1e1914d3afdc 100644 > --- a/drivers/phy/cadence/Kconfig > +++ b/drivers/phy/cadence/Kconfig > @@ -46,3 +46,11 @@ config PHY_CADENCE_SALVO > Enable this to support the Cadence SALVO PHY driver, > this PHY is a legacy PHY, and only are used for USB3 > and USB2. > + > +config PHY_CADENCE_HDPTX_DP alphabetically sorted please > + tristate "Cadence HDPTX DP PHY Driver" > + depends on OF && HAS_IOMEM > + depends on COMMON_CLK > + select GENERIC_PHY > + help > + Enable this to support the Cadence HDPTX DP PHY driver > diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile > index e17f035ddece..fbdb0bc5ff11 100644 > --- a/drivers/phy/cadence/Makefile > +++ b/drivers/phy/cadence/Makefile > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_CADENCE_DPHY)+= cdns-dphy.o > obj-$(CONFIG_PHY_CADENCE_DPHY_RX)+= cdns-dphy-rx.o > obj-$(CONFIG_PHY_CADENCE_SIERRA) += phy-cadence-sierra.o > obj-$(CONFIG_PHY_CADENCE_SALVO) += phy-cadence-salvo.o > +obj-$(CONFIG_PHY_CADENCE_HDPTX_DP) += phy-cadence-hdptx-dp.o here too > diff --git a/drivers/phy/cadence/phy-cadence-hdptx-dp.c > b/drivers/phy/cadence/phy-cadence-hdptx-dp.c > new file mode 100644 > index ..079d43772d1d > --- /dev/null > +++ b/drivers/phy/cadence/phy-cadence-hdptx-dp.c > @@ -0,0 +1,774 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Cadence HDP-TX Display Port Interface (DP) PHY driver > + * > + * Copyright (C) 2022 NXP Semiconductor, Inc. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define ADDR_PHY_AFE 0x8 > + > +/* PHY registers */ > +#define CMN_SSM_BIAS_TMR0x0022 > +#define CMN_PLLSM0_PLLEN_TMR0x0029 > +#define CMN_PLLSM0_PLLPRE_TMR 0x002A > +#define CMN_PLLSM0_PLLVREF_TMR 0x002B > +#define CMN_PLLSM0_PLLLOCK_TMR 0x002C > +#define CMN_PLLSM0_USER_DEF_CTRL0x002F > +#define CMN_PSM_CLK_CTRL0x0061 > +#define CMN_CDIAG_REFCLK_CTRL 0x0062 > +#define CMN_PLL0_VCOCAL_START 0x0081 > +#define CMN_PLL0_VCOCAL_INIT_TMR0x0084 > +#define CMN_PLL0_VCOCAL_ITER_TMR0x0085 > +#define CMN_PLL0_INTDIV 0x0094 > +#define CMN_PLL0_FRACDIV0x0095 > +#define CMN_PLL0_HIGH_THR 0x0096 > +#define CMN_PLL0_DSM_DIAG 0x0097 > +#define CMN_PLL0_SS_CTRL1 0x0098 > +#define CMN_PLL0_SS_CTRL2 0x0099 > +#define CMN_ICAL_INIT_TMR 0x00C4 > +#define CMN_ICAL_ITER_TMR 0x00C5 > +#define CMN_RXCAL_INIT_TMR 0x00D4 > +#define CMN_RXCAL_ITER_TMR 0x00D5 > +#define CMN_TXPUCAL_CTRL0x00E0 > +#define CMN_TXPUCAL_INIT_TMR0x00E4 > +#define CMN_TXPUCAL_ITER_TMR0x00E5 > +#define CMN_TXPDCAL_CTRL0x00F0 > +#define CMN_TXPDCAL_INIT_TMR0x00F4 > +#define CMN_TXPDCAL_ITER_TMR0x00F5 > +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 > +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 > +#define CMN_RX_ADJ_INIT_TMR 0x0106 > +#define CMN_RX_ADJ_ITER_TMR 0x0107 > +#define CMN_TXPU_ADJ_CTRL 0x0108 > +#define CMN_TXPU_ADJ_INIT_TMR 0x010A > +#define CMN_TXPU_ADJ_ITER_TMR 0x010B > +#define CMN_TXPD_ADJ_CTRL 0x010c > +#define CMN_TXPD_ADJ_INIT_TMR 0x010E > +#define CMN_TXPD_ADJ_ITER_TMR 0x010F > +#define CMN_DIAG_PLL0_FBH_OVRD 0x01C0 > +#define CMN_DIAG_PLL0_FBL_OVRD 0x01C1 > +#define CMN_DIAG_PLL0_OVRD 0x01C2 > +#define CMN_DIAG_PLL0_TEST_MODE 0x01C4 > +#define CMN_DIAG_PLL0_V2I_TUNE 0x01C5 > +#define CMN_DIAG_PLL0_CP_TUNE 0x01C6 > +#define CMN_DIAG_PLL0_LF_PROG 0x01C7 > +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01C8 > +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01C9 > +#define CMN_DIAG_PLL0_INCLK_CTRL0x01CA > +#define CMN_DIAG_PLL0_PXL_DIVH 0x01CB > +#define CMN_DIAG_PLL0_PXL_DIVL 0x01CC > +#define CMN_DIAG_HSCLK_SEL 0x01E0 > +#define CMN_DIAG_PER_CAL_ADJ0x01EC > +#define CMN_DIAG_CAL_CTRL 0x01ED > +#define CMN_DIAG_ACYA 0x01FF >
Re: [PATCH v3 04/10] phy: Add HDMI configuration options
On 08-11-22, 21:00, Sandor Yu wrote:
> Allow HDMI PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
>
> The parameters added here are based on HDMI PHY
> implementation practices. The current set of parameters
> should cover the potential users.
Is there any dpendency b/w phy and hdmi, I dont see anything in cover..
Pls consider splitting the phy series ..
>
> Signed-off-by: Sandor Yu
> ---
> include/linux/phy/phy-hdmi.h | 33 +
> include/linux/phy/phy.h | 7 ++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/phy/phy-hdmi.h
>
> diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
> new file mode 100644
> index ..73a32eb535b0
> --- /dev/null
> +++ b/include/linux/phy/phy-hdmi.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2022 NXP
> + */
> +
> +#ifndef __PHY_HDMI_H_
> +#define __PHY_HDMI_H_
> +
> +enum hdmi_phy_colorspace {
> + HDMI_PHY_COLORSPACE_RGB,
> + HDMI_PHY_COLORSPACE_YUV422,
> + HDMI_PHY_COLORSPACE_YUV444,
> + HDMI_PHY_COLORSPACE_YUV420,
> + HDMI_PHY_COLORSPACE_RESERVED4,
> + HDMI_PHY_COLORSPACE_RESERVED5,
> + HDMI_PHY_COLORSPACE_RESERVED6,
> +};
kernel-doc style comments here too please
> +
> +/**
> + * struct phy_configure_opts_hdmi - HDMI configuration set
> + * @pixel_clk_rate: Pixel clock of video modes in KHz.
> + * @bpc: Maximum bits per color channel.
> + * @color_space: Colorspace in enum hdmi_phy_colorspace.
> + *
> + * This structure is used to represent the configuration state of a HDMI phy.
> + */
> +struct phy_configure_opts_hdmi {
> + unsigned int pixel_clk_rate;
> + unsigned int bpc;
> + enum hdmi_phy_colorspace color_space;
> +};
> +
> +#endif /* __PHY_HDMI_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index b1413757fcc3..6f6873ea7270 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -17,6 +17,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -42,7 +43,8 @@ enum phy_mode {
> PHY_MODE_MIPI_DPHY,
> PHY_MODE_SATA,
> PHY_MODE_LVDS,
> - PHY_MODE_DP
> + PHY_MODE_DP,
> + PHY_MODE_HDMI,
> };
>
> enum phy_media {
> @@ -60,11 +62,14 @@ enum phy_media {
> * the DisplayPort protocol.
> * @lvds:Configuration set applicable for phys supporting
> * the LVDS phy mode.
> + * @hdmi:Configuration set applicable for phys supporting
> + * the HDMI phy mode.
> */
> union phy_configure_opts {
> struct phy_configure_opts_mipi_dphy mipi_dphy;
> struct phy_configure_opts_dpdp;
> struct phy_configure_opts_lvds lvds;
> + struct phy_configure_opts_hdmi hdmi;
> };
>
> /**
> --
> 2.34.1
--
~Vinod
Re: [PATCH v3 10/12] phy: mediatek: add support for phy-mtk-hdmi-mt8195
On 04-11-22, 15:09, Guillaume Ranquet wrote:
> Add basic support for the mediatek hdmi phy on MT8195 SoC
Are phy patches in this series dependent upon changes in drm/, if not
consider splitting them up!
>
> Signed-off-by: Guillaume Ranquet
> ---
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c | 543
> +
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.h | 109 ++
> drivers/phy/mediatek/phy-mtk-hdmi.c| 3 +
> drivers/phy/mediatek/phy-mtk-hdmi.h| 1 +
> 5 files changed, 657 insertions(+)
>
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index fb1f8edaffa7..c9a50395533e 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8173.o
> +phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt8195.o
> obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
>
> phy-mtk-mipi-dsi-drv-y := phy-mtk-mipi-dsi.o
> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> new file mode 100644
> index ..48efd3936f29
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c
> @@ -0,0 +1,543 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Copyright (c) 2022 BayLibre, SAS
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "phy-mtk-io.h"
> +#include "phy-mtk-hdmi.h"
> +#include "phy-mtk-hdmi-mt8195.h"
> +
> +static void mtk_hdmi_ana_fifo_en(struct mtk_hdmi_phy *hdmi_phy)
> +{
> + /* make data fifo writable for hdmi2.0 */
> + mtk_phy_set_bits(hdmi_phy->regs + HDMI_ANA_CTL, REG_ANA_HDMI20_FIFO_EN);
> +}
> +
> +static void
> +mtk_mt8195_phy_tmds_high_bit_clk_ratio(struct mtk_hdmi_phy *hdmi_phy,
> +bool enable)
> +{
> + void __iomem *regs = hdmi_phy->regs;
> +
> + mtk_hdmi_ana_fifo_en(hdmi_phy);
> +
> + /* HDMI 2.0 specification, 3.4Gbps <= TMDS Bit Rate <= 6G,
> + * clock bit ratio 1:40, under 3.4Gbps, clock bit ratio 1:10
> + */
> + if (enable)
> + mtk_phy_update_field(regs + HDMI20_CLK_CFG, REG_TXC_DIV,
> REG_TXC_DIV);
> + else
> + mtk_phy_clear_bits(regs + HDMI20_CLK_CFG, REG_TXC_DIV);
> +}
> +
> +static void mtk_hdmi_pll_select_source(struct clk_hw *hw)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + void __iomem *regs = hdmi_phy->regs;
> +
> + mtk_phy_clear_bits(regs + HDMI_CTL_3, REG_HDMITX_REF_XTAL_SEL);
> + mtk_phy_clear_bits(regs + HDMI_CTL_3, REG_HDMITX_REF_RESPLL_SEL);
> +
> + /* DA_HDMITX21_REF_CK for TXPLL input source */
> + mtk_phy_clear_bits(regs + HDMI_1_CFG_10, RG_HDMITXPLL_REF_CK_SEL);
> +}
> +
> +static int mtk_hdmi_pll_performance_setting(struct clk_hw *hw)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + void __iomem *regs = hdmi_phy->regs;
> +
> + /* BP2 */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_BP2);
> +
> + /* BC */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_BC);
> +
> + /* IC */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_IC, 0x1);
> +
> + /* BR */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_BR, 0x2);
> +
> + /* IR */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_IR, 0x2);
> +
> + /* BP */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_BP);
> +
> + /* IBAND_FIX_EN, RESERVE[14] */
> + mtk_phy_clear_bits(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_IBAND_FIX_EN);
> + mtk_phy_clear_bits(regs + HDMI_1_PLL_CFG_1, RG_HDMITXPLL_RESERVE_BIT14);
> +
> + /* HIKVCO */
> + mtk_phy_clear_bits(regs + HDMI_1_PLL_CFG_2, RG_HDMITXPLL_HIKVCO);
> +
> + /* HREN */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_HREN, 0x1);
> +
> + /* LVR_SEL */
> + mtk_phy_update_field(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_LVR_SEL,
> 0x1);
> +
> + /* RG_HDMITXPLL_RESERVE[12:11] */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_1,
> RG_HDMITXPLL_RESERVE_BIT12_11);
> +
> + /* TCL_EN */
> + mtk_phy_set_bits(regs + HDMI_1_PLL_CFG_0, RG_HDMITXPLL_TCL_EN);
> +
> + return 0;
> +}
> +
> +static int mtk_hdmi_pll_set_hw(struct clk_hw *hw, unsigned char prediv,
> +unsigned char fbkdiv_high,
> +unsigned long fbkdiv_low,
> +unsigned char fbkdiv_hs3, unsigned char posdiv1,
> +unsigned char posdiv2, unsigned char txprediv,
> +
Re: [PATCH v1 3/5] arm64: dts: qcom: sm8450-hdk: enable display hardware
On 04-11-22, 16:13, Dmitry Baryshkov wrote:
> Enable MDSS/DPU/DSI0 on SM8450-HDK device. Note, there is no panel
> configuration (yet).
>
> Signed-off-by: Dmitry Baryshkov
> ---
> arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
> b/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
> index 38ccd44620d0..e1a4cf1ee51d 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8450-hdk.dts
> @@ -442,3 +442,21 @@ _1_qmpphy {
> vdda-phy-supply = <_l6b_1p2>;
> vdda-pll-supply = <_l1b_0p91>;
> };
> +
> + {
> + status = "okay";
> +};
> +
> +_mdp {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + vdda-supply = <_l6b_1p2>;
> +};
> +
> +_phy {
> + status = "okay";
> + vdds-supply = <_l5b_0p88>;
> +};
This is missing dispcc, please enable that node too.
Also, sort this please
> --
> 2.35.1
--
~Vinod
Re: [PATCH] dt-bindings: Remove "status" from schema examples, again
On 14-10-22, 15:51, Rob Herring wrote:
> There's no reason to have "status" properties in examples. "okay" is the
> default, and "disabled" turns off some schema checks ('required'
> specifically).
>
> A meta-schema check for this is pending, so hopefully the last time to
> fix these.
>
> Fix the indentation in intel,phy-thunderbay-emmc while we're here.
Acked-By: Vinod Koul
--
~Vinod
Re: [PATCH 0/5] drm: Fix math issues in MSM DSC implementation
On 01-10-22, 21:08, Marijn Suijten wrote: > Various removals of complex yet unnecessary math, fixing all uses of > drm_dsc_config::bits_per_pixel to deal with the fact that this field > includes four fractional bits, and finally an approach for dealing with > dsi_host setting negative values in range_bpg_offset, resulting in > overflow inside drm_dsc_pps_payload_pack(). > > Note that updating the static bpg_offset array to limit the size of > these negative values to 6 bits changes what would be written to the DPU > hardware at register(s) DSC_RANGE_BPG_OFFSET, hence the choice has been > made to cover up for this while packing the value into a smaller field > instead. Thanks for fixing these. I dont have my pixel3 availble but changes lgtm Reviewed-by: Vinod Koul > Altogether this series is responsible for solving _all_ Display Stream > Compression issues and artifacts on the Sony Tama (sdm845) Akatsuki > smartphone (2880x1440p). Does it need two dsi lanes? -- ~Vinod
Re: [PATCH] phy: phy-mtk-dp: make array driving_params static const
On 29-09-22, 14:01, Colin Ian King wrote: > Don't populate the read-only array driving_params on the stack but instead > make it static const. Also makes the object code a little smaller. Applied, thanks -- ~Vinod
Re: [PATCH 00/18] unify register access and macros
On 20-09-22, 17:00, Chunfeng Yun wrote: > No need to define new macros to generate bits, mask and bitfield, use > common ones instead, e.g. BIT, GENMASK and FIELD_PREP etc. > Due to common register access helpers are defined for MediaTek's phy > drivers, the similar helpers defined by ufs, hdmi and mipi phy drivers > can be removed. Applied, thanks -- ~Vinod
Re: [Freedreno] [PATCH 0/5] drm/msm: add support for SM8450
On 22-09-22, 14:30, Dmitry Baryshkov wrote: > This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform. Tested this on DM8450-HDK with HDMI and it works for me. For whole series: Tested-by: Vinod Koul Reviewed-by: Vinod Koul > > Dmitry Baryshkov (5): > drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450 > drm/msm/dsi: add support for DSI 2.6.0 > drm/msm/dpu: add support for MDP_TOP blackhole > drm/msm/dpu: add support for SM8450 > drm/msm: mdss add support for SM8450 > > drivers/gpu/drm/msm/Kconfig | 6 +- > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++ > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 + > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +- > drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + > drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 2 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 132 ++- > drivers/gpu/drm/msm/msm_mdss.c| 8 + > 11 files changed, 381 insertions(+), 15 deletions(-) > > -- > 2.35.1 -- ~Vinod
Re: [PATCH -next] phy: phy-mtk-dp: change mtk_dp_phy_driver to static
On 07-07-22, 21:53, Yang Yingliang wrote: > mtk_dp_phy_driver is only used in phy-mtk-dp.c now, change it to static. Applied, thanks -- ~Vinod
Re: [PATCH v16 0/3] eDP/DP Phy vdda realted function
On 05-07-22, 09:29, Kuogee Hsieh wrote: > 0) rebase on > https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tree > 1) add regulator_set_load() to eDP phy > 2) add regulator_set_load() to DP phy > 3) remove vdda related function out of eDP/DP controller Applied, thanks -- ~Vinod
Re: [PATCH v5 03/13] dt-bindings: dma: dw-axi-dmac: extend the number of interrupts
On 05-07-22, 22:52, Conor Dooley wrote: > From: Conor Dooley > > The Canaan k210 apparently has a Sysnopsys Designware AXI DMA > controller, but according to the documentation & devicetree it has 6 > interrupts rather than the standard one. Support the 6 interrupt > configuration by unconditionally extending the binding to a maximum of > 8 per-channel interrupts thereby matching the number of possible > channels. Applied, thanks -- ~Vinod
Re: [PATCH v4 04/14] dt-bindings: dma: dw-axi-dmac: extend the number of interrupts
On 01-07-22, 20:22, Conor Dooley wrote: > From: Conor Dooley > > The Canaan k210 apparently has a Sysnopsys Designware AXI DMA > controller, but according to the documentation & devicetree it has 6 > interrupts rather than the standard one. Support the 6 interrupt > configuration by unconditionally extending the binding to a maximum of > 8 per-channel interrupts thereby matching the number of possible > channels. > > Link: > https://canaan-creative.com/wp-content/uploads/2020/03/kendryte_standalone_programming_guide_20190311144158_en.pdf > #Page 51 > Reviewed-by: Serge Semin > Signed-off-by: Conor Dooley > --- > .../devicetree/bindings/dma/snps,dw-axi-dmac.yaml | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > index 4324a94b26b2..98c2ab18d04f 100644 > --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml > @@ -34,7 +34,12 @@ properties: >- const: axidma_apb_regs > >interrupts: > -maxItems: 1 > +description: | rob asked you to drop this in last patch, pls fix that and send with his ack > + If the IP-core synthesis parameter DMAX_INTR_IO_TYPE is set to 1, this > + will be per-channel interrupts. Otherwise, this is a single combined > IRQ > + for all channels. > +minItems: 1 > +maxItems: 8 > >clocks: > items: > -- > 2.37.0 -- ~Vinod
Re: [PATCH v3 1/3] dt-bindings: phy: qcom,hdmi-phy-qmp: add clock-cells and XO clock
On 04-07-22, 19:11, Dmitry Baryshkov wrote: > As the QMP HDMI PHY is a clock provider, add constant #clock-cells > property. For the compatibility with older DTs the property is not > marked as required. Also add the XO clock to the list of the clocks used > by the driver. Acked-By: Vinod Koul > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Dmitry Baryshkov > --- > .../bindings/phy/qcom,hdmi-phy-qmp.yaml | 15 --- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml > b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml > index eea2e02678ed..83fe4b39b56f 100644 > --- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml > +++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml > @@ -28,12 +28,15 @@ properties: >- const: hdmi_phy > >clocks: > -maxItems: 2 > +minItems: 2 > +maxItems: 3 > >clock-names: > +minItems: 2 > items: >- const: iface >- const: ref > + - const: xo > >power-domains: > maxItems: 1 > @@ -44,6 +47,9 @@ properties: >vddio-supply: > description: phandle to VDD I/O supply regulator > > + '#clock-cells': > +const: 0 > + >'#phy-cells': > const: 0 > > @@ -75,9 +81,12 @@ examples: >"hdmi_phy"; > >clocks = < 116>, > - < 214>; > + < 214>, > + <_board>; >clock-names = "iface", > -"ref"; > +"ref", > +"xo"; > + #clock-cells = <0>; >#phy-cells = <0>; > >vddio-supply = <_l12a_1p8>; > -- > 2.35.1 -- ~Vinod
Re: [PATCH 1/3] dt-bindings: phy: qcom,hdmi-phy-qmp: add clock-cells
On 17-06-22, 13:36, Dmitry Baryshkov wrote: > As the QMP HDMI PHY is a clock provider, add constant #clock-cells > property. For the compatibility with older DTs the property is not > marked as required. Acked-By: Vinod Koul -- ~Vinod
Re: [PATCH v12 1/1] phy: phy-mtk-dp: Add driver for DP phy
On 24-06-22, 14:27, Bo-Chen Chen wrote: > From: Markus Schneider-Pargmann > > This is a new driver that supports the integrated DisplayPort phy for > mediatek SoCs, especially the mt8195. The phy is integrated into the > DisplayPort controller and will be created by the mtk-dp driver. This > driver expects a struct regmap to be able to work on the same registers > as the DisplayPort controller. It sets the device data to be the struct > phy so that the DisplayPort controller can easily work with it. > > The driver does not have any devicetree bindings because the datasheet > does not list the controller and the phy as distinct units. > > The interaction with the controller can be covered by the configure > callback of the phy framework and its displayport parameters. > > Signed-off-by: Markus Schneider-Pargmann > Signed-off-by: Guillaume Ranquet > [Bo-Chen: Modify reviewers' comments.] > Signed-off-by: Bo-Chen Chen > Reviewed-by: AngeloGioacchino Del Regno > Applied, thanks -- ~Vinod
Re: [PATCH v15 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
On 21-06-22, 10:01, Kuogee Hsieh wrote:
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> Reviewed-by: Douglas Anderson
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 43
> ---
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 893b5a4..df62980 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -604,6 +604,18 @@ static const struct qmp_phy_init_tbl qmp_v4_dp_tx_tbl[]
> = {
> QMP_PHY_INIT_CFG(QSERDES_V4_TX_TX_EMP_POST1_LVL, 0x20),
> };
>
> +
this makes it double blank lines, pls remove
> +/* list of regulators */
> +struct qmp_regulator_data {
> + const char *name;
> + unsigned int enable_load;
> +};
> +
> +struct qmp_regulator_data qmp_phy_vreg_l[] = {
> + { .name = "vdda-phy", .enable_load = 21800 },
> + { .name = "vdda-pll", .enable_load = 36000 },
> +};
> +
> struct qmp_phy;
>
> /* struct qmp_phy_cfg - per-PHY initialization config */
> @@ -646,7 +658,7 @@ struct qmp_phy_cfg {
> const char * const *reset_list;
> int num_resets;
> /* regulators to be requested */
> - const char * const *vreg_list;
> + const struct qmp_regulator_data *vreg_list;
> int num_vregs;
>
> /* array of registers with different offsets */
> @@ -809,11 +821,6 @@ static const char * const sc7180_usb3phy_reset_l[] = {
> "phy",
> };
>
> -/* list of regulators */
> -static const char * const qmp_phy_vreg_l[] = {
> - "vdda-phy", "vdda-pll",
> -};
> -
> static const struct qmp_phy_cfg sc7180_usb3phy_cfg = {
> .type = PHY_TYPE_USB3,
> .nlanes = 1,
> @@ -1969,16 +1976,32 @@ static int qcom_qmp_phy_combo_vreg_init(struct device
> *dev, const struct qmp_phy
> {
> struct qcom_qmp *qmp = dev_get_drvdata(dev);
> int num = cfg->num_vregs;
> - int i;
> + int ret, i;
>
> qmp->vregs = devm_kcalloc(dev, num, sizeof(*qmp->vregs), GFP_KERNEL);
> if (!qmp->vregs)
> return -ENOMEM;
>
> for (i = 0; i < num; i++)
> - qmp->vregs[i].supply = cfg->vreg_list[i];
> -
> - return devm_regulator_bulk_get(dev, num, qmp->vregs);
> + qmp->vregs[i].supply = cfg->vreg_list[i].name;
> +
> +ret = devm_regulator_bulk_get(dev, num, qmp->vregs);
> +if (ret) {
> +dev_err(dev, "failed at devm_regulator_bulk_get\n");
> +return ret;
> +}
> +
> +for (i = 0; i < num; i++) {
> +ret = regulator_set_load(qmp->vregs[i].consumer,
> + cfg->vreg_list[i].enable_load);
> +if (ret) {
> +dev_err(dev, "failed to set load at %s\n",
> +qmp->vregs[i].supply);
> +return ret;
> +}
> +}
> +
> +return 0;
argh!
checkpatch says:
total: 15 errors, 25 warnings, 1 checks, 277 lines checked
Looks like all lines use spaces and not tabs :-(
Pls fix that and resend
--
~Vinod
Re: [PATCH v2 02/96] soundwire: intel: Migrate to new style legacy DAI naming flag
On 23-06-22, 13:51, Charles Keepax wrote: > Change the legacy DAI naming flag from opting in to the new scheme > (non_legacy_dai_naming), to opting out of it (legacy_dai_naming). > This driver appears to be on the CPU side of the DAI link and > currently uses the legacy naming, so add the new flag. Acked-By: Vinod Koul -- ~Vinod
Re: [PATCH v13 0/3] eDP/DP Phy vdda realted function
On 20-06-22, 13:43, Kuogee Hsieh wrote: > > On 6/20/2022 1:07 PM, Kuogee Hsieh wrote: > > > > On 6/16/2022 5:02 PM, Vinod Koul wrote: > > > On 25-05-22, 14:02, Kuogee Hsieh wrote: > > > > 1) add regulator_set_load() to eDP phy > > > > 2) add regulator_set_load() to DP phy > > > > 3) remove vdda related function out of eDP/DP controller > > > > > > > > Kuogee Hsieh (3): > > > > phy: qcom-edp: add regulator_set_load to edp phy > > > > phy: qcom-qmp: add regulator_set_load to dp phy > > > > drm/msm/dp: delete vdda regulator related functions from eDP/DP > > > > controller > > > > > > > > drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- > > > > drivers/gpu/drm/msm/dp/dp_parser.h | 8 > > > > drivers/gpu/drm/msm/dp/dp_power.c | 95 > > > > + > > > > drivers/phy/qualcomm/phy-qcom-edp.c | 12 + > > > > drivers/phy/qualcomm/phy-qcom-qmp.c | 40 > > > Please rebase this to phy-next and apply to specific qmp phy driver... > > I will rebase to ==> > > https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git > > Hi Vinod, > > Would you please specify exactly procedures i have to do as to rebase this > patch series to phy=next tree. Yes pls rebase to above tree and next branch -- ~Vinod
Re: [PATCH v11 1/1] phy: phy-mtk-dp: Add driver for DP phy
On 13-06-22, 15:26, Bo-Chen Chen wrote: > From: Markus Schneider-Pargmann > > This is a new driver that supports the integrated DisplayPort phy for > mediatek SoCs, especially the mt8195. The phy is integrated into the > DisplayPort controller and will be created by the mtk-dp driver. This > driver expects a struct regmap to be able to work on the same registers > as the DisplayPort controller. It sets the device data to be the struct > phy so that the DisplayPort controller can easily work with it. > > The driver does not have any devicetree bindings because the datasheet > does not list the controller and the phy as distinct units. > > The interaction with the controller can be covered by the configure > callback of the phy framework and its displayport parameters. > > Signed-off-by: Markus Schneider-Pargmann > Signed-off-by: Guillaume Ranquet > [Bo-Chen: Modify reviewers' comments.] > Signed-off-by: Bo-Chen Chen > --- > MAINTAINERS | 1 + > drivers/phy/mediatek/Kconfig | 8 ++ > drivers/phy/mediatek/Makefile | 1 + > drivers/phy/mediatek/phy-mtk-dp.c | 202 ++ > 4 files changed, 212 insertions(+) > create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a6d3bd9d2a8d..f1460ee9ce83 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6698,6 +6698,7 @@ L: linux-media...@lists.infradead.org (moderated > for non-subscribers) > S: Supported > F: Documentation/devicetree/bindings/display/mediatek/ > F: drivers/gpu/drm/mediatek/ > +F: drivers/phy/mediatek/phy-mtk-dp.c > F: drivers/phy/mediatek/phy-mtk-hdmi* > F: drivers/phy/mediatek/phy-mtk-mipi* > > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig > index 55f8e6c048ab..d631525d12e1 100644 > --- a/drivers/phy/mediatek/Kconfig > +++ b/drivers/phy/mediatek/Kconfig > @@ -55,3 +55,11 @@ config PHY_MTK_MIPI_DSI > select GENERIC_PHY > help > Support MIPI DSI for Mediatek SoCs. > + > +config PHY_MTK_DP > + tristate "MediaTek DP-PHY Driver" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + depends on OF > + select GENERIC_PHY > + help > + Support DisplayPort PHY for MediaTek SoCs. > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile > index ace660fbed3a..4ba1e0650434 100644 > --- a/drivers/phy/mediatek/Makefile > +++ b/drivers/phy/mediatek/Makefile > @@ -3,6 +3,7 @@ > # Makefile for the phy drivers. > # > > +obj-$(CONFIG_PHY_MTK_DP) += phy-mtk-dp.o > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o > obj-$(CONFIG_PHY_MTK_UFS)+= phy-mtk-ufs.o > obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o > diff --git a/drivers/phy/mediatek/phy-mtk-dp.c > b/drivers/phy/mediatek/phy-mtk-dp.c > new file mode 100644 > index ..c4d5ca1719a4 > --- /dev/null > +++ b/drivers/phy/mediatek/phy-mtk-dp.c > @@ -0,0 +1,202 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * MediaTek DisplayPort PHY driver > + * > + * Copyright (c) 2022 BayLibre > + * Copyright (c) 2022 MediaTek It should be proper name of companies (hint see other uses) > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PHY_OFFSET 0x1000 > + > +#define MTK_DP_PHY_DIG_PLL_CTL_1 (PHY_OFFSET + 0x14) > +#define TPLL_SSC_EN BIT(3) > + > +#define MTK_DP_PHY_DIG_BIT_RATE (PHY_OFFSET + 0x3C) > +#define BIT_RATE_RBR 0 > +#define BIT_RATE_HBR 1 > +#define BIT_RATE_HBR22 > +#define BIT_RATE_HBR33 > + > +#define MTK_DP_PHY_DIG_SW_RST(PHY_OFFSET + 0x38) > +#define DP_GLB_SW_RST_PHYD BIT(0) > + > +#define MTK_DP_LANE0_DRIVING_PARAM_3 (PHY_OFFSET + 0x138) > +#define MTK_DP_LANE1_DRIVING_PARAM_3 (PHY_OFFSET + 0x238) > +#define MTK_DP_LANE2_DRIVING_PARAM_3 (PHY_OFFSET + 0x338) > +#define MTK_DP_LANE3_DRIVING_PARAM_3 (PHY_OFFSET + 0x438) > +#define XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULTBIT(4) > +#define XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT(BIT(10) | BIT(12)) > +#define XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULTGENMASK(20, 19) > +#define XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULTGENMASK(29, 29) > +#define DRIVING_PARAM_3_DEFAULT (XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULT | \ > + XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT | \ > + XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULT | \ > + XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULT) > + > +#define XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULTGENMASK(4, 3) > +#define XTP_LN_TX_LCTXC0_SW1_PRE1_DEFAULTGENMASK(12, 9) > +#define XTP_LN_TX_LCTXC0_SW1_PRE2_DEFAULT(BIT(18) | BIT(21)) > +#define XTP_LN_TX_LCTXC0_SW2_PRE0_DEFAULTGENMASK(29, 29) > +#define DRIVING_PARAM_4_DEFAULT (XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULT |
Re: [PATCH 2/2] dt-bindings: phy: List supplies for qcom,edp-phy
On 16-06-22, 08:35, Doug Anderson wrote: > Hi, > > On Mon, Apr 25, 2022 at 2:07 PM Douglas Anderson > wrote: > > > > We're supposed to list the supplies in the dt bindings but there are > > none in the eDP PHY bindings. > > > > Looking at the driver in Linux, I can see that there seem to be two > > relevant supplies: "vdda-phy" and "vdda-pll". Let's add those to the > > bindings. > > > > NOTE: from looking at the Qualcomm datasheet for sc7280, it's not > > immediately clear how to figure out how to fill in these supplies. The > > only two eDP related supplies are simply described as "power for eDP > > 0.9V circuits" and "power for eDP 1.2V circuits". From guessing and > > from comparing how a similar PHY is hooked up on other similar > > Qualcomm boards, I'll make the educated guess that the 1.2V supply > > goes to "vdda-phy" and the 0.9V supply goes to "vdda-pll" and I'll use > > that in the example here. > > > > Signed-off-by: Douglas Anderson > > --- > > > > Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml | 6 ++ > > 1 file changed, 6 insertions(+) > > Even though patch #1 in this series should be dropped, this patch > (patch #2) is still valid. Vinod: I assume this would land in your > tree along with the first two patches in Kuogee's series [1], which > are related. Please let me know if you need me to re-send or anything. I have applied this patch, thanks > [1] > https://lore.kernel.org/r/1653507433-22585-1-git-send-email-quic_khs...@quicinc.com/ This needs rebase on phy split which I have picked -- ~Vinod
Re: [PATCH v13 0/3] eDP/DP Phy vdda realted function
On 25-05-22, 14:02, Kuogee Hsieh wrote: > 1) add regulator_set_load() to eDP phy > 2) add regulator_set_load() to DP phy > 3) remove vdda related function out of eDP/DP controller > > Kuogee Hsieh (3): > phy: qcom-edp: add regulator_set_load to edp phy > phy: qcom-qmp: add regulator_set_load to dp phy > drm/msm/dp: delete vdda regulator related functions from eDP/DP > controller > > drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- > drivers/gpu/drm/msm/dp/dp_parser.h | 8 > drivers/gpu/drm/msm/dp/dp_power.c | 95 > + > drivers/phy/qualcomm/phy-qcom-edp.c | 12 + > drivers/phy/qualcomm/phy-qcom-qmp.c | 40 Please rebase this to phy-next and apply to specific qmp phy driver... -- ~Vinod
Re: [PATCH v10 17/21] phy: phy-mtk-dp: Add driver for DP phy
On 23-05-22, 12:47, Guillaume Ranquet wrote: > From: Markus Schneider-Pargmann > > This is a new driver that supports the integrated DisplayPort phy for > mediatek SoCs, especially the mt8195. The phy is integrated into the > DisplayPort controller and will be created by the mtk-dp driver. This > driver expects a struct regmap to be able to work on the same registers > as the DisplayPort controller. It sets the device data to be the struct > phy so that the DisplayPort controller can easily work with it. > > The driver does not have any devicetree bindings because the datasheet > does not list the controller and the phy as distinct units. > > The interaction with the controller can be covered by the configure > callback of the phy framework and its displayport parameters. I must admit that I have missed previous iteration of this driver. This is a standalone phy driver, pls split and submit this and we can get this merged... > > Signed-off-by: Markus Schneider-Pargmann > Signed-off-by: Guillaume Ranquet > --- > MAINTAINERS | 1 + > drivers/phy/mediatek/Kconfig | 8 ++ > drivers/phy/mediatek/Makefile | 1 + > drivers/phy/mediatek/phy-mtk-dp.c | 200 ++ > 4 files changed, 210 insertions(+) > create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4cc47b2dbdc9..bfca96469d80 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6604,6 +6604,7 @@ L: linux-media...@lists.infradead.org (moderated > for non-subscribers) > S: Supported > F: Documentation/devicetree/bindings/display/mediatek/ > F: drivers/gpu/drm/mediatek/ > +F: drivers/phy/mediatek/phy-mtk-dp.c > F: drivers/phy/mediatek/phy-mtk-hdmi* > F: drivers/phy/mediatek/phy-mtk-mipi* > > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig > index 55f8e6c048ab..f7ec86059049 100644 > --- a/drivers/phy/mediatek/Kconfig > +++ b/drivers/phy/mediatek/Kconfig > @@ -55,3 +55,11 @@ config PHY_MTK_MIPI_DSI > select GENERIC_PHY > help > Support MIPI DSI for Mediatek SoCs. > + > +config PHY_MTK_DP > + tristate "MediaTek DP-PHY Driver" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + depends on OF > + select GENERIC_PHY > + help > + Support DisplayPort PHY for Mediatek SoCs. > diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile > index ace660fbed3a..4ba1e0650434 100644 > --- a/drivers/phy/mediatek/Makefile > +++ b/drivers/phy/mediatek/Makefile > @@ -3,6 +3,7 @@ > # Makefile for the phy drivers. > # > > +obj-$(CONFIG_PHY_MTK_DP) += phy-mtk-dp.o > obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o > obj-$(CONFIG_PHY_MTK_UFS)+= phy-mtk-ufs.o > obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o > diff --git a/drivers/phy/mediatek/phy-mtk-dp.c > b/drivers/phy/mediatek/phy-mtk-dp.c > new file mode 100644 > index ..6f29854f0c2f > --- /dev/null > +++ b/drivers/phy/mediatek/phy-mtk-dp.c > @@ -0,0 +1,200 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * MediaTek DisplayPort PHY driver > + * > + * Copyright (c) 2021 BayLibre 2022 now > + * Author: Markus Schneider-Pargmann use MODULE_AUTHOR() > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PHY_OFFSET 0x1000 > + > +#define MTK_DP_PHY_DIG_PLL_CTL_1 (PHY_OFFSET + 0x14) > +#define TPLL_SSC_EN BIT(3) > + > +#define MTK_DP_PHY_DIG_BIT_RATE (PHY_OFFSET + 0x3C) > +#define BIT_RATE_RBR 0 > +#define BIT_RATE_HBR 1 > +#define BIT_RATE_HBR22 > +#define BIT_RATE_HBR33 > + > +#define MTK_DP_PHY_DIG_SW_RST(PHY_OFFSET + 0x38) > +#define DP_GLB_SW_RST_PHYD BIT(0) > + > +#define MTK_DP_LANE0_DRIVING_PARAM_3 (PHY_OFFSET + 0x138) > +#define MTK_DP_LANE1_DRIVING_PARAM_3 (PHY_OFFSET + 0x238) > +#define MTK_DP_LANE2_DRIVING_PARAM_3 (PHY_OFFSET + 0x338) > +#define MTK_DP_LANE3_DRIVING_PARAM_3 (PHY_OFFSET + 0x438) > +#define XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULTBIT(4) > +#define XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT((BIT(2) | BIT(4)) << 8) Sound like BIT(10) and BIT (12), no? > +#define XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULTGENMASK(20, 19) > +#define XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULTGENMASK(29, 29) > +#define DRIVING_PARAM_3_DEFAULT > (XTP_LN_TX_LCTXC0_SW0_PRE0_DEFAULT | \ > + > XTP_LN_TX_LCTXC0_SW0_PRE1_DEFAULT | \ > + > XTP_LN_TX_LCTXC0_SW0_PRE2_DEFAULT | \ > + > XTP_LN_TX_LCTXC0_SW0_PRE3_DEFAULT) > + > +#define XTP_LN_TX_LCTXC0_SW1_PRE0_DEFAULTGENMASK(4, 3) > +#define XTP_LN_TX_LCTXC0_SW1_PRE1_DEFAULT
[PATCH v2] drm/msm/disp/dpu1: remove superfluous init
Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
encoder") added dsc_common_mode variable which was set to zero but then
again programmed, so drop the superfluous init.
Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
Reported-by: kernel test robot
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
changes in v2:
- add r-b from Dmitry & Abhinav
- fix typo for superfluous
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 51f24ba68375..388125c8bda1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1798,7 +1798,6 @@ static void dpu_encoder_prep_dsc(struct dpu_encoder_virt
*dpu_enc,
}
}
- dsc_common_mode = 0;
pic_width = dsc->drm->pic_width;
dsc_common_mode = DSC_MODE_MULTIPLEX | DSC_MODE_SPLIT_PANEL;
--
2.34.1
[PATCH] drm/msm/disp/dpu1: remove supoerflous init
Commit 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in
encoder") added dsc_common_mode variable which was set to zero but then
again programmed, so drop the supoerflous init.
Fixes: 58dca9810749 ("drm/msm/disp/dpu1: Add support for DSC in encoder")
Reported-by: kernel test robot
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 51f24ba68375..388125c8bda1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1798,7 +1798,6 @@ static void dpu_encoder_prep_dsc(struct dpu_encoder_virt
*dpu_enc,
}
}
- dsc_common_mode = 0;
pic_width = dsc->drm->pic_width;
dsc_common_mode = DSC_MODE_MULTIPLEX | DSC_MODE_SPLIT_PANEL;
--
2.34.1
Re: [PATCH v4 2/3] phy/qualcomm: add regulator_set_load to dp phy
On 18-05-22, 14:36, Kuogee Hsieh wrote:
> This patch add regulator_set_load() before enable regulator at
> DP phy driver.
sigh! still wrong tags!
>
> Signed-off-by: Kuogee Hsieh
> Reviewed-by: Stephen Boyd
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index b144ae1..20ac446 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -3130,6 +3130,7 @@ struct qmp_phy_cfg {
> int num_resets;
> /* regulators to be requested */
> const char * const *vreg_list;
> + const unsigned int *vreg_enable_load;
> int num_vregs;
>
> /* array of registers with different offsets */
> @@ -3346,6 +3347,10 @@ static const char * const qmp_phy_vreg_l[] = {
> "vdda-phy", "vdda-pll",
> };
>
> +static const unsigned int qmp_phy_vreg_enable_load[] = {
> + 21800, 36000
> +};
> +
> static const struct qmp_phy_cfg ipq8074_usb3phy_cfg = {
> .type = PHY_TYPE_USB3,
> .nlanes = 1,
> @@ -4072,6 +4077,7 @@ static const struct qmp_phy_cfg sm8250_usb3phy_cfg = {
> .reset_list = msm8996_usb3phy_reset_l,
> .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
> .vreg_list = qmp_phy_vreg_l,
> + .vreg_enable_load = qmp_phy_vreg_enable_load,
> .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> .regs = qmp_v4_usb3phy_regs_layout,
>
> @@ -4139,6 +4145,7 @@ static const struct qmp_phy_cfg sm8250_dpphy_cfg = {
> .reset_list = msm8996_usb3phy_reset_l,
> .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
> .vreg_list = qmp_phy_vreg_l,
> + .vreg_enable_load = qmp_phy_vreg_enable_load,
> .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> .regs = qmp_v4_usb3phy_regs_layout,
>
> @@ -5008,6 +5015,11 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
> return 0;
> }
>
> + if (cfg->vreg_enable_load) {
> + for (i = cfg->num_vregs - 1; i >= 0; --i)
> + regulator_set_load(qmp->vregs[i].consumer,
> cfg->vreg_enable_load[i]);
> + }
> +
> /* turn on regulator supplies */
> ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
> if (ret) {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
~Vinod
Re: [PATCH v1 1/2] phy/qcom: add regulator_set_load to edp/dp phy
On 17-05-22, 10:25, Kuogee Hsieh wrote:
pls use the correct subsystem tag, "phy: xxx" in this case
> This patch add regulator_set_load() to both eDP and DP phy driver
> to have totally control regulators.
Can you explain what is meant by "totally control regulators"
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 25 +
> drivers/phy/qualcomm/phy-qcom-qmp.c | 24
> 2 files changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
> b/drivers/phy/qualcomm/phy-qcom-edp.c
> index cacd32f..9b55095 100644
> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> @@ -87,17 +87,24 @@ struct qcom_edp {
>
> struct clk_bulk_data clks[2];
> struct regulator_bulk_data supplies[2];
> + int enable_load[2];
> + int disable_load[2];
> };
>
> static int qcom_edp_phy_init(struct phy *phy)
> {
> struct qcom_edp *edp = phy_get_drvdata(phy);
> int ret;
> + int num_consumers = ARRAY_SIZE(edp->supplies);
> + int i;
>
> - ret = regulator_bulk_enable(ARRAY_SIZE(edp->supplies), edp->supplies);
> + ret = regulator_bulk_enable(num_consumers, edp->supplies);
> if (ret)
> return ret;
>
> + for (i = num_consumers - 1; i >= 0; --i)
> + regulator_set_load(edp->supplies[i].consumer,
> edp->enable_load[i]);
> +
> ret = clk_bulk_prepare_enable(ARRAY_SIZE(edp->clks), edp->clks);
> if (ret)
> goto out_disable_supplies;
> @@ -425,9 +432,15 @@ static int qcom_edp_phy_power_off(struct phy *phy)
> static int qcom_edp_phy_exit(struct phy *phy)
> {
> struct qcom_edp *edp = phy_get_drvdata(phy);
> + int num_consumers = ARRAY_SIZE(edp->supplies);
> + int i;
>
> clk_bulk_disable_unprepare(ARRAY_SIZE(edp->clks), edp->clks);
> - regulator_bulk_disable(ARRAY_SIZE(edp->supplies), edp->supplies);
> +
> + for (i = num_consumers - 1; i >= 0; --i)
> + regulator_set_load(edp->supplies[i].consumer,
> edp->disable_load[i]);
> +
> + regulator_bulk_disable(num_consumers, edp->supplies);
>
> return 0;
> }
> @@ -633,8 +646,12 @@ static int qcom_edp_phy_probe(struct platform_device
> *pdev)
> if (ret)
> return ret;
>
> - edp->supplies[0].supply = "vdda-phy";
> - edp->supplies[1].supply = "vdda-pll";
> + edp->supplies[0].supply = "vdda-1p2";
> + edp->supplies[1].supply = "vdda-0p9";
These are documented in bindings, so cannot be removed, Reminder binding
is an ABI
You have not documented the new names either...
> + edp->enable_load[0] = 21800;/* 1.2 V */
> + edp->enable_load[1] = 36000;/* 1.2 V */
> + edp->disable_load[0] = 4; /* 0.9 V */
> + edp->disable_load[1] = 4; /* 10.9V */
is that correct, 10.9V?
> ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(edp->supplies),
> edp->supplies);
> if (ret)
> return ret;
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index b144ae1..c589231 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
This is a different driver, so should be a different patch!
> @@ -3130,6 +3130,8 @@ struct qmp_phy_cfg {
> int num_resets;
> /* regulators to be requested */
> const char * const *vreg_list;
> + const unsigned int *vreg_enable_load;
> + const unsigned int *vreg_disable_load;
> int num_vregs;
>
> /* array of registers with different offsets */
> @@ -3346,6 +3348,14 @@ static const char * const qmp_phy_vreg_l[] = {
> "vdda-phy", "vdda-pll",
> };
>
> +static const unsigned int qmp_phy_vreg_enable_load[] = {
> + 21800, 36000
> +};
> +
> +static const unsigned int qmp_phy_vreg_disable_load[] = {
> + 4, 32
> +};
> +
> static const struct qmp_phy_cfg ipq8074_usb3phy_cfg = {
> .type = PHY_TYPE_USB3,
> .nlanes = 1,
> @@ -4072,6 +4082,8 @@ static const struct qmp_phy_cfg sm8250_usb3phy_cfg = {
> .reset_list = msm8996_usb3phy_reset_l,
> .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
> .vreg_list = qmp_phy_vreg_l,
> + .vreg_enable_load = qmp_phy_vreg_enable_load,
> + .vreg_disable_load = qmp_phy_vreg_disable_load,
> .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
> .regs = qmp_v4_usb3phy_regs_layout,
>
> @@ -4139,6 +4151,8 @@ static const struct qmp_phy_cfg sm8250_dpphy_cfg = {
> .reset_list = msm8996_usb3phy_reset_l,
> .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
> .vreg_list = qmp_phy_vreg_l,
> + .vreg_enable_load = qmp_phy_vreg_enable_load,
> + .vreg_disable_load = qmp_phy_vreg_disable_load,
> .num_vregs =
Re: [PATCH v0.5 6/9] phy: freescale: add Samsung HDMI PHY
On 06-05-22, 20:10, Lucas Stach wrote:
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/phy/freescale/Kconfig|6 +
> drivers/phy/freescale/Makefile |1 +
> drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1078 ++
> 3 files changed, 1085 insertions(+)
> create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
>
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index f9c54cd02036..e88cc2212370 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -26,6 +26,12 @@ config PHY_FSL_IMX8M_PCIE
> Enable this to add support for the PCIE PHY as found on
> i.MX8M family of SOCs.
>
> +config PHY_FSL_SAMSUNG_HDMI_PHY
> + tristate "Samsung HDMI PHY support"
> + depends on OF && HAS_IOMEM
> + help
> + Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> +
> endif
>
> config PHY_FSL_LYNX_28G
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 3518d5dbe8a7..46a26929376d 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -2,4 +2,5 @@
> obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
> obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
> obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
> obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> new file mode 100644
> index ..6d20a5ce44e6
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -0,0 +1,1078 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + * Copyright 2022 Pengutronix, Lucas Stach
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define HDMI_TX_CONTROL0 0x200
> +#define HDMI_TX_CONTROL_PHY_PWRDWN BIT(3)
> +
> +#define PHY_REG_33 0x84
> +#define REG33_MODE_SET_DONE BIT(7)
> +#define REG33_FIX_DABIT(1)
> +
> +#define PHY_REG_34 0x88
> +#define REG34_PHY_READY BIT(7)
> +#define REG34_PLL_LOCK BIT(6)
> +#define REG34_PHY_CLK_READY BIT(5)
> +
> +
> +#define PHY_PLL_REGS_NUM 48
> +
> +struct phy_config {
> + u32 clk_rate;
> + u8 regs[PHY_PLL_REGS_NUM];
> +};
> +
> +const struct phy_config phy_pll_cfg[] = {
> + { 2225, {
> + 0x00, 0xD1, 0x4B, 0xF1, 0x89, 0x88, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
So we have only opaque register values we program for each rate...? No
documentation for these registers?
Also, will these be same across different SoC and boards as well..?
Typically tuning parameters will differ for each board...
> + },
> + }, {
> + 2375, {
> + 0x00, 0xD1, 0x50, 0xF1, 0x86, 0x85, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + },{
> + 2400, {
> + 0x00, 0xD1, 0x50, 0xF0, 0x00, 0x00, 0x80, 0x00,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + },{
> + 24024000, {
> + 0x00, 0xD1, 0x50, 0xF1, 0x99, 0x02, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x00, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 25175000, {
> + 0x00, 0xD1, 0x54, 0xFC, 0xCC, 0x91, 0x80, 0x40,
> +
Re: [Freedreno] [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
On 02-05-22, 10:43, Marijn Suijten wrote: > On 2022-05-02 01:44:20, Dmitry Baryshkov wrote: > that require DSC for the screen to work. I've been told the series > didn't result in positive screen output way back in its infancy, but I would be intrested to hear about that. I have only pixel3 at my disposal so tested on that. I would be willing to help with more testing efforts. Also, to get DSC to work, the panel needs to be set as well... > I'll re-evaluate and send fixes or improvements if/when necessary. That would be nice -- ~Vinod
Re: [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
On 01-05-22, 22:41, Marijn Suijten wrote:
> On 2022-04-30 22:28:42, Dmitry Baryshkov wrote:
> > On 30/04/2022 21:58, Marijn Suijten wrote:
> > > On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
> > >> The downstream uses read-modify-write for updating command mode
> > >> compression registers. Let's follow this approach. This also fixes the
> > >> following warning:
> > >>
> > >> drivers/gpu/drm/msm/dsi/dsi_host.c:918:23: warning: variable 'reg_ctrl'
> > >> set but not used [-Wunused-but-set-variable]
> > >>
> > >> Reported-by: kernel test robot
> > >> Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
> > >> Signed-off-by: Dmitry Baryshkov
> > >
> > > I pointed this out in review multiple times, so you'll obviously get my:
> >
> > I think I might have also pointed this out once (and then forgot to
> > check that the issue was fixed by Vinod).
> >
> > >
> > > Reviewed-by: Marijn Suijten
> > >
> > > (But are you sure there's nothing else to clear in the 1st CTRL
> > > register, only the lowest 16 bits? That should mean `reg` never
> > > contains anything in 0x)
> >
> > Judging from the downstream the upper half conains the same fields, but
> > used for other virtual channel. I didn't research what's the difference
> > yet. All the dtsi files that I have here at hand use
> > 'qcom,mdss-dsi-virtual-channel-id = <0>;'
>
> As replied to Abhinav I'm simply asking whether we should be strict
> and add `reg & 0x` to prevent accidentally writing the top 16 bits,
> which are stream 1. It doesn't seem like the current code can hit that
> though, with all the macros using masks internally already; but it's
Since the macros were used I skipped setting that up explictly...
> still a little scary since we're assuming the registers for VIDEO are
> identical to CMD (as mentioned in the reply to Abhinav: I wonder if it's
The documentation seems to indicate they are similar and that is the
reason, I merged the code paths and set different registers required for
video and cmd modes
--
~Vinod
Re: [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
On 30-04-22, 22:28, Dmitry Baryshkov wrote:
> On 30/04/2022 21:58, Marijn Suijten wrote:
> > On 2022-04-30 20:55:33, Dmitry Baryshkov wrote:
> > > The downstream uses read-modify-write for updating command mode
> > > compression registers. Let's follow this approach. This also fixes the
> > > following warning:
> > >
> > > drivers/gpu/drm/msm/dsi/dsi_host.c:918:23: warning: variable 'reg_ctrl'
> > > set but not used [-Wunused-but-set-variable]
> > >
> > > Reported-by: kernel test robot
> > > Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
> > > Signed-off-by: Dmitry Baryshkov
> >
> > I pointed this out in review multiple times, so you'll obviously get my:
>
> I think I might have also pointed this out once (and then forgot to check
> that the issue was fixed by Vinod).
I think i have tried to reply to all comments, if anything was missed
that would be my mistake..
> > Reviewed-by: Marijn Suijten
> >
> > (But are you sure there's nothing else to clear in the 1st CTRL
> > register, only the lowest 16 bits? That should mean `reg` never
> > contains anything in 0x)
>
> Judging from the downstream the upper half conains the same fields, but used
> for other virtual channel. I didn't research what's the difference yet. All
> the dtsi files that I have here at hand use
> 'qcom,mdss-dsi-virtual-channel-id = <0>;'
Yes the register description is for STREAM1 in documentation, it is
unclear to me when that can be used
--
~Vinod
Re: [Freedreno] [PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
On 30-04-22, 20:55, Dmitry Baryshkov wrote: > The downstream uses read-modify-write for updating command mode > compression registers. Let's follow this approach. This also fixes the > following warning: > > drivers/gpu/drm/msm/dsi/dsi_host.c:918:23: warning: variable 'reg_ctrl' set > but not used [-Wunused-but-set-variable] Reviewed-by: Vinod Koul Tested on pixel3: Tested-by: Vinod Koul -- ~Vinod
Re: [PATCH 0/3] drm: move dsc data pointer from drm_panel to mipi_dsi_device
On 01-05-22, 18:12, Dmitry Baryshkov wrote:
> To properly support DSC the sink driver (panel) has to pass DSC pps data
> to the source (DSI host). The commit 0f40ba48de3b ("drm/msm/dsi: Pass
> DSC params to drm_panel") added a pointer to the DSC data to the struct
> drm_panel. However this is not the ideal solution.
>
> First, this leaves DSC-supporting DSI sink bridges (like ANX7625 which
> support DSC decoding on the MIPI DSI inputs).
>
> Second, this does not play well with the panel_bridge. Drivers depending
> solely on the bridge chains will still have to lookup panel and fetch
> data from it.
>
> Last, but not least, the DSC data is not relevant for the wide variety
> of panels including DPI and LVDS panels.
>
> To solve all these problems, move struct drm_dsc_config pointer from
> struct drm_panel to struct mipi_host_device. This way MIPI DSI host
> driver receives DSC data during attach callback without additional
> lookups.
Reviewed-by: Vinod Koul
I tested this on my pixel3 and had to change how panel driver handles
this, with that it worked just fine
Tested-by: Vinod Koul
--
~Vinod
Re: [PATCH] dt-bindings: Drop redundant 'maxItems/minItems' in if/then schemas
On 03-05-22, 11:27, Rob Herring wrote: > Another round of removing redundant minItems/maxItems when 'items' list is > specified. This time it is in if/then schemas as the meta-schema was > failing to check this case. > > If a property has an 'items' list, then a 'minItems' or 'maxItems' with the > same size as the list is redundant and can be dropped. Note that is DT > schema specific behavior and not standard json-schema behavior. The tooling > will fixup the final schema adding any unspecified minItems/maxItems. For phy: Acked-By: Vinod Koul -- ~Vinod
Re: [PATCH 20/41] dma: omap: hide legacy interface
On 19-04-22, 15:37, Arnd Bergmann wrote: > From: Arnd Bergmann > > The legacy interface for omap-dma is only used on OMAP1, and the > same is true for the non-DT case. Make both of these conditional on > CONFIG_ARCH_OMAP1 being set to simplify the dependency. Acked-By: Vinod Koul -- ~Vinod
Re: [PATCH resend v8 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
On 19-04-22, 09:08, Liu Ying wrote: > Hi, > > This is the v8 series to add i.MX8qxp LVDS PHY mode support for the Mixel > PHY in the Freescale i.MX8qxp SoC. > > The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either > MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp > SCU firmware. The PHY driver would call a SCU function to configure the > mode. > > The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, > where it appears to be a single MIPI DPHY. > > > Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller > bridge driver, since i.MX8qxp SoC embeds this controller IP to support > MIPI DSI displays together with the Mixel PHY. > > Patch 2/5 allows LVDS PHYs to be configured through the generic PHY functions > and through a custom structure added to the generic PHY configuration union. > > Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema. > > Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. > > Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. Applied patch 2-5 to phy-next, thanks -- ~Vinod
Re: [PATCH] drm/msm/dsi: fixup DSC support for the cases when there is no pannel attached
On 20-04-22, 00:37, Dmitry Baryshkov wrote: > Unable to handle kernel paging request at virtual address fe2b ... > > Signed-off-by: Dmitry Baryshkov > --- > > Note: I'm going to squash this fix into the respective patch from the > DSC series Thanks this looks good to me: Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH v6 resend 2/5] phy: Add LVDS configuration options
On 13-04-22, 20:39, Liu Ying wrote: > On Wed, 2022-04-13 at 16:19 +0530, Vinod Koul wrote: > > On 13-04-22, 18:04, Liu Ying wrote: > > > Hi Vinod, > > > > > > On Wed, 2022-04-13 at 11:41 +0530, Vinod Koul wrote: > > > > On 02-04-22, 13:24, Liu Ying wrote: > > > > > This patch allows LVDS PHYs to be configured through > > > > > the generic functions and through a custom structure > > > > > added to the generic union. > > > > > > > > > > The parameters added here are based on common LVDS PHY > > > > > implementation practices. The set of parameters > > > > > should cover all potential users. > > > > > > > > > > Cc: Kishon Vijay Abraham I > > > > > Cc: Vinod Koul > > > > > Cc: NXP Linux Team > > > > > Signed-off-by: Liu Ying > > > > > --- > > [...] > > > > > > + */ > > > > > + > > > > > +#ifndef __PHY_LVDS_H_ > > > > > +#define __PHY_LVDS_H_ > > > > > + > > > > > +/** > > > > > + * struct phy_configure_opts_lvds - LVDS configuration set > > > > > + * @bits_per_lane_and_dclk_cycle:Number of bits per data > > > > > lane > > > > > and > > > > > + * differential clock > > > > > cycle. > > > > > > > > What does it mean by bits per data lane and differential clock > > > > cycle? > > > > > > Please check > > > Documentation/devicetree/bindings/display/panel/lvds.yaml. > > > lvds.yaml metions slot. 'bits_per_lane_and_dclk_cycle' means the > > > number of slots. But, I don't find the word 'slot' in my lvds > > > relevant > > > specs which mentioned in lvds.yaml, so 'slots' is probably not a > > > generic name(lvds.yaml is for display panel). So, I use > > > 'bits_per_lane_and_dclk_cycle' as the name tells what it means. > > > > variable name is fine, explanation for bit per lane and differential > > clock cycle didnt help, maybe add better explanation of what this > > variable means > > I may add an example diagram as below... Not really a diagram, you can add if you like.. But something which explains in a sentence or few about the variable. bits per lane per differential clock cycle ? -- ~Vinod
Re: [PATCH v6 resend 2/5] phy: Add LVDS configuration options
On 13-04-22, 18:04, Liu Ying wrote:
> Hi Vinod,
>
> On Wed, 2022-04-13 at 11:41 +0530, Vinod Koul wrote:
> > On 02-04-22, 13:24, Liu Ying wrote:
> > > This patch allows LVDS PHYs to be configured through
> > > the generic functions and through a custom structure
> > > added to the generic union.
> > >
> > > The parameters added here are based on common LVDS PHY
> > > implementation practices. The set of parameters
> > > should cover all potential users.
> > >
> > > Cc: Kishon Vijay Abraham I
> > > Cc: Vinod Koul
> > > Cc: NXP Linux Team
> > > Signed-off-by: Liu Ying
> > > ---
> > > v5->v6:
> > > * Rebase upon v5.17-rc1.
> > >
> > > v4->v5:
> > > * Align kernel-doc style to include/linux/phy/phy.h. (Vinod)
> > > * Trivial tweaks.
> > > * Drop Robert's R-b tag.
> > >
> > > v3->v4:
> > > * Add Robert's R-b tag.
> > >
> > > v2->v3:
> > > * No change.
> > >
> > > v1->v2:
> > > * No change.
> > >
> > > include/linux/phy/phy-lvds.h | 32
> > > include/linux/phy/phy.h | 4
> > > 2 files changed, 36 insertions(+)
> > > create mode 100644 include/linux/phy/phy-lvds.h
> > >
> > > diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-
> > > lvds.h
> > > new file mode 100644
> > > index ..7a2f4747f624
> > > --- /dev/null
> > > +++ b/include/linux/phy/phy-lvds.h
> > > @@ -0,0 +1,32 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Copyright 2020 NXP
> >
> > 2022 now
>
> I may change it to 'Copyright 2020,2022 NXP'.
>
> >
> > > + */
> > > +
> > > +#ifndef __PHY_LVDS_H_
> > > +#define __PHY_LVDS_H_
> > > +
> > > +/**
> > > + * struct phy_configure_opts_lvds - LVDS configuration set
> > > + * @bits_per_lane_and_dclk_cycle:Number of bits per data lane
> > > and
> > > + * differential clock cycle.
> >
> > What does it mean by bits per data lane and differential clock cycle?
>
> Please check Documentation/devicetree/bindings/display/panel/lvds.yaml.
> lvds.yaml metions slot. 'bits_per_lane_and_dclk_cycle' means the
> number of slots. But, I don't find the word 'slot' in my lvds relevant
> specs which mentioned in lvds.yaml, so 'slots' is probably not a
> generic name(lvds.yaml is for display panel). So, I use
> 'bits_per_lane_and_dclk_cycle' as the name tells what it means.
variable name is fine, explanation for bit per lane and differential
clock cycle didnt help, maybe add better explanation of what this
variable means
>
> >
> > > + * @differential_clk_rate: Clock rate, in Hertz, of the
> > > LVDS
> > > + * differential clock.
> > > + * @lanes: Number of active, consecutive,
> > > + * data lanes, starting from lane
> > > 0,
> > > + * used for the transmissions.
> > > + * @is_slave:Boolean, true if the
> > > phy is a slave
> > > + * which works together with a
> > > master
> > > + * phy to support dual link
> > > transmission,
> > > + * otherwise a regular phy or a
> > > master phy.
> > > + *
> > > + * This structure is used to represent the configuration state of
> > > a LVDS phy.
> > > + */
> > > +struct phy_configure_opts_lvds {
> > > + unsigned intbits_per_lane_and_dclk_cycle;
> > > + unsigned long differential_clk_rate;
> > > + unsigned intlanes;
> > > + boolis_slave;
> > > +};
> >
> > Where is the user of this new configuration? Can you post that patch
> > for
> > reference as well please
>
> Patch 5/5 uses it. Also, I posted two drm bridge drivers[1][2] which
> use it.
That is phy driver not the user
>
> [1]
> https://patchwork.kernel.org/project/dri-devel/patch/1617172405-12962-13-git-send-email-victor@nxp.com/
> [2]
> https://patchwork.kernel.org/project/dri-devel/patch/1617172405-12962-14-git-send-email-victor@nxp.com/
this is helpful, thanks
--
~Vinod
Re: [PATCH v2] phy: mediatek: phy-mtk-mipi-dsi: Simplify with dev_err_probe()
On 28-03-22, 16:52, AngeloGioacchino Del Regno wrote: > Use the dev_err_probe() helper to simplify error handling during probe. Applied, thanks -- ~Vinod
Re: [PATCH] phy: mediatek: phy-mtk-hdmi: Simplify with dev_err_probe()
On 28-03-22, 13:10, AngeloGioacchino Del Regno wrote: > Use the dev_err_probe() helper to simplify error handling during probe. Applied, thanks -- ~Vinod
Re: [PATCH v6 resend 5/5] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
On 02-04-22, 13:24, Liu Ying wrote:
> i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> by SCU firmware and the driver would call a SCU firmware function to
> configure the PHY mode. The single LVDS PHY has 4 data lanes to support
> a LVDS display. Also, with a master LVDS PHY and a slave LVDS PHY, they
> may work together to support a LVDS display with 8 data lanes(usually, dual
> LVDS link display). Note that this patch supports the LVDS PHY mode only
> for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> supported, so for now error would be returned from ->set_mode() if MIPI
> DPHY mode is passed over to it for the combo PHY.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Reviewed-by: Guido Günther
> Signed-off-by: Liu Ying
> ---
> v5->v6:
> * No change.
>
> v4->v5:
> * No change.
>
> v3->v4:
> * Add Guido's R-b tag.
>
> v2->v3:
> * Improve readability of mixel_dphy_set_mode(). (Guido)
>
> v1->v2:
> * Print invalid PHY mode in dmesg. (Guido)
>
> .../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 269 +-
> 1 file changed, 258 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index a95572b397ca..af1ecda091c7 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -4,17 +4,31 @@
> * Copyright 2019 Purism SPC
> */
>
> +#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> +
> +/* Control and Status Registers(CSR) */
> +#define PHY_CTRL 0x00
> +#define CCM_MASKGENMASK(7, 5)
> +#define CCM(n) FIELD_PREP(CCM_MASK, (n))
> +#define CA_MASK GENMASK(4, 2)
> +#define CA(n) FIELD_PREP(CA_MASK, (n))
> +#define RFB BIT(1)
> +#define LVDS_EN BIT(0)
>
> /* DPHY registers */
> #define DPHY_PD_DPHY 0x00
> @@ -55,8 +69,15 @@
> #define PWR_ON 0
> #define PWR_OFF 1
>
> +#define MIN_VCO_FREQ 64000
> +#define MAX_VCO_FREQ 15
> +
> +#define MIN_LVDS_REFCLK_FREQ 2400
> +#define MAX_LVDS_REFCLK_FREQ 15000
> +
> enum mixel_dphy_devtype {
> MIXEL_IMX8MQ,
> + MIXEL_IMX8QXP,
> };
>
> struct mixel_dphy_devdata {
> @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> u8 reg_rxlprp;
> u8 reg_rxcdrp;
> u8 reg_rxhs_settle;
> + bool is_combo; /* MIPI DPHY and LVDS PHY combo */
> };
>
> static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata
> mixel_dphy_devdata[] = {
> .reg_rxlprp = 0x40,
> .reg_rxcdrp = 0x44,
> .reg_rxhs_settle = 0x48,
> + .is_combo = false,
> + },
> + [MIXEL_IMX8QXP] = {
> + .is_combo = true,
> },
> };
>
> @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> struct mixel_dphy_priv {
> struct mixel_dphy_cfg cfg;
> struct regmap *regmap;
> + struct regmap *lvds_regmap;
> struct clk *phy_ref_clk;
> const struct mixel_dphy_devdata *devdata;
> + struct imx_sc_ipc *ipc_handle;
> + bool is_slave;
> + int id;
> };
>
> static const struct regmap_config mixel_dphy_regmap_config = {
> @@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
> return 0;
> }
>
> -static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts
> *opts)
> +static int
> +mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts
> *opts)
Please dont change things like this.. A patch should do only one thing :)
> {
> struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> struct mixel_dphy_cfg cfg = { 0 };
> @@ -345,15 +376,121 @@ static int mixel_dphy_configure(struct phy *phy, union
> phy_configure_opts *opts)
> return 0;
> }
>
> +static int
> +mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts
> *opts)
> +{
> + struct mixel_dphy_priv *p
Re: [PATCH v6 resend 2/5] phy: Add LVDS configuration options
On 02-04-22, 13:24, Liu Ying wrote:
> This patch allows LVDS PHYs to be configured through
> the generic functions and through a custom structure
> added to the generic union.
>
> The parameters added here are based on common LVDS PHY
> implementation practices. The set of parameters
> should cover all potential users.
>
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> v5->v6:
> * Rebase upon v5.17-rc1.
>
> v4->v5:
> * Align kernel-doc style to include/linux/phy/phy.h. (Vinod)
> * Trivial tweaks.
> * Drop Robert's R-b tag.
>
> v3->v4:
> * Add Robert's R-b tag.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * No change.
>
> include/linux/phy/phy-lvds.h | 32
> include/linux/phy/phy.h | 4
> 2 files changed, 36 insertions(+)
> create mode 100644 include/linux/phy/phy-lvds.h
>
> diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
> new file mode 100644
> index ..7a2f4747f624
> --- /dev/null
> +++ b/include/linux/phy/phy-lvds.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2020 NXP
2022 now
> + */
> +
> +#ifndef __PHY_LVDS_H_
> +#define __PHY_LVDS_H_
> +
> +/**
> + * struct phy_configure_opts_lvds - LVDS configuration set
> + * @bits_per_lane_and_dclk_cycle:Number of bits per data lane and
> + * differential clock cycle.
What does it mean by bits per data lane and differential clock cycle?
> + * @differential_clk_rate: Clock rate, in Hertz, of the LVDS
> + * differential clock.
> + * @lanes: Number of active, consecutive,
> + * data lanes, starting from lane 0,
> + * used for the transmissions.
> + * @is_slave:Boolean, true if the phy is a
> slave
> + * which works together with a master
> + * phy to support dual link transmission,
> + * otherwise a regular phy or a master phy.
> + *
> + * This structure is used to represent the configuration state of a LVDS phy.
> + */
> +struct phy_configure_opts_lvds {
> + unsigned intbits_per_lane_and_dclk_cycle;
> + unsigned long differential_clk_rate;
> + unsigned intlanes;
> + boolis_slave;
> +};
Where is the user of this new configuration? Can you post that patch for
reference as well please
--
~Vinod
[PATCH v7 14/14] drm/msm/dsi: Add support for DSC configuration
When DSC is enabled, we need to configure DSI registers accordingly and
configure the respective stream compression registers.
Add support to calculate the register setting based on DSC params and
timing information and configure these registers.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index eb0be34add45..f3ed6c40b9e1 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -912,6 +912,65 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host,
bool enable,
dsi_write(msm_host, REG_DSI_CPHY_MODE_CTRL, BIT(0));
}
+static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool
is_cmd_mode, u32 hdisplay)
+{
+ struct msm_display_dsc_config *dsc = msm_host->dsc;
+ u32 reg, intf_width, reg_ctrl, reg_ctrl2;
+ u32 slice_per_intf, total_bytes_per_intf;
+ u32 pkt_per_line;
+ u32 bytes_in_slice;
+ u32 eol_byte_num;
+
+ /* first calculate dsc parameters and then program
+* compress mode registers
+*/
+ intf_width = hdisplay;
+ slice_per_intf = DIV_ROUND_UP(intf_width, dsc->drm->slice_width);
+
+ /* If slice_per_pkt is greater than slice_per_intf
+* then default to 1. This can happen during partial
+* update.
+*/
+ if (slice_per_intf > dsc->drm->slice_count)
+ dsc->drm->slice_count = 1;
+
+ slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->drm->slice_width);
+ bytes_in_slice = DIV_ROUND_UP(dsc->drm->slice_width *
dsc->drm->bits_per_pixel, 8);
+
+ dsc->drm->slice_chunk_size = bytes_in_slice;
+
+ total_bytes_per_intf = bytes_in_slice * slice_per_intf;
+
+ eol_byte_num = total_bytes_per_intf % 3;
+ pkt_per_line = slice_per_intf / dsc->drm->slice_count;
+
+ if (is_cmd_mode) /* packet data type */
+ reg =
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(MIPI_DSI_DCS_LONG_WRITE);
+ else
+ reg =
DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE(MIPI_DSI_COMPRESSED_PIXEL_STREAM);
+
+ /* DSI_VIDEO_COMPRESSION_MODE & DSI_COMMAND_COMPRESSION_MODE
+* registers have similar offsets, so for below common code use
+* DSI_VIDEO_COMPRESSION_MODE_ for setting bits
+*/
+ reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE(pkt_per_line >> 1);
+ reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM(eol_byte_num);
+ reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_EN;
+
+ if (is_cmd_mode) {
+ reg_ctrl = dsi_read(msm_host,
REG_DSI_COMMAND_COMPRESSION_MODE_CTRL);
+ reg_ctrl2 = dsi_read(msm_host,
REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2);
+
+ reg_ctrl |= reg;
+ reg_ctrl2 |=
DSI_COMMAND_COMPRESSION_MODE_CTRL2_STREAM0_SLICE_WIDTH(bytes_in_slice);
+
+ dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL, reg);
+ dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2,
reg_ctrl2);
+ } else {
+ dsi_write(msm_host, REG_DSI_VIDEO_COMPRESSION_MODE_CTRL, reg);
+ }
+}
+
static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
{
struct drm_display_mode *mode = msm_host->mode;
@@ -944,7 +1003,38 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
hdisplay /= 2;
}
+ if (msm_host->dsc) {
+ struct msm_display_dsc_config *dsc = msm_host->dsc;
+
+ /* update dsc params with timing params */
+ if (!dsc || !mode->hdisplay || !mode->vdisplay) {
+ pr_err("DSI: invalid input: pic_width: %d pic_height:
%d\n",
+ mode->hdisplay, mode->vdisplay);
+ return;
+ }
+
+ dsc->drm->pic_width = mode->hdisplay;
+ dsc->drm->pic_height = mode->vdisplay;
+ DBG("Mode %dx%d\n", dsc->drm->pic_width, dsc->drm->pic_height);
+
+ /* we do the calculations for dsc parameters here so that
+* panel can use these parameters
+*/
+ dsi_populate_dsc_params(dsc);
+
+ /* Divide the display by 3 but keep back/font porch and
+* pulse width same
+*/
+ h_total -= hdisplay;
+ hdisplay /= 3;
+ h_total += hdisplay;
+ ha_end = ha_start + hdisplay;
+ }
+
if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) {
+ if (msm_hos
[PATCH v7 13/14] drm/msm: Update generated headers
Update headers from mesa commit:
commit 28ae397be111c37c6ced397e12d453a7695701bd
Author: Vinod Koul
Date: Fri Apr 1 16:53:04 2022 +0530
freedreno/registers: update dsi registers to support dsc
Display Stream compression (DSC) compresses the display stream in
host which is later decoded by panel. This requires addition of 3 new
DSI registers to support DSC over DSI.
Signed-off-by: Vinod Koul
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14967>
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 80 +++
1 file changed, 80 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 4dee6f0bdda6..d1b2a17b0a66 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -704,5 +704,85 @@ static inline uint32_t DSI_VERSION_MAJOR(uint32_t val)
#define REG_DSI_CPHY_MODE_CTRL 0x02d4
+#define REG_DSI_VIDEO_COMPRESSION_MODE_CTRL0x029c
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__MASK 0x
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__SHIFT 16
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_WC(uint32_t val)
+{
+ return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__SHIFT) &
DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__MASK 0x3f00
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__SHIFT8
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE(uint32_t val)
+{
+ return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__SHIFT) &
DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__MASK 0x00c0
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__SHIFT6
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE(uint32_t
val)
+{
+ return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__SHIFT) &
DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__MASK 0x0030
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__SHIFT4
+static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM(uint32_t
val)
+{
+ return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__SHIFT) &
DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__MASK;
+}
+#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EN 0x0001
+
+#define REG_DSI_COMMAND_COMPRESSION_MODE_CTRL 0x02a4
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__MASK
0x3f00
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__SHIFT 24
+static inline uint32_t
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE(uint32_t val)
+{
+ return ((val) <<
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__SHIFT) &
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__MASK
0x00c0
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__SHIFT 22
+static inline uint32_t
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE(uint32_t val)
+{
+ return ((val) <<
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__SHIFT) &
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__MASK
0x0030
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__SHIFT 20
+static inline uint32_t
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM(uint32_t val)
+{
+ return ((val) <<
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__SHIFT) &
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EN 0x0001
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__MASK
0x3f00
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__SHIFT 8
+static inline uint32_t
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(uint32_t val)
+{
+ return ((val) <<
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__SHIFT) &
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__MASK
0x00c0
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__SHIFT 6
+static inline uint32_t
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE(uint32_t val)
+{
+ return ((val) <<
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__SHIFT) &
DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__MASK;
+}
+#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_EOL_BYTE_NUM__MASK
0x0030
+
[PATCH v7 12/14] drm/msm/dsi: add mode valid callback for dsi_mgr
Add a mode valid callback for dsi_mgr for checking mode being valid in
case of DSC. For DSC the height and width needs to be multiple of slice,
so we check that here
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 26 ++
drivers/gpu/drm/msm/dsi/dsi_manager.c | 12
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 16cd9b2fce86..580a1e6358bf 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -114,6 +114,8 @@ int msm_dsi_host_power_on(struct mipi_dsi_host *host,
int msm_dsi_host_power_off(struct mipi_dsi_host *host);
int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
const struct drm_display_mode *mode);
+enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
+ const struct drm_display_mode
*mode);
struct drm_panel *msm_dsi_host_get_panel(struct mipi_dsi_host *host);
unsigned long msm_dsi_host_get_mode_flags(struct mipi_dsi_host *host);
struct drm_bridge *msm_dsi_host_get_bridge(struct mipi_dsi_host *host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index cb2e179127ea..eb0be34add45 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -2554,6 +2554,32 @@ int msm_dsi_host_set_display_mode(struct mipi_dsi_host
*host,
return 0;
}
+enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
+ const struct drm_display_mode *mode)
+{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+ struct msm_display_dsc_config *dsc = msm_host->dsc;
+ int pic_width = mode->hdisplay;
+ int pic_height = mode->vdisplay;
+
+ if (!msm_host->dsc)
+ return MODE_OK;
+
+ if (pic_width % dsc->drm->slice_width) {
+ pr_err("DSI: pic_width %d has to be multiple of slice %d\n",
+ pic_width, dsc->drm->slice_width);
+ return MODE_H_ILLEGAL;
+ }
+
+ if (pic_height % dsc->drm->slice_height) {
+ pr_err("DSI: pic_height %d has to be multiple of slice %d\n",
+ pic_height, dsc->drm->slice_height);
+ return MODE_V_ILLEGAL;
+ }
+
+ return MODE_OK;
+}
+
struct drm_panel *msm_dsi_host_get_panel(struct mipi_dsi_host *host)
{
return of_drm_find_panel(to_msm_dsi_host(host)->device_node);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 0c1b7dde377c..100a8fcbddee 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -573,6 +573,17 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge
*bridge,
dsi_mgr_bridge_power_on(bridge);
}
+static enum drm_mode_status dsi_mgr_bridge_mode_valid(struct drm_bridge
*bridge,
+ const struct
drm_display_info *info,
+ const struct
drm_display_mode *mode)
+{
+ int id = dsi_mgr_bridge_get_id(bridge);
+ struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+ struct mipi_dsi_host *host = msm_dsi->host;
+
+ return msm_dsi_host_check_dsc(host, mode);
+}
+
static const struct drm_connector_funcs dsi_mgr_connector_funcs = {
.detect = dsi_mgr_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -593,6 +604,7 @@ static const struct drm_bridge_funcs dsi_mgr_bridge_funcs =
{
.disable = dsi_mgr_bridge_disable,
.post_disable = dsi_mgr_bridge_post_disable,
.mode_set = dsi_mgr_bridge_mode_set,
+ .mode_valid = dsi_mgr_bridge_mode_valid,
};
/* initialize connector when we're connected to a drm_panel */
--
2.34.1
[PATCH v7 11/14] drm/msm/disp/dpu1: Add DSC support in RM
This add the bits in RM to enable the DSC blocks
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 56 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 1 +
3 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 779e7bd01efd..a41f0eb2761b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -145,6 +145,7 @@ struct dpu_global_state {
uint32_t mixer_to_enc_id[LM_MAX - LM_0];
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
+ uint32_t dsc_to_enc_id[DSC_MAX - DSC_0];
};
struct dpu_global_state
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 7497538adae1..0e6634b217aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -11,6 +11,7 @@
#include "dpu_hw_intf.h"
#include "dpu_hw_dspp.h"
#include "dpu_hw_merge3d.h"
+#include "dpu_hw_dsc.h"
#include "dpu_encoder.h"
#include "dpu_trace.h"
@@ -77,6 +78,15 @@ int dpu_rm_destroy(struct dpu_rm *rm)
for (i = 0; i < ARRAY_SIZE(rm->hw_intf); i++)
dpu_hw_intf_destroy(rm->hw_intf[i]);
+ for (i = 0; i < ARRAY_SIZE(rm->dsc_blks); i++) {
+ struct dpu_hw_dsc *hw;
+
+ if (rm->dsc_blks[i]) {
+ hw = to_dpu_hw_dsc(rm->dsc_blks[i]);
+ dpu_hw_dsc_destroy(hw);
+ }
+ }
+
return 0;
}
@@ -210,6 +220,19 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->dspp_blks[dspp->id - DSPP_0] = >base;
}
+ for (i = 0; i < cat->dsc_count; i++) {
+ struct dpu_hw_dsc *hw;
+ const struct dpu_dsc_cfg *dsc = >dsc[i];
+
+ hw = dpu_hw_dsc_init(dsc->id, mmio, cat);
+ if (IS_ERR_OR_NULL(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed dsc object creation: err %d\n", rc);
+ goto fail;
+ }
+ rm->dsc_blks[dsc->id - DSC_0] = >base;
+ }
+
return 0;
fail:
@@ -441,6 +464,28 @@ static int _dpu_rm_reserve_ctls(
return 0;
}
+static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
+ struct dpu_global_state *global_state,
+ struct drm_encoder *enc,
+ const struct msm_display_topology *top)
+{
+ int num_dsc = top->num_dsc;
+ int i;
+
+ /* check if DSC required are allocated or not */
+ for (i = 0; i < num_dsc; i++) {
+ if (global_state->dsc_to_enc_id[i]) {
+ DPU_ERROR("DSC %d is already allocated\n", i);
+ return -EIO;
+ }
+ }
+
+ for (i = 0; i < num_dsc; i++)
+ global_state->dsc_to_enc_id[i] = enc->base.id;
+
+ return 0;
+}
+
static int _dpu_rm_make_reservation(
struct dpu_rm *rm,
struct dpu_global_state *global_state,
@@ -462,6 +507,10 @@ static int _dpu_rm_make_reservation(
return ret;
}
+ ret = _dpu_rm_reserve_dsc(rm, global_state, enc, >topology);
+ if (ret)
+ return ret;
+
return ret;
}
@@ -499,6 +548,8 @@ void dpu_rm_release(struct dpu_global_state *global_state,
ARRAY_SIZE(global_state->mixer_to_enc_id), enc->base.id);
_dpu_rm_clear_mapping(global_state->ctl_to_enc_id,
ARRAY_SIZE(global_state->ctl_to_enc_id), enc->base.id);
+ _dpu_rm_clear_mapping(global_state->dsc_to_enc_id,
+ ARRAY_SIZE(global_state->dsc_to_enc_id), enc->base.id);
}
int dpu_rm_reserve(
@@ -567,6 +618,11 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
hw_to_enc_id = global_state->dspp_to_enc_id;
max_blks = ARRAY_SIZE(rm->dspp_blks);
break;
+ case DPU_HW_BLK_DSC:
+ hw_blks = rm->dsc_blks;
+ hw_to_enc_id = global_state->dsc_to_enc_id;
+ max_blks = ARRAY_SIZE(rm->dsc_blks);
+ break;
default:
DPU_ERROR("blk type %d not managed by rm\n", type);
return 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 9b13200a050a..32e0d8aa65ab 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -28,6 +28,7 @@ struct dpu_rm {
struct dpu_hw_intf *hw_i
[PATCH v7 10/14] drm/msm/disp/dpu1: Add support for DSC in topology
For DSC to work we typically need a 2,2,1 configuration. This should
suffice for resolutions up to 4k. For more resolutions like 8k this won't
work.
Also, it is better to use 2 LMs and DSC instances as half width results
in lesser power consumption as compared to single LM, DSC at full width.
The panel has been tested only with 2,2,1 configuration, so for
now we blindly create 2,2,1 topology when DSC is enabled
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 +
drivers/gpu/drm/msm/msm_drv.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 95d1588f3bb6..51f24ba68375 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -567,8 +567,21 @@ static struct msm_display_topology
dpu_encoder_get_topology(
topology.num_enc = 0;
topology.num_intf = intf_count;
+ if (dpu_enc->dsc) {
+ /* In case of Display Stream Compression (DSC), we would use
+* 2 encoders, 2 layer mixers and 1 interface
+* this is power optimal and can drive up to (including) 4k
+* screens
+*/
+ topology.num_enc = 2;
+ topology.num_dsc = 2;
+ topology.num_intf = 1;
+ topology.num_lm = 2;
+ }
+
return topology;
}
+
static int dpu_encoder_virt_atomic_check(
struct drm_encoder *drm_enc,
struct drm_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index bf2ccff97562..0ace9b0549a4 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -103,12 +103,14 @@ enum msm_event_wait {
* @num_enc: number of compression encoder blocks used
* @num_intf: number of interfaces the panel is mounted on
* @num_dspp: number of dspp blocks used
+ * @num_dsc: number of Display Stream Compression (DSC) blocks used
*/
struct msm_display_topology {
u32 num_lm;
u32 num_enc;
u32 num_intf;
u32 num_dspp;
+ u32 num_dsc;
};
/* Commit/Event thread specific structure */
--
2.34.1
[PATCH v7 09/14] drm/msm: Add missing num_dspp field documentation
Somehow documentation for num_dspp was missed, so add that
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/msm_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 2a3280df7b12..bf2ccff97562 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -102,6 +102,7 @@ enum msm_event_wait {
* @num_lm: number of layer mixers used
* @num_enc: number of compression encoder blocks used
* @num_intf: number of interfaces the panel is mounted on
+ * @num_dspp: number of dspp blocks used
*/
struct msm_display_topology {
u32 num_lm;
--
2.34.1
[PATCH v7 08/14] drm/msm/dpu: don't use merge_3d if DSC merge topology is used
From: Dmitry Baryshkov
DPU supports different topologies for the case when multiple INTFs are
being driven by the single phys_enc. The driver defaults to using 3DMux
in such cases. Don't use it if DSC merge is used instead.
Suggested-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +++-
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4052486f19d8..95d1588f3bb6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -511,6 +511,22 @@ void dpu_encoder_helper_split_config(
}
}
+bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
+{
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+ int i, intf_count = 0, num_dsc = 0;
+
+ for (i = 0; i < MAX_PHYS_ENCODERS_PER_VIRTUAL; i++)
+ if (dpu_enc->phys_encs[i])
+ intf_count++;
+
+ /* See dpu_encoder_get_topology, we only support 2:2:1 topology */
+ if (dpu_enc->dsc)
+ num_dsc = 2;
+
+ return (num_dsc > 0) && (num_dsc > intf_count);
+}
+
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index ef873e5285a0..084c5265d7e5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -172,4 +172,10 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc);
*/
int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
+/**
+ * dpu_encoder_use_dsc_merge - returns true if the encoder uses DSC merge
topology.
+ * @drm_enc:Pointer to previously created drm encoder structure
+ */
+bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc);
+
#endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 4842070fdfa8..b5ad43b8a19b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -314,8 +314,10 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
dpu_cstate = to_dpu_crtc_state(phys_enc->parent->crtc->state);
+ /* Use merge_3d unless DSC MERGE topology is used */
if (phys_enc->split_role == ENC_ROLE_SOLO &&
- dpu_cstate->num_mixers == CRTC_DUAL_MIXERS)
+ dpu_cstate->num_mixers == CRTC_DUAL_MIXERS &&
+ !dpu_encoder_use_dsc_merge(phys_enc->parent))
return BLEND_3D_H_ROW_INT;
return BLEND_3D_NONE;
--
2.34.1
[PATCH v7 07/14] drm/msm/disp/dpu1: Add support for DSC in encoder
We need to configure the encoder for DSC configuration and calculate DSC
parameters for the given timing so this patch adds that support by
adding dpu_encoder_prep_dsc() which is invoked when DSC is enabled.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 128 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 8 ++
2 files changed, 135 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 3940b9c6323b..4052486f19d8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -21,6 +21,7 @@
#include "dpu_hw_intf.h"
#include "dpu_hw_ctl.h"
#include "dpu_hw_dspp.h"
+#include "dpu_hw_dsc.h"
#include "dpu_formats.h"
#include "dpu_encoder_phys.h"
#include "dpu_crtc.h"
@@ -135,6 +136,8 @@ enum dpu_enc_rc_states {
* @cur_slave: As above but for the slave encoder.
* @hw_pp: Handle to the pingpong blocks used for the display. No.
* pingpong blocks can be different than num_phys_encs.
+ * @hw_dsc:Handle to the DSC blocks used for the display.
+ * @dsc_mask: Bitmask of used DSC blocks.
* @intfs_swapped: Whether or not the phys_enc interfaces have been swapped
* for partial update right-only cases, such as pingpong
* split where virtual pingpong does not generate IRQs
@@ -168,6 +171,7 @@ enum dpu_enc_rc_states {
* @vsync_event_work: worker to handle vsync event for autorefresh
* @topology: topology of the display
* @idle_timeout: idle timeout duration in milliseconds
+ * @dsc: msm_display_dsc_config pointer, for DSC-enabled
encoders
*/
struct dpu_encoder_virt {
struct drm_encoder base;
@@ -180,6 +184,9 @@ struct dpu_encoder_virt {
struct dpu_encoder_phys *cur_master;
struct dpu_encoder_phys *cur_slave;
struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
+ struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
+
+ unsigned int dsc_mask;
bool intfs_swapped;
@@ -206,6 +213,9 @@ struct dpu_encoder_virt {
struct msm_display_topology topology;
u32 idle_timeout;
+
+ /* DSC configuration */
+ struct msm_display_dsc_config *dsc;
};
#define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)
@@ -942,7 +952,9 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
- int num_lm, num_ctl, num_pp;
+ struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
+ int num_lm, num_ctl, num_pp, num_dsc;
+ unsigned int dsc_mask = 0;
int i;
if (!drm_enc) {
@@ -980,6 +992,18 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
: NULL;
+ if (dpu_enc->dsc) {
+ num_dsc = dpu_rm_get_assigned_resources(_kms->rm,
global_state,
+ drm_enc->base.id,
DPU_HW_BLK_DSC,
+ hw_dsc,
ARRAY_SIZE(hw_dsc));
+ for (i = 0; i < num_dsc; i++) {
+ dpu_enc->hw_dsc[i] = to_dpu_hw_dsc(hw_dsc[i]);
+ dsc_mask |= BIT(dpu_enc->hw_dsc[i]->idx - DSC_0);
+ }
+ }
+
+ dpu_enc->dsc_mask = dsc_mask;
+
cstate = to_dpu_crtc_state(crtc_state);
for (i = 0; i < num_lm; i++) {
@@ -1677,6 +1701,95 @@ static void dpu_encoder_vsync_event_work_handler(struct
kthread_work *work)
nsecs_to_jiffies(ktime_to_ns(wakeup_time)));
}
+static u32
+dpu_encoder_dsc_initial_line_calc(struct msm_display_dsc_config *dsc,
+ u32 enc_ip_width)
+{
+ int ssm_delay, total_pixels, soft_slice_per_enc;
+
+ soft_slice_per_enc = enc_ip_width / dsc->drm->slice_width;
+
+ /*
+* minimum number of initial line pixels is a sum of:
+* 1. sub-stream multiplexer delay (83 groups for 8bpc,
+*91 for 10 bpc) * 3
+* 2. for two soft slice cases, add extra sub-stream multiplexer * 3
+* 3. the initial xmit delay
+* 4. total pipeline delay through the "lock step" of encoder (47)
+* 5. 6 additional pixels as the output of the rate buffer is
+*48 bits wide
+*/
+ ssm_delay = ((dsc->drm->bits_per_component &
[PATCH v7 06/14] drm/msm/disp/dpu1: Add DSC support in hw_ctl
Later gens of hardware have DSC bits moved to hw_ctl, so configure these
bits so that DSC would work there as well
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 11 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 3584f5ee6bb3..dc27579bb5f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -25,6 +25,8 @@
#define CTL_MERGE_3D_ACTIVE 0x0E4
#define CTL_INTF_ACTIVE 0x0F4
#define CTL_MERGE_3D_FLUSH0x100
+#define CTL_DSC_ACTIVE0x0E8
+#define CTL_DSC_FLUSH0x104
#define CTL_INTF_FLUSH0x110
#define CTL_INTF_MASTER 0x134
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
@@ -34,6 +36,7 @@
#define DPU_REG_RESET_TIMEOUT_US2000
#define MERGE_3D_IDX 23
+#define DSC_IDX22
#define INTF_IDX 31
#define CTL_INVALID_BIT 0x
#define CTL_DEFAULT_GROUP_ID 0xf
@@ -126,7 +129,6 @@ static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl
*ctx)
static inline void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
{
-
if (ctx->pending_flush_mask & BIT(MERGE_3D_IDX))
DPU_REG_WRITE(>hw, CTL_MERGE_3D_FLUSH,
ctx->pending_merge_3d_flush_mask);
@@ -511,6 +513,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
mode_sel = CTL_DEFAULT_GROUP_ID << 28;
+ if (cfg->dsc)
+ DPU_REG_WRITE(>hw, CTL_DSC_FLUSH, cfg->dsc);
+
if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
mode_sel |= BIT(17);
@@ -522,6 +527,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
+ if (cfg->dsc) {
+ DPU_REG_WRITE(>hw, CTL_FLUSH, DSC_IDX);
+ DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
+ }
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ac1544474022..97f326dff0af 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -40,6 +40,7 @@ struct dpu_hw_stage_cfg {
* @merge_3d: 3d merge block used
* @intf_mode_sel: Interface mode, cmd / vid
* @stream_sel:Stream selection for multi-stream interfaces
+ * @dsc: DSC BIT masks used
*/
struct dpu_hw_intf_cfg {
enum dpu_intf intf;
@@ -47,6 +48,7 @@ struct dpu_hw_intf_cfg {
enum dpu_merge_3d merge_3d;
enum dpu_ctl_mode_sel intf_mode_sel;
int stream_sel;
+ unsigned int dsc;
};
/**
--
2.34.1
[PATCH v7 05/14] drm/msm/disp/dpu1: Add DSC for SDM845 to hw_catalog
This adds SDM845 DSC blocks into hw_catalog
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
Signed-off-by: Vinod Koul
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77cddfea..d15fa5845066 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -1117,6 +1117,24 @@ static const struct dpu_pingpong_cfg sc7280_pp[] = {
PP_BLK("pingpong_2", PINGPONG_2, 0x6b000, 0, sc7280_pp_sblk, -1, -1),
PP_BLK("pingpong_3", PINGPONG_3, 0x6c000, 0, sc7280_pp_sblk, -1, -1),
};
+
+/*
+ * DSC sub blocks config
+ */
+#define DSC_BLK(_name, _id, _base) \
+ {\
+ .name = _name, .id = _id, \
+ .base = _base, .len = 0x140, \
+ .features = 0, \
+ }
+
+static struct dpu_dsc_cfg sdm845_dsc[] = {
+ DSC_BLK("dsc_0", DSC_0, 0x8),
+ DSC_BLK("dsc_1", DSC_1, 0x80400),
+ DSC_BLK("dsc_2", DSC_2, 0x80800),
+ DSC_BLK("dsc_3", DSC_3, 0x80c00),
+};
+
/*
* INTF sub blocks config
*/
@@ -1643,6 +1661,8 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
.mixer = sdm845_lm,
.pingpong_count = ARRAY_SIZE(sdm845_pp),
.pingpong = sdm845_pp,
+ .dsc_count = ARRAY_SIZE(sdm845_dsc),
+ .dsc = sdm845_dsc,
.intf_count = ARRAY_SIZE(sdm845_intf),
.intf = sdm845_intf,
.vbif_count = ARRAY_SIZE(sdm845_vbif),
--
2.34.1
