Hi Stephen, On Nov 12, 2012, at 6:49 PM, Stephen Warren wrote: > On 11/12/2012 04:23 AM, Pantelis Antoniou wrote: >> Hi Grant, >> >> Sorry for the late comments, travelling... >> >> On Nov 9, 2012, at 6:28 PM, Grant Likely wrote: > ... >>> *with the caveat that not all types of changes are a good idea and we >>> may disallow. For example, is changing properties in existing nodes a >>> good idea? >> >> Yes, changing properties is something that we need. One such change is >> the change of the bus controller 'status' properties to enabled upon >> insertion of a child device node, and change back to 'on-demand' when >> all the child device nodes are gone. > > Do we actually need to do that? > > From the base-board perspective, consider an SoC's I2C channel that is > routed to the child board connector. The routing to the connector is > always present on the base board. Only the presence (or lack thereof) of > devices on that I2C bus is influenced by whether a child board is > connected or not, and the design of the child board. Therefore, wouldn't > it make sense for the base board to always enable the I2C controller? > > That would make it easier for someone to hook up a couple wires to the > I2C pins and use utilities such as i2cget/set to communicate with it, > without going through the whole process of creating a DT to represent > the device. This could speed up simple hacking/prototyping and allow it > to proceed in a less structured way. Unfortunately that doesn't work for the beaglebone (am355x) and a large number of general purpose SoCs. What is different between general purpose SoCs and vertical market SoCs (i.e. OMAP) is that the design of the the latter is for devices where pretty much all the interfaces are expected to be active at the same time. General purpose SoCs put more peripherals in the SoC, but due to packaging considerations (and price), the peripheral pins are highly muxed. So the i2c bus pins are shared with the LCD controller are shared with the analog input and so on. It is impossible (and on top of that really dangerous) to enable peripheral blocks without knowing what's connected on the other side. In a nutshell, for the bone and similar devices, probing with the devices enabled doesn't work. Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
