2016-08-30 19:06 GMT+02:00 Rob Herring [off-list ref]:

On Wed, Aug 24, 2016 at 09:54:47PM +0200, Mirza Krak wrote:

quoted

2016-08-24 17:56 GMT+02:00 Jon Hunter [off-list ref]:
+

quoted

quoted

+Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
+controllers with a simple-bus node since they are all connected to the same
+chip-select (CS4), in this example external address decoding is provided:
+
+gmi at 70090000 {
+     compatible = "nvidia,tegra20-gmi";
+     reg = <0x70009000 0x1000>;
+     #address-cells = <1>;
+     #size-cells = <1>;
+     clocks = <&tegra_car TEGRA20_CLK_NOR>;
+     clock-names = "gmi";
+     resets = <&tegra_car 42>;
+     reset-names = "gmi";
+     ranges = <4 0x48000000 0x7ffffff>;
+
+     status = "disabled";
+
+     bus at 4 {
+             compatible = "simple-bus";
+             reg = <4>;
+             #address-cells = <1>;
+             #size-cells = <1>;
+             ranges = <0 4 0x40100>;

Does this work? I tried to add an example like this and I got ...

Warning (reg_format): "reg" property in /gmi at 70009000/bus at 4 has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)

Shoot, to get rid of the warning it should be

reg = <4 0 >;

But it works either way.

The CS node should have #address-cells=2 with the first being CS# and
the second being the offset (often 0).

quoted

quoted

I am wondering if we should just following the arm,pl172 example and
have ...

        cs4 {
                compatible = "simple-bus";
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;

Empty ranges is typically wrong and due to laziness...

This should have the CS# in it.

quoted

quoted

                nvidia,snor-cs = <4>;
                nvidia,snor-mux-mode;
                nvidia,snor-adv-inv;

                can at 0 {
                        reg = <0 0x100>;

This can be 1 cell with just the offset.

quoted

quoted

                        ...
                };

                ...
        };

That means to go back to V1 really (almost :)). Which I do not mind.
Will give it a test run.

But I am a little hesitant if will be any better/cleaner. In your example above:

can at 0 {
         reg = <0 0x100>;
         ...
};

Would this really translate correctly? In the pl172 example they have
multiple ranges and address with "flash at 0,0" which a range defined in
parent node. "can at 0" does not have valid match in parent node in our
example. So I probably need add some more logic for it to properly
translate.

pl172 has several things I don't like, so don't follow it. Mainly those
are custom CS property and 3 levels of nodes. I'm fine with 3 levels if
there is more than one device, but otherwise 2 levels with timing
properties in the child device node.

quoted

I have an idea which is following:

gmi at 70090000 {
         status = "okay";
         #address-cells = <2>;
         #size-cells = <1>;
         ranges = <4 0 0x48000000 0x00040000>;

         cs4 {

cs at 4,0

quoted

                 compatible = "simple-bus";
                 #address-cells = <2>;

1 cell here.

quoted

                 #size-cells = <1>;
                 ranges;

Fill this in to drop the 2nd cell on child addresses and just have the
offset.

quoted

                 nvidia,snor-cs = <4>;

NAK, no custom CS properties.

quoted

                 nvidia,snor-mux-mode;
                 nvidia,snor-adv-inv;

                 can at 0 {
                         compatible = "nxp,sja1000";
                         reg = <4 0 0x100>;
                         ...
                 };


                 can at 40000 {
                         compatible = "nxp,sja1000";
                         reg = <4 0x40000 0x100>;
                         ...
                 };
         };
};

Thank you for your review Rob.

Taking your comments in to account I end up with this:

gmi at 70090000 {
        compatible = "nvidia,tegra20-gmi";
        reg = <0x70009000 0x1000>;
        #address-cells = <2>;
        #size-cells = <1>;
        clocks = <&tegra_car TEGRA20_CLK_NOR>;
        clock-names = "gmi";
        resets = <&tegra_car 42>;
        reset-names = "gmi";
        ranges = <4 0 0xd0000000 0xfffffff>;

        status = "okay";

        bus at 4,0 {
                compatible = "simple-bus";
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0 4 0 0x40000>;

                nvidia,snor-mux-mode;
                nvidia,snor-adv-inv;

                can at 0 {
                        reg = <0 0x100>;
                        ...
                };

                can at 40000 {
                        reg = <0x40000 0x100>;
                        ...
                };
        };
};

Have I understood you correct?

Also wanted to verify the example case where you only have on device
connected to one CS#, from what I see in other implementations it
seems OK to put the CS# in the reg property in that case. Is this
correct?

Example with one SJA1000 CAN controller connected to the GMI bus
on CS4:

gmi at 70090000 {
        compatible = "nvidia,tegra20-gmi";
        reg = <0x70009000 0x1000>;
        #address-cells = <2>;
        #size-cells = <1>;
        clocks = <&tegra_car TEGRA20_CLK_NOR>;
        clock-names = "gmi";
        resets = <&tegra_car 42>;
        reset-names = "gmi";
        ranges = <4 0 0xd0000000 0xfffffff>;

        status = "okay";

        can at 4,0 {
                reg = <4 0 0x100>;
                nvidia,snor-mux-mode;
                nvidia,snor-adv-inv;
                ...
        };
};

Jon, to be able to handle both cases in the driver we would first
attempt to decode the CS# from the ranges property, and fallback to
reg property if no ranges are defined. Does that sound reasonable?

Best Regards
Mirza