On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
> On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
>> On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
>>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
>>>> From: R Sricharan <r.sricha...@ti.com>
> [...]
>>>> + mcspi4: spi@480ba000 {
>>>> + compatible = "ti,omap4-mcspi";
>>>> + reg = <0x480ba000 0x200>;
>>>> + interrupts = <0 48 0x4>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + ti,hwmods = "mcspi4";
>>>> + ti,spi-num-cs = <1>;
>>>> + dmas = <&sdma 70>, <&sdma 71>;
>>>> + dma-names = "tx0", "rx0";
>>>> + };
>>>> + };
>>>> +};
>>>>
>>> ref: [1], we discussed that we should now be able to introduce all
>>> instances of h/w blocks into the dra7.dts. Further, considering [2]
>>
>> hmm, thats a long discussion on crossbar driver that [1] points to. Do you
>> want to summarize what you mean by 'introduce all instances of h/w blocks'
>
> I recommend reading the last few emails on the thread about how we could do
> this with pinctrl. unfortunately, this patch is not informative enough to
> indicate that not all instances of the potential IP blocks are listed here.
>
>>
>>> would you not want to follow "status = disabled" for all modules by default
>>> and enable required modules in board file, so that we dont have to respin
>>> this yet again?
>>
>> Well, I was just following the convention of whats already followed on
>> existing OMAPs. See [3] for some views on these.
>
> DRA7 case, I would not think it makes sense due to the number of product
> variants being done, not all will use the same set. Further, rationale for
> DRA7 and my suggestion for Grant's option (1) is mainly because the product
> variants will require more dtsis rather than board files using the product
> variants use just the necessary modules from a common dtsi. Makes support of
> variants like OMAP57xx etc trivial and constrainted to board file usage,
> rather than spinning off new dtsis.
Makes sense with the different product variants for DRA7, AM335x already does
it this way, but the rest of OMAP3/4/5 are doing it the other way.
I think its just too confusing to follow different conventions for different
SoCs. We should stick to just one, either this way or that.
>
>>
>>>
>>>
>>> [1] http://marc.info/?t=137416599400001&r=1&w=2
>>> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=2
>> [3]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
