All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Kees Cook <keescook@chromium.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Robert Foss <robert.foss@linaro.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Harry Wentland <harry.wentland@amd.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Maxime Ripard <maxime@cerno.tech>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Paul Boddie <paul@boddie.org.uk>,
	OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
	<devicetree@vger.kernel.org>,
	linux-mips <linux-mips@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Discussions about the Letux Kernel 
	<letux-kernel@openphoenux.org>, Jonas Karlman <jonas@kwiboo.se>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Date: Mon, 08 Nov 2021 16:30:47 +0000	[thread overview]
Message-ID: <BVH92R.0VU3IKPQTLX9@crapouillou.net> (raw)
In-Reply-To: <D0809E59-DCB5-46CE-BE5E-D2A5D2ECA6F0@goldelico.com>

Hi,

Le lun., nov. 8 2021 at 16:29:11 +0100, H. Nikolaus Schaller 
<hns@goldelico.com> a écrit :
> Bnjour Paul,
> 
> 
>>  Am 08.11.2021 um 13:20 schrieb Paul Cercueil <paul@crapouillou.net>:
>> 
>>  Hi,
>> 
>>  Le lun., nov. 8 2021 at 11:52:20 +0100, H. Nikolaus Schaller 
>> <hns@goldelico.com> a écrit :
>>>  Hi Paul,
>>>>>  Am 08.11.2021 um 10:37 schrieb Paul Cercueil 
>>>>> <paul@crapouillou.net>:
>>>>>  Well, it was atomic: "add jz4780+hdmi functionality" or not. Now 
>>>>> we separate into "preparation for adding jz4780" and "really 
>>>>> adding". Yes, you can split atoms into quarks...
>>>>  And that's how it should be done. Lots of small atomic patches 
>>>> are much easier to review than a few big patches.
>>>  I doubt that in this case especially as it has nothing to do with 
>>> jz4780...
>> 
>>  It has nothing to do with JZ4780 and that's exactly why it should 
>> be a separate patch.
> 
> Question is why *I* should then make this patch and not someone 
> else...
> 
> I am not necessarily a volunteer to contribute to non-jz4780 code 
> just because I want to upstream jz4780 code.

The JZ4780 patch lies on top of the other one, so they are still 
related. They just shouldn't be the same patch.

