On 22/07/16 20:07, Mirza Krak wrote:

2016-07-22 11:32 GMT+02:00 Jon Hunter [off-list ref]:

quoted

On 21/07/16 21:10, Mirza Krak wrote:

quoted

2016-07-21 11:56 GMT+02:00 Jon Hunter [off-list ref]:

quoted

I wonder if it is worth mentioning that the chip-select specified in the
"nvidia,config" prop should match that in the "ranges" prop unless you
have some external decoding logic to provide an external chip-select.
Which raises a question, what does the chip-select in the ranges
actually represent? I am not sure if there is a common practice here for
device tree when boards have external logic to provide additional
chip-selects. I am sure this is quite common.

I do not understand why CS pin setting in nvidia,config need to match
the "ranges" prop? Other then maybe cosmetics.

Yes it would be cosmetic. That said, I even wonder if CS needs to be
exposed at all given that they all map to the same CPU address space.
Couldn't your binding for the CAN devices be as follows?

nor@70009000 {
        ...

        can@48000000 {
                ...
        };

        can@48040000 {
                ...
        };
};

This has also crossed my mind, maybe just get rid of the "ranges" prop
and do like you have above. But then again I do not know what is
preferred so I went with "ranges" prop initially.

quoted

Problem is if you did have devices on different chip-selects then how
would these be handled? They could not point to the same physical
address. I am not sure if there is a way to do that in DT?

Having trouble following your though here. We do not have "different"
chip-selects?

I meant that the device has multiple chip-selects and so I was not sure
the best way to handle this for the GMI.

Jon

-- 
nvpublic