linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wen He <wen.he_1@nxp.com>
To: Robin Murphy <robin.murphy@arm.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"liviu.dudau@arm.com" <liviu.dudau@arm.com>
Cc: Leo Li <leoyang.li@nxp.com>
Subject: RE: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required pixel clock rate
Date: Fri, 17 May 2019 10:37:01 +0000	[thread overview]
Message-ID: <AM0PR04MB4865EC817EB0B441D4042D38E20B0@AM0PR04MB4865.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <edd9dc6c-aba2-3881-3121-efee388b47cf@arm.com>



> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: 2019年5月16日 18:45
> To: Wen He <wen.he_1@nxp.com>; dri-devel@lists.freedesktop.org;
> linux-kernel@vger.kernel.org; liviu.dudau@arm.com
> Cc: Leo Li <leoyang.li@nxp.com>
> Subject: Re: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for required
> pixel clock rate
> 
> 
> On 16/05/2019 10:42, Wen He wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy@arm.com]
> >> Sent: 2019年5月16日 1:14
> >> To: Wen He <wen.he_1@nxp.com>; dri-devel@lists.freedesktop.org;
> >> linux-kernel@vger.kernel.org; liviu.dudau@arm.com
> >> Cc: Leo Li <leoyang.li@nxp.com>
> >> Subject: [EXT] Re: [v1] drm/arm/mali-dp: Disable checking for
> >> required pixel clock rate
> >>
> >> Caution: EXT Email
> >>
> >> On 15/05/2019 03:42, Wen He wrote:
> >>> Disable checking for required pixel clock rate if ARCH_LAYERSCPAE is
> >>> enable.
> >>>
> >>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
> >>> Signed-off-by: Wen He <wen.he_1@nxp.com>
> >>> ---
> >>> change in description:
> >>>        - This check that only supported one pixel clock required clock
> rate
> >>>        compare with dts node value. but we have supports 4 pixel clock
> >>>        for ls1028a board.
> >>>    drivers/gpu/drm/arm/malidp_crtc.c | 2 ++
> >>>    1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> >>> b/drivers/gpu/drm/arm/malidp_crtc.c
> >>> index 56aad288666e..bb79223d9981 100644
> >>> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> >>> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> >>> @@ -36,11 +36,13 @@ static enum drm_mode_status
> >>> malidp_crtc_mode_valid(struct drm_crtc *crtc,
> >>>
> >>>        if (req_rate) {
> >>>                rate = clk_round_rate(hwdev->pxlclk, req_rate);
> >>> +#ifndef CONFIG_ARCH_LAYERSCAPE
> >>
> >> What about multiplatform builds? The kernel config doesn't tell you
> >> what hardware you're actually running on.
> >>
> >
> > Hi Robin,
> >
> > Thanks for your reply.
> >
> > In fact, Only one platform integrates this IP when
> CONFIG_ARCH_LAYERSCAPE is set.
> > Although this are not good ways, but I think it won't be a problem under
> multiplatform builds.
> 
> My point is that ARCH_LAYERSCAPE is going to be enabled in distribution
> kernels along with everything else, so you're effectively removing this check for
> all other vendors' Mali-DP implementations as well, which is probably not OK.
> 
> Furthermore, if LS1028A really only supports 4 specific modes as the BSP
> documentation I found claims, then surely you'd want a *more* specific check
> here, rather than no check at all?

Hi Robin,

Thanks for your comments.

Yes, As you said, now LS1028A only supports 4 modes, and we use three clocks to support
all four modes. In fact, this was really the point.

However, we can only enable one mode to meet the check statement in this place.

For example, If user has a 1080p monitor, we must be set the pixel fixed-clock to 148.5MHz. 
if user want to choice 4k monitor, we also to be change the pixel fixed-clock to 594MHz in
DT node. In reality, We have no way of knowing what kind of monitor the user wants. Right?

Moreover, user cannot to change screen resolution in this case, I don't think this place is
reasonable. we need to supporting Ubuntu , Wayland and other embedded GU, so we need
to switch the resolutions.

Maybe it's that most android device used, and android system always only need one
resolution.

Best Regards,
Wen

> 
> Robin.

  reply	other threads:[~2019-05-17 10:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15  2:42 [v1] drm/arm/mali-dp: Disable checking for required pixel clock rate Wen He
2019-05-15 15:45 ` liviu.dudau
2019-05-16  8:10   ` [EXT] " Wen He
2019-05-16  8:23     ` liviu.dudau
2019-05-17 10:38       ` Wen He
2019-05-17 16:17         ` liviu.dudau
2019-05-15 17:14 ` Robin Murphy
2019-05-16  9:42   ` [EXT] " Wen He
2019-05-16 10:45     ` Robin Murphy
2019-05-17 10:37       ` Wen He [this message]
2019-05-17 16:13         ` liviu.dudau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM0PR04MB4865EC817EB0B441D4042D38E20B0@AM0PR04MB4865.eurprd04.prod.outlook.com \
    --to=wen.he_1@nxp.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=robin.murphy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).