Hi Peter, Am 07.05.2015 um 17:51 schrieb Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>: > On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote: >> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>: >>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: > >>> Both devicetree and tty/serial can already represent independent control; >>> what is proposed is a way to express dependent control, and in all cases, >>> that control stems directly from either the UART state itself or via >>> commands sent over that interface. >> >> Yes. This is why I propose that the tty/uart driver can send an internal notification >> to the device driver. And the device driver can register to be notified by the UART >> that is identified by the phandle of the slave DT entry. > > I've not seen any code with your proposal, so that makes it impossible to > compare competing solutions. If you can give me some (unspecified) time to do it, I can write (simplified) patches to demonstrate the idea. I just hesitate to work out and submit a counter proposal to what Neil has submitted, because it will become wasted effort if it is rejected before I am finished. > > >>> Any target not requiring UART involvement doesn't (and probably, shouldn't) >>> be expressed as a slave device. >> >> IMHO it is not obligatory to represent the direction of control by a parent>child >> relation in DT. DT just needs to describe that there is a relation/connection. > > Devicetree usage in the linux kernel is for representing the host view, not an > abstract machine. I have yet to see an example of a proposed tty slave where the > host interface is not a UART. So far, I am only aware of two devices proposed to be tty power controlled slaves: * our GPS chip and * several Bluetooth modules (using HCI). It is difficult to predict future use cases and systems. With some phantasy there could be some I2C controlled serial level shifter that translates uart RX/TX/RTS/CTS to RS232 levels but allows for pin swapping (null modem). Power control of that chip is done through I2C. Similar chips exist for headset pinout detection ans automatic swapping, e.g. TS3A225E. Or some Infrared (IrDA) transceiver with mode and power control over I2C. Such a device should probably be described as a child node of the I2C bus it is connected to. And the driver must become an i2c device driver. So this would be in conflict with tty slave child nodes - but no problem with a phandle to the uart. > >> The driver code already must “know” the direction of notifications. >> >> BTW, there can even be control in reverse direction in some cases. E.g. the slave >> driver wants to automatically set the baud rate of the uart, i.e. the slave controls >> the uart on /dev/tty side. >> >> If I have monitored some other discussion right, this is exactly done by a Codec >> driver to tell its mcbsp counterpart about clock rates and data formats it should >> expect. Maybe this is the reason why McBSP use (or are just happy with) the >> phandle approach. > > Parameters are not control. Agreed. Especially if you mean power control. But does it change the necessity to describe the control direction in the DT as parent>child? In many other situations power control is described by regulator phandles and the regulators are not children of the controlling DT node. BR, Nikolaus -- 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
