[PATCH v11 11/24] drm/rockchip: dw_hdmi: Use auto-generated tables
Robin Murphy
robin.murphy at arm.com
Tue May 3 05:17:08 PDT 2022
On 2022-05-03 12:02, Heiko Stübner wrote:
> Am Freitag, 22. April 2022, 09:28:28 CEST schrieb Sascha Hauer:
>> From: Douglas Anderson <dianders at chromium.org>
>>
>> The previous tables for mpll_cfg and curr_ctrl were created using the
>> 20-pages of example settings provided by the PHY vendor. Those
>> example settings weren't particularly dense, so there were places
>> where we were guessing what the settings would be for 10-bit and
>> 12-bit (not that we use those anyway). It was also always a lot of
>> extra work every time we wanted to add a new clock rate since we had
>> to cross-reference several tables.
>>
>> In <https://crrev.com/c/285855> I've gone through the work to figure
>> out how to generate this table automatically. Let's now use the
>> automatically generated table and then we'll never need to look at it
>> again.
>>
>> We only support 8-bit mode right now and only support a small number
>> of clock rates and I've verified that the only 8-bit rate that was
>> affected was 148.5. That mode appears to have been wrong in the old
>> table.
>>
>> Signed-off-by: Douglas Anderson <dianders at chromium.org>
>> Signed-off-by: Yakir Yang <ykk at rock-chips.com>
>> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
>
> This breaks hdmi on my rk3328-rock64 which then ends up in a
> [CRTC:37:crtc-0] vblank wait timed out
>
> warning-loop.
Oh yeah, that... IIRC from back when I was looking at it, it's because
the inno-hdmi phy does its own rate validation at a point when it's
already far too late to actually reject the mode. It manages to work at
the moment because its set of supported rates mostly line up with those
for the Synopsys phy which dw-hdmi-rockchip still insists on validating
against even when a vendor phy is present.
> Some part of the patch11-14 range also creates sparking horizontal
> lines on my rk3288-pinky.
I figure that's the PLL jitter issue that's come up before. Similarly,
when I last tried hacking in a 154MHz rate for my monitor's 1920x1200
mode, it was rock solid on RK3399, but intolerably glitchy on RK3288.
Robin.
> I haven't the time to dig overly deep into that, so left out the
> hdmi-rate patches (11-14) for now.
>
>
> Heiko
>
>
>> ---
>>
>> Notes:
>> Changes since v5:
>> - Add missing Signed-off-by me
>>
>> Changes since v3:
>> - new patch
>>
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++++++++++---------
>> 1 file changed, 69 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> index fe4f9556239ac..cb43e7b47157d 100644
>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> @@ -91,80 +91,88 @@ static struct rockchip_hdmi *to_rockchip_hdmi(struct drm_encoder *encoder)
>>
>> static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
>> {
>> - 27000000, {
>> - { 0x00b3, 0x0000},
>> - { 0x2153, 0x0000},
>> - { 0x40f3, 0x0000}
>> + 30666000, {
>> + { 0x00b3, 0x0000 },
>> + { 0x2153, 0x0000 },
>> + { 0x40f3, 0x0000 },
>> },
>> - }, {
>> - 36000000, {
>> - { 0x00b3, 0x0000},
>> - { 0x2153, 0x0000},
>> - { 0x40f3, 0x0000}
>> + }, {
>> + 36800000, {
>> + { 0x00b3, 0x0000 },
>> + { 0x2153, 0x0000 },
>> + { 0x40a2, 0x0001 },
>> },
>> - }, {
>> - 40000000, {
>> - { 0x00b3, 0x0000},
>> - { 0x2153, 0x0000},
>> - { 0x40f3, 0x0000}
>> + }, {
>> + 46000000, {
>> + { 0x00b3, 0x0000 },
>> + { 0x2142, 0x0001 },
>> + { 0x40a2, 0x0001 },
>> },
>> - }, {
>> - 54000000, {
>> - { 0x0072, 0x0001},
>> - { 0x2142, 0x0001},
>> - { 0x40a2, 0x0001},
>> + }, {
>> + 61333000, {
>> + { 0x0072, 0x0001 },
>> + { 0x2142, 0x0001 },
>> + { 0x40a2, 0x0001 },
>> },
>> - }, {
>> - 65000000, {
>> - { 0x0072, 0x0001},
>> - { 0x2142, 0x0001},
>> - { 0x40a2, 0x0001},
>> + }, {
>> + 73600000, {
>> + { 0x0072, 0x0001 },
>> + { 0x2142, 0x0001 },
>> + { 0x4061, 0x0002 },
>> },
>> - }, {
>> - 66000000, {
>> - { 0x013e, 0x0003},
>> - { 0x217e, 0x0002},
>> - { 0x4061, 0x0002}
>> + }, {
>> + 92000000, {
>> + { 0x0072, 0x0001 },
>> + { 0x2145, 0x0002 },
>> + { 0x4061, 0x0002 },
>> },
>> - }, {
>> - 74250000, {
>> - { 0x0072, 0x0001},
>> - { 0x2145, 0x0002},
>> - { 0x4061, 0x0002}
>> + }, {
>> + 122666000, {
>> + { 0x0051, 0x0002 },
>> + { 0x2145, 0x0002 },
>> + { 0x4061, 0x0002 },
>> },
>> - }, {
>> - 83500000, {
>> - { 0x0072, 0x0001},
>> + }, {
>> + 147200000, {
>> + { 0x0051, 0x0002 },
>> + { 0x2145, 0x0002 },
>> + { 0x4064, 0x0003 },
>> },
>> - }, {
>> - 108000000, {
>> - { 0x0051, 0x0002},
>> - { 0x2145, 0x0002},
>> - { 0x4061, 0x0002}
>> + }, {
>> + 184000000, {
>> + { 0x0051, 0x0002 },
>> + { 0x214c, 0x0003 },
>> + { 0x4064, 0x0003 },
>> },
>> - }, {
>> - 106500000, {
>> - { 0x0051, 0x0002},
>> - { 0x2145, 0x0002},
>> - { 0x4061, 0x0002}
>> + }, {
>> + 226666000, {
>> + { 0x0040, 0x0003 },
>> + { 0x214c, 0x0003 },
>> + { 0x4064, 0x0003 },
>> },
>> - }, {
>> - 146250000, {
>> - { 0x0051, 0x0002},
>> - { 0x2145, 0x0002},
>> - { 0x4061, 0x0002}
>> + }, {
>> + 272000000, {
>> + { 0x0040, 0x0003 },
>> + { 0x214c, 0x0003 },
>> + { 0x5a64, 0x0003 },
>> },
>> - }, {
>> - 148500000, {
>> - { 0x0051, 0x0003},
>> - { 0x214c, 0x0003},
>> - { 0x4064, 0x0003}
>> + }, {
>> + 340000000, {
>> + { 0x0040, 0x0003 },
>> + { 0x3b4c, 0x0003 },
>> + { 0x5a64, 0x0003 },
>> },
>> - }, {
>> + }, {
>> + 600000000, {
>> + { 0x1a40, 0x0003 },
>> + { 0x3b4c, 0x0003 },
>> + { 0x5a64, 0x0003 },
>> + },
>> + }, {
>> ~0UL, {
>> - { 0x00a0, 0x000a },
>> - { 0x2001, 0x000f },
>> - { 0x4002, 0x000f },
>> + { 0x0000, 0x0000 },
>> + { 0x0000, 0x0000 },
>> + { 0x0000, 0x0000 },
>> },
>> }
>> };
>>
>
>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
More information about the Linux-rockchip
mailing list