From: Andrzej Hajda <firstname.lastname@example.org> To: Mark Brown <email@example.com> Cc: Jeffrey Hugo <firstname.lastname@example.org>, Laurent.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 Subject: Re: [PATCH 1/2] regmap: Add DSI bus support Date: Mon, 15 Jul 2019 10:38:55 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20190711145045.GI14859@sirena.co.uk> On 11.07.2019 16:50, Mark Brown wrote: > On Thu, Jul 11, 2019 at 03:11:56PM +0200, Andrzej Hajda wrote: > >> 1. DSI protocol defines actually more than 30 types of transactions, >> but this patchset implements only few of them (dsi generic write/read >> family). Is it possible to implement multiple types of transactions in >> regmap? > You can, there's a couple of different ways depending on how > exactly things are done. > >> 3. DSI devices are no MFDs so regmap abstraction has no big value added >> (correct me, if there are other significant benefits). > There's a few extra bits even if you're not using the marshalling > code to get things onto the bus - the main ones are the register > cache support (which people often use for simpler suspend/resume > support) and the debug and trace facilities (things like > tracepoints and debugfs for dumping the register map). I do not see cache usable in bridge drivers, I guess default config will be caching disabled, as it is already in the driver from this patchset. So beside marshaling, we are left only with debug facilities, not a big gain :) Moreover as it was already written DSI is mainly used to transport COMMANDS to the device, with variable number of arguments - it does not resembles registry map at all. On the other side there is some subset of DSI devices which exposes register memory using MIPI DSI Generic Write/Read packets, for example: ti-sn65dsi86, tc358764. They fit better to regmap framework. Hard to say how common is this pattern. Maybe we can try with it? If yes it would be good to put clear remark that regmap/dsi is for such devices, to avoid possible confusion. Regards Andrzej
next prev parent reply other threads:[~2019-07-15 8:39 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 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 [this message] 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 \ --firstname.lastname@example.org \ --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).