Re: [PATCH v6 3/3] drm: Add GUD USB Display driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Noralf,

Peter Stuge wrote:
> I'll prepare a test setup for the RGB-TFT on the weekend.

So implementing a GUD and looking at the protocol from yet another
angle gives more new insights - surprise. :)

Here are some thoughts so far:

* GUD_REQ_SET_VERSION does still rub me wrong; it seems potentially
  quite complex to maintain compatibility in two places; both for host
  and device. I don't want to insist on removing it, but at a minimum
  it's quite unusual.
  Part of the idea in USB is that host software updates are easy if
  not fully automated but device firmware updates less so, thus
  complexity is rather placed in the host.

* It's unclear to me from reading the header files in this v6 patch set
  which GUD_REQ:s and which properties are actually mandatory in devices.
  I'm getting hints from your STM32 device and reading the driver code in
  detail, but what do you think is a good way to document what's required
  vs. optional?

* GUD_REQ_SET_BUFFER my old nemesis. :) It's great that it's optional!
  But do you see any way to turn it into a bulk message, in order to
  remove the memory barrier effect of a control transfer before bulk?

I think it would be possible to noticeably improve performance later,
by changing the host driver to submit asynchronous bulk transfers for
frame data rather than waiting for each transfer to finish; bulk
transfers will then pack optimally on the wire - but with a control
transfer in between there's no chance of achieving that.

Having only one kind of transfer in the hot path would also simplify
canceling still pending transfers (when using async later) if new data
gets flushed before the previous frame is completely transfered.

* A fair bit of the EDID isn't used or has dummy values. Have you already
  considered and dismissed some other ways of accomplishing the same?

* Sorry if I've asked before - but what's the purpose of
  GUD_REQ_SET_STATE_CHECK and GUD_REQ_SET_STATE_COMMIT? Why/when does
  drm do pipe check vs. update?

* How do you feel about passing the parameters for
  GUD_REQ_SET_CONTROLLER_ENABLE and GUD_REQ_SET_DISPLAY_ENABLE in wValue?
  It would save the transfer data stage.


Kind regards

//Peter



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux