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

Groups > linux.kernel > #1493936 > unrolled thread

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

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 Jon Hunter <jonathanh@nvidia.com> - 2016-09-30 10:10 +0200

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

Rob,

On 19/09/16 08:21, Mirza Krak wrote:
> 2016-09-06 12:32 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
>>
>> On 31/08/16 12:22, Mirza Krak wrote:
>>> 2016-08-30 19:06 GMT+02:00 Rob Herring <robh@kernel.org>:
>>
>> ...
>>
>>>>>                  nvidia,snor-cs = <4>;
>>>>
>>>> NAK, no custom CS properties.
>>
>> Ok, so ...
>>
>>> gmi@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@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@0 {
>>>                         reg = <0 0x100>;
>>>                         ...
>>>                 };
>>>
>>>                 can@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@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@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?
>>
>> Given the above examples that may be supported, is there a
>> better/simpler way to extract the CS# than what Mirza is proposing? For
>> example, from the node-name unit-address?
>>
> 
> Hi.
> 
> I have been on vacation and now I am back and wanted to finalize these
> patch series.
> 
> So pinging this thread to see I we can agree on a solution.
> 
> Rob any comments to my proposal and Jon`s comment?

Can you comment on the above?

Cheers
Jon

-- 
nvpublic

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web