[linux-sunxi] Re: [PATCH v5 3/7] drm: sun4i: dsi: Convert to bridge driver
Hi Jagan
@@ -1503,28 +1506,18 @@ static int samsung_dsim_panel_or_bridge(struct
samsung_dsim *dsi,
{
struct drm_bridge *panel_bridge;
struct drm_panel *panel;
- struct device_node *remote;
-
- if (of_graph_is_present(node)) {
- remote = of_graph_get_remote_node(node, DSI_PORT_OUT, 0);
- if (!remote)
- return -ENODEV;
+ int ret;
- node = remote;
- }
+ ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, &panel,
+ &panel_bridge);
+ if (ret)
+ return ret;
- panel_bridge = of_drm_find_bridge(node);
- if (!panel_bridge) {
- panel = of_drm_find_panel(node);
- if (!IS_ERR(panel)) {
- panel_bridge = drm_panel_bridge_add(panel);
- if (IS_ERR(panel_bridge))
- return PTR_ERR(panel_bridge);
- }
+ if (panel) {
+ panel_bridge = drm_panel_bridge_add(panel);
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
}
-
- of_node_put(node);
-
dsi->out_bridge = panel_bridge;
I need to apply this change to register my panel on imx8mn even mode I
found that
@@ -1594,11 +1587,15 @@ static int samsung_dsim_host_attach(struct
mipi_dsi_host *host,
return ret;
}
- mutex_lock(&drm->mode_config.mutex);
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
+
+ if (!drm)
+ return 0;
+
+ mutex_lock(&drm->mode_config.mutex);
mode_config is not initialized in this path.
Michael
On Tue, Nov 30, 2021 at 8:39 AM Jagan Teki wrote:
>
> On Fri, Nov 26, 2021 at 9:34 PM Maxime Ripard wrote:
> >
> > On Thu, Nov 25, 2021 at 09:44:14PM +0530, Jagan Teki wrote:
> > > On Thu, Nov 25, 2021 at 9:40 PM Maxime Ripard wrote:
> > > >
> > > > On Thu, Nov 25, 2021 at 07:55:41PM +0530, Jagan Teki wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, Nov 25, 2021 at 7:45 PM Maxime Ripard
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Nov 24, 2021 at 12:02:47AM +0530, Jagan Teki wrote:
> > > > > > > > > > > > + dsi->panel = of_drm_find_panel(remote);
> > > > > > > > > > > > + if (IS_ERR(dsi->panel)) {
> > > > > > > > > > > > + dsi->panel = NULL;
> > > > > > > > > > > > +
> > > > > > > > > > > > + dsi->next_bridge =
> > > > > > > > > > > > of_drm_find_bridge(remote);
> > > > > > > > > > > > + if (IS_ERR(dsi->next_bridge)) {
> > > > > > > > > > > > + dev_err(dsi->dev, "failed to find
> > > > > > > > > > > > bridge\n");
> > > > > > > > > > > > + return PTR_ERR(dsi->next_bridge);
> > > > > > > > > > > > + }
> > > > > > > > > > > > + } else {
> > > > > > > > > > > > + dsi->next_bridge = NULL;
> > > > > > > > > > > > + }
> > > > > > > > > > > > +
> > > > > > > > > > > > + of_node_put(remote);
> > > > > > > > > > >
> > > > > > > > > > > Using devm_drm_of_get_bridge would greatly simplify the
> > > > > > > > > > > driver
> > > > > > > > > >
> > > > > > > > > > I'm aware of this and this would break the existing sunxi
> > > > > > > > > > dsi binding,
> > > > > > > > > > we are not using ports based pipeline in dsi node.
> > > > > > > > > > Of-course you have
> > > > > > > > > > pointed the same before, please check below
> > > > > > > > > > https://patchwork.kernel.org/project/dri-devel/patch/20210322140152.101709-2-ja...@amarulasolutions.com/
> > > > > > > > >
> > > > > > > > > Then drm_of_find_panel_or_bridge needs to be adjusted to
> > > > > > > >
[linux-sunxi] Re: [PATCH v2 3/3] video: sunxi_display: Convert to DM_VIDEO
le(lcdc, sunxi_display.depth);
> > > + lcdc_enable(lcdc, sunxi_display->depth);
> > > sunxi_hdmi_enable();
> > > #endif
> > > break;
> > > @@ -930,7 +947,7 @@ static void sunxi_mode_set(const struct
> > > ctfb_res_modes *mode,
> > > axp_set_eldo(3, 1800);
> > > anx9804_init(CONFIG_VIDEO_LCD_I2C_BUS, 4,
> > >ANX9804_DATA_RATE_1620M,
> > > - sunxi_display.depth);
> > > + sunxi_display->depth);
> > > }
> > > if (IS_ENABLED(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM)) {
> > > mdelay(50); /* Wait for lcd controller power on */
> > > @@ -942,10 +959,10 @@ static void sunxi_mode_set(const struct
> > > ctfb_res_modes *mode,
> > > i2c_reg_write(0x5c, 0x04, 0x42); /* Turn on the LCD
> > > */
> > > i2c_set_bus_num(orig_i2c_bus);
> > > }
> > > - sunxi_composer_mode_set(mode, address);
> > > - sunxi_lcdc_tcon0_mode_set(mode, false);
> > > + sunxi_composer_mode_set(mode, address, monitor);
> > > + sunxi_lcdc_tcon0_mode_set(sunxi_display, mode, false);
> > > sunxi_composer_enable();
> > > - lcdc_enable(lcdc, sunxi_display.depth);
> > > + lcdc_enable(lcdc, sunxi_display->depth);
> > > #ifdef CONFIG_VIDEO_LCD_SSD2828
> > > sunxi_ssd2828_init(mode);
> > > #endif
> > > @@ -953,17 +970,17 @@ static void sunxi_mode_set(const struct
> > > ctfb_res_modes *mode,
> > > break;
> > > case sunxi_monitor_vga:
> > > #ifdef CONFIG_VIDEO_VGA
> > > - sunxi_composer_mode_set(mode, address);
> > > - sunxi_lcdc_tcon1_mode_set(mode, &clk_div, &clk_double, 1);
> > > - sunxi_tvencoder_mode_set();
> > > + sunxi_composer_mode_set(mode, address, monitor);
> > > + sunxi_lcdc_tcon1_mode_set(mode, &clk_div, &clk_double, 1,
> > > monitor);
> > > + sunxi_tvencoder_mode_set(monitor);
> > > sunxi_composer_enable();
> > > - lcdc_enable(lcdc, sunxi_display.depth);
> > > + lcdc_enable(lcdc, sunxi_display->depth);
> > > tvencoder_enable(tve);
> > > #elif defined CONFIG_VIDEO_VGA_VIA_LCD
> > > - sunxi_composer_mode_set(mode, address);
> > > - sunxi_lcdc_tcon0_mode_set(mode, true);
> > > + sunxi_composer_mode_set(mode, address, monitor);
> > > + sunxi_lcdc_tcon0_mode_set(sunxi_display, mode, true);
> > > sunxi_composer_enable();
> > > - lcdc_enable(lcdc, sunxi_display.depth);
> > > + lcdc_enable(lcdc, sunxi_display->depth);
> > > sunxi_vga_external_dac_enable();
> > > #endif
> > > break;
> > > @@ -972,11 +989,11 @@ static void sunxi_mode_set(const struct
> > > ctfb_res_modes *mode,
> > > case sunxi_monitor_composite_pal_m:
> > > case sunxi_monitor_composite_pal_nc:
> > > #ifdef CONFIG_VIDEO_COMPOSITE
> > > - sunxi_composer_mode_set(mode, address);
> > > - sunxi_lcdc_tcon1_mode_set(mode, &clk_div, &clk_double, 0);
> > > - sunxi_tvencoder_mode_set();
> > > + sunxi_composer_mode_set(mode, address, monitor);
> > > + sunxi_lcdc_tcon1_mode_set(mode, &clk_div, &clk_double, 0,
> > > monitor);
> > > + sunxi_tvencoder_mode_set(monitor);
> > > sunxi_composer_enable();
> > > - lcdc_enable(lcdc, sunxi_display.depth);
> > > + lcdc_enable(lcdc, sunxi_display->depth);
> > > tvencoder_enable(tve);
> > > #endif
> > > break;
> > > @@ -999,11 +1016,6 @@ static const char *sunxi_get_mon_desc(enum
> > > sunxi_monitor monitor)
> > > }
> > > }
> > >
> > > -ulong board_get_usable_ram_top(ulong total_size)
> > > -{
> > > - return gd->ram_top - CONFIG_SUNXI_MAX_FB_SIZE;
> > > -}
> > > -
> >
> > I couldn't find how you're allocating and reserving the video buff
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime On Wed, Aug 28, 2019 at 3:03 PM Maxime Ripard wrote: > > Hi, > > On Thu, Aug 15, 2019 at 02:25:57PM +0200, Michael Nazzareno Trimarchi wrote: > > On Tue, Aug 13, 2019 at 8:05 AM Maxime Ripard > > wrote: > > > On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi > > > wrote: > > > > Hi > > > > > > > > On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard > > > > wrote: > > > > > > > > > > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote: > > > > > > Hi Maxime, > > > > > > > > > > > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote: > > > > > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno > > > > > > > > > Trimarchi wrote: > > > > > > > > > > > > tcon-pixel clock is the rate that you want to achive on > > > > > > > > > > > > display side > > > > > > > > > > > > and if you have 4 lanes 32bit or lanes and different > > > > > > > > > > > > bit number that > > > > > > > > > > > > you need to have a clock that is able to put outside > > > > > > > > > > > > bits and speed > > > > > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a > > > > > > > > > > > > pixel-clock of > > > > > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have > > > > > > > > > > > > a clock of > > > > > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done > > > > > > > > > > > > but most of > > > > > > > > > > > > the display. > > > > > > > > > > > > > > > > > > > > > > So this is what the issue is then? > > > > > > > > > > > > > > > > > > > > > > This one does make sense, and you should just change the > > > > > > > > > > > rate in the > > > > > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu. > > > > > > > > > > > > > > > > > > > > > > I'm still wondering why that hasn't been brought up in > > > > > > > > > > > either the > > > > > > > > > > > discussion or the commit log before though. > > > > > > > > > > > > > > > > > > > > > Something like this? > > > > > > > > > > > > > > > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 > > > > > > > > > > +++- > > > > > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 -- > > > > > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-) > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > index 64c43ee6bd92..42560d5c327c 100644 > > > > > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > > > > > > @@ -263,10 +263,11 @@ static int > > > > > > > > > > sun4i_tcon_get_clk_delay(const struct > > > > > > > > > > drm_display_mode *mode, > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon > > > > > > > > > > *tcon, > > > > > > > > > > - const struct > > > > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime
On Tue, Aug 13, 2019 at 8:05 AM Maxime Ripard wrote:
>
> On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > > Hi Maxime,
> > > >
> > > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > > > wrote:
> > > > >
> > > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno
> > > > > > > Trimarchi wrote:
> > > > > > > > > > tcon-pixel clock is the rate that you want to achive on
> > > > > > > > > > display side
> > > > > > > > > > and if you have 4 lanes 32bit or lanes and different bit
> > > > > > > > > > number that
> > > > > > > > > > you need to have a clock that is able to put outside bits
> > > > > > > > > > and speed
> > > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a
> > > > > > > > > > pixel-clock of
> > > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a
> > > > > > > > > > clock of
> > > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but
> > > > > > > > > > most of
> > > > > > > > > > the display.
> > > > > > > > >
> > > > > > > > > So this is what the issue is then?
> > > > > > > > >
> > > > > > > > > This one does make sense, and you should just change the rate
> > > > > > > > > in the
> > > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > > > >
> > > > > > > > > I'm still wondering why that hasn't been brought up in either
> > > > > > > > > the
> > > > > > > > > discussion or the commit log before though.
> > > > > > > > >
> > > > > > > > Something like this?
> > > > > > > >
> > > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const
> > > > > > > > struct
> > > > > > > > drm_display_mode *mode,
> > > > > > > > }
> > > > > > > >
> > > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon
> > > > > > > > *tcon,
> > > > > > > > - const struct
> > > > > > > > drm_display_mode *mode)
> > > > > > > > + const struct
> > > > > > > > drm_display_mode *mode,
> > > > > > > > + u32 tcon_mul)
> > > > > > > > {
> > > > > > > > /* Configure the dot clock */
> > > > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul *
> > > > > > > > 1000);
> > > > > > > >
> > > > > > > > /* Set the resolution */
> > > > > > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime
On Mon, Jul 29, 2019 at 8:59 AM Michael Nazzareno Trimarchi
wrote:
>
> Hi
>
> On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> wrote:
> >
> > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > Hi Maxime,
> > >
> > > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno
> > > > > > Trimarchi wrote:
> > > > > > > > > tcon-pixel clock is the rate that you want to achive on
> > > > > > > > > display side
> > > > > > > > > and if you have 4 lanes 32bit or lanes and different bit
> > > > > > > > > number that
> > > > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > > > speed
> > > > > > > > > equal to pixel-clock * bits / lanes. so If you want a
> > > > > > > > > pixel-clock of
> > > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a
> > > > > > > > > clock of
> > > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but
> > > > > > > > > most of
> > > > > > > > > the display.
> > > > > > > >
> > > > > > > > So this is what the issue is then?
> > > > > > > >
> > > > > > > > This one does make sense, and you should just change the rate
> > > > > > > > in the
> > > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > > >
> > > > > > > > I'm still wondering why that hasn't been brought up in either
> > > > > > > > the
> > > > > > > > discussion or the commit log before though.
> > > > > > > >
> > > > > > > Something like this?
> > > > > > >
> > > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const
> > > > > > > struct
> > > > > > > drm_display_mode *mode,
> > > > > > > }
> > > > > > >
> > > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > > > - const struct
> > > > > > > drm_display_mode *mode)
> > > > > > > + const struct
> > > > > > > drm_display_mode *mode,
> > > > > > > + u32 tcon_mul)
> > > > > > > {
> > > > > > > /* Configure the dot clock */
> > > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul *
> > > > > > > 1000);
> > > > > > >
> > > > > > > /* Set the resolution */
> > > > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > > sun4i_tcon *tcon,
> > > > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > > > u8 lanes = device->lanes;
> > > > > > > u32 block_space, start_delay;
> > > > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi
On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
wrote:
>
> On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > wrote:
> > >
> > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > > wrote:
> > > > >
> > > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > > > wrote:
> > > > > > > > tcon-pixel clock is the rate that you want to achive on display
> > > > > > > > side
> > > > > > > > and if you have 4 lanes 32bit or lanes and different bit number
> > > > > > > > that
> > > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > > speed
> > > > > > > > equal to pixel-clock * bits / lanes. so If you want a
> > > > > > > > pixel-clock of
> > > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock
> > > > > > > > of
> > > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but
> > > > > > > > most of
> > > > > > > > the display.
> > > > > > >
> > > > > > > So this is what the issue is then?
> > > > > > >
> > > > > > > This one does make sense, and you should just change the rate in
> > > > > > > the
> > > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > > >
> > > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > > discussion or the commit log before though.
> > > > > > >
> > > > > > Something like this?
> > > > > >
> > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const
> > > > > > struct
> > > > > > drm_display_mode *mode,
> > > > > > }
> > > > > >
> > > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > > - const struct
> > > > > > drm_display_mode *mode)
> > > > > > + const struct
> > > > > > drm_display_mode *mode,
> > > > > > + u32 tcon_mul)
> > > > > > {
> > > > > > /* Configure the dot clock */
> > > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul *
> > > > > > 1000);
> > > > > >
> > > > > > /* Set the resolution */
> > > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > > sun4i_tcon *tcon,
> > > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > > u8 lanes = device->lanes;
> > > > > > u32 block_space, start_delay;
> > > > > > - u32 tcon_div;
> > > > > > + u32 tcon_div, tcon_mul;
> > > > > >
> > > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > > + tcon->dclk_min_div = 4;
> > > > > > + tcon->dclk_max_div = 127;
> > > > > >
> > > > > > -
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Jagan
On Mon, Jul 22, 2019 at 12:21 PM Jagan Teki wrote:
>
> Hi Maxime,
>
> On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> wrote:
> >
> > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > > wrote:
> > > > > > > tcon-pixel clock is the rate that you want to achive on display
> > > > > > > side
> > > > > > > and if you have 4 lanes 32bit or lanes and different bit number
> > > > > > > that
> > > > > > > you need to have a clock that is able to put outside bits and
> > > > > > > speed
> > > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock
> > > > > > > of
> > > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most
> > > > > > > of
> > > > > > > the display.
> > > > > >
> > > > > > So this is what the issue is then?
> > > > > >
> > > > > > This one does make sense, and you should just change the rate in the
> > > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > > >
> > > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > > discussion or the commit log before though.
> > > > > >
> > > > > Something like this?
> > > > >
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > > drm_display_mode *mode,
> > > > > }
> > > > >
> > > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > > - const struct drm_display_mode
> > > > > *mode)
> > > > > + const struct drm_display_mode
> > > > > *mode,
> > > > > + u32 tcon_mul)
> > > > > {
> > > > > /* Configure the dot clock */
> > > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > > >
> > > > > /* Set the resolution */
> > > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > > u8 lanes = device->lanes;
> > > > > u32 block_space, start_delay;
> > > > > - u32 tcon_div;
> > > > > + u32 tcon_div, tcon_mul;
> > > > >
> > > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > > + tcon->dclk_min_div = 4;
> > > > > + tcon->dclk_max_div = 127;
> > > > >
> > > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > > + tcon_mul = bpp / lanes;
> > > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > > >
> > > > > /* Set dithering if needed */
> > > > > sun4i_tcon0_mode_set_dithering(tcon,
> > > > > sun4i_tcon_get_connector(encoder));
> > > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > > sun4i_tcon *tcon,
> > > > > */
> > &
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi
On Sat, Jul 20, 2019 at 11:32 AM Maxime Ripard
wrote:
>
> On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > On Sat, Jul 20, 2019 at 12:28 PM Maxime Ripard
> > wrote:
> > >
> > > On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> > > wrote:
> > > > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > > > you need to have a clock that is able to put outside bits and speed
> > > > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > > > the display.
> > > > >
> > > > > So this is what the issue is then?
> > > > >
> > > > > This one does make sense, and you should just change the rate in the
> > > > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > > > >
> > > > > I'm still wondering why that hasn't been brought up in either the
> > > > > discussion or the commit log before though.
> > > > >
> > > > Something like this?
> > > >
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > > > 2 files changed, 11 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > index 64c43ee6bd92..42560d5c327c 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > > > drm_display_mode *mode,
> > > > }
> > > >
> > > > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > > > - const struct drm_display_mode
> > > > *mode)
> > > > + const struct drm_display_mode
> > > > *mode,
> > > > + u32 tcon_mul)
> > > > {
> > > > /* Configure the dot clock */
> > > > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > > > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> > > >
> > > > /* Set the resolution */
> > > > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > > > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > sun4i_tcon *tcon,
> > > > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > > > u8 lanes = device->lanes;
> > > > u32 block_space, start_delay;
> > > > - u32 tcon_div;
> > > > + u32 tcon_div, tcon_mul;
> > > >
> > > > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > > > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > > > + tcon->dclk_min_div = 4;
> > > > + tcon->dclk_max_div = 127;
> > > >
> > > > - sun4i_tcon0_mode_set_common(tcon, mode);
> > > > + tcon_mul = bpp / lanes;
> > > > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> > > >
> > > > /* Set dithering if needed */
> > > > sun4i_tcon0_mode_set_dithering(tcon,
> > > > sun4i_tcon_get_connector(encoder));
> > > > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > > > sun4i_tcon *tcon,
> > > > */
> > > > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > > > tcon_div &= GENMASK(6, 0);
> > > > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > > > + block_space = mode->htotal * tcon_div * tcon_mul;
> > > > block_space -= mode->hdisplay + 40;
> > > >
> > > > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > > > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > > > sun4i_tcon *tcon,
> > > >
> > > >
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi
On Sat., 20 Jul. 2019, 8:58 am Maxime Ripard,
wrote:
> On Thu, Jul 11, 2019 at 07:43:16PM +0200, Michael Nazzareno Trimarchi
> wrote:
> > > > tcon-pixel clock is the rate that you want to achive on display side
> > > > and if you have 4 lanes 32bit or lanes and different bit number that
> > > > you need to have a clock that is able to put outside bits and speed
> > > > equal to pixel-clock * bits / lanes. so If you want a pixel-clock of
> > > > 40 mhz and you have 32bits and 4 lanes you need to have a clock of
> > > > 40 * 32 / 4 in no-burst mode. I think that this is done but most of
> > > > the display.
> > >
> > > So this is what the issue is then?
> > >
> > > This one does make sense, and you should just change the rate in the
> > > call to clk_set_rate in sun4i_tcon0_mode_set_cpu.
> > >
> > > I'm still wondering why that hasn't been brought up in either the
> > > discussion or the commit log before though.
> > >
> > Something like this?
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +++-
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 --
> > 2 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index 64c43ee6bd92..42560d5c327c 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -263,10 +263,11 @@ static int sun4i_tcon_get_clk_delay(const struct
> > drm_display_mode *mode,
> > }
> >
> > static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > - const struct drm_display_mode
> *mode)
> > + const struct drm_display_mode
> *mode,
> > + u32 tcon_mul)
> > {
> > /* Configure the dot clock */
> > - clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
> > + clk_set_rate(tcon->dclk, mode->crtc_clock * tcon_mul * 1000);
> >
> > /* Set the resolution */
> > regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
> > @@ -335,12 +336,13 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > sun4i_tcon *tcon,
> > u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> > u8 lanes = device->lanes;
> > u32 block_space, start_delay;
> > - u32 tcon_div;
> > + u32 tcon_div, tcon_mul;
> >
> > - tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> > - tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
> > + tcon->dclk_min_div = 4;
> > + tcon->dclk_max_div = 127;
> >
> > - sun4i_tcon0_mode_set_common(tcon, mode);
> > + tcon_mul = bpp / lanes;
> > + sun4i_tcon0_mode_set_common(tcon, mode, tcon_mul);
> >
> > /* Set dithering if needed */
> > sun4i_tcon0_mode_set_dithering(tcon,
> sun4i_tcon_get_connector(encoder));
> > @@ -366,7 +368,7 @@ static void sun4i_tcon0_mode_set_cpu(struct
> > sun4i_tcon *tcon,
> > */
> > regmap_read(tcon->regs, SUN4I_TCON0_DCLK_REG, &tcon_div);
> > tcon_div &= GENMASK(6, 0);
> > - block_space = mode->htotal * bpp / (tcon_div * lanes);
> > + block_space = mode->htotal * tcon_div * tcon_mul;
> > block_space -= mode->hdisplay + 40;
> >
> > regmap_write(tcon->regs, SUN4I_TCON0_CPU_TRI0_REG,
> > @@ -408,7 +410,7 @@ static void sun4i_tcon0_mode_set_lvds(struct
> > sun4i_tcon *tcon,
> >
> > tcon->dclk_min_div = 7;
> > tcon->dclk_max_div = 7;
> > - sun4i_tcon0_mode_set_common(tcon, mode);
> > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> >
> > /* Set dithering if needed */
> > sun4i_tcon0_mode_set_dithering(tcon,
> sun4i_tcon_get_connector(encoder));
> > @@ -487,7 +489,7 @@ static void sun4i_tcon0_mode_set_rgb(struct
> > sun4i_tcon *tcon,
> >
> > tcon->dclk_min_div = 6;
> > tcon->dclk_max_div = 127;
> > - sun4i_tcon0_mode_set_common(tcon, mode);
> > + sun4i_tcon0_mode_set_common(tcon, mode, 1);
> >
> > /* Set dithering if needed */
> > sun4i_tcon0_mode_set_dithering(tcon, connector);
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> > index 5c3ad5be0690..a07090579f84 100644
> > --- a/drivers
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi On Thu, Jul 11, 2019 at 7:43 PM Michael Nazzareno Trimarchi wrote: > > Hi Maxime > > On Thu, Jul 11, 2019 at 2:23 PM Maxime Ripard > wrote: > > > > On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > > > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > > > wrote: > > > > > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > > > instead of having > > > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might > > > > > > > > > > > > be a bug in > > > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > > > generated from > > > > > > > > > > > > the pixel clock, and it indeed looks like the ratio > > > > > > > > > > > > between the pixel > > > > > > > > > > > > clock and the TCON dotclock is defined through the > > > > > > > > > > > > number of bits per > > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same > > > > > > > > > > > > than lcd_rate, > > > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > > > dsi_rate == > > > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 > > > > > > > > > > > > MHz. Indeed, if > > > > > > > > > > > > we look at: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > > > different than > > > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, > > > > > > > > > > > > in the case of a > > > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/d
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime On Thu, Jul 11, 2019 at 2:23 PM Maxime Ripard wrote: > > On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > > wrote: > > > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > > instead of having > > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might be > > > > > > > > > > > a bug in > > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > > generated from > > > > > > > > > > > the pixel clock, and it indeed looks like the ratio > > > > > > > > > > > between the pixel > > > > > > > > > > > clock and the TCON dotclock is defined through the number > > > > > > > > > > > of bits per > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same than > > > > > > > > > > > lcd_rate, > > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > > dsi_rate == > > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 MHz. > > > > > > > > > > > Indeed, if > > > > > > > > > > > we look at: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > > different than > > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, in > > > > > > > > > > > the case of a > > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 > > > > > > > > > > > > > > > > > > > > Let me explain, something more. > > > > > > > > > > > > > > > > > > > > According to bsp there are clk_info.tcon_div which I will > > > > > > > > > > ex
[linux-sunxi] Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
t; > > > > > > > there > > > > > > > > is no dynamic way of doing this BSP hard-coding these values. > > > > > > > > > > > > > > > > Patches 5,6,7 on this series doing this > > > > > > > > https://patchwork.freedesktop.org/series/60847/ > > > > > > > > > > > > > > > > Hope this explanation helps? > > > > > > > > > > > > > > It doesn't. > > > > > > > > > > > > > > The clock tree is this one: > > > > > > > > > > > > > > PLL(s) -> TCON module clock -> TCON dotclock. > > > > > > > > > > > > > > The links I mentioned above show that the clock set to lcd_rate > > > > > > > is the > > > > > > > TCON module clocks (and it should be the one taking the bpp and > > > > > > > lanes > > > > > > > into account), while the TCON dotclock uses a fixed divider of 4. > > > > > > > > > > > > Sorry, I can argue much other-than giving some code snips, > > > > > > according to [1] > > > > > > > > > > > > 00) Line 785, 786 with dclk_rate 14800 > > > > > > > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > > > > pll_rate = lcd_rate * clk_info.lcd_div; > > > > > > > > > > > > Since dsi_div is 6 (bpp/lanes), lcd_div 1 > > > > > > > > > > > > lcd_rate = 88800, pll_rate = 88800 > > > > > > > > > > > > 01) Line 801, 804 are final rates computed as per clock driver (say > > > > > > ccu_nkm in mainline) > > > > > > > > > > > > lcd_rate_set=89100 > > > > > > > > > > > > As per your comments if it would be 4 then the desired numbers are > > > > > > would be 59200 not 88800. > > > > > > > > > > > > This is what I'm trying to say in all mails, and same as verified > > > > > > with > > > > > > 2-lanes devices as well where the dsi_div is 12 so the final rate is > > > > > > 290MHz * 12 > > > > > > > > > > In the code you sent, you're forcing a divider on the internal TCON > > > > > clock, while that one is fixed in the BSP. > > > > > > > > > > There's indeed the bpp / lanes divider, but it's used in the *parent* > > > > > clock of the one you're changing. > > > > > > > > > > And the dsi0_clk clock you pointed out in the code snippet is yet > > > > > another clock, the MIPI DSI module clock. > > > > > > > > Correct, look like I refereed wrong reference in the above mail. sorry > > > > for the noise. > > > > > > > > Actually I'm trying to explain about pll_rate here which indeed > > > > depends on dsi.div > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L786 > > > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > > pll_rate = lcd_rate * clk_info.lcd_div; > > > > > > > > Say > > > > > > > > 1) For 148MHz dclk_rate with dsi_div is 6 (24/4) lcd_div is 1 which > > > > resulting pll_rate is 888MHz. > > > > > > > > 2) For 30MHz dclk_rate with 4 lane and 24 RGB the resulting pll_rate is > > > > 180MHz > > > > > > > > 3) For 27.5MHz dclk_rate with 2 lane and 24 RGB the resulting pll_rate > > > > is 330MHz > > > > > > > > Here is the few more logs in code, for case 2) > > > > > > > > [1.920441] sun4i_dclk_round_rate: min_div = 6 max_div = 6, rate = > > > > 3000 > > > > [1.920505] ideal = 18000, rounded = 17820 > > > > [1.920509] sun4i_dclk_round_rate: div = 6 rate = 2970 > > > > [1.920514] sun4i_dclk_round_rate: min_div = 6 max_div = 6, rate = > > > > 3000 > > > > [1.920532] ideal = 1800ls and one DSI-RGB bridge. All of them do use > > PLL_MIPI (pll_rate) and it indeed depends on bpp/lanes > >0, rounded = 17820 > > > > [1.920535] sun4i_dclk_round_rate: div = 6 rate = 297
[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN
Hi Maxime
On Tue, May 21, 2019 at 10:10 AM Maxime Ripard
wrote:
>
> On Tue, May 21, 2019 at 08:47:02AM +0200, Michael Nazzareno Trimarchi wrote:
> > > > + };
> > > > +
> > > > };
> > > >
> > > > &ehci0 {
> > > > @@ -77,6 +95,31 @@
> > > > status = "okay";
> > > > };
> > > >
> > > > +&pio {
> > > > + can_pins: can-pins {
> > > > + pins = "PD6", /* RX_BUF1_CAN0 */
> > > > +"PD7"; /* RX_BUF0_CAN0 */
> > > > + function = "gpio_in";
> > > > + };
> > > > +};
> > >
> > > That isn't needed. What are they used for, you're not tying them to
> > > anything?
> >
> > Mux of their function is correct. They are connected in the schematics
> > but not used right now.
>
> Then describe the whole thing or don't?
>
Ok
> And that's kind of missing my point. If that pin group isn't related
> to any device, the pin muxing will not be changed. So that group, in
> itself, has strictly no effect.
>
> Moreover, you don't need a pin group in the first place to mux pins in
> GPIOs, the GPIO API will make sure that is the case when you request
> it.
This is correct on sunxi. Is this valid for sunxi or in general in all the SoC?
Anyway make sense to have pins configured and place in the right
state, just suppose if the
booting stage is wrong or anything that make those pins in the wrong
configuration
>
> > I can garantee that kernel wlll always configurred in the right way
> > and if I want I can export in userspace
> > for debug purpose
Correct if you start to use it but if you want them right configured
the right place
is in the default state e/o initstate if this can be a problem of the hardware
Default state: the state the pinctrl handle shall be put
* into as default, usually this means the pins are up and ready to
* be used by the device driver. This state is commonly used by
* hogs to configure muxing and pins at boot, and also as a state
* to go into when returning from sleep and idle in
* .pm_runtime_resume() or ordinary .resume() for example.
Now the pins are connected to the canbus as should be and they are
configured and usually
put in the right state.
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&can_pins>;
>
> Yes, because the API does it, not your change
>
Do you prefer to drop the pinmux? or update the commit message
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAOf5uwnhXjur%3D2NezCydaCxP5d33S%2BAwdD9WTDtp2EUJr4UTgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN
Hi Maxime
On Thu, Apr 18, 2019 at 4:56 PM Maxime Ripard wrote:
>
> On Thu, Apr 18, 2019 at 07:46:58PM +0530, Jagan Teki wrote:
> > Oceanic 5205 5inMFD has MCP2515 CAN device connected via SPI1.
> >
> > - via SPI1 bus
> > - vdd supplied by 5V supply along with PL2 enable pin
> > - xceiver supply same as vdd
> > - can oscillator connected at 20MHz
> > - PB2 gpio as interrupt pin
> > - PD6 gpio as RX_BUF1_CAN0
> > - PD7 gpio as RX_BUF0_CAN0
> >
> > Tested-by: Tamas Papp
> > Signed-off-by: Jagan Teki
> > ---
> > .../sun50i-a64-oceanic-5205-5inmfd.dts| 43 +++
> > 1 file changed, 43 insertions(+)
> >
> > diff --git
> > a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > index f0cd6587f619..22535a297f51 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
> > @@ -21,6 +21,24 @@
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
> > +
> > + can_osc: can-osc {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <2000>;
> > + };
> > +
> > + reg_can_v5v: reg-can-v5v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "reg-can-v5v";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + regulator-boot-on;
> > + enable-active-high;
> > + gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* CAN_3V3_EN: PL2 */
> > + status = "okay";
>
> You don't need the status property here.
>
Correct, need to be dropped
> > + };
> > +
> > };
> >
> > &ehci0 {
> > @@ -77,6 +95,31 @@
> > status = "okay";
> > };
> >
> > +&pio {
> > + can_pins: can-pins {
> > + pins = "PD6", /* RX_BUF1_CAN0 */
> > +"PD7"; /* RX_BUF0_CAN0 */
> > + function = "gpio_in";
> > + };
> > +};
>
> That isn't needed. What are they used for, you're not tying them to
> anything?
Mux of their function is correct. They are connected in the schematics
but not used right now.
I can garantee that kernel wlll always configurred in the right way
and if I want I can export in userspace
for debug purpose
Michael
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAOf5uwn8CtRs8cx0KC-bxNoRP4TiDrHi8F83QfjsZhueLDYFJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Hi
On Mon, Dec 31, 2018 at 01:10:43PM +, André Przywara wrote:
> On 31/12/2018 11:27, Michael Trimarchi wrote:
> > Hi
> >
> > On Mon, Dec 31, 2018 at 11:34:51AM +0100, Olliver Schinagl wrote:
> >> Hey André,
> >>
> >> On 31-12-2018 00:23, André Przywara wrote:
> >>> On 29/12/2018 22:10, Olliver Schinagl wrote:
> >>>
> >>> Hi Olliver,
> >>>
> >>>> Luckily we have had no problem with this on our boards, but its sad to
> >>>> see this patch reverted due to the buggy ddr implementation ...
> >>>
> >>> This whole SPL is quite a sensitive construct, so moving things around
> >>> can have interesting effects. For instance try to use any .bss variables
> >>> (global variables initialised to 0) before the DRAM init.
> >>> Also especially the DRAM controller driver was written basically without
> >>> any single line of documentation. So bear with us if we didn't get
> >>> everything 100% correct.
> >> Actually, not exactly true. If you compare the DDR init with the
> >> leaked/shared boot0 I think it was called; you'll see a lot of
> >> similarities.
> >> So it's not hard to imageine it was at least inspired by boot0.
>
> Yeah, possibly. I did look at disassembly and decompilation of libdram
> myself. But still the code was not good quality, and if you look at the
> timing parameters, they don't seem to be quite right, for instance many
> values don't match the JEDEC recommendations, and on most boards we run
> DDR3-1600 chips at 672 MHz (so using 1333 timings).
> So yeah, a lot of guesswork.
>
According to my experience on A33 the idea is to use min_timing for all the
supported
frequency but even there I found some mistakes.
We need to add anyway a function to set parameters manually for all the
boards. If the problem is timing they should crash in linux too. I was looking
on get_timer and delay implementation if those can depend on cpu(s) but look
like that this is not a possibility.
Anyway without board I can not help
> >> That said, we still have no documentation, no idea who's IP it shares, so
> >> it
> >> is really still shooting in the dark here and we are just happy we have
> >> something that does work :) (albeit fragile it turns out now)
>
> Indeed. I think we have some idea on the origins of the IP (Designware),
> but that doesn't help too much, for various reasons.
>
> >>>
> >>> I actually wanted to ask you: what was your patch meaning to fix in the
> >>> first place? All the patch did was to move the DRAM init after the CPU
> >>> clock setting, which was the exact reason for the breakage.
> >>> What that power_failed check does is to avoid increasing the CPU
> >>> frequency, before and after that patch. There are no other consequences.
> >>> So the effect would be just a mere change in the order of reporting,
> >>> since we continue execution in any case.
> >>
> >> So it was cosemtic to the code. Mostly 'logical ordering'. First setup the
> >> power, CPU etc, if all that is setup properly, setup the DRAM. With the
> >> hoped side effect that with the faster running CPU init would happen faster
> >> (I guess it does but fails :).
> >>
> >> It was a little weird to first setup the DRAM and only then check if we can
> >> even setup the CPU/PLL properly ...
> >>
> >> It just made more sense to do it that way. I just realized I do have an
> >> OPie
> >> zero; so maybe I'll look into it again in a few months to see what's going
> >> wrong and where we can improve.
> >>>
> >>> So was that the only purpose of the patch? I believe that could be
> >>> better done this way, without any side effects:
> >>>
> >>> #endif
> >>> #endif
> >>>
> >>> if (power_failed)
> >>> printf("Error setting up the power controller.\n"
> >>> "CPU frequency not set.\n");
> >>> <... DRAM init ...>
> >>>
> >>> if (!power_failed)
> >>> clock_set_pll1(CONFIG_SYS_CLK_FREQ);
> >>>
> >>>
> >>>
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> > b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> > index ee387127f3..296f9d11bc 100644
> > --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> > +++ b/arch/
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Hi
On Mon, Dec 31, 2018 at 11:34:51AM +0100, Olliver Schinagl wrote:
> Hey André,
>
> On 31-12-2018 00:23, André Przywara wrote:
> > On 29/12/2018 22:10, Olliver Schinagl wrote:
> >
> > Hi Olliver,
> >
> > > Luckily we have had no problem with this on our boards, but its sad to
> > > see this patch reverted due to the buggy ddr implementation ...
> >
> > This whole SPL is quite a sensitive construct, so moving things around
> > can have interesting effects. For instance try to use any .bss variables
> > (global variables initialised to 0) before the DRAM init.
> > Also especially the DRAM controller driver was written basically without
> > any single line of documentation. So bear with us if we didn't get
> > everything 100% correct.
> Actually, not exactly true. If you compare the DDR init with the
> leaked/shared boot0 I think it was called; you'll see a lot of similarities.
> So it's not hard to imageine it was at least inspired by boot0.
>
> That said, we still have no documentation, no idea who's IP it shares, so it
> is really still shooting in the dark here and we are just happy we have
> something that does work :) (albeit fragile it turns out now)
>
> >
> > I actually wanted to ask you: what was your patch meaning to fix in the
> > first place? All the patch did was to move the DRAM init after the CPU
> > clock setting, which was the exact reason for the breakage.
> > What that power_failed check does is to avoid increasing the CPU
> > frequency, before and after that patch. There are no other consequences.
> > So the effect would be just a mere change in the order of reporting,
> > since we continue execution in any case.
>
> So it was cosemtic to the code. Mostly 'logical ordering'. First setup the
> power, CPU etc, if all that is setup properly, setup the DRAM. With the
> hoped side effect that with the faster running CPU init would happen faster
> (I guess it does but fails :).
>
> It was a little weird to first setup the DRAM and only then check if we can
> even setup the CPU/PLL properly ...
>
> It just made more sense to do it that way. I just realized I do have an OPie
> zero; so maybe I'll look into it again in a few months to see what's going
> wrong and where we can improve.
> >
> > So was that the only purpose of the patch? I believe that could be
> > better done this way, without any side effects:
> >
> > #endif
> > #endif
> >
> > if (power_failed)
> > printf("Error setting up the power controller.\n"
> >"CPU frequency not set.\n");
> > <... DRAM init ...>
> >
> > if (!power_failed)
> > clock_set_pll1(CONFIG_SYS_CLK_FREQ);
> >
> >
> >
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index ee387127f3..296f9d11bc 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -208,6 +208,7 @@ struct sunxi_ccm_reg {
#define CCM_PLL1_CTRL_N(n) n) - 1) & 0x1f) << 8)
#define CCM_PLL1_CTRL_P(n) (((n) & 0x3) << 16)
#define CCM_PLL1_CTRL_EN (0x1 << 31)
+#define CCM_PLL1_CTRL_LOCK (0x1 << 28)
#define CCM_PLL3_CTRL_M_SHIFT 0
#define CCM_PLL3_CTRL_M_MASK (0xf << CCM_PLL3_CTRL_M_SHIFT)
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
b/arch/arm/mach-sunxi/clock_sun6i.c
index 1628f3a7b6..10759b7775 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -142,6 +142,9 @@ void clock_set_pll1(unsigned int clk)
ATB_DIV_2 << ATB_DIV_SHIFT |
CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT,
&ccm->cpu_axi_cfg);
+
+ while (!(readl(&ccm->pll1_cfg) & CCM_PLL1_CTRL_LOCK))
+ ;
}
#endif
And waiting the pll1 to be lock does not change anything?
I don't have a board to test and I don't know why was not implemented
Michael
--
2.17.1
> > >
> > > Curiosity is getting the better of me and I cant seem to be able to
> > > reproduce the problem. So could you be a little bit more specific on the
> > > bug please?
> >
> > As I wrote in the commit message, the OrangePi Zero breaks straight away
> > with this patch, all of the time: 0 MB DRAM. I don't have any other
> > affected board to test on, but there were reports of more boards not
> > working as well.
> >
> > Since we shouldn't allow such drastic regressions, I believe it
[linux-sunxi] Re: [U-Boot] SPL variant of sunxi nand module
Hi On Sun, Dec 23, 2018 at 4:46 PM Nikolai Zhubr wrote: > > Hi again, > > 23.12.2018 16:29, I wrote: > > > U-Boot SPL 2019.01-rc2 (Dec 20 2018 - 16:30:46 +0300) > > > CPU: 91200Hz, AXI/AHB/APB: 3/2/2 > > > DRAM: 1024 MiB > > > Trying to boot from NAND > > > > Ok, discovered a special SPL-only sunxi_nand_spl variant, added some > debugging, so the detection is visible: > > In nand_detect_config(), start detection... > Considering addr_cycles=5, page_size=2048 > Considering ecc_size=1024, ecc_strength=0 failed(a). > Considering addr_cycles=5, page_size=2048 rejected. > Considering addr_cycles=5, page_size=4096 > Considering ecc_size=1024, ecc_strength=3 failed(a). > Considering addr_cycles=5, page_size=4096 rejected. > Considering addr_cycles=5, page_size=8192 > Considering ecc_size=1024, ecc_strength=4 good(b). > Considering addr_cycles=5, page_size=8192 accepted. > > I'm almost 100% sure that correct config would be page_size=8192, > ecc_size=1024, ecc_strength=40 (from nand chip identification structure > for regular linux kernel) That is an index on an array. Am I wrong? so the max is 74 Michael > > Now the detection routine in sunxi_nand_spl apparently comes up with a > value of ecc_strength=4 instead... Why is that? n - 1 using an index, if the code that I have is aligned so Michael > > > Thank you, > > Regards, > Nikolai > > > > > > > > Thank you, > > > > Regards, > > Nikolai > > ___ > > U-Boot mailing list > > u-b...@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > ___ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- 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 v4 0/6] media/sun6i: Allwinner A64 CSI support
Hi Maxime On Wed, Dec 19, 2018 at 11:25 AM Maxime Ripard wrote: > > On Tue, Dec 18, 2018 at 08:58:22PM +0530, Jagan Teki wrote: > > On Tue, Dec 18, 2018 at 8:51 PM Maxime Ripard > > wrote: > > > > > > On Tue, Dec 18, 2018 at 05:03:14PM +0530, Jagan Teki wrote: > > > > This series support CSI on Allwinner A64. > > > > > > > > Tested 640x480, 320x240, 720p, 1080p resolutions UYVY8_2X8 format. > > > > > > > > Changes for v4: > > > > - update the compatible string order > > > > - add proper commit message > > > > - included BPI-M64 patch > > > > - skipped amarula-a64 patch > > > > Changes for v3: > > > > - update dt-bindings for A64 > > > > - set mod clock via csi driver > > > > - remove assign clocks from dtsi > > > > - remove i2c-gpio opendrian > > > > - fix avdd and dovdd supplies > > > > - remove vcc-csi pin group supply > > > > > > > > Note: This series created on top of H3 changes [1] > > > > > > > > [1] https://patchwork.kernel.org/cover/10705905/ > > > > > > You had memory corruption before, how was this fixed? > > > > Memory corruption observed with default 600MHz on 1080p. It worked > > fine on BPI-M64 (with 300MHz) > > I don't get it. In the previous version of those patches, you were > mentionning you were still having this issue, even though you had the > clock running at 300MHz, and then you tried to convince us to merge > the patches nonetheless. > > Why would you say that then if that issue was fixed? It's simple, we have a full working platform with ov5640 that support all the resolutions, that can be test by anyone and we have an industrial product that has some problem on high xvclk because it can not give us a clear image but this is limited on another design and another camera module vendor. Problem is not in the kernel code but it's just on relic design. We are getting the information on that module and see if inside is really using the xvclk or it's clocked by some other things. We have only the schematic up to the connector. Michael > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- 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: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Hi André On Wed, Dec 19, 2018 at 2:46 AM André Przywara wrote: > > On 19/12/2018 00:51, André Przywara wrote: > > On 18/12/2018 12:06, Jagan Teki wrote: > >> On Tue, Dec 18, 2018 at 4:09 PM wrote: > >>> > >>> From: Karl Palsson > >>> > >>> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1 > >>> > >>> This causes DRAM init failures on (at least) > >>> * allwinner h3 nanopi-duo2 > >>> * allwinner h2+ orangepi zero v1.1 > >>> > >>> Signed-off-by: Karl Palsson > >>> --- > >>> > >>> Ideally, this should get into 2019.01, so that this release is not > >>> broken on those targets. > >> > >> Better to understand the issue here, since I have BPI-M2+ which boots > >> fine w/o this revert. > > > > Could this be a .bss issue? This lies in DRAM and is thus only available > > *after* DRAM init. IIRC we silently rely on not accessing anything in > > .bss before the DRAM is up, see 59d07ee08e85 for instance. > > I don't immediately spot any .bss usage in clock_set_pll1(), though. > > > > Or is the 1GHz CPU clock speed too fast for the DRAM init? If I am not > > mistaken, we run with 24MHz before, so there might be some "natural" > > delay in some setup routines. Some DRAM chips or board layout might be > > more susceptible to this than others, which might explain why it only > > fails on some boards. > > Just did some testing on my OrangePi Zero: if I force the CPU frequency > to 408 MHz, it works, but fails with the standard 1008 MHz. > So this smells that we indeed miss some delays in the DRAM setup code, > which sounds tedious to find. There are a number of delays, but those > are fine as they are timer controlled, so independent from the CPU > frequency. > > For now I think that reverting would be the easiest solution. Somewhat > in contrast to what the commit message says, we don't really change > anything in terms of error *checking*, as the code carries on anyways > (just without increasing the CPU frequency). The only real difference is > the order of CPU clock setup and DRAM init. > > Karl, can you please amend the commit message to mention the CPU > frequency issue? > > > So if the original patch is about bailing out on error early, can't we > > just do *that* before the DRAM init, keeping the CPU clock setup still > > after DRAM? > > Just checked, this works as well, but is a bit pointless. Just reverting > this and meanwhile checking the DRAM init code seems the easier solution. > Definitely have the same impression. Please send the same revert but adjust the commit message Michael > Cheers, > Andre > ___ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- 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: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
Hi Karl On Tue, Dec 18, 2018 at 7:12 PM Karl Palsson wrote: > > > Jagan Teki wrote: > > It's 4 days before, "U-Boot] sunxi: regression in dram init for > > h3 board" > > > > 7 days is not 4-days :) > > True, it was last week, not a week ago. > > > I would expect some debugging on this during these days and > > find the real root cause. > > Just so there's no unmet expectations here, I'm not doing any > _debugging_ of this. (Nor do I have any planned) Given that this > is a regression in working devices, I would _presume_ (quite > likely wrongly) that the honus of debugging this would be on the > people who suggested this patch, not people affected by it. I'm > happy to test things, but I have zero experience with dram init, > (only marginally greater than zero experience with uboot overall) > and no sane methods for debugging this further, nor enough > devices to give any test confidence that any debugging I could do > would be useful. > Do you have error after relocation or before relocation? Does it go outside and print DRAM size? Michael > Sincerely, > Karl P___ > U-Boot mailing list > u-b...@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- 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: Allwinner A64: Issue on external rtc clock to wifi chip
Hi Maxime
On Mon, May 14, 2018 at 1:17 PM, Maxime Ripard
wrote:
> On Mon, May 14, 2018 at 03:12:49PM +0530, Jagan Teki wrote:
>> On Mon, May 14, 2018 at 2:36 PM, Maxime Ripard
>> wrote:
>> > On Mon, May 14, 2018 at 02:34:22PM +0530, Jagan Teki wrote:
>> >> On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
>> >> wrote:
>> >> > On Mon, May 14, 2018 at 01:34:56PM +0530, Jagan Teki wrote:
>> >> >> On Mon, May 14, 2018 at 1:27 PM, Maxime Ripard
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
>> >> >> >> Hi Maxime and All,
>> >> >> >>
>> >> >> >> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
>> >> >> >> to have an external rtc clock has driven from wifi chip.
>> >> >> >>
>> >> >> >> So the devicetree is configured according to this as below.
>> >> >> >>
>> >> >> >> / {
>> >> >> >> wifi_pwrseq: wifi-pwrseq {
>> >> >> >> compatible = "mmc-pwrseq-simple";
>> >> >> >> clocks = <&rtc 1>;
>> >> >> >> clock-names = "ext_clock";
>> >> >> >> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2
>> >> >> >> */
>> >> >> >> post-power-on-delay-ms = <400>;
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> &rtc {
>> >> >> >> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
>> >> >> >> clocks = <&osc32k>;
>> >> >> >> #clock-cells = <1>;
>> >> >> >> };
>> >> >> >>
>> >> >> >> &mmc1 {
>> >> >> >> pinctrl-names = "default";
>> >> >> >> pinctrl-0 = <&mmc1_pins>;
>> >> >> >> vmmc-supply = <®_dcdc1>;
>> >> >> >> vqmmc-supply = <®_eldo1>;
>> >> >> >> mmc-pwrseq = <&wifi_pwrseq>;
>> >> >> >> bus-width = <4>;
>> >> >> >> non-removable;
>> >> >> >> status = "okay";
>> >> >> >>
>> >> >> >> brcmf: wifi@1 {
>> >> >> >> reg = <1>;
>> >> >> >> compatible = "brcm,bcm4329-fmac";
>> >> >> >> interrupt-parent = <&r_pio>;
>> >> >> >> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /*
>> >> >> >> WL-WAKE-AP: PL3 */
>> >> >> >> interrupt-names = "host-wake";
>> >> >> >> };
>> >> >> >> };
>> >> >> >>
>> >> >> >> And observed rtc-osc32k-out clock is never enabled[1] and the value
>> >> >> >> of
>> >> >> >> LOSC_OUT_GATING is 0x0 which eventually not enabling
>> >> >> >> LOSC_OUT_GATING_EN
>> >> >> >>
>> >> >> >> Pls. let us know if we miss anything here?
>> >> >> >>
>> >> >> >> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
>> >> >> >
>> >> >> > Could you paste your config and the logs from a boot to?
>> >> >>
>> >> >> .config
>> >> >> https://paste.ubuntu.com/p/w9w2KB7RFc/
>> >> >>
>> >> >> dmesg
>> >> >> https://paste.ubuntu.com/p/mrZGk5bWRR/
>> >> >
>> >> > This is kind of weird. Have you tested with a 4.17 kernel? We have
>> >> > runtime_pm changes lined up in next, so that might be a regression
>> >> > there, even though we tested it with Quentin at some point.
>> >>
>> >> This is 4.17-rc4 do you want to try it on 4.16 ?
>> >
>> > No, this is next-20180503. Please try with 4.17-rc4
>>
>> Couldn't find any different in behaviour [2]
>>
>> [2] https://paste.ubuntu.com/p/m3PGBwrv6W/
>
> It's hard to tell without the board, but have you looked at the return
> value of devm_clk_get in the pwrseq code?
>
> Enabling the clk ftrace events would also help.
>
The driver has one bug.
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 2e6fb27..a66f40c 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -74,7 +74,7 @@
#define SUN6I_ALARM_CONFIG_WAKEUP BIT(0)
#define SUN6I_LOSC_OUT_GATING 0x0060
-#define SUN6I_LOSC_OUT_GATING_EN BIT(0)
+#define SUN6I_LOSC_OUT_GATING_EN 0
You need to pass bit_idx that is 0 and not BIT(0)
Michael
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
--
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] Re: sun4i-ts hwmon broken with linux 4.10
Hi Quentin, On Wed, Mar 08, 2017 at 02:14:46PM +0100, Quentin Schulz wrote: > > iio_hwmon-isa- = (SENSORS_IIO_HWMON | MFD_SUN4I_GPADC | > > SUN4I_GPADC | THERMAL_OF) > Not sure I get what you mean, correct me if I don't. I understand your points and I was just asking out of curiosity. It's a meta-discussion anyway - let's table it. :) > > In the current case: Maybe the help text of SUN4I_GPADC could be > > adjusted to state clearly that THERMAL_OF is required for the sensor to > > work? > The patch enables CONFIG_THERMAL_OF by default for all sunxi platforms. > The Kconfig states that you can disable it if you want to get rid of the > thermal sensor. That should be enough IMHO. Not everyone is working off the defconfig though. My custom config started out with sunxi_defconfig but now I just 'make oldconfig' it from the one kernel version to the next. I decide on new options based on the help text. In this case THERMAL_OF was not enabled because it wasn't necessary and not in the defconfig before. For such cases a clear(er) pointer to the necessity of THERMAL_OF in the help text of SUN4I_GPADC might be helpful. Anyway, thanks again for all your help and patience. Looking forward to 4.12 now. ;) -- Michael -- 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] Re: sun4i-ts hwmon broken with linux 4.10
Hi Quentin, On Wed, Mar 08, 2017 at 10:35:54AM +0100, Quentin Schulz wrote: > > Still no sensor reading though. I guess, I'll wait for 4.12 and see. > Hum, no. Let's get that fixed (if it's a bug) before reaching 4.12 :) > Have you applied this[1] patch as well or enabled CONFIG_OF_THERMAL? > [1] https://patchwork.kernel.org/patch/9472443/ Well, the patch is in but the setting didn't make it from the defconfig to my config. My bad. Now it's sensoring as expected: # sensors iio_hwmon-isa- Adapter: ISA adapter temp1:+28.4°C Thanks for your help! On a general note: Am I right in my perception that there's currently a trend in the Linux kernel to have things abstracted to such a degree and spread across so large a number of independent subsystems that it's not possible any more and doesn't make sense to have settings depend on each other in a manner that a single switch can enable a whole function? iio_hwmon-isa- = (SENSORS_IIO_HWMON | MFD_SUN4I_GPADC | SUN4I_GPADC | THERMAL_OF) This is the second instance where I had to chase some quite non-obvious dependencies with no aid from Kconfig to get something working on my Cubieboard. (I think the last one had to do with pinctrl and gpio - not sure.) In the current case: Maybe the help text of SUN4I_GPADC could be adjusted to state clearly that THERMAL_OF is required for the sensor to work? "For the thermal sensor to work, CONFIG_THERMAL_OF needs to be enabled as well. The thermal sensor does slow down ADC readings though. This can be avoided by not enabling CONFIG_THERMAL_OF. However, the thermal sensor should be enabled by default since the SoC temperature is usually more critical than ADC readings." -- Thanks for your patience, Michael -- 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] Re: sun4i-ts hwmon broken with linux 4.10
Hi Quentin, On Wed, Mar 08, 2017 at 08:43:12AM +0100, Quentin Schulz wrote: > First of all, you should have sent this mail to the linux-arm-kernel [...] > CONFIG_MFD_SUN4I_GPADC enabled seems to be the culprit. Then, Cc the > guy(s) who wrote/edited the driver. In that case, myself. I can only ask for understanding that the way of communication in the Linux community (massive cross-posting, need to mail individuals directly to get noticed) is exactly the opposite of all other projects I interact with and would get me admonished just as harshly there. It's hard to keep track of per-project Netiquette as an infrequent requestor or contributor. I'll certainly try to do better. > > If so: > > How is it supposed to work, because even with sun4i-ts disabled and > > iio_hwmon activated I don't get any sensors. > It'll not work because these two drivers are drivers for the same > component. The mfd driver is probing other drivers (such as iio_hwmon > for example, but also the IIO driver in charge of registering the sensor > in Linux and returning values). However, the IIO driver is not merged yet. I figured out as much by looking more closely at the source and researching your patch series' and discussions yesterday. So it's very unfortunate that https://patchwork.kernel.org/patch/9472445/ didn't make it into 4.10 or this whole discussion could have been avoided. BTW: Out of curiosity I applied https://patchwork.kernel.org/patch/9472451/ to yesterday's mainline master and activated it. All the rest is already there, it seems. So I now have: # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_SENSORS_IIO_HWMON=y CONFIG_MFD_SUN4I_GPADC=y CONFIG_SUN4I_GPADC=y Still no sensor reading though. I guess, I'll wait for 4.12 and see. -- Thanks for getting back to me, Micha -- 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: sun4i-ts hwmon broken with linux 4.10
Okay, shame on me, On Sun, Feb 26, 2017 at 03:23:48PM +0100, Michael Weiser wrote: > With 4.10 the sensor isn't found any more and /sys/class/hwmon is > completely empty: Turns out with CONFIG_MFD_SUN4I_GPADC enabled sun4i-ts isn't found any more. If I leave sun4i-gpadc out of the kernel, all is well again. Is sun4i-gpadc supposed to replace the hwmon part of sun4i-ts? If so: How is it supposed to work, because even with sun4i-ts disabled and iio_hwmon activated I don't get any sensors. -- Thanks, Michael -- 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] sun4i-ts hwmon broken with linux 4.10
Hi, I'm running statically linked (i.e. no loadable modules) vanilla kernels on Cubieboard2's. With 4.9 and earlier the hwmon interface of the sun4i-ts driver works flawlessly and reports something like: # sensors sun4i_ts-isa- Adapter: ISA adapter SoC temperature: +44.4°C Conversely, /sys has a class/hwmon/hwmon0 node containing: # cat /sys/class/hwmon/hwmon0/name sun4i_ts The driver is detected automatically at boot time. With 4.10 the sensor isn't found any more and /sys/class/hwmon is completely empty: # sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. # find /sys/class/hwmon/ /sys/class/hwmon/ >From the commit logs I noticed that there's been some cleanup in the hwmon core. Is 4.10 broken in terms of hwmon for sunxi or am I doing something wrong? -- Thanks, Michael -- 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 v6] ARM: sun4i: spi: Allow transfers larger than FIFO size
Hi Mark, On Thu, Jul 21, 2016 at 05:31:53PM +0100, Mark Brown wrote: > > What is keeping the patch from being merged (i.e. into mainline)? > Someone needs to address whatever review comments there were on the last > version and submit it. That's my point: There don't seem to be any. v6 was resend with fixes to checkpatch niggles on v5: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363073.html v5 addressed comments by Maxime on v4: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244305.html http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/243995.html I can't find any comments on v5 or v6. -- Thanks, Michael -- 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 v6] ARM: sun4i: spi: Allow transfers larger than FIFO size
Hi all, On Sat, Aug 08, 2015 at 09:41:51PM +0200, Olliver Schinagl wrote: > Alexandru sent this patch over a year and a half ago, and I believe several > tree's have been carrying it since. We've been using this patch on an > Olimex OLinuxIno Lime1 and Lime2 using the mmc-spi driver to access SD cards > without problems. So bumping this and adding my I also have a need for this addition since it makes an ENC28J60 SPI ethernet controller work on the Cubieboard2. I've successfully tested it with 4.6.3 where it still applies cleanly. (There's is a very minor conflict when applying against current Linus master (EINVAL was changed to EMSGSIZE). I can supply a rebased version if so desired.) What is keeping the patch from being merged (i.e. into mainline)? Thanks! Michael > Tested-by: Olliver Schinagl Tested-by: Michael Weiser > Changes from v5as warned by checkpatch. No functional changes. > * Added some newlines to make checkpatch happy. No functional changes. > Changes from v4: > * use min3() instead of two if statements in sun4i_spi_fill_fifo() > * fix trivial whitespace issue in if statement in sun4i_spi_handler() > * use consistent style in assigning 'reg' in the added functions. > Alexandru Gagniuc (1): > ARM: sun4i: spi: Allow transfers larger than FIFO size > drivers/spi/spi-sun4i.c | 76 > +++------ > 1 file changed, 67 insertions(+), 9 deletions(-) -- Thanks, Michael -- 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 2/4] power: add axp20x-battery driver
Hi There,
On 05.07.2016 10:33, Icenowy Zheng wrote:
On 01.07.2016 11:29, Icenowy Zheng wrote:
+
+static enum power_supply_property axp22x_battery_properties[] = {
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+};
Here's what Bruno's driver supports:
static enum power_supply_property axp20x_battery_power_properties[] = {
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_CURRENT_NOW,
POWER_SUPPLY_PROP_CURRENT_MAX,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_TECHNOLOGY,
POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
/* POWER_SUPPLY_PROP_POWER_NOW, */
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
/* POWER_SUPPLY_PROP_CHARGE_NOW, */
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_TEMP,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
};
+
+static int axp20x_battery_probe(struct platform_device *pdev)
+{
+ struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+ struct power_supply_config psy_cfg = {};
+ struct axp20x_battery *power;
+ static const char * const axp22x_irq_names[] = {
+ "BATT_PLUGIN", "BATT_REMOVAL", "BATT_ENT_ACT_MODE",
+ "BATT_EXIT_ACT_MODE", "CHARG", "CHARG_DONE", NULL };
And here are the interrupts handled:
static const char * const irq_names[] = { "BATT_HOT", "BATT_COLD",
"BATT_PLUGIN", "BATT_REMOVAL", "BATT_ACTIVATE",
"BATT_ACTIVATED", "BATT_CHARGING", "BATT_CHARGED",
"BATT_CHG_CURR_LOW", "BATT_POWER_LOW_WARN",
"BATT_POWER_LOW_CRIT" };
There are a couple of issues with the version of Bruno's driver that I have:
* power management is disabled (in the driver, not in the charger) -
think suspend/resume
* the temperature sensor data is not turned into a temperature value
correctly
* the IRQ handlers need to be cleaned up (remove logging)
* device tree binding documentation is missing
Other than that, it's basically working and I have been using it at
least for some testing.
The device tree bindings support:
* OCV curve support
* battery resistance
* battery capacity
* temp sensor settings
You can find my copy of Bruno's driver here:
https://github.com/mhaas/linux-sunxi/blob/axp209-charger/drivers/power/axp20x_fuel_gauge.c
Thanks,
Michael
--
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 2/4] power: add axp20x-battery driver
Hi,
nice work! Is this in any way related to Bruno Prémonts driver for the
axp20x?
I've got a reworked version of that lying around, but it's not quite
ready for submission. Do you know what pieces are missing in your driver
for axp20x support - as opposed to axp22x, which is already working?
Michael
On 01.07.2016 11:29, Icenowy Zheng wrote:
This driver is the battery power supply driver of axp20x PMIC. Currently
it supports only AXP22x variants.
Signed-off-by: Icenowy Zheng
---
drivers/mfd/axp20x.c | 14 +++
drivers/power/Makefile | 1 +
drivers/power/axp20x_battery.c | 254 +
3 files changed, 269 insertions(+)
create mode 100644 drivers/power/axp20x_battery.c
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index cee5288..064e5015 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -166,6 +166,15 @@ static struct resource axp22x_usb_power_supply_resources[]
= {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
};
+static struct resource axp22x_battery_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_PLUGIN, "BATT_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_REMOVAL, "BATT_REMOVAL"),
+ DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_ENT_ACT_MODE, "BATT_ENT_ACT_MODE"),
+ DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_EXIT_ACT_MODE,
"BATT_EXIT_ACT_MODE"),
+ DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG, "CHARG"),
+ DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG_DONE, "CHARG_DONE"),
+};
+
static struct resource axp22x_pek_resources[] = {
{
.name = "PEK_DBR",
@@ -538,6 +547,11 @@ static struct mfd_cell axp22x_cells[] = {
.of_compatible = "x-powers,axp202-usb-power-supply",
.num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
.resources = axp22x_usb_power_supply_resources,
+ }, {
+ .name = "axp20x-battery",
+ .of_compatible = "x-powers,axp202-battery",
+ .num_resources = ARRAY_SIZE(axp22x_battery_resources),
+ .resources = axp22x_battery_resources,
},
};
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..1452d23 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER) += pda_power.o
obj-$(CONFIG_APM_POWER) += apm_power.o
obj-$(CONFIG_AXP20X_POWER)+= axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_battery.o
obj-$(CONFIG_MAX8925_POWER) += max8925_power.o
obj-$(CONFIG_WM831X_BACKUP) += wm831x_backup.o
obj-$(CONFIG_WM831X_POWER)+= wm831x_power.o
diff --git a/drivers/power/axp20x_battery.c b/drivers/power/axp20x_battery.c
new file mode 100644
index 000..8fac2cd
--- /dev/null
+++ b/drivers/power/axp20x_battery.c
@@ -0,0 +1,254 @@
+/*
+ * AXP20x PMIC battery status driver
+ *
+ * Copyright (C) 2016 Icenowy Zheng
+ * Copyright (C) 2015 Hans de Goede
+ * Copyright (C) 2014 Bruno Prémont
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRVNAME "axp20x-battery"
+
+#define AXP20X_PWR_STATUS_ACIN_USED BIT(6)
+#define AXP20X_PWR_STATUS_VBUS_USED BIT(4)
+#define AXP20X_PWR_STATUS_BAT_DIRECTION BIT(2)
+
+#define AXP20X_OP_MODE_CHARGING BIT(6)
+#define AXP20X_OP_MODE_BATTERY_PRESENT BIT(5)
+#define AXP20X_OP_MODE_BATTERY_ACTIVE BIT(3)
+
+#define AXP20X_CAPACITY_CORRECT BIT(7)
+
+struct axp20x_battery {
+ struct axp20x_dev *axp20x;
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static irqreturn_t axp20x_battery_irq(int irq, void *devid)
+{
+ struct axp20x_battery *power = devid;
+
+ power_supply_changed(power->supply);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp, union power_supply_propval *val)
+{
+ struct axp20x_battery *power = power_supply_get_drvdata(psy);
+ unsigned int input, op_mode, capacity, dh, dl;
+ int ret, ext;
+
+ /* All the properties below need the input-status reg value */
+ ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(power->regmap, AXP20X_PWR_OP_MODE, &op_mode);
+ if (ret)
+ return ret;
+
+ switch (p
[linux-sunxi] Re: [PATCH 1/3] clk: sunxi: Add a driver for the CCU
Quoting Maxime Ripard (2016-06-28 13:45:02) > What's the point of this, if we're not using (or exposing for that > matter) any of it? > > I'm sorry, but the whole point of the initial serie was to rework and > simplify things, precisely because dealing with the clk_factors code > was just too difficult nowadays. And this doesn't solve anything on > that aspect. > > We came with an approach that have all the maintainers involved > agreeing on it, I don't see why we should start over. There's some > useful features there (like tracing). But it's something that can be > added, and should be done differently anyway. Yes, let's not delay Maxime's work any longer. Stephen and I have requested these changes to the sunxi clock drivers for a long time and now we have them. I intend to merge Maxime's v3 once it addresses the last round of review questions. Regards, Mike > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com -- 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: brcmfmac device tree support
Hey Hans, Newbie to the brcmfmac here in need of some guidance. I'm trying to bring up a Broadcom 43362 module up on a Beaglebone Black. I modified the dts to define the sdio pins and associate mmc0 with the brcmfmac driver. How do I get the driver to recognize the oob irq line? Does the inclusion of this line in the pinctrl settings inform the driver or is there another setting that needs to be made? Thanks, -Mike On Monday, May 26, 2014 at 3:47:54 AM UTC-4, Hans de Goede wrote: > Hi Arend, > > On 04/11/2014 12:31 PM, Arend van Spriel wrote: > > Hi Hans, > > > > I have put some effort in adding device tree support in brcmfmac. > > Unfortunately, I had no luck getting MMC up and running on pandaboard > > extension header. So no way to test the patches. Would/could you be willing > > to do so. > > It has taken me longer then I would have liked, but I finally have > managed to got oob irq support working on 2 different A20 boards I've > (which are the only 2 with sdio wifi which I have). > > I also have an A10s board with sdio wifi, but that seems to have died on me > (the entire board), I've ordered a new one, and I'll also test this series + > send dts patches for that one, once I've the new one. > > I've removed the clk / reg_enable gpio support from the brcmfmac patches, as > discussion is still ongoing on how to best deal with that. > > I also needed to add a patch replicating some magic writes to the bcm43362 > module to enable the oob irq pin, Arend can you please give those a thorough > review, and maybe add some comments to make them less black magic ? > > I'm sending the actual series right after this mail, so for more details see > the patches there. > > Regards, > > Hans -- 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 v4 1/4] power: Add an axp20x-ac-power driver
On 05/09/2016 06:33 PM, Chen-Yu Tsai wrote:
>> +
>> + power->supply = devm_power_supply_register(&pdev->dev,
>> + &axp20x_ac_power_desc, &psy_cfg);
>> + if (IS_ERR(power->supply))
>> + return PTR_ERR(power->supply);
>> +
>> + /* Request irqs after registering, as irqs may trigger immediately */
>> + for (i = 0; i < ARRAY_SIZE(irq_names); i++) {
>> + irq = platform_get_irq_byname(pdev, irq_names[i]);
>> + if (irq < 0) {
>> + dev_warn(&pdev->dev, "No IRQ for %s: %d\n",
>> +irq_names[i], irq);
>> + continue;
>> + }
>> + irq = regmap_irq_get_virq(axp20x->regmap_irqc, irq);
>> + r = devm_request_any_context_irq(&pdev->dev, irq,
>> + axp20x_irq_ac_handler, 0, DRVNAME, power);
>> + if (r < 0)
>> + dev_warn(&pdev->dev, "Error requesting %s IRQ: %d\n",
>> +irq_names[i], r);
>
> Won't missing IRQs hinder the usage of this driver / hardware?
> A power supply isn't much use if the system isn't told when
> it's gone.
>
That's a good point. The real question is: how would you handle missing
IRQs? I have looked at other uses of devm_request_any_context_irq, e.g.
in rtc-pm8xxx.c [0]. These other users often return an error code in the
probe function. That doesn't help the system, though: it still won't
notice if the power is unplugged in addition to missing the driver
completely.
It's probably best to provide the remaining (functional) parts of the
driver (reading from /sys/class..) even if the IRQs cannot be
registered. The code is pretty much the same in the axp20x-usb-power.
Michael
[0] http://lxr.free-electrons.com/source/drivers/rtc/rtc-pm8xxx.c#L490
--
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] [PATCH v4 1/4] power: Add an axp20x-ac-power driver
This adds a driver for the ac power_supply bits of the axp20x
PMICs.
This submission is taken directly from Bruno Prémonts 2015 RFC [0].
The original RFC contains drivers for AC, battery and backup
battery. This commit only adds the AC driver for now.
[0] http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980
Signed-off-by: Michael Haas
---
drivers/power/Makefile | 2 +-
drivers/power/axp20x_ac_power.c | 181
2 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/axp20x_ac_power.c
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..3a785cc 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
-obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o axp20x_ac_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
new file mode 100644
index 000..0d1ca0e
--- /dev/null
+++ b/drivers/power/axp20x_ac_power.c
@@ -0,0 +1,181 @@
+/*
+ * AXP20x PMIC AC power driver
+ *
+ * Copyright 2014-2015 Bruno Prémont
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRVNAME "axp20x-ac-power"
+
+
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE BIT(6)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT BIT(1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
+
+/* Fields of AXP20X_ADC_EN1 */
+#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
+#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
+
+
+struct axp20x_ac_power {
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static int axp20x_ac_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
+ unsigned int input;
+ int r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_V_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 1700; /* 1 step = 1.7 mV */
+ return 0;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_I_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 375; /* 1 step = 0.375 mA */
+ return 0;
+ default:
+ break;
+ }
+
+ /* All the properties below need the input-status reg value */
+ r = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
+ if (r)
+ return r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = !!(input & AXP20X_PWR_STATUS_AC_PRESENT);
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = !!(input & AXP20X_PWR_STATUS_AC_AVAILABLE);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static enum power_supply_property axp20x_ac_power_properties[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+static const struct power_supply_desc axp20x_ac_power_desc = {
+ .name = "axp20x-ac",
+ .type = POWER_SUPPLY_TYPE_MAINS,
+ .properties = axp20x_ac_power_properties,
+ .num_properties = ARRAY_SIZE(axp20x_ac_power_properties),
+ .get_property = axp20x_ac_power_get_property,
+};
+
+static irqreturn_t axp20x_irq_ac_handler(int irq, void *devid)
+{
+ struct axp20x_ac_power *power = devid;
+
+ power_supply_changed(power->supply);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_ac_power_probe(struct platform_device *pdev)
+{
+ struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+ struct power_supply_config psy_cfg = {};
+ struct ax
[linux-sunxi] [PATCH v4 3/4] ARM: dts: Add binding documentation for AXP20x pmic ac power supply
Add binding documentation for the ac power supply part of the AXP20x
pmic.
Signed-off-by: Michael Haas
Acked-by: Rob Herring
---
.../bindings/power_supply/axp20x_ac_power.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
new file mode 100644
index 000..1cebe35
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
@@ -0,0 +1,17 @@
+AXP20x AC power supply
+
+Required Properties:
+-compatible: "x-powers,axp202-ac-power-supply"
+
+This node is a subnode of the axp20x PMIC.
+
+Example:
+
+axp209: pmic@34 {
+
+ ac-power-supply: ac-power-supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
+
+ ...
+};
--
2.8.2
--
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] [PATCH v4 2/4] mfd: axp20x: Add a cell for the ac power_supply part of the axp20x PMICs
As a counterpart to the usb power_supply cell, this commit adds an AC
power_supply cell to the axp20x driver.
Still missing are the RTC backup battery and the main battery charger
cells.
Signed-off-by: Michael Haas
Acked-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e9..aa6ef08 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -128,6 +128,12 @@ static struct resource axp152_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
};
+static struct resource axp20x_ac_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
+};
+
static struct resource axp20x_pek_resources[] = {
{
.name = "PEK_DBR",
@@ -436,6 +442,11 @@ static struct mfd_cell axp20x_cells[] = {
}, {
.name = "axp20x-regulator",
}, {
+ .name = "axp20x-ac-power-supply",
+ .of_compatible = "x-powers,axp202-ac-power-supply",
+ .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
+ .resources = axp20x_ac_power_supply_resources,
+ }, {
.name = "axp20x-usb-power-supply",
.of_compatible = "x-powers,axp202-usb-power-supply",
.num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
--
2.8.2
--
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] [PATCH v4 4/4] ARM: dts: axp209: Add ac_power_supply child node to the ax209 node
Add a node representing the ac power supply part of the axp209 pmic.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/axp209.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 051ab3b..bdf8fe8 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -90,8 +90,14 @@
};
};
+ ac_power_supply: ac_power_supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ status = "disabled";
+ };
+
usb_power_supply: usb_power_supply {
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
+
};
--
2.8.2
--
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] [PATCH v4 0/4]
Changes in v4: * Mark AC power driver as disabled by default in axp209.dtsi * Drop patch enabling USB power driver by default * Add Acked-By Rob Herring and Chen-Yu Tsai Changes in v3: * Move register definitions back from MFD header to driver itself * Globally enable AC power supply driver in axp209.dtsi * Additionally enable USB power supply driver in axp209.dtsi * Fix formatting and ordering issues noted by Chen-Yu Tsai * Drop Rob Herring's ACKED-BY on the binding documentation patch as I have simplified the example Changes in v2: * Remove check for shortcut between AC and USB * Remove logging in interrupt handler -- 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 v3 5/5] ARM: dts: axp209: Enable usb_power_supply by default
Hi Hans,
On 05/05/2016 12:39 PM, Hans de Goede wrote:
> Hi,
>
> On 05-05-16 12:35, Michael Haas wrote:
>> This node should be enabled by default. A device is likely to have an
>> USB power
>> connection. If USB power is indeed absent, the USB power driver
>> will simply report the power input as offline.
>
> Nack, as Maxime already said we do not want to enable any optional
> features by default. Many top set boxes do not use the usb power supply,
> and we don't want some userspace power control panel applet showing
> the supply as offline, we want the supply to simply not be there.
it was my understanding that Maxime [0] and ChenYu [1] indicated they
would prefer it to be enabled globally.
Best,
Michael
[0] https://groups.google.com/d/msg/linux-sunxi/cHAlhoIw74g/CbBeoX23AAAJ
[1] https://groups.google.com/d/msg/linux-sunxi/Ee7i8DVI4F8/0b0TBrRkAAAJ
>>
>> Signed-off-by: Michael Haas
>> ---
>> arch/arm/boot/dts/axp209.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/axp209.dtsi
>> b/arch/arm/boot/dts/axp209.dtsi
>> index 7deb7d9..4f16be0 100644
>> --- a/arch/arm/boot/dts/axp209.dtsi
>> +++ b/arch/arm/boot/dts/axp209.dtsi
>> @@ -97,7 +97,7 @@
>>
>> usb_power_supply: usb_power_supply {
>> compatible = "x-powers,axp202-usb-power-supply";
>> -status = "disabled";
>> +status = "okay";
>> };
>>
>> };
>>
--
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] [PATCH v3 3/5] ARM: dts: Add binding documentation for AXP20x pmic ac power supply
Add binding documentation for the ac power supply part of the AXP20x
pmic.
Signed-off-by: Michael Haas
---
.../bindings/power_supply/axp20x_ac_power.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
new file mode 100644
index 000..1cebe35
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
@@ -0,0 +1,17 @@
+AXP20x AC power supply
+
+Required Properties:
+-compatible: "x-powers,axp202-ac-power-supply"
+
+This node is a subnode of the axp20x PMIC.
+
+Example:
+
+axp209: pmic@34 {
+
+ ac-power-supply: ac-power-supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
+
+ ...
+};
--
2.8.2
--
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] [PATCH v3 0/6] Add axp20x-ac power driver
This version of the axp20x-ac driver hopefully cleans up all issues found in version 1. I have enabled the AC and USB power supply drivers in axp209.dtsi as suggested by Maxime Ripard and Chen-Yu Tsai Changes in v3: * Move register definitions back from MFD header to driver itself * Globally enable AC power supply driver in axp209.dtsi * Additionally enable USB power supply driver in axp209.dtsi * Fix formatting and ordering issues noted by Chen-Yu Tsai * Drop Rob Herring's ACKED-BY on the binding documentation patch as I have simplified the example Changes in v2: * Remove check for shortcut between AC and USB * Remove logging in interrupt handler -- 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] [PATCH v3 4/5] ARM: dts: axp209: Add ac_power_supply child node to the ax209 node
Add a node representing the ac power supply part of the axp209 pmic.
This node is enabled by default. A device is likely to have an AC power
connection. If the AC power is indeed absent, the ac power driver
will simply report the power input as offline.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/axp209.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 051ab3b..7deb7d9 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -90,8 +90,14 @@
};
};
+ ac_power_supply: ac_power_supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ status = "okay";
+ };
+
usb_power_supply: usb_power_supply {
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
+
};
--
2.8.2
--
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] [PATCH v3 2/5] mfd: axp20x: Add a cell for the ac power_supply part of the axp20x PMICs
As a counterpart to the usb power_supply cell, this commit adds an AC
power_supply cell to the axp20x driver.
Still missing are the RTC backup battery and the main battery charger
cells.
Signed-off-by: Michael Haas
---
drivers/mfd/axp20x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e9..aa6ef08 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -128,6 +128,12 @@ static struct resource axp152_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
};
+static struct resource axp20x_ac_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
+};
+
static struct resource axp20x_pek_resources[] = {
{
.name = "PEK_DBR",
@@ -436,6 +442,11 @@ static struct mfd_cell axp20x_cells[] = {
}, {
.name = "axp20x-regulator",
}, {
+ .name = "axp20x-ac-power-supply",
+ .of_compatible = "x-powers,axp202-ac-power-supply",
+ .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
+ .resources = axp20x_ac_power_supply_resources,
+ }, {
.name = "axp20x-usb-power-supply",
.of_compatible = "x-powers,axp202-usb-power-supply",
.num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
--
2.8.2
--
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] [PATCH v3 1/5] power: Add an axp20x-ac-power driver
This adds a driver for the ac power_supply bits of the axp20x
PMICs.
This submission is taken directly from Bruno Prémonts 2015 RFC [0].
The original RFC contains drivers for AC, battery and backup
battery. This commit only adds the AC driver for now.
[0] http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980
Signed-off-by: Michael Haas
---
drivers/power/Makefile | 2 +-
drivers/power/axp20x_ac_power.c | 181
2 files changed, 182 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/axp20x_ac_power.c
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..3a785cc 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
-obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o axp20x_ac_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
new file mode 100644
index 000..0d1ca0e
--- /dev/null
+++ b/drivers/power/axp20x_ac_power.c
@@ -0,0 +1,181 @@
+/*
+ * AXP20x PMIC AC power driver
+ *
+ * Copyright 2014-2015 Bruno Prémont
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRVNAME "axp20x-ac-power"
+
+
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE BIT(6)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT BIT(1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
+
+/* Fields of AXP20X_ADC_EN1 */
+#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
+#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
+
+
+struct axp20x_ac_power {
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static int axp20x_ac_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
+ unsigned int input;
+ int r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_V_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 1700; /* 1 step = 1.7 mV */
+ return 0;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_I_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 375; /* 1 step = 0.375 mA */
+ return 0;
+ default:
+ break;
+ }
+
+ /* All the properties below need the input-status reg value */
+ r = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
+ if (r)
+ return r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = !!(input & AXP20X_PWR_STATUS_AC_PRESENT);
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = !!(input & AXP20X_PWR_STATUS_AC_AVAILABLE);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static enum power_supply_property axp20x_ac_power_properties[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+static const struct power_supply_desc axp20x_ac_power_desc = {
+ .name = "axp20x-ac",
+ .type = POWER_SUPPLY_TYPE_MAINS,
+ .properties = axp20x_ac_power_properties,
+ .num_properties = ARRAY_SIZE(axp20x_ac_power_properties),
+ .get_property = axp20x_ac_power_get_property,
+};
+
+static irqreturn_t axp20x_irq_ac_handler(int irq, void *devid)
+{
+ struct axp20x_ac_power *power = devid;
+
+ power_supply_changed(power->supply);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_ac_power_probe(struct platform_device *pdev)
+{
+ struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+ struct power_supply_config psy_cfg = {};
+ struct ax
[linux-sunxi] [PATCH v3 5/5] ARM: dts: axp209: Enable usb_power_supply by default
This node should be enabled by default. A device is likely to have an USB power
connection. If USB power is indeed absent, the USB power driver
will simply report the power input as offline.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/axp209.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 7deb7d9..4f16be0 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -97,7 +97,7 @@
usb_power_supply: usb_power_supply {
compatible = "x-powers,axp202-usb-power-supply";
- status = "disabled";
+ status = "okay";
};
};
--
2.8.2
--
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] Re: [PATCH v2 2/6] mfd: axp20x: Add register bits for axp20x-ac-power
On 05/01/2016 11:48 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Sun, May 1, 2016 at 4:57 PM, Michael Haas
> wrote:
>> This change adds some register bit definitions used by the
>> axp20x-ac-power driver.
>>
>> Signed-off-by: Michael Haas
>> ---
>> include/linux/mfd/axp20x.h | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
>> index d82e7d5..c4c6dfa 100644
>> --- a/include/linux/mfd/axp20x.h
>> +++ b/include/linux/mfd/axp20x.h
>> @@ -90,6 +90,17 @@ enum {
>> #define AXP22X_ALDO3_V_OUT 0x2a
>> #define AXP22X_CHRG_CTRL3 0x35
>>
>> +
>> +/* Fields of AXP20X_PWR_INPUT_STATUS */
>> +#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
>> +#define AXP20X_PWR_STATUS_AC_AVAILABLE BIT(6)
>> +#define AXP20X_PWR_STATUS_AC_VBUS_SHORT BIT(1)
>> +#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
>> +
>> +/* Fields of AXP20X_ADC_EN1 */
>> +#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
>> +#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
>> +
>
> We keep the bit definitions of each register in each separate driver.
> The drivers only define the ones they use.
>
> ChenYu
Hi ChenYu,
i believe Maxime Ripard requested that these defines be moved to the
header: https://groups.google.com/d/msg/linux-sunxi/nEUg87cV6KI/TvdB6MBZBAAJ
What do you think?
Thanks for the review!
Michael
--
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] [PATCH v2 6/6] ARM: dts: sunxi: add ac-power to A20 OLinuXino Lime2 board
The A20-olinuxino-lime2 has an AC power input.
This patch enables support for current and voltage monitoring
via the axp20x-ac-power driver.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..bcd4a89 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -163,6 +163,10 @@
regulator-always-on;
};
};
+ ac_power_supply: ac_power_supply {
+ status = "okay";
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
};
};
--
2.8.0
--
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] [PATCH v2 0/6] Add axp20x-ac power driver
This version of the axp20x-ac driver hopefully cleans up all issues found in version 1. Major changes: * Remove check for shortcut between AC and USB * Remove logging in interrupt handler -- 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] [PATCH v2 2/6] mfd: axp20x: Add register bits for axp20x-ac-power
This change adds some register bit definitions used by the
axp20x-ac-power driver.
Signed-off-by: Michael Haas
---
include/linux/mfd/axp20x.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index d82e7d5..c4c6dfa 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -90,6 +90,17 @@ enum {
#define AXP22X_ALDO3_V_OUT 0x2a
#define AXP22X_CHRG_CTRL3 0x35
+
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE BIT(6)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT BIT(1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
+
+/* Fields of AXP20X_ADC_EN1 */
+#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
+#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
+
/* Interrupt */
#define AXP152_IRQ1_EN 0x40
#define AXP152_IRQ2_EN 0x41
--
2.8.0
--
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] [PATCH v2 5/6] ARM: dts: axp209: Add ac_power_supply child node to the ax209 node
Add a node representing the ac power supply part of the axp209 pmic.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/axp209.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 051ab3b..9046f0a 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -94,4 +94,10 @@
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
+
+ ac_power_supply: ac_power_supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ status = "disabled";
+ };
+
};
--
2.8.0
--
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] [PATCH v2 1/6] power: Add an axp20x-ac-power driver
This adds a driver for the ac power_supply bits of the axp20x
PMICs.
This submission is taken directly from Bruno Prémonts 2015 RFC [0].
The original RFC contains drivers for AC, battery and backup
battery. This commit only adds the AC driver for now.
[0] http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980
Signed-off-by: Michael Haas
---
drivers/power/Makefile | 2 +-
drivers/power/axp20x_ac_power.c | 169
2 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/axp20x_ac_power.c
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..3a785cc 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
-obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o axp20x_ac_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
new file mode 100644
index 000..dcbb1da
--- /dev/null
+++ b/drivers/power/axp20x_ac_power.c
@@ -0,0 +1,169 @@
+/*
+ * AXP20x PMIC AC power driver
+ *
+ * Copyright 2014-2015 Bruno Prémont
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRVNAME "axp20x-ac-power"
+
+struct axp20x_ac_power {
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static int axp20x_ac_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
+ unsigned int input;
+ int r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_V_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 1700; /* 1 step = 1.7 mV */
+ return 0;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_I_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 375; /* 1 step = 0.375 mA */
+ return 0;
+ default:
+ break;
+ }
+
+ /* All the properties below need the input-status reg value */
+ r = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
+ if (r)
+ return r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = !!(input & AXP20X_PWR_STATUS_AC_PRESENT);
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = !!(input & AXP20X_PWR_STATUS_AC_AVAILABLE);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static enum power_supply_property axp20x_ac_power_properties[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+};
+
+static const struct power_supply_desc axp20x_ac_power_desc = {
+ .name = "axp20x-ac",
+ .type = POWER_SUPPLY_TYPE_MAINS,
+ .properties = axp20x_ac_power_properties,
+ .num_properties = ARRAY_SIZE(axp20x_ac_power_properties),
+ .get_property = axp20x_ac_power_get_property,
+};
+
+static irqreturn_t axp20x_irq_ac_handler(int irq, void *devid)
+{
+ struct axp20x_ac_power *power = devid;
+
+ power_supply_changed(power->supply);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_ac_power_probe(struct platform_device *pdev)
+{
+ struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+ struct power_supply_config psy_cfg = {};
+ struct axp20x_ac_power *power;
+ static const char * const irq_names[] = { "ACIN_PLUGIN",
+ "ACIN_REMOVAL", "ACIN_OVER_V" };
+ int i, irq, r;
+
+ power = devm_kzalloc(&pdev->dev, sizeof(*power), GFP_KERNEL);
+ if (!power)
+ return -ENOMEM;
+
+ power->regmap = axp20x->re
[linux-sunxi] [PATCH v2 4/6] ARM: dts: Add binding documentation for AXP20x pmic ac power supply
Add binding documentation for the ac power supply part of the AXP20x
pmic.
Signed-off-by: Michael Haas
Acked-by: Rob Herring
---
.../bindings/power_supply/axp20x_ac_power.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
new file mode 100644
index 000..1cbdcfb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
@@ -0,0 +1,34 @@
+AXP20x AC power supply
+
+Required Properties:
+-compatible: "x-powers,axp202-ac-power-supply"
+
+This node is a subnode of the axp20x PMIC.
+
+Example:
+
+axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ x-powers,dcdc-freq = <1500>;
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <145>;
+ regulator-name = "vdd-cpu";
+ };
+
+ ...
+ };
+
+ ac-power-supply: ac-power-supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
+};
--
2.8.0
--
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] [PATCH v2 3/6] mfd: axp20x: Add a cell for the ac power_supply part of the axp20x PMICs
As a counterpart to the usb power_supply cell, this commit adds an AC
power_supply cell to the axp20x driver.
Still missing are the RTC backup battery and the main battery charger
cells.
Signed-off-by: Michael Haas
---
drivers/mfd/axp20x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e9..9351c0e 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -178,6 +178,12 @@ static struct resource axp288_power_button_resources[] = {
},
};
+static struct resource axp20x_ac_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
+};
+
static struct resource axp288_fuel_gauge_resources[] = {
{
.start = AXP288_IRQ_QWBTU,
@@ -440,6 +446,11 @@ static struct mfd_cell axp20x_cells[] = {
.of_compatible = "x-powers,axp202-usb-power-supply",
.num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
.resources = axp20x_usb_power_supply_resources,
+ }, {
+ .name = "axp20x-ac-power-supply",
+ .of_compatible = "x-powers,axp202-ac-power-supply",
+ .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
+ .resources = axp20x_ac_power_supply_resources,
},
};
--
2.8.0
--
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] Re: [PATCH 2/3] sunxi: A20-OLinuXino-LIME2: Add usb-power-supply
Hi Maxime, On 04/02/2016 12:36 PM, Maxime Ripard wrote: > Hi, > > On Fri, Mar 25, 2016 at 08:04:06PM +0100, Michael Haas wrote: >> The A20-OLinuXino-LIME2 uses the AXP209 PMIC. This patch adds the >> corresponding usb-power-supply node to the DTS. >> If CONFIG_AXP20X_POWER is set, this patch enables the >> /sys/class/power_supply/ >> diirectory. >> >> Signed-off-by: Michael Haas > > Is there *any* reason to not use the AXP209 dtsi where it's already > defined? > do you have any preference for this being in the AXP209 dtsi? I've been thinking about it and it makes sense to enable the power supply nodes for all devices using the AXP209. They will just report themselves as offline if the PMIC indicates nothing is connected. Best, Michael -- 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. signature.asc Description: OpenPGP digital signature
Re: [linux-sunxi] [PATCH 2/2] ARM: dtsi: sun7i: Enable sun4i_can on Olinuxino-a20-Lime2
Hi Johannes,
thanks for your patches. I had submitted my first patches
last month and it's a fun ride. Great to see more people riding the
olinuxino train :)
On 04/18/2016 09:12 PM, Johannes Kuhn wrote:
> +
> +&can0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&can0_pins_a>;
> + status = "okay";
> +};
> +
I believe this will disable PH20 and PH21 for GPIO purposes, right?
Maxime Ripard pointed out to me that stuff like this it not always
a good idea: http://www.spinics.net/lists/arm-kernel/msg495917.html
I figured I'd mention it here, I have no real authority or knowledge here :)
Michael
--
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] Re: [PATCH 1/4] power: Add an axp20x-ac-power driver
On 04/05/2016 08:05 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Mon, Apr 4, 2016 at 10:11 PM, Michael Haas
> wrote:
>> Hi Maxime,
>>
>> thanks for taking the time to review this.
>>
>> On 04/04/2016 11:38 PM, Maxime Ripard wrote:
>>> Hi,
>>>>
>>>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>>>> index a57d6e9..9351c0e 100644
>>>> --- a/drivers/mfd/axp20x.c
>>>> +++ b/drivers/mfd/axp20x.c
>>>> @@ -178,6 +178,12 @@ static struct resource
>>>> axp288_power_button_resources[] = {
>>>> },
>>>> };
>>>>
>>>> +static struct resource axp20x_ac_power_supply_resources[] = {
>>>> +DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
>>>> +DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
>>>> +DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
>>>> +};
>>>> +
>>>> static struct resource axp288_fuel_gauge_resources[] = {
>>>> {
>>>> .start = AXP288_IRQ_QWBTU,
>>>> @@ -440,6 +446,11 @@ static struct mfd_cell axp20x_cells[] = {
>>>> .of_compatible = "x-powers,axp202-usb-power-supply",
>>>> .num_resources =
>>>> ARRAY_SIZE(axp20x_usb_power_supply_resources),
>>>> .resources = axp20x_usb_power_supply_resources,
>>>> +}, {
>>>> +.name = "axp20x-ac-power-supply",
>>>> +.of_compatible = "x-powers,axp202-ac-power-supply",
>>>> +.num_resources =
>>>> ARRAY_SIZE(axp20x_ac_power_supply_resources),
>>>> +.resources = axp20x_ac_power_supply_resources,
>>>> },
>>>> };
>>>>
>>>
>>> These changes should be in a separate patch.
>>
>> Will do!
>>>
>>
>>>> +
>>>> +static irqreturn_t axp20x_irq_ac_removal(int irq, void *devid)
>>>> +{
>>>> +struct axp20x_ac_power *power = devid;
>>>> +
>>>> +dev_info(&power->supply->dev, "IRQ#%d AC disconnected\n", irq);
>>>> +power_supply_changed(power->supply);
>>>> +
>>>> +return IRQ_HANDLED;
>>>> +}
>>>
>>> Logging in the interrupt handler is usually a bad idea, for several
>>> reasons:
>>>- If you have a console, it's going to be output on the console,
>>> which might take quite some time. And you don't want to take
>>> quite some time in the interrupt handler.
>>>- printk might not even work in the interrupt context in some
>>> scenarios.
>>>
>>> Removing that handler, you can register the same interrupt handler on
>>> all the interrupts.
>>>
>>
>> Oops. Yes, I will fix that!
>>
>>>> +static int axp20x_ac_power_probe(struct platform_device *pdev)
>>>> +{
>>>> +struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>>>> +struct power_supply_config psy_cfg = {};
>>>> +struct axp20x_ac_power *power;
>>>> +static const char * const irq_names[] = { "ACIN_PLUGIN",
>>>> +"ACIN_REMOVAL", "ACIN_OVER_V" };
>>>> +irqreturn_t (*irq_funcs[])(int, void *) = { axp20x_irq_ac_plugin,
>>>> +axp20x_irq_ac_removal, axp20x_irq_ac_over_v };
>>>> +int i, irq, r, input;
>>>> +
>>>> +if (!of_device_is_available(pdev->dev.of_node))
>>>> +return -ENODEV;
>>>
>>> That's useless. If the device is not available, you're not going to be
>>> probed in the first place.
>>
>> Ok.
>>
>>>
>>>> +power = devm_kzalloc(&pdev->dev, sizeof(*power), GFP_KERNEL);
>>>> +if (!power)
>>>> +return -ENOMEM;
>>>> +
>>>> +power->regmap = axp20x->regmap;
>>>> +
>>>> +r = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
>>>> +if (r < 0)
>>>> +return r;
>>>> +
>>>> +if (!!(input & AXP20X_PWR_STATUS_AC_VBUS_SHORT)) {
>>>> +dev_err(&pdev->dev, "AC is connected to VBUS. Use
>>>> axp20x_usb_power-supply driver instead!&qu
[linux-sunxi] Re: [PATCH 1/4] power: Add an axp20x-ac-power driver
Hi Maxime,
thanks for taking the time to review this.
On 04/04/2016 11:38 PM, Maxime Ripard wrote:
> Hi,
>>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index a57d6e9..9351c0e 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -178,6 +178,12 @@ static struct resource axp288_power_button_resources[]
>> = {
>> },
>> };
>>
>> +static struct resource axp20x_ac_power_supply_resources[] = {
>> +DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
>> +DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
>> +DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
>> +};
>> +
>> static struct resource axp288_fuel_gauge_resources[] = {
>> {
>> .start = AXP288_IRQ_QWBTU,
>> @@ -440,6 +446,11 @@ static struct mfd_cell axp20x_cells[] = {
>> .of_compatible = "x-powers,axp202-usb-power-supply",
>> .num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
>> .resources = axp20x_usb_power_supply_resources,
>> +}, {
>> +.name = "axp20x-ac-power-supply",
>> +.of_compatible = "x-powers,axp202-ac-power-supply",
>> +.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
>> +.resources = axp20x_ac_power_supply_resources,
>> },
>> };
>>
>
> These changes should be in a separate patch.
Will do!
>
>> +
>> +static irqreturn_t axp20x_irq_ac_removal(int irq, void *devid)
>> +{
>> +struct axp20x_ac_power *power = devid;
>> +
>> +dev_info(&power->supply->dev, "IRQ#%d AC disconnected\n", irq);
>> +power_supply_changed(power->supply);
>> +
>> +return IRQ_HANDLED;
>> +}
>
> Logging in the interrupt handler is usually a bad idea, for several
> reasons:
>- If you have a console, it's going to be output on the console,
> which might take quite some time. And you don't want to take
> quite some time in the interrupt handler.
>- printk might not even work in the interrupt context in some
> scenarios.
>
> Removing that handler, you can register the same interrupt handler on
> all the interrupts.
>
Oops. Yes, I will fix that!
>> +static int axp20x_ac_power_probe(struct platform_device *pdev)
>> +{
>> +struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>> +struct power_supply_config psy_cfg = {};
>> +struct axp20x_ac_power *power;
>> +static const char * const irq_names[] = { "ACIN_PLUGIN",
>> +"ACIN_REMOVAL", "ACIN_OVER_V" };
>> +irqreturn_t (*irq_funcs[])(int, void *) = { axp20x_irq_ac_plugin,
>> +axp20x_irq_ac_removal, axp20x_irq_ac_over_v };
>> +int i, irq, r, input;
>> +
>> +if (!of_device_is_available(pdev->dev.of_node))
>> +return -ENODEV;
>
> That's useless. If the device is not available, you're not going to be
> probed in the first place.
Ok.
>
>> +power = devm_kzalloc(&pdev->dev, sizeof(*power), GFP_KERNEL);
>> +if (!power)
>> +return -ENOMEM;
>> +
>> +power->regmap = axp20x->regmap;
>> +
>> +r = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
>> +if (r < 0)
>> +return r;
>> +
>> +if (!!(input & AXP20X_PWR_STATUS_AC_VBUS_SHORT)) {
>> +dev_err(&pdev->dev, "AC is connected to VBUS. Use
>> axp20x_usb_power-supply driver instead!");
>> +return -ENODEV;
>> +}
>
> Can't that change over time? Can't we support both drivers at the same time?
Both drivers are supported at the same time. I did even try with both
AC and USB connected and both return meaningful values, at least for
voltage. The AXP20x can drawn power from both sources at the same time.
The check above fires in a specific scenario where ACIN and VBUS are
physically connected on the PCB. The Datasheet states for that
particular register:
"Indicates whether ACIN/VBUS short circuits on PCB or not"
So, assuming the chip detects the condition correctly, this does not
change over that. But you can switch from ACIN to VBUS and vice-versa
just fine if they are not short-circuited. If they are connected
together, I'd prefer the DTS to only enable the usb driver. The check
above is a last resort there.
Then again, with the quality of those data sheets, one never knows.
>
>> +/* Enable ac voltage and current measurement */
>> +r = regmap_update_bits(power->regmap, AXP20X_ADC_EN1,
>> +AXP20X_ADC_EN1_ACIN_CURR | AXP20X_ADC_EN1_ACIN_VOLT,
>> +AXP20X_ADC_EN1_ACIN_CURR | AXP20X_ADC_EN1_ACIN_VOLT);
>> +if (r)
>> +return r;
>> +
>> +psy_cfg.of_node = pdev->dev.of_node;
>> +psy_cfg.drv_data = power;
>> +
>> +power->supply = devm_power_supply_register(&pdev->dev,
>> +&axp20x_ac_power_desc, &psy_cfg);
>> +if (IS_ERR(power->supply))
>> +return PTR_ERR(power->supply);
>> +
>> +/* Request irqs after registering, as irqs
[linux-sunxi] [PATCH 3/4] ARM: dts: Add binding documentation for AXP20x pmic ac power supply
Add binding documentation for the ac power supply part of the AXP20x
pmic.
Signed-off-by: Michael Haas
---
.../bindings/power_supply/axp20x_ac_power.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
new file mode 100644
index 000..1cbdcfb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
@@ -0,0 +1,34 @@
+AXP20x AC power supply
+
+Required Properties:
+-compatible: "x-powers,axp202-ac-power-supply"
+
+This node is a subnode of the axp20x PMIC.
+
+Example:
+
+axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ x-powers,dcdc-freq = <1500>;
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <145>;
+ regulator-name = "vdd-cpu";
+ };
+
+ ...
+ };
+
+ ac-power-supply: ac-power-supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
+};
--
2.8.0
--
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] [PATCH 2/4] ARM: dts: axp209: Add ac_power_supply child node to the ax209 node
Add a node representing the ac power supply part of the axp209 pmic.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/axp209.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 051ab3b..9046f0a 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -94,4 +94,10 @@
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
+
+ ac_power_supply: ac_power_supply {
+ compatible = "x-powers,axp202-ac-power-supply";
+ status = "disabled";
+ };
+
};
--
2.8.0
--
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] [PATCH 1/4] power: Add an axp20x-ac-power driver
This adds a driver for the ac power_supply bits of the axp20x
PMICs.
This submission is taken directly from Bruno Prémonts 2015 RFC [0].
The original RFC contains drivers for AC, battery and backup
battery. This commit only adds the AC driver for now.
My only change to Bruno's axp20x_ac_power.c is the additional
check on a possible short-circuit between ACIN and VBUS. In this
case, axp20x-ac-power-supply refuses to attach itself to the device
and axp20x-usb-power-supply must be used.
[0] http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980
Signed-off-by: Michael Haas
---
drivers/mfd/axp20x.c| 11 +++
drivers/power/Makefile | 2 +-
drivers/power/axp20x_ac_power.c | 212
3 files changed, 224 insertions(+), 1 deletion(-)
create mode 100644 drivers/power/axp20x_ac_power.c
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e9..9351c0e 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -178,6 +178,12 @@ static struct resource axp288_power_button_resources[] = {
},
};
+static struct resource axp20x_ac_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
+};
+
static struct resource axp288_fuel_gauge_resources[] = {
{
.start = AXP288_IRQ_QWBTU,
@@ -440,6 +446,11 @@ static struct mfd_cell axp20x_cells[] = {
.of_compatible = "x-powers,axp202-usb-power-supply",
.num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
.resources = axp20x_usb_power_supply_resources,
+ }, {
+ .name = "axp20x-ac-power-supply",
+ .of_compatible = "x-powers,axp202-ac-power-supply",
+ .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
+ .resources = axp20x_ac_power_supply_resources,
},
};
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..3a785cc 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
-obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o axp20x_ac_power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
new file mode 100644
index 000..c5bcbeb
--- /dev/null
+++ b/drivers/power/axp20x_ac_power.c
@@ -0,0 +1,212 @@
+/*
+ * AXP20x PMIC AC power driver
+ *
+ * Copyright 2014-2015 Bruno Prémont
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRVNAME "axp20x-ac-power"
+/* Fields of AXP20X_PWR_INPUT_STATUS */
+#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
+#define AXP20X_PWR_STATUS_AC_AVAILABLE BIT(6)
+#define AXP20X_PWR_STATUS_AC_VBUS_SHORT BIT(1)
+#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
+
+/* Fields of AXP20X_ADC_EN1 */
+#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
+#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
+
+struct axp20x_ac_power {
+ struct regmap *regmap;
+ struct power_supply *supply;
+};
+
+static int axp20x_ac_power_get_property(struct power_supply *psy,
+ enum power_supply_property psp, union power_supply_propval *val)
+{
+ struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
+ unsigned int input;
+ int r;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_V_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 1700; /* 1 step = 1.7 mV */
+ return 0;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ r = axp20x_read_variable_width(power->regmap,
+ AXP20X_ACIN_I_ADC_H, 12);
+ if (r < 0)
+ return r;
+
+ val->intval = r * 375; /* 1 step = 0.375 mA */
+ return 0;
+ default:
+ break;
+ }
+
+ /* All the properties below need the inp
[linux-sunxi] [PATCH 4/4] ARM: dts: sunxi: add ac-power to A20 OLinuXino Lime2 board
The A20-olinuxino-lime2 has an AC power input.
This patch enables support for current and voltage monitoring
via the axp20x-ac-power driver.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 9303635..ed83365 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -166,6 +166,10 @@
usb_power_supply: usb_power_supply {
compatible = "x-powers,axp202-usb-power-supply";
};
+ ac_power_supply: ac_power_supply {
+ status = "okay";
+ compatible = "x-powers,axp202-ac-power-supply";
+ };
};
};
--
2.8.0
--
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] Re: [PATCH 3/3] sunxi: A20-OLinuXino-LIME2: Add i2c2 bus in DTS
Hello Maxime,
thank you for taking the time to review this patch set.
On 04/02/2016 12:34 PM, Maxime Ripard wrote:
> Hi,
>
> On Fri, Mar 25, 2016 at 08:04:07PM +0100, Michael Haas wrote:
>> The A20 processor provides a third I2C bus on pins PB20 and PB21.
>> The A20-OLinuXino-LIME2 exposes this bus via its GPIO1 port.
>>
>> Olimex also provide a breakout board called the
>> A20-OLinuXino-LIME2-UEXT. This change is required to properly
>> support I2C on the UEXT connector found there.
>>
>> Signed-off-by: Michael Haas
>
> What are the other options on that pin? Is it something exclusively
> dedicated to i2c on the pin headers and the documentation, or is
> anyone free to use that pin for whatever he wishes?
>
> Thanks,
> Maxime
I assume you are talking about the UEXT connector, not about PB20 and
PB21. These are regular GPIO pins multiplexed with I2C, but no other
function.
Regarding UEXT: the A20-OLinuXino-LIME2-UEXT breakout board supports two
use cases here.
The first one: provide a simple adapter from the 0.05" pin headers on
the olinuxino to the more common world of 0.1" headers. In this use
case, you can plug the A20-OLinuXino-LIME2-UEXT intoany of LCD_CON or
GIO-{1,2,3} and you're good to go.
The second one: here, you want to use UEXT modules provided by Olimex.
It's a simple connector exposing I2C, SPI and UART as mentioned by
Priit. To use UEXT, you have to use GPIO-1 to get the correct pin mapping.
Regarding the official documentation provided by Olimex. The
A20-OLinuXino-Lime2_Rev_c.pdf shows the pins on GPIO-1 as PB20 and PB21.
In the schematics for the breakout board,
A20-OLinuXino-Lime2-UEXT_sch.pdf, the pins for the UEXT connector are
labeled as PB20/SCK and PB21/SDA. This acknowledges the double use.
However, PB20 and PB21 have pull-ups by default according to
A20-OLinuXino-Lime2_Rev_c.pdf,
which makes them a lot more useful as I2C than as GPIO.
What originally prompted me to submit this patch: I bought a breakout
board and a small LCD with UEXT connector together with my board. Then I
found out that it doesn't work out of the box because i2c2 is not
enabled. Since using UEXT is probably common for that particular
vendor, I believe it should be enabled by default.
Michael
--
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] Re: [PATCH 2/3] sunxi: A20-OLinuXino-LIME2: Add usb-power-supply
Hello Maxime, On 04/02/2016 12:36 PM, Maxime Ripard wrote: > Hi, > > On Fri, Mar 25, 2016 at 08:04:06PM +0100, Michael Haas wrote: >> The A20-OLinuXino-LIME2 uses the AXP209 PMIC. This patch adds the >> corresponding usb-power-supply node to the DTS. >> If CONFIG_AXP20X_POWER is set, this patch enables the >> /sys/class/power_supply/ >> diirectory. >> >> Signed-off-by: Michael Haas > Is there *any* reason to not use the AXP209 dtsi where it's already > defined? > > Thanks, > Maxime > are you asking why usb-power-supply is not enabled by default? It is entirely possible that there will never be USB power supply connected to a particular board. There is also the possibility of using just the ACIN part, for which I will be submitting a driver soon (courtesy of Bruno Prémont). On the other hand, the USB supply is probably so common that we could just enable it. A board may choose to disable it or simply ignore the issue. After all, the driver will correctly report on POWER_SUPPLY_PROP_PRESENT and POWER_SUPPLY_PROP_ONLINE. Michael -- 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] Charger/battery driver for axp20x being worked on?
Hello all, On 03/31/2016 09:06 AM, Bruno Prémont wrote: > Currently I don't have enough spare time to (actively) work on the patch > set, so feel free to pick up! > > With recent additions of support for other AXP variants some porting > work has to be done (not sure I published my latest porting attempts > with some rework to adapt to Hans's axp20x_usb_power.c) and I won't have > time/access to right device to check before mid April. I have applied your patch to my local tree. No conflicts! I'll be cleaning this up and submit it as a series. The latest patch I found [0] mentions that it's a port "on top of Hans' work". > >>>> CC'ing Hans as he implemented axp20x_usb_power.c. >>> IIRC, Hans previously said that the acin and vbus supplies should be handled >>> by separate power supply drivers. ACIN is easy to do. Just port the VBUS >>> one. >>> >> Yeah, that is very straightforward. > Just remember that some devices short-cut ACIN and VBUS, thus the ACIN > driver should only load when the AXP status bit indicates they are > distinct (maybe also having device-tree flag to indicate connector > presence when not short-cutted). I have added a check for the short-cut bit in the power status register. Regarding device-tree flag: if the device short-cuts ACIN and VBUS, the dts file should only contain the VBUS node. > >>> The charger would likely be another separate driver, either combined or >>> separate from the fuel gauge (charge level) driver. > One thing I explicitly left aside was "estimating battery capacity", the > original 3.4.x code included some heuristics for that with saving > intermediate values to AXP's registers (data registers kept alive as > long as power was present). In any case, I'd rather not get too fancy here. Maybe I'll take a stab at this in a second iteration. It looks like the "estimating battery capacity" bit would be exposed via CHARGE_FULL and CHARGE_EMPTY attributes. Getting that right is probably not that easy as you have to go through at least a single charge/discharge cycle. > > Gauge and charger should be a single driver, especially when capacity > estimation comes into play. Interesting is the part of adjusting charge > current based on AC/VBUS power source and taking VBUS's max-current into > account. Doesn't the AXP209 do that automatically? > > The RTC battery charger though can be a mostly hidden driver as all it > needs is some settings from device-tree (voltage/current) and has no > data to report. Letting the user tune voltage/current or enable/disable > the charger is a matter of taste. From my cubietruck's behavior it seems > as if charger enablement might have an impact of rtc battery's > discharge rate while device is powered-off. Do you mean that the RTC battery discharges faster when the charger is disabled and the device is powered off (and disconnected from power)? Two questions about your original patch at [0]: 1) In axp20x_fuel_gauge.c, there is lots of code commented out in axp20x_power_probe(). It seems to me that the commented out functionality is actually implemented above. Is that correct? 2) Do you remember what's missing from the power management in axp20x_fuel_gauge, e.g. in axp20x_power_suspend()? You noted that as a TODO and the references to those functions are commented out. Thanks for the input so far! Michael [0] https://groups.google.com/forum/#!topic/linux-sunxi/_XIjwZfEi2U -- 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] Charger/battery driver for axp20x being worked on?
Hello, (adding Bruno to CC) On 03/31/2016 08:24 AM, Chen-Yu Tsai wrote: >> >> Is anyone working on that? If not, I'll get started. > > There was an attempt some time ago: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295547.html Bruno had submitted a new version a year later: http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/17980 There was also a different patchset by Siarhei Siamashka: https://groups.google.com/forum/#!topic/linux-sunxi/u4Rwo630MnY Bruno, can you comment on the state of the patchset? I'd be happy to pick up where you left off. >> >> CC'ing Hans as he implemented axp20x_usb_power.c. > > IIRC, Hans previously said that the acin and vbus supplies should be handled > by separate power supply drivers. ACIN is easy to do. Just port the VBUS one. > Yeah, that is very straightforward. > The charger would likely be another separate driver, either combined or > separate from the fuel gauge (charge level) driver. I agree. Best Michael -- 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] Charger/battery driver for axp20x being worked on?
Hello all, I'd like to monitor the battery and charging status connected to my axp209. Is anyone working on that? Currently, there is only USB power supply support via drivers/power/axp20x_usb_power.c. Adding support for the charging/battery/ACIN bits should be rather straightforward. There is a rather nasty bash script which polls the axp20x via i2cget. I'd rather have a proper solution. Is anyone working on that? If not, I'll get started. Or is there an existing driver implemented by Allwinner which can be re-used? CC'ing Hans as he implemented axp20x_usb_power.c. Best Michael -- 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 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS
Am 30. März 2016 09:55:54 MESZ, schrieb Hans de Goede : >Hi, > >On 30-03-16 06:57, Michael Haas wrote: >> On 03/28/2016 03:01 PM, Hans de Goede wrote: >>>> but unless there's a real need >>>> for me to verify this, >>>> I'll simply revert the u-boot patch and enjoy working GPIO. >>> >>> Given the entire discussion in this thread, I agree that fixing this >>> in u-boot >>> is best. But I do not see reverting the u-boot patch disabling >ldo3/4 >>> by default >>> as the solution. ldo3/4 are unused on most boards, so disabling them >>> by default >>> clearly is the right thing todo IMHO. >> >> I just checked the Banana Pi, which exposes ports from bank E on its >> CON1. Admittedly, >> that's the "Camera Serial Interface", but that connector is >explicitly >> also labelled >> as supporting various GPIO pins: >http://www.bananapi.org/p/product.html > >That connector is not usable unless you've got a really special cable, >also ldo3/4 are disabled in the kernel dts, so it does not matter what >u-boot >does. > >> On the Cubietruck, there's also CN9, exposing some GPIO ports from >bank G: >> https://linux-sunxi.org/Cubietech_Cubietruck > >The Cubietruck also has ldo3/4 disabled in the kernel dts. > >> Given that there tend to be crashes on re-enabling LDO3+LDO4 and many >> boards expose affected pins (not only for CSI!): wouldn't be it be >the >> best to keep them enabled? > >s/Many boards/Lime 2/ and we still do not fully understand what is >going >on there, we just know that not enabling ldo3/4 at the u-boot level >causes issues, we do not know / understand why though. > >U-boot supports 52 boards with an axp209 pmic, yet you only name a >select >few which need ldo3/4 according to you, and for 2 of your examples the >kernel dts says differently. > >I'm not going to enable ldo3/4 by default on all boards just because >they >are needed on the Lime 2. > >Regards, > >Hans Hi Hans, You are making an excellent point. I will submit patches for the lime* boards as proposed in your earlier mail. Just to ask for some clarification: you are saying the regulators are disabled in the kernel dts files. I looked at the cubietruck dts files and the regulators are not mentioned in there. If they are not mentioned, are they turned off or do they remain in their default state, e.g the way that u-boot left them? Stepping back from kernel/u-boot issues, would it make sense to also turn on the regulators for the cubietruck? Perhaps in u-boot and the kernel? Michael -- 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 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS
On 03/28/2016 03:01 PM, Hans de Goede wrote: >> but unless there's a real need >> for me to verify this, >> I'll simply revert the u-boot patch and enjoy working GPIO. > > Given the entire discussion in this thread, I agree that fixing this > in u-boot > is best. But I do not see reverting the u-boot patch disabling ldo3/4 > by default > as the solution. ldo3/4 are unused on most boards, so disabling them > by default > clearly is the right thing todo IMHO. I just checked the Banana Pi, which exposes ports from bank E on its CON1. Admittedly, that's the "Camera Serial Interface", but that connector is explicitly also labelled as supporting various GPIO pins: http://www.bananapi.org/p/product.html On the Cubietruck, there's also CN9, exposing some GPIO ports from bank G: https://linux-sunxi.org/Cubietech_Cubietruck Given that there tend to be crashes on re-enabling LDO3+LDO4 and many boards expose affected pins (not only for CSI!): wouldn't be it be the best to keep them enabled? FWIW, Olimex did reply to my inquiry regarding misleading pin names: https://github.com/OLIMEX/OLINUXINO/issues/35#issuecomment-202823804 > I see. We used this Allwinner document as original reference design: > a20_pad_std_v1_1.pdf @ sunxi > <http://dl.linux-sunxi.org/A20/a20_pad_std_v1_1.pdf> - if you inspect > the schematic you'd notice that the signals connected to E18 and E19 > are named respectively CSI1-VCC and CSI0-VCC. Hence, this is where the > wrong naming of our processor pins came from. I'll add the proposal > for correction for the future hardware revision of the boards affected. > > The difference between our boards and other boards come from the > simple fact that their designs use 3.3V cameras, while we followed the > original reference design and used 2.8V camera in A20-SOM-EVB (we even > used the same camera - GT2005). > Michael -- 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] GPIO do not trigger interrupts
On 03/27/2016 03:42 PM, Michael Haas wrote: > Hello all, > > > I'm trying to poll() on a GPIO 'value' file on the a20-olinuxino-lime2. > As a most basic test, > I am using gpio-int-test.c [0]. Once gpio-int-test is running, I am > putting 3.3V on the GPIO pin. > The value file shows changes from 0 to 1 and back, but the IRQ never > fires as evidenced by the /proc/interrupts file. > [..] > > Any idea what's going on here? Do I have to unmask an interrupt somewhere? > It turns out I was missing Henry Paulissen's patch, which can be found here: https://groups.google.com/d/topic/linux-sunxi/2a1p-zg24RQ/discussion and on sunxi-next. Now The interrupt on gpio-266 is firing, but never seems to stop.. at least with gpio-int-test.c. I will have a closer look soon(-ish). Michael -- 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] GPIO do not trigger interrupts
Hello all, I'm trying to poll() on a GPIO 'value' file on the a20-olinuxino-lime2. As a most basic test, I am using gpio-int-test.c [0]. Once gpio-int-test is running, I am putting 3.3V on the GPIO pin. The value file shows changes from 0 to 1 and back, but the IRQ never fires as evidenced by the /proc/interrupts file. I have tried several pins where interrupts are actually defined: PC21, PC22 and PI10. Here's some output from debufs and /proc/interrupts, mainly containing details from the last test using PI10 (EINT22): laga@ivanov:~/dev/gpio$ cat /proc/interrupts | grep pio 51: 0 0 sunxi_pio_edge 1 Edge 1c0f000.mmc cd 54: 1 0 sunxi_pio_edge 4 Edge usb0-id-det 55: 0 0 sunxi_pio_edge 5 Edge usb0-vbus-det 64: 0 0 sunxi_pio_edge 14 Edge gpiolib 65: 0 0 sunxi_pio_edge 15 Edge gpiolib 72: 0 0 sunxi_pio_edge 22 Edge gpiolib laga@ivanov:~/dev/gpio$ cat /proc/interrupts | grep gpio 64: 0 0 sunxi_pio_edge 14 Edge gpiolib 65: 0 0 sunxi_pio_edge 15 Edge gpiolib 72: 0 0 sunxi_pio_edge 22 Edge gpiolib laga@ivanov:~/dev/gpio$ sudo cat /sys/kernel/debug/gpio GPIOs 0-287, platform/1c20800.pinctrl, 1c20800.pinctrl: gpio-67 (|ahci-5v ) out hi gpio-81 (|usb0-vbus ) out lo gpio-85 (|sysfs ) in lo IRQ gpio-86 (|sysfs ) in lo IRQ gpio-87 (|sysfs ) in hi gpio-225 (|cd ) in lo IRQ gpio-226 (|? ) out hi gpio-227 (|usb2-vbus ) out hi gpio-228 (|usb0_id_det ) in hi IRQ gpio-229 (|usb0_vbus_det ) in lo IRQ gpio-230 (|usb1-vbus ) out hi gpio-266 (|sysfs ) in lo IRQ Any idea what's going on here? Do I have to unmask an interrupt somewhere? Best, Michael [0] https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c -- 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 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS
On 03/26/2016 09:56 AM, Iain Paton wrote: > Having reread the A20 datasheet yesterday, something in the back of my > mind was bothering me overnight so I took some time to check this morning. > > On the lime2 schematic we see the pins labeled as follows: > > F19 : VCC_CSI0 > E18 : VCC_CSI1 > > However the A20 datasheet doesn't label them this way, instead using: > > F19 : VCC-PE : Port E Power Supply > E18 : VCC-PG : Port G Power Supply > > no mention at all of CSI. CSI just happens to be a function that can be > multiplexed onto ports E & G. > > So lets assume for a moment we don't have a CSI device, or a CSI driver > and are not using those pins for CSI functions but are instead using > their default GPIO purpose, or in the case of PG perhaps for UART3 > or UART4. > > What happens when you disable the regulator? Hopefully from the above > you'll already have worked out that you lose ports E & G when you turn > their I/O power supply off and anything multiplexed onto those ports > becomes unuseable. > Hi Iain, I took some time to go through the data sheets and your analysis is on point. I did raise an issue with Olimex via github [0]. Maybe they will update their schematics. I do have my breakout board connected to GPIO-1.. and it turns out that mostly port G is exposed on GPIO-1. I'll be reverting Hans' patch locally so I can toggle some pins today. I am sure he will contribute his own thoughts on the matter. > I've also just tested building u-boot with LDO3 & 4 voltages set to > 3.3v to be the same as CubieBoard, this works for lime2. > So it's unlikely that the 2.8v & 2.3v settings from my previous patch > make sense. The crash is actually being caused by something else, > probably sequencing, due to unnecessarily turning the regulators off. > Whatever the reason, we don't have enough information in the > datasheets to know for sure so we simply shouldn't turn them off to > begin with. I just tried that on linux and axp20x-regulator.ko refuses to set the voltage on ldo4: [ 88.914653] at24 1-0050: 2048 byte 24c16 EEPROM, writable, 16 bytes/write [ 96.893312] axp20x-i2c 0-0034: AXP20x variant AXP209 found [ 96.910631] axp20x-i2c 0-0034: AXP20X driver loaded [ 96.955579] input: axp20x-pek as /devices/platform/soc@01c0/1c2ac00.i2c/i2c-0/0-0034/axp20x-pek/input/input0 [ 96.971734] ldo4: failed to apply 330uV constraint(-22) [ 96.990646] axp20x-regulator axp20x-regulator: Failed to register ldo4 [ 97.012686] axp20x-regulator: probe of axp20x-regulator failed with error -22 Perhaps this requires another patch [1], but unless there's a real need for me to verify this, I'll simply revert the u-boot patch and enjoy working GPIO. Michael [0] https://github.com/OLIMEX/OLINUXINO/issues/35 [1] https://www.spinics.net/lists/devicetree/msg118871.html -- 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 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS
On 03/26/2016 01:58 AM, Iain Paton wrote: > On 25/03/16 19:04, Michael Haas wrote: > >> This patch implements the suggested changes. It is not enough >> to set the voltage to 280 to avoid the crash. Hence, I have >> also removed regulator-always-on. > NAK. > > If setting both min and max to 280 isn't working then I'd suggest you're > just papering over the issue and not actually solving it. > > It should be fairly clear that whenever those regulators are turned on by > some driver you're going to see the same issue, you've just delayed the > problem by removing the regulator-always-on item. > > The real problem here is people monkeying with the regulators without > understanding what they're doing, bothering to test the results, or caring > about the consequences. > > Anyway, Hans was correct in that the datasheet we have access to says that > the defaults for these regulators are undefined. > I suspect that's not the whole story though, if these regulators had random > values at powerup we'd have seen problems before now. > Most likely the values we think we know are simply incorrect plus there's > probably some element of sequencing involved - perhaps LDO4 needs turned on > first. > However I don't see sufficient detail in the datasheets to confirm any of > that, so we shouldn't assume anything. > Electrically on the lime2 LDO3 goes to VCC-PE and LDO4 to VCC-PG. Neither > groups E or G appear to be connected to anything other than gpio headers, > so this has little to do with board design, it's something internal to > the SoC that the datasheet is lacking on detail about. > > One of the reasons for the regulator-always-on being in the dts was so that > the regulator didn't get touched and so didn't break anything. > > All said and done, it only takes a minute with a multimeter to determine > actual defaults. Helpful to have multiple boards to gain some confidence > that they behave the same, but still basing values like this on tiny > sample sizes is probably unwise. > > Looking at other A20 based boards, Cubieboards for example, shows LDO3/4 > being unused and the VCC-PE/PG pins they power on the lime2 being tied > directly to 3.3v. No issues there simply because there's no way to mess > with the power to those blocks. > > The patch you really want is something like the one below which works > on my boards regardless of the presence of regulator-always-on. > Verified on four boards with u-boot 2016.03 and kernel 4.5.0. > > Whether you decide to remove regulator-always-on or not is a different > question, but please use 2.3v, or some other proven working value, for > ldo3. At least that way you have a fighting chance of the board > remaining functional when something wants to turn the regulator on. Hi Iain, thanks for the feedback. I have yet to try your patch, but I have broken out the multimeter to measure LDO3. On GPIO-2, I'm measuring 2.8V between pins 2 and 4 instead of 2.3V you seem to measuring. In my setup, I have simply removed the SD card from the lime2 to get whatever defaults are used at boot. How did you measure LDO3? Also, did you find any pins for LDO4 besides the AXP209 itelf? Mine seems to be covered in flux. Michael -- 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] [PATCH 2/3] sunxi: A20-OLinuXino-LIME2: Add usb-power-supply
The A20-OLinuXino-LIME2 uses the AXP209 PMIC. This patch adds the
corresponding usb-power-supply node to the DTS.
If CONFIG_AXP20X_POWER is set, this patch enables the /sys/class/power_supply/
diirectory.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5ff2e9..d370166 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -161,6 +161,9 @@
regulator-always-on;
};
};
+ usb_power_supply: usb_power_supply {
+ compatible = "x-powers,axp202-usb-power-supply";
+ };
};
};
--
2.7.2
--
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] [PATCH 3/3] sunxi: A20-OLinuXino-LIME2: Add i2c2 bus in DTS
The A20 processor provides a third I2C bus on pins PB20 and PB21.
The A20-OLinuXino-LIME2 exposes this bus via its GPIO1 port.
Olimex also provide a breakout board called the
A20-OLinuXino-LIME2-UEXT. This change is required to properly
support I2C on the UEXT connector found there.
Signed-off-by: Michael Haas
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d370166..17791ef 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -179,6 +179,12 @@
};
};
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
--
2.7.2
--
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] [PATCH 1/3] sunxi: A20-OLinuXino-LIME2: Fix ldo3/ldo4 in DTS
LDO3 and LDO4 are set to regulator-always-on which causes
crashes on my A20-OLinuXino-LIME2 once axp20x-i2c.ko is loaded.
This crash is observed in combination with recent versions
of Das U-Boot starting from their commit
02cc27c74f9b884b538bcd1b93342a4c05b5d608.
>commit 02cc27c74f9b884b538bcd1b93342a4c05b5d608
>Author: Hans de Goede
>Date: Sat Oct 3 15:29:24 2015 +0200
>
>sunxi: power: Change axp209 LDO3 and LDO4 default to disabled
>
>LDO3 and LDO4 are normally either unused, or used to power csi
>attached camera sensors, and as such do not need to be enabled at
>boot time.
>
>Signed-off-by: Hans de Goede
>Acked-by: Ian Campbell
Hans de Goede suggests fixing the Linux DTS file via the u-boot list:
>The regulator-always-on will cause both regulators to get turned on,
>but the min / max constraints match the datasheet constrains / the
>absolute min / max values these ldo-s can deliver, not the constraints
>which the board design puts on these.
>
>So now these ldo-s end up getting turned on at whatever voltage
>is the default (which according to the datasheet is unknown),
>where as the schematic says that if these get turned on (which
>is not necessary) they should be run at 2.8V.
>
>This dts file is the only axp209 using dts file which:
>
>1) Does not have proper constraints for LDO3 / LDO4
>2) Uses regulator-always-on; for these
>
>I would suggest fixing both, first you can try making min = max =
>280. And if that fixes things, which I expect it will, I would
>also drop the regulator-always-on from the dts, since we really
>only need to turn these on when using the csi interface in which
>case it would be up to the csi driver to explicitly turn them on.
This patch implements the suggested changes. It is not enough
to set the voltage to 280 to avoid the crash. Hence, I have
also removed regulator-always-on.
Signed-off-by: Michael Haas
CC: Hans de Goede
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..d5ff2e9 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -140,15 +140,13 @@
};
vcc_csi0: ldo3 {
- regulator-min-microvolt = <70>;
- regulator-max-microvolt = <350>;
- regulator-always-on;
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
};
vcc_csi1: ldo4 {
- regulator-min-microvolt = <125>;
- regulator-max-microvolt = <330>;
- regulator-always-on;
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
};
vdd_cpu: dcdc2 {
--
2.7.2
--
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 v4 14/24] clk: pwm: use pwm_get/set_default_xxx() helpers where appropriate
Hi Boris,
Quoting Boris Brezillon (2015-11-16 00:56:37)
> pwm_set/get_default_xxx() helpers have been introduced to differentiate
> the default PWM states (those retrieved through DT, PWM lookup table or
> statically assigned by the driver) and the current ones.
> Make use of those helpers where appropriate.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/clk/clk-pwm.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index b6306a2..642a49a 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -71,23 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pwm))
> return PTR_ERR(pwm);
>
> - if (!pwm_get_period((pwm))) {
> + if (!pwm_get_default_period((pwm))) {
The change itself looks fine, but the semantic patch added extra parens.
Can you remove them? After doing so feel free to add:
Acked-by: Michael Turquette
--
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 v4 03/24] clk: pwm: use pwm_get_xxx() helpers where appropriate
Hi Boris,
Quoting Boris Brezillon (2015-11-16 00:56:26)
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index 328fcfc..b6306a2 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -71,22 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
> if (IS_ERR(pwm))
> return PTR_ERR(pwm);
>
> - if (!pwm->period) {
> + if (!pwm_get_period((pwm))) {
The change itself looks fine, but the semantic patch added extra parens.
Can you remove them? After doing so feel free to add:
Acked-by: Michael Turquette
--
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 v6 1/5] clk: Add a basic multiplier clock
Quoting Maxime Ripard (2015-10-21 07:53:35)
> On Tue, Oct 20, 2015 at 09:29:39AM -0700, Michael Turquette wrote:
> > Quoting Maxime Ripard (2015-10-20 07:40:47)
> > > Hi Mike,
> > >
> > > On Tue, Oct 20, 2015 at 06:43:43AM -0700, Michael Turquette wrote:
> > > > Hi Maxime,
> > > >
> > > > Quoting Maxime Ripard (2015-10-20 00:36:45)
> > > > > +struct clk *clk_register_multiplier(struct device *dev, const char
> > > > > *name,
> > > > > + const char *parent_name,
> > > > > + unsigned long flags,
> > > > > + void __iomem *reg, u8 shift, u8
> > > > > width,
> > > > > + u8 clk_mult_flags, spinlock_t
> > > > > *lock)
> > > > > +{
> > > >
> > > > Patch looks good in general. However this is a good opportunity to stop
> > > > the madness around the registration functions in these basic clock
> > > > types.
> > > >
> > > > clk_register is really all that we need since we've had struct
> > > > clk_init_data for a while. Initializing a multiplier should be as simple
> > > > as:
> > > >
> > > > struct clk_multiplier clk_foo = {
> > > > .hw.init = &(struct clk_init_data){
> > > > .name = "foo",
> > > > .parent_names = (const char *[]){
> > > > "bar",
> > > > },
> > > > .num_parents = 1;
> > > > .ops = &clk_multiplier_ops,
> > > > },
> > > > .reg = 0xd34db33f,
> > > > .shift = 1,
> > > > .width = 2,
> > > > };
> > > >
> > > > clk_register(dev, &clk_foo.hw);
> > > >
> > > > This is nice since it turns these basic clocks into even more of a
> > > > library and less of a poor mans driver.
> > > >
> > > > (I really hope the above works. I did not test it)
> > > >
> > > > Is it possible you can convert to using this method, and if it is
> > > > correct for you then just remove clk_multiplier_register altogether? (In
> > > > fact you might not use the registration function at all since you use
> > > > the composite clock...)
> > >
> > > This chunk of code has been here since v2, which has been first posted
> > > in May, two and half kernel releases ago.
> > >
> > > In the meantime, we had a full-blown DMA driver and a quite unusual
> > > ASoC driver merged. For some reason, this is the only piece of the
> > > audio support that is missing for us, while at the same time it's the
> > > most trivial.
> > >
> > > If that's the only issue you have with this patch, I'm fine with
> > > sending a subsequent patch this week. But I'd be really unhappy with
> > > sending yet another version for a single change, while you had 5
> > > monthes to review it, and we discussed it several times on IRC and
> > > face to face.
> >
> > The change can go in later. It's not a prerequisite. I had a feeling
> > you'd be grumpy about me asking but I thought I'd try anyways. I won't
> > even ask if you got sign-off from Jim on whether this works for his
> > platforms ;-)
>
> I asked several times, he never replied... :/
>
> > The copy/paste nature of these basic clock types really sucks and it is
> > one of many reasons that I am hesitant to accept them and slow to merge
> > them...
>
> I guess we cover all cases now? So it shouldn't grow that much.
>
> > Anyways it seems that you are not using the registration function at all
> > so I might just follow up with a patch to remove it.
> >
> > I can pick these 5 patches directly, or do you plan to send a PR?
>
> I have a pull request coming for you with a single patch, I can apply
> them on that branch and send you the PR later today if it's okay?
Sounds good to me.
Regards,
Mike
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
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 v6 1/5] clk: Add a basic multiplier clock
Quoting Maxime Ripard (2015-10-20 07:40:47)
> Hi Mike,
>
> On Tue, Oct 20, 2015 at 06:43:43AM -0700, Michael Turquette wrote:
> > Hi Maxime,
> >
> > Quoting Maxime Ripard (2015-10-20 00:36:45)
> > > +struct clk *clk_register_multiplier(struct device *dev, const char *name,
> > > + const char *parent_name,
> > > + unsigned long flags,
> > > + void __iomem *reg, u8 shift, u8 width,
> > > + u8 clk_mult_flags, spinlock_t *lock)
> > > +{
> >
> > Patch looks good in general. However this is a good opportunity to stop
> > the madness around the registration functions in these basic clock
> > types.
> >
> > clk_register is really all that we need since we've had struct
> > clk_init_data for a while. Initializing a multiplier should be as simple
> > as:
> >
> > struct clk_multiplier clk_foo = {
> > .hw.init = &(struct clk_init_data){
> > .name = "foo",
> > .parent_names = (const char *[]){
> > "bar",
> > },
> > .num_parents = 1;
> > .ops = &clk_multiplier_ops,
> > },
> > .reg = 0xd34db33f,
> > .shift = 1,
> > .width = 2,
> > };
> >
> > clk_register(dev, &clk_foo.hw);
> >
> > This is nice since it turns these basic clocks into even more of a
> > library and less of a poor mans driver.
> >
> > (I really hope the above works. I did not test it)
> >
> > Is it possible you can convert to using this method, and if it is
> > correct for you then just remove clk_multiplier_register altogether? (In
> > fact you might not use the registration function at all since you use
> > the composite clock...)
>
> This chunk of code has been here since v2, which has been first posted
> in May, two and half kernel releases ago.
>
> In the meantime, we had a full-blown DMA driver and a quite unusual
> ASoC driver merged. For some reason, this is the only piece of the
> audio support that is missing for us, while at the same time it's the
> most trivial.
>
> If that's the only issue you have with this patch, I'm fine with
> sending a subsequent patch this week. But I'd be really unhappy with
> sending yet another version for a single change, while you had 5
> monthes to review it, and we discussed it several times on IRC and
> face to face.
The change can go in later. It's not a prerequisite. I had a feeling
you'd be grumpy about me asking but I thought I'd try anyways. I won't
even ask if you got sign-off from Jim on whether this works for his
platforms ;-)
The copy/paste nature of these basic clock types really sucks and it is
one of many reasons that I am hesitant to accept them and slow to merge
them...
Anyways it seems that you are not using the registration function at all
so I might just follow up with a patch to remove it.
I can pick these 5 patches directly, or do you plan to send a PR?
Regards,
Mike
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
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 v6 1/5] clk: Add a basic multiplier clock
Hi Maxime,
Quoting Maxime Ripard (2015-10-20 00:36:45)
> +struct clk *clk_register_multiplier(struct device *dev, const char *name,
> + const char *parent_name,
> + unsigned long flags,
> + void __iomem *reg, u8 shift, u8 width,
> + u8 clk_mult_flags, spinlock_t *lock)
> +{
Patch looks good in general. However this is a good opportunity to stop
the madness around the registration functions in these basic clock
types.
clk_register is really all that we need since we've had struct
clk_init_data for a while. Initializing a multiplier should be as simple
as:
struct clk_multiplier clk_foo = {
.hw.init = &(struct clk_init_data){
.name = "foo",
.parent_names = (const char *[]){
"bar",
},
.num_parents = 1;
.ops = &clk_multiplier_ops,
},
.reg = 0xd34db33f,
.shift = 1,
.width = 2,
};
clk_register(dev, &clk_foo.hw);
This is nice since it turns these basic clocks into even more of a
library and less of a poor mans driver.
(I really hope the above works. I did not test it)
Is it possible you can convert to using this method, and if it is
correct for you then just remove clk_multiplier_register altogether? (In
fact you might not use the registration function at all since you use
the composite clock...)
Regards,
Mike
--
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] Allwinner GPL violations: definitive proof.
On Wednesday, February 25, 2015 at 4:15:38 AM UTC-8, Simos Xenitellis wrote: > On Wed, Feb 25, 2015 at 5:55 AM, Luc Verhaegen wrote: > > > > Allwinner, it is very high time to start playing nice. You've been at it > > for 4 years now and seem utterly incapable of or unwilling to change. > > I think it's time for Luc to start playing nice. His toxic behavior > does not help. > Trying to berate both on list and off list, even new members to this > Google group, > is unacceptable behavior. > It makes me wonder whether his abrasive behavior was actually a factor > to the situation that we try to solve here. > It's very ironic as well! > > We see constructive efforts from Allwinner to fix issues > and it makes sense for the community to be constructive as well. > I do not even see an issue filed at > https://github.com/allwinner-zh/media-codec/issues > > Being constructive and nice takes you a long way, > Simos Instead of whining about him calling you out on your years of noncompliance how about you start doing your fucking job. I hope someone with standing takes this to court and sues for damages as it is the only way anything will happen in a reasonable time frame. -- 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: [U-Boot] [PATCH 6/7] ARM: sun6i: Setup the A31 UART0 muxing
Hi Il 08/set/2014 15:36 "Chen-Yu Tsai" ha scritto: > > From: Maxime Ripard > > Signed-off-by: Maxime Ripard > Signed-off-by: Hans de Goede > [w...@csie.org: commit message was "ARM: sunxi: Setup the A31 UART0 muxing"] > Signed-off-by: Chen-Yu Tsai > --- > arch/arm/cpu/armv7/sunxi/board.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c > index f2cedbb..fc6aa4b 100644 > --- a/arch/arm/cpu/armv7/sunxi/board.c > +++ b/arch/arm/cpu/armv7/sunxi/board.c > @@ -54,6 +54,10 @@ int gpio_init(void) > sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB22_UART0_TX); > sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB23_UART0_RX); > sunxi_gpio_set_pull(SUNXI_GPB(23), 1); > +#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_SUN6I) > + sunxi_gpio_set_cfgpin(SUNXI_GPH(20), 2); > + sunxi_gpio_set_cfgpin(SUNXI_GPH(21), 2); > + sunxi_gpio_set_pull(SUNXI_GPH(21), 1); > #elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_SUN5I) > sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN5I_GPB19_UART0_TX); > sunxi_gpio_set_cfgpin(SUNXI_GPB(20), SUN5I_GPB20_UART0_RX); > -- > 2.1.0 > I don't know if it is correct that every architecture has a specific function to MUX, but can we define what is 2 2 and 1? Michael > ___ > U-Boot mailing list > u-b...@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- 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] Update cubieboard2/cubietruck dcdc2/dcdc3 voltages and dvfs data
Just an idea: Can the convince the most popular distros to add an automatic stability test which sends the data to a server? It could be advertised by e.g. the mod banner. I think thatn then we could become enough data to set this right. What a pitty that AllWinner can't provide us with safe numbers... 2014-05-13 0:47 GMT+02:00 Siarhei Siamashka : > On Sun, 11 May 2014 22:58:31 +0200 > Hans de Goede wrote: > > > Hi, > > > > On 05/11/2014 10:43 PM, Hans de Goede wrote: > > > Hi, > > > > > > On 05/11/2014 11:53 AM, Siarhei Siamashka wrote: > > >> It has been confirmed that a substantial percentage of cubieboard2 > > >> and cubietruck users are having stability issues. These issues are > > >> caused by having various voltages optimistically configured way too > > >> low. Because each unit has its own tolerances, not everyone can > > >> easily reproduce these problems. > > >> > > >> To address the issue, we take the updated settings from: > > >> > https://github.com/cubieboard/cubie_configs/tree/09e511721697/sysconfig/linux > > >> This repository is relevant because it is referenced from: > > >> > http://docs.cubieboard.org/tutorials/ct1/development/compiling_latest_kernel_for_cubietruck_cubieboard3 > > >> Please note that there is also a sunxi-boards repository fork at > > >> https://github.com/cubieboard (with bad settings) and this makes > > >> things more confusing than necessary. > > >> > > >> Signed-off-by: Siarhei Siamashka > > >> --- > > >> sys_config/a20/cubieboard2.fex | 18 +- > > >> sys_config/a20/cubietruck.fex | 16 > > >> 2 files changed, 17 insertions(+), 17 deletions(-) > > >> > > >> diff --git a/sys_config/a20/cubieboard2.fex > b/sys_config/a20/cubieboard2.fex > > >> index 1436df8..c8c9c74 100644 > > >> --- a/sys_config/a20/cubieboard2.fex > > >> +++ b/sys_config/a20/cubieboard2.fex > > >> @@ -1,14 +1,14 @@ > > >> [product] > > >> version = "100" > > >> -machine = "cubieboard" > > >> +machine = "cubieboard2" > > >> > > >> [platform] > > >> eraseflag = 0 > > >> > > >> [target] > > >> boot_clock = 912 > > >> -dcdc2_vol = 1400 > > >> -dcdc3_vol = 1250 > > >> +dcdc2_vol = 1450 > > > > > > This makes no sense, since in the dvfs table there is: > > > max_freq = 91200 > > > LV2_freq = 91200 > > > LV2_volt = 1425 > > My understanding is that the dcdc2_vol voltage value is in use in > the case if cpufreq is disabled and when the dvfs part of fex has > no effect. So I think that it tries to play defensively and > safeguard against the bootloader setting something like: > LV1_freq = 100800 > LV1_volt = 1450 > > Sure, in u-boot-sunxi we have the following code, which is hardcoding > the CPU clock frequency to 912MHz: > > #ifdef CONFIG_SUN7I > clock_set_pll1(91200); > #else > clock_set_pll1(100800); > #endif > > However this fex and u-boot interaction and implicit dependency > is quite nasty. It has already bitten us in the butt with the > u-boot setting dcdc3 to 1.3V and fex reverting it back to 1.25V > > Anyway, what do you suggest? > > > > S0 1.425 volt would make a lot more sense. Also Page 31 > > > of A20+Datasheet+v1.0+20130227.pdf says that the MAX > > > CPU and systemvoltage is 1425 volts. So what this patch > > > effectively does is overvolt the CPU cores and base system. > > > > > > Now overvolting is a well know trick when doing overclocking, > > > the question is do we really want to ship a config which > > > overvolts by default? > > The A10 datasheet says that the VDD voltage limit is 1.3V, however > this is not stopping anyone from using 1.4V on A10. > > The kernel sources and documentation are full of bullshit numbers. > Apparently almost everything has to be found by the trial and > error method. > > > > My first instinctive reaction is no we don't. But if this > > > cures our stability issues, then I think it makes sense to > > > do so, in this case u-boot should be changed to init the > > > cpu voltage to 1.425 volt by default too. > > Maybe. > > > Note all these new settings significantly exceed the > > official allwinner settings / the settings found in any > > other a20 device fex file. > > What are the official allwinner settings? > > > If we want to make these changes, we should probably change > > this for all boards. > > The situation is pretty much out of control. Having these > settings in the fex files allows the device manufacturers or > distro/image maintainers to hurt themselves and their users > quite easily. And they already do it. > > I have already said this before: IMHO the only solution to > contain the damage is the availability of hardware reliability > testing tools. > > > Follow up question, have you tried overvolting your A10 Lime > > to 1.425 volt to see if that fixes the L2 cache issues you've > > been seeing there. > > Yes > > > I know you said 1.450 volt fixes it, but I wonder if 1.425 volt > > fixes it too > > No. In fact even running with 1.450V and 1008MHz c
[linux-sunxi] [cubietruck - AXP209] Is there any way for MPPT support when charging li-ion battery?
Hi, My project is a solar driven cubietruck for 24/7 with a 5volt 1.5A solar panel and 3.7V / 27.2Ah li-ion battery. When I measure the inut voltage (and current) via "/sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20-supplyer.28/power_supply/battery/voltage_now (and current_now)" and my battery is charging, I see the input voltage from the solar panel drop to 4.0 volt, sometimes to 3.7 volt on cloudy days. I think that at these conditions the axp209 just switching betwen charging and discharging, so the 3.7 volt input is just "helping" the battery to power the board. So my question is, is there any way to implement an MPPT (Maximum Power Point Tracking) approach? When a battery is connected, measure the input "I" and "U" to get "P" and increase "I charge" until input "P" goes down and decrease "I charge" in the same way? In that way it would be much more efficient. Greets, mike PS: This is my first post here, I apologize if I did something wrong to post my idea/question here. -- 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.
