RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
-Original Message- From: Kaneda, Erik Sent: Monday, April 19, 2021 3:56 PM To: Williams, Dan J ; Andy Shevchenko ; Moore, Robert ; Wysocki, Rafael J Cc: linux-nvdimm ; Linux Kernel Mailing List ; Verma, Vishal L ; Jiang, Dave ; Weiny, Ira Subject: RE: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer +Bob and Rafael > -Original Message- > From: Dan Williams > Sent: Friday, April 16, 2021 3:09 PM > To: Andy Shevchenko > Cc: linux-nvdimm ; Linux Kernel Mailing > List ; Verma, Vishal L > ; Jiang, Dave ; Weiny, > Ira ; Kaneda, Erik > Subject: Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw > buffer > > On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko > wrote: > > > > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote: > > > [ add Erik ] > > > > > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko > > > wrote: > > > > > > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote: > > > > > Strictly speaking the comparison between guid_t and raw buffer > > > > > is not correct. Return to plain memcmp() since the data > > > > > structures haven't changed to use uuid_t / guid_t the current > > > > > state of affairs is inconsistent. Either it should be changed > > > > > altogether or left as is. > > > > > > > > Dan, please review this one as well. I think here you may agree with me. > > > > > > You know, this is all a problem because ACPICA is using a raw buffer. > > > > And this is fine. It might be any other representation as well. > > > > > Erik, would it be possible to use the guid_t type in ACPICA? That > > > would allow NFIT to drop some ugly casts. > > > > guid_t is internal kernel type. If we ever decide to deviate from > > the current representation it wouldn't be possible in case a 3rd > > party is using it 1:1 (via typedef or so). > Hi Dan, > I'm thinking something like ACPICA defining that space as a union with > the correct typing just for Linux. I'm assuming that you mean using something like guid_t type for ACPI data table fields like NFIT rather than objects returned by ACPI namespace object such as _DSD. For ACPI data tables, we could to use macros so that different operating systems can provide their own definitions for a guid. For ACPICA, it will expands to a 16-byte array. Linux can have it's own definition that contains a union or their own guid type (guid_t). As long as the OS-supplied definition is 16bytes, I don't think there would be an issue. Erik, I don't like to add these kinds of macros, since it is simply another item that needs to be added to port ACPICA to different hosts. (And must be known by the porter.) Other than that, I suppose we can add such a macro. Bob, do you have any thoughts on this? Erik
[PATCH v2] irqchip/xilinx: Expose Kconfig option for Zynq/ZynqMP
Previously the XILINX_INTC config option was hidden and only auto-selected on the MicroBlaze platform. However, this IP can also be used on the Zynq and ZynqMP platforms as a secondary cascaded controller. Allow this option to be user-enabled on those platforms. Signed-off-by: Robert Hancock --- drivers/irqchip/Kconfig | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 15536e321df5..1020cc5a7800 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -279,8 +279,13 @@ config XTENSA_MX select GENERIC_IRQ_EFFECTIVE_AFF_MASK config XILINX_INTC - bool + bool "Xilinx Interrupt Controller IP" + depends on MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP || COMPILE_TEST select IRQ_DOMAIN + help + Support for the Xilinx Interrupt Controller IP core. + This is used as a primary controller with MicroBlaze and can also + be used as a secondary chained controller on other platforms. config IRQ_CROSSBAR bool -- 2.27.0
Re: [PATCH] irqchip/xilinx: Expose Kconfig option
On Mon, 2021-04-19 at 13:23 +0200, Michal Simek wrote: > Hi Marc and Robert, +Anirudha > > On 4/16/21 8:14 PM, Robert Hancock wrote: > > On Fri, 2021-04-16 at 18:53 +0100, Marc Zyngier wrote: > > > On Fri, 16 Apr 2021 17:05:49 +0100, > > > Robert Hancock wrote: > > > > On Fri, 2021-04-16 at 14:41 +0100, Marc Zyngier wrote: > > > > > On Fri, 16 Apr 2021 00:32:50 +0100, > > > > > Robert Hancock wrote: > > > > > > Previously the XILINX_INTC config option was hidden and only > > > > > > auto-selected on the MicroBlaze platform. However, this IP can also > > > > > > be > > > > > > used on other platforms. Allow this option to be user-enabled. > > > > > > > > > > > > Signed-off-by: Robert Hancock > > > > > > > > > > I don't think this is a good idea. In general, people have no idea > > > > > which interrupt controller they need to select. So you either end-up > > > > > with a missing interrupt controller, or a bunch you really don't > > > > > need. > > > > > > > > > > This is essentially a platform constraint, and this should directly > > > > > be > > > > > selected by the platform if you have this IP in your system. > > > > > > > > > > Thanks, > > > > > > > > > > M. > > > > > > > > The problem is essentially that at the platform level, we don't know, > > > > other > > > > than in the MicroBlaze case where we know it will be used as the > > > > platform's > > > > primary interrupt controller. In our case, we are using this IP core on > > > > the > > > > ZynqMP platform as a secondary cascaded interrupt controller in the > > > > FPGA > > > > portion of the device. > > > > But many ZynqMP configurations wouldn't have this device present, it > > > > depends on what the user instantiates in the programmable logic. > > > > Also, this core could just as easily be instantiated in standalone > > > > Xilinx FPGAs which could be connected to many different platforms > > > > over a PCIe, AXI, etc. bus. > > > > > > Not compiling it for some users is great if you happen to *know* what > > > you have to select, which is probably a single digit percentage of the > > > people that build their own kernel. At least having it to depend on > > > ZYNQMP (or some other FPGA platform) would narrow it down. > > > > > > And if you have some other HW in your FPGA, you can make the config > > > fragment for this HW select the right interrupt controller. But I'm > > > definitely not keen on making this a universally user-selectable > > > driver. > > > > In general there is no specific or unique config option for what is > > instantiated in an FPGA, it is completely up to the whims of whoever set it > > up. > > You can instantiate whatever logic cores you want and there is no guarantee > > whether they will or won't end up using this interrupt controller in the > > path > > somewhere, so having a dependency there doesn't make much sense. For FPGA > > logic > > it's ultimately up to the user to ensure the kernel config they are using > > has > > the right drivers enabled for the cores they are using. Kconfig doesn't and > > can't really help in this regard. > > > > There's some precedent on this issue with drivers for various other FPGA- > > based > > IP cores for SPI, I2C, Ethernet etc. Often they started out with an > > architecture constraint which limited them to the platform they were > > originally > > developed with, but which was later removed because the ability to use them > > in > > standalone FPGAs means that the platforms they could potentially be used > > with > > are basically unconstrained. > > > > > > So I don't think having this as a platform constraint makes sense. > > > > > > I don't think imposing this on *everyone*, across all supported > > > architectures and platforms makes any sense. Surely, people who build > > > their own HW (because that's what we are talking about here) can be > > > bothered to add the small Kconfig fragment that is required to their > > > kernel build. > > The same interrupt controller was used by ppc405 and ppc440 xilinx > platform in p
Re: [PATCH v4 2/3] drm: bridge: add it66121 driver
Hey Neil, Thanks for the quick respin. Reviewed-by: Robert Foss On Mon, 19 Apr 2021 at 09:12, Neil Armstrong wrote: > > From: Phong LE > > This commit is a simple driver for bridge HMDI it66121. > The input format is RBG and there is no color conversion. > Audio, HDCP and CEC are not supported yet. > > Signed-off-by: Phong LE > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/bridge/Kconfig |8 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/ite-it66121.c | 1021 ++ > 3 files changed, 1030 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index e4110d6ca7b3..6915c38fa459 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC > HDMI signals > Please say Y if you have such hardware. > > +config DRM_ITE_IT66121 > + tristate "ITE IT66121 HDMI bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + help > + Support for ITE IT66121 HDMI bridge. > + > config DRM_LVDS_CODEC > tristate "Transparent LVDS encoders and decoders support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 86e7acc76f8d..4f725753117c 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o > obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o > +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o > > obj-y += analogix/ > obj-y += cadence/ > diff --git a/drivers/gpu/drm/bridge/ite-it66121.c > b/drivers/gpu/drm/bridge/ite-it66121.c > new file mode 100644 > index ..d8a60691fd32 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/ite-it66121.c > @@ -0,0 +1,1021 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2020 BayLibre, SAS > + * Author: Phong LE > + * Copyright (C) 2018-2019, Artem Mygaiev > + * Copyright (C) 2017, Fresco Logic, Incorporated. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define IT66121_VENDOR_ID0_REG 0x00 > +#define IT66121_VENDOR_ID1_REG 0x01 > +#define IT66121_DEVICE_ID0_REG 0x02 > +#define IT66121_DEVICE_ID1_REG 0x03 > + > +#define IT66121_VENDOR_ID0 0x54 > +#define IT66121_VENDOR_ID1 0x49 > +#define IT66121_DEVICE_ID0 0x12 > +#define IT66121_DEVICE_ID1 0x06 > +#define IT66121_REVISION_MASK GENMASK(7, 4) > +#define IT66121_DEVICE_ID1_MASKGENMASK(3, 0) > + > +#define IT66121_MASTER_SEL_REG 0x10 > +#define IT66121_MASTER_SEL_HOSTBIT(0) > + > +#define IT66121_AFE_DRV_REG0x61 > +#define IT66121_AFE_DRV_RSTBIT(4) > +#define IT66121_AFE_DRV_PWDBIT(5) > + > +#define IT66121_INPUT_MODE_REG 0x70 > +#define IT66121_INPUT_MODE_RGB (0 << 6) > +#define IT66121_INPUT_MODE_YUV422 BIT(6) > +#define IT66121_INPUT_MODE_YUV444 (2 << 6) > +#define IT66121_INPUT_MODE_CCIR656 BIT(4) > +#define IT66121_INPUT_MODE_SYNCEMB BIT(3) > +#define IT66121_INPUT_MODE_DDR BIT(2) > + > +#define IT66121_INPUT_CSC_REG 0x72 > +#define IT66121_INPUT_CSC_ENDITHER BIT(7) > +#define IT66121_INPUT_CSC_ENUDFILTER BIT(6) > +#define IT66121_INPUT_CSC_DNFREE_GOBIT(5) > +#define IT66121_INPUT_CSC_RGB_TO_YUV 0x02 > +#define IT66121_INPUT_CSC_YUV_TO_RGB 0x03 > +#define IT66121_INPUT_CSC_NO_CONV 0x00 > + > +#define IT66121_AFE_XP_REG 0x62 > +#define IT66121_AFE_XP_GAINBIT BIT(7) > +#define IT66121_AFE_XP_PWDPLL BIT(6) > +#define IT66121_AFE_XP_ENI BIT(5) > +#define IT66121_AFE_XP_ENO BIT(4) > +#define IT66121_AFE_XP_RESETB BIT(3) > +#define IT661
[PATCH v3] drm/bridge/sii8620: fix dependency on extcon
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency
on EXTCON, which causes issues when sii8620 is built
as a builtin and EXTCON is built as a module.
The symptoms are 'undefined reference' errors caused
by the symbols in EXTCON not being available
to the sii8620 driver.
Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic
to detect MHL")
Signed-off-by: Robert Foss
Reported-by: kernel test robot
---
LKP reported issue:
https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/
Changes since v1:
- Fix typo on comment
Changes since v2:
- Randy: Changed from `depends` to `select`
drivers/gpu/drm/bridge/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 22a467abd3e9..70402da5cc70 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -169,7 +169,7 @@ config DRM_SIL_SII8620
tristate "Silicon Image SII8620 HDMI/MHL bridge"
depends on OF
select DRM_KMS_HELPER
- imply EXTCON
+ select EXTCON
depends on RC_CORE || !RC_CORE
help
Silicon Image SII8620 HDMI/MHL bridge chip driver.
--
2.31.0.30.g398dba342d.dirty
Re: [PATCH] irqchip/xilinx: Expose Kconfig option
On Fri, 2021-04-16 at 18:53 +0100, Marc Zyngier wrote: > On Fri, 16 Apr 2021 17:05:49 +0100, > Robert Hancock wrote: > > On Fri, 2021-04-16 at 14:41 +0100, Marc Zyngier wrote: > > > On Fri, 16 Apr 2021 00:32:50 +0100, > > > Robert Hancock wrote: > > > > Previously the XILINX_INTC config option was hidden and only > > > > auto-selected on the MicroBlaze platform. However, this IP can also be > > > > used on other platforms. Allow this option to be user-enabled. > > > > > > > > Signed-off-by: Robert Hancock > > > > > > I don't think this is a good idea. In general, people have no idea > > > which interrupt controller they need to select. So you either end-up > > > with a missing interrupt controller, or a bunch you really don't need. > > > > > > This is essentially a platform constraint, and this should directly be > > > selected by the platform if you have this IP in your system. > > > > > > Thanks, > > > > > > M. > > > > The problem is essentially that at the platform level, we don't know, other > > than in the MicroBlaze case where we know it will be used as the platform's > > primary interrupt controller. In our case, we are using this IP core on the > > ZynqMP platform as a secondary cascaded interrupt controller in the FPGA > > portion of the device. > > But many ZynqMP configurations wouldn't have this device present, it > > depends on what the user instantiates in the programmable logic. > > Also, this core could just as easily be instantiated in standalone > > Xilinx FPGAs which could be connected to many different platforms > > over a PCIe, AXI, etc. bus. > > Not compiling it for some users is great if you happen to *know* what > you have to select, which is probably a single digit percentage of the > people that build their own kernel. At least having it to depend on > ZYNQMP (or some other FPGA platform) would narrow it down. > > And if you have some other HW in your FPGA, you can make the config > fragment for this HW select the right interrupt controller. But I'm > definitely not keen on making this a universally user-selectable > driver. In general there is no specific or unique config option for what is instantiated in an FPGA, it is completely up to the whims of whoever set it up. You can instantiate whatever logic cores you want and there is no guarantee whether they will or won't end up using this interrupt controller in the path somewhere, so having a dependency there doesn't make much sense. For FPGA logic it's ultimately up to the user to ensure the kernel config they are using has the right drivers enabled for the cores they are using. Kconfig doesn't and can't really help in this regard. There's some precedent on this issue with drivers for various other FPGA-based IP cores for SPI, I2C, Ethernet etc. Often they started out with an architecture constraint which limited them to the platform they were originally developed with, but which was later removed because the ability to use them in standalone FPGAs means that the platforms they could potentially be used with are basically unconstrained. > > > So I don't think having this as a platform constraint makes sense. > > I don't think imposing this on *everyone*, across all supported > architectures and platforms makes any sense. Surely, people who build > their own HW (because that's what we are talking about here) can be > bothered to add the small Kconfig fragment that is required to their > kernel build. -- Robert Hancock Senior Hardware Designer, Calian Advanced Technologies www.calian.com
Re: [PATCH] irqchip/xilinx: Expose Kconfig option
On Fri, 2021-04-16 at 14:41 +0100, Marc Zyngier wrote: > On Fri, 16 Apr 2021 00:32:50 +0100, > Robert Hancock wrote: > > Previously the XILINX_INTC config option was hidden and only > > auto-selected on the MicroBlaze platform. However, this IP can also be > > used on other platforms. Allow this option to be user-enabled. > > > > Signed-off-by: Robert Hancock > > I don't think this is a good idea. In general, people have no idea > which interrupt controller they need to select. So you either end-up > with a missing interrupt controller, or a bunch you really don't need. > > This is essentially a platform constraint, and this should directly be > selected by the platform if you have this IP in your system. > > Thanks, > > M. The problem is essentially that at the platform level, we don't know, other than in the MicroBlaze case where we know it will be used as the platform's primary interrupt controller. In our case, we are using this IP core on the ZynqMP platform as a secondary cascaded interrupt controller in the FPGA portion of the device. But many ZynqMP configurations wouldn't have this device present, it depends on what the user instantiates in the programmable logic. Also, this core could just as easily be instantiated in standalone Xilinx FPGAs which could be connected to many different platforms over a PCIe, AXI, etc. bus. So I don't think having this as a platform constraint makes sense. -- Robert Hancock Senior Hardware Designer, Calian Advanced Technologies www.calian.com
Re: [PATCH -next] drm: bridge: fix ANX7625 use of mipi_dsi_() functions
Merged for 5.13 in drm-misc-next-fixes
On Fri, 16 Apr 2021 at 10:41, Robert Foss wrote:
>
> Thanks Randy!
>
> Reviewed-by: Robert Foss
>
> On Thu, 15 Apr 2021 at 20:36, Randy Dunlap wrote:
> >
> > The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
> > interfaces so it should select DRM_MIPI_DSI to prevent build errors.
> >
> >
> > ERROR: modpost: "mipi_dsi_attach"
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_register_full"
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "of_find_mipi_dsi_host_by_node"
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_unregister"
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> > ERROR: modpost: "mipi_dsi_detach"
> > [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> >
> >
> > Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> > Signed-off-by: Randy Dunlap
> > Reported-by: kernel test robot
> > Cc: Xin Ji
> > Cc: Sam Ravnborg
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Robert Foss
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/bridge/analogix/Kconfig |1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- linux-next-20210414.orig/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ linux-next-20210414/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -30,6 +30,7 @@ config DRM_ANALOGIX_ANX7625
> > tristate "Analogix Anx7625 MIPI to DP interface support"
> > depends on DRM
> > depends on OF
> > + select DRM_MIPI_DSI
> > help
> > ANX7625 is an ultra-low power 4K mobile HD transmitter
> > designed for portable devices. It converts MIPI/DPI to
Re: [PATCH -next] drm: bridge: fix LONTIUM use of mipi_dsi_() functions
Merged for 5.13 in drm-misc-next-fixes
On Thu, 15 Apr 2021 at 21:36, Adrien Grassein wrote:
>
> Reviewed-by: Adren Grassein
>
> Le jeu. 15 avr. 2021 à 20:36, Randy Dunlap a écrit :
> >
> > The Lontium DRM bridge drivers use mipi_dsi_() function interfaces so
> > they need to select DRM_MIPI_DSI to prevent build errors.
> >
> > ERROR: modpost: "mipi_dsi_attach"
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_register_full"
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "of_find_mipi_dsi_host_by_node"
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_unregister"
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_detach"
> > [drivers/gpu/drm/bridge/lontium-lt9611uxc.ko] undefined!
> > ERROR: modpost: "mipi_dsi_attach"
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_register_full"
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "of_find_mipi_dsi_host_by_node"
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "mipi_dsi_device_unregister"
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > ERROR: modpost: "mipi_dsi_detach"
> > [drivers/gpu/drm/bridge/lontium-lt9611.ko] undefined!
> > WARNING: modpost: suppressed 5 unresolved symbol warnings because there
> > were too many)
> >
> > Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
> > Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC
> > bridge")
> > Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> > Signed-off-by: Randy Dunlap
> > Reported-by: kernel test robot
> > Cc: Dmitry Baryshkov
> > Cc: Sam Ravnborg
> > Cc: Vinod Koul
> > Cc: Bjorn Andersson
> > Cc: Srinivas Kandagatla
> > Cc: Adrien Grassein
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Robert Foss
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/bridge/Kconfig |3 +++
> > 1 file changed, 3 insertions(+)
> >
> > --- linux-next-20210414.orig/drivers/gpu/drm/bridge/Kconfig
> > +++ linux-next-20210414/drivers/gpu/drm/bridge/Kconfig
> > @@ -66,6 +66,7 @@ config DRM_LONTIUM_LT8912B
> > depends on OF
> > select DRM_PANEL_BRIDGE
> > select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > select REGMAP_I2C
> > help
> > Driver for Lontium LT8912B DSI to HDMI bridge
> > @@ -81,6 +82,7 @@ config DRM_LONTIUM_LT9611
> > depends on OF
> > select DRM_PANEL_BRIDGE
> > select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > select REGMAP_I2C
> > help
> > Driver for Lontium LT9611 DSI to HDMI bridge
> > @@ -94,6 +96,7 @@ config DRM_LONTIUM_LT9611UXC
> > depends on OF
> > select DRM_PANEL_BRIDGE
> > select DRM_KMS_HELPER
> > + select DRM_MIPI_DSI
> > select REGMAP_I2C
> > help
> > Driver for Lontium LT9611UXC DSI to HDMI bridge
Re: [PATCH -next] drm: bridge: fix ANX7625 use of mipi_dsi_() functions
Thanks Randy!
Reviewed-by: Robert Foss
On Thu, 15 Apr 2021 at 20:36, Randy Dunlap wrote:
>
> The Analogix DRM ANX7625 bridge driver uses mips_dsi_() function
> interfaces so it should select DRM_MIPI_DSI to prevent build errors.
>
>
> ERROR: modpost: "mipi_dsi_attach"
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "mipi_dsi_device_register_full"
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "of_find_mipi_dsi_host_by_node"
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "mipi_dsi_device_unregister"
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
> ERROR: modpost: "mipi_dsi_detach"
> [drivers/gpu/drm/bridge/analogix/anx7625.ko] undefined!
>
>
> Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: Xin Ji
> Cc: Sam Ravnborg
> Cc: dri-de...@lists.freedesktop.org
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20210414.orig/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ linux-next-20210414/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -30,6 +30,7 @@ config DRM_ANALOGIX_ANX7625
> tristate "Analogix Anx7625 MIPI to DP interface support"
> depends on DRM
> depends on OF
> + select DRM_MIPI_DSI
> help
> ANX7625 is an ultra-low power 4K mobile HD transmitter
> designed for portable devices. It converts MIPI/DPI to
[PATCH] irqchip/xilinx: Expose Kconfig option
Previously the XILINX_INTC config option was hidden and only auto-selected on the MicroBlaze platform. However, this IP can also be used on other platforms. Allow this option to be user-enabled. Signed-off-by: Robert Hancock --- drivers/irqchip/Kconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 15536e321df5..cc24f1bd3ca7 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -279,8 +279,12 @@ config XTENSA_MX select GENERIC_IRQ_EFFECTIVE_AFF_MASK config XILINX_INTC - bool + bool "Xilinx Interrupt Controller IP" select IRQ_DOMAIN + help + Support for the Xilinx Interrupt Controller IP core. + This is used as a primary controller with MicroBlaze and can also + be used as a secondary chained controller on other platforms. config IRQ_CROSSBAR bool -- 2.27.0
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
On Wed, 14 Apr 2021 at 08:13, Neil Armstrong wrote:
>
> Hi Rob,
>
> Le 13/04/2021 à 22:21, Robert Foss a écrit :
> > Hey Neil & Phong,
> >
> > Thanks for submitting this series!
> >
> >> +
> >> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> >> + .attach = it66121_bridge_attach,
> >> + .enable = it66121_bridge_enable,
> >> + .disable = it66121_bridge_disable,
> >> + .mode_set = it66121_bridge_mode_set,
> >> + .mode_valid = it66121_bridge_mode_valid,
> >> + .detect = it66121_bridge_detect,
> >> + .get_edid = it66121_bridge_get_edid,
> >> + .atomic_get_output_bus_fmts =
> >> it66121_bridge_atomic_get_output_bus_fmts,
> >> + .atomic_get_input_bus_fmts =
> >> it66121_bridge_atomic_get_input_bus_fmts,
> >> +};
> >
> > I would like to see an implementation of HPD, since it is supported by
> > the hardware[1] (and required by the documentation). IRQ status bit 0
> > seems to be the responsible for notifying us about hot plug detection
> > events.
>
> It's implemented in the IRQ handler with the IT66121_INT_STATUS1_HPD_STATUS
> event.
>
I didn't even get that far :)
Either way, the HPD support should be exposed in drm_bridge_funcs
(.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
drm_bridge.ops (DRM_BRIDGE_OP_HPD).
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hey Neil & Phong,
Thanks for submitting this series!
> +
> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> + .attach = it66121_bridge_attach,
> + .enable = it66121_bridge_enable,
> + .disable = it66121_bridge_disable,
> + .mode_set = it66121_bridge_mode_set,
> + .mode_valid = it66121_bridge_mode_valid,
> + .detect = it66121_bridge_detect,
> + .get_edid = it66121_bridge_get_edid,
> + .atomic_get_output_bus_fmts =
> it66121_bridge_atomic_get_output_bus_fmts,
> + .atomic_get_input_bus_fmts = it66121_bridge_atomic_get_input_bus_fmts,
> +};
I would like to see an implementation of HPD, since it is supported by
the hardware[1] (and required by the documentation). IRQ status bit 0
seems to be the responsible for notifying us about hot plug detection
events.
[1] https://rockchip.fr/radxa/IT66121_Programming_Guide.v1.05.pdf
Rob.
Re: [PATCH v3 3/3] MAINTAINERS: add it66121 HDMI bridge driver entry
On Mon, 12 Apr 2021 at 17:47, Neil Armstrong wrote: > > On 12/04/2021 17:46, Neil Armstrong wrote: > > From: Phong LE > > > > Add Neil Armstrong and myself as maintainers > > > > Signed-off-by: Phong LE > > Obviously: > Signed-off-by: Neil Armstrong > > > --- > > MAINTAINERS | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9ae8444c96b4..ff6450c83049 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9515,6 +9515,14 @@ Q: > > http://patchwork.linuxtv.org/project/linux-media/list/ > > T: git git://linuxtv.org/anttip/media_tree.git > > F: drivers/media/tuners/it913x* > > > > +ITE IT66121 HDMI BRIDGE DRIVER > > +M: Phong LE > > +M: Neil Armstrong > > +S: Maintained > > +F: drivers/gpu/drm/bridge/ite-it66121.c > > +T: git git://anongit.freedesktop.org/drm/drm-misc I'm getting a checkpatch --strict warning here. The two above lines should switch places. WARNING: Misordered MAINTAINERS entry - list 'T:' before 'F:' #27: FILE: MAINTAINERS:9537: +F:drivers/gpu/drm/bridge/ite-it66121.c +T:git git://anongit.freedesktop.org/drm/drm-misc With this warning silenced, feel free to add my r-b. Reviewed-by: Robert Foss > > +F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml > > + > > IVTV VIDEO4LINUX DRIVER > > M: Andy Walls > > L: linux-me...@vger.kernel.org > > >
Re: [PATCH v2] drm/bridge/sii8620: fix dependency on extcon
Hey Randy, Thanks for looking at this! On Fri, 9 Apr 2021 at 18:38, Randy Dunlap wrote: > > On 4/8/21 6:07 AM, Robert Foss wrote: > > The DRM_SIL_SII8620 kconfig has a weak `imply` dependency > > on EXTCON, which causes issues when sii8620 is built > > as a builtin and EXTCON is built as a module. > > > > The symptoms are 'undefined reference' errors caused > > by the symbols in EXTCON not being available > > to the sii8620 driver. > > > > Signed-off-by: Robert Foss > > Reported-by: kernel test robot > > --- > > > > Changes since v1: > > - Fix typo on comment > > > > drivers/gpu/drm/bridge/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 22a467abd3e9..2289b44613af 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -169,7 +169,7 @@ config DRM_SIL_SII8620 > > tristate "Silicon Image SII8620 HDMI/MHL bridge" > > depends on OF > > select DRM_KMS_HELPER > > - imply EXTCON > > + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in > > depends on RC_CORE || !RC_CORE > > help > > Silicon Image SII8620 HDMI/MHL bridge chip driver. > > > > That gives me: (on linux-next 20210409) > > drivers/gpu/drm/Kconfig:77:error: recursive dependency detected! > drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_HELPER is selected by > DRM_SIL_SII8620 > drivers/gpu/drm/bridge/Kconfig:168: symbol DRM_SIL_SII8620 depends on > EXTCON > drivers/extcon/Kconfig:2: symbol EXTCON is selected by CHARGER_MANAGER > drivers/power/supply/Kconfig:499: symbol CHARGER_MANAGER depends on > POWER_SUPPLY > drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by > OLPC_XO1_SCI > arch/x86/Kconfig:2757: symbol OLPC_XO1_SCI depends on GPIO_CS5535 > drivers/gpio/Kconfig:1156: symbol GPIO_CS5535 depends on GPIOLIB > drivers/gpio/Kconfig:14:symbol GPIOLIB is selected by I2C_MUX_LTC4306 > drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER > drivers/gpu/drm/Kconfig:83: symbol DRM_KMS_FB_HELPER depends on > DRM_KMS_HELPER > For a resolution refer to Documentation/kbuild/kconfig-language.rst > subsection "Kconfig recursive dependency limitations" I'm not sure how to avoid this circular dependency. The above solution is what I've seen w/r to issues like [1]. Clearly it doesn't work in this situation. `select EXTCON` doesn't seem to cause this dependency error, but I'm not sure it accurately represents the dependency sii8620 has on extcon. [1] https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/
Re: [PATCH v6 0/2] enable HDCP in Cadence MHDP bridge driver
Merged series. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=6a3608eae6d33a478a29348eb5e9ca330a528ae6 On Sat, 10 Apr 2021 at 20:14, Parshuram Thombare wrote: > > This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver. > > Changes since v1: > - Move sapb reg block right after apb reg block > - Corresponding changes in binding and example > > Changes since v2: > - Revert reg resource sequence in binding and > use resource mapping by name > - Remove hdcp_config from binding and use > DRM HDCP Content Type property to select > HDCP version > > Changes since v3: > - Fix kernel test robot warning > > Changes since v4: > - Fix binding issue > > Changes since v5: > - Maintain backward compatibility of driver on platforms > without SAPB port by allowing driver to continue without > HDCP feature instead of returning error > > > Parshuram Thombare (2): > dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP > drm: bridge: cdns-mhdp8546: Enable HDCP > > .../display/bridge/cdns,mhdp8546.yaml | 15 +- > drivers/gpu/drm/bridge/cadence/Makefile | 2 +- > .../drm/bridge/cadence/cdns-mhdp8546-core.c | 128 +++- > .../drm/bridge/cadence/cdns-mhdp8546-core.h | 22 + > .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 570 ++ > .../drm/bridge/cadence/cdns-mhdp8546-hdcp.h | 92 +++ > 6 files changed, 812 insertions(+), 17 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c > create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.h > > -- > 2.25.1 >
Re: [PATCH 04/12] ARM: pxa: stargate2: Constify the software node
Wolfram Sang writes: > On Mon, Mar 29, 2021 at 01:50:39PM +0300, Heikki Krogerus wrote: >> Additional device properties are always just a part of a >> software fwnode. If the device properties are constant, the >> software node can also be constant. >> >> Signed-off-by: Heikki Krogerus >> Cc: Jonathan Cameron >> Cc: Daniel Mack >> Cc: Haojian Zhuang >> Cc: Robert Jarzmik > > I like to apply it soon. Can we get an ack, please? Acked-by: Robert Jarzmik Cheers. -- Robert
Re: [PATCH] ARM: pxa: mainstone: avoid -Woverride-init warning
Arnd Bergmann writes: > From: Arnd Bergmann > > On Tue, 23 Mar 2021 14:08:27 +0100, Arnd Bergmann wrote: >> The default initializer at the start of the array causes a warning >> when building with W=1: >> >> In file included from arch/arm/mach-pxa/mainstone.c:47: >> arch/arm/mach-pxa/mainstone.h:124:33: error: initialized field overwritten >> [-Werror=override-init] >> 124 | #define MAINSTONE_IRQ(x)(MAINSTONE_NR_IRQS + (x)) >> | ^ >> arch/arm/mach-pxa/mainstone.h:133:33: note: in expansion of macro >> 'MAINSTONE_IRQ' >> 133 | #define MAINSTONE_S0_CD_IRQ MAINSTONE_IRQ(9) >> | ^ >> arch/arm/mach-pxa/mainstone.c:506:15: note: in expansion of macro >> 'MAINSTONE_S0_CD_IRQ' >> 506 | [5] = MAINSTONE_S0_CD_IRQ, >> | ^~~ >> >> [...] > > Applied to arm/fixes. Too late, but ... Acked-by: Robert Jarzmik Cheers. -- Robert
Re: [PATCH -next] media: camss: ispif: Remove redundant dev_err call in msm_ispif_subdev_init()
Hi Yang,
Thanks for the patch.
On Fri, 9 Apr 2021 at 07:03, Yang Yingliang wrote:
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Reported-by: Hulk Robot
> Signed-off-by: Yang Yingliang
> ---
> drivers/media/platform/qcom/camss/camss-ispif.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c
> b/drivers/media/platform/qcom/camss/camss-ispif.c
> index a30e453de162..37611c8861da 100644
> --- a/drivers/media/platform/qcom/camss/camss-ispif.c
> +++ b/drivers/media/platform/qcom/camss/camss-ispif.c
> @@ -1145,17 +1145,13 @@ int msm_ispif_subdev_init(struct camss *camss,
>
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[0]);
> ispif->base = devm_ioremap_resource(dev, r);
> - if (IS_ERR(ispif->base)) {
> - dev_err(dev, "could not map memory\n");
> + if (IS_ERR(ispif->base))
> return PTR_ERR(ispif->base);
> - }
>
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[1]);
> ispif->base_clk_mux = devm_ioremap_resource(dev, r);
> - if (IS_ERR(ispif->base_clk_mux)) {
> - dev_err(dev, "could not map memory\n");
> + if (IS_ERR(ispif->base_clk_mux))
> return PTR_ERR(ispif->base_clk_mux);
> - }
>
> /* Interrupt */
>
Reviewed-by: Robert Foss
Re: [PATCH 1/1] drm/bridge: anx7625: send DPCD command to downstream
Hey Xin,
On Fri, 9 Apr 2021 at 07:35, Xin Ji wrote:
>
> Send DPCD command to downstream before anx7625 power down,
> tell downstream into standby mode.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 75 +++
> 1 file changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 65cc05982f82..53d2f0d0ee30 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -124,6 +124,23 @@ static int anx7625_reg_write(struct anx7625_data *ctx,
> return ret;
> }
>
> +static int anx7625_reg_block_write(struct anx7625_data *ctx,
> + struct i2c_client *client,
> + u8 reg_addr, u8 len, u8 *buf)
> +{
> + int ret;
> + struct device *dev = &client->dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_write_i2c_block_data(client, reg_addr, len, buf);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "write i2c block failed id=%x\n:%x",
> + client->addr, reg_addr);
> +
> + return ret;
> +}
> +
> static int anx7625_write_or(struct anx7625_data *ctx,
> struct i2c_client *client,
> u8 offset, u8 mask)
> @@ -195,6 +212,55 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
> return val;
> }
>
> +static int anx7625_aux_dpcd_write(struct anx7625_data *ctx,
> + u8 addrh, u8 addrm, u8 addrl,
> + u8 len, u8 *buf)
> +{
> + struct device *dev = &ctx->client->dev;
> + int ret;
> + u8 cmd;
> +
> + if (len > MAX_DPCD_BUFFER_SIZE) {
> + DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
> + return -EINVAL;
> + }
> +
> + cmd = ((len - 1) << 4) | 0x08;
> +
> + /* Set command and length */
> + ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> + AP_AUX_COMMAND, cmd);
> +
> + /* Set aux access address */
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_7_0, addrl);
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_15_8, addrm);
> + ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
> +AP_AUX_ADDR_19_16, addrh);
> +
> + /* Set write data */
> + ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
> + AP_AUX_BUFF_START, len, buf);
> + /* Enable aux access */
> + ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
> + AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
> + return -EIO;
> + }
> +
> + usleep_range(2000, 2100);
> +
> + ret = wait_aux_op_finish(ctx);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int anx7625_video_mute_control(struct anx7625_data *ctx,
> u8 status)
> {
> @@ -617,6 +683,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
> {
> struct device *dev = &ctx->client->dev;
> int ret;
> + u8 data;
>
> DRM_DEV_DEBUG_DRIVER(dev, "stop dp output\n");
>
> @@ -628,8 +695,16 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
> ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client, 0x08, 0x7f);
>
> ret |= anx7625_video_mute_control(ctx, 1);
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "notify downstream enter into standby\n");
> +
> + /* Downstream monitor enter into standby mode */
> + data = 2;
> + ret |= anx7625_aux_dpcd_write(ctx, 0x00, 0x06, 0x00, 1, &data);
> if (ret < 0)
> DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
> +
> + return;
> }
Reviewed-by: Robert Foss
[PATCH v2] drm/bridge/sii8620: fix dependency on extcon
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency on EXTCON, which causes issues when sii8620 is built as a builtin and EXTCON is built as a module. The symptoms are 'undefined reference' errors caused by the symbols in EXTCON not being available to the sii8620 driver. Signed-off-by: Robert Foss Reported-by: kernel test robot --- Changes since v1: - Fix typo on comment drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 22a467abd3e9..2289b44613af 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -169,7 +169,7 @@ config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF select DRM_KMS_HELPER - imply EXTCON + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in depends on RC_CORE || !RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.31.0.30.g398dba342d.dirty
Re: [PATCH -next v3] drm/bridge: lt8912b: Add header file
Pushed to https://cgit.freedesktop.org/drm/drm-misc/commit/?id=7513ce49027c8218a6fce7ec45c3289b903ba4bd On Thu, 8 Apr 2021 at 11:38, Zhang Jianhua wrote: > > If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while > compiling lontium-lt8912b.c > > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function > ‘lt8912_hard_power_on’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit > declaration of function ‘gpiod_set_value_cansleep’; did you mean > ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] > gpiod_set_value_cansleep(lt->gp_reset, 0); > ^~~~ > gpio_set_value_cansleep > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit > declaration of function ‘devm_gpiod_get_optional’; did you mean > ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); > ^~~ > devm_gpio_request_one > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ > undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); >^~ > GPIOF_INIT_HIGH > > Signed-off-by: Zhang Jianhua > Reviewed-by: Robert Foss > --- > v2: > - add header file for lontium-lt8912b.c instead > of add config dependence for CONFIG_DRM_LONTIUM_LT8912B > v3: > - change the #include in alphabetical order > --- > drivers/gpu/drm/bridge/lontium-lt8912b.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c > b/drivers/gpu/drm/bridge/lontium-lt8912b.c > index 61491615bad0..4f693123985b 100644 > --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c > +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c > @@ -5,6 +5,7 @@ > > #include > #include > +#include > #include > #include > #include > -- > 2.17.1 >
Re: [PATCH -next v2] drm/bridge: lt8912b: Add header file
Hey Zhang, On Thu, 8 Apr 2021 at 05:54, Zhang Jianhua wrote: > > If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while > compiling lontium-lt8912b.c > > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function > ‘lt8912_hard_power_on’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit > declaration of function ‘gpiod_set_value_cansleep’; did you mean > ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] > gpiod_set_value_cansleep(lt->gp_reset, 0); > ^~~~ > gpio_set_value_cansleep > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit > declaration of function ‘devm_gpiod_get_optional’; did you mean > ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); > ^~~ > devm_gpio_request_one > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ > undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); >^~ >GPIOF_INIT_HIGH > > Signed-off-by: Zhang Jianhua > --- > v2: > - add header file for lontium-lt8912b.c instead > of add config dependence for CONFIG_DRM_LONTIUM_LT8912B > --- > drivers/gpu/drm/bridge/lontium-lt8912b.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c > b/drivers/gpu/drm/bridge/lontium-lt8912b.c > index 61491615bad0..79845b3b19e1 100644 > --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c > +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c > @@ -3,6 +3,7 @@ > * Copyright (c) 2018, The Linux Foundation. All rights reserved. > */ > > +#include > #include > #include > #include Add this #include in alphabetical order. With this change, feel free to add my r-b. Reviewed-by: Robert Foss > -- > 2.17.1 >
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Hey Zhang, On Thu, 8 Apr 2021 at 09:10, zhangjianhua (E) wrote: > > Hello Robert > > I am sorry that I make a mistake about the compiling error of lt8912b, > > the reason is that lt8912b miss the header file . > > Although there are many files reference gpiod_set_value_cansleep() and > > devm_gpiod_get_optional(), they all include > > and not occur the compiling error like lt8912b. I have send the second > > version patch, please read. No worries at all, and good job finding the real issue. I'll have a look at the next version. Rob.
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
> Yes, you are right, there are many files reference > gpiod_set_value_cansleep() and > > devm_gpiod_get_optional(). How about add config dependencies for all > releated I think this is the way to go and roughly half of the drm bridge drivers seem to need this change. Do you mind submitting a series of patches adding this fix for all of the relevant bridge drivers? > > configs or only add config dependencies for the top level config? >
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Hey Zhang On Tue, 6 Apr 2021 at 11:07, Zhang Jianhua wrote: > > If CONFIG_DRM_LONTIUM_LT8912B=y, the following errors will be seen while > compiling lontium-lt8912b.c > > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function > ‘lt8912_hard_power_on’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit > declaration of function ‘gpiod_set_value_cansleep’; did you mean > ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] > gpiod_set_value_cansleep(lt->gp_reset, 0); > ^~~~ > gpio_set_value_cansleep > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit > declaration of function ‘devm_gpiod_get_optional’; did you mean > ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); > ^~~ > devm_gpio_request_one > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ > undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); >^~ >GPIOF_INIT_HIGH > > Signed-off-by: Zhang Jianhua > --- > drivers/gpu/drm/bridge/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index dba62f92d051..caa9658ec933 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -67,6 +67,7 @@ config DRM_LONTIUM_LT8912B > select DRM_PANEL_BRIDGE > select DRM_KMS_HELPER > select REGMAP_I2C > + select GPIOLIB This appears like the right fix for this problem. However, a number of drm/bridge drivers seem to call both gpio_set_value_cansleep() and devm_gpiod_get_optional() without having the GPIOLIB kconfig option selected so this can't be a new issue. Maybe some more investigation is in order.
Re: [PATCH] drm: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
Reviewed-by: Robert Foss
On Tue, 30 Mar 2021 at 14:28, Robert Foss wrote:
>
> Hey Dafna,
>
> Thanks for submitting a cleanup patch, it is much appreciated. It
> looks good to me, feel free to add my r-b.
>
> I'm not going to merge this right away, but will let this patch soak
> for a while to let other people have a look at it.
>
> On Tue, 30 Mar 2021 at 13:52, Dafna Hirschfeld
> wrote:
> >
> > drm_bridge_funcs has a function called 'hpd_notify'.
> > The function drm_bridge_hpd_notify does not call
> > 'hpd_notify' but it calls 'hpd_cb'. This is rather
> > confusing. Rename the function to fix this confusion.
> >
> > Signed-off-by: Dafna Hirschfeld
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
> > drivers/gpu/drm/bridge/display-connector.c | 2 +-
> > drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> > drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
> > drivers/gpu/drm/drm_bridge.c| 8
> > include/drm/drm_bridge.h| 8
> > 8 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index 76555ae64e9c..748f82910f4f 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
> > cec_phys_addr_invalidate(adv7511->cec_adap);
> >
> > drm_kms_helper_hotplug_event(adv7511->connector.dev);
> > } else {
> > - drm_bridge_hpd_notify(&adv7511->bridge, status);
> > + drm_bridge_hpd_cb(&adv7511->bridge, status);
> > }
> > }
> > }
> > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > index d0c65610ebb5..682da288ff6d 100644
> > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > @@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw,
> > void *context)
> > if (mhdp->connector.dev)
> > drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> > else
> > - drm_bridge_hpd_notify(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > + drm_bridge_hpd_cb(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > }
> > }
> >
> > @@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq,
> > void *data)
> > else
> >
> > drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> > } else {
> > - drm_bridge_hpd_notify(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > + drm_bridge_hpd_cb(&mhdp->bridge,
> > cdns_mhdp_detect(mhdp));
> > }
> > }
> >
> > diff --git a/drivers/gpu/drm/bridge/display-connector.c
> > b/drivers/gpu/drm/bridge/display-connector.c
> > index 05eb759da6fc..8ccd69d7fe34 100644
> > --- a/drivers/gpu/drm/bridge/display-connector.c
> > +++ b/drivers/gpu/drm/bridge/display-connector.c
> > @@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq,
> > void *arg)
> > struct display_connector *conn = arg;
> > struct drm_bridge *bridge = &conn->bridge;
> >
> > - drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
> > + drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
> >
> > return IRQ_HANDLED;
> > }
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > index fee27952ec6d..58f61b5da605 100644
> > --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > @@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct
> > *work)
> > connected = lt9611uxc->hdmi_connected;
> > mutex_unlock(<9611uxc->ocm_lock)
[PATCH v1] drm/bridge/sii8620: fix dependency on extcon
The DRM_SIL_SII8620 kconfig has a weak `imply` dependency on EXTCON, which causes issues when sii8620 is built as a builtin and EXTCON is built as a module. Th symptoms are 'undefined reference' errors caused by the symbols in EXTCON not being available to the sii8620 driver. Signed-off-by: Robert Foss Reported-by: kernel test robot --- LKP reported issue: https://lore.kernel.org/lkml/202104040604.sste2cxf-...@intel.com/ drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 7c15fc170510..204c38e87849 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -169,7 +169,7 @@ config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF select DRM_KMS_HELPER - imply EXTCON + depends on EXTCON || !EXTCON # if EXTCON=m, this cannot be built-in depends on RC_CORE || !RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.31.0.30.g398dba342d.dirty
Re: [PATCH -next] media: camss: csid: Remove redundant dev_err call in msm_csid_subdev_init()
Hi Yang,
Thanks for the fix.
Reviewed-by: Robert Foss
On Fri, 2 Apr 2021 at 11:29, Yang Yingliang wrote:
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Reported-by: Hulk Robot
> Signed-off-by: Yang Yingliang
> ---
> drivers/media/platform/qcom/camss/camss-csid.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csid.c
> b/drivers/media/platform/qcom/camss/camss-csid.c
> index 463760c29294..cc11fbfdae13 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
> @@ -568,10 +568,8 @@ int msm_csid_subdev_init(struct camss *camss, struct
> csid_device *csid,
>
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[0]);
> csid->base = devm_ioremap_resource(dev, r);
> - if (IS_ERR(csid->base)) {
> - dev_err(dev, "could not map memory\n");
> + if (IS_ERR(csid->base))
> return PTR_ERR(csid->base);
> - }
>
> /* Interrupt */
>
> --
> 2.25.1
>
RE: [PATCH v2 3/3] hpsa: add an assert to prevent from __packed reintroduction
It looks like ia64 implements atomic_t as a 64-bit value and expects atomic_t
to be 64-bit aligned, but does nothing to ensure that.
For x86, atomic_t is a 32-bit value and atomic64_t is a 64-bit value, and
the definition of atomic64_t is overridden in a way that ensures
64-bit (8 byte) alignment:
Generic definitions are in include/linux/types.h:
typedef struct {
int counter;
} atomic_t;
#define ATOMIC_INIT(i) { (i) }
#ifdef CONFIG_64BIT
typedef struct {
s64 counter;
} atomic64_t;
#endif
Override in arch/x86/include/asm/atomic64_32.h:
typedef struct {
s64 __aligned(8) counter;
} atomic64_t;
Perhaps ia64 needs to take over the definition of both atomic_t and atomic64_t
and do the same?
RE: [PATCH] ACPICA: Events: support fixed pcie wake event
Can you send/point us to the spec that this change is based upon?
Thanks,
Bob
-Original Message-
From: Jianmin Lv
Sent: Thursday, April 01, 2021 5:06 AM
To: Moore, Robert ; Kaneda, Erik
; Wysocki, Rafael J ; Len
Brown
Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org;
lvjianmin
Subject: [PATCH] ACPICA: Events: support fixed pcie wake event
From: lvjianmin
Some chipsets support fixed pcie wake event which is defined in the PM1 block,
such as LS7A1000 of Loongson company, so we add code to handle it.
Signed-off-by: lvjianmin
diff --git a/drivers/acpi/acpica/evevent.c b/drivers/acpi/acpica/evevent.c
index 35385148fedb..08ba368beb2d 100644
--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -185,6 +185,10 @@ u32 acpi_ev_fixed_event_detect(void)
return (int_status);
}
+ if (fixed_enable & ACPI_BITMASK_PCIEXP_WAKE_DISABLE)
+ fixed_enable &= ~ACPI_BITMASK_PCIEXP_WAKE_DISABLE;
+ else
+ fixed_enable |= ACPI_BITMASK_PCIEXP_WAKE_DISABLE;
ACPI_DEBUG_PRINT((ACPI_DB_INTERRUPTS,
"Fixed Event Block: Enable %08X Status %08X\n",
fixed_enable, fixed_status));
@@ -250,8 +254,8 @@ static u32 acpi_ev_fixed_event_dispatch(u32 event)
if (!acpi_gbl_fixed_event_handlers[event].handler) {
(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
enable_register_id,
- ACPI_DISABLE_EVENT);
-
+ event == ACPI_EVENT_PCIE_WAKE ?
+ ACPI_ENABLE_EVENT :
ACPI_DISABLE_EVENT);
ACPI_ERROR((AE_INFO,
"No installed handler for fixed event - %s (%u),
disabling",
acpi_ut_get_event_name(event), event)); diff --git
a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c index
14baa13bf848..7e7ea4c2e914 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -312,6 +312,18 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state)
[ACPI_EVENT_SLEEP_BUTTON].
status_register_id, ACPI_CLEAR_STATUS);
+ /* Enable pcie wake event if support */
+ if ((acpi_gbl_FADT.flags & ACPI_FADT_PCI_EXPRESS_WAKE)) {
+ (void)
+ acpi_write_bit_register(acpi_gbl_fixed_event_info
+ [ACPI_EVENT_PCIE_WAKE].
+ enable_register_id, ACPI_DISABLE_EVENT);
+ (void)
+ acpi_write_bit_register(acpi_gbl_fixed_event_info
+ [ACPI_EVENT_PCIE_WAKE].
+ status_register_id, ACPI_CLEAR_STATUS);
+ }
+
acpi_hw_execute_sleep_method(METHOD_PATHNAME__SST, ACPI_SST_WORKING);
return_ACPI_STATUS(status);
}
diff --git a/drivers/acpi/acpica/utglobal.c b/drivers/acpi/acpica/utglobal.c
index 59a48371a7bc..68baf16d8a02 100644
--- a/drivers/acpi/acpica/utglobal.c
+++ b/drivers/acpi/acpica/utglobal.c
@@ -186,6 +186,10 @@ struct acpi_fixed_event_info
acpi_gbl_fixed_event_info[ACPI_NUM_FIXED_EVENTS] =
ACPI_BITREG_RT_CLOCK_ENABLE,
ACPI_BITMASK_RT_CLOCK_STATUS,
ACPI_BITMASK_RT_CLOCK_ENABLE},
+ /* ACPI_EVENT_PCIE_WAKE */ {ACPI_BITREG_PCIEXP_WAKE_STATUS,
+ ACPI_BITREG_PCIEXP_WAKE_DISABLE,
+ ACPI_BITMASK_PCIEXP_WAKE_STATUS,
+ ACPI_BITMASK_PCIEXP_WAKE_DISABLE},
};
#endif /* !ACPI_REDUCED_HARDWARE */
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
92c71dfce0d5..0b6c72033487 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -714,7 +714,8 @@ typedef u32 acpi_event_type;
#define ACPI_EVENT_POWER_BUTTON 2
#define ACPI_EVENT_SLEEP_BUTTON 3
#define ACPI_EVENT_RTC 4
-#define ACPI_EVENT_MAX 4
+#define ACPI_EVENT_PCIE_WAKE5
+#define ACPI_EVENT_MAX 5
#define ACPI_NUM_FIXED_EVENTS ACPI_EVENT_MAX + 1
/*
--
2.27.0
Re: [PATCH -next] media: camss: csiphy: Remove redundant dev_err call in msm_csiphy_subdev_init()
Hey Yang,
Thanks for the patch, feel free to add my r-b.
Reviewed-by: Robert Foss
On Thu, 1 Apr 2021 at 12:33, Yang Yingliang wrote:
>
> There is an error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Reported-by: Hulk Robot
> Signed-off-by: Yang Yingliang
> ---
> drivers/media/platform/qcom/camss/camss-csiphy.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c
> b/drivers/media/platform/qcom/camss/camss-csiphy.c
> index 6ceb6d7d53d1..b3c3bf19e522 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
> @@ -593,20 +593,16 @@ int msm_csiphy_subdev_init(struct camss *camss,
>
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[0]);
> csiphy->base = devm_ioremap_resource(dev, r);
> - if (IS_ERR(csiphy->base)) {
> - dev_err(dev, "could not map memory\n");
> + if (IS_ERR(csiphy->base))
> return PTR_ERR(csiphy->base);
> - }
>
> if (camss->version == CAMSS_8x16 ||
> camss->version == CAMSS_8x96) {
> r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> res->reg[1]);
> csiphy->base_clk_mux = devm_ioremap_resource(dev, r);
> - if (IS_ERR(csiphy->base_clk_mux)) {
> - dev_err(dev, "could not map memory\n");
> + if (IS_ERR(csiphy->base_clk_mux))
> return PTR_ERR(csiphy->base_clk_mux);
> - }
> } else {
> csiphy->base_clk_mux = NULL;
> }
> --
> 2.25.1
>
Re: [PATCH v6 3/5] drm/bridge: anx7625: add MIPI DPI input feature support
Hey Xin,
This patch looks good to me, feel free to add my r-b.
Reviewed-by: Robert Foss
On Fri, 19 Mar 2021 at 07:34, Xin Ji wrote:
>
> Add MIPI rx DPI input support.
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 245 --
> drivers/gpu/drm/bridge/analogix/anx7625.h | 18 +-
> 2 files changed, 203 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 04536cc7afe7..8c514b46d361 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
> return anx7625_reg_write(ctx, client, offset, (val & (mask)));
> }
>
> -static int anx7625_write_and_or(struct anx7625_data *ctx,
> - struct i2c_client *client,
> - u8 offset, u8 and_mask, u8 or_mask)
> +static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
> {
> - int val;
> + int i, ret;
>
> - val = anx7625_reg_read(ctx, client, offset);
> - if (val < 0)
> - return val;
> + ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CONTROL_REGISTER, 0x80);
> + for (i = 0; i < 13; i++)
> + ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> +VIDEO_BIT_MATRIX_12 + i,
> +0x18 + i);
>
> - return anx7625_reg_write(ctx, client,
> -offset, (val & and_mask) | (or_mask));
> + return ret;
> }
>
> static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
> @@ -219,38 +219,6 @@ static int anx7625_video_mute_control(struct
> anx7625_data *ctx,
> return ret;
> }
>
> -static int anx7625_config_audio_input(struct anx7625_data *ctx)
> -{
> - struct device *dev = &ctx->client->dev;
> - int ret;
> -
> - /* Channel num */
> - ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
> -
> - /* FS */
> - ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_4,
> - 0xf0, AUDIO_FS_48K);
> - /* Word length */
> - ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_5,
> - 0xf0, AUDIO_W_LEN_24_24MAX);
> - /* I2S */
> - ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
> - AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
> - ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
> -AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
> - /* Audio change flag */
> - ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
> - AP_AV_STATUS, AP_AUDIO_CHG);
> -
> - if (ret < 0)
> - DRM_DEV_ERROR(dev, "fail to config audio.\n");
> -
> - return ret;
> -}
> -
> /* Reduction of fraction a/b */
> static void anx7625_reduction_of_a_fraction(unsigned long *a, unsigned long
> *b)
> {
> @@ -410,7 +378,7 @@ static int anx7625_dsi_video_timing_config(struct
> anx7625_data *ctx)
> ret |= anx7625_write_and(ctx, ctx->i2c.rx_p1_client,
> MIPI_LANE_CTRL_0, 0xfc);
> ret |= anx7625_write_or(ctx, ctx->i2c.rx_p1_client,
> - MIPI_LANE_CTRL_0, 3);
> + MIPI_LANE_CTRL_0, ctx->pdata.mipi_lanes - 1);
>
> /* Htotal */
> htotal = ctx->dt.hactive.min + ctx->dt.hfront_porch.min +
> @@ -595,6 +563,76 @@ static int anx7625_dsi_config(struct anx7625_data *ctx)
> return ret;
> }
>
> +static int anx7625_api_dpi_config(struct anx7625_data *ctx)
> +{
> + struct device *dev = &ctx->client->dev;
> + u16 freq = ctx->dt.pixelclock.min / 1000;
> + int ret;
> +
> + /* configure pixel clock */
> + ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> + PIXEL_CLOCK_L, freq & 0xFF);
> + ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
> +PIXEL_CLOCK_H, (freq >> 8));
> +
> + /* set DPI mode */
> + /* set to DPI PLL mod
Re: [PATCH] drivers: gpu: drm: bridge: fix kconfig dependency on DRM_KMS_HELPER
Hey Julian, Nice catch, this patch looks good to me. I've pushed it to drm-misc-next. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62066d3164467167fc27b2383f67d097e39bf176 On Mon, 22 Feb 2021 at 22:56, Julian Braha wrote: > > When DRM_TOSHIBA_TC358762 is enabled and DRM_KMS_HELPER is disabled, > Kbuild gives the following warning: > > WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE > Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] > Selected by [y]: > - DRM_TOSHIBA_TC358762 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE > [=y] && OF [=y] > > This is because DRM_TOSHIBA_TC358762 selects DRM_PANEL_BRIDGE, > without depending on or selecting DRM_KMS_HELPER, > despite that config option depending on DRM_KMS_HELPER. > > Signed-off-by: Julian Braha > --- > drivers/gpu/drm/bridge/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index e4110d6ca7b3..909d0a5643c2 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -183,6 +183,7 @@ config DRM_TOSHIBA_TC358762 > tristate "TC358762 DSI/DPI bridge" > depends on OF > select DRM_MIPI_DSI > + select DRM_KMS_HELPER > select DRM_PANEL_BRIDGE > help > Toshiba TC358762 DSI/DPI bridge driver. > -- > 2.27.0
Re: [PATCH v6 5/5] drm/bridge: anx7625: add HDMI audio function
Hey Xin,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Mar 2021 at 07:35, Xin Ji wrote:
>
> Add audio HDMI codec function support, enable it through device true flag
> "analogix,audio-enable".
>
> Reported-by: kernel test robot
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 227 ++
> drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
> 2 files changed, 232 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index b424a570effa..02bb169d9c57 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -30,6 +30,8 @@
> #include
> #include
>
> +#include
> +
> #include
>
> #include "anx7625.h"
> @@ -150,6 +152,20 @@ static int anx7625_write_and(struct anx7625_data *ctx,
> return anx7625_reg_write(ctx, client, offset, (val & (mask)));
> }
>
> +static int anx7625_write_and_or(struct anx7625_data *ctx,
> + struct i2c_client *client,
> + u8 offset, u8 and_mask, u8 or_mask)
> +{
> + int val;
> +
> + val = anx7625_reg_read(ctx, client, offset);
> + if (val < 0)
> + return val;
> +
> + return anx7625_reg_write(ctx, client,
> +offset, (val & and_mask) | (or_mask));
> +}
> +
> static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
> {
> int i, ret;
> @@ -1498,6 +1514,9 @@ static int anx7625_parse_dt(struct device *dev,
> else
> DRM_DEV_DEBUG_DRIVER(dev, "found MIPI DSI host node.\n");
>
> + if (of_property_read_bool(np, "analogix,audio-enable"))
> + pdata->audio_en = 1;
> +
> ret = drm_of_find_panel_or_bridge(np, 1, 0, &panel, NULL);
> if (ret < 0) {
> if (ret == -ENODEV)
> @@ -1568,6 +1587,208 @@ static enum drm_connector_status
> anx7625_sink_detect(struct anx7625_data *ctx)
> connector_status_disconnected;
> }
>
> +static int anx7625_audio_hw_params(struct device *dev, void *data,
> + struct hdmi_codec_daifmt *fmt,
> + struct hdmi_codec_params *params)
> +{
> + struct anx7625_data *ctx = dev_get_drvdata(dev);
> + int wl, ch, rate;
> + int ret = 0;
> +
> + if (fmt->fmt != HDMI_DSP_A) {
> + DRM_DEV_ERROR(dev, "only supports DSP_A\n");
> + return -EINVAL;
> + }
> +
> + DRM_DEV_DEBUG_DRIVER(dev, "setting %d Hz, %d bit, %d channels\n",
> +params->sample_rate, params->sample_width,
> +params->cea.channels);
> +
> + ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_6,
> + ~I2S_SLAVE_MODE,
> + TDM_SLAVE_MODE);
> +
> + /* Word length */
> + switch (params->sample_width) {
> + case 16:
> + wl = AUDIO_W_LEN_16_20MAX;
> + break;
> + case 18:
> + wl = AUDIO_W_LEN_18_20MAX;
> + break;
> + case 20:
> + wl = AUDIO_W_LEN_20_20MAX;
> + break;
> + case 24:
> + wl = AUDIO_W_LEN_24_24MAX;
> + break;
> + default:
> + DRM_DEV_DEBUG_DRIVER(dev, "wordlength: %d bit not support",
> +params->sample_width);
> + return -EINVAL;
> + }
> + ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
> + AUDIO_CHANNEL_STATUS_5,
> + 0xf0, wl);
> +
> + /* Channel num */
> + switch (params->cea.channels) {
> + case 2:
> + ch = I2S_CH_2;
> + break;
> + case 4:
> + ch = TDM_CH_4;
> + break;
> + case 6:
> + ch = TDM_CH_6;
> + break;
> + case 8:
> + ch = TDM_CH_8;
> + break;
> + default:
> + DRM_DEV_DEBUG_DRIVER(dev, "channel number: %d not support",
> +params->cea.channels);
> + return -EINVAL;
> + }
> + ret |= anx7625_write_and_or(ctx, ctx
Re: [PATCH v6 1/5] dt-bindings:drm/bridge:anx7625:add vendor define flags
Hey Xin,
This series no longer applies to drm-misc/drm-misc-next, please rebase it.
On Wed, 24 Mar 2021 at 08:52, Xin Ji wrote:
>
> On Sun, Mar 21, 2021 at 02:00:38PM +0200, Laurent Pinchart wrote:
> > Hi Xin,
> >
> > Thank you for the patch.
> >
> > On Fri, Mar 19, 2021 at 02:32:39PM +0800, Xin Ji wrote:
> > > Add 'bus-type' and 'data-lanes' define for port0. Define DP tx lane0,
> > > lane1 swing register array define, and audio enable flag.
> > >
> > > Signed-off-by: Xin Ji
> > > ---
> > > .../display/bridge/analogix,anx7625.yaml | 58 ++-
> > > 1 file changed, 57 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index c789784efe30..3f54d5876982 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -34,6 +34,26 @@ properties:
> > > description: used for reset chip control, RESET_N pin B7.
> > > maxItems: 1
> > >
> > > + analogix,lane0-swing:
> > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > +minItems: 1
> > > +maxItems: 20
> > > +description:
> > > + an array of swing register setting for DP tx lane0 PHY, please
> > > don't
> > > + add this property, or contact vendor.
> >
> > DT properties need to be documented. Contacting the vendor doesn't count
> > as documentation I'm afraid.
>
> Hi Laurent Pinchart, thanks for your comment. For the DP phy swing
> setting, it is hard to describe in here, needs to refer the anx7625
> datasheet and programming guide. Basically, no need to change the DP phy
> swing setting.
>
Laurent is right. But if the value practically is a constant, you can
move the swing register into the driver. It should still be documented
as well as possible, but we can be a little bit more flexible.
> > > @@ -73,6 +123,10 @@ examples:
> > > enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > > reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > >
> > > +analogix,audio-enable;
> > > +analogix,lane0-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77
> > > 0x5b>;
> > > +analogix,lane1-swing = <0x14 0x54 0x64 0x74 0x29 0x7b 0x77
> > > 0x5b>;
> > > +
> > > ports {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
[PATCH v1] arm64: dts: qcom: sm8350: Add support for PRNG EE
RNG (Random Number Generator) in SM8350 features PRNG EE (Execution
Environment), hence add devicetree support for it.
Signed-off-by: Robert Foss
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index ea285147e43f..2a3ebf6964f4 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -673,6 +673,13 @@ tx {
};
};
+ rng: rng@10d3000 {
+ compatible = "qcom,prng-ee";
+ reg = <0 0x010d3000 0 0x1000>;
+ clocks = <&rpmhcc RPMH_HWKM_CLK>;
+ clock-names = "core";
+ };
+
intc: interrupt-controller@17a0 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
2.31.0.30.g398dba342d.dirty
Re: [RESEND PATCH v4 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
Hey Hsin-Yi,
Thanks for the reminder, just merged the series.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2f240cdb23e9cde551d99c77f4e60062188d8d81
On Thu, 1 Apr 2021 at 07:32, Hsin-Yi Wang wrote:
>
> anx7625 requires 3 power supply regulators.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Rob Herring
> Reviewed-by: Robert Foss
> ---
> v3->v4: rebase to drm-misc/for-linux-next
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index c789784efe306..ab48ab2f4240d 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -34,6 +34,15 @@ properties:
> description: used for reset chip control, RESET_N pin B7.
> maxItems: 1
>
> + vdd10-supply:
> +description: Regulator that provides the supply 1.0V power.
> +
> + vdd18-supply:
> +description: Regulator that provides the supply 1.8V power.
> +
> + vdd33-supply:
> +description: Regulator that provides the supply 3.3V power.
> +
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> @@ -55,6 +64,9 @@ properties:
> required:
>- compatible
>- reg
> + - vdd10-supply
> + - vdd18-supply
> + - vdd33-supply
>- ports
>
> additionalProperties: false
> @@ -72,6 +84,9 @@ examples:
> reg = <0x58>;
> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> +vdd10-supply = <&pp1000_mipibrdg>;
> +vdd18-supply = <&pp1800_mipibrdg>;
> +vdd33-supply = <&pp3300_mipibrdg>;
>
> ports {
> #address-cells = <1>;
> --
> 2.31.0.291.g576ba9dcdaf-goog
>
Re: Candidate Linux ABI for Intel AMX and hypothetical new related features
For the record, the benefits of dynamic XCR0 for rr recording portability still apply. I guess it'd be useful for CRIU too. We would also benefit from anything that incentivizes increased support for CPUID faulting. Rob -- Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew hcihw, gninnigeb eht morf saw hcihw taht.
Re: [PATCH v2 1/1] i2c: drivers: Use generic definitions for bus frequencies (part 2)
Hey Andy,
This patch looks good to me.
Reviewed-by: Robert Foss
On Wed, 31 Mar 2021 at 12:46, Andy Shevchenko
wrote:
>
> Since we have generic definitions for bus frequencies, let's use them.
>
> Cc: Wolfram Sang
> Signed-off-by: Andy Shevchenko
> Acked-by: Khalil Blaiech
> ---
> v2: added tag (Khalil), converted one missed place in DesignWare driver
> drivers/i2c/busses/i2c-designware-master.c | 2 +-
> drivers/i2c/busses/i2c-mlxbf.c | 14 --
> drivers/i2c/busses/i2c-qcom-cci.c | 4 ++--
> 3 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-master.c
> b/drivers/i2c/busses/i2c-designware-master.c
> index dd27b9dbe931..3f4d2124e0fc 100644
> --- a/drivers/i2c/busses/i2c-designware-master.c
> +++ b/drivers/i2c/busses/i2c-designware-master.c
> @@ -78,7 +78,7 @@ static int i2c_dw_set_timings_master(struct dw_i2c_dev *dev)
> * difference is the timing parameter values since the registers are
> * the same.
> */
> - if (t->bus_freq_hz == 100) {
> + if (t->bus_freq_hz == I2C_MAX_FAST_MODE_PLUS_FREQ) {
> /*
> * Check are Fast Mode Plus parameters available. Calculate
> * SCL timing parameters for Fast Mode Plus if not set.
> diff --git a/drivers/i2c/busses/i2c-mlxbf.c b/drivers/i2c/busses/i2c-mlxbf.c
> index 2fb0532d8a16..80ab831df349 100644
> --- a/drivers/i2c/busses/i2c-mlxbf.c
> +++ b/drivers/i2c/busses/i2c-mlxbf.c
> @@ -172,12 +172,6 @@
> #define MLXBF_I2C_SMBUS_THIGH_MAX_TBUF0x14
> #define MLXBF_I2C_SMBUS_SCL_LOW_TIMEOUT 0x18
>
> -enum {
> - MLXBF_I2C_TIMING_100KHZ = 10,
> - MLXBF_I2C_TIMING_400KHZ = 40,
> - MLXBF_I2C_TIMING_1000KHZ = 100,
> -};
> -
> /*
> * Defines SMBus operating frequency and core clock frequency.
> * According to ADB files, default values are compliant to 100KHz SMBus
> @@ -1202,7 +1196,7 @@ static int mlxbf_i2c_init_timings(struct
> platform_device *pdev,
>
> ret = device_property_read_u32(dev, "clock-frequency", &config_khz);
> if (ret < 0)
> - config_khz = MLXBF_I2C_TIMING_100KHZ;
> + config_khz = I2C_MAX_STANDARD_MODE_FREQ;
>
> switch (config_khz) {
> default:
> @@ -1210,15 +1204,15 @@ static int mlxbf_i2c_init_timings(struct
> platform_device *pdev,
> pr_warn("Illegal value %d: defaulting to 100 KHz\n",
> config_khz);
> fallthrough;
> - case MLXBF_I2C_TIMING_100KHZ:
> + case I2C_MAX_STANDARD_MODE_FREQ:
> config_idx = MLXBF_I2C_TIMING_CONFIG_100KHZ;
> break;
>
> - case MLXBF_I2C_TIMING_400KHZ:
> + case I2C_MAX_FAST_MODE_FREQ:
> config_idx = MLXBF_I2C_TIMING_CONFIG_400KHZ;
> break;
>
> - case MLXBF_I2C_TIMING_1000KHZ:
> + case I2C_MAX_FAST_MODE_PLUS_FREQ:
> config_idx = MLXBF_I2C_TIMING_CONFIG_1000KHZ;
> break;
> }
> diff --git a/drivers/i2c/busses/i2c-qcom-cci.c
> b/drivers/i2c/busses/i2c-qcom-cci.c
> index 1c259b5188de..c63d5545fc2a 100644
> --- a/drivers/i2c/busses/i2c-qcom-cci.c
> +++ b/drivers/i2c/busses/i2c-qcom-cci.c
> @@ -569,9 +569,9 @@ static int cci_probe(struct platform_device *pdev)
> cci->master[idx].mode = I2C_MODE_STANDARD;
> ret = of_property_read_u32(child, "clock-frequency", &val);
> if (!ret) {
> - if (val == 40)
> + if (val == I2C_MAX_FAST_MODE_FREQ)
> cci->master[idx].mode = I2C_MODE_FAST;
> - else if (val == 100)
> + else if (val == I2C_MAX_FAST_MODE_PLUS_FREQ)
> cci->master[idx].mode = I2C_MODE_FAST_PLUS;
> }
>
> --
> 2.30.2
>
Re: [PATCH v6 13/14] drm/bridge: imx: Add LDB support for i.MX8qm
On Wed, 31 Mar 2021 at 08:41, Liu Ying wrote: > > Hi Robert, > > On Tue, 2021-03-30 at 12:05 +0200, Robert Foss wrote: > > Hey Liu, > > > > checkpatch --strict lists some nits for this patch with those and the > > below warning fixed, feel free to add my r-b. > > Thanks for your review. > > Will fix those nits in the next version. > > Regarding the warning you mentioned, is it the Kconfig warning? > I'm asssuming it can also be ignored just like the one for patch 12/14? Yes, that's correct. And I'm ok with disregarding it. > > Liu Ying > > > > > On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote: > > > This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB) > > > which is officially named as pixel mapper. The LDB has two channels. > > > Each of them supports up to 30bpp parallel input color format and can > > > map the input to VESA or JEIDA standards. The two channels can be used > > > simultaneously, either in dual mode or split mode. In dual mode, the > > > two channels output identical data. In split mode, channel0 outputs > > > odd pixels and channel1 outputs even pixels. This patch supports the > > > LDB single mode and split mode. > > > > > > Signed-off-by: Liu Ying > > > --- > > > Note that this patch depends on the patch 'phy: Add LVDS configuration > > > options', > > > which has already been sent with the following series to add Mixel combo > > > PHY > > > found in i.MX8qxp: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-kernel%2Fmsg879957.html&data=04%7C01%7Cvictor.liu%40nxp.com%7C8d7bbad6a7884d28c2b108d8f3635586%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637526955256377476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FlBdn8%2FdU3tbJC5W%2B4qCIBv1UO6b8I97MnOFhOXiBy4%3D&reserved=0 > > > > > > v5->v6: > > > * No change. > > > > > > v4->v5: > > > * Link with the imx-ldb-helper object. (Robert) > > > * Correspondingly, rename 'imx8qm-ldb.c' to 'imx8qm-ldb-drv.c'. > > > > > > v3->v4: > > > * No change. > > > > > > v2->v3: > > > * No change. > > > > > > v1->v2: > > > * Drop unnecessary check for maximum available LDB channels. > > > * Mention i.MX8qm LDB official name 'pixel mapper' in the bridge driver > > > and Kconfig help message. > > > > > > drivers/gpu/drm/bridge/imx/Kconfig | 9 + > > > drivers/gpu/drm/bridge/imx/Makefile | 3 + > > > drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 586 > > > > > > 3 files changed, 598 insertions(+) > > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c > > > > > > diff --git a/drivers/gpu/drm/bridge/imx/Kconfig > > > b/drivers/gpu/drm/bridge/imx/Kconfig > > > index 94f8db4d..3a8683f 100644 > > > --- a/drivers/gpu/drm/bridge/imx/Kconfig > > > +++ b/drivers/gpu/drm/bridge/imx/Kconfig > > > @@ -1,3 +1,12 @@ > > > +config DRM_IMX8QM_LDB > > > + tristate "Freescale i.MX8QM LVDS display bridge" > > > + depends on OF > > > + depends on COMMON_CLK > > > + select DRM_KMS_HELPER > > > + help > > > + Choose this to enable the internal LVDS Display Bridge(LDB) > > > found in > > > + Freescale i.MX8qm processor. Official name of LDB is pixel > > > mapper. > > > + > > > config DRM_IMX8QXP_LDB > > > tristate "Freescale i.MX8QXP LVDS display bridge" > > > depends on OF > > > diff --git a/drivers/gpu/drm/bridge/imx/Makefile > > > b/drivers/gpu/drm/bridge/imx/Makefile > > > index 96d5d1e..aa90ec8 100644 > > > --- a/drivers/gpu/drm/bridge/imx/Makefile > > > +++ b/drivers/gpu/drm/bridge/imx/Makefile > > > @@ -1,3 +1,6 @@ > > > +imx8qm-ldb-objs := imx-ldb-helper.o imx8qm-ldb-drv.o > > > +obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o > > > + > > > imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o > > > obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o > > > > > > diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c > > > b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c > > > new file mode 100644 > > > index ..6c92636
Re: [PATCH] drm: bridge: rename the function drm_bridge_hpd_notify to drm_bridge_hpd_cb
Hey Dafna,
Thanks for submitting a cleanup patch, it is much appreciated. It
looks good to me, feel free to add my r-b.
I'm not going to merge this right away, but will let this patch soak
for a while to let other people have a look at it.
On Tue, 30 Mar 2021 at 13:52, Dafna Hirschfeld
wrote:
>
> drm_bridge_funcs has a function called 'hpd_notify'.
> The function drm_bridge_hpd_notify does not call
> 'hpd_notify' but it calls 'hpd_cb'. This is rather
> confusing. Rename the function to fix this confusion.
>
> Signed-off-by: Dafna Hirschfeld
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c| 2 +-
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
> drivers/gpu/drm/bridge/display-connector.c | 2 +-
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
> drivers/gpu/drm/drm_bridge.c| 8
> include/drm/drm_bridge.h| 8
> 8 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 76555ae64e9c..748f82910f4f 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -449,7 +449,7 @@ static void adv7511_hpd_work(struct work_struct *work)
> cec_phys_addr_invalidate(adv7511->cec_adap);
> drm_kms_helper_hotplug_event(adv7511->connector.dev);
> } else {
> - drm_bridge_hpd_notify(&adv7511->bridge, status);
> + drm_bridge_hpd_cb(&adv7511->bridge, status);
> }
> }
> }
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index d0c65610ebb5..682da288ff6d 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -794,7 +794,7 @@ static void cdns_mhdp_fw_cb(const struct firmware *fw,
> void *context)
> if (mhdp->connector.dev)
> drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> else
> - drm_bridge_hpd_notify(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> + drm_bridge_hpd_cb(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> }
> }
>
> @@ -2314,7 +2314,7 @@ static irqreturn_t cdns_mhdp_irq_handler(int irq, void
> *data)
> else
>
> drm_kms_helper_hotplug_event(mhdp->bridge.dev);
> } else {
> - drm_bridge_hpd_notify(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> + drm_bridge_hpd_cb(&mhdp->bridge,
> cdns_mhdp_detect(mhdp));
> }
> }
>
> diff --git a/drivers/gpu/drm/bridge/display-connector.c
> b/drivers/gpu/drm/bridge/display-connector.c
> index 05eb759da6fc..8ccd69d7fe34 100644
> --- a/drivers/gpu/drm/bridge/display-connector.c
> +++ b/drivers/gpu/drm/bridge/display-connector.c
> @@ -98,7 +98,7 @@ static irqreturn_t display_connector_hpd_irq(int irq, void
> *arg)
> struct display_connector *conn = arg;
> struct drm_bridge *bridge = &conn->bridge;
>
> - drm_bridge_hpd_notify(bridge, display_connector_detect(bridge));
> + drm_bridge_hpd_cb(bridge, display_connector_detect(bridge));
>
> return IRQ_HANDLED;
> }
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index fee27952ec6d..58f61b5da605 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -175,10 +175,10 @@ static void lt9611uxc_hpd_work(struct work_struct *work)
> connected = lt9611uxc->hdmi_connected;
> mutex_unlock(<9611uxc->ocm_lock);
>
> - drm_bridge_hpd_notify(<9611uxc->bridge,
> - connected ?
> - connector_status_connected :
> - connector_status_disconnected);
> + drm_bridge_hpd_cb(<9611uxc->bridge,
> + connected ?
> + connector_status_connected :
> + connector_status_disconnected);
> }
> }
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index dda4fa9a1a08..984ab5c4bc71 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -3026,7 +3026,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>
> if (hdmi->bridge.dev) {
> drm_helper_hpd_irq_event(hdmi->bridge.
Re: [PATCH v2 20/20] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
Hey Lyude,
This patch looks good, but I have one question below. With it
addressed, feel free to add my r-b.
Reviewed-by: Robert Foss
>
> -static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
> +static bool drm_dp_sideband_parse_req(const struct drm_dp_mst_topology_mgr
> *mgr,
> + struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_req_body
> *msg)
> {
> memset(msg, 0, sizeof(*msg));
> @@ -1117,12 +1125,12 @@ static bool drm_dp_sideband_parse_req(struct
> drm_dp_sideband_msg_rx *raw,
>
> switch (msg->req_type) {
> case DP_CONNECTION_STATUS_NOTIFY:
> - return drm_dp_sideband_parse_connection_status_notify(raw,
> msg);
> + return drm_dp_sideband_parse_connection_status_notify(mgr,
> raw, msg);
> case DP_RESOURCE_STATUS_NOTIFY:
> - return drm_dp_sideband_parse_resource_status_notify(raw, msg);
> + return drm_dp_sideband_parse_resource_status_notify(mgr, raw,
> msg);
> default:
> - DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
> - drm_dp_mst_req_type_str(msg->req_type));
> + drm_err(mgr->dev, "Got unknown request 0x%02x (%s)\n",
> + msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> return false;
> }
> }
>
.. snip ..
> @@ -4118,12 +4121,12 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)
>
> INIT_LIST_HEAD(&up_req->next);
>
> - drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
> + drm_dp_sideband_parse_req(mgr, &mgr->up_req_recv, &up_req->msg);
drm_dp_sideband_parse_req() is only called here, and the function
arguments could probably stand to have `&mgr->up_req_recv` removed
(here and in the func. declaration) since the same data structure is
accessible through the `mgr` pointer inside of
drm_dp_sideband_parse_req(). I guess this is a matter of taste, so
feel free to do what you want with this.
>
> if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
> up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
> - DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
> - up_req->msg.req_type);
> + drm_dbg_kms(mgr->dev, "Received unknown up req type,
> ignoring: %x\n",
> + up_req->msg.req_type);
> kfree(up_req);
> goto out;
> }
Re: [PATCH v2 19/20] drm/dp_mst: Drop DRM_ERROR() on kzalloc() fail in drm_dp_mst_handle_up_req()
Hey Lyude,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 26 Mar 2021 at 21:40, Lyude Paul wrote:
>
> Checkpatch was complaining about this - there's no need for us to print
> errors when kzalloc() fails, as kzalloc() will already WARN for us. So,
> let's fix that before converting things to make checkpatch happy.
>
> Signed-off-by: Lyude Paul
> Cc: Robert Foss
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ec2285595c33..74c420f5f204 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4113,10 +4113,9 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)
> return 0;
>
> up_req = kzalloc(sizeof(*up_req), GFP_KERNEL);
> - if (!up_req) {
> - DRM_ERROR("Not enough memory to process MST up req\n");
> + if (!up_req)
> return -ENOMEM;
> - }
> +
> INIT_LIST_HEAD(&up_req->next);
>
> drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
> --
> 2.30.2
>
Re: [PATCH v2 17/20] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
Hey Lyude,
Looks good to me.
Reviewed-by: Robert Foss
On Fri, 26 Mar 2021 at 21:40, Lyude Paul wrote:
>
> Now that we've added a back-pointer to drm_device to drm_dp_aux, made
> drm_dp_aux available to any functions in drm_dp_helper.c which need to
> print to the kernel log, and ensured all of our logging uses a consistent
> format, let's do the final step of the conversion and actually move
> everything over to using drm_err() and drm_dbg_*().
>
> This was done by using the following cocci script:
>
> @@
> expression list expr;
> @@
>
> (
> - DRM_DEBUG_KMS(expr);
> + drm_dbg_kms(aux->drm_dev, expr);
> |
> - DRM_DEBUG_DP(expr);
> + drm_dbg_dp(aux->drm_dev, expr);
> |
> - DRM_DEBUG_ATOMIC(expr);
> + drm_dbg_atomic(aux->drm_dev, expr);
> |
> - DRM_DEBUG_KMS_RATELIMITED(expr);
> + drm_dbg_kms_ratelimited(aux->drm_dev, expr);
> |
> - DRM_ERROR(expr);
> + drm_err(aux->drm_dev, expr);
> )
>
> Followed by correcting the resulting line-wrapping in the results by hand.
>
> v2:
> * Fix indenting in drm_dp_dump_access
>
> Signed-off-by: Lyude Paul
> Cc: Robert Foss
> ---
> drivers/gpu/drm/drm_dp_helper.c | 121
> 1 file changed, 59 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 54e19d7b9c51..4940db0bcaae 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
> drm_dp_aux *aux,
> DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> + drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
> (max 4)\n",
> + aux->name, rd_interval);
>
> if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> rd_interval = 100;
> @@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
> struct drm_dp_aux *aux,
> unsigned long rd_interval)
> {
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> + drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
> (max 4)\n",
> + aux->name, rd_interval);
>
> if (rd_interval == 0)
> rd_interval = 400;
> @@ -220,11 +220,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
> const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
>
> if (ret > 0)
> - DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> -aux->name, offset, arrow, ret, min(ret, 20),
> buffer);
> + drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> + aux->name, offset, arrow, ret, min(ret, 20),
> buffer);
> else
> - DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
> -aux->name, offset, arrow, ret);
> + drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
> + aux->name, offset, arrow, ret);
> }
>
> /**
> @@ -287,8 +287,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
> err = ret;
> }
>
> - DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
> - aux->name, err);
> + drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First
> error: %d\n",
> + aux->name, err);
> ret = err;
>
> unlock:
> @@ -524,44 +524,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
> *aux,
>
> if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
> &auto_test_req, 1) < 1) {
> - DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> - aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> + drm_err(aux->drm_dev, "%s: DPCD failed read at register
> 0x%x\n",
> + aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> return false;
> }
> au
Re: [PATCH v2 07/20] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
Hey Lyude,
I'm seeing no issues with this patch and the reasoning behind the
patch is sound to me.
Reviewed-by: Robert Foss
On Fri, 26 Mar 2021 at 21:39, Lyude Paul wrote:
>
> Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
> to make sure that we can also add ratelimited versions of these macros in
> order to retain some of the previous debugging output behavior we had.
>
> However, as I was preparing to do this I noticed that the current
> rate limited macros we have are kind of bogus. It looks like when I wrote
> these, I didn't notice that we'd always be calling __ratelimit() even if
> the debugging message we'd be printing would normally be filtered out due
> to the relevant DRM debugging category being disabled.
>
> So, let's fix this by making sure to check drm_debug_enabled() in our
> ratelimited macros before calling __ratelimit(), and start using
> drm_dev_printk() in order to print debugging messages since that will save
> us from doing a redundant drm_debug_enabled() check. And while we're at it,
> let's move the code for this into another macro that we can reuse for
> defining new ratelimited DRM debug macros more easily.
>
> v2:
> * Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED()
>
> Signed-off-by: Lyude Paul
> Cc: Robert Foss
> ---
> include/drm/drm_print.h | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index f32d179e139d..a3c58c941bdc 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -524,16 +524,20 @@ void __drm_err(const char *format, ...);
> #define DRM_DEBUG_DP(fmt, ...) \
> __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
>
> -
> -#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)\
> -({ \
> - static DEFINE_RATELIMIT_STATE(_rs, \
> - DEFAULT_RATELIMIT_INTERVAL, \
> - DEFAULT_RATELIMIT_BURST); \
> - if (__ratelimit(&_rs)) \
> - drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \
> +#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> \
> +({
> \
> + static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);\
> + const struct drm_device *drm_ = (drm);
> \
> +
> \
> + if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_))
> \
> + drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ##
> __VA_ARGS__); \
> })
>
> +#define drm_dbg_kms_ratelimited(drm, fmt, ...) \
> + __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
> +
> +#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL,
> fmt, ## __VA_ARGS__)
> +
> /*
> * struct drm_device based WARNs
> *
> --
> 2.30.2
>
Re: [PATCH v6 13/14] drm/bridge: imx: Add LDB support for i.MX8qm
Hey Liu,
checkpatch --strict lists some nits for this patch with those and the
below warning fixed, feel free to add my r-b.
On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote:
>
> This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 30bpp parallel input color format and can
> map the input to VESA or JEIDA standards. The two channels can be used
> simultaneously, either in dual mode or split mode. In dual mode, the
> two channels output identical data. In split mode, channel0 outputs
> odd pixels and channel1 outputs even pixels. This patch supports the
> LDB single mode and split mode.
>
> Signed-off-by: Liu Ying
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v5->v6:
> * No change.
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qm-ldb.c' to 'imx8qm-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary check for maximum available LDB channels.
> * Mention i.MX8qm LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 586
>
> 3 files changed, 598 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 94f8db4d..3a8683f 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QM_LDB
> + tristate "Freescale i.MX8QM LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qm processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_LDB
> tristate "Freescale i.MX8QXP LVDS display bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> b/drivers/gpu/drm/bridge/imx/Makefile
> index 96d5d1e..aa90ec8 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qm-ldb-objs := imx-ldb-helper.o imx8qm-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> +
> imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> new file mode 100644
> index ..6c92636
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> @@ -0,0 +1,586 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx-ldb-helper.h"
> +
> +#define LDB_CH0_10BIT_EN (1 << 22)
> +#define LDB_CH1_10BIT_EN (1 << 23)
> +#define LDB_CH0_DATA_WIDTH_24BIT (1 << 24)
> +#define LDB_CH1_DATA_WIDTH_24BIT (1 << 26)
> +#define LDB_CH0_DATA_WIDTH_30BIT (2 << 24)
> +#define LDB_CH1_DATA_WIDTH_30BIT (2 << 26)
> +
> +#define SS_CTRL0x20
> +#define CH_HSYNC_M(id)BIT(0 + ((id) * 2))
> +#define CH_VSYNC_M(id)BIT(1 + ((id) * 2))
> +#define CH_PHSYNC(id) BIT(0 + ((id) * 2))
> +#define CH_PVSYNC(id) BIT(1 + ((id) * 2))
> +
> +#define DRIVER_NAME"imx8qm-ldb"
> +
> +struct imx8qm_ldb_channel {
> + struct ldb_channel base;
> + struct phy *phy;
> +};
> +
> +struct imx8qm_ldb {
> + struct ldb base;
> + struct device *dev;
> + struct imx8qm_ldb_channel channel[MAX_LDB_CHAN_NUM];
> + struct clk *clk_pixel;
> + struct clk *clk_bypass;
> + int active_chno;
> +};
&
Re: [PATCH v6 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp
Hey Liu,
checkpatch --strict lists some nits and a warning. I think the kconfig
warning can be ignored. With the rest fixed, feel free to add my r-b.
Reviewed-by: Robert Foss
On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote:
>
> This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 24bpp parallel input color format and can map
> the input to VESA or JEIDA standards. The two channels cannot be used
> simultaneously, that is to say, the user should pick one of them to use.
> Two LDB channels from two LDB instances can work together in LDB split
> mode to support a dual link LVDS display. The channel indexes have to be
> different. Channel0 outputs odd pixels and channel1 outputs even pixels.
> This patch supports the LDB single mode and split mode.
>
> Signed-off-by: Liu Ying
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v5->v6:
> * No change.
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary DT validation.
> * Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
> get the input remote endpoint in imx8qxp_ldb_set_di_id().
> * Avoid using companion_port OF node after putting it in
> imx8qxp_ldb_parse_dt_companion().
> * Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720
> +++
> 3 files changed, 732 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 1ea1ce7..94f8db4d 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QXP_LDB
> + tristate "Freescale i.MX8QXP LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qxp processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_PIXEL_COMBINER
> tristate "Freescale i.MX8QM/QXP pixel combiner"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> b/drivers/gpu/drm/bridge/imx/Makefile
> index e74dd64..96d5d1e 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> +
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> new file mode 100644
> index ..d7f59c1
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx-ldb-helper.h"
> +
> +#define LDB_CH_SEL(1 << 28)
> +
> +#define SS_CTRL0x20
> +#define CH_HSYNC_M(id)BIT(0 + ((id) * 2))
> +#define CH_VSYNC_M(id)BIT(1 + ((id) * 2))
> +#define CH_PHSYNC(id) BIT(0 + ((id) * 2))
> +#define CH_PVSYNC(id) BIT(1 + ((id) * 2))
> +
> +#define DRIVER_NAME"imx8qxp-ldb"
> +
> +struct imx8qxp_ldb_channel {
> + struct ldb_channel base;
> + struct phy *phy;
> + unsigned int di_id;
> +};
> +
> +struct imx8qxp_ldb {
> + struct ldb base;
> + struct device *dev;
> + struct im
Re: [PATCH v6 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp
Hey Liu,
checkpatch --strict lists some nit and a warning. With those fixed
feel free to add my r-b.
On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote:
>
> This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 24bpp parallel input color format and can map
> the input to VESA or JEIDA standards. The two channels cannot be used
> simultaneously, that is to say, the user should pick one of them to use.
> Two LDB channels from two LDB instances can work together in LDB split
> mode to support a dual link LVDS display. The channel indexes have to be
> different. Channel0 outputs odd pixels and channel1 outputs even pixels.
> This patch supports the LDB single mode and split mode.
>
> Signed-off-by: Liu Ying
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v5->v6:
> * No change.
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary DT validation.
> * Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
> get the input remote endpoint in imx8qxp_ldb_set_di_id().
> * Avoid using companion_port OF node after putting it in
> imx8qxp_ldb_parse_dt_companion().
> * Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720
> +++
> 3 files changed, 732 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 1ea1ce7..94f8db4d 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QXP_LDB
> + tristate "Freescale i.MX8QXP LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qxp processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_PIXEL_COMBINER
> tristate "Freescale i.MX8QM/QXP pixel combiner"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> b/drivers/gpu/drm/bridge/imx/Makefile
> index e74dd64..96d5d1e 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> +
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> new file mode 100644
> index ..d7f59c1
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx-ldb-helper.h"
> +
> +#define LDB_CH_SEL(1 << 28)
> +
> +#define SS_CTRL0x20
> +#define CH_HSYNC_M(id)BIT(0 + ((id) * 2))
> +#define CH_VSYNC_M(id)BIT(1 + ((id) * 2))
> +#define CH_PHSYNC(id) BIT(0 + ((id) * 2))
> +#define CH_PVSYNC(id) BIT(1 + ((id) * 2))
> +
> +#define DRIVER_NAME"imx8qxp-ldb"
> +
> +struct imx8qxp_ldb_channel {
> + struct ldb_channel base;
> + struct phy *phy;
> + unsigned int di_id;
> +};
> +
> +struct imx8qxp_ldb {
> + struct ldb base;
> + struct device *dev;
> + struct imx8qxp_ldb_channel channel[MAX_LDB_CHAN_NUM];
> + struct clk *clk_pi
Re: [PATCH v6 14/14] MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs
Hey Liu, Reviewed-by: Robert Foss On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote: > > Add myself as the maintainer of DRM bridge drivers for i.MX SoCs. > > Signed-off-by: Liu Ying > --- > v5->v6: > * No change. > > v4->v5: > * No change. > > v3->v4: > * No change. > > v2->v3: > * No change. > > v1->v2: > * No change. > > MAINTAINERS | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4b705ba..488e0ef 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5939,6 +5939,16 @@ F: Documentation/devicetree/bindings/display/imx/ > F: drivers/gpu/drm/imx/ > F: drivers/gpu/ipu-v3/ > > +DRM DRIVERS FOR FREESCALE IMX BRIDGE > +M: Liu Ying > +L: dri-de...@lists.freedesktop.org > +S: Maintained > +F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml > +F: > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml > +F: > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml > +F: > Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml > +F: drivers/gpu/drm/bridge/imx/ > + > DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) > M: Patrik Jakobsson > L: dri-de...@lists.freedesktop.org > -- > 2.7.4 >
Re: [PATCH v6 10/14] drm/bridge: imx: Add LDB driver helper support
Hey Liu,
checkpatch --strict is listing some nits for this patch, with those
fixed feel free to add my r-b.
Reviewed-by: Robert Foss
On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote:
>
> This patch adds a helper to support LDB drm bridge drivers for
> i.MX SoCs. Helper functions supported by this helper should
> implement common logics for all LDB modules embedded in i.MX SoCs.
>
> Signed-off-by: Liu Ying
> ---
> v5->v6:
> * No change.
>
> v4->v5:
> * Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
> driver and i.MX8qm LDB bridge driver. (Robert)
> * Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
> (Robert)
> * s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * Call syscon_node_to_regmap() to get regmap instead of
> syscon_regmap_lookup_by_phandle().
>
> v1->v2:
> * No change.
>
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232
>
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.h | 98
> 2 files changed, 330 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> new file mode 100644
> index ..d01c4ff9
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> @@ -0,0 +1,232 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2012 Sascha Hauer, Pengutronix
> + * Copyright 2019,2020 NXP
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include "imx-ldb-helper.h"
> +
> +bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
> +}
> +
> +bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
> + ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
> +}
> +
> +int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> +
> + ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
> + ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
> +
> + return 0;
> +}
> +
> +void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> + struct ldb *ldb = ldb_ch->ldb;
> + bool is_split = ldb_channel_is_split_link(ldb_ch);
> +
> + if (is_split)
> + ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
> +
> + switch (ldb_ch->out_bus_format) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
> +LDB_BIT_MAP_CH0_JEIDA;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
> +LDB_BIT_MAP_CH1_JEIDA;
> + break;
> + }
> +}
> +
> +void ldb_bridge_enable_helper(struct drm_bridge *bridge)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> + struct ldb *ldb = ldb_ch->ldb;
> +
> + /*
> +* Platform specific bridge drivers should set ldb_ctrl properly
> +* for the enablement, so just write the ctrl_reg here.
> +*/
> + regmap_write(ldb->regmap, ldb->ctrl_reg, ldb->ldb_ctrl);
> +}
> +
> +void ldb_bridge_disable_helper(struct drm_bridge *bridge)
> +{
>
Re: [PATCH v6 09/14] drm/bridge: imx: Add i.MX8qxp pixel link to DPI support
Hey Liu,
checkpatch --strict had some complaints, with those fixed feel free to
add my r-b.
Reviewed-by: Robert Foss
On Wed, 17 Mar 2021 at 04:57, Liu Ying wrote:
>
> This patch adds a drm bridge driver for i.MX8qxp pixel link to display
> pixel interface(PXL2DPI). The PXL2DPI interfaces the pixel link 36-bit
> data output and the DSI controller’s MIPI-DPI 24-bit data input, and
> inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
> the pixel color codings between those modules. The PXL2DPI is purely
> combinatorial.
>
> Signed-off-by: Liu Ying
> ---
> v5->v6:
> * No change.
>
> v4->v5:
> * No change.
>
> v3->v4:
> * Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
> the PXL2DPI instance instead of using alias ID. (Rob)
>
> v2->v3:
> * Call syscon_node_to_regmap() to get regmap instead of
> syscon_regmap_lookup_by_phandle().
>
> v1->v2:
> * Drop unnecessary port availability check.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 8 +
> drivers/gpu/drm/bridge/imx/Makefile | 1 +
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 485
> +++
> 3 files changed, 494 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 4d1f027..1ea1ce7 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -14,3 +14,11 @@ config DRM_IMX8QXP_PIXEL_LINK
> help
> Choose this to enable display pixel link found in
> Freescale i.MX8qm/qxp processors.
> +
> +config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
> + tristate "Freescale i.MX8QXP pixel link to display pixel interface"
> + depends on OF
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable pixel link to display pixel interface(PXL2DPI)
> + found in Freescale i.MX8qxp processor.
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> b/drivers/gpu/drm/bridge/imx/Makefile
> index c15469f..e74dd64 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> +obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> new file mode 100644
> index ..6696855
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -0,0 +1,485 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define PXL2DPI_CTRL 0x40
> +#define CFG1_16BIT0x0
> +#define CFG2_16BIT0x1
> +#define CFG3_16BIT0x2
> +#define CFG1_18BIT0x3
> +#define CFG2_18BIT0x4
> +#define CFG_24BIT 0x5
> +
> +#define DRIVER_NAME"imx8qxp-pxl2dpi"
> +
> +struct imx8qxp_pxl2dpi {
> + struct regmap *regmap;
> + struct drm_bridge bridge;
> + struct drm_bridge *next_bridge;
> + struct drm_bridge *companion;
> + struct device *dev;
> + struct imx_sc_ipc *ipc_handle;
> + u32 sc_resource;
> + u32 in_bus_format;
> + u32 out_bus_format;
> + u32 pl_sel;
> +};
> +
> +#define bridge_to_p2d(b) container_of(b, struct imx8qxp_pxl2dpi,
> bridge)
> +
> +static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + DRM_DEV_ERROR(p2d->dev,
> + "do not support creating a drm_connector\n");
> + return -EINVAL;
> + }
> +
> + if (!bridge->encoder) {
> + DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
> + return -ENODEV;
> + }
> +
> + return drm_bridge_attach(bridge->encoder,
> +p2d->next_bridge, bridge,
> +DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +}
> +
> +static int
> +imx8qxp_pxl2dpi_bridge_atomic_check(st
RE: [PATCH] ACPICA: Fix a typo
Please make a pull request for this on our github. Thanks, Bob -Original Message- From: Bhaskar Chowdhury Sent: Thursday, March 25, 2021 5:19 PM To: Moore, Robert ; Kaneda, Erik ; Wysocki, Rafael J ; l...@kernel.org; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org Cc: rdun...@infradead.org; Bhaskar Chowdhury Subject: [PATCH] ACPICA: Fix a typo s/optimzation/optimization/ Signed-off-by: Bhaskar Chowdhury --- include/acpi/acoutput.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acoutput.h b/include/acpi/acoutput.h index 1538a6853822..1b4c45815695 100644 --- a/include/acpi/acoutput.h +++ b/include/acpi/acoutput.h @@ -362,7 +362,7 @@ * * A less-safe version of the macros is provided for optional use if the * compiler uses excessive CPU stack (for example, this may happen in the - * debug case if code optimzation is disabled.) + * debug case if code optimization is disabled.) */ /* Exit trace helper macro */ -- 2.26.2
Re: [PATCH v9 0/2] Add support of Lontium lt8912 MIPI to HDMI bridge
Pushed: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=3aa6031deefa9a2c056af2182af02d3dc5df1067 On Fri, 26 Mar 2021 at 13:20, Adrien Grassein wrote: > > Hi, > this patch set adds the support of the Lontium lt8912 MIPI to HDMI > bridge in the kernel. > > It's only support the video part, not the audio part yet > since I don't have the datasheet of this component. > I get the current i2c configuration from Digi and > Boundary drivers. > Developed using the DB_DSIHD board from BoundaryDevices. > > Update in v2 > - Use standard data-lanes instead of a custom prop; > - Use hdmi-connector node. > > Update in v3 > - Fix indentation; > - Implement missing bridge functions; > - Add some comments. > > Update in v4 > - Fix bridge ops; > - Fix i2c error detection. > > Update in v5 > - Fix lt8912 name (lt8912b instead of lt8912); > - Implement HPD via a workaround. In fact I don't have the datasheet > of this component yet so I can't say if the configuration of the > registers is correct or if I have an HW issue on my board. So, I choose > to implement a fake version of HPD using a workqueue and polling the > status regularly. > > Update in v6 > - Fix a warning found by "kernel test robot" > > Update in v7 > - Fix HPD logic (via an HW emulation); > - HPD from chip is still not working. > > Update in v8 > - Remove HPD logic (will be added later when HW bug qill be fixed). > > Update in v9 > - Fix errors found in scripts/checkpatch.pl --strict > > Thanks, > > Adrien Grassein (2): > dt-bindings: display: bridge: Add documentation for LT8912B > drm/bridge: Introduce LT8912B DSI to HDMI bridge > > .../display/bridge/lontium,lt8912b.yaml | 102 +++ > MAINTAINERS | 6 + > drivers/gpu/drm/bridge/Kconfig| 14 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/lontium-lt8912b.c | 765 ++ > 5 files changed, 888 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912b.c > > -- > 2.25.1 >
Re: [PATCH v5 1/2] dt-bindings: display: bridge: Add Chipone ICN6211 bindings
Pushed to drm-misc-next
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a42e37db23b88120aea9fa31f9c0952accb39296
On Mon, 22 Mar 2021 at 11:33, Jagan Teki wrote:
>
> ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
>
> It has a flexible configuration of MIPI DSI signal input and
> produces RGB565, RGB666, RGB888 output format.
>
> Add dt-bingings for it.
>
> Signed-off-by: Jagan Teki
> Reviewed-by: Robert Foss
> Reviewed-by: Rob Herring
> ---
> Changes for v5:
> - rebase drm-misc-next
> - collect Rob, Robert review tags
> Changes for v4:
> - fixed Laurent comments
> - added regulators
> - replace reset with EN
> - fixed warnings pointed by Robert
> Changes for v3:
> - updated to new dt-bindings style
>
> .../display/bridge/chipone,icn6211.yaml | 99 +++
> MAINTAINERS | 5 +
> 2 files changed, 104 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> new file mode 100644
> index ..62c3bd4cb28d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge
> +
> +maintainers:
> + - Jagan Teki
> +
> +description: |
> + ICN6211 is MIPI-DSI to RGB Converter bridge from chipone.
> +
> + It has a flexible configuration of MIPI DSI signal input and
> + produce RGB565, RGB666, RGB888 output format.
> +
> +properties:
> + compatible:
> +enum:
> + - chipone,icn6211
> +
> + reg:
> +maxItems: 1
> +description: virtual channel number of a DSI peripheral
> +
> + enable-gpios:
> +description: Bridge EN pin, chip is reset when EN is low.
> +
> + vdd1-supply:
> +description: A 1.8V/2.5V/3.3V supply that power the MIPI RX.
> +
> + vdd2-supply:
> +description: A 1.8V/2.5V/3.3V supply that power the PLL.
> +
> + vdd3-supply:
> +description: A 1.8V/2.5V/3.3V supply that power the RGB output.
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Video port for MIPI DSI input
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Video port for MIPI DPI output (panel or connector).
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bridge@0 {
> +compatible = "chipone,icn6211";
> +reg = <0>;
> +enable-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
> +
> +ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +reg = <0>;
> +
> +bridge_in_dsi: endpoint {
> + remote-endpoint = <&dsi_out_bridge>;
> +};
> + };
> +
> + port@1 {
> +reg = <1>;
> +
> +bridge_out_panel: endpoint {
> + remote-endpoint = <&panel_out_bridge>;
> +};
> + };
> +};
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b705ba51c54..b9d11101d060 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5568,6 +5568,11 @@ S: Maintained
> F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
> F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
>
> +DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTER BRIDGE
> +M: Jagan Teki
> +S: Maintained
> +F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> +
> DRM DRIVER FOR FARADAY TVE200 TV ENCODER
> M: Linus Walleij
> S: Maintained
> --
> 2.25.1
>
Re: [PATCH] drm: bridge: convert sysfs sprintf/snprintf family to sysfs_emit
Pushed to drm-misc-next
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=fffa69aa6b1c89853cd00dea969e4754633596d7
On Sun, 7 Feb 2021 at 10:12, Jiapeng Chong
wrote:
>
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c:858:8-16: WARNING: use
> scnprintf or sprintf.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index fee2795..3cac16d 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -855,7 +855,7 @@ static ssize_t lt9611uxc_firmware_show(struct device
> *dev, struct device_attribu
> {
> struct lt9611uxc *lt9611uxc = dev_get_drvdata(dev);
>
> - return snprintf(buf, PAGE_SIZE, "%02x\n", lt9611uxc->fw_version);
> + return sysfs_emit(buf, "%02x\n", lt9611uxc->fw_version);
> }
>
> static DEVICE_ATTR_RW(lt9611uxc_firmware);
> --
> 1.8.3.1
>
[PATCH v2] MAINTAINERS: Update Maintainers of DRM Bridge Drivers
Add myself as co-maintainer of DRM Bridge Drivers. Repository commit access has already been granted. https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338 Cc: Neil Armstrong Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Andrzej Hajda Cc: Jernej Škrabec Cc: Daniel Vetter Signed-off-by: Robert Foss Acked-by: Neil Armstrong Acked-by: Maxime Ripard Acked-by: Laurent Pinchart Acked-by: Andrzej Hajda --- Add maintainer Acks. Submitted to follow proper dim workflow. MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b705ba51c54..16ace8f58649 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5902,6 +5902,7 @@ F:drivers/gpu/drm/atmel-hlcdc/ DRM DRIVERS FOR BRIDGE CHIPS M: Andrzej Hajda M: Neil Armstrong +M: Robert Foss R: Laurent Pinchart R: Jonas Karlman R: Jernej Skrabec -- 2.31.0.30.g398dba342d.dirty
Re: [PATCH] cxl/mem: Force array size of mem_commands[] to CXL_MEM_COMMAND_ID_MAX
On 24.03.21 12:08:20, Dan Williams wrote: > On Wed, Mar 24, 2021 at 11:43 AM Ira Weiny wrote: > > Can't we use ARRAY_SIZE? > > An ARRAY_SIZE() check in cxl_validate_cmd_from_user() would work too, > but it wouldn't give the compiler protection that Robert mentions for > going the other way where mem_commands tries to add an entry that is > out of bounds relative to CXL_CMDS. I was considering that too. Another reason apart from above was to treat 'holes' in the array caused by #ifdefs the same regardless its position in the array. Thus, all should show up as being zeroed instead of cutting those at the end from the array. Thanks for applying, -Robert
[PATCH] cxl/mem: Force array size of mem_commands[] to CXL_MEM_COMMAND_ID_MAX
Typically the mem_commands[] array is in sync with 'enum { CXL_CMDS }'.
Current code works well.
However, the array size of mem_commands[] may not strictly be the same
as CXL_MEM_COMMAND_ID_MAX. E.g. if a new CXL_CMD() is added that is
guarded by #ifdefs, the array could be shorter. This could lead then
further to an out-of-bounds array access in cxl_validate_cmd_from_user().
Fix this by forcing the array size to CXL_MEM_COMMAND_ID_MAX. This
also adds range checks for array items in mem_commands[] at compile
time.
Signed-off-by: Robert Richter
---
drivers/cxl/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 244cb7d89678..ecfc9ccdba8d 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -169,7 +169,7 @@ struct cxl_mem_command {
* table will be validated against the user's input. For example, if size_in is
* 0, and the user passed in 1, it is an error.
*/
-static struct cxl_mem_command mem_commands[] = {
+static struct cxl_mem_command mem_commands[CXL_MEM_COMMAND_ID_MAX] = {
CXL_CMD(IDENTIFY, 0, 0x43, CXL_CMD_FLAG_FORCE_ENABLE),
#ifdef CONFIG_CXL_MEM_RAW_COMMANDS
CXL_CMD(RAW, ~0, ~0, 0),
--
2.29.2
[PATCH v3 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
sm8350 has 29 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle their
frequencies on crossing passive temperature thresholds.
Signed-off-by: Robert Foss
Reviewed-by: Vinod Koul
---
Changes since v1:
- Vinod: Remove comment
Changes since v2:
- Vinod: Add r-b
- Konrad: Use lower case hex addresses
- Really remove comments
arch/arm64/boot/dts/qcom/sm8350.dtsi | 826 +++
1 file changed, 826 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 4abdba78cec1..3b53066285ce 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -46,6 +47,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <&L2_0>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -62,6 +64,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <&L2_100>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -75,6 +78,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <&L2_200>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -88,6 +92,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <&L2_300>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -101,6 +106,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <&L2_400>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -114,6 +120,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <&L2_500>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -128,6 +135,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <&L2_600>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -141,6 +149,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <&L2_700>;
qcom,freq-domain = <&cpufreq_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -682,6 +691,28 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c222000 {
+ compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1ff>, /* TM */
+ <0 0x0c222000 0 0x8>; /* SROT */
+ #qcom,sensors = <15>;
+ interrupts = <&pdc 26 IRQ_TYPE_LEVEL_HI
[PATCH v3 1/2] dt-bindings: thermal: qcom-tsens: Add compatible for sm8350
Add tsens bindings for sm8350. Signed-off-by: Robert Foss Reviewed-by: Vinod Koul --- Changes since v1: - Vinod: Remove comment Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 95462e071ab4..e788378eff8d 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -43,6 +43,7 @@ properties: - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens + - qcom,sm8350-tsens - const: qcom,tsens-v2 reg: -- 2.31.0.30.g398dba342d.dirty
[PATCH v1] MAINTAINERS: Update Maintainers of DRM Bridge Drivers
Add myself as co-maintainer of DRM Bridge Drivers. Repository commit access has already been granted. https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/338 Cc: Neil Armstrong Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Andrzej Hajda Cc: Jernej Škrabec Cc: Daniel Vetter Signed-off-by: Robert Foss --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4b705ba51c54..16ace8f58649 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5902,6 +5902,7 @@ F:drivers/gpu/drm/atmel-hlcdc/ DRM DRIVERS FOR BRIDGE CHIPS M: Andrzej Hajda M: Neil Armstrong +M: Robert Foss R: Laurent Pinchart R: Jonas Karlman R: Jernej Skrabec -- 2.31.0.30.g398dba342d.dirty
[PATCH v2 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
sm8350 has 29 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle their
frequencies on crossing passive temperature thresholds.
Signed-off-by: Robert Foss
Reviewed-by: Vinod Koul
---
Changes since v1:
- Vinod: Remove comment
Changes since v2:
- Vinod: Add r-b
- Konrad: Use lower case hex addresses
- Really remove comments
arch/arm64/boot/dts/qcom/sm8350.dtsi | 826 +++
1 file changed, 826 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 4abdba78cec1..3b53066285ce 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -46,6 +47,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <&L2_0>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -62,6 +64,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <&L2_100>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -75,6 +78,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <&L2_200>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -88,6 +92,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <&L2_300>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -101,6 +106,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <&L2_400>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -114,6 +120,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <&L2_500>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -128,6 +135,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <&L2_600>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -141,6 +149,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <&L2_700>;
qcom,freq-domain = <&cpufreq_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -682,6 +691,28 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c222000 {
+ compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
+ reg = <0 0x0c263000 0 0x1ff>, /* TM */
+ <0 0x0c222000 0 0x8>; /* SROT */
+ #qcom,sensors = <15>;
+ interrupts = <&pdc 26 IRQ_TYPE_LEVEL_HI
[PATCH v2 1/2] dt-bindings: thermal: qcom-tsens: Add compatible for sm8350
Add tsens bindings for sm8350. Signed-off-by: Robert Foss Reviewed-by: Vinod Koul --- Changes since v2: - Vinod: Add r-b Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 95462e071ab4..e788378eff8d 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -43,6 +43,7 @@ properties: - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens + - qcom,sm8350-tsens - const: qcom,tsens-v2 reg: -- 2.31.0.30.g398dba342d.dirty
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
Alright, I think the best way forward is to remove the polled HPD support. Don't forget to update flags and function pointers. With that, feel free to add my r-b. Reviewed-by: Robert Foss
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
> > Are you saying that pin 63 never is high, or that an irq/isr routine
> > isn't getting executed?
> >
> > > When reading the value of the HPD pin, I always get 1 (and no
> > > transition occurs when plugging / unplugging a cable).
> > > The HPD IRQ is done on the HDMI connector driver [5].
> > > I think a register configuration should be done to enable the IRQ pin
> > > or maybe there is a nug in electronics.
> >
> > After looking at the documentation a bit more, I think we can ignore
> > pin63 and instead have a look at pin14. It is the HDMI TX HPD Control
> > pin. It has a 100k pull-down, so it should be active high.
>
> pin63 is always active high.
> pin14 is connected to the HDMI logic (pin 19 of the HDMI connector)
> with a 100k pull-down.
Thanks, that makes sense. pin14 is connected directly to the physical connector.
>
> >
> > I also found some different I2C addresses than what you've used, I
> > assume the device is available on both addresses.
> >
> > Chip control registers, address:0x90
> > CEC control registers, address 0x92
> >
> Strange, configuration seems to be working well with the address used
> in my driver.
Some chips support alternative addresses, I guess we can assume that
is the case here.
>
> > > The HPD pin is linked to a 2.2k pullup resistor (maybe it's wrong)
> >
> > The datasheet isn't entirely clear about if pin14 has an internal 100k
> > pull-down, or if they recommend adding a 100k pull-down.
> >
> > But this does seem like an issue.
>
> pin14 can't be used directly. I guess it's used by the internal logic
> of the chip to generate the HPD (pin63) signal.
Ack. Ok, false alert with pin14 then.
> >
> > >
> > > >
> > > > > >
> > > > > > > +
> > > > > > > +static int lt8912_probe(struct i2c_client *client,
> > > > > > > +const struct i2c_device_id *id)
> > > > > > > +{
> > > > > > > + static struct lt8912 *lt;
> > > > > > > + int ret = 0;
> > > > > > > + struct device *dev = &client->dev;
> > > > > > > +
> > > > > > > + lt = devm_kzalloc(dev, sizeof(struct lt8912), GFP_KERNEL);
> > > > > > > + if (!lt)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + lt->dev = dev;
> > > > > > > + lt->i2c_client[0] = client;
> > > > > > > + lt->cable_status = connector_status_unknown;
> > > > > > > + lt->workq = create_workqueue("lt8912_workq");
> > > > > >
> > > > > > Looking at [1] and maybe even better [2], I think this polling
> > > > > > approach is the wrong way to go. And with access to documentation, I
> > > > > > think we should be able to sort this out.
> > > > >
> > > > > I neither like the polling approach too. I did it to go on this issue.
> > > > > I will totally remove it once the HPD issue will be resolved.
> > > > > >
> > > > > > Using the irq driver approach requires the interrupt pin to be
> > > > > > configured. Pin 63 of the lt8912b is the IRQ output pin.
> > > > > >
> > > > > > In order to trigger interrupts based on it, the dt-binding would
> > > > > > need
> > > > > > to be updated[3][4] as well as whichever DTS you're using.
> > > > > >
> > > > >
> > > > > The IRQ part is working well in my DTB. It test it by adding some
> > > > > electronics to emulate the HPD pin on the GPIO expander where the HPD
> > > > > pin is linked.
> > > >
> > > > Looking at the dt-binding patch, it does not seem to list any
> > > > interrupts. So that should be added. I think the irq support from [3]
> > > > & [4] can be pretty much copied.
> > > >
> > > > Then we can come back and replace the polling code with the IRQ driven
> > > > code from [2].
> > >
> > > My board uses a "max7323" GPIO expander and the HPD pin is linked to it.
> > > I test this GPIO expander by soldering a pull up resistor and an
> > > interrupt on it and an interrupt was correctly triggered in both
> > > max7323 driver and hdmi-connector;
> > > So I guess that my DTB configuration is correct.
> > > I made my DBT configuration available:
> > > - hdmi-connector node: [6]
> > > - lt8912b node: |7]
> > > - max7323 node: [8].
> >
> > Looking at [7] I think that you would want to add something like:
> >
> > hdmi-bridge@48 {
> > interrupts-extended = <&max7323 $LT8912B_PIN_14
> > IRQ_TYPE_EDGE_RISING>;
> > }
Ok, so pin63 is the output from lt8912b we should be listening to.
And looking at lt9611 it seems to be low=active, so IRQ_TYPE_EDGE_FALLING.
interrupts-extended = <&max7323 $LT8912B_PIN_63 IRQ_TYPE_EDGE_FALLING>;
> >
> > And of course add the corresponding parts from [2] and [3].
> >
> > >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > [1]
> > > > > > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/analogix/anx7625.c#L1751
> > > > > >
> > > > > > [2]
> > > > > > https://github.com/torvalds/linux/blob/v5.11/drivers/gpu/drm/bridge/lontium-lt9611.c#L1160
> > > > > >
> > > > > > [3]
> > > > > > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/displa
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
> > > >
> > > > > +static enum drm_connector_status lt8912_check_cable_status(struct
> > > > > lt8912 *lt)
> > > > > +{
> > > > > + int ret;
> > > > > + unsigned int reg_val;
> > > > > +
> > > > > + ret = regmap_read(lt->regmap[I2C_MAIN], 0xC1, ®_val);
> > > > > + if (ret)
> > > > > + return connector_status_unknown;
> > > > > +
> > > > > + if (reg_val & BIT(7))
> > > > > + return connector_status_connected;
> > > >
> > > > Register 0xc0 & BIT(7) - HPD signal after debounce
> > > > Register 0xc0 & BIT(6) - HPD signal for TX HPD pad
> > >
> > > So, if I understand well, I need to write 0xc0 & BIT(6) with 1 to
> > > enable the HPD pin.
> >
> > Ah, sorry about being a bit terse.
> >
> > Both bit 6 & 7 are read only, and are probably best read after an IRQ.
>
> In my case, IRQ is not triggered at all.
Are you saying that pin 63 never is high, or that an irq/isr routine
isn't getting executed?
> When reading the value of the HPD pin, I always get 1 (and no
> transition occurs when plugging / unplugging a cable).
> The HPD IRQ is done on the HDMI connector driver [5].
> I think a register configuration should be done to enable the IRQ pin
> or maybe there is a nug in electronics.
After looking at the documentation a bit more, I think we can ignore
pin63 and instead have a look at pin14. It is the HDMI TX HPD Control
pin. It has a 100k pull-down, so it should be active high.
I also found some different I2C addresses than what you've used, I
assume the device is available on both addresses.
Chip control registers, address:0x90
CEC control registers, address 0x92
> The HPD pin is linked to a 2.2k pullup resistor (maybe it's wrong)
The datasheet isn't entirely clear about if pin14 has an internal 100k
pull-down, or if they recommend adding a 100k pull-down.
But this does seem like an issue.
>
> >
> > > >
> > > > > +
> > > > > +static int lt8912_probe(struct i2c_client *client,
> > > > > +const struct i2c_device_id *id)
> > > > > +{
> > > > > + static struct lt8912 *lt;
> > > > > + int ret = 0;
> > > > > + struct device *dev = &client->dev;
> > > > > +
> > > > > + lt = devm_kzalloc(dev, sizeof(struct lt8912), GFP_KERNEL);
> > > > > + if (!lt)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + lt->dev = dev;
> > > > > + lt->i2c_client[0] = client;
> > > > > + lt->cable_status = connector_status_unknown;
> > > > > + lt->workq = create_workqueue("lt8912_workq");
> > > >
> > > > Looking at [1] and maybe even better [2], I think this polling
> > > > approach is the wrong way to go. And with access to documentation, I
> > > > think we should be able to sort this out.
> > >
> > > I neither like the polling approach too. I did it to go on this issue.
> > > I will totally remove it once the HPD issue will be resolved.
> > > >
> > > > Using the irq driver approach requires the interrupt pin to be
> > > > configured. Pin 63 of the lt8912b is the IRQ output pin.
> > > >
> > > > In order to trigger interrupts based on it, the dt-binding would need
> > > > to be updated[3][4] as well as whichever DTS you're using.
> > > >
> > >
> > > The IRQ part is working well in my DTB. It test it by adding some
> > > electronics to emulate the HPD pin on the GPIO expander where the HPD
> > > pin is linked.
> >
> > Looking at the dt-binding patch, it does not seem to list any
> > interrupts. So that should be added. I think the irq support from [3]
> > & [4] can be pretty much copied.
> >
> > Then we can come back and replace the polling code with the IRQ driven
> > code from [2].
>
> My board uses a "max7323" GPIO expander and the HPD pin is linked to it.
> I test this GPIO expander by soldering a pull up resistor and an
> interrupt on it and an interrupt was correctly triggered in both
> max7323 driver and hdmi-connector;
> So I guess that my DTB configuration is correct.
> I made my DBT configuration available:
> - hdmi-connector node: [6]
> - lt8912b node: |7]
> - max7323 node: [8].
Looking at [7] I think that you would want to add something like:
hdmi-bridge@48 {
interrupts-extended = <&max7323 $LT8912B_PIN_14 IRQ_TYPE_EDGE_RISING>;
}
And of course add the corresponding parts from [2] and [3].
>
>
> >
> > >
> > > >
> > > > [1]
> > > > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/analogix/anx7625.c#L1751
> > > >
> > > > [2]
> > > > https://github.com/torvalds/linux/blob/v5.11/drivers/gpu/drm/bridge/lontium-lt9611.c#L1160
> > > >
> > > > [3]
> > > > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L27
> > > >
> > > > [4]
> > > > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L144
>
> [5]
> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/display-connector.c#L199
> [6]
> https://github.com/grassead/linux
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
On Tue, 23 Mar 2021 at 11:01, Adrien Grassein wrote:
>
> Hey Robert,
>
> Thanks for the update.
>
> Le mar. 23 mars 2021 à 10:10, Robert Foss a écrit :
> >
> > Hey Adrien,
> >
> > Sorry about the slow reply, but I just received the documentation from
> > the vendor. So let's dig in to the HPD issue.
>
> No problem :)
> >
> > > +static enum drm_connector_status lt8912_check_cable_status(struct lt8912
> > > *lt)
> > > +{
> > > + int ret;
> > > + unsigned int reg_val;
> > > +
> > > + ret = regmap_read(lt->regmap[I2C_MAIN], 0xC1, ®_val);
> > > + if (ret)
> > > + return connector_status_unknown;
> > > +
> > > + if (reg_val & BIT(7))
> > > + return connector_status_connected;
> >
> > Register 0xc0 & BIT(7) - HPD signal after debounce
> > Register 0xc0 & BIT(6) - HPD signal for TX HPD pad
>
> So, if I understand well, I need to write 0xc0 & BIT(6) with 1 to
> enable the HPD pin.
Ah, sorry about being a bit terse.
Both bit 6 & 7 are read only, and are probably best read after an IRQ.
> >
> > > +
> > > +static int lt8912_probe(struct i2c_client *client,
> > > +const struct i2c_device_id *id)
> > > +{
> > > + static struct lt8912 *lt;
> > > + int ret = 0;
> > > + struct device *dev = &client->dev;
> > > +
> > > + lt = devm_kzalloc(dev, sizeof(struct lt8912), GFP_KERNEL);
> > > + if (!lt)
> > > + return -ENOMEM;
> > > +
> > > + lt->dev = dev;
> > > + lt->i2c_client[0] = client;
> > > + lt->cable_status = connector_status_unknown;
> > > + lt->workq = create_workqueue("lt8912_workq");
> >
> > Looking at [1] and maybe even better [2], I think this polling
> > approach is the wrong way to go. And with access to documentation, I
> > think we should be able to sort this out.
>
> I neither like the polling approach too. I did it to go on this issue.
> I will totally remove it once the HPD issue will be resolved.
> >
> > Using the irq driver approach requires the interrupt pin to be
> > configured. Pin 63 of the lt8912b is the IRQ output pin.
> >
> > In order to trigger interrupts based on it, the dt-binding would need
> > to be updated[3][4] as well as whichever DTS you're using.
> >
>
> The IRQ part is working well in my DTB. It test it by adding some
> electronics to emulate the HPD pin on the GPIO expander where the HPD
> pin is linked.
Looking at the dt-binding patch, it does not seem to list any
interrupts. So that should be added. I think the irq support from [3]
& [4] can be pretty much copied.
Then we can come back and replace the polling code with the IRQ driven
code from [2].
>
> >
> > [1]
> > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/analogix/anx7625.c#L1751
> >
> > [2]
> > https://github.com/torvalds/linux/blob/v5.11/drivers/gpu/drm/bridge/lontium-lt9611.c#L1160
> >
> > [3]
> > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L27
> >
> > [4]
> > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L144
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
Hey Adrien,
Sorry about the slow reply, but I just received the documentation from
the vendor. So let's dig in to the HPD issue.
> +static enum drm_connector_status lt8912_check_cable_status(struct lt8912 *lt)
> +{
> + int ret;
> + unsigned int reg_val;
> +
> + ret = regmap_read(lt->regmap[I2C_MAIN], 0xC1, ®_val);
> + if (ret)
> + return connector_status_unknown;
> +
> + if (reg_val & BIT(7))
> + return connector_status_connected;
Register 0xc0 & BIT(7) - HPD signal after debounce
Register 0xc0 & BIT(6) - HPD signal for TX HPD pad
> +
> +static int lt8912_probe(struct i2c_client *client,
> +const struct i2c_device_id *id)
> +{
> + static struct lt8912 *lt;
> + int ret = 0;
> + struct device *dev = &client->dev;
> +
> + lt = devm_kzalloc(dev, sizeof(struct lt8912), GFP_KERNEL);
> + if (!lt)
> + return -ENOMEM;
> +
> + lt->dev = dev;
> + lt->i2c_client[0] = client;
> + lt->cable_status = connector_status_unknown;
> + lt->workq = create_workqueue("lt8912_workq");
Looking at [1] and maybe even better [2], I think this polling
approach is the wrong way to go. And with access to documentation, I
think we should be able to sort this out.
Using the irq driver approach requires the interrupt pin to be
configured. Pin 63 of the lt8912b is the IRQ output pin.
In order to trigger interrupts based on it, the dt-binding would need
to be updated[3][4] as well as whichever DTS you're using.
[1]
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/analogix/anx7625.c#L1751
[2]
https://github.com/torvalds/linux/blob/v5.11/drivers/gpu/drm/bridge/lontium-lt9611.c#L1160
[3]
https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L27
[4]
https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L144
Re: [PATCH v2 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
Hey Konrad,
Thanks for the review!
On Mon, 22 Mar 2021 at 18:27, Konrad Dybcio
wrote:
>
> Hi!
>
>
> > + tsens0: thermal-sensor@c222000 {
> > + compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
> > + reg = <0 0x0C263000 0 0x1ff>, /* TM */
> > + <0 0x0C222000 0 0x8>; /* SROT */
>
> Please use lowercase hex
Ack
>
>
> > + tsens1: thermal-sensor@c223000 {
> > + compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
> > + reg = <0 0x0C265000 0 0x1ff>, /* TM */
> > + <0 0x0c223000 0 0x8>; /* SROT */
>
> Ditto
Ack
>
>
> > + trips {
> > + cpu0_alert0: trip-point0 {
> > + temperature = <9>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > +
> > + cpu0_alert1: trip-point1 {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "passive";
>
> Shouldn't this be "hot"? Possibly ditto for all cpu*alert1-labeled nodes.
I based this patch on the upstream DTS for sm8250 & sdm845, and this
is what they use. However, if you think it is incorrect I'm happy to
do a little digging.
>
>
> > + };
> > +
> > + cpu0_crit: cpu_crit {
> > + temperature = <11>;
> > + hysteresis = <1000>;
> > + type = "critical";
> > + };
> > + };
>
> These values seem, err.. scorching hot.. Are they alright?
I agree :) This is what the vendor ships in their downstream DTS.
>
>
>
> > + // TODO: What is the NSP subsystem?
> Please use C-style comments (/* foo */)
Removing comment.
[PATCH v2 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
sm8350 has 29 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle their
frequencies on crossing passive temperature thresholds.
Signed-off-by: Robert Foss
---
Changes since v1:
- Vinod: Remove comment
arch/arm64/boot/dts/qcom/sm8350.dtsi | 829 +++
1 file changed, 829 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 4abdba78cec1..424887652f47 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -46,6 +47,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <&L2_0>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -62,6 +64,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <&L2_100>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -75,6 +78,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <&L2_200>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -88,6 +92,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <&L2_300>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -101,6 +106,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <&L2_400>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -114,6 +120,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <&L2_500>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -128,6 +135,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <&L2_600>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -141,6 +149,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <&L2_700>;
qcom,freq-domain = <&cpufreq_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -682,6 +691,28 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c222000 {
+ compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
+ reg = <0 0x0C263000 0 0x1ff>, /* TM */
+ <0 0x0C222000 0 0x8>; /* SROT */
+ #qcom,sensors = <15>;
+ interrupts = <&pdc 26 IRQ_TYPE_LEVEL_HIGH>,
+<&pdc 28 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "up
[PATCH v2 1/2] dt-bindings: thermal: qcom-tsens: Add compatible for sm8350
Add tsens bindings for sm8350. Signed-off-by: Robert Foss --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 95462e071ab4..e788378eff8d 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -43,6 +43,7 @@ properties: - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens + - qcom,sm8350-tsens - const: qcom,tsens-v2 reg: -- 2.27.0
Re: [PATCH v6 2/5] drm/bridge: anx7625: fix not correct return value
Hey Xin,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Mar 2021 at 07:33, Xin Ji wrote:
>
> At some time, the original code may return non zero value, force return 0
> if operation finished.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 65cc05982f82..04536cc7afe7 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -189,10 +189,10 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
>AP_AUX_CTRL_STATUS);
> if (val < 0 || (val & 0x0F)) {
> DRM_DEV_ERROR(dev, "aux status %02x\n", val);
> - val = -EIO;
> + return -EIO;
> }
>
> - return val;
> + return 0;
> }
>
> static int anx7625_video_mute_control(struct anx7625_data *ctx,
> --
> 2.25.1
>
Re: [PATCH] drm: bridge: adv7511: Support I2S IEC958 encoded PCM format
Hey Sia, Thanks for the patch, it looks good to me. Reviewed-by: Robert Foss On Fri, 12 Mar 2021 at 10:09, Sia Jee Heng wrote: > > Support IEC958 encoded PCM format for ADV7511 so that ADV7511 HDMI > audio driver can accept the IEC958 data from the I2S input. > > Signed-off-by: Sia Jee Heng > --- > drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 + > drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 6 ++ > 2 files changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h > b/drivers/gpu/drm/bridge/adv7511/adv7511.h > index a9bb734366ae..05e3abb5a0c9 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h > @@ -191,6 +191,7 @@ > #define ADV7511_I2S_FORMAT_I2S 0 > #define ADV7511_I2S_FORMAT_RIGHT_J 1 > #define ADV7511_I2S_FORMAT_LEFT_J 2 > +#define ADV7511_I2S_IEC958_DIRECT 3 > > #define ADV7511_PACKET(p, x) ((p) * 0x20 + (x)) > #define ADV7511_PACKET_SDP(x) ADV7511_PACKET(0, x) > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > index 45838bd08d37..61f4a38e7d2b 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > @@ -101,6 +101,10 @@ static int adv7511_hdmi_hw_params(struct device *dev, > void *data, > case 20: > len = ADV7511_I2S_SAMPLE_LEN_20; > break; > + case 32: > + if (fmt->bit_fmt != SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE) > + return -EINVAL; > + fallthrough; > case 24: > len = ADV7511_I2S_SAMPLE_LEN_24; > break; > @@ -112,6 +116,8 @@ static int adv7511_hdmi_hw_params(struct device *dev, > void *data, > case HDMI_I2S: > audio_source = ADV7511_AUDIO_SOURCE_I2S; > i2s_format = ADV7511_I2S_FORMAT_I2S; > + if (fmt->bit_fmt == SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE) > + i2s_format = ADV7511_I2S_IEC958_DIRECT; > break; > case HDMI_RIGHT_J: > audio_source = ADV7511_AUDIO_SOURCE_I2S; > > base-commit: de066e116306baf3a6a62691ac63cfc0b1dabddb > -- > 2.18.0 >
Re: [PATCH 13/30] drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe()
Hey Lyude, Thanks for the patch, it looks good to me. Reviewed-by: Robert Foss On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote: > > Just another drive-by fix I noticed while going through the tree to cleanup > DP aux adapter registration - make sure we unregister the DP AUX dev if > analogix_dp_probe() fails. > > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > index aa1bb86293fd..f115233b1cb9 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > @@ -1782,6 +1782,7 @@ int analogix_dp_bind(struct analogix_dp_device *dp, > struct drm_device *drm_dev) > > err_disable_pm_runtime: > pm_runtime_disable(dp->dev); > + drm_dp_aux_unregister(&dp->aux); > > return ret; > } > -- > 2.29.2 >
Re: [PATCH 12/30] drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach()
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another drive-by fix I found when fixing DP AUX adapter across the kernel
> tree - make sure we don't leak resources (and by proxy-AUX adapters) on
> failures in anx6345_bridge_attach() by unrolling on errors.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 6258f16da0e8..aa6cda458eb9 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -550,7 +550,7 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
> DRM_MODE_CONNECTOR_eDP);
> if (err) {
> DRM_ERROR("Failed to initialize connector: %d\n", err);
> - return err;
> + goto aux_unregister;
> }
>
> drm_connector_helper_add(&anx6345->connector,
> @@ -562,16 +562,21 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
>bridge->encoder);
> if (err) {
> DRM_ERROR("Failed to link up connector to encoder: %d\n",
> err);
> - return err;
> + goto connector_cleanup;
> }
>
> err = drm_connector_register(&anx6345->connector);
> if (err) {
> DRM_ERROR("Failed to register connector: %d\n", err);
> - return err;
> + goto connector_cleanup;
> }
>
> return 0;
> +connector_cleanup:
> + drm_connector_cleanup(&anx6345->connector);
> +aux_unregister:
> + drm_dp_aux_unregister(&anx6345->aux);
> + return err;
> }
>
> static void anx6345_bridge_detach(struct drm_bridge *bridge)
> --
> 2.29.2
>
Re: [PATCH 11/30] drm/bridge/analogix/anx6345: Don't link encoder until after connector registration
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another case of linking an encoder to a connector after the connector's
> been registered. The proper place to do this is before connector
> registration, so let's fix that.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 8e016ba7c54a..6258f16da0e8 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -556,12 +556,6 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
> drm_connector_helper_add(&anx6345->connector,
> &anx6345_connector_helper_funcs);
>
> - err = drm_connector_register(&anx6345->connector);
> - if (err) {
> - DRM_ERROR("Failed to register connector: %d\n", err);
> - return err;
> - }
> -
> anx6345->connector.polled = DRM_CONNECTOR_POLL_HPD;
>
> err = drm_connector_attach_encoder(&anx6345->connector,
> @@ -571,6 +565,12 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
> return err;
> }
>
> + err = drm_connector_register(&anx6345->connector);
> + if (err) {
> + DRM_ERROR("Failed to register connector: %d\n", err);
> + return err;
> + }
> +
> return 0;
> }
>
> --
> 2.29.2
>
Re: [PATCH 10/30] drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another driver I found that seems to forget to unregister it's DP AUX
> device. Let's fix this by adding anx6345_bridge_detach().
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index d9164fab044d..8e016ba7c54a 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -574,6 +574,11 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge,
> return 0;
> }
>
> +static void anx6345_bridge_detach(struct drm_bridge *bridge)
> +{
> + drm_dp_aux_unregister(&bridge_to_anx6345(bridge)->aux);
> +}
> +
> static enum drm_mode_status
> anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> const struct drm_display_info *info,
> @@ -624,6 +629,7 @@ static void anx6345_bridge_enable(struct drm_bridge
> *bridge)
>
> static const struct drm_bridge_funcs anx6345_bridge_funcs = {
> .attach = anx6345_bridge_attach,
> + .detach = anx6345_bridge_detach,
> .mode_valid = anx6345_bridge_mode_valid,
> .disable = anx6345_bridge_disable,
> .enable = anx6345_bridge_enable,
> --
> 2.29.2
>
Re: [PATCH 09/30] drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach()
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Just another issue I noticed while correcting usages of
> drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the
> steps in anx78xx_bridge_attach() fail, we end up leaking resources. So,
> let's fix that (and fix leaking a DP AUX adapter in the process) by
> unrolling on errors.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 338dd8531d4b..f20558618220 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -918,7 +918,7 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
> DRM_MODE_CONNECTOR_DisplayPort);
> if (err) {
> DRM_ERROR("Failed to initialize connector: %d\n", err);
> - return err;
> + goto aux_unregister;
> }
>
> drm_connector_helper_add(&anx78xx->connector,
> @@ -930,16 +930,21 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
>bridge->encoder);
> if (err) {
> DRM_ERROR("Failed to link up connector to encoder: %d\n",
> err);
> - return err;
> + goto connector_cleanup;
> }
>
> err = drm_connector_register(&anx78xx->connector);
> if (err) {
> DRM_ERROR("Failed to register connector: %d\n", err);
> - return err;
> + goto connector_cleanup;
> }
>
> return 0;
> +connector_cleanup:
> + drm_connector_cleanup(&anx78xx->connector);
> +aux_unregister:
> + drm_dp_aux_unregister(&anx78xx->aux);
> + return err;
> }
>
> static void anx78xx_bridge_detach(struct drm_bridge *bridge)
> --
> 2.29.2
>
Re: [PATCH 08/30] drm/bridge/analogix/anx78xx: Setup encoder before registering connector
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Since encoder mappings for connectors are exposed to userspace, we should
> be attaching the encoder before exposing the connector to userspace. Just a
> drive-by fix for an issue I noticed while fixing up usages of
> drm_dp_aux_init()/drm_dp_aux_register() across the tree.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index ec4607dc01eb..338dd8531d4b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -924,12 +924,6 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
> drm_connector_helper_add(&anx78xx->connector,
> &anx78xx_connector_helper_funcs);
>
> - err = drm_connector_register(&anx78xx->connector);
> - if (err) {
> - DRM_ERROR("Failed to register connector: %d\n", err);
> - return err;
> - }
> -
> anx78xx->connector.polled = DRM_CONNECTOR_POLL_HPD;
>
> err = drm_connector_attach_encoder(&anx78xx->connector,
> @@ -939,6 +933,12 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
> return err;
> }
>
> + err = drm_connector_register(&anx78xx->connector);
> + if (err) {
> + DRM_ERROR("Failed to register connector: %d\n", err);
> + return err;
> + }
> +
> return 0;
> }
>
> --
> 2.29.2
>
Re: [PATCH 07/30] drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Surprisingly, this bridge actually registers it's AUX adapter at the
> correct time already. Nice job! However, it does forget to actually
> unregister the AUX adapter, so let's add a bridge function to handle that.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 81debd02c169..ec4607dc01eb 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -942,6 +942,11 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge,
> return 0;
> }
>
> +static void anx78xx_bridge_detach(struct drm_bridge *bridge)
> +{
> + drm_dp_aux_unregister(&bridge_to_anx78xx(bridge)->aux);
> +}
> +
> static enum drm_mode_status
> anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
> const struct drm_display_info *info,
> @@ -1013,6 +1018,7 @@ static void anx78xx_bridge_enable(struct drm_bridge
> *bridge)
>
> static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
> .attach = anx78xx_bridge_attach,
> + .detach = anx78xx_bridge_detach,
> .mode_valid = anx78xx_bridge_mode_valid,
> .disable = anx78xx_bridge_disable,
> .mode_set = anx78xx_bridge_mode_set,
> --
> 2.29.2
>
Re: [PATCH 04/30] drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached
Hey Lyude,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Since this is a bridge, we don't start out with a respective DRM device.
> Likewise this means we don't have a connector, which also means that we
> should be following drm_dp_aux_register()'s documentation advice and not
> call drm_dp_aux_register() until we have a matching connector. Instead,
> call drm_dp_aux_init() in tc_probe() and wait until tc_bridge_attach() to
> register our AUX channel. We also add tc_bridge_detach() to handle
> unregistering the AUX adapter once the bridge has been disconnected.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/bridge/tc358767.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 34a3e4e9f717..da89922721ed 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1414,11 +1414,15 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> return 0;
>
> + ret = drm_dp_aux_register(&tc->aux);
> + if (ret < 0)
> + return ret;
> +
> /* Create DP/eDP connector */
> drm_connector_helper_add(&tc->connector, &tc_connector_helper_funcs);
> ret = drm_connector_init(drm, &tc->connector, &tc_connector_funcs,
> tc->bridge.type);
> if (ret)
> - return ret;
> + goto aux_unregister;
>
> /* Don't poll if don't have HPD connected */
> if (tc->hpd_pin >= 0) {
> @@ -1438,10 +1442,19 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
> drm_connector_attach_encoder(&tc->connector, tc->bridge.encoder);
>
> return 0;
> +aux_unregister:
> + drm_dp_aux_unregister(&tc->aux);
> + return ret;
> +}
> +
> +static void tc_bridge_detach(struct drm_bridge *bridge)
> +{
> + drm_dp_aux_unregister(&bridge_to_tc(bridge)->aux);
> }
>
> static const struct drm_bridge_funcs tc_bridge_funcs = {
> .attach = tc_bridge_attach,
> + .detach = tc_bridge_detach,
> .mode_valid = tc_mode_valid,
> .mode_set = tc_bridge_mode_set,
> .enable = tc_bridge_enable,
> @@ -1680,9 +1693,7 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> tc->aux.name = "TC358767 AUX i2c adapter";
> tc->aux.dev = tc->dev;
> tc->aux.transfer = tc_aux_transfer;
> - ret = drm_dp_aux_register(&tc->aux);
> - if (ret)
> - return ret;
> + drm_dp_aux_init(&tc->aux);
>
> tc->bridge.funcs = &tc_bridge_funcs;
> if (tc->hpd_pin >= 0)
> @@ -1702,7 +1713,6 @@ static int tc_remove(struct i2c_client *client)
> struct tc_data *tc = i2c_get_clientdata(client);
>
> drm_bridge_remove(&tc->bridge);
> - drm_dp_aux_unregister(&tc->aux);
>
> return 0;
> }
> --
> 2.29.2
>
Re: [PATCH 30/30] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()
Hey Lyude,
Thanks for the patch
On Fri, 19 Feb 2021 at 23:03, Lyude Paul wrote:
>
> And finally, convert all of the code in drm_dp_mst_topology.c over to using
> drm_err() and drm_dbg*(). Note that this refactor would have been a lot
> more complicated to have tried writing a coccinelle script for, so this
> whole thing was done by hand.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 369 +-
> 1 file changed, 187 insertions(+), 182 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index fb66df39e0bb..f66232954689 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -286,7 +286,8 @@ static void drm_dp_encode_sideband_msg_hdr(struct
> drm_dp_sideband_msg_hdr *hdr,
> *len = idx;
> }
>
> -static bool drm_dp_decode_sideband_msg_hdr(struct drm_dp_sideband_msg_hdr
> *hdr,
> +static bool drm_dp_decode_sideband_msg_hdr(const struct
> drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_sideband_msg_hdr
> *hdr,
>u8 *buf, int buflen, u8 *hdrlen)
> {
> u8 crc4;
> @@ -303,7 +304,7 @@ static bool drm_dp_decode_sideband_msg_hdr(struct
> drm_dp_sideband_msg_hdr *hdr,
> crc4 = drm_dp_msg_header_crc4(buf, (len * 2) - 1);
>
> if ((crc4 & 0xf) != (buf[len - 1] & 0xf)) {
> - DRM_DEBUG_KMS("crc4 mismatch 0x%x 0x%x\n", crc4, buf[len -
> 1]);
> + drm_dbg_kms(mgr->dev, "crc4 mismatch 0x%x 0x%x\n", crc4,
> buf[len - 1]);
> return false;
> }
>
> @@ -789,7 +790,8 @@ static bool drm_dp_sideband_append_payload(struct
> drm_dp_sideband_msg_rx *msg,
> return true;
> }
>
> -static bool drm_dp_sideband_parse_link_address(struct drm_dp_sideband_msg_rx
> *raw,
> +static bool drm_dp_sideband_parse_link_address(const struct
> drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_sideband_msg_rx
> *raw,
>struct
> drm_dp_sideband_msg_reply_body *repmsg)
> {
> int idx = 1;
> @@ -1014,7 +1016,8 @@ drm_dp_sideband_parse_query_stream_enc_status(
> return true;
> }
>
> -static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
> +static bool drm_dp_sideband_parse_reply(const struct drm_dp_mst_topology_mgr
> *mgr,
> + struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_reply_body
> *msg)
> {
> memset(msg, 0, sizeof(*msg));
> @@ -1030,7 +1033,7 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
>
> switch (msg->req_type) {
> case DP_LINK_ADDRESS:
> - return drm_dp_sideband_parse_link_address(raw, msg);
> + return drm_dp_sideband_parse_link_address(mgr, raw, msg);
> case DP_QUERY_PAYLOAD:
> return drm_dp_sideband_parse_query_payload_ack(raw, msg);
> case DP_REMOTE_DPCD_READ:
> @@ -1053,14 +1056,16 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
> case DP_QUERY_STREAM_ENC_STATUS:
> return drm_dp_sideband_parse_query_stream_enc_status(raw,
> msg);
> default:
> - DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
> - drm_dp_mst_req_type_str(msg->req_type));
> + drm_err(mgr->dev, "Got unknown reply 0x%02x (%s)\n",
> + msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> return false;
> }
> }
>
> -static bool drm_dp_sideband_parse_connection_status_notify(struct
> drm_dp_sideband_msg_rx *raw,
> - struct
> drm_dp_sideband_msg_req_body *msg)
> +static bool
> +drm_dp_sideband_parse_connection_status_notify(const struct
> drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_sideband_msg_rx
> *raw,
> + struct
> drm_dp_sideband_msg_req_body *msg)
> {
> int idx = 1;
>
> @@ -1082,12 +1087,14 @@ static bool
> drm_dp_sideband_parse_connection_status_notify(struct drm_dp_sideban
> idx++;
> return true;
> fail_len:
> - DRM_DEBUG_KMS("connection status reply parse length fail %d %d\n",
> idx, raw->curlen);
> + drm_dbg_kms(mgr->dev, "connection status reply parse length fail %d
> %d\n",
> + idx, raw->curlen);
> return false;
> }
>
> -static bool drm_dp_sideband_parse_resource_status_notify(struct
> drm_dp_sideband_msg_rx *raw,
> - struct
> drm_dp_sideband_msg_req_body *msg)
> +static bool drm_dp_sideband_parse_resource_status_notify(const struc
Re: [PATCH 28/30] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()
Hey Lyude,
Thanks for the patch.
On Fri, 19 Feb 2021 at 23:03, Lyude Paul wrote:
>
> Now that we've added a back-pointer to drm_device to drm_dp_aux, made
> drm_dp_aux available to any functions in drm_dp_helper.c which need to
> print to the kernel log, and ensured all of our logging uses a consistent
> format, let's do the final step of the conversion and actually move
> everything over to using drm_err() and drm_dbg_*().
>
> This was done by using the following cocci script:
>
> @@
> expression list expr;
> @@
>
> (
> - DRM_DEBUG_KMS(expr);
> + drm_dbg_kms(aux->drm_dev, expr);
> |
> - DRM_DEBUG_DP(expr);
> + drm_dbg_dp(aux->drm_dev, expr);
> |
> - DRM_DEBUG_ATOMIC(expr);
> + drm_dbg_atomic(aux->drm_dev, expr);
> |
> - DRM_DEBUG_KMS_RATELIMITED(expr);
> + drm_dbg_kms_ratelimited(aux->drm_dev, expr);
> |
> - DRM_ERROR(expr);
> + drm_err(aux->drm_dev, expr);
> )
>
> Followed by correcting the resulting line-wrapping in the results by hand.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_helper.c | 122
> 1 file changed, 60 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index b5e2671baf22..0a787ddf39fd 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -139,8 +139,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct
> drm_dp_aux *aux,
> DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> + drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
> (max 4)\n",
> + aux->name, rd_interval);
>
> if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> rd_interval = 100;
> @@ -155,8 +155,8 @@ static void __drm_dp_link_train_channel_eq_delay(const
> struct drm_dp_aux *aux,
> unsigned long rd_interval)
> {
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("%s: AUX interval %lu, out of range (max 4)\n",
> - aux->name, rd_interval);
> + drm_dbg_kms(aux->drm_dev, "%s: AUX interval %lu, out of range
> (max 4)\n",
> + aux->name, rd_interval);
>
> if (rd_interval == 0)
> rd_interval = 400;
> @@ -220,11 +220,12 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
> const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
>
> if (ret > 0)
> - DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> -aux->name, offset, arrow, ret, min(ret, 20),
> buffer);
> + drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
> + aux->name, offset, arrow, ret, min(ret, 20),
> + buffer);
checkpatch --strict is unhappy with this chunk
ERROR: code indent should use tabs where possible
#75: FILE: drivers/gpu/drm/drm_dp_helper.c:224:
+^I^I aux->name, offset, arrow, ret, min(ret, 20),$
ERROR: code indent should use tabs where possible
#76: FILE: drivers/gpu/drm/drm_dp_helper.c:225:
> else
> - DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
> -aux->name, offset, arrow, ret);
> + drm_dbg_dp(aux->drm_dev, "%s: 0x%05x AUX %s (ret=%3d)\n",
> + aux->name, offset, arrow, ret);
checkpatch --strict is unhappy with this chunk
ERROR: code indent should use tabs where possible
#81: FILE: drivers/gpu/drm/drm_dp_helper.c:228:
+^I^I aux->name, offset, arrow, ret);$
> }
>
> /**
> @@ -287,8 +288,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
> err = ret;
> }
>
> - DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
> - aux->name, err);
> + drm_dbg_kms(aux->drm_dev, "%s: Too many retries, giving up. First
> error: %d\n",
> + aux->name, err);
> ret = err;
>
> unlock:
> @@ -524,44 +525,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux
> *aux,
>
> if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
> &auto_test_req, 1) < 1) {
> - DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> - aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> + drm_err(aux->drm_dev, "%s: DPCD failed read at register
> 0x%x\n",
> + aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> return false;
> }
> auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
>
> if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, &link_edid_read, 1) < 1) {
> - DRM_ER
Re: [PATCH 27/30] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()
Hey Lyude,
Thanks for the patch.
On Fri, 19 Feb 2021 at 23:03, Lyude Paul wrote:
>
> Since this is one of the few functions in drm_dp_mst_topology.c that
> doesn't have any way of getting access to a drm_device, let's pass the
> drm_dp_mst_topology_mgr down to this function so that it can use
> drm_dbg_kms().
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 7 +--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
> include/drm/drm_dp_mst_helper.h | 3 ++-
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index cf4f2f85711e..fb66df39e0bb 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3631,6 +3631,7 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
>
> /**
> * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
> + * @mgr: The &drm_dp_mst_topology_mgr to use
> * @link_rate: link rate in 10kbits/s units
> * @link_lane_count: lane count
> *
> @@ -3639,7 +3640,8 @@ static int drm_dp_send_up_ack_reply(struct
> drm_dp_mst_topology_mgr *mgr,
> * convert the number of PBNs required for a given stream to the number of
> * timeslots this stream requires in each MTP.
> */
> -int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
> +int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
> +int link_rate, int link_lane_count)
> {
> if (link_rate == 0 || link_lane_count == 0)
> DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
> @@ -3704,7 +3706,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
> goto out_unlock;
> }
>
> - mgr->pbn_div =
> drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
> + mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr,
> +
> drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
> mgr->dpcd[2] &
> DP_MAX_LANE_COUNT_MASK);
> if (mgr->pbn_div == 0) {
> ret = -EINVAL;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 8e316146b6d1..60ca0fa32d15 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -70,7 +70,8 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
> slots = drm_dp_atomic_find_vcpi_slots(state,
> &intel_dp->mst_mgr,
> connector->port,
> crtc_state->pbn,
> -
> drm_dp_get_vc_payload_bw(crtc_state->port_clock,
> +
> drm_dp_get_vc_payload_bw(&intel_dp->mst_mgr,
> +
> crtc_state->port_clock,
>
> crtc_state->lane_count));
checkpatch --strict is unhappy about this chunk
WARNING: line length of 102 exceeds 100 columns
#61: FILE: drivers/gpu/drm/i915/display/intel_dp_mst.c:73:
+ crtc_state->port_clock,
Maybe the results of drm_dp_get_vc_payload_bw() can be but in a
temporary variable.
> if (slots == -EDEADLK)
> return slots;
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index bd1c39907b92..20dc705642bd 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -783,7 +783,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
>
> struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
> drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
>
> -int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
> +int drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
> +int link_rate, int link_lane_count);
>
> int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
>
> --
> 2.29.2
>
Re: [PATCH 18/30] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
Hey Lyude,
Thanks for the patch,
On Fri, 19 Feb 2021 at 22:59, Lyude Paul wrote:
>
> Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
> to make sure that we can also add ratelimited versions of these macros in
> order to retain some of the previous debugging output behavior we had.
>
> However, as I was preparing to do this I noticed that the current
> rate limited macros we have are kind of bogus. It looks like when I wrote
> these, I didn't notice that we'd always be calling __ratelimit() even if
> the debugging message we'd be printing would normally be filtered out due
> to the relevant DRM debugging category being disabled.
>
> So, let's fix this by making sure to check drm_debug_enabled() in our
> ratelimited macros before calling __ratelimit(), and start using
> drm_dev_printk() in order to print debugging messages since that will save
> us from doing a redundant drm_debug_enabled() check. And while we're at it,
> let's move the code for this into another macro that we can reuse for
> defining new ratelimited DRM debug macros more easily.
>
> Signed-off-by: Lyude Paul
> ---
> include/drm/drm_print.h | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index f32d179e139d..3a0c3fe4d292 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -524,16 +524,20 @@ void __drm_err(const char *format, ...);
> #define DRM_DEBUG_DP(fmt, ...) \
> __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
>
> -
> -#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...)\
> -({ \
> - static DEFINE_RATELIMIT_STATE(_rs, \
> - DEFAULT_RATELIMIT_INTERVAL, \
> - DEFAULT_RATELIMIT_BURST); \
> - if (__ratelimit(&_rs)) \
> - drm_dev_dbg(NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__); \
> +#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> \
> +({
> \
> + static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST); \
> + const struct drm_device *drm_ = (drm);
>\
> +
> \
> + if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_))
>\
> + drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ##
> __VA_ARGS__);\
> })
checkpatch --strict is unhappy about the tabs/spaces in this patch
ERROR: code indent should use tabs where possible
#48: FILE: include/drm/drm_print.h:531:
+
\$
WARNING: please, no spaces at the start of a line
#48: FILE: include/drm/drm_print.h:531:
+
\$
>
> +#define drm_dbg_kms_ratelimited(drm, fmt, ...) \
> + __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
> +
> +#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL,
> fmt, ## __VA_ARGS__)
> +
> /*
> * struct drm_device based WARNs
> *
> --
> 2.29.2
>
Re: [PATCH v1 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
On Fri, 19 Mar 2021 at 11:49, Robert Foss wrote:
>
> sm8350 has 29 thermal sensors split across two tsens controllers. Add
> the thermal zones to expose them and wireup the cpus to throttle their
> frequencies on crossing passive temperature thresholds.
>
> Signed-off-by: Robert Foss
> ---
> arch/arm64/boot/dts/qcom/sm8350.dtsi | 829 +++
> 1 file changed, 829 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index 4abdba78cec1..424887652f47 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> interrupt-parent = <&intc>;
> @@ -46,6 +47,7 @@ CPU0: cpu@0 {
> enable-method = "psci";
> next-level-cache = <&L2_0>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> + #cooling-cells = <2>;
> L2_0: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -62,6 +64,7 @@ CPU1: cpu@100 {
> enable-method = "psci";
> next-level-cache = <&L2_100>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> + #cooling-cells = <2>;
> L2_100: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -75,6 +78,7 @@ CPU2: cpu@200 {
> enable-method = "psci";
> next-level-cache = <&L2_200>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> + #cooling-cells = <2>;
> L2_200: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -88,6 +92,7 @@ CPU3: cpu@300 {
> enable-method = "psci";
> next-level-cache = <&L2_300>;
> qcom,freq-domain = <&cpufreq_hw 0>;
> + #cooling-cells = <2>;
> L2_300: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -101,6 +106,7 @@ CPU4: cpu@400 {
> enable-method = "psci";
> next-level-cache = <&L2_400>;
> qcom,freq-domain = <&cpufreq_hw 1>;
> + #cooling-cells = <2>;
> L2_400: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -114,6 +120,7 @@ CPU5: cpu@500 {
> enable-method = "psci";
> next-level-cache = <&L2_500>;
> qcom,freq-domain = <&cpufreq_hw 1>;
> + #cooling-cells = <2>;
> L2_500: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -128,6 +135,7 @@ CPU6: cpu@600 {
> enable-method = "psci";
> next-level-cache = <&L2_600>;
> qcom,freq-domain = <&cpufreq_hw 1>;
> + #cooling-cells = <2>;
> L2_600: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -141,6 +149,7 @@ CPU7: cpu@700 {
> enable-method = "psci";
> next-level-cache = <&L2_700>;
> qcom,freq-domain = <&cpufreq_hw 2>;
> + #cooling-cells = <2>;
> L2_700: l2-cache {
> compatible = "cache";
> next-level-cache = <&L3_0>;
> @@ -682,6 +691,28 @@ pdc: interrupt-controller@b22 {
> interrupt-controller;
> };
>
> + tsens0: thermal-sensor@c222000 {
> + comp
[PATCH v1 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
sm8350 has 29 thermal sensors split across two tsens controllers. Add
the thermal zones to expose them and wireup the cpus to throttle their
frequencies on crossing passive temperature thresholds.
Signed-off-by: Robert Foss
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 829 +++
1 file changed, 829 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 4abdba78cec1..424887652f47 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -46,6 +47,7 @@ CPU0: cpu@0 {
enable-method = "psci";
next-level-cache = <&L2_0>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_0: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -62,6 +64,7 @@ CPU1: cpu@100 {
enable-method = "psci";
next-level-cache = <&L2_100>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_100: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -75,6 +78,7 @@ CPU2: cpu@200 {
enable-method = "psci";
next-level-cache = <&L2_200>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_200: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -88,6 +92,7 @@ CPU3: cpu@300 {
enable-method = "psci";
next-level-cache = <&L2_300>;
qcom,freq-domain = <&cpufreq_hw 0>;
+ #cooling-cells = <2>;
L2_300: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -101,6 +106,7 @@ CPU4: cpu@400 {
enable-method = "psci";
next-level-cache = <&L2_400>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_400: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -114,6 +120,7 @@ CPU5: cpu@500 {
enable-method = "psci";
next-level-cache = <&L2_500>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_500: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -128,6 +135,7 @@ CPU6: cpu@600 {
enable-method = "psci";
next-level-cache = <&L2_600>;
qcom,freq-domain = <&cpufreq_hw 1>;
+ #cooling-cells = <2>;
L2_600: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -141,6 +149,7 @@ CPU7: cpu@700 {
enable-method = "psci";
next-level-cache = <&L2_700>;
qcom,freq-domain = <&cpufreq_hw 2>;
+ #cooling-cells = <2>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <&L3_0>;
@@ -682,6 +691,28 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ tsens0: thermal-sensor@c222000 {
+ compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
+ reg = <0 0x0C263000 0 0x1ff>, /* TM */
+ <0 0x0C222000 0 0x8>; /* SROT */
+ #qcom,sensors = <15>;
+ interrupts = <&pdc 26 IRQ_TYPE_LEVEL_HIGH>,
+<&pdc 28 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "uplow", "critical";
+
[PATCH v1 1/2] dt-bindings: thermal: qcom-tsens: Add compatible for sm8350
Add tsens bindings for sm8350. Signed-off-by: Robert Foss --- Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 95462e071ab4..e788378eff8d 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -43,6 +43,7 @@ properties: - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens + - qcom,sm8350-tsens - const: qcom,tsens-v2 reg: -- 2.27.0
[PATCH v9 13/22] media: camss: Enable SDM845
Enable support for SDM845 based Titan 170 ISPs.
Signed-off-by: Robert Foss
Reviewed-by: Andrey Konovalov
---
Changes since v5:
- Andrey: Add r-b
drivers/media/platform/qcom/camss/camss.c | 17 +
drivers/media/platform/qcom/camss/camss.h | 6 --
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss.c
b/drivers/media/platform/qcom/camss/camss.c
index 9b23285d1c20..ef100d5f7763 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -939,6 +939,12 @@ static int camss_init_subdevices(struct camss *camss)
csid_res = csid_res_660;
ispif_res = &ispif_res_660;
vfe_res = vfe_res_660;
+ } else if (camss->version == CAMSS_845) {
+ csiphy_res = csiphy_res_845;
+ csid_res = csid_res_845;
+ /* Titan VFEs don't have an ISPIF */
+ ispif_res = NULL;
+ vfe_res = vfe_res_845;
} else {
return -EINVAL;
}
@@ -1244,6 +1250,8 @@ static int camss_configure_pd(struct camss *camss)
if (camss->version == CAMSS_8x96 ||
camss->version == CAMSS_660)
nbr_pm_domains = PM_DOMAIN_GEN1_COUNT;
+ else if (camss->version == CAMSS_845)
+ nbr_pm_domains = PM_DOMAIN_GEN2_COUNT;
for (i = 0; i < nbr_pm_domains; i++) {
camss->genpd[i] = dev_pm_domain_attach_by_id(camss->dev, i);
@@ -1312,6 +1320,12 @@ static int camss_probe(struct platform_device *pdev)
camss->csiphy_num = 3;
camss->csid_num = 4;
camss->vfe_num = 2;
+ } else if (of_device_is_compatible(dev->of_node,
+ "qcom,sdm845-camss")) {
+ camss->version = CAMSS_845;
+ camss->csiphy_num = 4;
+ camss->csid_num = 3;
+ camss->vfe_num = 3;
} else {
ret = -EINVAL;
goto err_free;
@@ -1443,6 +1457,8 @@ void camss_delete(struct camss *camss)
if (camss->version == CAMSS_8x96 ||
camss->version == CAMSS_660)
nbr_pm_domains = PM_DOMAIN_GEN1_COUNT;
+ else if (camss->version == CAMSS_845)
+ nbr_pm_domains = PM_DOMAIN_GEN2_COUNT;
for (i = 0; i < nbr_pm_domains; i++) {
device_link_del(camss->genpd_link[i]);
@@ -1476,6 +1492,7 @@ static const struct of_device_id camss_dt_match[] = {
{ .compatible = "qcom,msm8916-camss" },
{ .compatible = "qcom,msm8996-camss" },
{ .compatible = "qcom,sdm660-camss" },
+ { .compatible = "qcom,sdm845-camss" },
{ }
};
diff --git a/drivers/media/platform/qcom/camss/camss.h
b/drivers/media/platform/qcom/camss/camss.h
index 33ed16ab821d..dc8b4154f92b 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -60,6 +60,8 @@ enum pm_domain {
PM_DOMAIN_VFE0 = 0,
PM_DOMAIN_VFE1 = 1,
PM_DOMAIN_GEN1_COUNT = 2, /* CAMSS series of ISPs */
+ PM_DOMAIN_VFELITE = 2, /* VFELITE / TOP GDSC */
+ PM_DOMAIN_GEN2_COUNT = 3, /* Titan series of ISPs */
};
enum camss_version {
@@ -83,8 +85,8 @@ struct camss {
int vfe_num;
struct vfe_device *vfe;
atomic_t ref_count;
- struct device *genpd[PM_DOMAIN_GEN1_COUNT];
- struct device_link *genpd_link[PM_DOMAIN_GEN1_COUNT];
+ struct device *genpd[PM_DOMAIN_GEN2_COUNT];
+ struct device_link *genpd_link[PM_DOMAIN_GEN2_COUNT];
};
struct camss_camera_interface {
--
2.27.0
[PATCH v9 07/22] media: camss: Add support for VFE hardware version Titan 170
Add register definitions for version 170 of the Titan architecture and implement support for the RDI output mode. The RDI mode as opposed to the PIX output mode for the VFE unit does not support any ISP functionality. This means essentially only supporting dumping the output of the whatever the CSI decoder receives from the sensor. For example will a sensor outputting YUV pixel format frames, only allow the VFE to dump those frames as they are received by the ISP to memory through the RDI interface. Signed-off-by: Robert Foss Reviewed-by: Andrey Konovalov --- Changes since v1: - Andrey: Remove commented out chunk - Remove left over WIP comments Changes since v4: - Andrey: Remove traces of PIX support - Andrey: Fix vfe_global_reset() overwriting reset command - Remove unused variable Changes since v5: - Andrey: Fix copy/paste issues in header - Andrey: Remove unecessary looping for 1 value Changes since v6: - Andrey: Add r-b Changes since v7: - Hans: Fix "make C=1 CHECK='/usr/bin/sparse'" warnings - Hans: Fix checkpatch.pl --strict warnings drivers/media/platform/qcom/camss/Makefile| 1 + .../media/platform/qcom/camss/camss-vfe-170.c | 767 ++ drivers/media/platform/qcom/camss/camss-vfe.c | 47 +- drivers/media/platform/qcom/camss/camss-vfe.h | 24 +- .../media/platform/qcom/camss/camss-video.c | 52 ++ drivers/media/platform/qcom/camss/camss.c | 61 ++ 6 files changed, 934 insertions(+), 18 deletions(-) create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-170.c diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile index 940c0ae3e003..052c4f405fa3 100644 --- a/drivers/media/platform/qcom/camss/Makefile +++ b/drivers/media/platform/qcom/camss/Makefile @@ -11,6 +11,7 @@ qcom-camss-objs += \ camss-vfe-4-1.o \ camss-vfe-4-7.o \ camss-vfe-4-8.o \ + camss-vfe-170.o \ camss-vfe-gen1.o \ camss-vfe.o \ camss-video.o \ diff --git a/drivers/media/platform/qcom/camss/camss-vfe-170.c b/drivers/media/platform/qcom/camss/camss-vfe-170.c new file mode 100644 index ..d99971e0b83c --- /dev/null +++ b/drivers/media/platform/qcom/camss/camss-vfe-170.c @@ -0,0 +1,767 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * camss-vfe-170.c + * + * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v170 + * + * Copyright (C) 2020-2021 Linaro Ltd. + */ + +#include +#include +#include +#include + +#include "camss.h" +#include "camss-vfe.h" + +#define VFE_HW_VERSION (0x000) + +#define VFE_GLOBAL_RESET_CMD (0x018) +#defineGLOBAL_RESET_CMD_CORE BIT(0) +#defineGLOBAL_RESET_CMD_CAMIF BIT(1) +#defineGLOBAL_RESET_CMD_BUSBIT(2) +#defineGLOBAL_RESET_CMD_BUS_BDGBIT(3) +#defineGLOBAL_RESET_CMD_REGISTER BIT(4) +#defineGLOBAL_RESET_CMD_PM BIT(5) +#defineGLOBAL_RESET_CMD_BUS_MISR BIT(6) +#defineGLOBAL_RESET_CMD_TESTGENBIT(7) +#defineGLOBAL_RESET_CMD_DSPBIT(8) +#defineGLOBAL_RESET_CMD_IDLE_CGC BIT(9) +#defineGLOBAL_RESET_CMD_RDI0 BIT(10) +#defineGLOBAL_RESET_CMD_RDI1 BIT(11) +#defineGLOBAL_RESET_CMD_RDI2 BIT(12) +#defineGLOBAL_RESET_CMD_RDI3 BIT(13) +#defineGLOBAL_RESET_CMD_VFE_DOMAIN BIT(30) +#defineGLOBAL_RESET_CMD_RESET_BYPASS BIT(31) + +#define VFE_CORE_CFG (0x050) +#defineCFG_PIXEL_PATTERN_YCBYCR(0x4) +#defineCFG_PIXEL_PATTERN_YCRYCB(0x5) +#defineCFG_PIXEL_PATTERN_CBYCRY(0x6) +#defineCFG_PIXEL_PATTERN_CRYCBY(0x7) +#defineCFG_COMPOSITE_REG_UPDATE_EN BIT(4) + +#define VFE_IRQ_CMD(0x058) +#defineCMD_GLOBAL_CLEARBIT(0) + +#define VFE_IRQ_MASK_0 (0x05c) +#defineMASK_0_CAMIF_SOFBIT(0) +#defineMASK_0_CAMIF_EOFBIT(1) +#defineMASK_0_RDI_REG_UPDATE(n)BIT((n) + 5) +#defineMASK_0_IMAGE_MASTER_n_PING_PONG(n) BIT((n) + 8) +#defineMASK_0_IMAGE_COMPOSITE_DONE_n(n)BIT((n) + 25) +#defineMASK_0_RESET_ACKBIT(31) + +#define VFE_IRQ_MASK_1 (0x060) +#defineMASK_1_CAMIF_ERROR BIT(0) +#defineMASK_1_VIOLATIONBIT(7) +#defin
[PATCH v9 21/22] arm64: dts: sdm845-db845c: Configure regulators for camss node
Add regulator to camss device tree node.
Signed-off-by: Robert Foss
Reviewed-by: Andrey Konovalov
---
Changes since v5:
- Andrey: Add r-b
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index c4ac6f5dc008..7e3c9fe4955d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -1108,6 +1108,10 @@ &cci {
status = "okay";
};
+&camss {
+ vdda-supply = <&vreg_l1a_0p875>;
+};
+
&cci_i2c0 {
camera@10 {
compatible = "ovti,ov8856";
--
2.27.0
[PATCH v9 14/22] dt-bindings: media: camss: Add qcom,msm8916-camss binding
Add bindings for qcom,msm8916-camss in order to support the camera
subsystem on MSM8916.
Signed-off-by: Robert Foss
Reviewed-by: Rob Herring
---
Changes since v2:
- Remove redundant descriptions
- Add power domain description
- Make clock-lanes a constant
- Add max & minItems to data-lanes
- Remove ports requirement - endpoint & reg
- Rework to conform to new port schema
Changes since v4:
- Rob: Added r-b
.../bindings/media/qcom,msm8916-camss.yaml| 256 ++
1 file changed, 256 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
new file mode 100644
index ..304908072d72
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
@@ -0,0 +1,256 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Qualcomm CAMSS ISP
+
+maintainers:
+ - Robert Foss
+ - Todor Tomov
+
+description: |
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
+
+properties:
+ compatible:
+const: qcom,msm8916-camss
+
+ clocks:
+minItems: 19
+maxItems: 19
+
+ clock-names:
+items:
+ - const: top_ahb
+ - const: ispif_ahb
+ - const: csiphy0_timer
+ - const: csiphy1_timer
+ - const: csi0_ahb
+ - const: csi0
+ - const: csi0_phy
+ - const: csi0_pix
+ - const: csi0_rdi
+ - const: csi1_ahb
+ - const: csi1
+ - const: csi1_phy
+ - const: csi1_pix
+ - const: csi1_rdi
+ - const: ahb
+ - const: vfe0
+ - const: csi_vfe0
+ - const: vfe_ahb
+ - const: vfe_axi
+
+ interrupts:
+minItems: 6
+maxItems: 6
+
+ interrupt-names:
+items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csid0
+ - const: csid1
+ - const: ispif
+ - const: vfe0
+
+ iommus:
+maxItems: 1
+
+ power-domains:
+items:
+ - description: VFE GDSC - Video Front End, Global Distributed Switch
Controller.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+description:
+ CSI input ports.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description:
+ Input port for receiving CSI data.
+
+properties:
+ endpoint:
+$ref: video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ clock-lanes:
+items:
+ - const: 1
+
+ data-lanes:
+description:
+ An array of physical data lanes indexes.
+ Position of an entry determines the logical
+ lane number, while the value of an entry
+ indicates physical lane index. Lane swapping
+ is supported. Physical lane indexes;
+ 0, 2, 3, 4.
+minItems: 1
+maxItems: 4
+
+required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedProperties: false
+description:
+ Input port for receiving CSI data.
+
+properties:
+ endpoint:
+$ref: video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ clock-lanes:
+items:
+ - const: 1
+
+ data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+ - clock-lanes
+ - data-lanes
+
+ reg:
+minItems: 9
+maxItems: 9
+
+ reg-names:
+items:
+ - const: csiphy0
+ - const: csiphy0_clk_mux
+ - const: csiphy1
+ - const: csiphy1_clk_mux
+ - const: csid0
+ - const: csid1
+ - const: ispif
+ - const: csi_clk_mux
+ - const: vfe0
+
+ vdda-supply:
+description:
+ Definition of the regulator used as analog power supply.
+
+required:
+ - clock-names
+ - clocks
+ - compatible
+ - interrupt-names
+ - interrupts
+ - iommus
+ - power-domains
+ - reg
+ - reg-names
+ - vdda-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+camss: camss@1b0 {
+ compatible = "qcom,msm8916-camss";
+
+ clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+<&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+<&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+<&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+<&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+<&gcc GCC_CAMSS_CSI0_CLK
[PATCH v9 22/22] arm64: dts: sdm845-db845c: Enable ov8856 sensor and connect to ISP
Enable camss & ov8856 DT nodes.
Signed-off-by: Robert Foss
Reviewed-by: Andrey Konovalov
---
Changes since v5:
- Andrey: Add r-b
- Change CSI clock & data pins
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index 7e3c9fe4955d..e5a693c8dc42 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -1110,6 +1110,21 @@ &cci {
&camss {
vdda-supply = <&vreg_l1a_0p875>;
+
+ status = "ok";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ csiphy0_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&ov8856_ep>;
+ };
+ };
+ };
};
&cci_i2c0 {
@@ -1141,7 +1156,7 @@ camera@10 {
avdd-supply = <&cam0_avdd_2v8>;
dvdd-supply = <&cam0_dvdd_1v2>;
- status = "disable";
+ status = "ok";
port {
ov8856_ep: endpoint {
@@ -1149,7 +1164,7 @@ ov8856_ep: endpoint {
link-frequencies = /bits/ 64
<36000 18000>;
data-lanes = <1 2 3 4>;
-// remote-endpoint = <&csiphy0_ep>;
+ remote-endpoint = <&csiphy0_ep>;
};
};
};
--
2.27.0
[PATCH v9 20/22] arm64: dts: sdm845: Add CAMSS ISP node
Add the camss dt node for sdm845.
Signed-off-by: Robert Foss
Reviewed-by: Andrey Konovalov
---
Changes since v1:
- Laurent: Fix subject
- Laurent: Remove redundant regulator labels
- Laurent: Remove empty line
Changes since v3:
- Fixed ordering of IRQs
- Add newlines for better readability
Changes since v5:
- Andrey: Add r-b
arch/arm64/boot/dts/qcom/sdm845.dtsi | 135 +++
1 file changed, 135 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 454f794af547..36cf4503664c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3909,6 +3909,141 @@ videocc: clock-controller@ab0 {
#reset-cells = <1>;
};
+ camss: camss@a0 {
+ compatible = "qcom,sdm845-camss";
+
+ reg = <0 0xacb3000 0 0x1000>,
+ <0 0xacba000 0 0x1000>,
+ <0 0xacc8000 0 0x1000>,
+ <0 0xac65000 0 0x1000>,
+ <0 0xac66000 0 0x1000>,
+ <0 0xac67000 0 0x1000>,
+ <0 0xac68000 0 0x1000>,
+ <0 0xacaf000 0 0x4000>,
+ <0 0xacb6000 0 0x4000>,
+ <0 0xacc4000 0 0x4000>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "vfe0",
+ "vfe1",
+ "vfe_lite";
+
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "vfe0",
+ "vfe1",
+ "vfe_lite";
+
+ power-domains = <&clock_camcc IFE_0_GDSC>,
+ <&clock_camcc IFE_1_GDSC>,
+ <&clock_camcc TITAN_TOP_GDSC>;
+
+ clocks = <&clock_camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&clock_camcc CAM_CC_CPAS_AHB_CLK>,
+ <&clock_camcc CAM_CC_CPHY_RX_CLK_SRC>,
+ <&clock_camcc CAM_CC_IFE_0_CSID_CLK>,
+ <&clock_camcc CAM_CC_IFE_0_CSID_CLK_SRC>,
+ <&clock_camcc CAM_CC_IFE_1_CSID_CLK>,
+ <&clock_camcc CAM_CC_IFE_1_CSID_CLK_SRC>,
+ <&clock_camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&clock_camcc CAM_CC_IFE_LITE_CSID_CLK_SRC>,
+ <&clock_camcc CAM_CC_CSIPHY0_CLK>,
+ <&clock_camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&clock_camcc CAM_CC_CSI0PHYTIMER_CLK_SRC>,
+ <&clock_camcc CAM_CC_CSIPHY1_CLK>,
+ <&clock_camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&clock_camcc CAM_CC_CSI1PHYTIMER_CLK_SRC>,
+ <&clock_camcc CAM_CC_CSIPHY2_CLK>,
+ <&clock_camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&clock_camcc CAM_CC_CSI2PHYTIMER_CLK_SRC>,
+ <&clock_camcc CAM_CC_CSIPHY3_CLK>,
+ <&clock_camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&clock_camcc CAM_CC_CSI3PHYTIMER_CLK_SRC>,
+ <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_AXI_CL
[PATCH v9 19/22] media: dt-bindings: media: Remove qcom,camss documentation
This documentation has been incorporated in dtschema dt-bindings for the devices supported by CAMSS and is no longer helpful. Signed-off-by: Robert Foss Reviewed-by: Rob Herring --- Changes since v4: - Rob: Added r-b .../devicetree/bindings/media/qcom,camss.txt | 236 -- 1 file changed, 236 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt b/Documentation/devicetree/bindings/media/qcom,camss.txt deleted file mode 100644 index 498234629e21.. --- a/Documentation/devicetree/bindings/media/qcom,camss.txt +++ /dev/null @@ -1,236 +0,0 @@ -Qualcomm Camera Subsystem - -* Properties - -- compatible: - Usage: required - Value type: - Definition: Should contain one of: - - "qcom,msm8916-camss" - - "qcom,msm8996-camss" - - "qcom,sdm660-camss" -- reg: - Usage: required - Value type: - Definition: Register ranges as listed in the reg-names property. -- reg-names: - Usage: required - Value type: - Definition: Should contain the following entries: - - "csiphy0" - - "csiphy0_clk_mux" - - "csiphy1" - - "csiphy1_clk_mux" - - "csiphy2" (8996 only) - - "csiphy2_clk_mux" (8996 only) - - "csid0" - - "csid1" - - "csid2" (8996 only) - - "csid3" (8996 only) - - "ispif" - - "csi_clk_mux" - - "vfe0" - - "vfe1"(8996 only) -- interrupts: - Usage: required - Value type: - Definition: Interrupts as listed in the interrupt-names property. -- interrupt-names: - Usage: required - Value type: - Definition: Should contain the following entries: - - "csiphy0" - - "csiphy1" - - "csiphy2" (8996 only) - - "csid0" - - "csid1" - - "csid2" (8996 only) - - "csid3" (8996 only) - - "ispif" - - "vfe0" - - "vfe1"(8996 only) -- power-domains: - Usage: required - Value type: - Definition: A phandle and power domain specifier pairs to the - power domain which is responsible for collapsing - and restoring power to the peripheral. -- clocks: - Usage: required - Value type: - Definition: A list of phandle and clock specifier pairs as listed - in clock-names property. -- clock-names: - Usage: required - Value type: - Definition: Should contain the following entries: - - "top_ahb" - - "throttle_axi"(660 only) - - "ispif_ahb" - - "csiphy0_timer" - - "csiphy1_timer" - - "csiphy2_timer" (8996 only) - - "csiphy_ahb2crif" (660 only) - - "csi0_ahb" - - "csi0" - - "csi0_phy" - - "csi0_pix" - - "csi0_rdi" - - "cphy_csid0" (660 only) - - "csi1_ahb" - - "csi1" - - "csi1_phy" - - "csi1_pix" - - "csi1_rdi" - - "cphy_csid1" (660 only) - - "csi2_ahb"(8996 only) - - "csi2"(8996 only) - - "csi2_phy"(8996 only) - - "csi2_pix"(8996 only) - - "csi2_rdi"(8996 only) - - "cphy_csid2" (660 only) - - "csi3_ahb"(8996 only) - - "csi3"(8996 only) - - "csi3_phy"(8996 only) - - "csi3_pix"(8996 only) - - "csi3_rdi"(8996 only) - - "cphy_csid3" (660 only) - - "ahb" - - "vfe0" - - "csi_vfe0" - - "vfe0_ahb", (8996 only) - - "vfe0_stream",(8996 o
[PATCH v9 18/22] MAINTAINERS: Change CAMSS documentation to use dtschema bindings
Due to the complexity of describing multiple hardware generations in one document, switch to using separate dt-bindings. Signed-off-by: Robert Foss Reviewed-by: Rob Herring --- Changes since v4 - Rob: Added r-b MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d92f85ca831d..7da3e0c74fab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14787,7 +14787,7 @@ M: Todor Tomov L: linux-me...@vger.kernel.org S: Maintained F: Documentation/admin-guide/media/qcom_camss.rst -F: Documentation/devicetree/bindings/media/qcom,camss.txt +F: Documentation/devicetree/bindings/media/*camss* F: drivers/media/platform/qcom/camss/ QUALCOMM CORE POWER REDUCTION (CPR) AVS DRIVER -- 2.27.0
[PATCH v9 17/22] dt-bindings: media: camss: Add qcom,sdm845-camss binding
Add bindings for qcom,sdm845-camss in order to support the camera subsystem for SDM845. Signed-off-by: Robert Foss Reviewed-by: Rob Herring --- Changes since v2: - Rob: Removed extra empty lines at end of file - Rob: Add new line at end of file - Rob: Remove redundant descriptions - Rob: Add power domain description - Rob: Make clock-lanes a constant - Rob: Rework to conform to new port schema - Add max & minItems to data-lanes - Remove ports requirement - endpoint & reg - Add proper commit message - Remove Todor as binding maintainer Changes since v3: - Fixed ordering of IRQs Changes since v4: - Rob: Added r-b Changes since v5: - Force CSI clock to use pin 7 .../bindings/media/qcom,sdm845-camss.yaml | 371 ++ 1 file changed, 371 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml new file mode 100644 index ..9ca5dfa7f226 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -0,0 +1,371 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml#"; +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; + +title: Qualcomm CAMSS ISP + +maintainers: + - Robert Foss + +description: | + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms + +properties: + compatible: +const: qcom,sdm845-camss + + clocks: +minItems: 36 +maxItems: 36 + + clock-names: +items: + - const: camnoc_axi + - const: cpas_ahb + - const: cphy_rx_src + - const: csi0 + - const: csi0_src + - const: csi1 + - const: csi1_src + - const: csi2 + - const: csi2_src + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy0_timer_src + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy1_timer_src + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy2_timer_src + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy3_timer_src + - const: gcc_camera_ahb + - const: gcc_camera_axi + - const: slow_ahb_src + - const: soc_ahb + - const: vfe0_axi + - const: vfe0 + - const: vfe0_cphy_rx + - const: vfe0_src + - const: vfe1_axi + - const: vfe1 + - const: vfe1_cphy_rx + - const: vfe1_src + - const: vfe_lite + - const: vfe_lite_cphy_rx + - const: vfe_lite_src + + interrupts: +minItems: 10 +maxItems: 10 + + interrupt-names: +items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + iommus: +maxItems: 4 + + power-domains: +items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +description: + CSI input ports. + +properties: + port@0: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +maxItems: 1 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@1: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@2: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +maxItems: 1 + + data-lanes:
[PATCH v9 16/22] dt-bindings: media: camss: Add qcom,sdm660-camss binding
Add bindings for qcom,sdm660-camss in order to support the camera subsystem on SDM630/660 and SDA variants. Signed-off-by: Robert Foss Reviewed-by: Rob Herring --- Changes since v2: - Rob: Add new line at end of file - Rob: Remove redundant descriptions - Rob: Add power domain description - Rob: Make clock-lanes a constant - Rob: Rework to conform to new port schema - Add max & minItems to data-lanes - Remove ports requirement - endpoint & reg - Added Angelo as binding maintainer - Removed Todor as binding maintainer Changes since v3: - Rob: Added r-b .../bindings/media/qcom,sdm660-camss.yaml | 398 ++ 1 file changed, 398 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml new file mode 100644 index ..841a1aafdd13 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -0,0 +1,398 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#"; +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; + +title: Qualcomm CAMSS ISP + +maintainers: + - Robert Foss + - AngeloGioacchino Del Regno + +description: | + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms + +properties: + compatible: +const: qcom,sdm660-camss + + clocks: +minItems: 42 +maxItems: 42 + + clock-names: +items: + - const: ahb + - const: cphy_csid0 + - const: cphy_csid1 + - const: cphy_csid2 + - const: cphy_csid3 + - const: csi0_ahb + - const: csi0 + - const: csi0_phy + - const: csi0_pix + - const: csi0_rdi + - const: csi1_ahb + - const: csi1 + - const: csi1_phy + - const: csi1_pix + - const: csi1_rdi + - const: csi2_ahb + - const: csi2 + - const: csi2_phy + - const: csi2_pix + - const: csi2_rdi + - const: csi3_ahb + - const: csi3 + - const: csi3_phy + - const: csi3_pix + - const: csi3_rdi + - const: csiphy0_timer + - const: csiphy1_timer + - const: csiphy2_timer + - const: csiphy_ahb2crif + - const: csi_vfe0 + - const: csi_vfe1 + - const: ispif_ahb + - const: throttle_axi + - const: top_ahb + - const: vfe0_ahb + - const: vfe0 + - const: vfe0_stream + - const: vfe1_ahb + - const: vfe1 + - const: vfe1_stream + - const: vfe_ahb + - const: vfe_axi + + interrupts: +minItems: 10 +maxItems: 10 + + interrupt-names: +items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid3 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: ispif + - const: vfe0 + - const: vfe1 + + iommus: +maxItems: 4 + + power-domains: +items: + - description: VFE0 GDSC - Video Front End, Global Distributed Switch Controller. + - description: VFE1 GDSC - Video Front End, Global Distributed Switch Controller. + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +description: + CSI input ports. + +properties: + port@0: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@1: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@2: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1
[PATCH v9 15/22] dt-bindings: media: camss: Add qcom,msm8996-camss binding
Add bindings for qcom,msm8996-camss in order to support the camera subsystem on MSM8996. Signed-off-by: Robert Foss Reviewed-by: Rob Herring --- Changes since v2 - Rob: Add new line at end of file - Rob: Remove redundant descriptions - Rob: Add power domain description - Rob: Make clock-lanes a constant - Rob: Rework to conform to new port schema - Add max & minItems to data-lanes - Remove ports requirement - endpoint & reg Changes since v4 - Rob: Added r-b .../bindings/media/qcom,msm8996-camss.yaml| 387 ++ 1 file changed, 387 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml new file mode 100644 index ..38be41e932f0 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -0,0 +1,387 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml#"; +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; + +title: Qualcomm CAMSS ISP + +maintainers: + - Robert Foss + - Todor Tomov + +description: | + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms + +properties: + compatible: +const: qcom,msm8996-camss + + clocks: +minItems: 36 +maxItems: 36 + + clock-names: +items: + - const: top_ahb + - const: ispif_ahb + - const: csiphy0_timer + - const: csiphy1_timer + - const: csiphy2_timer + - const: csi0_ahb + - const: csi0 + - const: csi0_phy + - const: csi0_pix + - const: csi0_rdi + - const: csi1_ahb + - const: csi1 + - const: csi1_phy + - const: csi1_pix + - const: csi1_rdi + - const: csi2_ahb + - const: csi2 + - const: csi2_phy + - const: csi2_pix + - const: csi2_rdi + - const: csi3_ahb + - const: csi3 + - const: csi3_phy + - const: csi3_pix + - const: csi3_rdi + - const: ahb + - const: vfe0 + - const: csi_vfe0 + - const: vfe0_ahb + - const: vfe0_stream + - const: vfe1 + - const: csi_vfe1 + - const: vfe1_ahb + - const: vfe1_stream + - const: vfe_ahb + - const: vfe_axi + + interrupts: +minItems: 10 +maxItems: 10 + + interrupt-names: +items: + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid3 + - const: ispif + - const: vfe0 + - const: vfe1 + + iommus: +maxItems: 4 + + power-domains: +items: + - description: VFE0 GDSC - Video Front End, Global Distributed Switch Controller. + - description: VFE1 GDSC - Video Front End, Global Distributed Switch Controller. + + ports: +$ref: /schemas/graph.yaml#/properties/ports + +description: + CSI input ports. + +properties: + port@0: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +description: + An array of physical data lanes indexes. + Position of an entry determines the logical + lane number, while the value of an entry + indicates physical lane index. Lane swapping + is supported. Physical lane indexes are; + 0, 1, 2, 3 +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@1: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: + - const: 7 + + data-lanes: +minItems: 1 +maxItems: 4 + +required: + - clock-lanes + - data-lanes + + port@2: +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false +description: + Input port for receiving CSI data. + +properties: + endpoint: +$ref: video-interfaces.yaml# +unevaluatedProperties: false + +properties: + clock-lanes: +items: +
