Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1470541 > unrolled thread

Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller

Started byMirza Krak <mirza.krak@gmail.com>
First post2016-08-26 07:00 +0200
Last post2016-08-29 09:40 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Mirza Krak <mirza.krak@gmail.com> - 2016-08-26 07:00 +0200
    Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Jon Hunter <jonathanh@nvidia.com> - 2016-08-26 09:30 +0200
      Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller Mirza Krak <mirza.krak@gmail.com> - 2016-08-29 09:40 +0200

#1470541 — Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller

FromMirza Krak <mirza.krak@gmail.com>
Date2016-08-26 07:00 +0200
SubjectRe: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
Message-ID<sahpf-2mA-3@gated-at.bofh.it>
2016-08-24 21:54 GMT+02:00 Mirza Krak <mirza.krak@gmail.com>:
> 2016-08-24 17:56 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
> +
>>> +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@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@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@70009000/bus@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.
>
>>
>> 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;
>>
>>                 nvidia,snor-cs = <4>;
>>                 nvidia,snor-mux-mode;
>>                 nvidia,snor-adv-inv;
>>
>>                 can@0 {
>>                         reg = <0 0x100>;
>>                         ...
>>                 };
>>
>>                 ...
>>         };
>>
>
> 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@0 {
>          reg = <0 0x100>;
>          ...
> };
>
> Would this really translate correctly? In the pl172 example they have
> multiple ranges and address with "flash@0,0" which a range defined in
> parent node. "can@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.
>
> I have an idea which is following:
>
> gmi@70090000 {
>          status = "okay";
>          #address-cells = <2>;
>          #size-cells = <1>;
>          ranges = <4 0 0x48000000 0x00040000>;
>
>          cs4 {
>                  compatible = "simple-bus";
>                  #address-cells = <2>;
>                  #size-cells = <1>;
>                  ranges;
>
>                  nvidia,snor-cs = <4>;
>                  nvidia,snor-mux-mode;
>                  nvidia,snor-adv-inv;
>
>                  can@0 {
>                          compatible = "nxp,sja1000";
>                          reg = <4 0 0x100>;
>                          ...
>                  };
>
>
>                  can@40000 {
>                          compatible = "nxp,sja1000";
>                          reg = <4 0x40000 0x100>;
>                          ...
>                  };
>          };
> };
>
> Do not know if above will work at all (not able to test at current
> location), anyway I will play around with it some more and get back to
> you.

Gave above a test run and it works like a charm. Are we happy with that?

Best Regards
Mirza

[toc] | [next] | [standalone]


#1470572

FromJon Hunter <jonathanh@nvidia.com>
Date2016-08-26 09:30 +0200
Message-ID<sajKp-3YE-7@gated-at.bofh.it>
In reply to#1470541
On 26/08/16 05:53, Mirza Krak wrote:

...

>> I have an idea which is following:
>>
>> gmi@70090000 {
>>          status = "okay";
>>          #address-cells = <2>;
>>          #size-cells = <1>;
>>          ranges = <4 0 0x48000000 0x00040000>;
>>
>>          cs4 {
>>                  compatible = "simple-bus";
>>                  #address-cells = <2>;
>>                  #size-cells = <1>;
>>                  ranges;
>>
>>                  nvidia,snor-cs = <4>;
>>                  nvidia,snor-mux-mode;
>>                  nvidia,snor-adv-inv;
>>
>>                  can@0 {
>>                          compatible = "nxp,sja1000";
>>                          reg = <4 0 0x100>;
>>                          ...
>>                  };
>>
>>
>>                  can@40000 {
>>                          compatible = "nxp,sja1000";
>>                          reg = <4 0x40000 0x100>;
>>                          ...
>>                  };
>>          };
>> };
>>
>> Do not know if above will work at all (not able to test at current
>> location), anyway I will play around with it some more and get back to
>> you.
> 
> Gave above a test run and it works like a charm. Are we happy with that?

Does it not work with #address-cells = <1>? Seems odd to have the cs in
the reg for the device.

Cheers
Jon

-- 
nvpublic

[toc] | [prev] | [next] | [standalone]


#1471596

FromMirza Krak <mirza.krak@gmail.com>
Date2016-08-29 09:40 +0200
Message-ID<sbpkJ-4p3-11@gated-at.bofh.it>
In reply to#1470572
2016-08-26 9:25 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
>
> On 26/08/16 05:53, Mirza Krak wrote:
>
> ...
>
>>> I have an idea which is following:
>>>
>>> gmi@70090000 {
>>>          status = "okay";
>>>          #address-cells = <2>;
>>>          #size-cells = <1>;
>>>          ranges = <4 0 0x48000000 0x00040000>;
>>>
>>>          cs4 {
>>>                  compatible = "simple-bus";
>>>                  #address-cells = <2>;
>>>                  #size-cells = <1>;
>>>                  ranges;
>>>
>>>                  nvidia,snor-cs = <4>;
>>>                  nvidia,snor-mux-mode;
>>>                  nvidia,snor-adv-inv;
>>>
>>>                  can@0 {
>>>                          compatible = "nxp,sja1000";
>>>                          reg = <4 0 0x100>;
>>>                          ...
>>>                  };
>>>
>>>
>>>                  can@40000 {
>>>                          compatible = "nxp,sja1000";
>>>                          reg = <4 0x40000 0x100>;
>>>                          ...
>>>                  };
>>>          };
>>> };
>>>
>>> Do not know if above will work at all (not able to test at current
>>> location), anyway I will play around with it some more and get back to
>>> you.
>>
>> Gave above a test run and it works like a charm. Are we happy with that?
>
> Does it not work with #address-cells = <1>? Seems odd to have the cs in
> the reg for the device.
>

No it does not work with #address-cells = <1> with the current
structure that we have.

With #address-cells = <2>, we can state that this device is on
chip-select 4 and on this specific offset of chip-select 4 (that is
the second address cell). I do not see how we can specify this with
only one address cell.

And is it really that odd? Looking at other drivers they all use the
same metod, even the arm,pl172 that you where referring to as a base
for our implementation.

Best Regards
Mirza

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web