On Fri, Sep 27, 2013 at 11:33:19AM -0500, Matt Sealey wrote: > On Fri, Sep 27, 2013 at 8:31 AM, Jason Cooper <jason@xxxxxxxxxxxxxx> wrote: > > On Fri, Sep 27, 2013 at 02:21:07PM +0100, Russell King - ARM Linux wrote: > >> On Fri, Sep 27, 2013 at 09:12:25AM -0400, Jason Cooper wrote: > >> > I'm currently slogging through the exact same issues for adding imx50 > >> > (SanDisk Connect Wireless media Drive). I thought I was just thick. > >> > It's a relief to know I'm not the only one having trouble with this. > >> > >> I'm coming to the conclusion that it's almost to the point of "vendor > >> lockin" - you have to find someone who understands this stuff to take > >> your hardware description and turn it into a working DT description. > > > > I don't think it's vendor lock-in, I think Freescale's pinctrl/gpio IP > > block is just an over-complicated pain in the ass that doesn't lend > > itself to DT well. > > > Me either - device trees aren't vendor lock-in but they ARE a huge > reminder of how silicon vendors prioritize software development - the > chip works. The i.MX IOMUX block lends itself VERY well to device > trees. The "vendor lock-in" that I'm talking about here is the lock-in to the people who created the DT mess in the first place, *not* the silicon vendor. If it's extremely difficult to understand how to put together the proper DT description because it's just a load of numbers, and the knowledge is limited to a few developers, then that makes it really difficult for 3rd parties to create their own device tree files. There should be an effort to make writing a DT description as simple and easy as possible, and part of that means ensuring that the documentation helps people to understand how to do that, and certainly doesn't add additional needless to confusion. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
