Re: [PATCH 3/3] phy: rockchip: Add Samsung HDMI/DP Combo PHY driver

From: Alex Bee <knaerzche@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>,
	Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Cc: Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Johan Jonker <jbx6244@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Andy Yan <andy.yan@rock-chips.com>,
	Algea Cao <algea.cao@rock-chips.com>,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCH 3/3] phy: rockchip: Add Samsung HDMI/DP Combo PHY driver
Date: Sat, 20 Jan 2024 17:00:35 +0100	[thread overview]
Message-ID: <e3713300-492c-43eb-aaf9-0add95ef3b19@gmail.com> (raw)
In-Reply-To: <eodlujrytdm6gugcbaz3efnjvgg7sbvsqedwllmleh4ar6e7cr@3ejicokdjzcd>

Am 19.01.24 um 23:47 schrieb Sebastian Reichel:
> Hi Cristian,
> 
> On Fri, Jan 19, 2024 at 09:38:03PM +0200, Cristian Ciocaltea wrote:
>> Add driver for the Rockchip HDMI/eDP TX Combo PHY found on RK3588 SoC.
>>
>> The PHY is based on a Samsung IP block and supports HDMI 2.1 TMDS, FRL
>> and eDP links.  The maximum data rate is 12Gbps (HDMI 2.1 FRL), while
>> the minimum is 250Mbps (HDMI 2.1 TMDS).
>>
>> Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
>> Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
> 
> The driver has multiple sequences looking like this (this is just one
> example of many):
> 
>> +	hdptx_write(hdptx, CMN_REG0087, 0x04);
>> +	hdptx_write(hdptx, CMN_REG0089, 0x00);
>> +	hdptx_write(hdptx, CMN_REG008A, 0x55);
>> +	hdptx_write(hdptx, CMN_REG008B, 0x25);
>> +	hdptx_write(hdptx, CMN_REG008C, 0x2c);
>> +	hdptx_write(hdptx, CMN_REG008D, 0x22);
>> +	hdptx_write(hdptx, CMN_REG008E, 0x14);
>> +	hdptx_write(hdptx, CMN_REG008F, 0x20);
>> +	hdptx_write(hdptx, CMN_REG0090, 0x00);
>> +	hdptx_write(hdptx, CMN_REG0091, 0x00);
>> +	hdptx_write(hdptx, CMN_REG0092, 0x00);
>> +	hdptx_write(hdptx, CMN_REG0093, 0x00);
>> +	hdptx_write(hdptx, CMN_REG0095, 0x00);
>> +	hdptx_write(hdptx, CMN_REG0097, 0x02);
>> +	hdptx_write(hdptx, CMN_REG0099, 0x04);
>> +	hdptx_write(hdptx, CMN_REG009A, 0x11);
>> +	hdptx_write(hdptx, CMN_REG009B, 0x00);
> 
> Instead of the repetitive calls to regmap_write, it's better to do
> it like this:
> 
> static const struct reg_sequence some_init_seq[] = {
> 	REG_SEQ0(CMN_REG0087, 0x04),
> 	REG_SEQ0(CMN_REG0089, 0x00),
> 	REG_SEQ0(CMN_REG008A, 0x55),
> 	REG_SEQ0(CMN_REG008B, 0x25),
> 	REG_SEQ0(CMN_REG008C, 0x2c),
> 	REG_SEQ0(CMN_REG008D, 0x22),
> 	REG_SEQ0(CMN_REG008E, 0x14),
> 	REG_SEQ0(CMN_REG008F, 0x20),
> 	REG_SEQ0(CMN_REG0090, 0x00),
> 	REG_SEQ0(CMN_REG0091, 0x00),
> 	REG_SEQ0(CMN_REG0092, 0x00),
> 	REG_SEQ0(CMN_REG0093, 0x00),
> 	REG_SEQ0(CMN_REG0095, 0x00),
> 	REG_SEQ0(CMN_REG0097, 0x02),
> 	REG_SEQ0(CMN_REG0099, 0x04),
> 	REG_SEQ0(CMN_REG009A, 0x11),
> 	REG_SEQ0(CMN_REG009B, 0x00),
> };
> 
> regmap_multi_reg_write(hdptx->regmap, some_init_seq, ARRAY_SIZE(some_init_seq));
+1 on that.

It' quite hard currently to figure out what the driver is _actually_ doing
as it has all this hardcoded sequences mixed up with driver logic. Better
move them at the top as arrays and use regmap_multi_reg_write as Sebastian
suggests.

Alex
> 
>> +static const struct of_device_id rockchip_hdptx_phy_of_match[] = {
>> +	{ .compatible = "rockchip,rk3588-hdptx-phy", },
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(of, rockchip_hdptx_phy_of_match);
>> +
>> +static struct platform_driver rockchip_hdptx_phy_driver = {
>> +	.probe  = rockchip_hdptx_phy_probe,
>> +	.driver = {
>> +		.name = "rockchip-hdptx-phy",
>> +		.pm = &rockchip_hdptx_phy_pm_ops,
>> +		.of_match_table = of_match_ptr(rockchip_hdptx_phy_of_match),
> 
> Remove of_match_ptr(). It's a nop, since the driver depends on OF.
> 
> Greetings,
> 
> -- Sebastian
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip