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

[Lee Jones]

On Fri, 11 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
> state of an external pin. The latter is writable. Only when
> the these device addressing bits (in the upper 4 bits of the
> registers) match, will the device respond to operations on
> its other registers.
> 
> The AXP806_REG_ADDR_EXT was previously configured by Allwinner's
> bootloader. Work on U-boot SPL support now allows us to switch
> to mainline U-boot, which doesn't do this for us. There might
> be other bare minimum bootloaders out there which don't to this
> either. It's best to handle this in the kernel.
> 
> 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.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/mfd/axp20x.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index cdaeb34a9a38..2f5d46f28511 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -829,6 +829,41 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
>  {
>   int ret;
>  
> + /*
> +  * 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
> +  * state of an external pin. The latter is writable. Only when
> +  * the these device addressing bits (in the upper 4 bits of the
> +  * registers) match, will the device respond to operations on its
> +  * other registers.
> +  *
> +  * Since we only support an AXP806 chained to an AXP809 in slave
> +  * mode, and there isn't any existing hardware which uses AXP806
> +  * in master mode, or has 2 AXP806s in the same system, we can
> +  * just program the register address extension to the slave mode
> +  * address.
> +  */
> + if (axp20x->variant == AXP806_ID) {
> + /* Write to the register address extension register */
> + regmap_write(axp20x->regmap, AXP806_REG_ADDR_EXT, 0x10);

Please define 0x10.

> + /* Make sure the write hits the device */
> + regcache_sync_region(axp20x->regmap, AXP806_REG_ADDR_EXT,
> +  AXP806_REG_ADDR_EXT);
> +
> + /*
> +  * Reinitialize the regmap cache in case the device didn't
> +  * properly respond to our reads before.
> +  */
> + regmap_reinit_cache(axp20x->regmap, axp20x->regmap_cfg);
> + }
> +
>   ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
> IRQF_ONESHOT | IRQF_SHARED, -1,
> axp20x->regmap_irq_chip,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 1/2] mfd: axp20x: Add address extension registers for AXP806 regmap

[Lee Jones]

