| Message ID | 20240422184553.3573009-1-sean.anderson@linux.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: zynqmp_dp: IRQ cleanups and debugfs support | expand |
On 4/22/24 14:45, Sean Anderson wrote: > This series cleans up the zyqnmp_dp IRQ and locking situation. Once > that's done, it adds debugfs support. The intent is to enable compliance > testing or to help debug signal-integrity issues. > > Last time I discussed converting the HPD work(s) to a threaded IRQ. I > did not end up doing that for this series since the steps would be > > - Add locking > - Move link retraining to a work function > - Harden the IRQ > - Merge the works into a threaded IRQ (omitted) > > Which with the exception of the final step is the same as leaving those > works as-is. Conversion to a threaded IRQ can be done as a follow-up. > > Changes in v3: > - Store base pointers in zynqmp_disp directly > - Don't delay work > - Convert to a hard IRQ > - Use AUX IRQs instead of polling > - Take dp->lock in zynqmp_dp_hpd_work_func > > Changes in v2: > - Fix kerneldoc > - Rearrange zynqmp_dp for better padding > - Split off the HPD IRQ work into another commit > - Expand the commit message > - Document hpd_irq_work > - Document debugfs files > - Add ignore_aux_errors and ignore_hpd debugfs files to replace earlier > implicit functionality > - Attempt to fix unreproducable, spurious build warning > - Drop "Optionally ignore DPCD errors" in favor of a debugfs file > directly affecting zynqmp_dp_aux_transfer. > > Sean Anderson (13): > drm: xlnx: Store base pointers in zynqmp_disp directly > drm: xlnx: Fix kerneldoc > drm: zynqmp_dp: Downgrade log level for aux retries message > drm: zynqmp_dp: Adjust training values per-lane > drm: zynqmp_dp: Rearrange zynqmp_dp for better padding > drm: zynqmp_dp: Don't delay work > drm: zynqmp_dp: Add locking > drm: zynqmp_dp: Don't retrain the link in our IRQ > drm: zynqmp_dp: Convert to a hard IRQ > drm: zynqmp_dp: Use AUX IRQs instead of polling > drm: zynqmp_dp: Split off several helper functions > drm: zynqmp_dp: Take dp->lock in zynqmp_dp_hpd_work_func > drm: zynqmp_dp: Add debugfs interface for compliance testing > > Documentation/gpu/drivers.rst | 1 + > Documentation/gpu/zynqmp.rst | 149 +++++ > MAINTAINERS | 1 + > drivers/gpu/drm/xlnx/zynqmp_disp.c | 44 +- > drivers/gpu/drm/xlnx/zynqmp_dp.c | 909 +++++++++++++++++++++++++--- > drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 1 + > drivers/gpu/drm/xlnx/zynqmp_kms.h | 4 +- > 7 files changed, 1000 insertions(+), 109 deletions(-) > create mode 100644 Documentation/gpu/zynqmp.rst > +CC Tomi, who I forgot to add initially...
Hi Sean, On 22/04/2024 21:45, Sean Anderson wrote: > This series cleans up the zyqnmp_dp IRQ and locking situation. Once > that's done, it adds debugfs support. The intent is to enable compliance > testing or to help debug signal-integrity issues. > > Last time I discussed converting the HPD work(s) to a threaded IRQ. I > did not end up doing that for this series since the steps would be > > - Add locking > - Move link retraining to a work function > - Harden the IRQ > - Merge the works into a threaded IRQ (omitted) > > Which with the exception of the final step is the same as leaving those > works as-is. Conversion to a threaded IRQ can be done as a follow-up. What is the base for this series? I'm having trouble applying it. I managed to mostly apply it, but I see the board hang when I unload the modules. I didn't debug it as it might as well be caused by my conflict resolution. Tomi > Changes in v3: > - Store base pointers in zynqmp_disp directly > - Don't delay work > - Convert to a hard IRQ > - Use AUX IRQs instead of polling > - Take dp->lock in zynqmp_dp_hpd_work_func > > Changes in v2: > - Fix kerneldoc > - Rearrange zynqmp_dp for better padding > - Split off the HPD IRQ work into another commit > - Expand the commit message > - Document hpd_irq_work > - Document debugfs files > - Add ignore_aux_errors and ignore_hpd debugfs files to replace earlier > implicit functionality > - Attempt to fix unreproducable, spurious build warning > - Drop "Optionally ignore DPCD errors" in favor of a debugfs file > directly affecting zynqmp_dp_aux_transfer. > > Sean Anderson (13): > drm: xlnx: Store base pointers in zynqmp_disp directly > drm: xlnx: Fix kerneldoc > drm: zynqmp_dp: Downgrade log level for aux retries message > drm: zynqmp_dp: Adjust training values per-lane > drm: zynqmp_dp: Rearrange zynqmp_dp for better padding > drm: zynqmp_dp: Don't delay work > drm: zynqmp_dp: Add locking > drm: zynqmp_dp: Don't retrain the link in our IRQ > drm: zynqmp_dp: Convert to a hard IRQ > drm: zynqmp_dp: Use AUX IRQs instead of polling > drm: zynqmp_dp: Split off several helper functions > drm: zynqmp_dp: Take dp->lock in zynqmp_dp_hpd_work_func > drm: zynqmp_dp: Add debugfs interface for compliance testing > > Documentation/gpu/drivers.rst | 1 + > Documentation/gpu/zynqmp.rst | 149 +++++ > MAINTAINERS | 1 + > drivers/gpu/drm/xlnx/zynqmp_disp.c | 44 +- > drivers/gpu/drm/xlnx/zynqmp_dp.c | 909 +++++++++++++++++++++++++--- > drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 1 + > drivers/gpu/drm/xlnx/zynqmp_kms.h | 4 +- > 7 files changed, 1000 insertions(+), 109 deletions(-) > create mode 100644 Documentation/gpu/zynqmp.rst >
On 4/23/24 09:33, Tomi Valkeinen wrote: > Hi Sean, > > On 22/04/2024 21:45, Sean Anderson wrote: >> This series cleans up the zyqnmp_dp IRQ and locking situation. Once >> that's done, it adds debugfs support. The intent is to enable compliance >> testing or to help debug signal-integrity issues. >> >> Last time I discussed converting the HPD work(s) to a threaded IRQ. I >> did not end up doing that for this series since the steps would be >> >> - Add locking >> - Move link retraining to a work function >> - Harden the IRQ >> - Merge the works into a threaded IRQ (omitted) >> >> Which with the exception of the final step is the same as leaving those >> works as-is. Conversion to a threaded IRQ can be done as a follow-up. > > What is the base for this series? I'm having trouble applying it. > > I managed to mostly apply it, but I see the board hang when I unload the modules. I didn't debug it as it might as well be caused by my conflict resolution. The base is v6.8-rc1, but it should probably be v6.9. I can rebase and resend. --Sean >> Changes in v3: >> - Store base pointers in zynqmp_disp directly >> - Don't delay work >> - Convert to a hard IRQ >> - Use AUX IRQs instead of polling >> - Take dp->lock in zynqmp_dp_hpd_work_func >> >> Changes in v2: >> - Fix kerneldoc >> - Rearrange zynqmp_dp for better padding >> - Split off the HPD IRQ work into another commit >> - Expand the commit message >> - Document hpd_irq_work >> - Document debugfs files >> - Add ignore_aux_errors and ignore_hpd debugfs files to replace earlier >> implicit functionality >> - Attempt to fix unreproducable, spurious build warning >> - Drop "Optionally ignore DPCD errors" in favor of a debugfs file >> directly affecting zynqmp_dp_aux_transfer. >> >> Sean Anderson (13): >> drm: xlnx: Store base pointers in zynqmp_disp directly >> drm: xlnx: Fix kerneldoc >> drm: zynqmp_dp: Downgrade log level for aux retries message >> drm: zynqmp_dp: Adjust training values per-lane >> drm: zynqmp_dp: Rearrange zynqmp_dp for better padding >> drm: zynqmp_dp: Don't delay work >> drm: zynqmp_dp: Add locking >> drm: zynqmp_dp: Don't retrain the link in our IRQ >> drm: zynqmp_dp: Convert to a hard IRQ >> drm: zynqmp_dp: Use AUX IRQs instead of polling >> drm: zynqmp_dp: Split off several helper functions >> drm: zynqmp_dp: Take dp->lock in zynqmp_dp_hpd_work_func >> drm: zynqmp_dp: Add debugfs interface for compliance testing >> >> Documentation/gpu/drivers.rst | 1 + >> Documentation/gpu/zynqmp.rst | 149 +++++ >> MAINTAINERS | 1 + >> drivers/gpu/drm/xlnx/zynqmp_disp.c | 44 +- >> drivers/gpu/drm/xlnx/zynqmp_dp.c | 909 +++++++++++++++++++++++++--- >> drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 1 + >> drivers/gpu/drm/xlnx/zynqmp_kms.h | 4 +- >> 7 files changed, 1000 insertions(+), 109 deletions(-) >> create mode 100644 Documentation/gpu/zynqmp.rst >> >
On 23/04/2024 17:59, Sean Anderson wrote: > On 4/23/24 09:33, Tomi Valkeinen wrote: >> Hi Sean, >> >> On 22/04/2024 21:45, Sean Anderson wrote: >>> This series cleans up the zyqnmp_dp IRQ and locking situation. Once >>> that's done, it adds debugfs support. The intent is to enable compliance >>> testing or to help debug signal-integrity issues. >>> >>> Last time I discussed converting the HPD work(s) to a threaded IRQ. I >>> did not end up doing that for this series since the steps would be >>> >>> - Add locking >>> - Move link retraining to a work function >>> - Harden the IRQ >>> - Merge the works into a threaded IRQ (omitted) >>> >>> Which with the exception of the final step is the same as leaving those >>> works as-is. Conversion to a threaded IRQ can be done as a follow-up. >> >> What is the base for this series? I'm having trouble applying it. >> >> I managed to mostly apply it, but I see the board hang when I unload the modules. I didn't debug it as it might as well be caused by my conflict resolution. > > The base is v6.8-rc1, but it should probably be v6.9. I can rebase and resend. Did you have something extra in your branch before the series? I got "error: sha1 information is lacking or useless". Tomi
On 4/23/24 11:30, Tomi Valkeinen wrote: > On 23/04/2024 17:59, Sean Anderson wrote: >> On 4/23/24 09:33, Tomi Valkeinen wrote: >>> Hi Sean, >>> >>> On 22/04/2024 21:45, Sean Anderson wrote: >>>> This series cleans up the zyqnmp_dp IRQ and locking situation. Once >>>> that's done, it adds debugfs support. The intent is to enable compliance >>>> testing or to help debug signal-integrity issues. >>>> >>>> Last time I discussed converting the HPD work(s) to a threaded IRQ. I >>>> did not end up doing that for this series since the steps would be >>>> >>>> - Add locking >>>> - Move link retraining to a work function >>>> - Harden the IRQ >>>> - Merge the works into a threaded IRQ (omitted) >>>> >>>> Which with the exception of the final step is the same as leaving those >>>> works as-is. Conversion to a threaded IRQ can be done as a follow-up. >>> >>> What is the base for this series? I'm having trouble applying it. >>> >>> I managed to mostly apply it, but I see the board hang when I unload the modules. I didn't debug it as it might as well be caused by my conflict resolution. >> >> The base is v6.8-rc1, but it should probably be v6.9. I can rebase and resend. > > Did you have something extra in your branch before the series? I got "error: sha1 information is lacking or useless". Nope. --Sean