On Wed, 20 Aug 2014, Robert Nelson wrote:
btw, what's your guys thoughts on the simplified dts file, here is the
black: Simple enough for end users to enable/disable things for their
custom capes?
One thing that I am curious about is the workflow for building the
.dtb being used by the end user using this universal cape design. Will
the boot .dtb be built at kernel compile time only? Or are there plans for
the arch/arm/boot/am33*.dts* and associated files to be built
independently of the kernel to allow for modifications of the boot .dtb
without requiring a kernel rebuild?
If it is built only at kernel build time, is it possible to use #define
preprocessor logic to selectively enable pieces of the universal cape
.dts* files via menuconfig (and avoid end-users having to edit the .dts*
files themselves)?
Also, is HDMI audio not included in the RCN 3.14 kernel? I was just
looking through the current 3.14 BB kernel on github and saw the McASP
pins and compatibility for the am33xx audio driver in the .dts files, but
the RCN kernel only has McASP mappings for the audio cape. For the
universal cape, will the HDMI audio functionality be rolled into the
include file for the nxp-hdmi cape? I figure that the two kernel trees
will converge together to include all functionality eventually, but I am
curious how HDMI audio will be handled for the universal cape design. Two
HDMI cape includes (one with audio, one without)? Or one for HDMI video
and one for HDMI audio? It seems like the second one would be better to
avoid trouble with people accidentally enabling both, since it turns a
mutual exclusion setup into an additive one...
Andrew
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
