On 3/29/22 14:25, Deepak Kumar Singh wrote:
>
> On 3/23/2022 7:08 PM, Arnaud POULIQUEN wrote:
>>
>> On 1/18/22 20:43, Deepak Kumar Singh wrote:
>>> Add TICOMGET and TIOCMSET ioctl support for rpmsg char device nodes
>>> to get/set the low level transport signals.
>>>
>>> Signed-off-by: Chris Lew <quic_clew@xxxxxxxxxxx>
>>> Signed-off-by: Deepak Kumar Singh <quic_deesin@xxxxxxxxxxx>
>>> ---
>>> drivers/rpmsg/rpmsg_char.c | 47
>>> ++++++++++++++++++++++++++++++++++++++++++----
>>> 1 file changed, 43 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
>>> index b5907b8..c03a118 100644
>>> --- a/drivers/rpmsg/rpmsg_char.c
>>> +++ b/drivers/rpmsg/rpmsg_char.c
>>> @@ -19,6 +19,7 @@
>>> #include <linux/rpmsg.h>
>>> #include <linux/skbuff.h>
>>> #include <linux/slab.h>
>>> +#include <linux/termios.h>
>>> #include <linux/uaccess.h>
>>> #include <uapi/linux/rpmsg.h>
>>> @@ -74,6 +75,9 @@ struct rpmsg_eptdev {
>>> spinlock_t queue_lock;
>>> struct sk_buff_head queue;
>>> wait_queue_head_t readq;
>>> +
>>> + u32 rsigs;
>>> + bool sig_pending;
>>> };
>>> static int rpmsg_eptdev_destroy(struct device *dev, void *data)
>>> @@ -112,7 +116,18 @@ static int rpmsg_ept_cb(struct rpmsg_device
>>> *rpdev, void *buf, int len,
>>> skb_queue_tail(&eptdev->queue, skb);
>>> spin_unlock(&eptdev->queue_lock);
>>> - /* wake up any blocking processes, waiting for new data */
>>> + wake_up_interruptible(&eptdev->readq);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int rpmsg_sigs_cb(struct rpmsg_device *rpdev, void *priv, u32
>>> sigs)
>>> +{
>>> + struct rpmsg_eptdev *eptdev = priv;
>>> +
>>> + eptdev->rsigs = sigs;
>>> + eptdev->sig_pending = true;
>>> +
>>> wake_up_interruptible(&eptdev->readq);
>> Regarding the Glink code, the callback is used to be informed that the
>> remote
>> is ready to send (DSR) and to receive (CTS or DSR)
>> So I suppose that the transmission should also be conditioned by the
>> sig_pending
>
> I think client need to get signal value before starting transmission, so
> that it knows that
>
> it good to transmit data. Also it is not be enforced for every client.
> Some clients may not require
>
> to use signalling/flow control.
>
>>
>> That said tell me if I'm wrong but look to me that what is implemented
>> here is the
>> hardware flow control already managed by the TTY interface. What
>> about using the
>> TTY interface in this case?
>
> Correct. But some clients are using rpmsg char driver directly and don't
> go through tty interface.
>
> So we are incorporating tty like interface here(flow control).
This is the point I would like to highlight to be sure that it is the
good direction.
