Re: [PATCH v1] regmap: introduce value tracing for regmap bulk operations

[Dmitry Rokosov]

On Fri, Aug 19, 2022 at 01:07:47PM +0100, Mark Brown wrote:
> On Thu, Aug 18, 2022 at 05:44:23PM +0000, Dmitry Rokosov wrote:
> > On Thu, Aug 18, 2022 at 04:43:45PM +0100, Mark Brown wrote:
> 
> > > At the minute we don't put the actual data for the bulk transfers into
> > > the trace so the information simply isn't there.
> 
> > What do you think about the patch? Can we use the separate trace event
> > class, or do we have to add these tracepoints to some existing class, like
> > regmap_block?
> 
> I didn't realise that was even a question, but then there seems to be
> some discussion I've not seen given the CCing going on.  The biggest
> issue is do we even want the overhead but I'll need to find time to look
> at this properly.

No any additional discussion before. I've added your address to all emails
which I sent.
I've asked about the bulk tracepoints patch. As I understood Marc's question
about multiple ways of logging the same stuff, the main concern is patch
adding additional trace event class "regmap_block_io" and doesn't use already
existing classes. I've tried to inject bulk transfer data hexdumping to
regmap_block trace event class, but it has some difficult and ugly
conditions should be applied. That's why I would prefer to discuss
implementation proposed by patch if possible.

Why do you think it this patch will bring overhead to regmap? AFAK, when
tracepoint is disabled, tracepoint fast assign operation shouldn't be
executed. In other words, memcpy will not be applied.

-- 
Thank you,
Dmitry