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

["Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>]

Hi Michał,

[snip]

> >  > 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.
> 

Here is the reply by hardware designer after an internal discussion
with us:

Due to internal regulations, we are unable to disclose the actual
hardware specifications.

The current approach has been validated against the hardware
limitations:
1. pixel clock rate < 594000 KHz
2. pixel clock rate / VBP  < 8250

While it is possible that exceeding these limitations might still work,
it could potentially go beyond the guarantees provided by the DRAM
controller and Hardware Real-Time (HRT) capabilities, leading to a risk
of encountering unstable underflow issues.

I think this scaling patch (without hardware guarantees) is more
suitable for the specific product lines applied to Chrome, not
upstream.

Regards,
Jason-JH Lin

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