| Message ID | 20240603-ucsi-rework-interface-v1-0-99a6d544cec8@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | usb: typec: ucsi: rework glue driver interface | expand |
On Mon, Jun 03, 2024 at 02:24:53AM GMT, Dmitry Baryshkov wrote: > The interface between UCSI and the glue driver is very low-level. It > allows reading the UCSI data from any offset (but in reality the UCSI > driver reads only VERSION, CCI an MESSAGE_IN data). All event handling > is to be done by the glue driver (which already resulted in several > similar-but-slightly different implementations). It leaves no place to > optimize the write-read-read sequence for the command execution (which > might be beneficial for some of the drivers), etc. > > The patchseries attempts to restructure the UCSI glue driver interface > in order to provide sensible operations instead of a low-level read / > write calls. > > If this approach is found to be acceptable, I plan to further rework the > command interface, moving reading CCI and MESSAGE_IN to the common > control code, which should simplify driver's implementation and remove > necessity to split quirks between sync_control and read_message_in e.g. > as implemented in the ucsi_ccg.c. > > Note, the series was tested only on the ucsi_glink platforms. Further > testing is appreciated. Gracious ping for the reviews / comments. My endgoal is to simplify the command submission interface, allowing us to handle odd commands in a single function rather than having the code split between sync_write() and notification handling. > > Depends: [1], [2] > > [1] https://lore.kernel.org/linux-usb/20240521151109.3078775-1-fabrice.gasnier@foss.st.com/ > > [2] https://lore.kernel.org/linux-usb/20240531104653.1303519-1-heikki.krogerus@linux.intel.com/ > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > Dmitry Baryshkov (7): > usb: typec: ucsi: move ucsi_acknowledge() from ucsi_read_error() > usb: typec: ucsi: simplify command sending API > usb: typec: ucsi: split read operation > usb: typec: ucsi: rework command execution functions > usb: typec: ucsi: inline ucsi_read_message_in > usb: typec: ucsi: extract common code for command handling > usb: typec: ucsi: reorder operations in ucsi_run_command()
Hi Dmitry, On Tue, Jun 18, 2024 at 09:59:07PM +0300, Dmitry Baryshkov wrote: > On Mon, Jun 03, 2024 at 02:24:53AM GMT, Dmitry Baryshkov wrote: > > The interface between UCSI and the glue driver is very low-level. It > > allows reading the UCSI data from any offset (but in reality the UCSI > > driver reads only VERSION, CCI an MESSAGE_IN data). All event handling > > is to be done by the glue driver (which already resulted in several > > similar-but-slightly different implementations). It leaves no place to > > optimize the write-read-read sequence for the command execution (which > > might be beneficial for some of the drivers), etc. > > > > The patchseries attempts to restructure the UCSI glue driver interface > > in order to provide sensible operations instead of a low-level read / > > write calls. > > > > If this approach is found to be acceptable, I plan to further rework the > > command interface, moving reading CCI and MESSAGE_IN to the common > > control code, which should simplify driver's implementation and remove > > necessity to split quirks between sync_control and read_message_in e.g. > > as implemented in the ucsi_ccg.c. > > > > Note, the series was tested only on the ucsi_glink platforms. Further > > testing is appreciated. > > Gracious ping for the reviews / comments. My endgoal is to simplify the > command submission interface, allowing us to handle odd commands in a > single function rather than having the code split between sync_write() > and notification handling. I don't have any objections. Just rebase these and drop the RFC. The patch 6/7 did not apply cleanly anymore on top of the two dependencies you listed. thanks,
The interface between UCSI and the glue driver is very low-level. It allows reading the UCSI data from any offset (but in reality the UCSI driver reads only VERSION, CCI an MESSAGE_IN data). All event handling is to be done by the glue driver (which already resulted in several similar-but-slightly different implementations). It leaves no place to optimize the write-read-read sequence for the command execution (which might be beneficial for some of the drivers), etc. The patchseries attempts to restructure the UCSI glue driver interface in order to provide sensible operations instead of a low-level read / write calls. If this approach is found to be acceptable, I plan to further rework the command interface, moving reading CCI and MESSAGE_IN to the common control code, which should simplify driver's implementation and remove necessity to split quirks between sync_control and read_message_in e.g. as implemented in the ucsi_ccg.c. Note, the series was tested only on the ucsi_glink platforms. Further testing is appreciated. Depends: [1], [2] [1] https://lore.kernel.org/linux-usb/20240521151109.3078775-1-fabrice.gasnier@foss.st.com/ [2] https://lore.kernel.org/linux-usb/20240531104653.1303519-1-heikki.krogerus@linux.intel.com/ Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Dmitry Baryshkov (7): usb: typec: ucsi: move ucsi_acknowledge() from ucsi_read_error() usb: typec: ucsi: simplify command sending API usb: typec: ucsi: split read operation usb: typec: ucsi: rework command execution functions usb: typec: ucsi: inline ucsi_read_message_in usb: typec: ucsi: extract common code for command handling usb: typec: ucsi: reorder operations in ucsi_run_command() drivers/usb/typec/ucsi/ucsi.c | 215 ++++++++++++++++++---------------- drivers/usb/typec/ucsi/ucsi.h | 26 ++-- drivers/usb/typec/ucsi/ucsi_acpi.c | 100 ++++++++-------- drivers/usb/typec/ucsi/ucsi_ccg.c | 103 +++++++--------- drivers/usb/typec/ucsi/ucsi_glink.c | 74 ++++-------- drivers/usb/typec/ucsi/ucsi_stm32g0.c | 79 +++++-------- 6 files changed, 277 insertions(+), 320 deletions(-) --- base-commit: 975aa2136eebb8c7c716ac2d24d9bfdb002f87fd change-id: 20240525-ucsi-rework-interface-5ff2264f6aec Best regards,