From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric@anholt.net (Eric Anholt) Date: Mon, 29 Jan 2018 16:00:40 -0800 Subject: [PATCH] drm/pl111: Use max memory bandwidth for resolution In-Reply-To: References: <20180123132220.29886-1-linus.walleij@linaro.org> <87inbqppm4.fsf@anholt.net> Message-ID: <87tvv4w6zb.fsf@anholt.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Linus Walleij writes: > On Thu, Jan 25, 2018 at 4:46 AM, Eric Anholt wrote: > >>> + pl111_choose_max_resolution(dev, priv->memory_bw, >>> + &mode_config->max_width, >>> + &mode_config->max_height, &bpp); >>> + dev_info(dev->dev, "cap resolution at %u x %u, %u BPP\n", >>> + mode_config->max_width, mode_config->max_height, bpp); >> >> I think this is the wrong place in the pipeline to be doing this, but I >> don't have a complete solution so I'm not necessarily saying no. > > So currently the driver does this: > > mode_config->max_width = 1024; > mode_config->max_height = 768; > > And that is because it cannot really handle anything. I guess ideally > the DRM driver should set these to -1 or something so that any widths > and heights negotiated will work. The PPL field only gets you up to 1024 width. Looks like LPP lets you get up to 1024 height, though, even if the top level of the PL111 docs say 1024x768 is the max. >> Things I think we should do for bandwidth limits: >> >> A new pl111_mode_valid() rejects modes with width*height*2 > bandwidth >> (if we can't scan it out with our smallest format, don't advertise it). >> >> pl111_display_check() rejects modes with width*height*bpp > bandwidth >> (if we can't scan out this particular configuration, let them know we >> can't set the mode). >> >> Ideally given those two things, fbdev and X11 would notice that the >> preferred mode fails at 24bpp and fall back to 16bpp. I don't think >> either of those does so today, though. >> >> Interested in tackling any of these? > > I tried the pl111_display_check() version. It just made the driver > fail to initialize anything, at least when using the dumb VGA > bridge. > > There are .mode_valid() callbacks on the bridges we use > (panel and dumb VGA) but neither uses it at the moment, hm. > I could just assign my own .mode_valid() callback to the bridge, > but it seems a bit fragile. But it's worth a hack, I'll try it. > > I sent a sent of lesser controversial patches in the meantime, > and rebased this on top of those so we can deal with the > memory BW issue separately. The memory-bandwidth field is in the pl111 binding, so I do think we should handle it there. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/pl111: Use max memory bandwidth for resolution Date: Mon, 29 Jan 2018 16:00:40 -0800 Message-ID: <87tvv4w6zb.fsf@anholt.net> References: <20180123132220.29886-1-linus.walleij@linaro.org> <87inbqppm4.fsf@anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4214348967861286339==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Linus Walleij Cc: Linux ARM , Daniel Vetter , Sean Paul , Jani Nikula , "open list:DRM PANEL DRIVERS" List-Id: dri-devel@lists.freedesktop.org --===============4214348967861286339== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Linus Walleij writes: > On Thu, Jan 25, 2018 at 4:46 AM, Eric Anholt wrote: > >>> + pl111_choose_max_resolution(dev, priv->memory_bw, >>> + &mode_config->max_width, >>> + &mode_config->max_height, &bpp); >>> + dev_info(dev->dev, "cap resolution at %u x %u, %u BPP\n", >>> + mode_config->max_width, mode_config->max_height, bpp); >> >> I think this is the wrong place in the pipeline to be doing this, but I >> don't have a complete solution so I'm not necessarily saying no. > > So currently the driver does this: > > mode_config->max_width = 1024; > mode_config->max_height = 768; > > And that is because it cannot really handle anything. I guess ideally > the DRM driver should set these to -1 or something so that any widths > and heights negotiated will work. The PPL field only gets you up to 1024 width. Looks like LPP lets you get up to 1024 height, though, even if the top level of the PL111 docs say 1024x768 is the max. >> Things I think we should do for bandwidth limits: >> >> A new pl111_mode_valid() rejects modes with width*height*2 > bandwidth >> (if we can't scan it out with our smallest format, don't advertise it). >> >> pl111_display_check() rejects modes with width*height*bpp > bandwidth >> (if we can't scan out this particular configuration, let them know we >> can't set the mode). >> >> Ideally given those two things, fbdev and X11 would notice that the >> preferred mode fails at 24bpp and fall back to 16bpp. I don't think >> either of those does so today, though. >> >> Interested in tackling any of these? > > I tried the pl111_display_check() version. It just made the driver > fail to initialize anything, at least when using the dumb VGA > bridge. > > There are .mode_valid() callbacks on the bridges we use > (panel and dumb VGA) but neither uses it at the moment, hm. > I could just assign my own .mode_valid() callback to the bridge, > but it seems a bit fragile. But it's worth a hack, I'll try it. > > I sent a sent of lesser controversial patches in the meantime, > and rebased this on top of those so we can deal with the > memory BW issue separately. The memory-bandwidth field is in the pl111 binding, so I do think we should handle it there. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlpvtagACgkQtdYpNtH8 nuitLBAAl0ZTM7StzTGy5oPeSmmUV2YX+FOumDApml6rCO78OsU6vR7dAwXDALlO mjtLVd6+83XgijYOx6zLz3X0lP3hZdFwBOYgpAuBM6fl9aXSkfHeF67s+4FYxugF 52n76fhU59xWZGU1jkT2uDoXCpV0WwKmgmeUTFjDGzZV/MO3UC4uHW/RCHTGNzj1 gs8kA9uTUq8A7Lwk/k2WOuZIWcIX06zVLIBJ+2fOwO4SBnyfuJNSQ3PsJOQNCIts XYZ7vXE72orfV/+r5uVEPHsnbdgaJ5RYh452YdbeLS+jAlRQMuyzV2veiVgilLI/ 0NGh1S7sfGw/szTFOSc6XCreUGZMswf+zJPooRM31zw0qtVkSNcQYsddGuhyAMPX kYmDFGyOGkCe/gW0Ya4DUE42Yv5ai1E1BJQMZXDheFhgYf3StCql3W50b9zusElu lvtYGZaCrLh5Jzec2ENfqYS5tB/fqJuQxYxwiz/3aOO/5ajfD10Fx8k4PVmXbvJx i0rJULWJDMF3gc17CtztcotYDLKo02+v1Ntfa2FrlfmFO0sKDz9Uv5Jawf0ZlXyP OQtIIGLM0FRh9rJrH1X6xcK+wpbKyerqwlMT+OBzwINgDBI3sSPOH3fJcrViWtBF +2uj+Qr6dtiEblLtQ8mIBYtZg/KopULNtjxyY2crpugSQoNgiMQ= =WXib -----END PGP SIGNATURE----- --=-=-=-- --===============4214348967861286339== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============4214348967861286339==--