On Fri, 11 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
> state of an external pin. The latter is writable. Only when
> the these device addressing bits (in the upper 4 bits of the
> registers) match, will the device respond to operations on
> its other registers.
> 
> Add these 2 registers to the regmap so we can access them.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/mfd/axp20x.c   | 3 ++-
>  include/linux/mfd/axp20x.h | 2 ++
>  2 files changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be32e61..cdaeb34a9a38 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -135,6 +135,7 @@ static const struct regmap_range 
> axp806_writeable_ranges[] = {
>   regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
>   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
>   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
> + regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT),
>  };
>  
>  static const struct regmap_range axp806_volatile_ranges[] = {
> @@ -305,7 +306,7 @@ static const struct regmap_config axp806_regmap_config = {
>   .val_bits   = 8,
>   .wr_table   = _writeable_table,
>   .volatile_table = _volatile_table,
> - .max_register   = AXP806_VREF_TEMP_WARN_L,
> + .max_register   = AXP806_REG_ADDR_EXT,
>   .cache_type = REGCACHE_RBTREE,
>  };
>  
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index fec597fb34cb..7e85ececcedf 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -115,6 +115,8 @@ enum {
>  #define AXP806_CLDO2_V_CTRL  0x25
>  #define AXP806_CLDO3_V_CTRL  0x26
>  #define AXP806_VREF_TEMP_WARN_L  0xf3
> +#define AXP806_BUS_ADDR_EXT  0xfe
> +#define AXP806_REG_ADDR_EXT  0xff
>  
>  /* Interrupt */
>  #define AXP152_IRQ1_EN   0x40

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins

[Linus Walleij]

[Notice this reply has little to do with the patch in question: I think
it should be applied. I just want to involve some MMC/SD people here]

On Thu, Nov 17, 2016 at 9:57 PM,   wrote:
> On 2016-11-17 10:34, Chen-Yu Tsai wrote:
>>
>> Given that MMC starts in open-drain mode and the pull-ups are required,
>> it's best to enable it for all the pin settings.
>
> It's even more complicated than that with MMC. It starts in open-drain mode
> for
> CMD during initialization but changes to push-pull afterwards. The card has
> internal pull-ups to prevent bus floating during setup and will disable them
> after switching to 4bit mode (or 8bit for eMMC when available).
> But even after switching to push-pull drivers there are states the bus would
> float and pull ups have to ensure a high level on the bus.
>
> See JESD84-A441 chapter 7.15 ff as reference.
>
>   The difference between the P-bit and Z-bit is that a P-bit is actively
> driven
>   to HIGH by the card respectively host output driver, while Z-bit is driven
> to
>  (respectively kept) HIGH by the pull-up resistors Rcmd respectively Rdat.
>
> Enabling the pull ups on the CPU would be the right choice considering that
> most boards will not have external pull-ups. Even if they would have one,
> adding the internal in parallel would work in almost all cases and the
> increase in power consumption would be negligible.

I guess you are referring to software-controlled pull up on the pad ring of
the SoC. Nominally that should be handled by pin control like in this
patch.

It is not clear from context to me which of the lines need to be handled
like this? Just the data lines? DAT0 would be the critical line to pull up
in that case, since the others will not be used until bus switch anyways
right?

But what about CMD?

I assume CLK should always be push-pull?

Also: if the pins have an explicit Open Drain setting, should that
be used? I guess so?

Overall I think this construction is pretty common.

We essentially have two classes of connections:

- Those connecting the eMMC or even MMC/SD card directly to
  the SoC. No pull-ups on the board. Here it makes sense to have:

  1. A pin control default state with open drain and pull-ups
 enabled for those lines

  and it then needs

  2. A second "4/8bit mode" that will switch these
 pins to push-pull mode and turn off the pull-ups.

  If the OD+pull-up state is the default we should probably
  standardize a default name for the state when we kick in 4/8bit
  mode from the IOS operation.

- Those connection the MMC/SD on an external slot through a
  levelshifter/EMI filter. In that case I guess it is pretty much
  dependent on the levelshifter or EMI thing how the lines out
  of the SoC should be configured, and usually it is static so
  you do not need to worry about it after boot configuration
  of pins. (Mostly no bias, push-pull I think.)

I highly suspect a whole bunch of SoC drivers are not getting
this business right today. Not even in out-of-tree vendor kernels.

Yours,
Linus Walleij

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH sunxi-boards] add fex file from Nintendo NES Classic Edition

[Mike Valk]

On Friday, November 18, 2016 at 8:04:06 AM UTC+1, Chen-Yu Tsai wrote:
>
> On Fri, Nov 18, 2016 at 3:01 PM, Naoki FUKAUMI  > wrote: 
> > ah, sorry, my reply was about u-boot patch, not fex file... 
> > 
> > then, that fex is came from Japanese version. I can wait English 
> > version to compare difference. 
> > 
> > or should I use name of Japanese version? 
>
> I guess the English name is more recognizable outside of Japan. 
> Maybe you could add _japanese_version or something to the file name? 
>

Would the following not be better?:
nintendo_classic_mini_nes_famicom.fex
And split into following if needed?:
nintendo_classic_mini_nes.fex
nintendo_classic_mini_famicom.fex

Wikipedia:
https://en.wikipedia.org/wiki/NES_Classic_Edition
Nintendo Classic Mini: Nintendo Entertainment System in Europe and Australia
Nintendo Classic Mini: Family Computer in Japan
 

>
> If they end up the same we could then just remove it. 
>
> ChenYu 
>
> > 
> > On Fri, Nov 18, 2016 at 1:18 PM, Naoki FUKAUMI  > wrote: 
> >> hi 
> >> 
> >> On Fri, Nov 18, 2016 at 11:01 AM, Chen-Yu Tsai  > wrote: 
> >>> Just to clarify, is this the Japanese version or the U.S. version? 
> >> 
> >> well, 
> >> 
> >> I have only Japanese version, but I prefer to use name of English 
> >> version for this kind of things. 
> >> 
> >> my patch is intended to support both version. I tested it on only 
> >> Japanese version. currently I have no feedback from U.S. version user. 
> >> 
> >>> AFAIK the Japanese version is Famicom Mini? 
> >> 
> >> official name is, 
> >> 
> >>  Nintendo Classic Mini: Family Computer (in Japanese, of course) 
> >> 
> >> "Famicom Mini" is another product. 
> >>  https://en.wikipedia.org/wiki/List_of_Classic_NES_Series_games 
> >> 
> >>> I think you mentioned on IRC that one has an LED and the other 
> doesn't? 
> >> 
> >> I just saw some pictures of U.S. version on the web. I think there is 
> >> one LED on front (next to POWER/RESET buttons), but I cannot confirm 
> >> it. 
> >> 
> >> I'm sure there is no LED on Japanese version. 
> >>  
> http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-19.jpg
>  
> >>  
> http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-20.jpg
>  
> >> 
> >> I think, main board, connectors, and cables are same. controller and 
> >> sub board are different but I guess it's compatible enough. 
> >> 
> >> Regards, 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] About Lamobo-R1

[Chen-Yu Tsai]

Hi,

I sent some patches to fix the GPIO pins for USB WiFi for the
Lamobo-R1 some time ago. It seems the original DTS matches
the fex file found in sunxi-boards, but not the schematics
released by BananaPi.

What version do you have? Mine says Lamobo R1-SD_v3.

Thanks
ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.