linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Stuge <peter@stuge.se>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: hudson@trmm.net, markus@raatikainen.cc,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	linux-usb@vger.kernel.org, dri-devel@lists.freedesktop.org,
	th020394@gmail.com, lkundrak@v3.sk, pontus.fuchs@gmail.com,
	sam@ravnborg.org
Subject: Re: [PATCH v6 3/3] drm: Add GUD USB Display driver
Date: Mon, 1 Mar 2021 18:31:58 +0000	[thread overview]
Message-ID: <20210301183158.6090.qmail@stuge.se> (raw)
In-Reply-To: <20210225213729.GG20076@stuge.se>

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

  parent reply	other threads:[~2021-03-01 18:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 12:16 [PATCH v6 0/3] GUD USB Display driver Noralf Trønnes
2021-02-19 12:17 ` [PATCH v6 1/3] drm/uapi: Add USB connector type Noralf Trønnes
2021-02-19 12:17 ` [PATCH v6 2/3] drm/probe-helper: Check epoch counter in output_poll_execute() Noralf Trønnes
2021-02-19 12:17 ` [PATCH v6 3/3] drm: Add GUD USB Display driver Noralf Trønnes
2021-02-19 21:42   ` Peter Stuge
2021-02-20 17:27     ` Noralf Trønnes
2021-02-26 12:09       ` Noralf Trønnes
2021-02-28  1:52         ` Peter Stuge
2021-02-28 21:04           ` Noralf Trønnes
2021-02-25  9:58   ` Peter Stuge
2021-02-25 18:06     ` Noralf Trønnes
2021-02-25 21:37       ` Peter Stuge
2021-02-26 12:18         ` Noralf Trønnes
     [not found]       ` <20210225213729.GG20076@stuge.se>
2021-03-01 18:31         ` Peter Stuge [this message]
2021-03-01 21:41           ` Noralf Trønnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210301183158.6090.qmail@stuge.se \
    --to=peter@stuge.se \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hudson@trmm.net \
    --cc=linux-usb@vger.kernel.org \
    --cc=lkundrak@v3.sk \
    --cc=markus@raatikainen.cc \
    --cc=noralf@tronnes.org \
    --cc=pontus.fuchs@gmail.com \
    --cc=sam@ravnborg.org \
    --cc=th020394@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).