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. >> 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. > 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. Regards, Peter Hurley -- 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
