From: Stephen Warren <swarren@wwwdotorg.org>
To: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
Russell King <linux@arm.linux.org.uk>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Rob Herring <rob.herring@calxeda.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
Date: Tue, 10 Sep 2013 11:32:41 -0600 [thread overview]
Message-ID: <522F57B9.5000001@wwwdotorg.org> (raw)
In-Reply-To: <1378808726-32535-1-git-send-email-pawel.moll@arm.com>
On 09/10/2013 04:25 AM, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them.
> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> +Optional properties:
> +
> +- video-ram: phandle to a node describing specialized video memory
> + (that is *not* described in the top level "memory" node)
> + that must be used as a framebuffer, eg. due to restrictions
> + of the system interconnect; the node must contain a
> + standard reg property describing the address and the size
> + of the memory area
Should this use the "CMA bindings" that are being proposed at the moment?
Even if not, I'm not quite clear on what the referenced node is supposed
to contain; is just a reg property enough, so you'd see the following at
a completely arbitrary location in the DT:
framebuffer-mem {
reg = <0x80000000 0x00100000>;
};
I'm not sure what the benefit of making this a standalone node is; why
not just put the base/size directly into the video-ram property in the
CLCD node?
> +- max-framebuffer-size: maximum size in bytes of the framebuffer the
> + system can handle, eg. in terms of available
> + memory bandwidth
Size doesn't imply bandwidth, due to the potential for varying bpp,
frame-rates, margin/porch sizes, etc. If this is a bandwidth limit,
shouldn't we instead represent that value directly, perhaps along with
some multiplier to convert theoretical bandwidth to practical bandwidth
(to account for memory protocol and controller overheads)?
...
> +- panel-type: (required) must be "tft" or "stn", defines panel type
...
> +- panel-stn-4bit: (for monochrome "stn" panel) if present means
> + that the monochrome display is connected
> + via 4 bit-wide interface
I just wanted to confirm that those are a complete/direct representation
of all the HW options the module supports?
> +- display-timings: standard display timings sub-node, see
> + Documentation/devicetree/bindings/video/display-timing.txt
Should that be in a "Required sub-nodes" section (I assume required not
optional) rather than "Optional Properties"?
next prev parent reply other threads:[~2013-09-10 17:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 10:25 [PATCH v2 1/2] video: ARM CLCD: Add DT support Pawel Moll
2013-09-10 10:25 ` [PATCH v2 2/2] ARM: vexpress: Add CLCD Device Tree properties Pawel Moll
2013-09-10 17:32 ` Stephen Warren [this message]
2013-09-11 11:45 ` [PATCH v2 1/2] video: ARM CLCD: Add DT support Pawel Moll
2013-09-11 17:39 ` Stephen Warren
2013-09-12 13:03 ` Pawel Moll
2013-09-12 14:55 ` Stephen Warren
2013-09-12 15:26 ` Pawel Moll
2013-09-12 15:27 ` Pawel Moll
2013-09-12 15:56 ` Russell King - ARM Linux
2013-09-12 15:41 ` Russell King - ARM Linux
2013-09-10 19:43 ` Russell King - ARM Linux
2013-09-11 16:02 ` Pawel Moll
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=522F57B9.5000001@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=arnd.bergmann@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=plagnioj@jcrosoft.com \
--cc=rob.herring@calxeda.com \
--cc=sylvester.nawrocki@gmail.com \
--cc=tomi.valkeinen@ti.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).