Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
Hi Adam, On Tue, Mar 26, 2024 at 06:43:26AM -0500, Adam Ford wrote: > On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai > wrote: > > > > Hi Laurent, > > > > On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote: > > > Hi Tommaso, > > > > > > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote: > > > > Hi Adam, Lucas, > > > > Thanks for this series. > > > > > > > > This series make HDMI work on evk. > > > > All is working properly on my side. > > > > > > > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1. > > > > Hope this help. > > > > > > > > Tested-by: Tommaso Merciai > > > > > > The DRM side has been merged already. The only missing patches are for > > > the PHY, and the latest version can be found in > > > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford...@gmail.com/. > > > You can test that series and send a Tested-by tag. I'm crossing my > > > fingers and hoping it will be merged in v6.10. > > (same here :) ) > > > > Thanks for sharing! :) > > > > To be honest I test all this series rebasing my alvium next branch on top > > of media_stage/master (6.9.0-rc1) > > All is working properly on my side. > > I found v8 into the commit msg here: > > https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford...@gmail.com/ > > then I'm thinking this is the latest. > > > > I'm going to switch to your suggestion that looks more recent :) > > Sorry about the confusion. I was confused by the versioning too when > I pulled from different parts of Lucas' stuff. Since varying > components were applied at different times, and the remaining part was > based on the wrong starting point and not applied, I reverted back to > the versioning of the PHY which was the only remaining part other than > device tree stuff. No problem, thanks for clarify :) Thanks & Regards, Tommaso > > adam > > > > Thanks again, > > Tommaso > > > > > > > > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote: > > > > > The i.MX8M Plus has an HDMI controller, but it depends on two > > > > > other systems, the Parallel Video Interface (PVI) and the > > > > > HDMI PHY from Samsung. The LCDIF controller generates the display > > > > > and routes it to the PVI which converts passes the parallel video > > > > > to the HDMI bridge. The HDMI system has a corresponding power > > > > > domain controller whose driver was partially written, but the > > > > > device tree for it was never applied, so some changes to the > > > > > power domain should be harmless because they've not really been > > > > > used yet. > > > > > > > > > > This series is adapted from multiple series from Lucas Stach with > > > > > edits and suggestions from feedback from various series, but it > > > > > since it's difficult to use and test them independently, > > > > > I merged them into on unified series. The version history is a > > > > > bit ambiguous since different components were submitted at different > > > > > times and had different amount of retries. In an effort to merge them > > > > > I used the highest version attempt. > > > > > > > > > > Adam Ford (3): > > > > > dt-bindings: soc: imx: add missing clock and power-domains to > > > > > imx8mp-hdmi-blk-ctrl > > > > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix > > > > > domain > > > > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module > > > > > > > > > > Lucas Stach (9): > > > > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > > > > > phy: freescale: add Samsung HDMI PHY > > > > > arm64: dts: imx8mp: add HDMI power-domains > > > > > arm64: dts: imx8mp: add HDMI irqsteer > > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > > > > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface > > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > > > > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI > > > > > arm64: dts: imx8mp: add HDMI display pipeline > > > > > > > > > > .../display/bridge/fsl,imx8mp-
Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
Hi Laurent, On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote: > Hi Tommaso, > > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote: > > Hi Adam, Lucas, > > Thanks for this series. > > > > This series make HDMI work on evk. > > All is working properly on my side. > > > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1. > > Hope this help. > > > > Tested-by: Tommaso Merciai > > The DRM side has been merged already. The only missing patches are for > the PHY, and the latest version can be found in > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford...@gmail.com/. > You can test that series and send a Tested-by tag. I'm crossing my > fingers and hoping it will be merged in v6.10. (same here :) ) Thanks for sharing! :) To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1) All is working properly on my side. I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford...@gmail.com/ then I'm thinking this is the latest. I'm going to switch to your suggestion that looks more recent :) Thanks again, Tommaso > > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote: > > > The i.MX8M Plus has an HDMI controller, but it depends on two > > > other systems, the Parallel Video Interface (PVI) and the > > > HDMI PHY from Samsung. The LCDIF controller generates the display > > > and routes it to the PVI which converts passes the parallel video > > > to the HDMI bridge. The HDMI system has a corresponding power > > > domain controller whose driver was partially written, but the > > > device tree for it was never applied, so some changes to the > > > power domain should be harmless because they've not really been > > > used yet. > > > > > > This series is adapted from multiple series from Lucas Stach with > > > edits and suggestions from feedback from various series, but it > > > since it's difficult to use and test them independently, > > > I merged them into on unified series. The version history is a > > > bit ambiguous since different components were submitted at different > > > times and had different amount of retries. In an effort to merge them > > > I used the highest version attempt. > > > > > > Adam Ford (3): > > > dt-bindings: soc: imx: add missing clock and power-domains to > > > imx8mp-hdmi-blk-ctrl > > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix > > > domain > > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module > > > > > > Lucas Stach (9): > > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > > > phy: freescale: add Samsung HDMI PHY > > > arm64: dts: imx8mp: add HDMI power-domains > > > arm64: dts: imx8mp: add HDMI irqsteer > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI > > > arm64: dts: imx8mp: add HDMI display pipeline > > > > > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++ > > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++ > > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + > > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +- > > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++ > > > arch/arm64/configs/defconfig |1 + > > > drivers/gpu/drm/bridge/imx/Kconfig| 18 + > > > drivers/gpu/drm/bridge/imx/Makefile |2 + > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 > > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++ > > > drivers/phy/freescale/Kconfig |6 + > > > drivers/phy/freescale/Makefile|1 + > > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 + > > > drivers/pmdomain/imx/imx8mp-blk-ctrl.c| 10 +- > > > 14 files changed, 1876 insertions(+), 13 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c > > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c > > -- > Regards, > > Laurent Pinchart
Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
Hi Adam, Lucas, Thanks for this series. This series make HDMI work on evk. All is working properly on my side. Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1. Hope this help. Tested-by: Tommaso Merciai Thanks & Regards, Tommaso On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote: > The i.MX8M Plus has an HDMI controller, but it depends on two > other systems, the Parallel Video Interface (PVI) and the > HDMI PHY from Samsung. The LCDIF controller generates the display > and routes it to the PVI which converts passes the parallel video > to the HDMI bridge. The HDMI system has a corresponding power > domain controller whose driver was partially written, but the > device tree for it was never applied, so some changes to the > power domain should be harmless because they've not really been > used yet. > > This series is adapted from multiple series from Lucas Stach with > edits and suggestions from feedback from various series, but it > since it's difficult to use and test them independently, > I merged them into on unified series. The version history is a > bit ambiguous since different components were submitted at different > times and had different amount of retries. In an effort to merge them > I used the highest version attempt. > > Adam Ford (3): > dt-bindings: soc: imx: add missing clock and power-domains to > imx8mp-hdmi-blk-ctrl > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix > domain > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module > > Lucas Stach (9): > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > phy: freescale: add Samsung HDMI PHY > arm64: dts: imx8mp: add HDMI power-domains > arm64: dts: imx8mp: add HDMI irqsteer > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI > arm64: dts: imx8mp: add HDMI display pipeline > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++ > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++ > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +- > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++ > arch/arm64/configs/defconfig |1 + > drivers/gpu/drm/bridge/imx/Kconfig| 18 + > drivers/gpu/drm/bridge/imx/Makefile |2 + > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++ > drivers/phy/freescale/Kconfig |6 + > drivers/phy/freescale/Makefile|1 + > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 + > drivers/pmdomain/imx/imx8mp-blk-ctrl.c| 10 +- > 14 files changed, 1876 insertions(+), 13 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml > create mode 100644 > Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c > > -- > 2.43.0 > >
Re: [PATCH v0.5 0/9] i.MX8MP HDMI support
Hello Lucas, On Fri, May 06, 2022 at 08:10:25PM +0200, Lucas Stach wrote: > Hi all, > > second round of the i.MX8MP HDMI work. Still not split up into proper > parts for merging through the various trees this needs to go into, but > should make it easy for people to test. > > I've worked in the feedback I got from the last round, including fixing > the system hang that could happen when the drivers were built as modules. > > Series is based on linux-next/master, as there are some prerequisite > patches in both the drm and imx tree already. The last patch from [1] > and the patches from [2] need to be applied. Please note that this series > expects the sync polarity from the LCDIF to be set according to the > comments I made in [2]. Please test and provide feedback. > > Regards, > Lucas I tested your series on Linux 6.2.0-rc8 Tested-by: Tommaso Merciai Thanks for your work! Regards, Tommaso > > [1] > https://lore.kernel.org/all/20220406153402.1265474-1-l.st...@pengutronix.de/ > [2] https://lore.kernel.org/all/20220322142853.125880-1-ma...@denx.de/ > > Lucas Stach (9): > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > drm/imx: add bridge wrapper driver for i.MX8MP DWC HDMI > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > drm/imx: add driver for HDMI TX Parallel Video Interface > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > phy: freescale: add Samsung HDMI PHY > arm64: dts: imx8mp: add HDMI irqsteer > arm64: dts: imx8mp: add HDMI display pipeline > arm64: dts: imx8mp-evk: enable HDMI > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 83 ++ > .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 73 ++ > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + > arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 19 + > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 94 ++ > drivers/gpu/drm/imx/Kconfig |1 + > drivers/gpu/drm/imx/Makefile |2 + > drivers/gpu/drm/imx/bridge/Kconfig| 18 + > drivers/gpu/drm/imx/bridge/Makefile |4 + > drivers/gpu/drm/imx/bridge/imx-hdmi-pvi.c | 201 +++ > drivers/gpu/drm/imx/bridge/imx-hdmi.c | 141 +++ > drivers/phy/freescale/Kconfig |6 + > drivers/phy/freescale/Makefile|1 + > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1078 + > 14 files changed, 1783 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi.yaml > create mode 100644 > Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml > create mode 100644 drivers/gpu/drm/imx/bridge/Kconfig > create mode 100644 drivers/gpu/drm/imx/bridge/Makefile > create mode 100644 drivers/gpu/drm/imx/bridge/imx-hdmi-pvi.c > create mode 100644 drivers/gpu/drm/imx/bridge/imx-hdmi.c > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c > > -- > 2.30.2 > >
Re: [PATCH] dma-buf: A collection of typo and documentation fixes
Hi T.J,
On Wed, Nov 23, 2022 at 07:35:18PM +, T.J. Mercier wrote:
> I've been collecting these typo fixes for a while and it feels like
> time to send them in.
>
> Signed-off-by: T.J. Mercier
> ---
> drivers/dma-buf/dma-buf.c | 14 +++---
> include/linux/dma-buf.h | 6 +++---
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index dd0f83ee505b..614ccd208af4 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1141,7 +1141,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, DMA_BUF);
> *
> * @dmabuf: [in]buffer which is moving
> *
> - * Informs all attachmenst that they need to destroy and recreated all their
> + * Informs all attachments that they need to destroy and recreate all their
> * mappings.
> */
> void dma_buf_move_notify(struct dma_buf *dmabuf)
> @@ -1159,11 +1159,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
> /**
> * DOC: cpu access
> *
> - * There are mutliple reasons for supporting CPU access to a dma buffer
> object:
> + * There are multiple reasons for supporting CPU access to a dma buffer
> object:
> *
> * - Fallback operations in the kernel, for example when a device is
> connected
> * over USB and the kernel needs to shuffle the data around first before
> - * sending it away. Cache coherency is handled by braketing any
> transactions
> + * sending it away. Cache coherency is handled by bracketing any
> transactions
> * with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
> * access.
> *
> @@ -1190,7 +1190,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
> * replace ION buffers mmap support was needed.
> *
> * There is no special interfaces, userspace simply calls mmap on the
> dma-buf
> - * fd. But like for CPU access there's a need to braket the actual access,
> + * fd. But like for CPU access there's a need to bracket the actual access,
> * which is handled by the ioctl (DMA_BUF_IOCTL_SYNC). Note that
> * DMA_BUF_IOCTL_SYNC can fail with -EAGAIN or -EINTR, in which case it
> must
> * be restarted.
> @@ -1264,10 +1264,10 @@ static int __dma_buf_begin_cpu_access(struct dma_buf
> *dmabuf,
> * preparations. Coherency is only guaranteed in the specified range for the
> * specified access direction.
> * @dmabuf: [in]buffer to prepare cpu access for.
> - * @direction: [in]length of range for cpu access.
> + * @direction: [in]direction of access.
> *
> * After the cpu access is complete the caller should call
> - * dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls
> is
> + * dma_buf_end_cpu_access(). Only when cpu access is bracketed by both calls
> is
> * it guaranteed to be coherent with other DMA access.
> *
> * This function will also wait for any DMA transactions tracked through
> @@ -1307,7 +1307,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_begin_cpu_access, DMA_BUF);
> * actions. Coherency is only guaranteed in the specified range for the
> * specified access direction.
> * @dmabuf: [in]buffer to complete cpu access for.
> - * @direction: [in]length of range for cpu access.
> + * @direction: [in]direction of access.
> *
> * This terminates CPU access started with dma_buf_begin_cpu_access().
> *
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 71731796c8c3..1d61a4f6db35 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -330,7 +330,7 @@ struct dma_buf {
>* @lock:
>*
>* Used internally to serialize list manipulation, attach/detach and
> - * vmap/unmap. Note that in many cases this is superseeded by
> + * vmap/unmap. Note that in many cases this is superseded by
>* dma_resv_lock() on @resv.
>*/
> struct mutex lock;
> @@ -365,7 +365,7 @@ struct dma_buf {
>*/
> const char *name;
>
> - /** @name_lock: Spinlock to protect name acces for read access. */
> + /** @name_lock: Spinlock to protect name access for read access. */
> spinlock_t name_lock;
>
> /**
> @@ -402,7 +402,7 @@ struct dma_buf {
>* anything the userspace API considers write access.
>*
>* - Drivers may just always add a write fence, since that only
> - * causes unecessarily synchronization, but no correctness issues.
> + * causes unnecessary synchronization, but no correctness issues.
>*
>* - Some drivers only expose a synchronous userspace API with no
>* pipelining across driv
Re: [PATCH] i2c: qcom-geni: fix error return code in geni_i2c_gpi_xfer
Hi Wang,
On Mon, Nov 21, 2022 at 06:17:52PM +0800, Wang Yufen wrote:
> Fix to return a negative error code from the gi2c->err instead of
> 0.
>
> Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
> Signed-off-by: Wang Yufen
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 84a7751..8fce98b 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -626,7 +626,6 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c,
> struct i2c_msg msgs[], i
> dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d
> addr:0x%x\n",
> gi2c->cur->flags, gi2c->cur->addr);
> gi2c->err = -ETIMEDOUT;
> - goto err;
Looks good to me.
Reviewed-by: Tommaso Merciai
Regards,
Tommaso
> }
>
> if (gi2c->err) {
> --
> 1.8.3.1
>
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 2/2] drm/tiny: add support for tft displays based on ilitek,ili9488
On Tue, Oct 18, 2022 at 08:31:22PM +0200, Michael Nazzareno Trimarchi wrote: Hi Michael, > Hi > > On Tue, Oct 18, 2022 at 6:46 PM Tommaso Merciai > wrote: > > > > This adds support for ilitek,ili9488 based displays with shift register > > in front of controller. Waveshare,pico-restouch-lcd-3.5 are such displays > > > > Signed-off-by: Tommaso Merciai > > --- > > Because I start to make it working this driver, I think that my > signed-off is missing here Yes, right. :) I upload in v2, my bad > > > drivers/gpu/drm/tiny/Kconfig | 13 + > > drivers/gpu/drm/tiny/Makefile | 1 + > > drivers/gpu/drm/tiny/ili9488.c | 440 + > > 3 files changed, 454 insertions(+) > > create mode 100644 drivers/gpu/drm/tiny/ili9488.c > > > > diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig > > index 027cd87c3d0d7..6e708e8414806 100644 > > --- a/drivers/gpu/drm/tiny/Kconfig > > +++ b/drivers/gpu/drm/tiny/Kconfig > > @@ -148,6 +148,19 @@ config TINYDRM_ILI9486 > > > > If M is selected the module will be called ili9486. > > > > +config TINYDRM_ILI9488 > > + tristate "DRM support for ILI9488 display panels" > > + depends on DRM && SPI > > + select DRM_KMS_HELPER > > + select DRM_GEM_CMA_HELPER > > + select DRM_MIPI_DBI > > + select BACKLIGHT_CLASS_DEVICE > > + help > > + DRM driver for the following Ilitek ILI9488 panels: > > + * LCD 3.5" 320x480 TFT (Waveshare Pico-ResTouch-LCD-3.5") > > + > > + If M is selected the module will be called ili9486. > > + > > config TINYDRM_MI0283QT > > tristate "DRM support for MI0283QT" > > depends on DRM && SPI > > diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile > > index 1d9d6227e7ab7..aad6683b2ac40 100644 > > --- a/drivers/gpu/drm/tiny/Makefile > > +++ b/drivers/gpu/drm/tiny/Makefile > > @@ -11,6 +11,7 @@ obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o > > obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o > > obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o > > obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o > > +obj-$(CONFIG_TINYDRM_ILI9488) += ili9488.o > > obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o > > obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o > > obj-$(CONFIG_TINYDRM_ST7586) += st7586.o > > diff --git a/drivers/gpu/drm/tiny/ili9488.c b/drivers/gpu/drm/tiny/ili9488.c > > new file mode 100644 > > index 0..b94d9d4ff4544 > > --- /dev/null > > +++ b/drivers/gpu/drm/tiny/ili9488.c > > @@ -0,0 +1,440 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * DRM driver for Ilitek ILI9488 panels > > + * > > + * Copyright 2020 Kamlesh Gurudasani > > + */ > > Code was changed a bit so please add copyright of me and you Agree, thanks. > > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define ILI9488_VCOM_CONTROL_1 0xC5 > > +#define ILI9488_COLUMN_ADDRESS_SET 0x2A > > +#define ILI9488_PAGE_ADDRESS_SET 0x2B > > +#define ILI9488_MEMORY_WRITE 0x2C > > +#define ILI9488_POSITIVE_GAMMA_CORRECTION 0xE0 > > +#define ILI9488_NEGATIVE_GAMMA_CORRECTION 0xE1 > > +#define ILI9488_POWER_CONTROL_10xC0 > > +#define ILI9488_POWER_CONTROL_20xC1 > > +#define ILI9488_POWER_CONTROL_30xC2 > > +#define ILI9488_MEM_ACCESS_CONTROL 0x36 > > +#define ILI9488_COLMOD_PIXEL_FORMAT_SET0x3A > > +#define ILI9488_INTERFACE_MODE_CONTROL 0xB0 > > +#define ILI9488_FRAME_RATE_CONTROL_PARTIAL 0xB3 > > +#define ILI9488_DISPLAY_INVERSION_ON 0x21 > > +#define ILI9488_DISPLAY_INVERSION_CONTROL 0xB4 > > +#define ILI9488_DISPLAY_FUNCTION_CONTROL 0xB6 > > +#define ILI9488_ENTRY_MODE_SET 0xB7 > > +#define ILI9488_HS_LANES_CONTROL 0xBE > > +#define ILI9488_SET_IMAGE_FUNCTION 0xE9 > > +#define ILI9488_ADJUS
[PATCH 2/2] drm/tiny: add support for tft displays based on ilitek, ili9488
This adds support for ilitek,ili9488 based displays with shift register
in front of controller. Waveshare,pico-restouch-lcd-3.5 are such displays
Signed-off-by: Tommaso Merciai
---
drivers/gpu/drm/tiny/Kconfig | 13 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9488.c | 440 +
3 files changed, 454 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9488.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 027cd87c3d0d7..6e708e8414806 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -148,6 +148,19 @@ config TINYDRM_ILI9486
If M is selected the module will be called ili9486.
+config TINYDRM_ILI9488
+ tristate "DRM support for ILI9488 display panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9488 panels:
+ * LCD 3.5" 320x480 TFT (Waveshare Pico-ResTouch-LCD-3.5")
+
+ If M is selected the module will be called ili9486.
+
config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 1d9d6227e7ab7..aad6683b2ac40 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
+obj-$(CONFIG_TINYDRM_ILI9488) += ili9488.o
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
diff --git a/drivers/gpu/drm/tiny/ili9488.c b/drivers/gpu/drm/tiny/ili9488.c
new file mode 100644
index 0..b94d9d4ff4544
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9488.c
@@ -0,0 +1,440 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9488 panels
+ *
+ * Copyright 2020 Kamlesh Gurudasani
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9488_VCOM_CONTROL_1 0xC5
+#define ILI9488_COLUMN_ADDRESS_SET 0x2A
+#define ILI9488_PAGE_ADDRESS_SET 0x2B
+#define ILI9488_MEMORY_WRITE 0x2C
+#define ILI9488_POSITIVE_GAMMA_CORRECTION 0xE0
+#define ILI9488_NEGATIVE_GAMMA_CORRECTION 0xE1
+#define ILI9488_POWER_CONTROL_10xC0
+#define ILI9488_POWER_CONTROL_20xC1
+#define ILI9488_POWER_CONTROL_30xC2
+#define ILI9488_MEM_ACCESS_CONTROL 0x36
+#define ILI9488_COLMOD_PIXEL_FORMAT_SET0x3A
+#define ILI9488_INTERFACE_MODE_CONTROL 0xB0
+#define ILI9488_FRAME_RATE_CONTROL_PARTIAL 0xB3
+#define ILI9488_DISPLAY_INVERSION_ON 0x21
+#define ILI9488_DISPLAY_INVERSION_CONTROL 0xB4
+#define ILI9488_DISPLAY_FUNCTION_CONTROL 0xB6
+#define ILI9488_ENTRY_MODE_SET 0xB7
+#define ILI9488_HS_LANES_CONTROL 0xBE
+#define ILI9488_SET_IMAGE_FUNCTION 0xE9
+#define ILI9488_ADJUST_CONTROL_3 0xF7
+#define ILI9488_DISPLAY_ON 0x29
+#define ILI9488_DISPLAY_OFF0x28
+#define ILI9488_ENTER_SLEEP_MODE 0x10
+#define ILI9488_DBI_BPP18 0x06
+#define ILI9488_DBI_BPP16 0x05
+#define ILI9488_DPI_BPP24 0x70
+#define ILI9488_DPI_BPP18 0x60
+#define ILI9488_DPI_BPP16 0x50
+#define ILI9488_FRAME_RATE_CONTROL_NORMAL 0xB1
+#define ILI9488_SLEEP_OUT 0x11
+
+#define ILI9488_MADCTL_RGB BIT(2)
+#define ILI9488_MADCTL_BGR BIT(3)
+#define ILI9488_MADCTL_MV BIT(5)
+#define ILI9488_MADCTL_MX BIT(6)
+#define ILI9488_MADCTL_MY BIT(7)
+
+static void ili9488_rgb565_to_rgb666_line(u8 *dst, u16 *sbuf,
+ unsigned int pixels)
+{
+ unsigned int x;
+
+ for (x = 0; x < pixels; x++) {
+ *dst++ = ((*sbuf & 0xF800) >> 8);
+ *dst++ = ((*sbuf & 0x07E0) >> 3);
+ *dst++ = ((*sbuf & 0x001F) << 3);
+ sbuf++;
+ }
+}
+
+static void ili9488_rgb565_to_rgb666(u8 *dst, void *vaddr,
+struct drm_framebuffer *fb,
+struct drm_rect *rect)
+{
+ unsigned long linepixels = drm_rect_width(rect);
+ unsig
[PATCH 1/2] dt-bindings: add binding for tft displays based on ilitek, ili9488
This binding is for the tft displays based on ilitek,ili9488.
waveshare,waveshare,pico-rt-lcd-35 (waveshare pico-restouch-lcd-3.5)
Signed-off-by: Tommaso Merciai
---
.../bindings/display/ilitek,ili9488.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
b/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
new file mode 100644
index 0..879ecc42c350c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9488.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ilitek,ili9488.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9488 display panels device tree bindings
+
+maintainers:
+ - Kamlesh Gurudasani
+ - Michael Trimarchi
+ - Tommaso Merciai
+
+description:
+ This binding is for display panels using an Ilitek ILI9488 controller in SPI
+ mode.
+
+allOf:
+ - $ref: panel/panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ # Waveshare 3.5" 320x480 Color TFT LCD
+ - "waveshare,pico-rt-lcd-35"
+ - const: ilitek,ili9488
+
+ spi-max-frequency:
+maximum: 2000
+
+ dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+ backlight: true
+ reg: true
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - dc-gpios
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+backlight: backlight {
+compatible = "gpio-backlight";
+gpios = < 22 GPIO_ACTIVE_HIGH>;
+};
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+
+display@0{
+compatible = "waveshare,pico-rt-lcd-35", "ilitek,ili9488";
+reg = <0>;
+spi-max-frequency = <2000>;
+dc-gpios = < 24 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 25 GPIO_ACTIVE_HIGH>;
+backlight = <>;
+};
+};
+
+...
--
2.25.1
[PATCH 0/2] drm/tiny: add support tft display based on ilitek, ili9488
Hi All, This series support for ilitek,ili9488 based displays like Waveshare-ResTouch-LCD-3.5 display. Tested on Waveshare-ResTouch-LCD-3.5 connected to px30-evb via SPI. This series is based on work done by Kamlesh Gurudasani in 2020: - "drm/tiny: add support for tft displays based on ilitek, ili9488" (Thanks Kamlesh for your starting point) Tests are done using the following tools coming from Yocto fs: - modetest -M "ili9488" -s 31:320x480@RG16 -v - fb-test - fb-rect References: - https://patchwork.kernel.org/project/dri-devel/patch/00719f68aca488a6476b0dda634617606b592823.1592055494.git.kamlesh.gurudas...@gmail.com/ - https://www.hpinfotech.ro/ILI9488.pdf - https://www.waveshare.com/wiki/Pico-ResTouch-LCD-3.5 Regards, Tommaso Tommaso Merciai (2): dt-bindings: add binding for tft displays based on ilitek,ili9488 drm/tiny: add support for tft displays based on ilitek,ili9488 .../bindings/display/ilitek,ili9488.yaml | 72 +++ drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9488.c| 440 ++ 4 files changed, 526 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9488.yaml create mode 100644 drivers/gpu/drm/tiny/ili9488.c -- 2.25.1
[PATCH] drm/amdgpu: initialize r variable into amdgpu_cs_submit function
The builds of arm64 allmodconfig with clang failed to build next-20220920 with the following result: 1190:3: error: variable 'r' is uninitialized when used here [-Werror,-Wuninitialized] note: initialize the variable 'r' to silence this warning This fix compilation error Signed-off-by: Tommaso Merciai --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 58088c663125..efa3dc9b69fd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1168,7 +1168,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, struct amdgpu_bo_list_entry *e; struct amdgpu_job *job; uint64_t seq; - int r; + int r = 0; job = p->job; p->job = NULL; -- 2.25.1
Re: [PATCH] drm/amdgpu: initialize r variable into amdgpu_cs_submit function
Hi Christian, On Tue, Sep 20, 2022 at 02:23:58PM +0200, Christian König wrote: > Am 20.09.22 um 14:22 schrieb Tommaso Merciai: > > The builds of arm64 allmodconfig with clang failed to build > > next-20220920 with the following result: > > > > 1190:3: error: variable 'r' is uninitialized when used here > > [-Werror,-Wuninitialized] > > note: initialize the variable 'r' to silence this warning > > > > This fix compilation error > > I've already send a patch to fix this to the mailing list 7 Minutes ago :) > > Please review or ack that one. Sorry, my bad. Don't see your patch :) Cheers, Tommaso > > Thanks, > Christian. > > > > > Signed-off-by: Tommaso Merciai > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > index 58088c663125..efa3dc9b69fd 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > @@ -1168,7 +1168,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser > > *p, > > struct amdgpu_bo_list_entry *e; > > struct amdgpu_job *job; > > uint64_t seq; > > - int r; > > + int r = 0; > > job = p->job; > > p->job = NULL; > -- Tommaso Merciai Embedded Linux Engineer tommaso.merc...@amarulasolutions.com __ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH v2] drm/nouveau/bios: Rename prom_init() and friends functions
On Sat, Mar 19, 2022 at 11:27:51AM +0100, Christophe Leroy wrote:
> While working at fixing powerpc headers, I ended up with the
> following error.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error:
> conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const
> char *)'
> make[5]: *** [scripts/Makefile.build:288:
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o] Error 1
>
> powerpc and a few other architectures have a prom_init() global function.
> One day or another it will conflict with the one in shadowrom.c
>
> Those being static, they can easily be renamed. Do it.
>
> While at it, also rename the ops structure as 'nvbios_prom' instead of
> 'nvbios_rom' in order to make it clear that it refers to the
> NV_PROM device.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: using nvbios_prom prefix instead of nvbios_rom. Changed structure name to
> keep things consistant.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h| 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +-
> .../gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c | 14 +++---
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
> index fac1bff1311b..cfa8a0c356dd 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h
> @@ -19,7 +19,7 @@ struct nvbios_source {
> int nvbios_extend(struct nvkm_bios *, u32 length);
> int nvbios_shadow(struct nvkm_bios *);
>
> -extern const struct nvbios_source nvbios_rom;
> +extern const struct nvbios_source nvbios_prom;
> extern const struct nvbios_source nvbios_ramin;
> extern const struct nvbios_source nvbios_acpi_fast;
> extern const struct nvbios_source nvbios_acpi_slow;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
> index 4b571cc6bc70..19188683c8fc 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
> @@ -171,7 +171,7 @@ nvbios_shadow(struct nvkm_bios *bios)
> struct shadow mthds[] = {
> { 0, _of },
> { 0, _ramin },
> - { 0, _rom },
> + { 0, _prom },
> { 0, _acpi_fast },
> { 4, _acpi_slow },
> { 1, _pcirom },
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c
> index ffa4b395220a..39144ceb117b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c
> @@ -25,7 +25,7 @@
> #include
>
> static u32
> -prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios)
> +nvbios_prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios)
> {
> struct nvkm_device *device = data;
> u32 i;
> @@ -38,14 +38,14 @@ prom_read(void *data, u32 offset, u32 length, struct
> nvkm_bios *bios)
> }
>
> static void
> -prom_fini(void *data)
> +nvbios_prom_fini(void *data)
> {
> struct nvkm_device *device = data;
> nvkm_pci_rom_shadow(device->pci, true);
> }
>
> static void *
> -prom_init(struct nvkm_bios *bios, const char *name)
> +nvbios_prom_init(struct nvkm_bios *bios, const char *name)
> {
> struct nvkm_device *device = bios->subdev.device;
> if (device->card_type == NV_40 && device->chipset >= 0x4c)
> @@ -55,10 +55,10 @@ prom_init(struct nvkm_bios *bios, const char *name)
> }
>
> const struct nvbios_source
> -nvbios_rom = {
> +nvbios_prom = {
> .name = "PROM",
> - .init = prom_init,
> - .fini = prom_fini,
> - .read = prom_read,
> + .init = nvbios_prom_init,
> + .fini = nvbios_prom_fini,
> + .read = nvbios_prom_read,
> .rw = false,
> };
> --
> 2.35.1
>
Look's good.
Tommaso
--
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
On Tue, Jan 11, 2022 at 09:21:51PM +0100, Tommaso Merciai wrote:
> On Sun, Jan 09, 2022 at 03:44:07PM -0300, Fabio Estevam wrote:
> > Hi Tommaso,
> >
> > On Sat, Jan 8, 2022 at 4:17 PM Tommaso Merciai
> > wrote:
> >
> > > Hi Fabio,
> > > If you need some test let me know. Whitch filesystem are you using?
> >
> > I am using a rootfs generated by Buildroot.
> >
> > The issue I see seems to be hotplug-related.
> >
> > cat /sys/class/drm/card1-HDMI-A-1/status
> >
> > not always match with the real state of the HDMI cable.
> >
> > > In the next days I will investigate on this issue.
> > > Let me know.
> >
> > Thanks
>
> Hi Fabio,
> Got it, I'll try to reproduce the issue on my side and let you know.
>
> Thanks,
> Tommaso
Hi Fabio,
I'm working on bring up urt,umsh-8596md-20t lvds kit panel, but after enable
following node I get the following error:
+ backlight_display: backlight-display {
+ compatible = "pwm-backlight";
+ pwms = < 0 500>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <32>;
+ };
+
leds {
compatible = "gpio-leds";
@@ -70,6 +77,17 @@ reg_wlan: regulator-wlan {
startup-delay-us = <7>;
enable-active-high;
};
+
+ panel {
+ compatible = "urt,umsh-8596md-20t";
+ backlight = <_display>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
};
{
@@ -196,6 +214,12 @@ pinctrl_bt_reg: btreggrp {
;
};
+ pinctrl_pwm4: pwm4grp-1 {
+ fsl,pins = <
+ MX6SX_PAD_SD1_DATA1__PWM4_OUT 0x110b0
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins =
,
@@ -316,6 +340,40 @@ pinctrl_usdhc3: usdhc3grp {
,
;
};
+
+ pinctrl_lcd: lcdgrp {
+ fsl,pins = <
+ MX6SX_PAD_LCD1_DATA00__LCDIF1_DATA_0 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA01__LCDIF1_DATA_1 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA02__LCDIF1_DATA_2 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA03__LCDIF1_DATA_3 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA04__LCDIF1_DATA_4 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA05__LCDIF1_DATA_5 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA06__LCDIF1_DATA_6 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA07__LCDIF1_DATA_7 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA08__LCDIF1_DATA_8 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA09__LCDIF1_DATA_9 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA10__LCDIF1_DATA_10 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA11__LCDIF1_DATA_11 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA12__LCDIF1_DATA_12 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA13__LCDIF1_DATA_13 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA14__LCDIF1_DATA_14 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA15__LCDIF1_DATA_15 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA16__LCDIF1_DATA_16 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA17__LCDIF1_DATA_17 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA18__LCDIF1_DATA_18 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA19__LCDIF1_DATA_19 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA20__LCDIF1_DATA_20 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA21__LCDIF1_DATA_21 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA22__LCDIF1_DATA_22 0x4001b0b0
+ MX6SX_PAD_LCD1_DATA23__LCDIF1_DATA_23 0x4001b0b0
+ MX6SX_PAD_LCD1_CLK__LCDIF1_CLK 0x4001b0b0
+ MX6SX_PAD_LCD1_ENABLE__LCDIF1_ENABLE 0x4001b0b0
+ MX6SX_PAD_LCD1_VSYNC__LCDIF1_VSYNC 0x4001b0b0
+ MX6SX_PAD_LCD1_HSYNC__LCDIF1_HSYNC 0x4001b0b0
+ MX6SX_PAD_LCD1_RESET__GPIO3_IO_27 0x4001b0b0
+ >;
+ };
};
{
@@ -408,3 +466,22 @@ wlcore: wlcore@2 {
tcxo-clock-frequency = <2600>;
};
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lcd>;
+ status = "okay";
+
+ port {
+
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
On Sun, Jan 16, 2022 at 10:27:19AM -0300, Fabio Estevam wrote: > Hi Tommaso, > > On Sat, Jan 15, 2022 at 8:23 PM Tommaso Merciai > wrote: > > > Hi Fabio, > > I'm working on bring up urt,umsh-8596md-20t lvds kit panel, but after enable > > following node I get the following error: > > I assume you are trying to connect an external panel via connector CN3. Hi Fabio, Right. > > This connector is for LVDS panel, not parallel. Yep, for that I try also urt,umsh-8596md-19t without success. > > The eLCDIF parallel interface is connected to the TDA19988. Thanks for the info. > > Anyway, this is a different topic. My goal here is to fix the kernel > warning when using the TDA19988 HDMI output. My bad sorry, I'm looking for a second HDMI Display for try to reproduce the issue on my side. Meanwhile I'm working on lvds. Thanks, Tommaso > > Thanks
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
On Sun, Jan 09, 2022 at 03:44:07PM -0300, Fabio Estevam wrote: > Hi Tommaso, > > On Sat, Jan 8, 2022 at 4:17 PM Tommaso Merciai wrote: > > > Hi Fabio, > > If you need some test let me know. Whitch filesystem are you using? > > I am using a rootfs generated by Buildroot. > > The issue I see seems to be hotplug-related. > > cat /sys/class/drm/card1-HDMI-A-1/status > > not always match with the real state of the HDMI cable. > > > In the next days I will investigate on this issue. > > Let me know. > > Thanks Hi Fabio, Got it, I'll try to reproduce the issue on my side and let you know. Thanks, Tommaso
Re: [PATCH 1/2] drm/i2c/tda998x: Switch to atomic operations
On Mon, Jan 03, 2022 at 09:35:14AM -0300, Fabio Estevam wrote: > Hi Laurent, > > On Mon, Jan 3, 2022 at 8:48 AM Laurent Pinchart > wrote: > > > With the comment from 2/2 taken into account, > > > > Reviewed-by: Laurent Pinchart > > Thanks for the review. I addressed your feedback and sent v2. > > I noticed a problem when removing/inserting the HDMI cable. > > If I boot the board with the HDMI cable connected, then after > removal/insertion of the HDMI cable, the following > kernel warning is observed: > > # [ 23.201080] [ cut here ] > [ 23.207275] WARNING: CPU: 0 PID: 56 at > drivers/gpu/drm/drm_atomic_helper.c:1514 > drm_atomic_helper_wait_for_vblanks.part.0+0x27c/0x294 > [ 23.221469] [CRTC:35:crtc-0] vblank wait timed out > [ 23.226448] Modules linked in: > [ 23.230255] CPU: 0 PID: 56 Comm: kworker/0:3 Not tainted > 5.15.12-3-g27f29fb60028 #94 > [ 23.238508] Hardware name: Freescale i.MX6 SoloX (Device Tree) > [ 23.244457] Workqueue: events output_poll_execute > [ 23.249377] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 23.257316] [] (show_stack) from [] > (dump_stack_lvl+0x58/0x70) > [ 23.265059] [] (dump_stack_lvl) from [] > (__warn+0xd8/0x114) > [ 23.272533] [] (__warn) from [] > (warn_slowpath_fmt+0x90/0xc4) > [ 23.280166] [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.0+0x27c/0x294) > [ 23.291054] [] > (drm_atomic_helper_wait_for_vblanks.part.0) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [ 23.303150] [] (drm_atomic_helper_commit_tail_rpm) from > [] (commit_tail+0x9c/0x190) > [ 23.312717] [] (commit_tail) from [] > (drm_atomic_helper_commit+0x158/0x18c) > [ 23.321588] [] (drm_atomic_helper_commit) from > [] (drm_client_modeset_commit_atomic+0x238/0x284) > [ 23.332314] [] (drm_client_modeset_commit_atomic) from > [] (drm_client_modeset_commit_locked+0x60/0x1cc) > [ 23.343615] [] (drm_client_modeset_commit_locked) from > [] (drm_client_modeset_commit+0x24/0x40) > [ 23.354218] [] (drm_client_modeset_commit) from > [] (__drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc8) > [ 23.365803] [] > (__drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x38/0x68) > [ 23.377015] [] (drm_fb_helper_set_par) from [] > (drm_fb_helper_hotplug_event.part.0+0xa4/0xc0) > [ 23.387443] [] (drm_fb_helper_hotplug_event.part.0) from > [] (drm_client_dev_hotplug+0x6c/0xb4) > [ 23.397959] [] (drm_client_dev_hotplug) from [] > (output_poll_execute+0x200/0x21c) > [ 23.407346] [] (output_poll_execute) from [] > (process_one_work+0x298/0x7cc) > [ 23.416224] [] (process_one_work) from [] > (worker_thread+0x30/0x50c) > [ 23.424479] [] (worker_thread) from [] > (kthread+0x154/0x17c) > [ 23.432039] [] (kthread) from [] > (ret_from_fork+0x14/0x38) > [ 23.439413] Exception stack(0xc42a1fb0 to 0xc42a1ff8) > [ 23.444588] 1fa0: > > [ 23.452888] 1fc0: > > [ 23.461182] 1fe0: 0013 > [ 23.468734] irq event stamp: 43775 > [ 23.472305] hardirqs last enabled at (43783): [] > __up_console_sem+0x50/0x60 > [ 23.480785] hardirqs last disabled at (43792): [] > __up_console_sem+0x3c/0x60 > [ 23.489224] softirqs last enabled at (43774): [] > __do_softirq+0x2ec/0x5a4 > [ 23.497163] softirqs last disabled at (43747): [] > irq_exit+0x18c/0x210 > [ 23.505106] ---[ end trace 86572327287ca501 ]--- > > I haven't managed to fix this yet, but if you have any suggestions, > please let me know. > > Thanks, > > Fabio Estevam Hi Fabio, If you need some test let me know. Whitch filesystem are you using? In the next days I will investigate on this issue. Let me know. Thanks, Tommaso
