Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/