On 25.04.2012 12:45, Thierry Reding wrote:
> +/ {
> + ...
> +
> + /* host1x */
> + host1x: host1x@50000000 {
> + compatible = "nvidia,tegra20-host1x";
> + reg = <0x50000000 0x00024000>;
> + interrupts = <0 64 0x04 /* cop syncpt */
> + 0 65 0x04 /* mpcore syncpt */
> + 0 66 0x04 /* cop general */
> + 0 67 0x04>; /* mpcore general */
> + };
> +
> + /* video-encoding/decoding */
> + mpe@54040000 {
> + reg = <0x54040000 0x00040000>;
> + interrupts = <0 68 0x04>;
> + };
> +
(...)
Hi Thierry,
I have still lots of questions regarding how device trees work. I'm now
just trying to match the device tree structure with hardware - let me
know if that goes wrong.
There's a hierarchy in the hardware, which should be represented in the
device trees. All of the hardware are client modules for host1x - with
the exception of host1x obviously. CPU has two methods for accessing the
hardware: clients' register aperture and host1x channels. Both of these
operate via host1x hardware.
We should define host1x bus in the device tree, and move all nodes
except host1x under that bus. This will help us in the long run, as we
will have multiple drivers (drm, v4l2) each accessing hardware under
host1x. We will need to model the bus and the bus_type will need to take
over responsibilities of managing the common resources.
When we are clocking hardware, whenever we want to access display's
register aperture, host1x needs to be clocked.
> + /* graphics host */
> + graphics@54000000 {
> + compatible = "nvidia,tegra20-graphics";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + display-controllers = <&disp1 &disp2>;
> + carveout = <0x0e000000 0x02000000>;
> + host1x = <&host1x>;
> + gart = <&gart>;
> +
> + connectors {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + connector@0 {
> + reg = <0>;
> + edid = /incbin/("machine.edid");
> + output = <&lvds>;
> + };
> +
> + connector@1 {
> + reg = <1>;
> + output = <&hdmi>;
> + ddc = <&i2c2>;
> +
> + hpd-gpio = <&gpio 111 0>; /* PN7 */
> + };
> + };
> + };
> +};
I'm not sure what this node means. The register range from 54000000
onwards is actually the one that you just described in the nodes of the
individual client modules. Why is it represented here again?
Terje
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
