From: Mark Brown <firstname.lastname@example.org> To: Jeffrey Hugo <email@example.com> Cc: Andrzej Hajda <firstname.lastname@example.org>, Laurent Pinchart <Laurent.email@example.com>, Dave Airlie <firstname.lastname@example.org>, Daniel Vetter <email@example.com>, Rob Clark <firstname.lastname@example.org>, Bjorn Andersson <email@example.com>, "open list:DRM PANEL DRIVERS" <firstname.lastname@example.org>, MSM <email@example.com>, lkml <firstname.lastname@example.org> Subject: Re: [PATCH 1/2] regmap: Add DSI bus support Date: Thu, 11 Jul 2019 15:41:59 +0100 [thread overview] Message-ID: <20190711144159.GH14859@sirena.co.uk> (raw) In-Reply-To: <CAOCk7No77CDRE=bnBVGzYw9ixWKO4PMBBWksm4JEeh3ydfOkemail@example.com> [-- Attachment #1: Type: text/plain, Size: 2487 bytes --] On Wed, Jul 10, 2019 at 12:08:34PM -0600, Jeffrey Hugo wrote: > On Fri, Jul 5, 2019 at 7:06 PM Mark Brown <firstname.lastname@example.org> wrote: > The addresses for these spec defined messages are 8-bit wide, so 256 > valid "destinations". However, the payload is variable. Most of the > defined operations take an 8-bit payload, but there are a few that I > see with 16-bit payloads. Oh, good, variable register sizes, what a market leading idea :( That basically doesn't work with regmap, you need to either define one regmap per register size and attach them to the device or use reg_read() and reg_write() and hide the complexity in there. > As the contents of the generic read/write messages are implementation > defined, the answer to your question seems to be no - the spec does > not define that the registers are 8-bit addressable, and 8-bit wide. The code definitely ought to at least be more flexible then. Right now it's very hard coded. > I think perhaps the discussion needs to step back a bit, and decide > how flexible do we want this regmap over DSI to be? I think its > usefulness comes from when a device can be configured via multiple > interfaces, so I don't expect it to be useful for every DSI interface. > It seems like the DSI panels use DSI directly to craft their > configuration. As a result, we are probably looking at just devices > which use the generic read/write commands, but sadly the format for > those is not universal per the spec. From the implementations I've > seen, I suspect 8-bit addressing of 8-bit wide registers to be the > most common, but apparently there is an exception to that already in > the one device that I care about. It's relatively easy to add a bunch of special cases in - look at how the I2C code handles it, keying off a combination of the register configuration and the capabilities of the host controller. I guess for this it'd mainly be the register configuration. You might find the reg_read()/reg_write() interface better than the raw buffer one for some of the formats, it does let > Do we want to go forward with this regmap support just for the one TI > device, and see what other usecases come out of it, and attempt to > solve those as we go? I have no strong opinions here, it looks fine from a framework point of view though it's unclear to me if viewing it as a register map meshes well with how the hardware is designed or not - it seems plausible though. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-11 14:42 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-03 21:43 [PATCH 0/2] ti-sn65dsi86 DSI configuration support Jeffrey Hugo 2019-07-03 21:45 ` [PATCH 1/2] regmap: Add DSI bus support Jeffrey Hugo 2019-07-06 1:06 ` Mark Brown 2019-07-10 18:08 ` Jeffrey Hugo 2019-07-11 14:41 ` Mark Brown [this message] 2019-07-11 13:11 ` Andrzej Hajda 2019-07-11 13:56 ` Rob Clark 2019-07-12 13:01 ` Andrzej Hajda 2019-07-12 14:22 ` Jeffrey Hugo 2019-07-13 0:49 ` Rob Clark 2019-07-11 14:50 ` Mark Brown 2019-07-15 8:38 ` Andrzej Hajda 2019-07-03 21:45 ` [PATCH 2/2] drm/bridge: ti-sn65dsi86: Add support to be a DSI device Jeffrey Hugo
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=20190711144159.GH14859@sirena.co.uk \ --email@example.com \ --cc=Laurent.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 1/2] regmap: Add DSI bus support' \ /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
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).