Defining schemas for Device Tree
jonsmirl at gmail.com
jonsmirl at gmail.com
Tue Jul 30 14:26:02 EDT 2013
On Tue, Jul 30, 2013 at 2:04 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Tue, Jul 30, 2013 at 2:03 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> On Tue, Jul 30, 2013 at 1:49 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:
>>>> On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>> On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:
>>>>>> On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>>>
>>>>>>> On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:
>>>>>>>> On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown <broonie at kernel.org> wrote:
>>>>>>>>> On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:
>>>>>>>>>
>>>>>>>>>> This...
>>>>>>>>>> tx-dma-channel = <&pdma0 7>; /* preliminary */
>>>>>>>>>> rx-dma-channel = <&pdma0 6>; /* preliminary */
>>>>>>>>>
>>>>>>>>>> Probably should be
>>>>>>>>>> dmas = <&pdma0 7>,<&pdma0 6>;
>>>>>>>>>> dma-names = "tx", "rx";
>>>>>>>>>
>>>>>>>>> It should be - the latter is the generic DMA binding. There's a lot of
>>>>>>>>> bindings in the kernel that predate that but people are currently
>>>>>>>>> working to transfer over, this is one of the examples of instability
>>>>>>>>> that everyone is talking about.
>>>>>>>>
>>>>>>>> Is something similar to this possible in device tree syntax?
>>>>>>>> dmas = <"tx" &pdma0 7>, <"rx" &pdma0 6>;
>>>>>>>
>>>>>>> I /think/ you can physically write that in *.dts, or something very
>>>>>>> similar; with the strings outside the <>:
>>>>>>>
>>>>>>> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
>>>>>>>
>>>>>>> However, there's been strong push-back (i.e. doing that has not been
>>>>>>> allowed at all) on attempting to mix variable-length strings and
>>>>>>> fixed-length/alignment integer cells in the same property. This is
>>>>>>> primarily because you then can't ensure that the integer cell data is
>>>>>>> aligned in the DTB (dtc and/or the DTB format spec does/requires/allows
>>>>
>>>> The PowerPC FDT doc says that strings are indirected into a string
>>>> table. So they aren't variable length in the data structures.
>>>
>>> Do you have a link to the document; I'm not sure which one you mean.
>>
>> So it looks like there is one indirection to get to the block, then
>> the strings are concatenated. The indirection must have been hidden
>> when the node structure was created. I had thought that there was a
>> list of indirects each pointing to a string in the string block.
>>
>> https://www.power.org/documentation/epapr-version-1-1/
>
> So what does an alternating use of strings do?
>
> dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;
dtc compiles this string without complaint....
gpios = "str1", <&gpio0 10 1>, "str2", <&gpio0 10 1>;
It would a new helper function to interpret it but I this it should work.
I've always disliked paired attributes (dmas, dma-names) is easy to
mess them up by accident.
>
>
>>
>> 8.5 Strings Block
>> The strings block contains strings representing all the property names
>> used in the tree. These null-
>> terminated strings are simply concatenated together in this section,
>> and referred to from the structure
>> block by an offset into the strings block.
>> The strings block has no alignment constraints and may appear at any
>> offset from the beginning of the
>> device tree blob.
>>
>>
>>>
>>>> I was wondering how dmas = "tx", "rx" was implemented. It is two
>>>> pointers into the indirect block. So this should work, there is no
>>>> variable length data to worry about in the structure.
>>>
>>> If you look at of_property_read_string_index() in drivers/of/base.c,
>>> you'll see that it expects the strings to just be packed together inline.
>>>
>>> What you say may be correct for node and property names, just not
>>> property values.
>>
>>
>>
>> --
>> Jon Smirl
>> jonsmirl at gmail.com
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com
--
Jon Smirl
jonsmirl at gmail.com
More information about the linux-arm-kernel
mailing list