dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: balbi@kernel.org, linux-usb@vger.kernel.org,
	lee.jones@linaro.org, dri-devel@lists.freedesktop.org
Subject: Re: [RFC 1/9] regmap: Add USB support
Date: Mon, 17 Feb 2020 22:44:38 +0000	[thread overview]
Message-ID: <20200217224438.GW9304@sirena.org.uk> (raw)
In-Reply-To: <34adf00c-a465-6d6d-23bd-a2a00290c1fa@tronnes.org>


[-- Attachment #1.1: Type: text/plain, Size: 1351 bytes --]

On Mon, Feb 17, 2020 at 11:15:37PM +0100, Noralf Trønnes wrote:
> Den 17.02.2020 22.39, skrev Mark Brown:

> > Out of interest why are 8 bit registers going to be a problem?

> I have written 3 drivers so far and they all have some registers that
> need to deal with values larger than 255. If I would need to add a lot
> of code because of dropping regmap, then I would have looked at ways to
> work around this in order to keep regmap, hi/lo registers perhaps with
> wrapping access functions. But it looks like the LOC won't change much,
> I need a few lines to ensure values are little endian, but I can also
> remove some lines that's not needed anymore.

Right, so you effectively have mixed register sizes which regmap isn't
going to be super happy with (assuming you need all the actual display
data to be 8 bit "registers").  One thing you could do there if you
wanted to try the regmap route is to have multiple regmaps but since
it's not clear what you're really getting from regmap other than the
trace functionality you're probably right that it's not worth bothering.

The only other thing I can think of is packing RGB into a single
register so you're display data isn't 8 bit but that's probably not
sensible from a graphics point of view (I didn't really look at that
code so no idea what you're doing there).

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-02-17 22:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-16 17:21 [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...) Noralf Trønnes
2020-02-16 17:21 ` [RFC 1/9] regmap: Add USB support Noralf Trønnes
2020-02-17 12:11   ` Mark Brown
2020-02-17 21:33     ` Noralf Trønnes
2020-02-17 21:39       ` Mark Brown
2020-02-17 22:15         ` Noralf Trønnes
2020-02-17 22:44           ` Mark Brown [this message]
2020-02-16 17:21 ` [RFC 2/9] mfd: Add driver for Multifunction USB Device Noralf Trønnes
2020-02-27  9:09   ` Lee Jones
2020-02-29 13:26     ` Noralf Trønnes
2020-02-29 16:02       ` Alan Stern
2020-02-16 17:21 ` [RFC 3/9] usb: gadget: function: Add Multifunction USB Device support Noralf Trønnes
2020-02-16 17:21 ` [RFC 4/9] pinctrl: Add Multifunction USB Device pinctrl driver Noralf Trønnes
2020-02-16 17:21 ` [RFC 5/9] usb: gadget: function: mud: Add gpio support Noralf Trønnes
2020-02-16 17:21 ` [RFC 6/9] regmap: Speed up _regmap_raw_write_impl() for large buffers Noralf Trønnes
2020-02-17 12:15   ` Mark Brown
2020-02-16 17:21 ` [RFC 7/9] drm: Add Multifunction USB Device display driver Noralf Trønnes
2020-02-16 17:21 ` [RFC 8/9] drm/client: Add drm_client_init_from_id() and drm_client_modeset_set() Noralf Trønnes
2020-02-17  9:38   ` Daniel Vetter
2020-02-23 17:43     ` Noralf Trønnes
2020-02-23 20:59       ` Daniel Vetter
2020-02-16 17:21 ` [RFC 9/9] usb: gadget: function: mud: Add display support Noralf Trønnes
2020-02-17  9:40 ` [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...) Daniel Vetter
2020-02-17 10:32 ` Neil Armstrong
2020-02-17 14:05   ` Noralf Trønnes
2020-02-18 20:57 ` Andy Shevchenko
2020-02-18 21:31   ` 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=20200217224438.GW9304@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=balbi@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=noralf@tronnes.org \
    /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).