Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1541248 > unrolled thread

Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot Mark Brown <broonie@kernel.org> - 2016-12-13 17:50 +0100
    Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot Chen-Yu Tsai <wens@csie.org> - 2016-12-14 15:00 +0100
      Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot Mark Brown <broonie@kernel.org> - 2016-12-14 18:50 +0100
        Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot Chen-Yu Tsai <wens@csie.org> - 2017-01-03 05:00 +0100

#1541248 — Re: [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot

[Multipart message — attachments visible in raw view] — view raw

On Fri, Dec 09, 2016 at 11:20:18AM +0000, Lee Jones wrote:

> Is the following valid/necessary?

> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote:
> > The AXP806 supports either master/standalone or slave mode.
> > Slave mode allows sharing the serial bus, even with multiple
> > AXP806 which all have the same hardware address.

> > This is done with extra "serial interface address extension",
> > or AXP806_BUS_ADDR_EXT, and "register address extension", or
> > AXP806_REG_ADDR_EXT, registers. The former is read-only, with
> > 1 bit customizable at the factory, and 1 bit depending on the

I don't really know anything about the details of this chip, sorry.

> > This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
> > know to be the proper value for a standard AXP806 in slave mode.
> > Afterwards it will reinitialize the regmap cache, to purge any
> > invalid stale values.

If the chip has been reset then you'd want to reset the cache too.  I've
no idea if that's needed here or not though, it depends what happens to
the global state of the chip when this reconfiguration happens.

[toc] | [next] | [standalone]

#1541919

On Wed, Dec 14, 2016 at 12:47 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Dec 09, 2016 at 11:20:18AM +0000, Lee Jones wrote:
>
>> Is the following valid/necessary?
>
>> On Wed, 23 Nov 2016, Chen-Yu Tsai wrote:
>> > The AXP806 supports either master/standalone or slave mode.
>> > Slave mode allows sharing the serial bus, even with multiple
>> > AXP806 which all have the same hardware address.
>
>> > This is done with extra "serial interface address extension",
>> > or AXP806_BUS_ADDR_EXT, and "register address extension", or
>> > AXP806_REG_ADDR_EXT, registers. The former is read-only, with
>> > 1 bit customizable at the factory, and 1 bit depending on the
>
> I don't really know anything about the details of this chip, sorry.

If these 2 registers don't match, any access to the other registers
is ignored, so the kernel either read bogus data, or the read fails.

What this patch does is make sure the registers match, to guarantee
access, and then reinitialize the regmap cache to get rid of any
stale data.

>> > This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
>> > know to be the proper value for a standard AXP806 in slave mode.
>> > Afterwards it will reinitialize the regmap cache, to purge any
>> > invalid stale values.
>
> If the chip has been reset then you'd want to reset the cache too.  I've
> no idea if that's needed here or not though, it depends what happens to
> the global state of the chip when this reconfiguration happens.

It is not a reset in the general sense. I suppose a better way would
be to do an explicit write to the register first, then initialize
the regmap. I'd have to export the write function from the RSB bus
driver first though.

Regards
ChenYu

[toc] | [prev] | [next] | [standalone]

#1542081

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 14, 2016 at 09:52:31PM +0800, Chen-Yu Tsai wrote:

> What this patch does is make sure the registers match, to guarantee
> access, and then reinitialize the regmap cache to get rid of any
> stale data.

So what you're saying is that previous writes may have been ignored?

> > If the chip has been reset then you'd want to reset the cache too.  I've
> > no idea if that's needed here or not though, it depends what happens to
> > the global state of the chip when this reconfiguration happens.

> It is not a reset in the general sense. I suppose a better way would
> be to do an explicit write to the register first, then initialize
> the regmap. I'd have to export the write function from the RSB bus
> driver first though.

Surely just doing a write immediately after initializing the regmap
would have the same effect?  That'd ensure that the hardware has the
desired value before there are any other writes.  But I might be missing
something here.

[toc] | [prev] | [next] | [standalone]

#1549519

On Thu, Dec 15, 2016 at 1:40 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Dec 14, 2016 at 09:52:31PM +0800, Chen-Yu Tsai wrote:
>
>> What this patch does is make sure the registers match, to guarantee
>> access, and then reinitialize the regmap cache to get rid of any
>> stale data.
>
> So what you're saying is that previous writes may have been ignored?

Sorry for the late reply.

Yes, any previous reads and writes may have been ignored. I'm not sure
if regmap cache prefetches any registers. Last I checked it didn't.

>> > If the chip has been reset then you'd want to reset the cache too.  I've
>> > no idea if that's needed here or not though, it depends what happens to
>> > the global state of the chip when this reconfiguration happens.
>
>> It is not a reset in the general sense. I suppose a better way would
>> be to do an explicit write to the register first, then initialize
>> the regmap. I'd have to export the write function from the RSB bus
>> driver first though.
>
> Surely just doing a write immediately after initializing the regmap
> would have the same effect?  That'd ensure that the hardware has the
> desired value before there are any other writes.  But I might be missing
> something here.

So I just tested this. Dropping both the regcache_sync_region() and
regmap_reinit_cache() is ok.

I'll send a revised patch.

ChenYu

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web