linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V17 2/3] dmaengine: qcom_hidma: add debugfs hooks
Date: Mon, 2 May 2016 14:55:52 +0530	[thread overview]
Message-ID: <20160502092552.GC2274@localhost> (raw)
In-Reply-To: <57258799.70803@codeaurora.org>

On Sun, May 01, 2016 at 12:35:37AM -0400, Sinan Kaya wrote:
> >>> >
> >>> > Hmm, have you thought about using regmap?
> >>>
> >>> To be honest, I didn't know what regmap is but I just read some code
> >>> and looked at how it is used. Feel free to correct me if I got it
> >>> wrong.
> >>>
> >>> Regmap seems to be designed for *slow* speed peripherals to improve frequent
> >>> accesses by the SW. It looks like it is used by MFD, SPI and I2C drivers.
> >>>
> >>> It seems to cache the register contents and flush/invalidate them only when
> >>> needed.
> >>>
> >>> The MMIO version seems to be assuming the presence of device-tree like CLK
> >>> API which doesn't exist on ACPI systems and is not portable.
> >>>
> >>> My reaction is that it is a lot of code with no added functionality to what
> >>> HIDMA driver is trying to achieve.
> >>>
> >>> Given that the use case here is only for debug purposes; I think it is OK
> >>> to keep this runtime call here. I don't want to add any overhead into the
> >>> existing code just to support the debug use case.
> >>>
> >>> None of my register read/writes are slow. This file will only be used to
> >>> troubleshoot customer issues.
> >>
> >> $ is always faster than MMIO. This way you can give reg contents to users
> >> without waking up hw.
> >>
> >> Also we at Intel use regmap on ACPI systems without CLK API
> > 
> > I can try and see the performance impact is. What happens to registers that hw updates like status registers. Those will be most interesting during debug. How does remap get updated for those? Is there a way to tell it not to cache certain registers
> 
> My evaluation turned out negative. The regmap code is nice for bus like peripherals
> like I2C and SPI where everything is bitwise accessed. This is not the case
> in this code. 

I do not entirely agree with the statements here, it does give big benefit
on our systems with MMIO. I am going to ask Mark to comment on this, he
know better and understands ARM.

I am probably going to be okay with this not using regmap and it is debug
but you should give that a try in future for better performance and ofcourse
you can add to regmap to get a better model for your device

> Regmap is a nice tool if used properly but it doesn't mean that it will work
> in every single case. It doesn't match with the goal of this driver. 
> 
> As soon as I abstract register accesses, the regmap code writes all MMIO registers
> with the readl variant functions.
> 
> Barriers are really expensive on ARM. I paid very special attention in the 
> code to decide when to use relaxed version vs. the readl version. I lose 
> all of this optimization. 
> 
> Since the clocks are restored only during the debug case, I don't see any
> problems here. It is not worth the effort to do redo the whole thing and 
> introduce errors as I see a lot of tripping points like regmap_sync variants.

-- 
~Vinod

  reply	other threads:[~2016-05-02  9:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11 14:21 [PATCH V17 0/3] dmaengine: add Qualcomm Technologies HIDMA driver Sinan Kaya
2016-04-11 14:21 ` [PATCH V17 1/3] dmaengine: qcom_hidma: implement lower level hardware interface Sinan Kaya
2016-04-26  3:28   ` Vinod Koul
2016-04-26 15:04     ` Sinan Kaya
2016-04-26 15:10       ` Andy Shevchenko
2016-04-26 15:23         ` Sinan Kaya
2016-04-26 16:24       ` Vinod Koul
2016-04-28 19:30         ` Sinan Kaya
2016-05-01  4:38           ` Sinan Kaya
2016-04-11 14:21 ` [PATCH V17 2/3] dmaengine: qcom_hidma: add debugfs hooks Sinan Kaya
2016-04-26  3:30   ` Vinod Koul
2016-04-26 12:08     ` okaya at codeaurora.org
2016-04-26 16:25       ` Vinod Koul
2016-04-26 16:55         ` Sinan Kaya
2016-04-27  8:15           ` Vinod Koul
2016-04-27  8:47             ` Marc Zyngier
2016-04-27 13:25               ` okaya at codeaurora.org
2016-04-27 12:51             ` okaya at codeaurora.org
2016-05-01  4:35               ` Sinan Kaya
2016-05-02  9:25                 ` Vinod Koul [this message]
2016-05-02 10:40                   ` Mark Brown
2016-04-11 14:21 ` [PATCH V17 3/3] dmaengine: qcom_hidma: add support for object hierarchy Sinan Kaya

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=20160502092552.GC2274@localhost \
    --to=vinod.koul@intel.com \
    --cc=linux-arm-kernel@lists.infradead.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).