linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Robert Chiras <robert.chiras@nxp.com>
Cc: Marek Vasut <marex@denx.de>, Stefan Agner <stefan@agner.ch>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Mark Rutland <mark.rutland@arm.com>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	NXP Linux Team <linux-imx@nxp.com>,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 05/10] dt-bindings: display: Add max-res property for mxsfb
Date: Mon, 22 Jul 2019 11:48:53 -0600	[thread overview]
Message-ID: <20190722174853.GA31795@bogus> (raw)
In-Reply-To: <1561555938-21595-6-git-send-email-robert.chiras@nxp.com>

On Wed, Jun 26, 2019 at 04:32:13PM +0300, Robert Chiras wrote:
> Add new optional property 'max-res', to limit the maximum supported
> resolution by the MXSFB_DRM driver.

Bindings are for h/w description, not driver config.

> 
> Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> ---
>  Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
> index 472e1ea..55e22ed 100644
> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
> @@ -17,6 +17,12 @@ Required properties:
>  Required sub-nodes:
>    - port: The connection to an encoder chip.
>  
> +Optional properties:
> +- max-res:	an array with a maximum of two integers, representing the
> +		maximum supported resolution, in the form of
> +		<maxX>, <maxY>; if one of the item is <0>, the default
> +		driver-defined maximum resolution for that axis is used

I suppose what you are after is bandwidth limits? IIRC, there's already 
some bindings expressing such limits. Also, wouldn't you need to account 
for bpp and using the 2nd plane (IIRC that there is one).

Rob

  reply	other threads:[~2019-07-22 17:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26 13:32 [PATCH 00/10] Improvements and fixes for mxsfb DRM driver Robert Chiras
2019-06-26 13:32 ` [PATCH 01/10] drm/mxsfb: Update mxsfb to support a bridge Robert Chiras
2019-07-21 10:26   ` Guido Günther
2019-06-26 13:32 ` [PATCH 02/10] drm/mxsfb: Update mxsfb with additional pixel formats Robert Chiras
2019-07-21 10:27   ` Guido Günther
2019-06-26 13:32 ` [PATCH 03/10] drm/mxsfb: Fix the vblank events Robert Chiras
2019-06-26 13:32 ` [PATCH 04/10] drm/mxsfb: Signal mode changed when bpp changed Robert Chiras
2019-06-26 13:32 ` [PATCH 05/10] dt-bindings: display: Add max-res property for mxsfb Robert Chiras
2019-07-22 17:48   ` Rob Herring [this message]
2019-08-14  8:05     ` [EXT] " Robert Chiras
2019-06-26 13:32 ` [PATCH 06/10] drm/mxsfb: Add max-res property for MXSFB Robert Chiras
2019-06-26 13:32 ` [PATCH 07/10] drm/mxsfb: Update mxsfb to support LCD reset Robert Chiras
2019-06-26 13:32 ` [PATCH 08/10] drm/mxsfb: Improve the axi clock usage Robert Chiras
2019-06-26 13:32 ` [PATCH 09/10] drm/mxsfb: Clear OUTSTANDING_REQS bits Robert Chiras
2019-06-26 13:32 ` [PATCH 10/10] drm/mxsfb: Add support for horizontal stride Robert Chiras
2019-07-11 15:04 ` [PATCH 00/10] Improvements and fixes for mxsfb DRM driver Guido Günther
2019-07-12  8:15   ` [EXT] " Robert Chiras
2019-07-16 14:54     ` Guido Günther
2019-07-20 21:09       ` Guido Günther
2019-08-13 10:23 ` Guido Günther
2019-08-13 10:36   ` [EXT] " Robert Chiras

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=20190722174853.GA31795@bogus \
    --to=robh@kernel.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=robert.chiras@nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=stefan@agner.ch \
    /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).