public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: noman pouigt <variksla@gmail.com>
Cc: Mark Brown <broonie@kernel.org>, <linux-kernel@vger.kernel.org>,
	<gregkh@linuxfoundation.org>
Subject: Re: bug fix for registers debugfs file implementation [RFC]
Date: Thu, 8 Jun 2017 09:50:35 +0100	[thread overview]
Message-ID: <20170608085035.GA28618@localhost.localdomain> (raw)
In-Reply-To: <CAES_P+-gfN9EMzowrZfu9Z1rXi=x07kQFthEG04pSLmRXGG1rA@mail.gmail.com>

On Wed, Jun 07, 2017 at 04:31:15PM -0700, noman pouigt wrote:
> On Mon, Apr 24, 2017 at 2:02 AM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> >> > I'm also very surprised that this is failing for you as I know this code
> >> > has been fairly heavily exercised with devices with very large register
> >> > maps much larger than 4k and my own testing is mainly doing cats which
> >> > seemed to work last time I tried and should be iterating over the 4k
> >> > boundary...  what's the actual failure mode?  I'm guessing it's
> >>
> >> I have integrated Florida codec(wm8281) from cirrus and it has more than 4K registers. I could not dump more than 4K with the existing interface.
> >>
> >> Charles, are you able to dump all the registers?
> >>
> >
> > I seem to be able to dump all the registers just fine here (all
> > 500k of them). You say it only dumps 4k worth of registers then
> > just stops? What version of the kernel are you testing this
> > on? The test I just ran was on Linus's tree, is this an older
> > kernel or for-next?
> >
> > If its an older kernel are you perhaps missing one of these
> 
> Using
> https://github.com/CirrusLogic/linux-drivers/tree/v3.18-arizona/drivers
> 

I am able to dump all the registers if I merge in that branch
into my stock 3.18 setup here. My guess would be there must be
some vendor kernel excitement or something going on here. If you
can ping through a copy of your
drivers/base/regmap/regmap-debugfs.c I can have a look at that
see how it compares to mine.

But I suspect you might need to work through and work out where
it is bombing out in regmap_read_debugfs.

Thanks,
Charles

      reply	other threads:[~2017-06-08  8:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01  9:13 bug fix for registers debugfs file implementation [RFC] noman pouigt
2017-04-21 17:27 ` Mark Brown
2017-04-22 20:28   ` Variksla
2017-04-24  9:02     ` Charles Keepax
2017-04-24 12:04       ` Mark Brown
2017-06-07 23:31       ` noman pouigt
2017-06-08  8:50         ` Charles Keepax [this message]

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=20170608085035.GA28618@localhost.localdomain \
    --to=ckeepax@opensource.wolfsonmicro.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=variksla@gmail.com \
    /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