Thanks for your suggestions.
On Tue, Feb 25, 2014 at 10:22 AM, Rob Herring <robherring2@xxxxxxxxx> wrote:
> On Fri, Feb 21, 2014 at 11:36 AM, Joel Fernandes <joelf@xxxxxx> wrote:
>> On 02/21/2014 06:15 AM, Mark Rutland wrote:
>>>> Also, while at it get rid of the assumption in the code that "CC" is at reg
>>>> index 0 in the DT and xbar is at offset 1. Instead use reg-names to get the
>>>> memory resource in concern keeping things much cleaner and simpler. This also
>>>> makes it possible to have multiple channel controllers.
>>>
>>> While this is nice I think we have to have a fallback to the existing
>>> behaviour if there's no reg-names property present, unless we know for
>>> certain no-one is possibly using an existing DTB.
>>
>> Yes, its true it break existing DTBs but currently only 2 TI SoCs use EDMA this
>> way, the vast majority of EDMA users are yet to follow where we can do it right.
>> Further, the old bindings are really limiting specially the 2 CC case and if
>> additionally memory maps are used in the future. So keeping the old binding is
>> limiting in this regard.
>>
>> Here is what the platform_data used to look like when used by mach-davinci:
>>
>> static struct resource da850_edma_resources[] = {
>> {
>> .name = "edma_cc0",
>> .start = DA8XX_TPCC_BASE,
>> .end = DA8XX_TPCC_BASE + SZ_32K - 1,
>> .flags = IORESOURCE_MEM,
>> },
>> {
>> .name = "edma_tc0",
>> .start = DA8XX_TPTC0_BASE,
>> .end = DA8XX_TPTC0_BASE + SZ_1K - 1,
>> .flags = IORESOURCE_MEM,
>> },
>> {
>> .name = "edma_tc1",
>> .start = DA8XX_TPTC1_BASE,
>> .end = DA8XX_TPTC1_BASE + SZ_1K - 1,
>> .flags = IORESOURCE_MEM,
>> },
>> {
>> .name = "edma_cc1",
>> .start = DA850_TPCC1_BASE,
>> .end = DA850_TPCC1_BASE + SZ_32K - 1,
>> .flags = IORESOURCE_MEM,
>> },
>>
>> As you can see, there are several memory maps and different interpretations.
>> Considering this, IMO- it makes sense to pay a small price to keep the semantics
>> sane.
>
> Then do 1 compatible string per interpretation. That can then define
> the number of CCs and TCs.
Ok.
>>
>> On the other hand, the other 2 options are:
>> 1. We add a fallback if reg-names look up fails.
>
> reg-names is supposed to be optional, so you should already have that fallback.
With the new binding, without reg-names not sure how to fall back
there can variable number of different reg entries of different types.
There's no way to know when one ends and the other begins. The fall
back I mentioned can only work for old dtbs that only specify 1 CC.
Thanks,
-Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
