devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pawel Moll <pawel.moll@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	"rob.herring@calxeda.com" <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"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/2] video: ARM CLCD: Add DT support
Date: Wed, 11 Sep 2013 17:02:22 +0100	[thread overview]
Message-ID: <1378915342.4082.140.camel@hornet> (raw)
In-Reply-To: <20130910194324.GE12758@n2100.arm.linux.org.uk>

On Tue, 2013-09-10 at 20:43 +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 10, 2013 at 11:25:25AM +0100, Pawel Moll wrote:
> > +#ifdef CONFIG_OF
> > +static int clcdfb_of_get_tft_panel(struct device_node *node,
> > +		struct clcd_panel *panel)
> > +{
> > +	int err;
> > +	u32 rgb[3];
> > +
> > +	err = of_property_read_u32_array(node, "panel-tft-interface", rgb, 3);
> > +	if (err)
> > +		return err;
> > +
> > +	/* Bypass pixel clock divider, data output on the falling edge */
> > +	panel->tim2 = TIM2_BCD | TIM2_IPC;
> > +
> > +	/* TFT display, vert. comp. interrupt at the start of the back porch */
> > +	panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> > +
> > +	if (rgb[0] >= 4 && rgb[1] >= 4 && rgb[2] >= 4)
> > +		panel->caps |= CLCD_CAP_444;
> > +	if (rgb[0] >= 5 && rgb[1] >= 5 && rgb[2] >= 5)
> > +		panel->caps |= CLCD_CAP_5551;
> > +	if (rgb[0] >= 5 && rgb[1] >= 6 && rgb[2] >= 5)
> > +		panel->caps |= CLCD_CAP_565;
> > +	if (rgb[0] >= 8 && rgb[1] >= 8 && rgb[2] >= 8)
> > +		panel->caps |= CLCD_CAP_888;
> 
> This definitely isn't right.  Why does a panel which has 8 bits of RGB
> get to indicate that it supports everything below it?
> 
> This is not how this hardware works.  Look at table A-7 in the TRM.
> If you wire the CLCD controller directly to a panel which is 8-bit RGB
> only, it can't support any of the other formats.
> 
> The CLCD controller itself can only support on the hardware 8-bits of
> RGB or 5 bits of RGB plus an intensity bit, so that's two formats.

I must admit I didn't checked the PL110 CLD multiplexing scheme, naively
expecting it to be the same as PL111. My bad, thanks for pointing this
out.

The code above works for PL111 - the signals are laid so with full 888
wiring and 444 mode the bottom bits are reserved (see table A.10). In
reality they're zeros, so the colour space is narrowed.

Seems that the code will have to behave differently for PL110 and PL111
here.

> However, things are complicated by ARMs addition of an external mux
> on the CLCD output, which gives us the other format possibilities
> by munging the signals to give appropriate formats in the framebuffer
> memory.  In other words, in RGB444 mode, the mux ends up taking
> red from CLD[4:1], green from CLD[9:7,5], blue from CLD[14:13,11:10].

It's the Versatile AB/PB hacked CLCD, PL110/111 hybrid, right? It
doesn't really fall into the "arm,pl110" and "arm,pl111" compatible
value, so would need to be something like "arm,versatile,clcdc" and
require custom code. I don't think I want to solve this problem right
now.

> This is one of the dangers of directly converting what's in the kernel
> to DT properties without getting the hardware documentation and fully
> understanding that first - remember, DT properties are supposed to be
> based on the hardware, not the Linux implementation.

I don't think I've directly converted what's in the kernel to DT
properties. There is no "caps" property in the binding. There is only
information how is the cell wired up to a panel, and this information is
valid for both PL110 and PL111 as it is. My fault I've believed when was
told that "the two are basically the same." and should have compared the
TRMs in details.

Will fix the code.

Paweł



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2013-09-11 16:02 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 ` [PATCH v2 1/2] video: ARM CLCD: Add DT support Stephen Warren
2013-09-11 11:45   ` 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 [this message]

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=1378915342.4082.140.camel@hornet \
    --to=pawel.moll@arm.com \
    --cc=Mark.Rutland@arm.com \
    --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=plagnioj@jcrosoft.com \
    --cc=rob.herring@calxeda.com \
    --cc=swarren@wwwdotorg.org \
    --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).