>> 
>>>  But I have a proposal for a better solution at the end of this 
>>> mail.
>>>>>>  Note that you can do even better, set the .max_register field 
>>>>>> according to the memory resource you get from DTS. Have a look 
>>>>>> at the pinctrl driver which does exactly this.
>>>>>  That is an interesting idea. Although I don't see where
>>>>>  
>>>>> https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/pinctrl-ingenic.c#L4171
>>>>>  does make use of the memory resource from DTS. It just reads two 
>>>>> values from the ingenic_chip_info instead of one I do read from 
>>>>> soc_info.
>>>>  It overrides the .max_register from a static regmap_config 
>>>> instance.
>>>  To be precise: it overrides .max_register of a copy of a static 
>>> regmap_config instance (which has .max_register = 0).
>>>>  You can do the same,
>>>  We already do the same...
>>>>  calculating the .max_register from the memory resource you get 
>>>> from DT.
>>>  I can't see any code in pinctrl-ingenic.c getting the memory 
>>> resource that from DT. It calculates it from the ingenic_chip_info 
>>> tables inside the driver code but not DT.
>>>>  I'm sure you guys can figure it out.
>>>  Ah, we have to figure out. You are not sure yourself how to do it? 
>>> And it is *not* exactly like the pinctrl driver (already) does? 
>>> Please give precise directions in reviews and not vague research 
>>> homework. Our time is also valuable. Sorry if I review your 
>>> reviews...
>>>  Anyways I think you roughly intend (untested):
>>>  	struct resource *r;
>>>  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>  	regmap_config.max_register = r.end - r.start;
>> 
>>  Replace the "devm_platform_ioremap_resource" with 
>> "devm_platform_get_and_ioremap_resource" to get a pointer to the 
>> resource.
>> 
>>  Then the .max_register should be (r.end - r.start - 4) I think.
>> 
>>  And lose the aggressivity. It's not going to get you anywhere, 
>> especially since I'm the one who decides whether or not I should 
>> merge your patches. You want your code upstream, that's great, but 
>> it's your responsability to get it to shape so that it's eventually 
>> accepted.
> 
> Well on the other side of the fence it is maintainers responsibility 
> to give clear and understandable rules and guidance about what will 
> be accepted and to enable us to bring it into the shape he/she has in 
> mind.
> 
> But a fundamental problem is: "good shape" is very subjective. What 
> would you recommend me to do, if I feel that my proposed code is in 
> better shape than what the maintainer thinks or recommends?
> 
>> 
>>>  But I wonder how that could work at all (despite adding code 
>>> execution time) with:
>> 
>>  Code execution time? ...
> 
> I reasoned about doing an additional platform_get_resource() call and 
> doing a subtraction. This is additional execution time. Maybe not 
> worth thinking about because it is in the probe function. And using 
> devm_platform_get_and_ioremap_resource() is of course potentially 
> better.
> 
>> 
>>>  e.g. jz4770.dtsi:
>>>  	lcd: lcd-controller@13050000 {
>>>  		compatible = "ingenic,jz4770-lcd";
>>>  		reg = <0x13050000 0x300>;
>>>  or jz4725b.dtsi:
>>>  	lcd: lcd-controller@13050000 {
>>>  		compatible = "ingenic,jz4725b-lcd";
>>>  		reg = <0x13050000 0x1000>;
>>>  So max_register becomes 0x300 or 0x1000 but not
>>>  #define JZ_REG_LCD_SIZE1	0x12c
>>>  	.max_reg = JZ_REG_LCD_SIZE1,
>>>  And therefore wastes a lot of regmap memory.
>> 
>>  "regmap memory"? ...
> 
> regmap allocates memory for its cache. Usually the total amount 
> specified in the reg property.

We are not using any register cache here.

>> 
>>>  Do you want this? DTS should not be reduced (DTS should be kept as 
>>> stable as possible), since the reg property describes address 
>>> mapping - not how many bytes are really used by registers or how 
>>> big a cache should be allocated (cache allocation size requirements 
>>> are not hardware description).
>> 
>>  The DTS should list the address and size of the register area. If 
>> your last register is at address 0x12c and there's nothing above, 
>> then the size in DTS should be 0x130.
> 
> If I look into some .dtsi it is sometimes that way but sometimes not. 
> There seems to be no consistent rule.
> 
> So does this mean you allow me to modify jz4740.dtsi, jz4770.dtsi and 
> jz4725b.dtsi as well (as mentioned above: this is beyond the scope of 
> my project)?

You could update them if you wanted to, but there is no need to do it 
here.

>> 
>>>  But here are good news:
>>>  I have a simpler and less invasive proposal. We keep the 
>>> devm_regmap_init_mmio code as is and just increase its 
>>> .max_register from JZ_REG_LCD_SIZE1 to JZ_REG_LCD_PCFG when 
>>> introducing the jz4780. This wastes a handful bytes for all 
>>> non-jz4780 chips but less than using the DTS memory region size. 
>>> And is less code (no entry in soc_info tables, no modifyable copy) 
>>> and faster code execution than all other proposals.
>>>  This is then just a single-line change when introducing the 
>>> jz4780. And no "preparation for adding jz4780" patch is needed at 
>>> all. No patch to split out for separate review.
>>>  Let's go this way to get it eventually finalized. Ok?
>> 
>>  No.
> 
> Look friend, if you explain your "no" and what is wrong with my 
> arguments, it helps to understand your decisions and learn something 
> from them. A plain "no" does not help anyone.

I answered just "no" because I felt like I explained already what I 
wanted to see in the previous email.

By using a huge number as the .max_register, we do *not* waste 
additional memory. Computing the value of the .max_register field does 
not add any overhead, either.

The .max_register is only used for boundary checking. To make sure that 
you're not calling regmap_write() with an invalid register. That's all 
there is to it.

> So to summarize: if you prefer something which I consider worse, it 
> is ok for me... In the end you are right - you are the maintainer, 
> not me. So you have to live with your proposals.
> 
> Therefore, I have prepared new variants so you can choose which one 
> is easier to maintain for you.
> 
> Note that they are both preparing for full jz4780-lcdc/hdmi support 
> but in very different ways:
> 
> Variant 1 already adds some jz4780 stuff while Variant 2 just 
> prepares for it.
> 
> Variant 2 is not tested (except to compile). So it needs some 
> Tested-by: from someone with access to hardware. IMHO it is more 
> invasive.
> 
> And don't forget: DTB could be in ROM or be provided by a separate 
> bootloader... So we should not change it too often (I had such 
> discussions some years ago with maintainers when I thought it is 
> easier to change DTS instead of code).
> 
> Variant 3 would be to not separate this. As proposed in [PATCH v5 
> 2/7].
> (Finally, a Variant 3b would be to combine the simple change from 
> Variant 1 with Variant 3).
> 
> So what is your choice?

Variant 4: the variant #2 without the changes to the DTSI files.

Cheers,
-Paul


> BR and thanks,
> Nikolaus
> 
> 
> #### VARIANT 0001 ####
> 
> From c7afa925f6b53bb6cafa080b7dd582788c8eb2eb Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: Mon, 8 Nov 2021 15:38:21 +0100
> Subject: [PATCH] RFC: drm/ingenic: Add register definitions for 
> JZ4780 lcdc
> 
> JZ4780 has additional registers compared to the other
> SoC of the JZ47xx series. So we add the constants for
> registers and bits we make use of (there are even more
> which can be added later).
> 
> And we increase the regmap max_register accordingly.
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm.h     | 39 
> +++++++++++++++++++++++
>  2 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index a5df1c8d34cde..1903e897d2299 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -122,7 +122,7 @@ static const struct regmap_config 
> ingenic_drm_regmap_config = {
>  	.val_bits = 32,
>  	.reg_stride = 4,
> 
> -	.max_register = JZ_REG_LCD_SIZE1,
> +	.max_register = JZ_REG_LCD_PCFG,
>  	.writeable_reg = ingenic_drm_writeable_reg,
>  };
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.h 
> b/drivers/gpu/drm/ingenic/ingenic-drm.h
> index 22654ac1dde1c..e7430c4af41f6 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.h
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.h
> @@ -44,8 +44,11 @@
>  #define JZ_REG_LCD_XYP1				0x124
>  #define JZ_REG_LCD_SIZE0			0x128
>  #define JZ_REG_LCD_SIZE1			0x12c
> +#define JZ_REG_LCD_PCFG				0x2c0
> 
>  #define JZ_LCD_CFG_SLCD				BIT(31)
> +#define JZ_LCD_CFG_DESCRIPTOR_8			BIT(28)
> +#define JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN	BIT(25)
>  #define JZ_LCD_CFG_PS_DISABLE			BIT(23)
>  #define JZ_LCD_CFG_CLS_DISABLE			BIT(22)
>  #define JZ_LCD_CFG_SPL_DISABLE			BIT(21)
> @@ -63,6 +66,7 @@
>  #define JZ_LCD_CFG_DE_ACTIVE_LOW		BIT(9)
>  #define JZ_LCD_CFG_VSYNC_ACTIVE_LOW		BIT(8)
>  #define JZ_LCD_CFG_18_BIT			BIT(7)
> +#define JZ_LCD_CFG_24_BIT			BIT(6)
>  #define JZ_LCD_CFG_PDW				(BIT(5) | BIT(4))
> 
>  #define JZ_LCD_CFG_MODE_GENERIC_16BIT		0
> @@ -132,6 +136,7 @@
>  #define JZ_LCD_CMD_SOF_IRQ			BIT(31)
>  #define JZ_LCD_CMD_EOF_IRQ			BIT(30)
>  #define JZ_LCD_CMD_ENABLE_PAL			BIT(28)
> +#define JZ_LCD_CMD_FRM_ENABLE			BIT(26)
> 
>  #define JZ_LCD_SYNC_MASK			0x3ff
> 
> @@ -153,6 +158,7 @@
>  #define JZ_LCD_RGBC_EVEN_BGR			(0x5 << 0)
> 
>  #define JZ_LCD_OSDC_OSDEN			BIT(0)
> +#define JZ_LCD_OSDC_ALPHAEN			BIT(2)
>  #define JZ_LCD_OSDC_F0EN			BIT(3)
>  #define JZ_LCD_OSDC_F1EN			BIT(4)
> 
> @@ -176,6 +182,39 @@
>  #define JZ_LCD_SIZE01_WIDTH_LSB			0
>  #define JZ_LCD_SIZE01_HEIGHT_LSB		16
> 
> +#define JZ_LCD_DESSIZE_ALPHA_OFFSET		24
> +#define JZ_LCD_DESSIZE_HEIGHT_MASK		GENMASK(23, 12)
> +#define JZ_LCD_DESSIZE_WIDTH_MASK		GENMASK(11, 0)
> +
> +/* TODO: 4,5 and 7 match the above BPP */
> +#define JZ_LCD_CPOS_BPP_15_16			(4 << 27)
> +#define JZ_LCD_CPOS_BPP_18_24			(5 << 27)
> +#define JZ_LCD_CPOS_BPP_30			(7 << 27)
> +#define JZ_LCD_CPOS_RGB555			BIT(30)
> +#define JZ_LCD_CPOS_PREMULTIPLY_LCD		BIT(26)
> +#define JZ_LCD_CPOS_COEFFICIENT_OFFSET		24
> +#define JZ_LCD_CPOS_COEFFICIENT_0		0
> +#define JZ_LCD_CPOS_COEFFICIENT_1		1
> +#define JZ_LCD_CPOS_COEFFICIENT_ALPHA1		2
> +#define JZ_LCD_CPOS_COEFFICIENT_1_ALPHA1	3
> +
> +#define JZ_LCD_RGBC_RGB_PADDING			BIT(15)
> +#define JZ_LCD_RGBC_RGB_PADDING_FIRST		BIT(14)
> +#define JZ_LCD_RGBC_422				BIT(8)
> +#define JZ_LCD_RGBC_RGB_FORMAT_ENABLE		BIT(7)
> +
> +#define JZ_LCD_PCFG_PRI_MODE			BIT(31)
> +#define JZ_LCD_PCFG_HP_BST_4			(0 << 28)
> +#define JZ_LCD_PCFG_HP_BST_8			(1 << 28)
> +#define JZ_LCD_PCFG_HP_BST_16			(2 << 28)
> +#define JZ_LCD_PCFG_HP_BST_32			(3 << 28)
> +#define JZ_LCD_PCFG_HP_BST_64			(4 << 28)
> +#define JZ_LCD_PCFG_HP_BST_16_CONT		(5 << 28)
> +#define JZ_LCD_PCFG_HP_BST_DISABLE		(7 << 28)
> +#define JZ_LCD_PCFG_THRESHOLD2_OFFSET		18
> +#define JZ_LCD_PCFG_THRESHOLD1_OFFSET		9
> +#define JZ_LCD_PCFG_THRESHOLD0_OFFSET		0
> +
>  struct device;
>  struct drm_plane;
>  struct drm_plane_state;
> --
> 2.33.0
> 
> 
> #### VARIANT 0002 ####
> 
> From c4b5cfa2789493f02da91e385719bc97aefb6c6c Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: Mon, 8 Nov 2021 14:40:58 +0100
> Subject: [PATCH] RFC: drm/ingenic: prepare ingenic drm for later 
> addition of
>  JZ4780
> 
> This changes the way the regmap is allocated to prepare for the
> later addition of the JZ4780 which has more registers and bits
> than the others.
> 
> To make this work we have to change the device tree records of
> all devices so that the reg property is limited to the physically
> available registers.
> 
> The magic value 0x130 in the device tree is JZ_REG_LCD_SIZE1 + 4.
> 
> Note that it is not tested since I have no access to the hardware.
> 
> Suggested-by: Paul Cercueil <paul@crapouillou.net>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  arch/mips/boot/dts/ingenic/jz4725b.dtsi   | 2 +-
>  arch/mips/boot/dts/ingenic/jz4740.dtsi    | 2 +-
>  arch/mips/boot/dts/ingenic/jz4770.dtsi    | 2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 ++++++---
>  4 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/mips/boot/dts/ingenic/jz4725b.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4725b.dtsi
> index a1f0b71c92237..c017b087c0e52 100644
> --- a/arch/mips/boot/dts/ingenic/jz4725b.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4725b.dtsi
> @@ -321,7 +321,7 @@ udc: usb@13040000 {
> 
>  	lcd: lcd-controller@13050000 {
>  		compatible = "ingenic,jz4725b-lcd";
> -		reg = <0x13050000 0x1000>;
> +		reg = <0x13050000 0x130>;
> 
>  		interrupt-parent = <&intc>;
>  		interrupts = <31>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> index c1afdfdaa8a38..ce3689e5015b5 100644
> --- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> @@ -323,7 +323,7 @@ udc: usb@13040000 {
> 
>  	lcd: lcd-controller@13050000 {
>  		compatible = "ingenic,jz4740-lcd";
> -		reg = <0x13050000 0x1000>;
> +		reg = <0x13050000 0x130>;
> 
>  		interrupt-parent = <&intc>;
>  		interrupts = <30>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> index 05c00b93088e9..0d1ee58d6c40b 100644
> --- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> @@ -399,7 +399,7 @@ gpu: gpu@13040000 {
> 
>  	lcd: lcd-controller@13050000 {
>  		compatible = "ingenic,jz4770-lcd";
> -		reg = <0x13050000 0x300>;
> +		reg = <0x13050000 0x130>;
> 
>  		interrupt-parent = <&intc>;
>  		interrupts = <31>;
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index a5df1c8d34cde..3c8e3c5a447bb 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -122,7 +122,6 @@ static const struct regmap_config 
> ingenic_drm_regmap_config = {
>  	.val_bits = 32,
>  	.reg_stride = 4,
> 
> -	.max_register = JZ_REG_LCD_SIZE1,
>  	.writeable_reg = ingenic_drm_writeable_reg,
>  };
> 
> @@ -858,6 +857,8 @@ static int ingenic_drm_bind(struct device *dev, 
> bool has_components)
>  	struct drm_encoder *encoder;
>  	struct drm_device *drm;
>  	void __iomem *base;
> +	struct resource *res;
> +	struct regmap_config regmap_config;
>  	long parent_rate;
>  	unsigned int i, clone_mask = 0;
>  	dma_addr_t dma_hwdesc_phys_f0, dma_hwdesc_phys_f1;
> @@ -904,14 +905,16 @@ static int ingenic_drm_bind(struct device *dev, 
> bool has_components)
>  	drm->mode_config.funcs = &ingenic_drm_mode_config_funcs;
>  	drm->mode_config.helper_private = &ingenic_drm_mode_config_helpers;
> 
> -	base = devm_platform_ioremap_resource(pdev, 0);
> +	base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
>  	if (IS_ERR(base)) {
>  		dev_err(dev, "Failed to get memory resource\n");
>  		return PTR_ERR(base);
>  	}
> 
> +	regmap_config = ingenic_drm_regmap_config;
> +	regmap_config.max_register = res->end - res->start - 4;
>  	priv->map = devm_regmap_init_mmio(dev, base,
> -					  &ingenic_drm_regmap_config);
> +					  &regmap_config);
>  	if (IS_ERR(priv->map)) {
>  		dev_err(dev, "Failed to create regmap\n");
>  		return PTR_ERR(priv->map);
> --
> 2.33.0
> 
> 



WARNING: multiple messages have this Message-ID (diff)
From: Paul Cercueil <paul@crapouillou.net>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Paul Boddie <paul@boddie.org.uk>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Neil Armstrong <narmstrong@baylibre.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-mips <linux-mips@vger.kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
	<devicetree@vger.kernel.org>, Kees Cook <keescook@chromium.org>,
	Jonas Karlman <jonas@kwiboo.se>, Mark Brown <broonie@kernel.org>,
	Maxime Ripard <maxime@cerno.tech>,
	Discussions about the Letux Kernel <letux-kernel@openphoenux.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Robert Foss <robert.foss@linaro.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>
Subject: Re: [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output
Date: Mon, 08 Nov 2021 16:30:47 +0000	[thread overview]
Message-ID: <BVH92R.0VU3IKPQTLX9@crapouillou.net> (raw)
In-Reply-To: <D0809E59-DCB5-46CE-BE5E-D2A5D2ECA6F0@goldelico.com>

Hi,

Le lun., nov. 8 2021 at 16:29:11 +0100, H. Nikolaus Schaller 
<hns@goldelico.com> a écrit :
> Bnjour Paul,
> 
> 
>>  Am 08.11.2021 um 13:20 schrieb Paul Cercueil <paul@crapouillou.net>:
>> 
>>  Hi,
>> 
>>  Le lun., nov. 8 2021 at 11:52:20 +0100, H. Nikolaus Schaller 
>> <hns@goldelico.com> a écrit :
>>>  Hi Paul,
>>>>>  Am 08.11.2021 um 10:37 schrieb Paul Cercueil 
>>>>> <paul@crapouillou.net>:
>>>>>  Well, it was atomic: "add jz4780+hdmi functionality" or not. Now 
>>>>> we separate into "preparation for adding jz4780" and "really 
>>>>> adding". Yes, you can split atoms into quarks...
>>>>  And that's how it should be done. Lots of small atomic patches 
>>>> are much easier to review than a few big patches.
>>>  I doubt that in this case especially as it has nothing to do with 
>>> jz4780...
>> 
>>  It has nothing to do with JZ4780 and that's exactly why it should 
>> be a separate patch.
> 
> Question is why *I* should then make this patch and not someone 
> else...
> 
> I am not necessarily a volunteer to contribute to non-jz4780 code 
> just because I want to upstream jz4780 code.

The JZ4780 patch lies on top of the other one, so they are still 
related. They just shouldn't be the same patch.

>> 
>>>  But I have a proposal for a better solution at the end of this 
>>> mail.
>>>>>>  Note that you can do even better, set the .max_register field 
>>>>>> according to the memory resource you get from DTS. Have a look 
>>>>>> at the pinctrl driver which does exactly this.
>>>>>  That is an interesting idea. Although I don't see where
>>>>>  
>>>>> https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/pinctrl-ingenic.c#L4171
>>>>>  does make use of the memory resource from DTS. It just reads two 
>>>>> values from the ingenic_chip_info instead of one I do read from 
>>>>> soc_info.
>>>>  It overrides the .max_register from a static regmap_config 
>>>> instance.
>>>  To be precise: it overrides .max_register of a copy of a static 
>>> regmap_config instance (which has .max_register = 0).
>>>>  You can do the same,
>>>  We already do the same...
>>>>  calculating the .max_register from the memory resource you get 
>>>> from DT.
>>>  I can't see any code in pinctrl-ingenic.c getting the memory 
>>> resource that from DT. It calculates it from the ingenic_chip_info 
>>> tables inside the driver code but not DT.
>>>>  I'm sure you guys can figure it out.
>>>  Ah, we have to figure out. You are not sure yourself how to do it? 
>>> And it is *not* exactly like the pinctrl driver (already) does? 
>>> Please give precise directions in reviews and not vague research 
>>> homework. Our time is also valuable. Sorry if I review your 
>>> reviews...
>>>  Anyways I think you roughly intend (untested):
>>>  	struct resource *r;
>>>  	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>  	regmap_config.max_register = r.end - r.start;
>> 
>>  Replace the "devm_platform_ioremap_resource" with 
>> "devm_platform_get_and_ioremap_resource" to get a pointer to the 
>> resource.
>> 
>>  Then the .max_register should be (r.end - r.start - 4) I think.
>> 
>>  And lose the aggressivity. It's not going to get you anywhere, 
>> especially since I'm the one who decides whether or not I should 
>> merge your patches. You want your code upstream, that's great, but 
>> it's your responsability to get it to shape so that it's eventually 
>> accepted.
> 
> Well on the other side of the fence it is maintainers responsibility 
> to give clear and understandable rules and guidance about what will 
> be accepted and to enable us to bring it into the shape he/she has in 
> mind.
> 
> But a fundamental problem is: "good shape" is very subjective. What 
> would you recommend me to do, if I feel that my proposed code is in 
> better shape than what the maintainer thinks or recommends?
> 
>> 
>>>  But I wonder how that could work at all (despite adding code 
>>> execution time) with:
>> 
>>  Code execution time? ...
> 
> I reasoned about doing an additional platform_get_resource() call and 
> doing a subtraction. This is additional execution time. Maybe not 
> worth thinking about because it is in the probe function. And using 
> devm_platform_get_and_ioremap_resource() is of course potentially 
> better.
> 
>> 
>>>  e.g. jz4770.dtsi:
>>>  	lcd: lcd-controller@13050000 {
>>>  		compatible = "ingenic,jz4770-lcd";
>>>  		reg = <0x13050000 0x300>;
>>>  or jz4725b.dtsi:
>>>  	lcd: lcd-controller@13050000 {
>>>  		compatible = "ingenic,jz4725b-lcd";
>>>  		reg = <0x13050000 0x1000>;
>>>  So max_register becomes 0x300 or 0x1000 but not
>>>  #define JZ_REG_LCD_SIZE1	0x12c
>>>  	.max_reg = JZ_REG_LCD_SIZE1,
>>>  And therefore wastes a lot of regmap memory.
>> 
>>  "regmap memory"? ...
> 
> regmap allocates memory for its cache. Usually the total amount 
> specified in the reg property.

We are not using any register cache here.

>> 
>>>  Do you want this? DTS should not be reduced (DTS should be kept as 
>>> stable as possible), since the reg property describes address 
>>> mapping - not how many bytes are really used by registers or how 
>>> big a cache should be allocated (cache allocation size requirements 
>>> are not hardware description).
>> 
>>  The DTS should list the address and size of the register area. If 
>> your last register is at address 0x12c and there's nothing above, 
>> then the size in DTS should be 0x130.
> 
> If I look into some .dtsi it is sometimes that way but sometimes not. 
> There seems to be no consistent rule.
> 
> So does this mean you allow me to modify jz4740.dtsi, jz4770.dtsi and 
> jz4725b.dtsi as well (as mentioned above: this is beyond the scope of 
> my project)?

You could update them if you wanted to, but there is no need to do it 
here.

>> 
>>>  But here are good news:
>>>  I have a simpler and less invasive proposal. We keep the 
>>> devm_regmap_init_mmio code as is and just increase its 
>>> .max_register from JZ_REG_LCD_SIZE1 to JZ_REG_LCD_PCFG when 
>>> introducing the jz4780. This wastes a handful bytes for all 
>>> non-jz4780 chips but less than using the DTS memory region size. 
>>> And is less code (no entry in soc_info tables, no modifyable copy) 
>>> and faster code execution than all other proposals.
>>>  This is then just a single-line change when introducing the 
>>> jz4780. And no "preparation for adding jz4780" patch is needed at 
>>> all. No patch to split out for separate review.
>>>  Let's go this way to get it eventually finalized. Ok?
>> 
>>  No.
> 
> Look friend, if you explain your "no" and what is wrong with my 
> arguments, it helps to understand your decisions and learn something 
> from them. A plain "no" does not help anyone.

I answered just "no" because I felt like I explained already what I 
wanted to see in the previous email.

By using a huge number as the .max_register, we do *not* waste 
additional memory. Computing the value of the .max_register field does 
not add any overhead, either.

The .max_register is only used for boundary checking. To make sure that 
you're not calling regmap_write() with an invalid register. That's all 
there is to it.

> So to summarize: if you prefer something which I consider worse, it 
> is ok for me... In the end you are right - you are the maintainer, 
> not me. So you have to live with your proposals.
> 
> Therefore, I have prepared new variants so you can choose which one 
> is easier to maintain for you.
> 
> Note that they are both preparing for full jz4780-lcdc/hdmi support 
> but in very different ways:
> 
> Variant 1 already adds some jz4780 stuff while Variant 2 just 
> prepares for it.
> 
> Variant 2 is not tested (except to compile). So it needs some 
> Tested-by: from someone with access to hardware. IMHO it is more 
> invasive.
> 
> And don't forget: DTB could be in ROM or be provided by a separate 
> bootloader... So we should not change it too often (I had such 
> discussions some years ago with maintainers when I thought it is 
> easier to change DTS instead of code).
> 
> Variant 3 would be to not separate this. As proposed in [PATCH v5 
> 2/7].
> (Finally, a Variant 3b would be to combine the simple change from 
> Variant 1 with Variant 3).
> 
> So what is your choice?

Variant 4: the variant #2 without the changes to the DTSI files.

Cheers,
-Paul


> BR and thanks,
> Nikolaus
> 
> 
> #### VARIANT 0001 ####
> 
> From c7afa925f6b53bb6cafa080b7dd582788c8eb2eb Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: Mon, 8 Nov 2021 15:38:21 +0100
> Subject: [PATCH] RFC: drm/ingenic: Add register definitions for 
> JZ4780 lcdc
> 
> JZ4780 has additional registers compared to the other
> SoC of the JZ47xx series. So we add the constants for
> registers and bits we make use of (there are even more
> which can be added later).
> 
> And we increase the regmap max_register accordingly.
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm.h     | 39 
> +++++++++++++++++++++++
>  2 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index a5df1c8d34cde..1903e897d2299 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -122,7 +122,7 @@ static const struct regmap_config 
> ingenic_drm_regmap_config = {
>  	.val_bits = 32,
>  	.reg_stride = 4,
> 
> -	.max_register = JZ_REG_LCD_SIZE1,
> +	.max_register = JZ_REG_LCD_PCFG,
>  	.writeable_reg = ingenic_drm_writeable_reg,
>  };
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.h 
> b/drivers/gpu/drm/ingenic/ingenic-drm.h
> index 22654ac1dde1c..e7430c4af41f6 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm.h
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm.h
> @@ -44,8 +44,11 @@
>  #define JZ_REG_LCD_XYP1				0x124
>  #define JZ_REG_LCD_SIZE0			0x128
>  #define JZ_REG_LCD_SIZE1			0x12c
> +#define JZ_REG_LCD_PCFG				0x2c0
> 
>  #define JZ_LCD_CFG_SLCD				BIT(31)
> +#define JZ_LCD_CFG_DESCRIPTOR_8			BIT(28)
> +#define JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN	BIT(25)
>  #define JZ_LCD_CFG_PS_DISABLE			BIT(23)
>  #define JZ_LCD_CFG_CLS_DISABLE			BIT(22)
>  #define JZ_LCD_CFG_SPL_DISABLE			BIT(21)
> @@ -63,6 +66,7 @@
>  #define JZ_LCD_CFG_DE_ACTIVE_LOW		BIT(9)
>  #define JZ_LCD_CFG_VSYNC_ACTIVE_LOW		BIT(8)
>  #define JZ_LCD_CFG_18_BIT			BIT(7)
> +#define JZ_LCD_CFG_24_BIT			BIT(6)
>  #define JZ_LCD_CFG_PDW				(BIT(5) | BIT(4))
> 
>  #define JZ_LCD_CFG_MODE_GENERIC_16BIT		0
> @@ -132,6 +136,7 @@
>  #define JZ_LCD_CMD_SOF_IRQ			BIT(31)
>  #define JZ_LCD_CMD_EOF_IRQ			BIT(30)
>  #define JZ_LCD_CMD_ENABLE_PAL			BIT(28)
> +#define JZ_LCD_CMD_FRM_ENABLE			BIT(26)
> 
>  #define JZ_LCD_SYNC_MASK			0x3ff
> 
> @@ -153,6 +158,7 @@
>  #define JZ_LCD_RGBC_EVEN_BGR			(0x5 << 0)
> 
>  #define JZ_LCD_OSDC_OSDEN			BIT(0)
> +#define JZ_LCD_OSDC_ALPHAEN			BIT(2)
>  #define JZ_LCD_OSDC_F0EN			BIT(3)
>  #define JZ_LCD_OSDC_F1EN			BIT(4)
> 
> @@ -176,6 +182,39 @@
>  #define JZ_LCD_SIZE01_WIDTH_LSB			0
>  #define JZ_LCD_SIZE01_HEIGHT_LSB		16
> 
> +#define JZ_LCD_DESSIZE_ALPHA_OFFSET		24
> +#define JZ_LCD_DESSIZE_HEIGHT_MASK		GENMASK(23, 12)
> +#define JZ_LCD_DESSIZE_WIDTH_MASK		GENMASK(11, 0)
> +
> +/* TODO: 4,5 and 7 match the above BPP */
> +#define JZ_LCD_CPOS_BPP_15_16			(4 << 27)
> +#define JZ_LCD_CPOS_BPP_18_24			(5 << 27)
> +#define JZ_LCD_CPOS_BPP_30			(7 << 27)
> +#define JZ_LCD_CPOS_RGB555			BIT(30)
> +#define JZ_LCD_CPOS_PREMULTIPLY_LCD		BIT(26)
> +#define JZ_LCD_CPOS_COEFFICIENT_OFFSET		24
> +#define JZ_LCD_CPOS_COEFFICIENT_0		0
> +#define JZ_LCD_CPOS_COEFFICIENT_1		1
> +#define JZ_LCD_CPOS_COEFFICIENT_ALPHA1		2
> +#define JZ_LCD_CPOS_COEFFICIENT_1_ALPHA1	3
> +
> +#define JZ_LCD_RGBC_RGB_PADDING			BIT(15)
> +#define JZ_LCD_RGBC_RGB_PADDING_FIRST		BIT(14)
> +#define JZ_LCD_RGBC_422				BIT(8)
> +#define JZ_LCD_RGBC_RGB_FORMAT_ENABLE		BIT(7)
> +
> +#define JZ_LCD_PCFG_PRI_MODE			BIT(31)
> +#define JZ_LCD_PCFG_HP_BST_4			(0 << 28)
> +#define JZ_LCD_PCFG_HP_BST_8			(1 << 28)
> +#define JZ_LCD_PCFG_HP_BST_16			(2 << 28)
> +#define JZ_LCD_PCFG_HP_BST_32			(3 << 28)
> +#define JZ_LCD_PCFG_HP_BST_64			(4 << 28)
> +#define JZ_LCD_PCFG_HP_BST_16_CONT		(5 << 28)
> +#define JZ_LCD_PCFG_HP_BST_DISABLE		(7 << 28)
> +#define JZ_LCD_PCFG_THRESHOLD2_OFFSET		18
> +#define JZ_LCD_PCFG_THRESHOLD1_OFFSET		9
> +#define JZ_LCD_PCFG_THRESHOLD0_OFFSET		0
> +
>  struct device;
>  struct drm_plane;
>  struct drm_plane_state;
> --
> 2.33.0
> 
> 
> #### VARIANT 0002 ####
> 
> From c4b5cfa2789493f02da91e385719bc97aefb6c6c Mon Sep 17 00:00:00 2001
> From: "H. Nikolaus Schaller" <hns@goldelico.com>
> Date: Mon, 8 Nov 2021 14:40:58 +0100
> Subject: [PATCH] RFC: drm/ingenic: prepare ingenic drm for later 
> addition of
>  JZ4780
> 
> This changes the way the regmap is allocated to prepare for the
> later addition of the JZ4780 which has more registers and bits
> than the others.
> 
> To make this work we have to change the device tree records of
> all devices so that the reg property is limited to the physically
> available registers.
> 
> The magic value 0x130 in the device tree is JZ_REG_LCD_SIZE1 + 4.
> 
> Note that it is not tested since I have no access to the hardware.
> 
> Suggested-by: Paul Cercueil <paul@crapouillou.net>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  arch/mips/boot/dts/ingenic/jz4725b.dtsi   | 2 +-
>  arch/mips/boot/dts/ingenic/jz4740.dtsi    | 2 +-
>  arch/mips/boot/dts/ingenic/jz4770.dtsi    | 2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 ++++++---
>  4 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/mips/boot/dts/ingenic/jz4725b.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4725b.dtsi
> index a1f0b71c92237..c017b087c0e52 100644
> --- a/arch/mips/boot/dts/ingenic/jz4725b.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4725b.dtsi
> @@ -321,7 +321,7 @@ udc: usb@13040000 {
> 
>  	lcd: lcd-controller@13050000 {
>  		compatible = "ingenic,jz4725b-lcd";
> -		reg = <0x13050000 0x1000>;
> +		reg = <0x13050000 0x130>;
> 
>  		interrupt-parent = <&intc>;
>  		interrupts = <31>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> index c1afdfdaa8a38..ce3689e5015b5 100644
> --- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> @@ -323,7 +323,7 @@ udc: usb@13040000 {
> 
>  	lcd: lcd-controller@13050000 {
>  		compatible = "ingenic,jz4740-lcd";
> -		reg = <0x13050000 0x1000>;
> +		reg = <0x13050000 0x130>;
> 
>  		interrupt-parent = <&intc>;
>  		interrupts = <30>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> index 05c00b93088e9..0d1ee58d6c40b 100644
> --- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> @@ -399,7 +399,7 @@ gpu: gpu@13040000 {
> 
>  	lcd: lcd-controller@13050000 {
>  		compatible = "ingenic,jz4770-lcd";
> -		reg = <0x13050000 0x300>;
> +		reg = <0x13050000 0x130>;
> 
>  		interrupt-parent = <&intc>;
>  		interrupts = <31>;
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index a5df1c8d34cde..3c8e3c5a447bb 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -122,7 +122,6 @@ static const struct regmap_config 
> ingenic_drm_regmap_config = {
>  	.val_bits = 32,
>  	.reg_stride = 4,
> 
> -	.max_register = JZ_REG_LCD_SIZE1,
>  	.writeable_reg = ingenic_drm_writeable_reg,
>  };
> 
> @@ -858,6 +857,8 @@ static int ingenic_drm_bind(struct device *dev, 
> bool has_components)
>  	struct drm_encoder *encoder;
>  	struct drm_device *drm;
>  	void __iomem *base;
> +	struct resource *res;
> +	struct regmap_config regmap_config;
>  	long parent_rate;
>  	unsigned int i, clone_mask = 0;
>  	dma_addr_t dma_hwdesc_phys_f0, dma_hwdesc_phys_f1;
> @@ -904,14 +905,16 @@ static int ingenic_drm_bind(struct device *dev, 
> bool has_components)
>  	drm->mode_config.funcs = &ingenic_drm_mode_config_funcs;
>  	drm->mode_config.helper_private = &ingenic_drm_mode_config_helpers;
> 
> -	base = devm_platform_ioremap_resource(pdev, 0);
> +	base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
>  	if (IS_ERR(base)) {
>  		dev_err(dev, "Failed to get memory resource\n");
>  		return PTR_ERR(base);
>  	}
> 
> +	regmap_config = ingenic_drm_regmap_config;
> +	regmap_config.max_register = res->end - res->start - 4;
>  	priv->map = devm_regmap_init_mmio(dev, base,
> -					  &ingenic_drm_regmap_config);
> +					  &regmap_config);
>  	if (IS_ERR(priv->map)) {
>  		dev_err(dev, "Failed to create regmap\n");
>  		return PTR_ERR(priv->map);
> --
> 2.33.0
> 
> 



  reply	other threads:[~2021-11-08 16:31 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 12:29 [PATCH v5 0/7] MIPS: JZ4780 and CI20 HDMI H. Nikolaus Schaller
2021-10-05 12:29 ` [PATCH v5 1/7] drm/ingenic: Fix drm_init error path if IPU was registered H. Nikolaus Schaller
2021-10-05 12:29 ` [PATCH v5 2/7] drm/ingenic: Add support for JZ4780 and HDMI output H. Nikolaus Schaller
2021-10-05 20:22   ` Paul Cercueil
2021-11-07 13:41     ` H. Nikolaus Schaller
2021-11-07 19:01       ` Paul Cercueil
2021-11-07 19:01         ` Paul Cercueil
2021-11-07 20:25         ` H. Nikolaus Schaller
2021-11-07 20:25           ` H. Nikolaus Schaller
2021-11-08  9:37           ` Paul Cercueil
2021-11-08  9:37             ` Paul Cercueil
2021-11-08 10:52             ` H. Nikolaus Schaller
2021-11-08 10:52               ` H. Nikolaus Schaller
2021-11-08 12:20               ` Paul Cercueil
2021-11-08 12:20                 ` Paul Cercueil
2021-11-08 15:29                 ` H. Nikolaus Schaller
2021-11-08 15:29                   ` H. Nikolaus Schaller
2021-11-08 16:30                   ` Paul Cercueil [this message]
2021-11-08 16:30                     ` Paul Cercueil
2021-11-08 17:22                     ` H. Nikolaus Schaller
2021-11-08 17:22                       ` H. Nikolaus Schaller
2021-11-08 17:49                       ` Paul Cercueil
2021-11-08 17:49                         ` Paul Cercueil
2021-11-08 18:33                         ` H. Nikolaus Schaller
2021-11-08 18:33                           ` H. Nikolaus Schaller
2021-11-08 18:53                           ` Paul Cercueil
2021-11-08 18:53                             ` Paul Cercueil
2021-12-22 14:03             ` H. Nikolaus Schaller
2021-12-22 14:03               ` H. Nikolaus Schaller
2022-01-18 14:50               ` H. Nikolaus Schaller
2022-01-18 14:50                 ` H. Nikolaus Schaller
2022-01-18 16:58                 ` Paul Cercueil
2022-01-18 16:58                   ` Paul Cercueil
2022-01-18 17:14                   ` H. Nikolaus Schaller
2022-01-18 17:14                     ` H. Nikolaus Schaller
2022-01-18 22:59                   ` Paul Boddie
2022-01-19  6:40                     ` H. Nikolaus Schaller
2022-01-19  6:40                       ` H. Nikolaus Schaller
2022-01-19 20:04                       ` Paul Boddie
2022-01-19 20:04                         ` Paul Boddie
2021-10-05 12:29 ` [PATCH v5 3/7] dt-bindings: display: Add ingenic,jz4780-dw-hdmi DT Schema H. Nikolaus Schaller
2021-10-05 12:29   ` [PATCH v5 3/7] dt-bindings: display: Add ingenic, jz4780-dw-hdmi " H. Nikolaus Schaller
2021-10-05 20:43   ` [PATCH v5 3/7] dt-bindings: display: Add ingenic,jz4780-dw-hdmi " Paul Cercueil
2021-11-07 13:43     ` H. Nikolaus Schaller
2021-11-07 13:43       ` H. Nikolaus Schaller
2021-11-07 19:03       ` Paul Cercueil
2021-11-07 19:03         ` Paul Cercueil
2021-10-05 22:45   ` Rob Herring
2021-10-05 22:45     ` [PATCH v5 3/7] dt-bindings: display: Add ingenic, jz4780-dw-hdmi " Rob Herring
2021-10-05 12:29 ` [PATCH v5 4/7] drm/ingenic: Add dw-hdmi driver for jz4780 H. Nikolaus Schaller
2021-10-05 12:29 ` [PATCH v5 5/7] MIPS: DTS: jz4780: Account for Synopsys HDMI driver and LCD controllers H. Nikolaus Schaller
2021-10-05 20:50   ` Paul Cercueil
2021-10-05 21:44     ` Paul Boddie
2021-10-05 21:52       ` Paul Cercueil
2021-11-07 13:45         ` H. Nikolaus Schaller
2021-11-07 13:45           ` H. Nikolaus Schaller
2021-11-07 19:05           ` Paul Cercueil
2021-11-07 19:05             ` Paul Cercueil
2021-11-09 20:19             ` H. Nikolaus Schaller
2021-11-09 20:19               ` H. Nikolaus Schaller
2021-11-09 20:36               ` Paul Cercueil
2021-11-09 20:36                 ` Paul Cercueil
2021-11-09 20:42                 ` H. Nikolaus Schaller
2021-11-09 20:42                   ` H. Nikolaus Schaller
2021-11-09 21:14                   ` [Letux-kernel] " H. Nikolaus Schaller
2021-11-09 21:14                     ` H. Nikolaus Schaller
2021-10-05 12:29 ` [PATCH v5 6/7] MIPS: DTS: CI20: Add DT nodes for HDMI setup H. Nikolaus Schaller
2021-10-05 12:29 ` [PATCH v5 7/7] MIPS: defconfig: CI20: configure for DRM_DW_HDMI_JZ4780 H. Nikolaus Schaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BVH92R.0VU3IKPQTLX9@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@linux.ie \
    --cc=broonie@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiederm@xmission.com \
    --cc=geert+renesas@glider.be \
    --cc=harry.wentland@amd.com \
    --cc=hns@goldelico.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=keescook@chromium.org \
    --cc=letux-kernel@openphoenux.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime@cerno.tech \
    --cc=miquel.raynal@bootlin.com \
    --cc=narmstrong@baylibre.com \
    --cc=paul@boddie.org.uk \
    --cc=robert.foss@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.