building RaspPi Images

[Warner Losh]

On Feb 13, 2013, at 10:35 PM, Tim Kientzle wrote:

> 
> On Feb 12, 2013, at 10:17 PM, Warner Losh wrote:
> 
>> 
>> On Feb 12, 2013, at 10:30 PM, Tim Kientzle wrote:
>> 
>>> On Feb 12, 2013, at 10:45 AM, Warner Losh wrote:
>>> 
>>>> But it doesn't have all the pin group stuff in yet, so I'll have to chase that down and see what happened to that part of the early patches I was reviewing…
>>> 
>>> I would be interested in seeing those early patches.
>>> 
>>> I agree that it would be best to bundle pinmux info
>>> with the related device in the FDT.  Seeing some
>>> prior art would help a lot.
>> 
>> They were posted to the device-tree mailing list a while ago, but I don't have a pointer to the archives :(...  They were from somebody at Atmel.com, so if you find it, it will be easy to search  for.
>> 
>> Warner
>> 
> 
> 
> I finally found the thread I think you're referring to, from
> January 2012.  This looks like an interesting post
> because it gives some concrete ideas for what the
> device tree might look like (and the author gives
> some thoughtful critiques that I'll have to think about
> further):
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-January/012015.html
> 
> Skimming some other discussions, it looks like the general
> idea a lot of folks are considering is:
> 
> Having a pinmux node for whatever hardware controls
> pinmuxing.  For the TI chip I'm working with, that would be
> the scm (System Control Module).
> 
> Within that node, have a collection of named pinmux settings.
> E.g., pmx_ethernet01 or pmx_uart02
> 
> Within other hardware nodes, refer to those named
> settings, so you might have (very roughly; I still don't
> understand FDT syntax):
> 
>     uart02: uart at 40800000 {
>         compatible = "….";
>         ….
>         pinmux = "pmx_uart02";
>         pinmuxc = "scm01";
>     }
> 
> (That is, the uart02 should use scm01 to enable
> pmx_uart02 pinmux settings.)  In particular, for
> hardware with multiple states, you could refer
> to multiple pinmux settings (e.g., an idle setting
> that tristated the outputs vs. an active setting
> that powered them).
> 
> A lot of the debate seems to revolve around the details
> of whether the pinmux details should be lists of hardware
> numeric codes (advantage:  eliminates tables from
> the pinmux driver source and eliminates lots of text
> from the DTS) or should be more verbose textual
> descriptions (advantage:  easier to read and update).
> 
> Is this generally what you had in mind?

Generally, yes. The thread I had seen was a different one, but one quite similar in tone....

Warner