On Wed, Feb 05, 2014 at 08:56:34AM -0600, Nishanth Menon wrote: > On 02/05/2014 08:38 AM, Matt Porter wrote: > > On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote: > >> On 02/05/2014 07:48 AM, Jack Mitchell wrote: > [...] > >>> + * --- a/arch/arm/boot/dts/am335x-boneblack.dts > >>> + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts > >>> + * @@ -73,6 +74,6 @@ > >>> + * pinctrl-names = "default", "off"; > >>> + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>; > >>> + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; > >>> + * - status = "okay"; > >>> + * + status = "disabled"; > >>> + * }; > >>> + * }; > >>> + */ > >>> + > >> how about making the audio-cape-reva.dts which includes and overrides > >> parameters of boneblack.dts? > > > > Yeah, that might be a little cleaner. Black makes things unfortunately > > messy for these capes that were really intended for BBW :( > > yes indeed - we might have to live with more dts in such a case. > > > >> Further, I see a bunch of capes in > >> http://elinux.org/Beagleboard:BeagleBone_Capes > >> > >> Assuming that we dont want to discuss capebus all over again, is this > >> the approach we'd like to consider in the interim? > > > > I think that's a fair assumption...I'll note that there is work slowly > > in progress on a very minimal implementation DT overlays upstream. But > > that doesn't exist. We are simply interested in a sane way to use the > > hardware we own in mainline and this approach makes it possible to build > > a kernel+dtb from mainline that works for this configuration. If > > there's a better way to support this hardware *today* let's discuss it. > > One of the big benefits to having this upstream is that it's no longer > > out of sight out of mind. It should be managed alongside all the other > > am335x dts data. > > > > Incidentally, I'm hoping to contribute a similar patch for the DVI cape > > I have here. > > If I am not mistaken, the capes are stackable (within reason), and are > not exactly hotpluggable.. question pops up as to how do we handle > multiple cape descriptions on the same board without having the user > to create custom dts which includes each relevant cape dts he has on > his/her bone? I wonder(without proper research, just thinking aloud) > if u-boot can do some sort of merge of dtbs - assuming ofcourse eeprom > data is used to detect the capes plugged on board? Well covered in the original discussion. gcl summarizes options in https://lkml.org/lkml/2012/11/5/615 Since then, the basic overlay support for the kernel is pretty much a done deal. It has a wide variety of users (FPGA folks) beyond this board specific case. The problem you describe about resource management and conflicts would probably need to be built on top of that. Pantelis had a PoC implementation with capebus/not-a-capebus but that's not part of what is being upstreamed. I'm not sure if there's anybody with enough time out of the Beagleboard community to upstream a resource manager on top of the basic overlay support that's in progress. However, it might make a nice GSoC2014 project. :) -Matt -- 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
