On Fri, 17 May 2013 19:00:29 +0100
Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote:
> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> > case. And, yes, I better like a hardware cursor: it asks for less
> > computation, and I get it immediately at graphic starting time!
>
> Interesting. Where did you find the documentation for the transparency?
> The FS lists HWC32_TRANS_CNTL but omits to specify where that gets used.
Simply in the ¶ 11.3.2.1. The HWC32_TRANS_CNTL SRAM is loaded like the
HWC 2bpp, but with 00 transparent / 01 RGB.
> > The first step is "DT or not DT"? For me, the DT is more flexible
> > (one or two LCDs, smart panel definition, display controller or not..)
> > and permits easy inclusion of out of tree drivers as the private VPU
> > and GPU ones.
>
> I'd argue supporting both. :)
Not easy!
If you have not yet looked at our driver, here is how it starts:
- in '/', the DT contains
video {
compatible = "marvell,dove-video";
};
which loads the dove-drm module.
- its module init function registers the lcd driver, the dcon driver
and the drm driver.
- the lcd probe function tries to get all the resources for the
specific LCD from the DT, including the clocks and the HDMI
transmitter.
If some resource is lacking, it deferes.
When all resources are there, it says "present" to the drm driver (see
below).
The resources of a LCD are declared in the DT by something like:
&lcd0 { /* the iomem and irq are declared
* in the Dove global DT */
status = "okay"; /* this LCD is present and usable */
clocks = <&core_clk 3>, <0>, <&lcdclk>, <&si5351 0>;
/* 3 usable clocks */
marvell,port-type = <11>; /* HDMIA */
marvell,external-encoder = <&tda998x>; /* HDMI slave encoder */
};
- the dcon probe function gets its resources and says "present" to the
drm driver.
Its DT declaration is just:
&dcon { status = "okay"; }; /* iomem and irq in the Dove DT */
- the drm probe function scans all the DT, counting its usuable devices,
(i.e. the LCDs and the dcon), and decrement the "present" variable
accordingly.
- when the "present" variable is null, the active devices have all
their resources, and, then, the drm driver is activated by a call to
drm_platform_init().
I don't see clearly how to do that with a static initialization, and I
don't want to write a "cubox-setup.c". A kernel CONFIG_CUBOX ?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
