On Sep 15, 2011, at 12:11 AM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <d144ba6d-b90c-46cd-be7f-619701567...@kernel.crashing.org> you > wrote: >> >> Now you could say that we should deal with this via #defines. Which is >> true, however our reference boards allow for running in hundreds if not >> thousands of various possible HW configurations and we've tried to avoid >> having different builds for such things unless completely unavoidable. > > Understood and agreed. > >> So this gives the option to the board code to disable things if it knows >> based on some other information. In the specific case for the P3060QDS >> board, we have "add-on" cards that provide 4-ports of 1-gig SGMII. We >> can detect if one of these cards is in a slot. If the card is missing >> we can 'disable' the ports associated with the slot. > > Well, can you not turn this logic around, and come up in a > configuration with all ports disabled, and then enable only those > ports that are actually present? That appears to make much more sense > to me. Eventually it is even more efficient in terms of things > likepower cinsumption etc. ?
Unfortuantely not. The HW makes the assumption you turn things off, not on. Once we turn something 'off' in the HW we can't turn it back 'on' as the SoC will gate the power to the block and only a hard reset will bring it back up. > [In the long run (maybe not so long actually) you can even do this > device tree based …] - k _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
