Re: [PATCH v2 1/1] drm/mediatek: Filter modes according to hardware capability

["Shawn Sung (宋孝謙)" <Shawn.Sung@mediatek.com>]

Hi Michał,

On Fri, 2024-11-29 at 17:13 +0100, Michał Kopeć wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Hi Shawn, thanks for replying!

Thank you for bringing this issue to our attention.

Since every email from outside of the company is first moved to an
isolation folder, I replied your mail before moving it out and noticed
that there is a "[SPAM]" tag in the subject line.
I apologize for what happened and have fixed it this time.

> 
>  > As the reference number 8250 = 594000 / 72:
>  > 594000 is KHz of the clock rate in mode setting
>  > 72 is lines during VBP (Vertical Back Porch)
>  > Can you share your reference number or the EDID in 3440x1440@144
> with
>  > us?
> 
> Sure, here's the mode defined in the EDID:
> 
> DTD: 3440x1440 143.922761 Hz 0:0 217.323 kHz 799.750000 MHz (aspect
> undefined, no 3D stereo, preferred)
>            Hfront 48 Hsync 32 Hback 160 Hpol P
>            Vfront 3 Vsync 10 Vback 57 Vpol N
> 
> 799750/57 is 14030 so definitely much higher than supported
> according to the code.
> 
> There's also other modes:
> 
> DTD: 3440x1440 119.999642 Hz 0:0 182.999 kHz 670.510000 MHz (aspect
> undefined, no 3D stereo)
>            Hfront 144 Hsync 32 Hback 48 Hpol P
>            Vfront 3 Vsync 4 Vback 78 Vpol N
> 
> DTD 2: 3440x1440 99.981604 Hz 43:18 150.972 kHz 543.500000 MHz (800
> mm
> x 335 mm)
>              Hfront 48 Hsync 32 Hback 80 Hpol P
>              Vfront 3 Vsync 4 Vback 63 Vpol N
> 
> 670510/78 = 8596
> 543500/63 = 8626
> 
> So the 120Hz and 100Hz modes look like they might almost work :) The
> manufacturer neglected to add a 60Hz mode which I suspect might have
> worked without issue.

Yes, these two numbers seems to work as they are just less than 5%
above the spec.

> 
>  > The reference number 8250 is established based on our hardware
>  > specifications. Numbers higher than that may function, but could
> be
>  > unstable. For example, the monitor may seem to work properly at
> first,
>  > but you could encounter black screens or glitching from time to
> time.
> 
> Understood. I was just wondering if it might be dependent on other
> factors than Vbp and pixel clock.
> 
>  > May I confirm if you are going to implement the patch just for
> local
>  > testing or for upstream? As 8250 is calculated based on the
>  > specifications and was verified through a series of procedures.
> Any
>  > changes to it may require thorough verifications before being
> accepted.
> 
> I was going to initially try to implement something for personal use
> but
> I wanted to eventually try to upstream it. However, from what I
> understand,
> it might not be easy or possible.
> 
> If I develop a patch that works reliably at least for me, would you
> be
> open to me adding a kernel module parameter to allow unverified data
> rates, with clear description that it may cause unstable behavior?

As I also have a high refresh rate monitor, I can completely understand
how you feel. Could you please change 8250 to `8250 * 1.05` and see if
it works in your situation?

Since the official configuration usually prefer a more stable setting,
we have initiated an internal discussion about this request.

> 
>  > Regards,
>  > Shawn
> 
> Regards,
> Michał
> 

Regards,
Shawn