[U-Boot] [PATCH V2 5/6] P2571: dts: Add DT files for Tegra210/P2571 board

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/23/2015 01:06 PM, Tom Warren wrote:
> Stephen,
>
>> -----Original Message-----
>> From: Stephen Warren [mailto:swarren at wwwdotorg.org]
>> Sent: Thursday, July 23, 2015 11:00 AM
>> To: Tom Warren
>> Cc: u-boot at lists.denx.de; Thierry Reding; Stephen Warren;
>> tomcwarren3959 at gmail.com
>> Subject: Re: [U-Boot] [PATCH V2 5/6] P2571: dts: Add DT files for
>> Tegra210/P2571 board
>>
>> On 07/23/2015 11:44 AM, Tom Warren wrote:
>>> Stephen,
>>>
>>>> -----Original Message-----
>>>> From: Stephen Warren [mailto:swarren at wwwdotorg.org]
>>>> Sent: Wednesday, July 22, 2015 11:17 AM
>>>> To: Tom Warren
>>>> Cc: u-boot at lists.denx.de; Thierry Reding; Stephen Warren;
>>>> tomcwarren3959 at gmail.com
>>>> Subject: Re: [U-Boot] [PATCH V2 5/6] P2571: dts: Add DT files for
>>>> Tegra210/P2571 board
>>>>
>>>> On 07/20/2015 01:50 PM, Tom Warren wrote:
>>>>> Based on T124 Venice2. SDMMC1 is SD-card slot.
>>>>
>>>>>     arch/arm/dts/{tegra124.dtsi => tegra210.dtsi}      | 153 ++++-----------------
>>>>
>>>> There's also a lot of stuff in that file that isn't used in U-Boot or
>>>> isn't validated yet (audio, SPI?, PWM, I2C?, APBDMA, PCIe). I'd
>>>> suggest trimming the DT down to the absolute bare minimum for what
>>>> U-Boot is using right now. That will help prevent any inconsistencies
>>>> between the U-Boot and kernel DT files for Tegra210.
>>   >
>>> Audio, PCIE make sense. UART and SPI both have DMA properties, so I can' t
>> remove APBDMA. I'll do a cleanup run and see what shakes out.
>>
>> I believe the DMA properties should be optional in the bindings for UART and
>> SPI. So, you should be able to remove the DMA properties from the client
>> nodes and hence also the APBDMA node. (Especially given that the U-Boot
>> drivers those HW blocks don't do DMA).
 >
> If they're optional, why are they in tegra124.dtsi? (and T114 and T30). I wonder how they got in there originally?

DMA is a useful feature, and all the bindings design work and testing 
for APBDMA has happened on earlier chips in order to enable DMA usage in 
the Linux kernel. Consequently, the DMA-related properties exist in the 
Linux kernel's copy of the DT.

The whole point of a DT is that it's identical between all users of the 
DT. Consequently, (parts of I suspect) the DT file from the Linux kernel 
have been sync'd into U-Boot's copy of the DT, and hence the DMA 
properties showed up in U-Boot.

For T210, we haven't yet validated that all the DMA related bindings/... 
are appropriate, so we shouldn't be adding them to /any/ copy of the DT 
yet, in case design/... changes are required. This will avoid adding 
incorrect content and then having to fix it later. Once DMA usage is 
validated in the kernel, and hence DMA-related properties are added to 
the kernel's copy of the DT, we should keep the nodes/properties in sync 
between the kernel and U-Boot just like earlier chips.