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

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

[Michał Kopeć]

(Re-sending because Shawn's @google email is inactive)

Hi Shawn,

I'm a new owner of the Chromebook Ciri (MT8188) and have run into an 
issue which I believe is related to this patch.

I'm attempting to use a 3440x1440 144Hz monitor over DisplayPort, but 
the available resolutions are limited to 2560x1440@120Hz. I found this 
patch, then I confirmed with the monitor's EDID that i am indeed 
reaching data rates above 8250 (though minimally) in higher resolution 
modes.

I wanted to ask about this comment:

 > The proposed formula is only one way to estimate whether our SoC
 > supports the mode setting. The basic idea behind it is just to check
 > if the data rate requirement is too high (directly proportional to
 > pixel clock, inversely proportional to vbp). Please adjust the
 > function if it doesn't fit your situation in the future.

- Can you confirm if the reference number 8250 is the hard limit of the 
hardware?
- Could you suggest other formulae that could work for my use case? I'd 
be happy to implement and test on my end but as I don't have access to 
MTK documentation, I don't know the actual limits of the hardware and 
how to deal with them

Regards,
Michał Kopeć

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

[CK Hu (胡俊光)]

+ Jason

On Wed, 2024-11-27 at 15:28 +0100, Michał Kopeć wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> (Re-sending because Shawn's @google email is inactive)
> 
> Hi Shawn,
> 
> I'm a new owner of the Chromebook Ciri (MT8188) and have run into an
> issue which I believe is related to this patch.
> 
> I'm attempting to use a 3440x1440 144Hz monitor over DisplayPort, but
> the available resolutions are limited to 2560x1440@120Hz. I found this
> patch, then I confirmed with the monitor's EDID that i am indeed
> reaching data rates above 8250 (though minimally) in higher resolution
> modes.
> 
> I wanted to ask about this comment:
> 
>  > The proposed formula is only one way to estimate whether our SoC
>  > supports the mode setting. The basic idea behind it is just to check
>  > if the data rate requirement is too high (directly proportional to
>  > pixel clock, inversely proportional to vbp). Please adjust the
>  > function if it doesn't fit your situation in the future.
> 
> - Can you confirm if the reference number 8250 is the hard limit of the
> hardware?
> - Could you suggest other formulae that could work for my use case? I'd
> be happy to implement and test on my end but as I don't have access to
> MTK documentation, I don't know the actual limits of the hardware and
> how to deal with them
> 
> Regards,
> Michał Kopeć
> 
> 
> 
> 

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

[Shawn Sung (宋孝謙)]

Hi Michał,

On Wed, 2024-11-27 at 15:28 +0100, Michał Kopeć wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> (Re-sending because Shawn's @google email is inactive)
> 
> Hi Shawn,
> 
> I'm a new owner of the Chromebook Ciri (MT8188) and have run into an
> issue which I believe is related to this patch.
> 
> I'm attempting to use a 3440x1440 144Hz monitor over DisplayPort, but
> the available resolutions are limited to 2560x1440@120Hz. I found
> this
> patch, then I confirmed with the monitor's EDID that i am indeed
> reaching data rates above 8250 (though minimally) in higher
> resolution
> modes.

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?

> 
> I wanted to ask about this comment:
> 
>  > The proposed formula is only one way to estimate whether our SoC
>  > supports the mode setting. The basic idea behind it is just to
> check
>  > if the data rate requirement is too high (directly proportional to
>  > pixel clock, inversely proportional to vbp). Please adjust the
>  > function if it doesn't fit your situation in the future.
> 
> - Can you confirm if the reference number 8250 is the hard limit of
> the
> hardware?

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. 

> - Could you suggest other formulae that could work for my use case?
> I'd
> be happy to implement and test on my end but as I don't have access
> to
> MTK documentation, I don't know the actual limits of the hardware and
> how to deal with them
> 

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.

> Regards,
> Michał Kopeć
> 
> 
Regards,
Shawn

>