Hi Rob,
Am Freitag, den 02.10.2015, 09:24 -0500 schrieb Rob Herring:
[...]
> >> > I'll try to bind to this node and have the driver find sibling nodes
> >> > using their compatible strings.
> >>
> >> That doesn't seem like a good choice since there are other functions
> >> in the block. I was thinking one of the display related blocks like
> >> whatever block provides the main crtc functions.
> >
> > Why exactly isn't this a good choice? Since all display function blocks
> > are spread throughout the MMSYS address space, using the mmsys driver to
> > create the DRM/component master platform driver that collects its
> > subdevices sounded logical.
>
> Given it is a syscon, I was assuming there are other unrelated
> functions. If everything in it is display related, then it would be a
> fine choice.
Oh, ok. Next to the display blocks there's also a similar graph of MDP
("multimedia data path") blocks that can perform memory-to-memory
scaling and rotation that use the same multiplexers and mutex, and the
HDMI encoder controls the FIFO between its parallel output and the HDMI
PHY via (separate) registers in the MMSYS_CONFIG region. Still, I think
these are sufficiently display related.
> > Another candidate would be the mutex node, which can synchronize the
> > configuration updates to the function blocks in the MMSYS region to
> > frame borders.
> >
> > The hardware blocks that most closely correspond to crtc functionality
> > are the two OVL blocks, as Daniel points out. They provide DMA and plane
> > composition. But they are equivalent, and there is no single central
> > node, same as with the two IPUs on i.MX6.
>
> Just curious, are 2 IPUs represented as 1 or 2 struct drm_device?
One. There's bus multiplexer fabric between the IPU outputs and the
LVDS/HDMI encoders, so it's all connected.
regards
Philipp
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
