On Tuesday 30 July 2013 06:29 PM, Nishanth Menon wrote:
> On 07/30/2013 07:56 AM, Rajendra Nayak wrote:
>> 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.
>>
>
> I think bucketing DRA7(with multitude of SoC variants) with OMAP
> family(usually with <5 variants) will be a wrong approach. we should choose
> the approach appropriate for the SoC. hence, OMAPx having all default enabled
> makes sense (as the delta is usually trivial), but on DRA7, the variants are
> larger :(
>
> just my 2 cents.
I can respin with the changes, but before I do so, Benoit do you agree with the
rationale for these and fine with the approach?
>
>>>
>>>>
>>>>>
>>>>>
>>>>> [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
