Hi all. I've been thinking for quite a while now about setting up a
wiki for documenting new device tree bindings. I've finally got
around to setting something up to give it a try and making a first cut
at a peer-review process for new bindings. I'd like to get some
feedback on what I've set up
On Thu, Mar 25, 2010 at 3:04 PM, Russell King - ARM Linux
wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
>> ===Required System State===
>> *Quiesce all DMA
>> *CPU register contents
>> **r0 = 0
>> **r1 = Linux machine number (as defined in the ARM Linux machine database)
>
On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi wrote:
> Grant Likely wrote:
>> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
>>> It seems to me that there are plausible use cases for both direct-inclusion
>>> and indirection. I don't see any real problems with either, so I would vote
>>> f
> > > ===Required System State===
> > > *Quiesce all DMA
> > > *CPU register contents
> > > **r0 = 0
> > > **r1 = Linux machine number (as defined in the ARM Linux machine
> > > database) or 0
> >
> > 0 is a valid machine number. What is your purpose of passing 0?
>
> Presumably a machine number
On Thu, Mar 25, 2010 at 6:53 PM, M. Warner Losh wrote:
> Most !linux systems are not GPL'd. They are BSDL, primarily, or some
> private license between seller and buyer. In any event, other OSes
> likely won't have the GPL issue.
You're probably right.
> But I'm confused. If you can't distri
In message:
Timur Tabi writes:
: The initrd thing is a good idea, but it doesn't help non-Linux
: operating systems. Then again, those OS's might not have any GPL
: issues, so it could be a moot point.
Most !linux systems are not GPL'd. They are BSDL, primarily, or some
private lic
On Thu, Mar 25, 2010 at 09:04:09PM +, Russell King - ARM Linux wrote:
> On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> > Hi all,
> >
> > Since work is being done to add ARM Flattened Device Tree support to
> > both Linux and FreeBSD, I think it would be worth while to agree on
On Thu, Mar 25, 2010 at 10:59:01AM -0600, Grant Likely wrote:
> On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi wrote:
> > Grant Likely wrote:
> >> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
> >>> It seems to me that there are plausible use cases for both
> >>> direct-inclusion
> >>> and
Grant Likely wrote:
On Thu, Mar 25, 2010 at 1:53 PM, Scott Wood wrote:
Grant Likely wrote:
On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
Grant Likely wrote:
For indirect firmware, create a /chosen/firmware node. Don't add a
compatible property,
Oh, I don't like that idea at all. Th
Grant Likely wrote:
> No, this isn't off in the weeds. I concede the point of needing to
> store firmware in a separate node, but I still don't agree with the
> argument that it needs to be anything more than an anonymous named
> blob.
I still don't understand what's so *bad* about having some k
On Thu, Mar 25, 2010 at 2:04 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> I don't know that it's strictly necessary in this case -- it looks like
>> there is a magic number in the firmware blob -- but I don't understand
>> the objection as a matter of principle. These device tree discussions
>
On Thu, Mar 25, 2010 at 1:53 PM, Scott Wood wrote:
> Grant Likely wrote:
>>
>> On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
>>>
>>> Grant Likely wrote:
For indirect firmware, create a /chosen/firmware node. Don't add a
compatible property,
>>>
>>> Oh, I don't like that idea
On Wed, Mar 24, 2010 at 09:11:56AM -0600, Grant Likely wrote:
> Hi all,
>
> Since work is being done to add ARM Flattened Device Tree support to
> both Linux and FreeBSD, I think it would be worth while to agree on a
> common boot interface for passing a device tree blob from firmware to
> the ker
Scott Wood wrote:
> I don't know that it's strictly necessary in this case -- it looks like
> there is a magic number in the firmware blob -- but I don't understand
> the objection as a matter of principle. These device tree discussions
> have a tendency to get awfully bikesheddy.
I don't wa
Grant Likely wrote:
On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
Grant Likely wrote:
For indirect firmware, create a /chosen/firmware node. Don't add a
compatible property,
Oh, I don't like that idea at all. The compatible property is useful for me to
know *how* to parse the binary
Grant Likely wrote:
> Compatible is for devices. This is not a device. Drivers cannot bind
> against it. Use a different mechanism if you have metadata about the
> blob. If your driver doesn't know how to validate its own firmware
> blobs, then you've got bigger problems.
Perhaps. I left the
On Thu, Mar 25, 2010 at 11:03 AM, Timur Tabi wrote:
> Grant Likely wrote:
>> For indirect firmware, create a /chosen/firmware node. Don't add a
>> compatible property,
>
> Oh, I don't like that idea at all. The compatible property is useful for me
> to know *how* to parse the binary blob.
Comp
Grant Likely wrote:
> For indirect firmware, create a /chosen/firmware node. Don't add a
> compatible property,
Oh, I don't like that idea at all. The compatible property is useful for me to
know *how* to parse the binary blob.
> compatible is for devices and this node is for
> blob data.
On Thu, Mar 25, 2010 at 10:36 AM, Timur Tabi wrote:
> Grant Likely wrote:
>> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
>>> It seems to me that there are plausible use cases for both direct-inclusion
>>> and indirection. I don't see any real problems with either, so I would vote
>>> f
Timur Tabi wrote:
Grant Likely wrote:
On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
It seems to me that there are plausible use cases for both direct-inclusion
and indirection. I don't see any real problems with either, so I would vote
for specifying both alternatives.
Ugh. Then thi
Scott Wood wrote:
> It would be nice to not have to provide separate copies of the firmware
> to u-boot and Linux -- not from a space perspective, but support.
My plan was to take the copy that U-Boot already knows about (via macros like
CONFIG_SYS_QE_FW_ADDR) and have U-Boot dynamically embed
Grant Likely wrote:
> On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
>> It seems to me that there are plausible use cases for both direct-inclusion
>> and indirection. I don't see any real problems with either, so I would vote
>> for specifying both alternatives.
>
> Ugh. Then this one d
Grant Likely wrote:
[cc'd David Gibson]
On Thu, Mar 25, 2010 at 8:42 AM, Timur Tabi wrote:
The initrd thing is a good idea, but it doesn't help non-Linux
operating systems. Then again, those OS's might not have any GPL
issues, so it could be a moot point.
The more I think about it, the more
On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote:
> It seems to me that there are plausible use cases for both direct-inclusion
> and indirection. I don't see any real problems with either, so I would vote
> for specifying both alternatives.
Ugh. Then this one driver would need to implement
[cc'd David Gibson]
On Thu, Mar 25, 2010 at 8:42 AM, Timur Tabi wrote:
> On Wed, Mar 24, 2010 at 8:49 PM, Segher Boessenkool
> wrote:
>
>> I do; I consider that indirection thing (and putting firmware blobs
>> in the device tree at all, but to a lesser extent) as making a mess
>> of your device
It seems to me that there are plausible use cases for both
direct-inclusion and indirection. I don't see any real problems with
either, so I would vote for specifying both alternatives.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozl
Segher Boessenkool wrote:
As far as I can see, you want that indirection node so that you
safe space in the DTB.
Probably more of a general desire to not duplicate things that don't
need to be duplicated... I don't think the space issue is critical in
this particular case.
With real OF it
On Wed, Mar 24, 2010 at 8:49 PM, Segher Boessenkool
wrote:
> I do; I consider that indirection thing (and putting firmware blobs
> in the device tree at all, but to a lesser extent) as making a mess
> of your device binding.
I guess we'll just have to agree to disagree.
> Let's forget that I do
28 matches
Mail list logo
