On 3/4/26 23:18, Shenwei Wang wrote:
[...] > +GPIO RPMSG Protocol > +=================== > + > +The GPIO RPMSG transport protocol is used for communication and interaction > +with GPIO controllers located on remote cores on the RPMSG bus. > + > +Message Format > +-------------- > + > +The RPMSG message consists of a 6-byte packet with the following layout: > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + |type |cmd |port |line | data | > + +-----+-----+-----+-----+-----+----+ > + > +- **Type (Message Type)**: The message type can be one of: > + > + - 0: GPIO_RPMSG_SEND > + - 1: GPIO_RPMSG_REPLY > + - 2: GPIO_RPMSG_NOTIFY I think would make sense to display the type in hexa. e.g : 0x00, 0x01, etc. Also, would it make sense to display the byte index as follows outside of the boxes? > + > +- **Cmd**: Command code, used for GPIO_RPMSG_SEND messages. Are there any specific commands? Also please either use upper-case first letter (e.g Type, Cmd) or lower-case letter (port, line) but do not mix them. > + > +- **line**: The GPIO line(pin) index of the port. In message format line comes after port so switch the order here. > + > +- **port**: The GPIO port(bank) index. > + > +- **data**: See details in the command description below. > + > +- **reply err**: Error code from the remote core. > + > + - 0: Success > + - 1: General error (Early remote software only returns this unclassified > error) > + - 2: Not supported (A command is not supported by the remote firmware) > + - 3: Resource not available (The resource is not allocated to Linux) > + - 4: Resource busy (The resource is already in use) > + - 5: Parameter error Is this part of the 6-byte packet? Are these standard errors or you defined them as is? > + > + > +GPIO Commands > +------------- > + > +Commands are specified in the **Cmd** field for **GPIO_RPMSG_SEND** (Type=0) > messages. > + > +The SEND message is always sent from Linux to the remote firmware. Each > +SEND corresponds to a single REPLY message. The GPIO driver should Wouldn't be the other way around? Each REPLY corresponds to a single SEND msg? > +serialize messages and determine whether a REPLY message is required. If a > +REPLY message is expected but not received within the specified timeout > +period (currently 1 second in the Linux driver), the driver should return > +-ETIMEOUT. > + > +GET_DIRECTION (Cmd=2) > +~~~~~~~~~~~~~~~~~~~~~ > + > +**Request:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 0 | 2 |port |line | 0 | 0 | > + +-----+-----+-----+-----+-----+----+ > + > +**Reply:** > + > +.. code-block:: none > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 1 | 2 |port |line | err | dir| > + +-----+-----+-----+-----+-----+----+ > + > +- **err**: See above for definitions. > + > +- **dir**: Direction. > + > + - 0: Output > + - 1: Input > + > +SET_DIRECTION (Cmd=3) > +~~~~~~~~~~~~~~~~~~~~~ > + > +**Request:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 0 | 3 |port |line | dir | 0 | > + +-----+-----+-----+-----+-----+----+ > + > +- **dir**: Direction. > + > + - 0: None > + - 1: Output > + - 2: Input > + > +**Reply:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 1 | 3 |port |line | err | 0 | > + +-----+-----+-----+-----+-----+----+ > + > +- **err**: See above for definitions. > + > + > +GET_VALUE (Cmd=4) > +~~~~~~~~~~~~~~~~ > + > +**Request:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 0 | 4 |port |line | 0 | 0 | > + +-----+-----+-----+-----+-----+----+ > + > +**Reply:** > + > +.. code-block:: none > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 1 | 4 |port |line | err | val| > + +-----+-----+-----+-----+-----+----+ > + > +- **err**: See above for definitions. > + > +- **val**: Direction. Why is direction High or Low? Or I'm missing something. > + > + - 0: High > + - 1: Low > + > +SET_VALUE (Cmd=5) > +~~~~~~~~~~~~~~~~~ > + > +**Request:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 0 | 5 |port |line | val | 0 | > + +-----+-----+-----+-----+-----+----+ So when getting replies val is at index 5, but when sending requests val is at index 4. Wonder if we make this consistent? Or at least explain why did you choose this layout. > + > +- **val**: Output Level. > + > + - 0: High > + - 1: Low > + > +**Reply:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 1 | 5 |port |line | err | 0 | > + +-----+-----+-----+-----+-----+----+ > + > +- **err**: See above for definitions. > + > +SET_IRQ_TYPE (Cmd=6) Is there a cmd for gpio polarity? [...] > + > +NOTIFY_REPLY (Cmd=10) > +~~~~~~~~~~~~~~~~~~~~ > +The reply message for the notification is optional. The remote firmware can > +implement it to simulate the interrupt acknowledgment behavior. > + > +**Request:** > + > +.. code-block:: none > + > + +-----+-----+-----+-----+-----+----+ > + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05| > + | 0 | 10 |port |line |level| 0 | > + +-----+-----+-----+-----+-----+----+ > + > +- **line**: The GPIO line(pin) index of the port. > +- **port**: The GPIO port(bank) index. > +- **level**: GPIO line status. > + > +Notification Message > +-------------------- > + > +Notifications are sent with **Type=2 (GPIO_RPMSG_NOTIFY)**: Here you should clarify who sends the notification messages. ... Notifications are messages sent by the remote core and they have Type=0x02... [..]
