Brian, On Sat, Nov 30, 2013 at 01:15:56AM -0800, Brian Norris wrote: > > > Can anyone help me understand if there's *any* valid use case where we > > want to specify a-priori the bus width, considering it's completely > > discoverable at run-time? > > I think the primary use case should be to reflect a limitation in the > hardware (besides just the flash chip). It can mean that the controller > itself only supports one bus width, or that the board is only wired up > for x8, for instance. >
What do you mean by "reflect a limitation" of the hardware? Maybe I'm not really following you, but it sounds as you're mixing up the NAND device buswidth and the memory controller buswidth. At least I consider them as two different parameters for two different pieces of hardware. Consider OMAP, just as an example. We currently have two DT properties: 1. nand-bus-width: not related to OMAP but kernel wide. It's supposed to specify the devices buswidth. 2. gpmc,device-width: It specifies how the controller should be configured (it doesn't really specify hardware, but configuration, sadly). I now realise maybe this piece of DT binding is not a good example of DT. Anyway, once again: Why would we need to set "nand-bus-width" to specify the flash device width given we can discover that as soon as the NAND is detected? Notice, that this discussion is independent of the discussion about removing the NAND_BUSWIDTH_AUTO. It's just about removing a DT property for a parameter that's runtime configurable. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
