From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 08/12] sunxi: Add axp209 pmic support
Date: Tue, 03 Jun 2014 19:12:29 +0200 [thread overview]
Message-ID: <538E01FD.8040502@redhat.com> (raw)
In-Reply-To: <1401556087.15871.122.camel@hastur.hellion.org.uk>
Hi,
On 05/31/2014 07:08 PM, Ian Campbell wrote:
> On Fri, 2014-05-30 at 11:06 +0200, Hans de Goede wrote:
>> From: Henrik Nordstrom <henrik@henriknordstrom.net>
>>
>> Add support for the x-powers axp209 pmic which is found on most A10, A13 and
>> A20 boards.
>>
>> While changing the boards.cfg lines for the Cubietruck, add myself as board
>> maintainer for the Cubietruck.
>
> I don't know much about these PMIC things, so just some general
> comments/questions.
>
>> #include <asm/arch/clock.h>
>> #include <asm/arch/dram.h>
>> #include <asm/arch/gpio.h>
>> @@ -116,12 +119,35 @@ void i2c_init_board(void)
>> #ifdef CONFIG_SPL_BUILD
>> void sunxi_board_init(void)
>> {
>> + int power_failed = 0;
>
> bool?
I would prefer to keep this as an int, doing |= on a bool just
feels wrong.
>
>> unsigned long ramsize;
>>
>> +#ifdef CONFIG_AXP209_POWER
>> + power_failed |= axp209_init();
>> + power_failed |= axp209_set_dcdc2(1400);
>> + power_failed |= axp209_set_dcdc3(1250);
>> + power_failed |= axp209_set_ldo2(3000);
>> + power_failed |= axp209_set_ldo3(2800);
>> + power_failed |= axp209_set_ldo4(2800);
>
> I take it that it is safe to keep poking at things after one of them
> fails?
Yes.
>
>> +#endif
>> +
>> printf("DRAM:");
>> ramsize = sunxi_dram_init();
>> printf(" %lu MiB\n", ramsize >> 20);
>> if (!ramsize)
>> hang();
>> +
>> + /*
>> + * Only clock up the CPU to full speed if we are reasonably
>> + * assured it's being powered with suitable core voltage
>> + */
>> + if (!power_failed)
>> +#ifdef CONFIG_SUN7I
>> + clock_set_pll1(912000000);
>> +#else
>> + clock_set_pll1(1008000000);
>
> #define CLK_FULL_SPEED in the relevant sun?i-config.h-es?
Good idea, done.
>
>> +#endif
>> + else
>> + printf("Failed to set core voltage! Can't set CPU frequency\n");
>> }
>> #endif
>> diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
>> new file mode 100644
>> index 0000000..a3f9d52
>> --- /dev/null
>> +++ b/drivers/power/axp209.c
>> @@ -0,0 +1,198 @@
>> +/*
>> + * (C) Copyright 2012
>> + * Henrik Nordstrom <henrik@henriknordstrom.net>
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include <common.h>
>> +#include <i2c.h>
>> +#include <axp209.h>
>> +
>> +enum axp209_reg {
>> + AXP209_POWER_STATUS = 0x00,
>> + AXP209_CHIP_VERSION = 0x03,
>> + AXP209_DCDC2_VOLTAGE = 0x23,
>> + AXP209_DCDC3_VOLTAGE = 0x27,
>> + AXP209_LDO24_VOLTAGE = 0x28,
>> + AXP209_LDO3_VOLTAGE = 0x29,
>> + AXP209_IRQ_STATUS3 = 0x4a,
>> + AXP209_IRQ_STATUS5 = 0x4c,
>> + AXP209_SHUTDOWN = 0x32,
>> +};
>> +
>> +#define AXP209_POWER_STATUS_ON_BY_DC (1<<0)
>> +
>> +#define AXP209_IRQ3_PEK_SHORT (1<<1)
>> +#define AXP209_IRQ3_PEK_LONG (1<<0)
>> +
>> +#define AXP209_IRQ5_PEK_UP (1<<6)
>> +#define AXP209_IRQ5_PEK_DOWN (1<<5)
>
> Only IRQ5 is used?
True, I've dropped the IRQ3 defines.
>
>> +
>> +int axp209_write(enum axp209_reg reg, u8 val)
>> +{
>> + return i2c_write(0x34, reg, 1, &val, 1);
>> +}
>> +
>> +int axp209_read(enum axp209_reg reg, u8 *val)
>> +{
>> + return i2c_read(0x34, reg, 1, val, 1);
>> +}
>> +
>> +int axp209_set_dcdc2(int mvolt)
>> +{
>> + int cfg = (mvolt - 700) / 25;
>> + int rc;
>> + u8 current;
>> +
>> + if (cfg < 0)
>> + cfg = 0;
>
> Can we make mvolt and cfg unsigned? (I suppose you'd then need a range
> check on mvolt before the subtraction, so perhaps it doesn't save much?)
I don't think making them unsigned is helpful.
>
>> + if (cfg > (1 << 6) - 1)
>> + cfg = (1 << 6) - 1;
>
> #define AXP209_DCDC2_MAX?
>
>> +int axp209_set_dcdc3(int mvolt)
>> +{
>> + int cfg = (mvolt - 700) / 25;
>> + u8 reg;
>> + int rc;
>> +
>> + if (cfg < 0)
>> + cfg = 0;
>> + if (cfg > (1 << 7) - 1)
>> + cfg = (1 << 7) - 1;
>
> Some two comments as for DCDC2 (which I won't bother making for
> subsequent clocks).
>
> perhaps cfg = clamp(cfg, 0, 1<<7-1)? Or even cfg = mvolt_to_cfg(mvolt,
> 700, 25, 0, 1<<7-1)?
I've added an mvolt_to_cfg function and used that everywhere.
>
>> + rc = axp209_write(AXP209_DCDC3_VOLTAGE, cfg);
>> + rc |= axp209_read(AXP209_DCDC3_VOLTAGE, ®);
>
> Is read safe if the write failed? Since the reg is never used I assume
> it's just some sort of sync? Or do you need to confirm the contents
> "took"? If not you could remove reg and readback into cfg.
The read is useless, good catch, I've dropped it.
>> + rc = axp209_read(AXP209_LDO24_VOLTAGE, ®);
>> + if (rc)
>> + return rc;
>> +
>> + reg = (reg & 0x0f) | (cfg << 4);
>
> Do we know what these magic numbers mean?
>
> (ah, you have a comment on the use of the lower 4 bits, but not the
> upper 4 used here...)
Added a comment.
>> + rc = axp209_write(AXP209_LDO24_VOLTAGE, reg);
>> + if (rc)
>> + return rc;
>> +
>> + return 0;
>> +}
>> +
>> +int axp209_set_ldo3(int mvolt)
>> +{
>> + int cfg = (mvolt - 700) / 25;
>> +
>> + if (cfg < 0)
>> + cfg = 0;
>> + if (cfg > 127)
>> + cfg = 127;
>> + if (mvolt == -1)
>> + cfg = 0x80; /* detemined by LDO3IN pin */
>
> "determined"
Fixed.
>
>> +
>> + return axp209_write(AXP209_LDO3_VOLTAGE, cfg);
>> +}
>> +
>> +int axp209_set_ldo4(int mvolt)
>> +{
>> + int cfg, rc;
>> + static const int vindex[] = {
>> + 1250, 1300, 1400, 1500, 1600, 1700, 1800, 1900, 2000, 2500,
>> + 2700, 2800, 3000, 3100, 3200, 3300
>> + };
>> + u8 reg;
>> +
>> + /* Translate mvolt to register cfg value, requested <= selected */
>> + for (cfg = 15; vindex[cfg] > mvolt && cfg > 0; cfg--);
>> +
>> + rc = axp209_read(AXP209_LDO24_VOLTAGE, ®);
>> + if (rc)
>> + return rc;
>> +
>> + /* LDO4 configuration is in lower 4 bits */
>> + reg = (reg & 0xf0) | (cfg << 0);
>> + rc = axp209_write(AXP209_LDO24_VOLTAGE, reg);
>> + if (rc)
>> + return rc;
>> +
>> + return 0;
>> +}
>> +
>> +void axp209_poweroff(void)
>> +{
>> + u8 val;
>> +
>> + if (axp209_read(AXP209_SHUTDOWN, &val) != 0)
>> + return;
>> +
>> + val |= 1 << 7;
>
> #define?
Fixed.
Regards,
Hans
next prev parent reply other threads:[~2014-06-03 17:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 9:06 [U-Boot] sunxi: Bug fixes, sun4i and sun5i support, pmic support and network improvements Hans de Goede
2014-05-30 9:06 ` [U-Boot] [PATCH 01/12] sunxi: mksunxiboot: Fix loading of files with a size which is not a multiple of 4 Hans de Goede
2014-05-30 9:19 ` Ian Campbell
2014-07-23 17:29 ` Siarhei Siamashka
2014-07-23 17:40 ` Ian Campbell
2014-07-23 18:30 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 02/12] sunxi: Fix u-boot-spl.lds to refer to .vectors Hans de Goede
2014-05-30 9:20 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 03/12] sunxi: Remove mmc DMA support Hans de Goede
2014-05-30 9:22 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 04/12] sunxi: Implement reset_cpu Hans de Goede
2014-05-30 9:48 ` Ian Campbell
2014-05-30 13:21 ` Hans de Goede
2014-05-30 9:06 ` [U-Boot] [PATCH 05/12] sunxi: Add sun4i support Hans de Goede
2014-05-31 16:46 ` Ian Campbell
2014-06-01 9:54 ` Hans de Goede
2014-05-30 9:06 ` [U-Boot] [PATCH 06/12] sunxi: Add sun5i support Hans de Goede
2014-05-31 16:51 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 07/12] sunxi: Add i2c support Hans de Goede
2014-05-31 16:53 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 08/12] sunxi: Add axp209 pmic support Hans de Goede
2014-05-31 17:08 ` Ian Campbell
2014-06-03 17:12 ` Hans de Goede [this message]
2014-05-30 9:06 ` [U-Boot] [PATCH 09/12] sunxi: Add axp152 " Hans de Goede
2014-05-31 17:10 ` Ian Campbell
2014-06-03 17:31 ` Hans de Goede
2014-05-30 9:06 ` [U-Boot] [PATCH 10/12] net: Rename and cleanup sunxi (Allwinner) emac driver Hans de Goede
2014-05-31 17:19 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 11/12] sunxi: enable emac for sun4i Hans de Goede
2014-05-31 17:20 ` Ian Campbell
2014-05-30 9:06 ` [U-Boot] [PATCH 12/12] sunxi: Add support for using MII phy-s with the GMAC nic Hans de Goede
2014-05-30 10:26 ` Ian Campbell
2014-05-30 13:18 ` Hans de Goede
2014-05-31 9:51 ` Ian Campbell
2014-05-31 9:59 ` Ian Campbell
2014-05-31 11:45 ` Hans de Goede
2014-05-31 12:13 ` Ian Campbell
2014-05-31 14:08 ` Hans de Goede
2014-05-31 14:25 ` Ian Campbell
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=538E01FD.8040502@redhat.com \
--to=hdegoede@redhat.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.