Date: Tue, 12 Feb 2013 09:40:06 -0700 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org, Brett Wynkoop <wynkoop@wynn.com>, Ian Lepore <ian@freebsd.org> Subject: Re: building RaspPi Images Message-ID: <FB6E9736-F961-4685-9502-AA5AC17D9F29@bsdimp.com> In-Reply-To: <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <E691571B-EA19-4485-BB02-7486685B44C7@bsdimp.com> <1360598511.4545.92.camel@revolution.hippie.lan> <DCA761EF-FAE4-4BC9-AE33-D9F55C8ABB16@bsdimp.com> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 11, 2013, at 11:27 PM, Tim Kientzle wrote: > On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: >=20 >> =85 I still find it much more cumbersome to work with >> than the old hints system. The very fact that you need >> a special compiler to change the fdt data is part of that. >=20 > This is my single biggest complaint about fdt as well. And the better solution is? We have nothing that's better... >>> 2) We're still debating the role of the FDT vis a vis >>> end user customization. Personally, I would like >>> to find some more dynamic approach to handling >>> pinmux at runtime. (E.g., if you want to use a pin >>> for gpio, you do this: >>> $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change >>> $ gpioctl 1 7 on >>> Similarly, I think that enabling uart2 should automatically >>> adjust the pinmux appropriately. >>=20 >> I whole-heartedly agree with that last sentence, but it's about a >> zillion miles from where our code is now. I'm not even sure it's = fully >> possible, it just seems like a nice generic ideal "I asked for a = uart, >> so the uart driver should enable power, enable clocks, and assign = pins >> to make that happen." >=20 > At least for BeagleBone, I think I see a way to > make the pinmux code work this way. That code is > all table-driven, so with some creative reworking of > the tables, it should be feasible to define groups of > pins and a mechanism to manage them. Tedious > work, to be sure, simply because of the sheer number > of definitions involved, but nothing particularly complicated. The tables should come in from the FDT. I know that's a pain, but it = makes it so that when the next rev of the silicon comes out that has = slightly different swizzled pins easier to integrate. > Another approach I've considered is to have the > necessary pinmux assignments be part of the > device entry in the DTS. (BeagleBone DTS, at > least, defines a single list of pinmux settings for > the board, which I don't like at all.) This would > be similar to the way interrupts and memory > regions are assigned today. That would at > least move the problem down to the level of > enabling/disabling particular entries in the DTS. > Unfortunately, I don't yet understand the inner workings > of simplebus and the FDT management in the kernel > well enough to be able to tackle this just yet. This is the approach that's favored by those driving the FDT = definitions. I've seen it work well in the Atmel case where they have = the same basic core that they remix with different devices to produce = the different SoCs optimized for different market segments. They have = gotten tot he point where a new SoC with old IP just needs a new FDT to = be supported by the kernel. > Having pinmux settings be part of the associated > device node in the DTS would also make your next > issue a little easier to manage, I think. (For example, > the DTS in SVN could have several versions of a single > device with most of them disabled.) The typical approach taken over in linux-land is to have a base config, = then have customizations done with a file that just includes the base, = and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: include "GENERIC" nodevice foo device bar option FRED nooption WILMA FDT is powerful enough to cope with those things today, with the version = we have in the tree. Warner >> The problem crops up when "assign pins" has >> several sets of pins to choose from for a given device, and I know at >> least the Atmel SoCs do this a lot. >=20 >=20 > Tim >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB6E9736-F961-4685-9502-AA5AC17D9F29>