[linux-sunxi] Re: [PATCH] i2c: mv64xxx: Add runtime PM support
Hello Samuel,
On Thu, Jan 28, 2021 at 10:22:08AM +0100, Wolfram Sang wrote:
> On Sun, Jan 03, 2021 at 04:51:46AM -0600, Samuel Holland wrote:
> > To save power, gate the clock when the bus is inactive, during system
> > sleep, and during shutdown. On some platforms, specifically Allwinner
> > A13/A20, gating the clock implicitly resets the module as well. Since
> > the module already needs to be reset after some suspend/resume cycles,
> > it is simple enough to reset it during every runtime suspend/resume.
> >
> > Because the bus may be used by wakeup source IRQ threads, it needs to
> > be functional as soon as IRQs are enabled. Thus, its system PM hooks
> > need to run in the noirq phase.
> >
> > Signed-off-by: Samuel Holland
Tested-by: Ondrej Jirman
I tried it on H3, H5, H6, A64, A83T and A13 based devices. This time it works on
my A13 pocketbook, too.
I get "mmc_erase: group start error -110, status 0x0" in dmesg on my 2 Orange Pi
3's soon after boot on 5.11-rc4 + this patch. Though I do get these without this
patch too. So those timeouts are unrelated.
I think it's comming from some f2fs background gc job doing trim and mmc
sometimes times out during that. It doesn't lead to corruption.
kind regards,
o.
> Gregory, what do you think?
>
> > ---
> > drivers/i2c/busses/i2c-mv64xxx.c | 120 ---
> > 1 file changed, 78 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> > b/drivers/i2c/busses/i2c-mv64xxx.c
> > index 5cfe70aedced..b03c344323d1 100644
> > --- a/drivers/i2c/busses/i2c-mv64xxx.c
> > +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -717,6 +718,10 @@ mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct
> > i2c_msg msgs[], int num)
> > struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
> > int rc, ret = num;
> >
> > + rc = pm_runtime_resume_and_get(&adap->dev);
> > + if (rc)
> > + return rc;
> > +
> > BUG_ON(drv_data->msgs != NULL);
> > drv_data->msgs = msgs;
> > drv_data->num_msgs = num;
> > @@ -732,6 +737,9 @@ mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct
> > i2c_msg msgs[], int num)
> > drv_data->num_msgs = 0;
> > drv_data->msgs = NULL;
> >
> > + pm_runtime_mark_last_busy(&adap->dev);
> > + pm_runtime_put_autosuspend(&adap->dev);
> > +
> > return ret;
> > }
> >
> > @@ -828,7 +836,6 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
> > rc = PTR_ERR(drv_data->rstc);
> > goto out;
> > }
> > - reset_control_deassert(drv_data->rstc);
> >
> > /* Its not yet defined how timeouts will be specified in device tree.
> > * So hard code the value to 1 second.
> > @@ -893,6 +900,32 @@ static int mv64xxx_i2c_init_recovery_info(struct
> > mv64xxx_i2c_data *drv_data,
> > return 0;
> > }
> >
> > +static int
> > +mv64xxx_i2c_runtime_suspend(struct device *dev)
> > +{
> > + struct mv64xxx_i2c_data *drv_data = dev_get_drvdata(dev);
> > +
> > + reset_control_assert(drv_data->rstc);
> > + clk_disable_unprepare(drv_data->reg_clk);
> > + clk_disable_unprepare(drv_data->clk);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +mv64xxx_i2c_runtime_resume(struct device *dev)
> > +{
> > + struct mv64xxx_i2c_data *drv_data = dev_get_drvdata(dev);
> > +
> > + clk_prepare_enable(drv_data->clk);
> > + clk_prepare_enable(drv_data->reg_clk);
> > + reset_control_reset(drv_data->rstc);
> > +
> > + mv64xxx_i2c_hw_init(drv_data);
> > +
> > + return 0;
> > +}
> > +
> > static int
> > mv64xxx_i2c_probe(struct platform_device *pd)
> > {
> > @@ -920,18 +953,22 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> >
> > /* Not all platforms have clocks */
> > drv_data->clk = devm_clk_get(&pd->dev, NULL);
> > - if (PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > - if (!IS_ERR(drv_data->clk))
> > - clk_prepare_enable(drv_data->clk);
> > + if (IS_ERR(drv_data->clk)) {
> > + if (PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + drv_data->clk = NULL;
> > + }
> >
> > drv_data->reg_clk = devm_clk_get(&pd->dev, "reg");
> > - if (PTR_ERR(drv_data->reg_clk) == -EPROBE_DEFER)
> > - return -EPROBE_DEFER;
> > - if (!IS_ERR(drv_data->reg_clk))
> > - clk_prepare_enable(drv_data->reg_clk);
> > + if (IS_ERR(drv_data->reg_clk)) {
> > + if (PTR_ERR(drv_data->reg_clk) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + drv_data->reg_clk = NULL;
> > + }
> >
> > drv_data->irq = platform_get_irq(pd, 0);
> > + if (drv_data->irq < 0)
> > + return drv_data->irq;
> >
> > if (pdata) {
> > drv_data->freq_m = pdata->freq_m;
> > @@ -942,16 +979,12 @@ mv64xxx_i2c_probe(struct platform_devi
[linux-sunxi] Re: [PATCH] RFC: arm64: arch_timer: Fix timer inconsistency test for A64
Hello Roman,
On Tue, Sep 29, 2020 at 02:13:47PM +0300, Roman Stratiienko wrote:
> Fixes linux_kselftest:timers_inconsistency-check_arm_64
>
> Test logs without the fix:
> '''
> binary returned non-zero. Exit code: 1, stderr: , stdout:
> Consistent CLOCK_REALTIME
> 1601335525:467086804
> 1601335525:467087554
> 1601335525:467088345
> 1601335525:467089095
> 1601335525:467089887
> 1601335525:467090637
> 1601335525:467091429
> 1601335525:467092179
> 1601335525:467092929
> 1601335525:467093720
> 1601335525:467094470
> 1601335525:467095262
> 1601335525:467096012
> 1601335525:467096804
>
> 1601335525:467097554
> 1601335525:467077012
>
> 1601335525:467099095
> 1601335525:467099845
> 1601335525:467100637
> 1601335525:467101387
> 1601335525:467102179
> 1601335525:467102929
> '''
Can you reproduce the issue with a fixed CPU frequency. I suspect the root
cause is around CPU frequency scaling code on A64, and timer jumps happen when
the kernel is changing CPU frequency.
I fixed a similar issue on H3 SoC just by changing the CPU frequency scaling
code, without having to touch the timer readout code.
https://megous.com/git/linux/commit/?h=ths-5.9&id=51ff1a6d80126f678efca42555f93efa611f50c4
regards,
o.
> Signed-off-by: Roman Stratiienko
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-ker...@vger.kernel.org
> CC: linux-sunxi@googlegroups.com
> CC: meg...@megous.com
> ---
> drivers/clocksource/arm_arch_timer.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 6c3e841801461..d50aa43cb654b 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -346,16 +346,17 @@ static u64 notrace arm64_858921_read_cntvct_el0(void)
> * number of CPU cycles in 3 consecutive 24 MHz counter periods.
> */
> #define __sun50i_a64_read_reg(reg) ({
> \
> - u64 _val; \
> + u64 _val1, _val2; \
> int _retries = 150; \
> \
> do {\
> - _val = read_sysreg(reg);\
> + _val1 = read_sysreg(reg); \
> + _val2 = read_sysreg(reg); \
> _retries--; \
> - } while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries);\
> + } while (((_val2 - _val1) > 0x10) && _retries); \
> \
> WARN_ON_ONCE(!_retries);\
> - _val; \
> + _val2; \
> })
>
> static u64 notrace sun50i_a64_read_cntpct_el0(void)
> --
> 2.25.1
>
--
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/20200929113519.b2vydqmhcivvbwom%40core.my.home.
[linux-sunxi] Re: [PATCH] mfd: sun4i-gpadc: Interrupt numbers should start from 1
Hello Maxime, On Thu, Sep 17, 2020 at 03:19:04PM +0200, Maxime Ripard wrote: > Hi, > > On Sat, Sep 12, 2020 at 01:22:00PM +0200, Ondrej Jirman wrote: > > mfd: sun4i-gpadc: Interrupt numbers should start from 1 > > Why? An hwirq with 0 is totally fine > > > This avoids a warning: > > > > [2.891592] [ cut here ] > > [2.895052] WARNING: CPU: 0 PID: 149 at drivers/base/platform.c:317 > > __platform_get_irq_byname+0x7c/0x8c > > [2.903212] usb 1-1: new high-speed USB device number 2 using > > ehci-platform > > [2.908930] 0 is an invalid IRQ number > > [2.911425] Modules linked in: sun4i_gpadc_iio(+) r8188eu(C) lib80211 > > ohci_platform ohci_hcd ehci_platform ehci_hcd cyttsp4_i2c cyttsp_i2c_common > > cyttsp4_core g_cdc usb_f_acm u_serial usb_f_ecm u_ether libcomposite sunxi > > phy_generic musb_hdrc udc_core usbcore sun5ieink > > [2.934048] CPU: 0 PID: 149 Comm: tablet-init Tainted: G C > > 5.8.0-rc2-00316-gc6a5213fdeba-dirty #8 > > [2.943027] Hardware name: Allwinner sun4i/sun5i Families > > [2.947204] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > [2.953714] [] (show_stack) from [] > > (__warn+0xc0/0xd8) > > [2.959364] [] (__warn) from [] > > (warn_slowpath_fmt+0x84/0x94) > > [2.965599] [] (warn_slowpath_fmt) from [] > > (__platform_get_irq_byname+0x7c/0x8c) > > [2.973480] [] (__platform_get_irq_byname) from [] > > (platform_get_irq_byname+0x10/0x48) > > [2.981896] [] (platform_get_irq_byname) from [] > > (sun4i_irq_init+0x38/0xe0 [sun4i_gpadc_iio]) > > [2.990923] [] (sun4i_irq_init [sun4i_gpadc_iio]) from > > [] (sun4i_gpadc_probe+0x234/0x308 [sun4i_gpadc_iio]) > > [3.001152] [] (sun4i_gpadc_probe [sun4i_gpadc_iio]) from > > [] (platform_drv_probe+0x48/0x98) > > [3.010051] [] (platform_drv_probe) from [] > > (really_probe+0x1e0/0x348) > > [3.017152] [] (really_probe) from [] > > (driver_probe_device+0x5c/0xb4) > > [3.024081] [] (driver_probe_device) from [] > > (device_driver_attach+0x58/0x60) > > [3.031696] [] (device_driver_attach) from [] > > (__driver_attach+0x58/0xcc) > > [3.038966] [] (__driver_attach) from [] > > (bus_for_each_dev+0x64/0x90) > > [3.045886] [] (bus_for_each_dev) from [] > > (bus_add_driver+0x15c/0x1e0) > > [3.052892] [] (bus_add_driver) from [] > > (driver_register+0x7c/0x114) > > [3.059731] [] (driver_register) from [] > > (do_one_initcall+0x44/0x194) > > [3.066696] [] (do_one_initcall) from [] > > (do_init_module+0x5c/0x220) > > [3.073568] [] (do_init_module) from [] > > (load_module+0x20ec/0x2380) > > [3.080340] [] (load_module) from [] > > (sys_init_module+0x134/0x154) > > [3.087020] [] (sys_init_module) from [] > > (ret_fast_syscall+0x0/0x54) > > [3.093852] Exception stack(0xc8ea7fa8 to 0xc8ea7ff0) > > [3.097649] 7fa0: b6fe2000 3b14 > > 00031284 0005 > > [3.104596] 7fc0: b6fe2000 0080 00052220 be9fd940 > > 00052246 002e > > [3.111626] 7fe0: be9fd79c be9fd780 00015bd0 0001dcf4 > > [3.115468] ---[ end trace df4dd47fb61bf5a4 ]--- > > In which situation? During boot. It's a new check added in Linux 5.8. https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L317 > > Signed-off-by: Ondrej Jirman > > --- > > include/linux/mfd/sun4i-gpadc.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/mfd/sun4i-gpadc.h > > b/include/linux/mfd/sun4i-gpadc.h > > index ea0ccf33a459..021f820f9d52 100644 > > --- a/include/linux/mfd/sun4i-gpadc.h > > +++ b/include/linux/mfd/sun4i-gpadc.h > > @@ -81,8 +81,8 @@ > > #define SUN4I_GPADC_TEMP_DATA 0x20 > > #define SUN4I_GPADC_DATA 0x24 > > > > -#define SUN4I_GPADC_IRQ_FIFO_DATA 0 > > -#define SUN4I_GPADC_IRQ_TEMP_DATA 1 > > +#define SUN4I_GPADC_IRQ_FIFO_DATA 1 > > +#define SUN4I_GPADC_IRQ_TEMP_DATA 2 > > Where is it coming from, and why is it the proper fix? Actual numbers seem irrelevant. It's just an index into this array: https://elixir.bootlin.com/linux/latest/source/drivers/mfd/sun4i-gpadc.c#L27 The array will get sparse, but that doesn't seem like an issue to me, because the irq code handles the holes in the list if mask is 0. Not sure it's the best fix. regards, o. > Maxime -- 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/20200917140117.jowpyurs5pjyr2if%40core.my.home.
[linux-sunxi] Re: [PATCH] RFC: sun4i/drm: Swap back U and V channels for DRM_FORMAT_YVU4xx
On Tue, Sep 01, 2020 at 11:30:47PM +0300, Roman Stratiienko wrote:
> Fixes: e1ef9006663b ("drm/sun4i: Wire in DE2 YUV support")
> Signed-off-by: Roman Stratiienko
>
> ---
> CC: meg...@megous.com
> CC: jernej.skra...@gmail.com
> CC: linux-sunxi@googlegroups.com
> CC: dri-de...@lists.freedesktop.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-ker...@vger.kernel.org
>
> Hi, this patch fixes wrong colors during video playback for me.
> Implemented ugly for now, please review/suggest how to improve.
Why do you think the issue is at DRM level? Have you tried displaying a known
color image via a vi layer, and was it wrong?
I used DRM with YUV data in the past, and didn't notice any weird colors,
so I'm a bit skeptical.
regards,
o.
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 8 +++-
> drivers/gpu/drm/sun4i/sun8i_mixer.h| 2 +-
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 28 +++---
> 4 files changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index dce40c430100..bbbeef44899a 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -31,6 +31,7 @@
> struct de2_fmt_info {
> u32 drm_fmt;
> u32 de2_fmt;
> + boolswap_uv;
> };
>
> static bool hw_preconfigured;
> @@ -219,14 +220,17 @@ static const struct de2_fmt_info de2_formats[] = {
> {
> .drm_fmt = DRM_FORMAT_YVU422,
> .de2_fmt = SUN8I_MIXER_FBFMT_YUV422,
> + .swap_uv = true,
> },
> {
> .drm_fmt = DRM_FORMAT_YVU420,
> .de2_fmt = SUN8I_MIXER_FBFMT_YUV420,
> + .swap_uv = true,
> },
> {
> .drm_fmt = DRM_FORMAT_YVU411,
> .de2_fmt = SUN8I_MIXER_FBFMT_YUV411,
> + .swap_uv = true,
> },
> {
> .drm_fmt = DRM_FORMAT_P010,
> @@ -238,13 +242,15 @@ static const struct de2_fmt_info de2_formats[] = {
> },
> };
>
> -int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format)
> +int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format, bool *swap_uv)
> {
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(de2_formats); ++i)
> if (de2_formats[i].drm_fmt == format) {
> *hw_format = de2_formats[i].de2_fmt;
> + if (swap_uv)
> + *swap_uv = de2_formats[i].swap_uv;
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> index 79a74bca1ea3..6358ffd251f9 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -207,5 +207,5 @@ sun8i_channel_base(struct sun8i_mixer *mixer, int channel)
> return DE2_CH_BASE + channel * DE2_CH_SIZE;
> }
>
> -int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format);
> +int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format, bool *swap_uv);
> #endif /* _SUN8I_MIXER_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> index a7f21f08ec89..57bbd9f1071c 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -215,7 +215,7 @@ static int sun8i_ui_layer_update_formats(struct
> sun8i_mixer *mixer, int channel,
> ch_base = sun8i_channel_base(mixer, channel);
>
> fmt = state->fb->format;
> - ret = sun8i_mixer_drm_format_to_hw(fmt->format, &hw_fmt);
> + ret = sun8i_mixer_drm_format_to_hw(fmt->format, &hw_fmt, NULL);
> if (ret || fmt->is_yuv) {
> DRM_DEBUG_DRIVER("Invalid format\n");
> return -EINVAL;
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> index 3553e38ec642..4da51155c4d5 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -313,7 +313,7 @@ static int sun8i_vi_layer_update_formats(struct
> sun8i_mixer *mixer, int channel,
> ch_base = sun8i_channel_base(mixer, channel);
>
> fmt = state->fb->format;
> - ret = sun8i_mixer_drm_format_to_hw(fmt->format, &hw_fmt);
> + ret = sun8i_mixer_drm_format_to_hw(fmt->format, &hw_fmt, NULL);
> if (ret) {
> DRM_DEBUG_DRIVER("Invalid format\n");
> return ret;
> @@ -368,8 +368,17 @@ static int sun8i_vi_layer_update_buffer(struct
> sun8i_mixer *mixer, int channel,
> struct drm_gem_cma_object *gem;
> u32 dx, dy, src_x, src_y;
> dma_addr_t paddr;
> + bool swap_uv;
> u32 ch_base;
> - int i;
> + u32 hw_fmt;
> + int ret;
> + int i, j;
> +
> + ret = sun8i_mixer_drm_format_to_hw(plane->state->fb->format->format,
> &hw_fmt, &swap_uv);
> + if (ret) {
> + DRM_
Re: [linux-sunxi] [PATCH] drm/sun4i: Fix dsi dcs long write function
On Fri, Aug 28, 2020 at 02:35:26PM +0200, Jernej Škrabec wrote:
> Dne petek, 28. avgust 2020 ob 13:24:44 CEST je Ondrej Jirman napisal(a):
> > It's writing too much data. regmap_bulk_write expects number of
> > register sized chunks to write, not a byte sized length of the
> > bounce buffer. Bounce buffer needs to be padded too, so that
> > regmap_bulk_write will not read past the end of the buffer.
> >
> > Signed-off-by: Ondrej Jirman
>
> Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller
> support")
It doesn't really fix anything user visible though, and will not help
the stable branch in any way. It just makes the code more correct.
Though now that you came up with the tag, copypasting it is not that much
work. ;) So I added it.
> should be added. Fix will be then automatically picked into stable releases.
>
> Small nit below.
>
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c index 7f13f4d715bf..840fad1b68dd
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> > *dsi, regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0),
> > sun6i_dsi_dcs_build_pkt_hdr(dsi, msg));
> >
> > - bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL);
> > + bounce = kzalloc(msg->tx_len + sizeof(crc) + 3, GFP_KERNEL);
>
> It would be nicer to use ALIGN() macro, but I'm fine either way.
Nice idea.
> Reviewed-by: Jernej Skrabec
Thanks. :)
regards,
o.
> Best regards,
> Jernej
>
> > if (!bounce)
> > return -ENOMEM;
> >
> > @@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi
> > *dsi, memcpy((u8 *)bounce + msg->tx_len, &crc, sizeof(crc));
> > len += sizeof(crc);
> >
> > - regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
> len);
> > + regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce,
> > DIV_ROUND_UP(len, 4)); regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len +
> > 4 - 1);
> > kfree(bounce);
>
>
>
>
--
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/20200828125124.mgqforbmrjjee7gj%40core.my.home.
[linux-sunxi] Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
On Fri, Aug 28, 2020 at 02:16:36PM +0200, Clément Péron wrote: > Hi Maxime, > > On Tue, 25 Aug 2020 at 15:35, Maxime Ripard wrote: > > > > Hi Clement, > > > > On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote: > > > Hi Maxime and All, > > > > > > On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote: > > > > > > > > Hi Maxime, > > > > > > > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > > > > Add an Operating Performance Points table for the GPU to > > > > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > > > > > > > The voltage range is set with minival voltage set to the target > > > > > > and the maximal voltage set to 1.2V. This allow DVFS framework to > > > > > > work properly on board with fixed regulator. > > > > > > > > > > > > Signed-off-by: Clément Péron > > > > > > > > > > That patch seems reasonable, why shouldn't we merge it? > > > > > > > > I didn't test it a lot and last time I did, some frequencies looked > > > > unstable. > > > > https://lore.kernel.org/patchwork/cover/1239739/ > > > > > > > > This series adds regulator support to Panfrost devfreq, I will send a > > > > new one if DVFS on the H6 GPU is stable. > > > > > > > > I got this running glmark2 last time > > > > # glmark2-es2-drm > > > > === > > > > glmark2 2017.07 > > > > === > > > > OpenGL Information > > > > GL_VENDOR: Panfrost > > > > GL_RENDERER: Mali T720 (Panfrost) > > > > GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5 > > > > === > > > > > > > > [ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) at > > > > 0x80117100 > > > > [ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0, > > > > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > > > > sched_job=e3c2132f > > > > > > > > [ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > > 0x > > > > [ 328.871070] Reason: TODO > > > > [ 328.871070] raw fault status: 0xAA0003C2 > > > > [ 328.871070] decoded fault status: SLAVE FAULT > > > > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > [ 328.871070] access type 0x3: WRITE > > > > [ 328.871070] source id 0xAA00 > > > > [ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1, > > > > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > > > > sched_job=7ac31097 > > > > [ 329.386527] panfrost 180.gpu: js fault, js=0, > > > > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > > > > [ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0, > > > > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > > > > sched_job=04c90381 > > > > [ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > > > 0x > > > > [ 329.411521] Reason: TODO > > > > [ 329.411521] raw fault status: 0xAA0003C2 > > > > [ 329.411521] decoded fault status: SLAVE FAULT > > > > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > > > [ 329.411521] access type 0x3: WRITE > > > > [ 329.411521] source id 0xAA00 > > > > > > Just to keep a track of this issue. > > > > > > Piotr Oniszczuk give more test and seems to be software related: > > > https://www.spinics.net/lists/dri-devel/msg264279.html > > > > > > Ondrej gave a great explanation about a possible origin of this issue: > > > https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 > > > > > > 20:12 looks like gpu pll on H6 is NKMP clock, and those are > > > implemented in such a way in mainline that they are prone to > > > overshooting the frequency during output divider reduction > > > 20:13 so disabling P divider may help > > > 20:13 or fixing the dividers > > > 20:14 and just allowing N to change > > > 20:22 hmm, I haven't looked at this for quite some time, but H6 > > > BSP way of setting PLL factors actually makes the most sense out of > > > everything I've seen/tested so far > > > 20:23 it waits for lock not after setting NK factors, but after > > > reducing the M factor (pre-divider) > > > 20:24 I might as well re-run my CPU PLL tester with this > > > algorithm, to see if it fixes the lockups > > > 20:26 it makes sense to wait for PLL to stabilize "after" > > > changing all the factors that actually affect the VCO, and not just > > > some of them > > > 20:27 warpme_: ^ > > > 20:28 it may be the same thing that plagues the CPU PLL rate > > > changes at runtime > > > > I guess it's one of the bugs we never heard of... > > > > It would be a good idea to test it on another platform (like Rockchip?) > > to rule out any driver issue? > > > > What do you think? > > I can't exclude a bug in the driver, but if it was the case LE > community or Panfrost maintainer woul
[linux-sunxi] Re: [PATCH v4 2/4] input: gpio-vibra: Allow to use vcc-supply alone to control the vibrator
Hello Dmitry,
thanks for looking into the patch. :)
On Wed, Jul 29, 2020 at 11:19:39PM -0700, Dmitry Torokhov wrote:
> Hi Ondrej,
>
> On Tue, Jul 14, 2020 at 12:23:01PM +0200, Ondrej Jirman wrote:
> > Make enable-gpio optional to allow using this driver with boards that
> > have vibrator connected to a power supply without intermediate gpio
> > based enable circuitry.
> >
> > Also avoid a case where neither regulator nor enable gpio is specified,
> > and bail out in probe in such a case.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/input/misc/gpio-vibra.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/input/misc/gpio-vibra.c
> > b/drivers/input/misc/gpio-vibra.c
> > index f79f75595dd7..b3bb7e61ed1d 100644
> > --- a/drivers/input/misc/gpio-vibra.c
> > +++ b/drivers/input/misc/gpio-vibra.c
> > @@ -39,7 +39,7 @@ static int gpio_vibrator_start(struct gpio_vibrator
> > *vibrator)
> > struct device *pdev = vibrator->input->dev.parent;
> > int err;
> >
> > - if (!vibrator->vcc_on) {
> > + if (vibrator->vcc && !vibrator->vcc_on) {
> > err = regulator_enable(vibrator->vcc);
> > if (err) {
> > dev_err(pdev, "failed to enable regulator: %d\n", err);
> > @@ -57,7 +57,7 @@ static void gpio_vibrator_stop(struct gpio_vibrator
> > *vibrator)
> > {
> > gpiod_set_value_cansleep(vibrator->gpio, 0);
> >
> > - if (vibrator->vcc_on) {
> > + if (vibrator->vcc && vibrator->vcc_on) {
> > regulator_disable(vibrator->vcc);
> > vibrator->vcc_on = false;
> > }
> > @@ -112,7 +112,7 @@ static int gpio_vibrator_probe(struct platform_device
> > *pdev)
> > if (!vibrator->input)
> > return -ENOMEM;
> >
> > - vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
> > + vibrator->vcc = devm_regulator_get_optional(&pdev->dev, "vcc");
>
> I know it is very surprising, but regulator_get_optional does not return
> NULL when regulator is not present, but rather ERR_PTR(-ENODEV). You
> need to replace it with NULL in the branch below, or change conditions
> to !IS_ERR(virbrator->vcc) (and still handle -ENODEV in the branch
> below).
Oops, I'll fix that in the next revision.
regards,
o.
> > err = PTR_ERR_OR_ZERO(vibrator->vcc);
> > if (err) {
> > if (err != -EPROBE_DEFER)
> > @@ -121,7 +121,8 @@ static int gpio_vibrator_probe(struct platform_device
> > *pdev)
> > return err;
> > }
> >
> > - vibrator->gpio = devm_gpiod_get(&pdev->dev, "enable", GPIOD_OUT_LOW);
> > + vibrator->gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> > +GPIOD_OUT_LOW);
> > err = PTR_ERR_OR_ZERO(vibrator->gpio);
> > if (err) {
> > if (err != -EPROBE_DEFER)
> > @@ -130,6 +131,11 @@ static int gpio_vibrator_probe(struct platform_device
> > *pdev)
> > return err;
> > }
> >
> > + if (!vibrator->vcc && !vibrator->gpio) {
> > + dev_err(&pdev->dev, "Neither gpio nor regulator provided\n");
> > + return -EINVAL;
> > + }
> > +
> > INIT_WORK(&vibrator->play_work, gpio_vibrator_play_work);
> >
> > vibrator->input->name = "gpio-vibrator";
> > --
> > 2.27.0
> >
>
> Thanks.
>
> --
> Dmitry
--
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/20200730091812.7sia7w3waz2jj62a%40core.my.home.
[linux-sunxi] Re: [PATCH] thermal: sun8i: Be loud when probe fails
Hi Maxime, On Wed, Jul 08, 2020 at 03:57:48PM +0200, Maxime Ripard wrote: > On Wed, Jul 08, 2020 at 03:44:41PM +0200, Ondřej Jirman wrote: > > > [...] > > > Yeah, but on the other hand, we regularly have people that come up and > > > ask if a "legitimate" EPROBE_DEFER error message (as in: the driver > > > wasn't there on the first attempt but was there on the second) is a > > > cause of concern or not. > > > > That's why I also added a success message, to distinguish this case. > > That doesn't really help though. We have plenty of drivers that have > some sort of success message and people will still ask about that error > message earlier. > > > > > And people run several distros for 3-4 months without anyone noticing > > > > any > > > > issues and that thermal regulation doesn't work. So it seems that lack > > > > of a > > > > success message is not enough. > > > > > > I understand what the issue is, but do you really expect phone users to > > > monitor the kernel logs every time they boot their phone to see if the > > > thermal throttling is enabled? > > > > Not phone users, but people making their own kernels/distributions. Those > > people > > monitor dmesg, and out of 4 distros or more nobody noticed there was an > > issue > > (despite the complaints of overheating by their users). > > > > So I thought some warning may be in order, so that distro people more easily > > notice they have misconfigured the kernel or sometging. > > I mean, then there's nothing we can do to properly address that then. > > The configuration system is a gun, we can point at the target, but > anyone is definitely free to shot themself in the foot. > > You would have exactly the same result if you left the thermal driver > disabled, or if you didn't have cpufreq support. Right. Though I hope there's some middle ground. I mean all of those dev_err in error paths of many drivers are there mostly to help debugging stuff. And even though I was part of this driver's development, it took me quite some time to figure out it was the missing sunxi-sid driver causing the issue, with complete silence from the driver. Maybe this can/will be solved at another level entirely, like having a device core report devices probes that failed with EPROBE_DEFER some time after the boot finished and modules had a chance to load, instead of immediately for each probe retry. regards, o. > Maxime -- 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/20200712232942.eecoekr25i3wu2iq%40core.my.home.
[linux-sunxi] Re: [PATCH] thermal: sun8i: Be loud when probe fails
On Wed, Jul 08, 2020 at 03:36:54PM +0200, Maxime Ripard wrote:
> On Wed, Jul 08, 2020 at 03:29:24PM +0200, Ondřej Jirman wrote:
> > Hello Maxime,
> >
> > On Wed, Jul 08, 2020 at 02:25:42PM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Wed, Jul 08, 2020 at 12:55:27PM +0200, Ondrej Jirman wrote:
> > > > I noticed several mobile Linux distributions failing to enable the
> > > > thermal regulation correctly, because the kernel is silent
> > > > when thermal driver fails to probe. Add enough error reporting
> > > > to debug issues and warn users in case thermal sensor is failing
> > > > to probe.
> > > >
> > > > Failing to notify users means, that SoC can easily overheat under
> > > > load.
> > > >
> > > > Signed-off-by: Ondrej Jirman
> > > > ---
> > > > drivers/thermal/sun8i_thermal.c | 55 ++---
> > > > 1 file changed, 43 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/thermal/sun8i_thermal.c
> > > > b/drivers/thermal/sun8i_thermal.c
> > > > index 74d73be16496..9065e79ae743 100644
> > > > --- a/drivers/thermal/sun8i_thermal.c
> > > > +++ b/drivers/thermal/sun8i_thermal.c
> > > > @@ -287,8 +287,12 @@ static int sun8i_ths_calibrate(struct ths_device
> > > > *tmdev)
> > > >
> > > > calcell = devm_nvmem_cell_get(dev, "calibration");
> > > > if (IS_ERR(calcell)) {
> > > > + dev_err(dev, "Failed to get calibration nvmem cell
> > > > (%ld)\n",
> > > > + PTR_ERR(calcell));
> > > > +
> > > > if (PTR_ERR(calcell) == -EPROBE_DEFER)
> > > > return -EPROBE_DEFER;
> > > > +
> > >
> > > The rest of the patch makes sense, but we should probably put the error
> > > message after the EPROBE_DEFER return so that we don't print any extra
> > > noise that isn't necessarily useful
> >
> > I thought about that, but in this case this would have helped, see my other
> > e-mail. Though lack of "probe success" message may be enough for me, to
> > debug the issue, I'm not sure the user will notice that a message is
> > missing, while
> > he'll surely notice if there's a flood of repeated EPROBE_DEFER messages.
>
> Yeah, but on the other hand, we regularly have people that come up and
> ask if a "legitimate" EPROBE_DEFER error message (as in: the driver
> wasn't there on the first attempt but was there on the second) is a
> cause of concern or not.
That's why I also added a success message, to distinguish this case.
> > And people run several distros for 3-4 months without anyone noticing any
> > issues and that thermal regulation doesn't work. So it seems that lack of a
> > success message is not enough.
>
> I understand what the issue is, but do you really expect phone users to
> monitor the kernel logs every time they boot their phone to see if the
> thermal throttling is enabled?
Not phone users, but people making their own kernels/distributions. Those people
monitor dmesg, and out of 4 distros or more nobody noticed there was an issue
(despite the complaints of overheating by their users).
So I thought some warning may be in order, so that distro people more easily
notice they have misconfigured the kernel or sometging.
End users really don't care about dmesg.
regards,
o.
> If anything, it looks like a distro problem, and the notification /
> policy to deal with that should be implemented in userspace.
>
> > Other solution may be to select CONFIG_NVMEM_SUNXI_SID if this driver
> > is enabled. That may get rid of this error scenario of waiting infinitely
> > for calibration data with EPROBE_DEFER. And other potential EPROBE_DEFER
> > sources
> > will probably be quite visible even without this driver telling the user.
> > So this message may not be necessary in that case.
>
> That would only partially solve your issue. If the nvmem driver doesn't
> load for some reason, you would end up in a similar situation.
>
> Maxime
--
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/20200708134441.4lfuh7nwtqnkkg2a%40core.my.home.
[linux-sunxi] Re: [PATCH] thermal: sun8i: Be loud when probe fails
On Wed, Jul 08, 2020 at 07:55:40PM +0800, Frank Lee wrote:
> HI Ondrej,
> On Wed, Jul 8, 2020 at 6:55 PM Ondrej Jirman wrote:
> >
> > I noticed several mobile Linux distributions failing to enable the
> > thermal regulation correctly, because the kernel is silent
> > when thermal driver fails to probe. Add enough error reporting
> > to debug issues and warn users in case thermal sensor is failing
> > to probe.
> >
> > Failing to notify users means, that SoC can easily overheat under
> > load.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/thermal/sun8i_thermal.c | 55 ++---
> > 1 file changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c
> > b/drivers/thermal/sun8i_thermal.c
> > index 74d73be16496..9065e79ae743 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -287,8 +287,12 @@ static int sun8i_ths_calibrate(struct ths_device
> > *tmdev)
> >
> > calcell = devm_nvmem_cell_get(dev, "calibration");
> > if (IS_ERR(calcell)) {
> > + dev_err(dev, "Failed to get calibration nvmem cell (%ld)\n",
> > + PTR_ERR(calcell));
> > +
> > if (PTR_ERR(calcell) == -EPROBE_DEFER)
> > return -EPROBE_DEFER;
> > +
> > /*
> > * Even if the external calibration data stored in sid is
> > * not accessible, the THS hardware can still work, although
> > @@ -308,6 +312,8 @@ static int sun8i_ths_calibrate(struct ths_device *tmdev)
> > caldata = nvmem_cell_read(calcell, &callen);
> > if (IS_ERR(caldata)) {
> > ret = PTR_ERR(caldata);
> > + dev_err(dev, "Failed to read calibration data (%d)\n",
> > + ret);
> > goto out;
> > }
> >
> > @@ -330,23 +336,35 @@ static int sun8i_ths_resource_init(struct ths_device
> > *tmdev)
> > return PTR_ERR(base);
> >
> > tmdev->regmap = devm_regmap_init_mmio(dev, base, &config);
> > - if (IS_ERR(tmdev->regmap))
> > + if (IS_ERR(tmdev->regmap)) {
> > + dev_err(dev, "Failed to init regmap (%ld)\n",
> > + PTR_ERR(tmdev->regmap));
> > return PTR_ERR(tmdev->regmap);
> > + }
> >
> > if (tmdev->chip->has_bus_clk_reset) {
> > tmdev->reset = devm_reset_control_get(dev, NULL);
> > - if (IS_ERR(tmdev->reset))
> > + if (IS_ERR(tmdev->reset)) {
> > + dev_err(dev, "Failed to get reset (%ld)\n",
> > + PTR_ERR(tmdev->reset));
> > return PTR_ERR(tmdev->reset);
> > + }
> >
> > tmdev->bus_clk = devm_clk_get(&pdev->dev, "bus");
> > - if (IS_ERR(tmdev->bus_clk))
> > + if (IS_ERR(tmdev->bus_clk)) {
> > + dev_err(dev, "Failed to get bus clock (%ld)\n",
> > + PTR_ERR(tmdev->bus_clk));
> > return PTR_ERR(tmdev->bus_clk);
> > + }
> > }
> >
> > if (tmdev->chip->has_mod_clk) {
> > tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
> > - if (IS_ERR(tmdev->mod_clk))
> > + if (IS_ERR(tmdev->mod_clk)) {
> > + dev_err(dev, "Failed to get mod clock (%ld)\n",
> > + PTR_ERR(tmdev->mod_clk));
> > return PTR_ERR(tmdev->mod_clk);
> > + }
> > }
> >
> > ret = reset_control_deassert(tmdev->reset);
> > @@ -471,8 +489,12 @@ static int sun8i_ths_register(struct ths_device *tmdev)
> > i,
> >
> > &tmdev->sensor[i],
> > &ths_ops);
> > - if (IS_ERR(tmdev->sensor[i].tzd))
> > + if (IS_ERR(tmdev->sensor[i].tzd)) {
> > + dev_err(tmdev->dev,
> > + "Failed to register sensor %d (%ld)\n",
> > + i, PTR_ERR(tmdev->sensor[i].tzd));
> > return PTR_ERR(tmdev->sensor[i].tzd);
> > + }
> >
> > if (devm_thermal_add_hwmon_sysfs(tmdev->sensor[i].tzd))
> > dev_warn(tmdev->dev,
> > @@ -501,19 +523,21 @@ static int sun8i_ths_probe(struct platform_device
> > *pdev)
> >
> > ret = sun8i_ths_resource_init(tmdev);
> > if (ret)
> > - return ret;
> > + goto err_out;
> >
> > irq = platform_get_irq(pdev, 0);
> > - if (irq < 0)
> > - return irq;
> > + if (irq < 0) {
> > + ret = irq;
> > + goto err_out;
> > + }
> >
> >
[linux-sunxi] Re: [PATCH] thermal: sun8i: Be loud when probe fails
Hello Maxime,
On Wed, Jul 08, 2020 at 02:25:42PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Wed, Jul 08, 2020 at 12:55:27PM +0200, Ondrej Jirman wrote:
> > I noticed several mobile Linux distributions failing to enable the
> > thermal regulation correctly, because the kernel is silent
> > when thermal driver fails to probe. Add enough error reporting
> > to debug issues and warn users in case thermal sensor is failing
> > to probe.
> >
> > Failing to notify users means, that SoC can easily overheat under
> > load.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/thermal/sun8i_thermal.c | 55 ++---
> > 1 file changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c
> > b/drivers/thermal/sun8i_thermal.c
> > index 74d73be16496..9065e79ae743 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -287,8 +287,12 @@ static int sun8i_ths_calibrate(struct ths_device
> > *tmdev)
> >
> > calcell = devm_nvmem_cell_get(dev, "calibration");
> > if (IS_ERR(calcell)) {
> > + dev_err(dev, "Failed to get calibration nvmem cell (%ld)\n",
> > + PTR_ERR(calcell));
> > +
> > if (PTR_ERR(calcell) == -EPROBE_DEFER)
> > return -EPROBE_DEFER;
> > +
>
> The rest of the patch makes sense, but we should probably put the error
> message after the EPROBE_DEFER return so that we don't print any extra
> noise that isn't necessarily useful
I thought about that, but in this case this would have helped, see my other
e-mail. Though lack of "probe success" message may be enough for me, to
debug the issue, I'm not sure the user will notice that a message is missing,
while
he'll surely notice if there's a flood of repeated EPROBE_DEFER messages.
And people run several distros for 3-4 months without anyone noticing any
issues and that thermal regulation doesn't work. So it seems that lack of a
success message is not enough.
Other solution may be to select CONFIG_NVMEM_SUNXI_SID if this driver
is enabled. That may get rid of this error scenario of waiting infinitely
for calibration data with EPROBE_DEFER. And other potential EPROBE_DEFER sources
will probably be quite visible even without this driver telling the user.
So this message may not be necessary in that case.
thank you and regards,
o.
> Maxime
--
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/20200708132924.r6f5id2evprhybec%40core.my.home.
[linux-sunxi] Re: [PATCH] thermal: sun8i: Be loud when probe fails
On Wed, Jul 08, 2020 at 07:55:40PM +0800, Frank Lee wrote:
> HI Ondrej,
> On Wed, Jul 8, 2020 at 6:55 PM Ondrej Jirman wrote:
> >
> > I noticed several mobile Linux distributions failing to enable the
> > thermal regulation correctly, because the kernel is silent
> > when thermal driver fails to probe. Add enough error reporting
> > to debug issues and warn users in case thermal sensor is failing
> > to probe.
> >
> > Failing to notify users means, that SoC can easily overheat under
> > load.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/thermal/sun8i_thermal.c | 55 ++---
> > 1 file changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c
> > b/drivers/thermal/sun8i_thermal.c
> > index 74d73be16496..9065e79ae743 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -287,8 +287,12 @@ static int sun8i_ths_calibrate(struct ths_device
> > *tmdev)
> >
> > calcell = devm_nvmem_cell_get(dev, "calibration");
> > if (IS_ERR(calcell)) {
> > + dev_err(dev, "Failed to get calibration nvmem cell (%ld)\n",
> > + PTR_ERR(calcell));
> > +
> > if (PTR_ERR(calcell) == -EPROBE_DEFER)
> > return -EPROBE_DEFER;
> > +
> > /*
> > * Even if the external calibration data stored in sid is
> > * not accessible, the THS hardware can still work, although
> > @@ -308,6 +312,8 @@ static int sun8i_ths_calibrate(struct ths_device *tmdev)
> > caldata = nvmem_cell_read(calcell, &callen);
> > if (IS_ERR(caldata)) {
> > ret = PTR_ERR(caldata);
> > + dev_err(dev, "Failed to read calibration data (%d)\n",
> > + ret);
> > goto out;
> > }
> >
> > @@ -330,23 +336,35 @@ static int sun8i_ths_resource_init(struct ths_device
> > *tmdev)
> > return PTR_ERR(base);
> >
> > tmdev->regmap = devm_regmap_init_mmio(dev, base, &config);
> > - if (IS_ERR(tmdev->regmap))
> > + if (IS_ERR(tmdev->regmap)) {
> > + dev_err(dev, "Failed to init regmap (%ld)\n",
> > + PTR_ERR(tmdev->regmap));
> > return PTR_ERR(tmdev->regmap);
> > + }
> >
> > if (tmdev->chip->has_bus_clk_reset) {
> > tmdev->reset = devm_reset_control_get(dev, NULL);
> > - if (IS_ERR(tmdev->reset))
> > + if (IS_ERR(tmdev->reset)) {
> > + dev_err(dev, "Failed to get reset (%ld)\n",
> > + PTR_ERR(tmdev->reset));
> > return PTR_ERR(tmdev->reset);
> > + }
> >
> > tmdev->bus_clk = devm_clk_get(&pdev->dev, "bus");
> > - if (IS_ERR(tmdev->bus_clk))
> > + if (IS_ERR(tmdev->bus_clk)) {
> > + dev_err(dev, "Failed to get bus clock (%ld)\n",
> > + PTR_ERR(tmdev->bus_clk));
> > return PTR_ERR(tmdev->bus_clk);
> > + }
> > }
> >
> > if (tmdev->chip->has_mod_clk) {
> > tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
> > - if (IS_ERR(tmdev->mod_clk))
> > + if (IS_ERR(tmdev->mod_clk)) {
> > + dev_err(dev, "Failed to get mod clock (%ld)\n",
> > + PTR_ERR(tmdev->mod_clk));
> > return PTR_ERR(tmdev->mod_clk);
> > + }
> > }
> >
> > ret = reset_control_deassert(tmdev->reset);
> > @@ -471,8 +489,12 @@ static int sun8i_ths_register(struct ths_device *tmdev)
> > i,
> >
> > &tmdev->sensor[i],
> > &ths_ops);
> > - if (IS_ERR(tmdev->sensor[i].tzd))
> > + if (IS_ERR(tmdev->sensor[i].tzd)) {
> > + dev_err(tmdev->dev,
> > + "Failed to register sensor %d (%ld)\n",
> > + i, PTR_ERR(tmdev->sensor[i].tzd));
> > return PTR_ERR(tmdev->sensor[i].tzd);
> > + }
> >
> > if (devm_thermal_add_hwmon_sysfs(tmdev->sensor[i].tzd))
> > dev_warn(tmdev->dev,
> > @@ -501,19 +523,21 @@ static int sun8i_ths_probe(struct platform_device
> > *pdev)
> >
> > ret = sun8i_ths_resource_init(tmdev);
> > if (ret)
> > - return ret;
> > + goto err_out;
> >
> > irq = platform_get_irq(pdev, 0);
> > - if (irq < 0)
> > - return irq;
> > + if (irq < 0) {
> > + ret = irq;
> > + goto err_out;
> > + }
> >
> >
[linux-sunxi] Re: [PATCH] thermal: sun8i: Be loud when probe fails
On Wed, Jul 08, 2020 at 12:03:01PM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Jul 08, 2020 at 12:55:27PM +0200, Ondrej Jirman wrote:
> > I noticed several mobile Linux distributions failing to enable the
> > thermal regulation correctly, because the kernel is silent
> > when thermal driver fails to probe. Add enough error reporting
> > to debug issues and warn users in case thermal sensor is failing
> > to probe.
> >
> > Failing to notify users means, that SoC can easily overheat under
> > load.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/thermal/sun8i_thermal.c | 55 ++---
> > 1 file changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c
> > b/drivers/thermal/sun8i_thermal.c
> > index 74d73be16496..9065e79ae743 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -287,8 +287,12 @@ static int sun8i_ths_calibrate(struct ths_device
> > *tmdev)
> >
> > calcell = devm_nvmem_cell_get(dev, "calibration");
> > if (IS_ERR(calcell)) {
> > + dev_err(dev, "Failed to get calibration nvmem cell (%ld)\n",
> > + PTR_ERR(calcell));
>
> Consider using:
>
> dev_err(dev, "Failed to get calibration nvmem cell (%pe)\n",
> calcell);
>
> which means the kernel can print the symbolic errno value.
Thank you, I'll change it in v2. :)
regards,
o.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
--
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/20200708111050.ivpkcutwwvm7kwcm%40core.my.home.
[linux-sunxi] Re: [PATCH] MAINTAINERS: adjust entry to renaming and conversion
Hello Lukas,
On Sun, Jul 05, 2020 at 08:59:17AM +0200, Lukas Bulwahn wrote:
> Commit a74e81a56405 ("drm/panel: rocktech-jh057n00900: Rename the driver to
> st7703") and commit 7317f4574492 ("dt-bindings: panel: Convert
> rocktech,jh057n00900 to yaml") renamed and converted the files mentioned in
> DRM DRIVER FOR ROCKTECH JH057N00900 PANELS, but did not adjust the entries
> in MAINTAINERS.
A similar patch was already posted:
https://lkml.kernel.org/lkml/20200701184640.1674969-1-meg...@megous.com/
thank you and regards,
o.
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: \
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> warning: no file matches F: \
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
>
> Adjust entries after this file renaming and devicetree conversion.
>
> Signed-off-by: Lukas Bulwahn
> ---
> applies cleanly on next-20200703
>
> Ondrej, please ack this patch.
> Sam, please pick this minor non-urgent patch into your -next tree.
>
> This is the minimal change to address the warning. You might consider
> changing the name of the section from ROCKTECH to ST7703, change
> maintainers etc.
>
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9375edaef11f..8a7b92faff99 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5493,8 +5493,8 @@ DRM DRIVER FOR ROCKTECH JH057N00900 PANELS
> M: Guido Günther
> R: Purism Kernel Team
> S: Maintained
> -F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> -F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> +F:
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> +F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
>
> DRM DRIVER FOR SAVAGE VIDEO CARDS
> S: Orphan / Obsolete
> --
> 2.17.1
>
--
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/20200705113017.mostxjvatkqkhqf6%40core.my.home.
[linux-sunxi] Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
On Fri, Jul 03, 2020 at 12:44:48PM +0200, megous hlavni wrote:
> Hello Sam,
>
> On Fri, Jul 03, 2020 at 07:11:55AM +0200, Sam Ravnborg wrote:
> > Hi Ondrej.
> >
> > > > My bot found errors running 'make dt_binding_check' on your patch:
> > > >
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of
> > > > the regexes: 'pinctrl-[0-9]+'
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: 'vcc-supply' is a required property
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: 'iovcc-supply' is a required property
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: 'reset-gpios' is a required property
> > >
> > > Paths look bogus
> > >
> > > It should be .../rocktech,jh057n00900.yaml: ...
> >
> > The example in nwl-dsi.yaml contains:
> > compatible = "rocktech,jh057n00900";
> >
> > So the example is checked against your updated binding.
> > And the binding check fails because the example is no longer valid.
>
> Ah, now I understand.
>
> > This needs to be fixed as we do not wat to introduce new errors.
> > Either the example or the binding needs the fix.
>
> I think we can unrequire the supplies, but reset is needed really.
Hmm, that's probably wrong kind of thinking. Panel has the supplies, and
obviously requires them, so the dts must describe them somehow, even if
they are the fixed supplies. So I'll not unrequire them.
> The panel only has one port, so there should be no address/size-cells
> in the example, and port@0 should be just port to match existing binding.
> If it had multiple ports, port@0 would have to be inside ports { } node
> anyway, according to the existing binding. Then add reset-gpios to
> the example...
>
> And that should fix it.
>
> I'll prepare the patch shortly.
>
> regards,
> o.
>
> > Sam
> >
> >
> > >
> > > regards,
> > > o.
> > >
> > > >
> > > > See https://patchwork.ozlabs.org/patch/1320690
> > > >
> > > > If you already ran 'make dt_binding_check' and didn't see the above
> > > > error(s), then make sure dt-schema is up to date:
> > > >
> > > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
> > > > --upgrade
> > > >
> > > > Please check and re-submit.
> > > >
--
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/20200703111323.zcmv3cuo7toa4d3g%40core.my.home.
[linux-sunxi] Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
Hello Sam,
On Fri, Jul 03, 2020 at 07:11:55AM +0200, Sam Ravnborg wrote:
> Hi Ondrej.
>
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > >
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of
> > > the regexes: 'pinctrl-[0-9]+'
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: 'vcc-supply' is a required property
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: 'iovcc-supply' is a required property
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: 'reset-gpios' is a required property
> >
> > Paths look bogus
> >
> > It should be .../rocktech,jh057n00900.yaml: ...
>
> The example in nwl-dsi.yaml contains:
> compatible = "rocktech,jh057n00900";
>
> So the example is checked against your updated binding.
> And the binding check fails because the example is no longer valid.
Ah, now I understand.
> This needs to be fixed as we do not wat to introduce new errors.
> Either the example or the binding needs the fix.
I think we can unrequire the supplies, but reset is needed really.
The panel only has one port, so there should be no address/size-cells
in the example, and port@0 should be just port to match existing binding.
If it had multiple ports, port@0 would have to be inside ports { } node
anyway, according to the existing binding. Then add reset-gpios to
the example...
And that should fix it.
I'll prepare the patch shortly.
regards,
o.
> Sam
>
>
> >
> > regards,
> > o.
> >
> > >
> > > See https://patchwork.ozlabs.org/patch/1320690
> > >
> > > If you already ran 'make dt_binding_check' and didn't see the above
> > > error(s), then make sure dt-schema is up to date:
> > >
> > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
> > > --upgrade
> > >
> > > Please check and re-submit.
> > >
--
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/20200703104448.iwhxk77d2hyrr3x5%40core.my.home.
[linux-sunxi] Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
On Thu, Jul 02, 2020 at 02:51:43PM -0600, Rob Herring wrote: > On Wed, 01 Jul 2020 18:29:17 +0200, Ondrej Jirman wrote: > > Convert Rocktech MIPI DSI panel driver from txt to yaml bindings. > > > > Signed-off-by: Ondrej Jirman > > --- > > .../display/panel/rocktech,jh057n00900.txt| 23 --- > > .../display/panel/rocktech,jh057n00900.yaml | 66 +++ > > 2 files changed, 66 insertions(+), 23 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of the > regexes: 'pinctrl-[0-9]+' > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: 'vcc-supply' is a required property > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: 'iovcc-supply' is a required property > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: 'reset-gpios' is a required property Paths look bogus It should be .../rocktech,jh057n00900.yaml: ... regards, o. > > See https://patchwork.ozlabs.org/patch/1320690 > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. > -- 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/20200702210354.562wkzpdmyrlwojx%40core.my.home.
[linux-sunxi] Re: [PATCH v6 13/13] arm64: dts: sun50i-a64-pinephone: Add touchscreen support
Hi Icenowy,
On Wed, Jul 01, 2020 at 08:01:14PM +0800, Icenowy Zheng wrote:
>
>
> 于 2020年7月1日 GMT+08:00 下午6:31:26, Ondrej Jirman 写到:
> >Pinephone has a Goodix GT917S capacitive touchscreen controller on
> >I2C0 bus. Add support for it.
> >
> >Signed-off-by: Ondrej Jirman
> >Acked-by: Linus Walleij
> >---
> > .../dts/allwinner/sun50i-a64-pinephone.dtsi | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> >index 85a7aa5efd32..2d5694446d17 100644
> >--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> >+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> >@@ -123,6 +123,25 @@ &ehci1 {
> > status = "okay";
> > };
> >
> >+&i2c0 {
> >+pinctrl-names = "default";
> >+pinctrl-0 = <&i2c0_pins>;
> >+status = "okay";
> >+
> >+touchscreen@5d {
> >+compatible = "goodix,gt917s", "goodix,gt911";
>
> Please drop gt911 here. GT917S belong to the GT1x product line, not the same
> line with GT911.
>
> You will see this in the driver.
Right. I'll do so in v8.
thnk you and regards,
o.
> >+reg = <0x5d>;
> >+interrupt-parent = <&pio>;
> >+interrupts = <7 4 IRQ_TYPE_LEVEL_HIGH>; /* PH4 */
> >+irq-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> >+reset-gpios = <&pio 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
> >+AVDD28-supply = <®_ldo_io0>;
> >+VDDIO-supply = <®_ldo_io0>;
> >+touchscreen-size-x = <720>;
> >+touchscreen-size-y = <1440>;
> >+};
> >+};
> >+
> > &i2c1 {
> > 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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200701185741.z5cga3b7z4gmba6u%40core.my.home.
[linux-sunxi] Re: [PATCH v7 00/13] Add support for PinePhone LCD panel
Hello Sam, On Wed, Jul 01, 2020 at 07:30:18PM +0200, Sam Ravnborg wrote: > Hi Ondrej. > > On Wed, Jul 01, 2020 at 06:29:15PM +0200, Ondrej Jirman wrote: > > This patchset adds support for the LCD panel of PinePhone. > > > > I've tested this on PinePhone 1.0 and 1.2. > > Thanks for this nive sereis. > Applied the first 11 patches to drm-misc-next. > The DTS files needs to go in via another tree. Thank you very much, too. :) regards, o. > Sam -- 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/20200701184853.ctrowkdtdsqnlk2f%40core.my.home.
[linux-sunxi] Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
Hello, On Wed, Jul 01, 2020 at 05:54:05PM +0200, Guido Günther wrote: > Hi, > On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > > This patchset adds support for the LCD panel of PinePhone. > > I gave this a quick spin on the Librem5 devkit so > > Tested-by: Guido Günther > > but please also adjust MAINTAINERS so we stay in the loop on driver > changes. Ah, right. I'll send a quick followup patch[1] after this gets merged, or add it to v8 if there will be a need for v8. Thanks for noticing. [1] https://megous.com/dl/tmp/0001-MAINTAINERS-Update-entry-for-st7703-driver-after-the.patch And thanks for testing, too. :) regards, o. > Cheers, > -- Guido > > > > > I've tested this on PinePhone 1.0 and 1.2. > > > > Please take a look. > > > > thank you and regards, > > Ondrej Jirman > > > > Changes in v6: > > - Fixed spacing in yaml > > - Fixed wrong vccio->iovcc supply name in the bindings doc > > - I noticed that the original driver uses a delay of 20ms in the init > > function to achieve a combined total of 120ms required from post-reset > > to display_on. I've added a similar delay to xbd599_init, so that > > xbd599 panel also has the right timing. (patch 9) > > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > > - Added review/ack tags > > - Learned to run dt_binding_check by myself ;) > > > > Changes in v5: > > - rewritten on top of rocktech-jh057n00900 driver > > - rocktech-jh057n00900 renamed to st7703 (controller name) > > - converted rocktech-jh057n00900 bindings to yaml and extended for xbd599 > > > > Changes in v4: > > - use ->type from the mode instead of hardcoding (Samuel) > > - move init_sequence to ->prepare (Samuel) > > - move anti-flicker delay to ->enable, explain it (Samuel) > > - add enter_sleep after display_off (Samuel) > > - drop ->disable (move code to ->unprepare) > > - add ID bytes dumping (Linus) > > (I can't test it since allwinner DSI driver has a broken > >dcs_read function, and I didn't manage to fix it.) > > - document magic bytes (Linus) > > - assert reset during powerup > > - cleanup powerup timings according to the datasheet > > > > Changes in v3: > > - Panel driver renamed to the name of the LCD controller > > - Re-organize the driver slightly to more easily support more panels > > based on the same controller. > > - Add patch to enable the touchscreen to complete the LCD support > > on PinePhone. > > - Dropped the "DSI fix" patch (the driver seems to work for me without it) > > - Improved brightness levels handling: > > - PinePhone 1.0 uses default levels generated by the driver > > - On PinePhone 1.1 duty cycles < 20% lead to black screen, so > > default levels can't be used. Martijn Braam came up with a > > list of duty cycle values that lead to perception of linear > > brigtness level <-> light intensity on PinePhone 1.1 > > - There was some feedback on v2 about this being similar to st7701. > > It's only similar in name. Most of the "user commands" are different, > > so I opted to keep this in a new driver instead of creating st770x. > > > > Anyone who likes to check the differences, here are datasheets: > > > > - https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > - https://megous.com/dl/tmp/ST7701.pdf > > > > Changes in v2: > > - DT Example fix. > > - DT Format fix. > > - Raised copyright info to 2020. > > - Sort panel operation functions. > > - Sort inclusion. > > > > > > -- For phone owners: -- > > > > There's an open question on how to set the backlight brightness values > > on post 1.0 revision phone, since lower duty cycles (< 10-20%) lead > > to backlight being black. It would be nice if more people can test > > the various backlight levels on 1.1 and 1.2 revision with this change > > in dts: > > > >brightness-levels = <0 1000>; > >num-interpolated-steps = <1000>; > > > > and report at what brightness level the backlight turns on. So far it > > seems this has a wide range. Lowest useable duty cycle for me is ~7% > > on 1.2 and for Martijn ~20% on 1.1. > > > > Icenowy Zheng (2): > > dt-bindings: vendor-prefixes: Add Xingbangda > > arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone > > > > Ondrej Jirman (11): > > dt-bindings: panel: Convert rocktech,jh057n00900 to yaml > > dt-bindings: panel: Add compatible for Xingbangda XBD599 panel > > drm/panel: rocktech-jh057n00900: Rename the driver to st7703 > > drm/panel: st7703: Rename functions from jh057n prefix to st7703 > > drm/panel: st7703: Prepare for supporting multiple panels > > drm/panel: st7703: Move code specific to jh057n closer together > > drm/panel: st7703: Move generic part of init sequence to enable > > callback > > drm/panel: st7703: Add support for Xingbangda XBD599 > > drm/panel: st7703: Enter sleep after display off > > drm/panel: st7703: Assert reset prior to powering down the regulators > > arm64: dts: sun50i-a64-pinephone: Add touchs
[linux-sunxi] Re: [PATCH v6 02/13] dt-bindings: panel: Convert rocktech,jh057n00900 to yaml
Hello Guido,
On Wed, Jul 01, 2020 at 05:58:57PM +0200, Guido Günther wrote:
> Hi Ondrej,
> On Wed, Jul 01, 2020 at 12:31:15PM +0200, Ondrej Jirman wrote:
> > Convert Rocktech MIPI DSI panel driver from txt to yaml bindings.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > .../display/panel/rocktech,jh057n00900.txt| 23 ---
> > .../display/panel/rocktech,jh057n00900.yaml | 66 +++
> > 2 files changed, 66 insertions(+), 23 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
>
> Thanks for the conversion! Shouldn't we switch to `sitronix-st7703.yaml`
> as well in this patch?
Names of yaml files should be according to one of the compatibles.
And thank you for your review of the patches.
regards,
o.
> Cheers,
> -- Guido
>
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> > deleted file mode 100644
> > index a372c5d84695..
> > ---
> > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> > +++ /dev/null
> > @@ -1,23 +0,0 @@
> > -Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
> > -
> > -Required properties:
> > -- compatible: should be "rocktech,jh057n00900"
> > -- reg: DSI virtual channel of the peripheral
> > -- reset-gpios: panel reset gpio
> > -- backlight: phandle of the backlight device attached to the panel
> > -- vcc-supply: phandle of the regulator that provides the vcc supply
> > voltage.
> > -- iovcc-supply: phandle of the regulator that provides the iovcc supply
> > - voltage.
> > -
> > -Example:
> > -
> > - &mipi_dsi {
> > - panel@0 {
> > - compatible = "rocktech,jh057n00900";
> > - reg = <0>;
> > - backlight = <&backlight>;
> > - reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
> > - vcc-supply = <®_2v8_p>;
> > - iovcc-supply = <®_1v8_p>;
> > - };
> > - };
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> > new file mode 100644
> > index ..928ba42e7f8d
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> > @@ -0,0 +1,66 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
> > +
> > +maintainers:
> > + - Ondrej Jirman
> > +
> > +description: |
> > + Rocktech JH057N00900 is a 720x1440 TFT LCD panel
> > + connected using a MIPI-DSI video interface.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: rocktech,jh057n00900
> > +
> > + reg:
> > +maxItems: 1
> > +description: DSI virtual channel
> > +
> > + vcc-supply:
> > +description: Panel power supply
> > +
> > + iovcc-supply:
> > +description: I/O voltage supply
> > +
> > + reset-gpios:
> > +description: GPIO used for the reset pin
> > +maxItems: 1
> > +
> > + backlight:
> > +description: Backlight used by the panel
> > +$ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vcc-supply
> > + - iovcc-supply
> > + - reset-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +dsi {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + panel@0 {
> > +compatible = "rocktech,jh057n00900";
> > +reg = <0>;
> > +vcc-supply = <®_2v8_p>;
> > +iovcc-supply = <®_1v8_p>;
> > +reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
> > +backlight = <&backlight>;
> > + };
> > +};
> > +...
> > --
> > 2.27.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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200701163227.on7wo6fo5majket6%40core.my.home.
[linux-sunxi] Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
Hello Sam, On Wed, Jul 01, 2020 at 05:25:32PM +0200, Sam Ravnborg wrote: > Hi Ondrej. > > On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > > This patchset adds support for the LCD panel of PinePhone. > > > > I've tested this on PinePhone 1.0 and 1.2. > > > > Please take a look. > > > > thank you and regards, > > Ondrej Jirman > > > > Changes in v6: > > - Fixed spacing in yaml > > - Fixed wrong vccio->iovcc supply name in the bindings doc > > - I noticed that the original driver uses a delay of 20ms in the init > > function to achieve a combined total of 120ms required from post-reset > > to display_on. I've added a similar delay to xbd599_init, so that > > xbd599 panel also has the right timing. (patch 9) > > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > > - Added review/ack tags > > - Learned to run dt_binding_check by myself ;) > The patch-set does not apply clean on top of drm-misc-next - due to > vrefresh removal. > Please re-spin. Sorry for that. Rebased and retested. thank you, o. > Sam -- 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/20200701163018.cfweuzp76qx5nsew%40core.my.home.
[linux-sunxi] Re: [PATCH v5 09/13] drm/panel: st7703: Add support for Xingbangda XBD599
Hello Linus, On Wed, Jul 01, 2020 at 09:50:40AM +0200, Linus Walleij wrote: > On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > > > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel used in > > PinePhone. Add support for it. > > > > Signed-off-by: Icenowy Zheng > > Signed-off-by: Ondrej Jirman > > Reviewed-by: Linus Walleij Thank you very much for the review. :) I've sent v6 which should fix the currently remaining issues with dt bindings + one timing issue I've found in this patch. I've kept your reviewed-by tag, because it's a fairly trivial issue. But feel free to complain. thank you again and regards, o. > Yours, > Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200701103451.67worsg3wvupyuoh%40core.my.home.
[linux-sunxi] Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
Hello Sam, On Mon, Jun 22, 2020 at 10:08:02AM +0200, Sam Ravnborg wrote: > On Sun, Jun 21, 2020 at 12:30:10AM +0200, Ondřej Jirman wrote: > > On Sat, Jun 20, 2020 at 11:25:29PM +0200, Sam Ravnborg wrote: > > > Hi Ondrej et al. ... > > > Would it not be better to have one st7703 driver that suipports both > > > panels? > > > > > > The driver would need dedicated init functions depending on the panel. > > > But a lot could also be shared. > > > > I guess I can move the code there. > In the same process the river should then be renamed to follow other > sitronix based drivers. > So the next developer will recognize this and use the correct driver. Are driver/module names considered kernel ABI? Or is it possible to change them? regards, o. -- 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/20200622111752.jsz37zl7hidvkozw%40core.my.home.
[linux-sunxi] Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
On Sat, Jun 20, 2020 at 11:25:29PM +0200, Sam Ravnborg wrote:
> Hi Ondrej et al.
>
> On Wed, Jun 17, 2020 at 02:32:07AM +0200, Ondrej Jirman wrote:
> > From: Icenowy Zheng
> >
> > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> > Xingbangda, which is used on PinePhone final assembled phones.
> >
> > It is based on Sitronix ST7703 LCD controller.
>
> I am a little late to the game here - so sorry if this has been
> discussed before.
> We already have panel-rocktech-jh057n00900.c which is a panle driver
> based on st7703.
> Why is it we need a new driver?
No reason other than the driver not being named after the controller,
so I didn't notice.
> Would it not be better to have one st7703 driver that suipports both
> panels?
>
> The driver would need dedicated init functions depending on the panel.
> But a lot could also be shared.
I guess I can move the code there.
regards,
o.
> Sam
>
> >
> > Add support for it.
> >
> > Signed-off-by: Icenowy Zheng
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/gpu/drm/panel/Kconfig | 10 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 535 ++
> > 3 files changed, 546 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 39055c1f0e2f..b7bc157b0612 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -395,6 +395,16 @@ config DRM_PANEL_SITRONIX_ST7701
> > ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> > system interfaces.
> >
> > +config DRM_PANEL_SITRONIX_ST7703
> > + tristate "Sitronix ST7703 panel driver"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + depends on BACKLIGHT_CLASS_DEVICE
> > + help
> > + Say Y here if you want to enable support for the Sitronix
> > + ST7703 controller for 720X1440 LCD panels with MIPI/RGB/SPI
> > + system interfaces.
> > +
> > config DRM_PANEL_SITRONIX_ST7789V
> > tristate "Sitronix ST7789V panel"
> > depends on OF && SPI
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index de74f282c433..47f4789a8685 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -41,6 +41,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
> > panel-sharp-lq101r1sx01.o
> > obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> > +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> > obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > new file mode 100644
> > index ..dbd46b6c0b46
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > @@ -0,0 +1,535 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DRM driver for Sitronix ST7703 MIPI DSI panel
> > + *
> > + * Copyright (C) 2020 Ondrej Jirman
> > + * Copyright (C) 2019-2020 Icenowy Zheng
> > + *
> > + * Based on panel-rocktech-jh057n00900.c, which is:
> > + * Copyright (C) Purism SPC 2019
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* Manufacturer specific DCS commands */
> > +#define ST7703_CMD_SETDISP 0xB2
> > +#define ST7703_CMD_SETRGBIF0xB3
> > +#define ST7703_CMD_SETCYC 0xB4
> > +#define ST7703_CMD_SETBGP 0xB5
> > +#define ST7703_CMD_SETVCOM 0xB6
> > +#define ST7703_CMD_SETOTP 0xB7
> > +#define ST7703_CMD_SETPOWER_EXT0xB8
> > +#define ST7703_CMD_SETEXTC 0xB9
> > +#define ST7703_CMD_SETMIPI 0xBA
> > +#define ST7703_CMD_SETVDC 0xBC
> > +#define ST7703_CMD_UNK_BF 0xBF
> > +#define ST7703_CMD_SETSCR 0xC0
> > +#define ST7703_CMD_SETPOWER0xC1
> > +#define ST7703_CMD_UNK_C6 0xC6
> > +#define ST7703_CMD_SETPANEL0xCC
> > +#define ST7703_CMD_RDID1 0xDA
> > +#define ST7703_CMD_RDID2 0xDB
> > +#define ST7703_CMD_RDID3 0xDC
> > +#define ST7703_CMD_SETGAMMA0xE0
> > +#define ST7703_CMD_SETEQ 0xE3
> > +#define ST7703_CMD_SETGIP1 0xE9
> > +#define ST7703_CMD_SETGIP2 0xEA
> > +
> > +struct st7703_panel_desc {
> > + const struct drm_display_mode *mode;
> > + unsigned int lanes;
> > + unsigned long flags;
> > + enum mipi_dsi_pixel_format format;
> > + const char *const *supply_names;
> > + unsigned int num_supplies;
> > +};
> > +
> > +struct st7703 {
> > + struct device *dev;
Re: [linux-sunxi] Re: [PATCH v3 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
Hello Linus, On Tue, May 26, 2020 at 01:32:25PM +0200, Linus Walleij wrote: > Hi Ondrej, > [...] > > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, > > + 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12, > > + 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38, > > + 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00, > > + 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88, > > + 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64, > > + 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > > + 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00); > > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, > > + 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88, > > + 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13, > > + 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > > + 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A, > > + 0xA5, 0x00, 0x00, 0x00, 0x00); > > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, > > + 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35, > > + 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12, > > + 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, > > + 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, > > + 0x12, 0x18); > > + msleep(20); > > This stuff is really hard or impossible to understand without the > datasheet. > > In my previous review I wrote: > > It appears that the Himax HX8363 is using the same display controller > if you look at the datasheet: > http://www.datasheet-pdf.com/PDF/HX8369-A-Datasheet-Himax-729024 > There you find an explanation to some of the commands. It is st7703, and we have a fairly complete datasheet available publicly. I posted links in the cover letter. > That means, try to get rid of as much of the magic bytes as you can > and use proper #defines. I know it takes some work but the result > is so much more useful and readable. I've added some descriptions from the datasheet as comments next to the values in v4. Thank you and regards, o. > Further I wrote: > > You should definately insert code to read the MTP bytes: > 0xDA manufacturer > 0xDB driver version > 0xDC LCD module/driver > And print these, se e.g. my newly added NT35510 driver or > the Sony ACX424AKP driver. > > So please do that. > > Yours, > Linus Walleij > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZpiQ7E_v-Gfk6vFcUEiMazvixYaL0ksKeP%3DTq3O6Fh%3DQ%40mail.gmail.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/20200617020049.iz6vujrs25kuipl6%40core.my.home.
Re: [linux-sunxi] Pocketbook 626 - LUX 3 - Gadget serial
Hi, On Sat, May 23, 2020 at 12:55:42AM -0700, Antonin Skala wrote: > Hello, did somebody tried to compile gadget serial module for this reader? yes. You also need to configure it on the kernel command line, I think. Something like console=/dev/ttyGS0 to get the kernel console output there if that's what you're looking for. regards, o. > -- > 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/75d7c25b-f561-4bff-9f00-25a591adef20%40googlegroups.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/20200525190619.3uwvegtfs35ibcll%40core.my.home.
[linux-sunxi] Re: [PATCH v2 1/4] dt-bindings: input: gpio-vibrator: Don't require enable-gpios
On Tue, May 12, 2020 at 03:52:12PM -0700, Dmitry Torokhov wrote: > On Wed, May 13, 2020 at 12:22:02AM +0200, Ondrej Jirman wrote: > > It is possible to turn the motor on/off just by enabling/disabling > > the vcc-supply. > > > > Signed-off-by: Ondrej Jirman > > Acked-by: Rob Herring > > --- > > Documentation/devicetree/bindings/input/gpio-vibrator.yaml | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/input/gpio-vibrator.yaml > > b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml > > index 2384465eaa19..c700b640bd53 100644 > > --- a/Documentation/devicetree/bindings/input/gpio-vibrator.yaml > > +++ b/Documentation/devicetree/bindings/input/gpio-vibrator.yaml > > @@ -24,7 +24,6 @@ properties: > > > > required: > >- compatible > > - - enable-gpios > > Hmm we need at least one of the 2 (gpio and supply). Should we encode it > in the binding? Not sure how to encode either one or the other property being required, but not both at once. Maybe I can add a supply-vibrator compatible to the driver and binding and make requirements dependent on the compatible? > Also, in the dirver code, I guess we need to switch to have regulator > optional (so we are not given the dummy one) and bail if neither > regulator nor GPIO is found. Though nothing bad will happen in the driver if binding will lack both of these. The driver will just not control any HW, so at least it's failsafe as is. regards, o. > Thanks. > > -- > Dmitry -- 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/20200512230557.zvdgwhbqygc2fufv%40core.my.home.
Re: [linux-sunxi] [PATCH v2] arm64: dts: allwinner: h6: Use dummy regulator for Tanix TX6
Hi Clément,
On Tue, Apr 28, 2020 at 04:26:29PM +0200, Clément Péron wrote:
> Tanix TX6 has a fixed regulator. As DVFS is instructed to change
> voltage to meet OPP table, the DVFS is not working as expected.
>
> Avoid to introduce a new dedicated OPP Table where voltage are
> equals to the fixed regulator as it will only duplicate all the OPPs.
> Instead remove the fixed regulator so the DVFS framework will create
> dummy regulator and will have the same behavior.
>
> Add some comments to explain this in the device-tree.
>
> Reported-by: Piotr Oniszczuk
> Fixes: add1e27fb703 ("arm64: dts: allwinner: h6: Enable CPU opp tables for
> Tanix TX6")
> Signed-off-by: Clément Péron
> ---
> .../boot/dts/allwinner/sun50i-h6-tanix-tx6.dts | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> index be81330db14f..3e96fcb317ea 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
> @@ -48,7 +48,15 @@
> };
>
> &cpu0 {
> - cpu-supply = <®_vdd_cpu_gpu>;
> + /*
> + * Don't specify the CPU regulator, as it's a fixed
> + * regulator DVFS will not work as it is intructed
> + * to reach a voltage which can't be reached.
> + * Not specifying a regulator will create a dummy
> + * regulator allowing all OPPs.
> + *
> + * cpu-supply = <®_vdd_cpu_gpu>;
> + */
reg_vdd_cpu_gpu has
regulator-min-microvolt = <1135000>;
regulator-max-microvolt = <1135000>;
top OPP is:
opp@18 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <18>;
opp-microvolt-speed0 = <116>;
opp-microvolt-speed1 = <110>;
opp-microvolt-speed2 = <110>;
};
So I guess ignoring the voltage and not disabling this OPP may or may not work
based on SoC bin.
On Orange Pi One, there's a regulator that supports two voltages (that can't
support all the listed OPPs for H3), and cpufreq-dt can deal with that
automagically, if you specify OPP voltages via a tripplet of [prefered min max].
Kernell will log this in dmesg on boot:
[0.672440] core: _opp_supported_by_regulators: OPP minuV: 132 maxuV:
132, not supported by regulator
[0.672454] cpu cpu0: _opp_add: OPP not supported by regulators (110400)
[0.672523] core: _opp_supported_by_regulators: OPP minuV: 132 maxuV:
132, not supported by regulator
[0.672530] cpu cpu0: _opp_add: OPP not supported by regulators (12)
[0.672621] core: _opp_supported_by_regulators: OPP minuV: 134 maxuV:
134, not supported by regulator
[0.672628] cpu cpu0: _opp_add: OPP not supported by regulators (129600)
[0.672712] core: _opp_supported_by_regulators: OPP minuV: 140 maxuV:
140, not supported by regulator
[0.672719] cpu cpu0: _opp_add: OPP not supported by regulators (136800)
And the list of available OPPs will be reduced at runtime to a supportable
set by the CPU regulator.
If you look at:
https://megous.com/git/linux/commit/?h=ths-5.7&id=d231770195913cf543c0cf9539deee2ecec06680
you'll see a bunch of OPPs for H3 that are specified as a range. So
for example if you want 480MHz, and your regulator can't produce
1.04V exactly, cpufreq will set the voltage to something supportable
in the range.
I think the proper fix is to fix the OPP table for H6, so that it uses
voltage ranges for each OPP and not a single fixed voltage, to support
boards that don't have the standard PMIC that goes with H6.
regards,
o.
> };
>
> &de {
> @@ -68,7 +76,13 @@
> };
>
> &gpu {
> - mali-supply = <®_vdd_cpu_gpu>;
> + /*
> + * Don't specify the GPU regulator, see comment
> + * above for the CPU supply.
> + *
> + * mali-supply = <®_vdd_cpu_gpu>;
> + */
> +
> status = "okay";
> };
>
> --
> 2.20.1
>
> --
> 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/20200428142629.8950-1-peron.clem%40gmail.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/20200504122742.er2jd67bvrn2rfgp%40core.my.home.
[linux-sunxi] Re: [PATCH v5 2/9] arm64: dts: allwinner: h6: Add thermal trip points/cooling map
Hi,
On Mon, Apr 20, 2020 at 03:00:14PM +0200, Clément Péron wrote:
> From: Ondrej Jirman
>
> This enables passive cooling by down-regulating CPU voltage
> and frequency.
Does this not produce a lot of warnings for you during compilation?
regards,
o.
> Signed-off-by: Ondrej Jirman
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index 370e77b86fe1..60da1627772b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -964,6 +964,30 @@
> polling-delay-passive = <0>;
> polling-delay = <0>;
> thermal-sensors = <&ths 0>;
> +
> + trips {
> + cpu_alert: cpu-alert {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu-crit {
> + temperature = <10>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert>;
> + cooling-device = <&cpu0
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu1
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu2
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&cpu3
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> };
>
> gpu-thermal {
> --
> 2.20.1
>
--
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/20200420134604.bkjp66fjiggses7a%40core.my.home.
[linux-sunxi] Re: [PATCH v3 0/7] Add support for Allwinner H6 DVFS
Hi Maxime, On Mon, Apr 20, 2020 at 10:45:47AM +0200, Maxime Ripard wrote: > Hi, > > On Sun, Apr 19, 2020 at 03:50:04PM +0200, Clément Péron wrote: > > Now that required drivers are merged we can contibute on DVFS > > support for Allwinner H6. > > > > This serie is based on Yangtao Li serie[0] and Ondřej Jirman work[1]. > > > > Most of the OPP tables are taken from original vendor kernel[2]. > > Plus there are new CPU frequencies at 1.6GHz, 1.7GHz and 1.8GHz. > > > > I wrote a simple script to randomly set a frequency during > > a random time[3]. This script is quite stressfull and set some high > > frequency without checking temperature. This can result on behavior > > that whould not occurs with the real cpufreq framework. > > As Maxime point out I also tested with cpufreq-ljt-stress-test > > (found here https://github.com/ssvb/cpuburn-arm). > > This script doesn't trigger any issue. > > I also test that that offlining CPU0 and doing DVFS on other CPUs > > works. As CPU regulator is only set for CPU0. > > > > The GPU devfreq was drop as the regulator is still not properly > > drive by panfrost driver[4]. > > I will re-introduce it later. > > > > Ondřej Jirman has an Orange Pi 3, Jernej has a PineH64 and a Tanix > > TX6 boards and I have a Beelink GS1 board so I have enable these > > boards. But CPU Devfreq is really touchy has it depends on: > > board design, SoC speed_grade and environement which can affect > > thermal cooling and have different behavior for different user. > > > > If people can test this serie and give feedback, I will try to > > introduce this in LibreElec tree, so LE community can test it. > > Applied all of them, thanks! Please also apply "[PATCH v2 1/7] arm64: dts: allwinner: h6: Add clock to CPU cores" from the v2 series, otherwise cpufreq will not work. I can also send a missing patch adding the trip points, and cpu as a cooling device, that I linked in my other reply to this patch series afterwards, if Clément wants. regards, o. > Maxime -- 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/20200420103927.uvzotrolz2inz6q2%40core.my.home.
Re: [linux-sunxi] [PATCH v3 0/7] Add support for Allwinner H6 DVFS
On Mon, Apr 20, 2020 at 11:48:01AM +0200, megous hlavni wrote: > Hello Clément, > > On Sun, Apr 19, 2020 at 03:50:04PM +0200, Clément Péron wrote: > > Hi Sunxi maintainers and members, > > > > Now that required drivers are merged we can contibute on DVFS > > support for Allwinner H6. > > > > [ snip ] > > > > > Changes since v2 (thanks to Maxime Ripard): > > - Change Orange Pi boards to Orange Pi 3 > > - Change soc speed nvmem node name > > - Fix device tree warnings > > - Drop GPU opp tables > > Looks like you may have also inadverently dropped the second patch from v2 > series that implemented CPU thermal trip points. Also it looks like the patch 1 from v2 implementing the clock properties is missing from v3, and I don't see it being already applied anywhere. Without that cpufreq doesn't work. Also, thermal trip points need to be in the opp.dtsi to avoid dtc warnings during build. https://megous.com/git/linux/commit/?h=ths-5.7&id=cacefd7decf5ae0ce42ab4d48a13a58552929ebd regards, o. > > Changes since v1 (thanks to Ondřej Jirman): > > - Remove Polling thermal > > - Add Orange Pi boards > > - Remove minimal voltage change for Beelink GS1 > > - Add ramp-deplay for GPU and CPU regulators > > - Push to thermal point to 85°C (Allwinner set them to 100°C and 115°C) > > - Added 1.6GHz and 1.7GHz to OPP table. > > > > Clément Péron (6): > > arm64: configs: Enable sun50i cpufreq nvmem > > arm64: dts: allwinner: h6: Enable CPU opp tables for Beelink GS1 > > arm64: dts: allwinner: h6: Enable CPU opp tables for Orange Pi 3 > > arm64: dts: allwinner: h6: Enable CPU opp tables for Tanix TX6 > > arm64: dts: allwinner: Sort Pine H64 device-tree nodes > > arm64: dts: allwinner: h6: Enable CPU and GPU opp tables for Pine H64 > > You may also want to fix title of this patch to drop the GPU reference. > > thank you and regards, > o. > > > Ondrej Jirman (1): > > arm64: dts: allwinner: h6: Add CPU Operating Performance Points table -- 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/20200420102711.4ozfiiakvgisukpk%40core.my.home.
Re: [linux-sunxi] [PATCH v3 0/7] Add support for Allwinner H6 DVFS
Hello Clément, On Sun, Apr 19, 2020 at 03:50:04PM +0200, Clément Péron wrote: > Hi Sunxi maintainers and members, > > Now that required drivers are merged we can contibute on DVFS > support for Allwinner H6. > [ snip ] > > Changes since v2 (thanks to Maxime Ripard): > - Change Orange Pi boards to Orange Pi 3 > - Change soc speed nvmem node name > - Fix device tree warnings > - Drop GPU opp tables Looks like you may have also inadverently dropped the second patch from v2 series that implemented CPU thermal trip points. > Changes since v1 (thanks to Ondřej Jirman): > - Remove Polling thermal > - Add Orange Pi boards > - Remove minimal voltage change for Beelink GS1 > - Add ramp-deplay for GPU and CPU regulators > - Push to thermal point to 85°C (Allwinner set them to 100°C and 115°C) > - Added 1.6GHz and 1.7GHz to OPP table. > > Clément Péron (6): > arm64: configs: Enable sun50i cpufreq nvmem > arm64: dts: allwinner: h6: Enable CPU opp tables for Beelink GS1 > arm64: dts: allwinner: h6: Enable CPU opp tables for Orange Pi 3 > arm64: dts: allwinner: h6: Enable CPU opp tables for Tanix TX6 > arm64: dts: allwinner: Sort Pine H64 device-tree nodes > arm64: dts: allwinner: h6: Enable CPU and GPU opp tables for Pine H64 You may also want to fix title of this patch to drop the GPU reference. thank you and regards, o. > Ondrej Jirman (1): > arm64: dts: allwinner: h6: Add CPU Operating Performance Points table -- 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/20200420094801.ltsittj3gdrbbr3u%40core.my.home.
Re: [linux-sunxi] [PATCH 0/7] Add support for Allwinner H6 DVFS
Hi, On Sun, Apr 05, 2020 at 04:33:37PM +0200, Clément Péron wrote: > Hi Ondřej, [ ... ] > Good point, this information should be added for both CPU and GPU regulator. > This could be nice to confirm this point with a scope. > > Also I remark that Allwinner user higher temperature than what we set : > alarm_low_temp = <105000>; > alarm_high_temp = <11>; > alarm_temp_hysteresis = <15000>; > shut_temp= <115000>; > https://github.com/orangepi-xunlong/OrangePiH6_Linux4_9/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi#L1924 > > Don't you think that we can push a bit higher the temperature it's > actually at 80°C ? We probably can. But just 5°C between high temp and criticla temp is probably not enough. I'd probably set our value to something like 90-100°C so that quick temperature spike before regulation kicks in would not shutdown the CPU. regards, o. > Thanks for the review, > Clement > -- 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/20200405145443.uycsh73kxmurdmil%40core.my.home.
Re: [linux-sunxi] [PATCH 0/7] Add support for Allwinner H6 DVFS
Hello Clément, On Sun, Apr 05, 2020 at 12:49:06PM +0200, Clément Péron wrote: > Hi Sunxi maintainers and members, > > Now that required drivers are merged we can contibute on DVFS support for > Allwinner H6. > > This serie is based on Yangtao Li serie[0] and Megous works[1]. > > Most of the OPP tables are taken from original vendor kernel[2]. > Plus there is a new CPU frequency @1.8GHz. > > I wrote a simple script to randomly set a frequency during a random time[3]. > With this script and using stress-ng during a day I didn't see any issue. > Moreover I have tested specifically the 1.8GHz on my Beelink GS1, max thermal > 80°C is reached after ~10min and then the SoC oscillates quickly between 1.5 > and 1.8GHz. Thank you for working on this. :) I wonder what SoC bin you tested this on. I have a patch to print it here: https://megous.com/git/linux/commit/?h=ths-5.7&id=c5ddd2a45c7e04dcec31619b58de7c798ad6594c > I also test that that offlining CPU0 and doing DVFS on other CPUs works. > As CPU regulator is only set for CPU0. > > But maybe it doesn't cost much to set the regulator for all the CPUs? > > Jernej test the GPU devfreq on several H6 board particulary the Tanix TX6 > which > doesn't have a proper dedicated PMIC and doesn't had any trouble with it. > > Do you think I can enable GPU OPP for all H6 Boards? > > Also Yangtao Li enable DVFS for OrangePi and Pine64, as I can't test them I > didn't reenable these boards. Please, let me know if you want me to add these > boards in this serie. Feel free to add these OPPs also to OrangePi 3 dts, I've been running mine with this OPP table for at least a year already (I have the worst SoC bin). Though I'll run a bit more comprehensive test for more frequencies, like you did, just to be sure. One thing I wonder about is if there should not be some small ramp delay on the CPU regulator node, because voltage change probably takes some small time to apply, compared to changing the PLL frequency. And I have no idea if the CPU is not running for some very small time out of spec during transitions. I didn't find timing information in the PMIC datasheet, but I suppose based on the DCDCA frequency of 3MHz that it will adapt to the new voltage in the range of 1s-10s of microseconds. In datasheet of the similar PMIC (AXP813) there is this note: DVM (Dynamic Voltage scaling Management) ramp rate: 2.5mV/us at buck frequency 3MHz I think it will be simiar with AXP805. regards, o. > Thanks, > Clément > > 0: https://patchwork.kernel.org/cover/10815117/ > 1: https://megous.com/git/linux/log/?h=ths-5.7 > 2: > https://github.com/orangepi-xunlong/OrangePiH6_Linux4_9/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi#L345-L517 > 3: https://gist.github.com/clementperon/55a055dae3f13bbd14fb39c0069fe2e2 > > Clément Péron (4): > arm64: dts: allwinner: h6: set thermal polling time > arm64: dts: allwinner: h6: Add GPU Operating Performance Points table > arm64: configs: Enable sun50i cpufreq nvmem > arm64: dts: allwinner: h6: Enable CPU and GPU opp tables for Beelink > GS1 > > Ondrej Jirman (2): > arm64: dts: allwinner: h6: Add thermal trip points/cooling map > arm64: dts: allwinner: h6: Add CPU Operating Performance Points table > > Yangtao Li (1): > arm64: dts: allwinner: h6: Add clock to CPU cores > > .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 10 +- > .../boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi | 103 ++ > .../boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi | 74 + > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 44 +++- > arch/arm64/configs/defconfig | 1 + > 5 files changed, 226 insertions(+), 6 deletions(-) > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-gpu-opp.dtsi > > -- > 2.20.1 > > -- > 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/20200405104913.22806-1-peron.clem%40gmail.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/20200405115138.vrrvv7spnv6ifm6x%40core.my.home.
Re: [linux-sunxi] [PATCH 7/7] arm64: dts: allwinner: h6: Enable CPU and GPU opp tables for Beelink GS1
Hello,
On Sun, Apr 05, 2020 at 12:49:13PM +0200, Clément Péron wrote:
> Enable CPU and GPU opp tables for Beelink GS1.
>
> This needs also to change the CPU regulator min/max voltage to fit
> the OPP table.
>
> Signed-off-by: Clément Péron
> ---
> .../arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> index df6d872c34e2..8e65d56a7c85 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> @@ -4,6 +4,8 @@
> /dts-v1/;
>
> #include "sun50i-h6.dtsi"
> +#include "sun50i-h6-cpu-opp.dtsi"
> +#include "sun50i-h6-gpu-opp.dtsi"
>
> #include
>
> @@ -70,6 +72,10 @@
> };
> };
>
> +&cpu0 {
> + cpu-supply = <®_dcdca>;
> +};
> +
> &de {
> status = "okay";
> };
> @@ -226,8 +232,8 @@
>
> reg_dcdca: dcdca {
> regulator-always-on;
> - regulator-min-microvolt = <81>;
> - regulator-max-microvolt = <108>;
> + regulator-min-microvolt = <82>;
> + regulator-max-microvolt = <116>;
The H6 datasheet says:
- VDD-CPU Power Supply for CPU 0.81 - 1.08 V (recommended)
- VDD-CPU Power Supply for CPU -0.30 - 1.30 V (abs max)
So I guess there's no need to increase the lower limit, because it matches
the datasheet already.
regards,
o.
> regulator-name = "vdd-cpu";
> };
>
> --
> 2.20.1
>
> --
> 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/20200405104913.22806-8-peron.clem%40gmail.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/20200405113146.be2etxxjdkgtrmac%40core.my.home.
Re: [linux-sunxi] [PATCH 3/7] arm64: dts: allwinner: h6: set thermal polling time
Hello,
On Sun, Apr 05, 2020 at 12:49:09PM +0200, Clément Péron wrote:
> Add reasonable thermal polling time for Allwinner H6.
>
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index d4d3963705f5..c3e4f09f60ce 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -905,8 +905,8 @@
>
> thermal-zones {
> cpu-thermal {
> - polling-delay-passive = <0>;
> - polling-delay = <0>;
> + polling-delay-passive = <100>;
> + polling-delay = <1000>;
> thermal-sensors = <&ths 0>;
This is not necessary, and will not do anything useful, since the driver
uses interrupts to update the thermal zone's temperature. Please keep the
values at 0.
With your settings the thermal zone would just add a polling timer in addition
to being updated every 250ms via THS interrupt. The real thermal measurements
are available every 250ms anyway, so setting a smaller period here will not do
anything useful, and 1s period will not lead to slower updates either.
Values of 0 mean tell the thermal zone to rely on thermal driver to update
the thermal zone by itself (via interrupt) and to not poll.
regards,
o.
> trips {
> @@ -935,8 +935,8 @@
> };
>
> gpu-thermal {
> - polling-delay-passive = <0>;
> - polling-delay = <0>;
> + polling-delay-passive = <100>;
> + polling-delay = <1000>;
> thermal-sensors = <&ths 1>;
> };
> };
> --
> 2.20.1
>
> --
> 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/20200405104913.22806-4-peron.clem%40gmail.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/20200405112409.gl6kn7cjakwludf6%40core.my.home.
Re: [linux-sunxi] [PATCH v2 5/5] arm64: allwinner: dts: a64: add LCD-related device nodes for PinePhone
On Thu, Mar 19, 2020 at 10:51:36PM +0800, Icenowy Zheng wrote:
> 在 2020-03-16星期一的 21:35 +0800，Icenowy Zheng写道：
> > PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> > display.
> >
> > Add its device nodes.
> >
> > Signed-off-by: Icenowy Zheng
> > ---
> > No changes in v2.
> >
> > .../dts/allwinner/sun50i-a64-pinephone.dtsi | 37
> > +++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > index cefda145c3c9..96d9150423e0 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > @@ -16,6 +16,15 @@ aliases {
> > serial0 = &uart0;
> > };
> >
> > + backlight: backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&r_pwm 0 5 PWM_POLARITY_INVERTED>;
> > + brightness-levels = <0 16 18 20 22 24 26 29 32 35 38 42
> > 46 51 56 62 68 75 83 91 100>;
>
> Should I drop the 0 here and replace it with 14?
Almost all boards in arm/boot/dts start at 0.
> I have heard community complaining about setting 0 to brightness make
> the screen black.
Level 0 (first value in the list) is special, and turns off the backlight:
123 if (brightness > 0) {
124 pwm_get_state(pb->pwm, &state);
125 state.duty_cycle = compute_duty_cycle(pb, brightness);
126 pwm_apply_state(pb->pwm, &state);
127 pwm_backlight_power_on(pb);
128 } else {
129 pwm_backlight_power_off(pb);
130 }
o.
> (I think in this situation bl_power or blank the DSI panel can still
> totally shut down the backlight).
>
> > + default-brightness-level = <15>;
> > + enable-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> > + power-supply = <®_ldo_io0>;
> > + };
> > +
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
> > @@ -84,6 +93,30 @@ &dai {
> > status = "okay";
> > };
> >
> > +&de {
> > + status = "okay";
> > +};
> > +
> > +&dphy {
> > + status = "okay";
> > +};
> > +
> > +&dsi {
> > + vcc-dsi-supply = <®_dldo1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + panel@0 {
> > + compatible = "xingbangda,xbd599";
> > + reg = <0>;
> > + reset-gpios = <&pio 3 23 GPIO_ACTIVE_LOW>; /* PD23 */
> > + iovcc-supply = <®_dldo2>;
> > + vcc-supply = <®_ldo_io0>;
> > + backlight = <&backlight>;
> > + };
> > +};
> > +
> > &ehci0 {
> > status = "okay";
> > };
> > @@ -188,6 +221,10 @@ &r_pio {
> > */
> > };
> >
> > +&r_pwm {
> > + status = "okay";
> > +};
> > +
> > &r_rsb {
> > status = "okay";
> >
> > --
> > 2.24.1
> >
>
--
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/20200319161002.kmivhr3ouhoyn4bt%40core.my.home.
[linux-sunxi] Re: [PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
Hello Icenowy,
On Mon, Mar 16, 2020 at 09:35:01PM +0800, Icenowy Zheng wrote:
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> Xingbangda, which is used on PinePhone final assembled phones.
>
> [snip]
>
> +static const struct drm_display_mode xbd599_default_mode = {
> + .hdisplay= 720,
> + .hsync_start = 720 + 40,
> + .hsync_end = 720 + 40 + 40,
> + .htotal = 720 + 40 + 40 + 40,
> + .vdisplay= 1440,
> + .vsync_start = 1440 + 18,
> + .vsync_end = 1440 + 18 + 10,
> + .vtotal = 1440 + 18 + 10 + 17,
> + .vrefresh= 60,
Does the display actually run for you at 60fps? I measured 36.63 FPS with
a DRM app that just does DRM_IOCTL_MODE_ATOMIC update after each
DRM_EVENT_FLIP_COMPLETE event.
thank you and regards,
o.
> + .clock = 69000,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +
> + .width_mm= 68,
> + .height_mm = 136,
> + .type= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
--
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/20200316191122.yeb5l22ldtt73vx5%40core.my.home.
Re: [linux-sunxi] [PATCH 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet
On Tue, Mar 10, 2020 at 11:27:24AM +0100, Pascal Roeleven wrote:
> The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
> different brands. The mainboard mentions A721 clearly, so this tablet
> is best known under this name.
>
> Signed-off-by: Pascal Roeleven
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 302 +++
> 2 files changed, 304 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
>
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Topwise A721";
> + compatible = "topwise,a721", "allwinner,sun4i-a10";
And you also need to add the compatible to:
Documentation/devicetree/bindings/arm/sunxi.yaml
regards,
o.
--
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/20200310140452.cfzw2o7al6uf2fpp%40core.my.home.
Re: [linux-sunxi] [PATCH 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet
Hello Pascal,
On Tue, Mar 10, 2020 at 11:27:24AM +0100, Pascal Roeleven wrote:
> The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
> different brands. The mainboard mentions A721 clearly, so this tablet
> is best known under this name.
>
> Signed-off-by: Pascal Roeleven
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 302 +++
> 2 files changed, 304 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 78f144e33..6e6141e00 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1040,7 +1040,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb \
> sun4i-a10-pcduino2.dtb \
> - sun4i-a10-pov-protab2-ips9.dtb
> + sun4i-a10-pov-protab2-ips9.dtb \
> + sun4i-a10-topwise-a721.dtb
> dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a10s-auxtek-t003.dtb \
> sun5i-a10s-auxtek-t004.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> new file mode 100644
> index 0..ff43c9c12
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
> @@ -0,0 +1,302 @@
> +/*
> + * Copyright 2020 Pascal Roeleven
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
You should use SPDX license identifier instead of boilerplate license
text.
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Topwise A721";
> + compatible = "topwise,a721", "allwinner,sun4i-a10";
topwise is not in vendor-prefixes.yaml
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 10 PWM_POLARITY_INVERTED>;
> + power-supply = <®_vbat>;
> + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> + brightness-levels = <0 30 40 50 60 70 80 90 100>;
> + default-brightness-level = <8>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + panel: panel {
> + compatible = "starry,kr070pe2t";
> + backlight = <&backlight>;
> + power-supply = <®_lcd_power>;
> +
> + port {
> + panel_input: endpoint {
> + remote-endpoint = <&tcon0_out_panel>;
> + };
> + };
> + };
> +
> + reg_lcd_power: reg-lcd-power {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_power_pin>;
> + regulator-name = "reg-lcd-power";
> + gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
> +
[linux-sunxi] Re: [PATCH v2 0/3] Add support for Pine64 PinePhone Linux Smartphone
On Thu, Feb 27, 2020 at 02:04:27PM +0100, Maxime Ripard wrote: > On Thu, Feb 27, 2020 at 02:26:47AM +0100, Ondrej Jirman wrote: > > This series adds an initial support for Pine64 PinePhone. > > > > Please take a look. > > > > thank you and regards, > > Ondrej Jirman > > Applied all three, thanks Thank you too! :) regards, o. > Maxime -- 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/20200227155259.2gvtmeiismceh7ca%40core.my.home.
[linux-sunxi] Re: [PATCH v2 2/3] dt-bindings: arm: sunxi: Add PinePhone 1.0 and 1.1 bindings
Hello, On Thu, Feb 27, 2020 at 02:26:49AM +0100, megous hlavni wrote: > Document board compatible names for Pine64 PinePhone: > > - 1.0 - Developer variant > - 1.1 - Braveheart variant > > Signed-off-by: Ondrej Jirman This also got: Reviewed-by: Rob Herring short time ago on v1. I didn't catch that before sending v2 out. regards, o. > --- > Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml > b/Documentation/devicetree/bindings/arm/sunxi.yaml > index 5b22b77e4bb73..abf2d97fb7ae3 100644 > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml > @@ -642,6 +642,16 @@ properties: >- const: pine64,pinebook >- const: allwinner,sun50i-a64 > > + - description: Pine64 PinePhone Developer Batch (1.0) > +items: > + - const: pine64,pinephone-1.0 > + - const: allwinner,sun50i-a64 > + > + - description: Pine64 PinePhone Braveheart (1.1) > +items: > + - const: pine64,pinephone-1.1 > + - const: allwinner,sun50i-a64 > + >- description: Pine64 PineTab > items: >- const: pine64,pinetab > -- > 2.25.1 > -- 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/20200227013247.mufbxd4gsc5c6g6p%40core.my.home.
[linux-sunxi] Re: [PATCH v2] ARM: dts: sun8i-a83t: Add thermal trip points/cooling maps
On Mon, Feb 24, 2020 at 06:56:18PM +0100, Daniel Lezcano wrote: > On 24/02/2020 18:39, Ondřej Jirman wrote: > > On Mon, Feb 24, 2020 at 06:23:28PM +0100, megous hlavni wrote: > > > > To be more clear, new temperatures are available from the thermal sensor > > driver > > at the rate of 4 per second, which should be enough to do quick adjustments > > to > > the thermal zone/cooling device even for quick temperature rises. > > > > https://elixir.bootlin.com/linux/v5.6-rc3/source/drivers/thermal/sun8i_thermal.c#L442 > > > > There's no slow/fast period depending on whether the cooling is active. > > It's always fast and no polling of the thermal sensor is needed. > > Thanks for the clarification. All sensors have their specificity. > > Does the sensor allow to create a threshold temperature where an > interrupt fires when crossing the boundary? That would be interesting > for performance and energy saving to disable the interrupts until > 'cpu0_hot' is reached, no? I think so. I don't think it would affect this binding though. It would still require no polling, and thermal driver would probably just have to be updated to get the relevant information about trip points from the thermal zone and notify it of changes/trip point crossing. I don't think it would affect performance or energy saving much though. 4 interrupts per second is barely noticeable, and there are much bigger fish to fry, when it comes to power savings on A83T at this point. thank you and regards, o. > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | > <http://www.linaro.org/linaro-blog/> Blog > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200224183300.jnclticehmc7uevs%40core.my.home.
[linux-sunxi] Re: [PATCH v2] ARM: dts: sun8i-a83t: Add thermal trip points/cooling maps
On Mon, Feb 24, 2020 at 06:23:28PM +0100, megous hlavni wrote:
> Hi,
>
> On Mon, Feb 24, 2020 at 06:06:20PM +0100, Daniel Lezcano wrote:
> > On 24/02/2020 17:54, Ondrej Jirman wrote:
> > > This enables passive cooling by down-regulating CPU voltage
> > > clocks = <&ccu CLK_C1CPUX>;
> > > @@ -1188,12 +1188,60 @@ cpu0_thermal: cpu0-thermal {
> > > polling-delay-passive = <0>;
> > > polling-delay = <0>;
> > > thermal-sensors = <&ths 0>;
> > > +
> > > + trips {
> > > + cpu0_hot: cpu-hot {
> > > + temperature = <8>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> > > + };
> > > +
> > > + cpu0_very_hot: cpu-very-hot {
> > > + temperature = <10>;
> > > + hysteresis = <0>;
> > > + type = "critical";
> > > + };
> > > + };
> > > +
> > > + cooling-maps {
> > > + cpu-hot-limit {
> > > + trip = <&cpu0_hot>;
> > > + cooling-device = <&cpu0
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&cpu1
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&cpu2
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&cpu3
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > > + };
> > > + };
> > > };
> > >
> > > cpu1_thermal: cpu1-thermal {
> > > polling-delay-passive = <0>;
> >
> > No polling to mitigate?
>
> Polling to mitigate what?
>
> The driver is using interrupts whenever new reading is available, and
> notifies tz of the change. I don't have a reason to believe any new
> values are available from thermal sensor outside of the interrupt
> period.
To be more clear, new temperatures are available from the thermal sensor driver
at the rate of 4 per second, which should be enough to do quick adjustments to
the thermal zone/cooling device even for quick temperature rises.
https://elixir.bootlin.com/linux/v5.6-rc3/source/drivers/thermal/sun8i_thermal.c#L442
There's no slow/fast period depending on whether the cooling is active.
It's always fast and no polling of the thermal sensor is needed.
regards,
o.
> > > polling-delay = <0>;
> > > thermal-sensors = <&ths 1>;
> > > +
> > > + trips {
> > > + cpu1_hot: cpu-hot {
> > > + temperature = <8>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> >
> > I'm curious, can you really reach this temperature with a cortex-a7
> > running at 1.2GHz max?
>
> That depends on ambient temperature. I'd say easily. My A83T is running
> iniside enclosed space with no cooling other than dissipating heat to
> the board.
>
> Anyway, I'm running my A83T boards at 1.8GHz. And A83T can run up to 2GHz
> at the best SoC bin.
>
> I'll probably submit updated cpufreq table at some point too, once I fix
> it up to use the SoC bin information.
>
> https://megous.com/git/linux/commit/?h=ths-5.6&id=171b7c3c3db98b5939d28d0c96b384edda95cec3
>
> regards,
> o.
>
> > > + };
> > > +
> > > + cpu1_very_hot: cpu-very-hot {
> > > + temperature = <10>;
> > > + hysteresis = <0>;
> > > + type = "critical";
> > > + };
> > > + };
> > > +
> > > + cooling-maps {
> > > + cpu-hot-limit {
> > > + trip = <&cpu1_hot>;
> > > + cooling-device = <&cpu100
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&cpu101
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&cpu102
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > + <&cpu103
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > > + };
> > > + };
> > > };
> > >
> > > gpu_thermal: gpu-thermal {
> > >
> >
> >
> > --
> > Facebook |
> > Twitter |
> >
[linux-sunxi] Re: [PATCH v2] ARM: dts: sun8i-a83t: Add thermal trip points/cooling maps
Hi,
On Mon, Feb 24, 2020 at 06:06:20PM +0100, Daniel Lezcano wrote:
> On 24/02/2020 17:54, Ondrej Jirman wrote:
> > This enables passive cooling by down-regulating CPU voltage
> > clocks = <&ccu CLK_C1CPUX>;
> > @@ -1188,12 +1188,60 @@ cpu0_thermal: cpu0-thermal {
> > polling-delay-passive = <0>;
> > polling-delay = <0>;
> > thermal-sensors = <&ths 0>;
> > +
> > + trips {
> > + cpu0_hot: cpu-hot {
> > + temperature = <8>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > +
> > + cpu0_very_hot: cpu-very-hot {
> > + temperature = <10>;
> > + hysteresis = <0>;
> > + type = "critical";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + cpu-hot-limit {
> > + trip = <&cpu0_hot>;
> > + cooling-device = <&cpu0
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > +<&cpu1
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > +<&cpu2
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > +<&cpu3
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + };
> > + };
> > };
> >
> > cpu1_thermal: cpu1-thermal {
> > polling-delay-passive = <0>;
>
> No polling to mitigate?
Polling to mitigate what?
The driver is using interrupts whenever new reading is available, and
notifies tz of the change. I don't have a reason to believe any new
values are available from thermal sensor outside of the interrupt
period.
> > polling-delay = <0>;
> > thermal-sensors = <&ths 1>;
> > +
> > + trips {
> > + cpu1_hot: cpu-hot {
> > + temperature = <8>;
> > + hysteresis = <2000>;
> > + type = "passive";
>
> I'm curious, can you really reach this temperature with a cortex-a7
> running at 1.2GHz max?
That depends on ambient temperature. I'd say easily. My A83T is running
iniside enclosed space with no cooling other than dissipating heat to
the board.
Anyway, I'm running my A83T boards at 1.8GHz. And A83T can run up to 2GHz
at the best SoC bin.
I'll probably submit updated cpufreq table at some point too, once I fix
it up to use the SoC bin information.
https://megous.com/git/linux/commit/?h=ths-5.6&id=171b7c3c3db98b5939d28d0c96b384edda95cec3
regards,
o.
> > + };
> > +
> > + cpu1_very_hot: cpu-very-hot {
> > + temperature = <10>;
> > + hysteresis = <0>;
> > + type = "critical";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + cpu-hot-limit {
> > + trip = <&cpu1_hot>;
> > + cooling-device = <&cpu100
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > +<&cpu101
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > +<&cpu102
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > +<&cpu103
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + };
> > + };
> > };
> >
> > gpu_thermal: gpu-thermal {
> >
>
>
> --
> Facebook |
> Twitter |
>
Re: [linux-sunxi] Re: [PATCH 0/4] Add support for charger LED for AXP813 and TBS A711 Tablet
On Mon, Feb 24, 2020 at 08:31:06AM +0200, Stefan Mavrodiev wrote: > > On 2/23/20 3:35 PM, Ondřej Jirman wrote: > > On Sun, Feb 23, 2020 at 02:27:30PM +0100, megous hlavni wrote: > > > On Sun, Feb 23, 2020 at 02:14:31PM +0100, megous hlavni wrote: > > > > The tablet has a charger LED exposed on the top. This LED is controlled > > > > by AXP813 PMIC. Add support for enabling the LED and using it either > > > > for charging indication (handled by PMIC automatically) or for other > > > > uses > > > > via user control. > > > Dang, I just noticed someone sent a similar driver recently, although I > > > had this > > > one prepared for quite some time (since 2017) in my tree. I guess I > > > should have > > > sent it earlier. > > > > > > Please ignore. > > Though the meaning of "recently" is a bit relative. The other work was sent > > in > > a year ago. Here's a reference: > > > >https://lore.kernel.org/patchwork/cover/1042764/ > > Hi, > > I'm the author of the 'other' work. I don't know the full story here, but I > don't > mind someone else submitting this patch as his. Hello Stefan, There's really no story. Just me being a bit anoyed at myself, for not checking the mailing lists prior to spending some time cleaning up and extending some old patches to upstream them, and wasting quite a bit of time in the process. https://megous.com/git/linux/commit/?h=linux-tbs&id=737eec64565d328cab98b75879e3f9eb1cf2f609 > When I submitted the last patch, there was the proposal to use the > ledtrig-pattern instead > of sysfs entries. Also AXP209 has inverted CTRL bit. > > Please read the the 'other' discussion. Thanks, I'll check it out. regards, o. > Best regards, > Stefan Mavrodiev > > > > > > regards, > > > o. > > > > > > > > > > Please take a look. > > > > > > > > thank you and regards, > > > >Ondrej Jirman > > > > > > > > Ondrej Jirman (4): > > > >dt-bindings: leds: Add a binding for AXP813 charger led > > > >leds: axp20x: Support charger LED on AXP20x like PMICs > > > >ARM: dts: axp813: Add charger LED > > > >ARM: dts: sun8i-a83t-tbs-a711: Enable charging LED > > > > > > > > .../devicetree/bindings/leds/leds-axp20x.yaml | 24 ++ > > > > arch/arm/boot/dts/axp81x.dtsi | 5 + > > > > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 + > > > > drivers/leds/Kconfig | 7 + > > > > drivers/leds/Makefile | 1 + > > > > drivers/leds/leds-axp20x.c| 240 ++ > > > > drivers/mfd/axp20x.c | 3 + > > > > 7 files changed, 284 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/leds/leds-axp20x.yaml > > > > create mode 100644 drivers/leds/leds-axp20x.c > > > > > > > > -- > > > > 2.25.1 > > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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/20200224162840.z7csqagz2frwvmf3%40core.my.home.
[linux-sunxi] Re: [PATCH v2] arm64: dts: sun50i-h5-orange-pi-pc2: Add CPUX voltage regulator
On Mon, Feb 24, 2020 at 10:27:04AM +0100, Maxime Ripard wrote:
> On Sun, Feb 23, 2020 at 11:40:19AM +0100, Ondrej Jirman wrote:
> > Orange Pi PC2 features sy8106a regulator just like Orange Pi PC.
> >
> > Signed-off-by: Ondrej Jirman
> > Reviewed-by: Samuel Holland
> > ---
> > .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 20 +++
> > 1 file changed, 20 insertions(+)
>
> Having a changelog would be great
>
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > index 70b5f09984218..7b2572dc84857 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > @@ -93,6 +93,10 @@ &codec {
> > status = "okay";
> > };
> >
> > +&cpu0 {
> > + cpu-supply = <®_vdd_cpux>;
> > +};
> > +
> > &de {
> > status = "okay";
> > };
> > @@ -168,6 +172,22 @@ &ohci3 {
> > status = "okay";
> > };
> >
> > +&r_i2c {
> > + status = "okay";
> > +
> > + reg_vdd_cpux: regulator@65 {
> > + compatible = "silergy,sy8106a";
> > + reg = <0x65>;
> > + regulator-name = "vdd-cpux";
> > + silergy,fixed-microvolt = <110>;
> > + regulator-min-microvolt = <100>;
> > + regulator-max-microvolt = <140>;
> > + regulator-ramp-delay = <200>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +};
> > +
>
> Looks like you fixed the issues reported by Samuel though. I've
> applied it.
Sorry, yes, I just did that. Re-ordering + removing a comment and changing the
fixed voltage.
Thank you,
o.
> Maxime
--
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/20200224151131.fw7to7pmegj5ylqy%40core.my.home.
[linux-sunxi] Re: [PATCH 3/4] ARM: dts: sun8i-a83t-tbs-a711: Add support for the vibrator motor
Hello,
On Mon, Feb 24, 2020 at 10:10:59AM +0100, Maxime Ripard wrote:
> Hi,
>
> On Sun, Feb 23, 2020 at 12:14:27AM +0100, Ondrej Jirman wrote:
> > The board has a vibrator mottor. Hook it to the input subsystem.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > index 2fd31a0a0b344..a22920275e99b 100644
> > --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > @@ -99,6 +99,11 @@ panel_input: endpoint {
> > };
> > };
> >
> > + vibrator {
> > + compatible = "gpio-vibrator";
> > + vcc-supply = <®_ldo_io1>;
> > + };
> > +
>
> LDO IO1 can also be muxed in as a GPIO iirc, why did you choose the
> regulator instead?
According to the specification, LDO needs to be enabled (value 0b11)
to achieve the specified max driving current of 150mA:
https://megous.com/dl/tmp/92b7d9d94820c3ba.png
Otherwise the chip is probably just using the regular CMOS logic output
(typically limited to around 20-35mA, but not specified in this datasheet),
which would be probably overdriven, if we try to drive the motor with it.
And since we're driving a motor directly, the more the better.
thank you and regards,
o.
> Maxime
--
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/20200224141437.opcsfhozfppulu4g%40core.my.home.
[linux-sunxi] Re: [PATCH 1/3] arm64: dts: sun50i-a64: Add i2c2 pins
On Mon, Feb 24, 2020 at 12:01:00PM +0100, Maxime Ripard wrote:
> On Sun, Feb 23, 2020 at 06:29:14PM +0100, Ondrej Jirman wrote:
> > PinePhone needs I2C2 pins description. Add it.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 862b47dc9dc90..0fdf5f400d743 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -671,6 +671,11 @@ i2c1_pins: i2c1-pins {
> > function = "i2c1";
> > };
> >
> > + i2c2_pins: i2c2-pins {
> > + pins = "PE14", "PE15";
> > + function = "i2c2";
> > + };
> > +
>
> Setting it as the default muxing for i2c2 would be great
Right, I checked the datasheet and it looks like this is the only pins where
i2c2 can be muxed to.
I will change it.
regards,
o.
> Maxime
--
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/20200224125945.dyl7reaqqiqds4ee%40core.my.home.
[linux-sunxi] Re: [PATCH 3/3] arm64: dts: allwinner: Add initial support for Pine64 PinePhone
Hello Maxime,
On Mon, Feb 24, 2020 at 12:00:27PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Sun, Feb 23, 2020 at 06:29:16PM +0100, Ondrej Jirman wrote:
> > At them moment PinePhone comes in two slightly incompatible variants:
> >
> > - 1.0: Early Developer Batch
> > - 1.1: Braveheart Batch
> >
> > There will be at least one more incompatible variant in the very near
> > future, so let's start by sharing the dtsi among multiple variants,
> > right away, even though the HW description doesn't yet include the
> > different bits.
> >
> > This is a basic DT that includes only features that are already
> > supported by mainline drivers.
>
> What are those incompatibilities? It's not really obvious from your
> patch.
The changes are listed here:
https://wiki.pine64.org/index.php/PinePhone_v1.1_-_Braveheart#Changes_from_1.0
Substantial ones are:
2. Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were
reversed
5. Set the EG25G's PWRKEY on by default (see resistor R1526)
6. Add R630 resistor location, populate with 0K by default. Allows adjusting to
different battery thermistors in case this is not possible in software.
The incompatiblilities between 1.1 and 1.2 will be more extensive:
https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_GPIO_Hardware_Changes
> > Co-developed-by: Samuel Holland
> > Signed-off-by: Samuel Holland
> > Co-developed-by: Martijn Braam
> > Signed-off-by: Martijn Braam
> > Co-developed-by: Luca Weiss
> > Signed-off-by: Luca Weiss
> > Signed-off-by: Bhushan Shah
> > Signed-off-by: Icenowy Zheng
> > Signed-off-by: Ondrej Jirman
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile| 2 +
> > .../allwinner/sun50i-a64-pinephone-1.0.dts| 11 +
> > .../allwinner/sun50i-a64-pinephone-1.1.dts| 11 +
> > .../dts/allwinner/sun50i-a64-pinephone.dtsi | 385 ++
> > 4 files changed, 409 insertions(+)
> > create mode 100644
> > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > create mode 100644
> > arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> > b/arch/arm64/boot/dts/allwinner/Makefile
> > index cf4f78617c3f3..79ca263672c38 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -9,6 +9,8 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb
> > sun50i-a64-pine64.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > new file mode 100644
> > index 0..0c42272106afa
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Ondrej Jirman
>
> Given the list of authors, surely you're not the sole copyright owner
> here?
Yes, I made this and the 1.1 dts file by myself. It's not really a meaningful
contribution, since at the moment it's basically empty. I suppose to have
a license, the file requires some author.
Collaborative work is mostly in the dtsi.
> > +/dts-v1/;
> > +
> > +#include "sun50i-a64-pinephone.dtsi"
> > +
> > +/ {
> > + model = "Pine64 PinePhone Developer Batch (1.0)";
> > + compatible = "pine64,pinephone-1.0", "allwinner,sun50i-a64";
> > +};
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > new file mode 100644
> > index 0..06a775c41664b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Ondrej Jirman
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-a64-pinephone.dtsi"
> > +
> > +/ {
> > + model = "Pine64 PinePhone Braveheart (1.1)";
> > + compatible = "pine64,pinephone-1.1", "allwinner,sun50i-a64";
> > +};
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > new file mode 100644
> > index 0..d0cf21d82c9e9
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> > @@ -0,0 +1,385 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2019 Icenowy Zheng
> > +// Copyr
[linux-sunxi] Re: [PATCH 0/4] Add support for charger LED for AXP813 and TBS A711 Tablet
On Sun, Feb 23, 2020 at 02:27:30PM +0100, megous hlavni wrote: > On Sun, Feb 23, 2020 at 02:14:31PM +0100, megous hlavni wrote: > > The tablet has a charger LED exposed on the top. This LED is controlled > > by AXP813 PMIC. Add support for enabling the LED and using it either > > for charging indication (handled by PMIC automatically) or for other uses > > via user control. > > Dang, I just noticed someone sent a similar driver recently, although I had > this > one prepared for quite some time (since 2017) in my tree. I guess I should > have > sent it earlier. > > Please ignore. Though the meaning of "recently" is a bit relative. The other work was sent in a year ago. Here's a reference: https://lore.kernel.org/patchwork/cover/1042764/ > regards, > o. > > > > Please take a look. > > > > thank you and regards, > > Ondrej Jirman > > > > Ondrej Jirman (4): > > dt-bindings: leds: Add a binding for AXP813 charger led > > leds: axp20x: Support charger LED on AXP20x like PMICs > > ARM: dts: axp813: Add charger LED > > ARM: dts: sun8i-a83t-tbs-a711: Enable charging LED > > > > .../devicetree/bindings/leds/leds-axp20x.yaml | 24 ++ > > arch/arm/boot/dts/axp81x.dtsi | 5 + > > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 + > > drivers/leds/Kconfig | 7 + > > drivers/leds/Makefile | 1 + > > drivers/leds/leds-axp20x.c| 240 ++ > > drivers/mfd/axp20x.c | 3 + > > 7 files changed, 284 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/leds/leds-axp20x.yaml > > create mode 100644 drivers/leds/leds-axp20x.c > > > > -- > > 2.25.1 > > -- 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/20200223133517.hfqrg5dta2xk4zj3%40core.my.home.
[linux-sunxi] Re: [PATCH 0/4] Add support for charger LED for AXP813 and TBS A711 Tablet
On Sun, Feb 23, 2020 at 02:14:31PM +0100, megous hlavni wrote: > The tablet has a charger LED exposed on the top. This LED is controlled > by AXP813 PMIC. Add support for enabling the LED and using it either > for charging indication (handled by PMIC automatically) or for other uses > via user control. Dang, I just noticed someone sent a similar driver recently, although I had this one prepared for quite some time (since 2017) in my tree. I guess I should have sent it earlier. Please ignore. regards, o. > Please take a look. > > thank you and regards, > Ondrej Jirman > > Ondrej Jirman (4): > dt-bindings: leds: Add a binding for AXP813 charger led > leds: axp20x: Support charger LED on AXP20x like PMICs > ARM: dts: axp813: Add charger LED > ARM: dts: sun8i-a83t-tbs-a711: Enable charging LED > > .../devicetree/bindings/leds/leds-axp20x.yaml | 24 ++ > arch/arm/boot/dts/axp81x.dtsi | 5 + > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 + > drivers/leds/Kconfig | 7 + > drivers/leds/Makefile | 1 + > drivers/leds/leds-axp20x.c| 240 ++ > drivers/mfd/axp20x.c | 3 + > 7 files changed, 284 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/leds-axp20x.yaml > create mode 100644 drivers/leds/leds-axp20x.c > > -- > 2.25.1 > -- 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/20200223132730.6g7tnm2f263oubhv%40core.my.home.
Re: [linux-sunxi] [PATCH 1/4] ARM: dts: sun8i-a83t-tbs-a711: OOB WiFi interrupt doesn't work
Hello,
On Sun, Feb 23, 2020 at 12:03:46PM +0800, Chen-Yu Tsai wrote:
> On Sun, Feb 23, 2020 at 11:26 AM Chen-Yu Tsai wrote:
> >
> > Hi,
> >
> >
> > On Sun, Feb 23, 2020 at 6:32 AM Ondrej Jirman wrote:
> > >
> > > It just causes a constant rate of 5000 interrupts per second for both
> > > GPIO and MMC, even if nothing is happening. Rely on in-band interrupts
> > > instead.
> > >
> > > Fixes: 0e23372080def7bb ("arm: dts: sun8i: Add the TBS A711 tablet
> > > devicetree")
> > > Signed-off-by: Ondrej Jirman
> >
> > What WiFi chip/module does this use? It might be worth asking Broadcom
> > people to help with this and fix the driver.
>
> Based on the comments in the device tree file, it uses an AP6210, which
> is a BCM43362 inside for SDIO-based WiFi. There is a recent fix in 5.6-rc1
> for this,
>
> 8c8e60fb86a9 brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362
>
> which seems to fix things for me. Could you try it on your end?
I can confirm that it works as you say (on linus/master). 5.5 still doesn't have
the patch, so it's broken there, which confused me I guess.
Please ignore this patch.
thank you,
Ondrej
> ChenYu
>
>
> > ChenYu
> >
> > > ---
> > > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > index 2fd31a0a0b344..ee5ce3556b2ad 100644
> > > --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > @@ -214,9 +214,6 @@ &mmc1 {
> > > brcmf: wifi@1 {
> > > reg = <1>;
> > > compatible = "brcm,bcm4329-fmac";
> > > - interrupt-parent = <&r_pio>;
> > > - interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 WL_WAKE_UP
> > > */
> > > - interrupt-names = "host-wake";
> > > };
> > > };
> > >
> > > --
> > > 2.25.1
> > >
> > > --
> > > 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/2020023154.221632-2-megous%40megous.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/20200223105524.smp3p2quewp3ddop%40core.my.home.
Re: [linux-sunxi] [PATCH] arm64: dts: sun50i-h5-orange-pi-pc2: Add CPUX voltage regulator
Hi Samuel,
On Sat, Feb 22, 2020 at 09:26:30PM -0600, Samuel Holland wrote:
> Hi Ondrej,
>
> On 2/22/20 3:45 PM, Ondrej Jirman wrote:
> > Orange Pi PC2 features sy8106a regulator just like Orange Pi PC.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 29 +++
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > index 70b5f09984218..5feedde95b5fc 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> > @@ -85,6 +85,10 @@ reg_usb0_vbus: usb0-vbus {
> > };
> > };
> >
> > +&cpu0 {
> > + cpu-supply = <®_vdd_cpux>;
> > +};
> > +
>
> This should go alphabetically after "codec".
>
> > &codec {
> > allwinner,audio-routing =
> > "Line Out", "LINEOUT",
> > @@ -180,6 +184,31 @@ flash@0 {
> > };
> > };
> >
> > +&r_i2c {
>
> This should go alphabetically before "spi0".
>
> > + status = "okay";
> > +
> > + reg_vdd_cpux: regulator@65 {
> > + compatible = "silergy,sy8106a";
> > + reg = <0x65>;
> > + regulator-name = "vdd-cpux";
> > + silergy,fixed-microvolt = <120>;
>
> The resistors in the datasheet (10k/11.8k) make this 1.1V.
Ah, you're right. I didn't notice the fine print bellow:
https://megous.com/dl/tmp/e696b6042b80bf2e.png
only the big number above. Hehe.
> > + /*
> > +* The datasheet uses 1.1V as the minimum value of VDD-CPUX,
> > +* however both the Armbian DVFS table and the official one
> > +* have operating points with voltage under 1.1V, and both
> > +* DVFS table are known to work properly at the lowest
> > +* operating point.
> > +*
> > +* Use 1.0V as the minimum voltage instead.
> > +*/
>
> The datasheet I have for H5 has "TBD" for the VDD-CPUX volatage range. I think
> this comment only applies to H3 and is not necessary here.
Ok.
> > + regulator-min-microvolt = <100>;
> > + regulator-max-microvolt = <140>;
> > + regulator-ramp-delay = <200>;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > &uart0 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&uart0_pa_pins>;
> >
>
> Otherwise,
> Reviewed-by: Samuel Holland
Thanks for the feedback.
regards,
o.
> Regards,
> Samuel
--
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/20200223103736.5uigz2nvvee3w5yr%40core.my.home.
[linux-sunxi] Re: [PATCH] ARM: dts: sun8i-h3: Add thermal trip points/cooling maps
Hello, On Sun, Feb 23, 2020 at 11:29:31AM +0800, Chen-Yu Tsai wrote: > On Sun, Feb 23, 2020 at 5:42 AM Ondrej Jirman wrote: > > > > This enables passive cooling by down-regulating CPU voltage > > and frequency. > > > Please state for the record how the trip points were derived. Were they from > the BSP? Or the user manual? I used a slightly lowered value from the BSP code. 110 seemed like a lot for the critical temp. So I rounded it off to 100°C. https://megous.com/git/linux/tree/drivers/thermal/sunxi-temperature.c?h=a83t-3.4-bsp-tbs-a711#n1139 H3 lists the same recommended ambient temperature range as A83T. -20 to 70 °C. regards, o. > ChenYu > > > Signed-off-by: Ondrej Jirman -- 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/20200223101647.wqhya3uqvgmsvj32%40core.my.home.
[linux-sunxi] Re: [PATCH] ARM: dts: sun8i-a83t: Add thermal trip points/cooling maps
Hello, On Sun, Feb 23, 2020 at 11:29:07AM +0800, Chen-Yu Tsai wrote: > Hi, > > On Sun, Feb 23, 2020 at 5:40 AM Ondrej Jirman wrote: > > > > This enables passive cooling by down-regulating CPU voltage > > and frequency. > > Please state for the record how the trip points were derived. Were they from > the BSP? Or the user manual? The values are taken from the BSP for A83T: https://megous.com/git/linux/tree/drivers/thermal/sunxi-temperature.c?h=a83t-3.4-bsp-tbs-a711#n747 The datasheet only mentions recommended Ta (ambient operating temperature) range -20 to +70°C. So die voltages will be larger than that. I guess that roughly matches the BSP values. regards, o. > ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200223101050.lqe5uegpmoyqvna6%40core.my.home.
Re: [linux-sunxi] [PATCH 1/4] ARM: dts: sun8i-a83t-tbs-a711: OOB WiFi interrupt doesn't work
On Sun, Feb 23, 2020 at 12:03:46PM +0800, Chen-Yu Tsai wrote:
> On Sun, Feb 23, 2020 at 11:26 AM Chen-Yu Tsai wrote:
> >
> > Hi,
> >
> >
> > On Sun, Feb 23, 2020 at 6:32 AM Ondrej Jirman wrote:
> > >
> > > It just causes a constant rate of 5000 interrupts per second for both
> > > GPIO and MMC, even if nothing is happening. Rely on in-band interrupts
> > > instead.
> > >
> > > Fixes: 0e23372080def7bb ("arm: dts: sun8i: Add the TBS A711 tablet
> > > devicetree")
> > > Signed-off-by: Ondrej Jirman
> >
> > What WiFi chip/module does this use? It might be worth asking Broadcom
> > people to help with this and fix the driver.
>
> Based on the comments in the device tree file, it uses an AP6210, which
> is a BCM43362 inside for SDIO-based WiFi. There is a recent fix in 5.6-rc1
> for this,
>
> 8c8e60fb86a9 brcmfmac: sdio: Fix OOB interrupt initialization on brcm43362
>
> which seems to fix things for me. Could you try it on your end?
Interesting, thanks for finding out! I'll test it.
I think it will work, since my tablet started having overheating issue recently,
and I tracked it down to this.
regards,
o.
> ChenYu
>
>
> > ChenYu
> >
> > > ---
> > > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 3 ---
> > > 1 file changed, 3 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > index 2fd31a0a0b344..ee5ce3556b2ad 100644
> > > --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > > @@ -214,9 +214,6 @@ &mmc1 {
> > > brcmf: wifi@1 {
> > > reg = <1>;
> > > compatible = "brcm,bcm4329-fmac";
> > > - interrupt-parent = <&r_pio>;
> > > - interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 WL_WAKE_UP
> > > */
> > > - interrupt-names = "host-wake";
> > > };
> > > };
> > >
> > > --
> > > 2.25.1
> > >
> > > --
> > > 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/2020023154.221632-2-megous%40megous.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/20200223100225.6e6n65mc3mj365wy%40core.my.home.
Re: [linux-sunxi] [PATCH 2/4] ARM: dts: sun8i-a83t-tbs-a711: HM5065 doesn't like such a high voltage
Hello,
On Sun, Feb 23, 2020 at 11:39:17AM +0800, Chen-Yu Tsai wrote:
> On Sun, Feb 23, 2020 at 6:32 AM Ondrej Jirman wrote:
> >
> > Lowering the voltage solves the quick image degradation over time
> > (minutes), that was probably caused by overheating.
> >
> > Signed-off-by: Ondrej Jirman
>
> Makes sense. A lot of camera sensors run their digital parts off 1.8V.
> This one is no different.
>
> Acked-by: Chen-Yu Tsai
>
> The whole CSI stuff isn't enabled in the device tree yet though, and
> there are a lot of regulators with CSI in their names. Will this get
> worked on?
Yes, I'm preparing support for both cameras in this branch:
https://megous.com/git/linux/log/?h=cam-5.6
Both already work quite well. I'm just sending some fixes early.
Both cameras work best at 1.8V for the digital part.
regards,
o.
> ChenYu
>
> > ---
> > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > index ee5ce3556b2ad..ae1fd2ee3bcce 100644
> > --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > @@ -371,8 +371,8 @@ ®_dldo2 {
> > };
> >
> > ®_dldo3 {
> > - regulator-min-microvolt = <280>;
> > - regulator-max-microvolt = <280>;
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > regulator-name = "vdd-csi";
> > };
> >
> > --
> > 2.25.1
> >
> > --
> > 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/2020023154.221632-3-megous%40megous.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/20200223095736.5c3dr66734kv3ypg%40core.my.home.
[linux-sunxi] Re: [PATCH] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads
Hi,
On Thu, Feb 20, 2020 at 06:32:13PM +0100, Maxime Ripard wrote:
> On Wed, Feb 19, 2020 at 02:09:50AM +0100, Ondrej Jirman wrote:
> > When doing a 16-bit read that returns data in the MSB byte, the
> > RSB_DATA register will keep the MSB byte unchanged when doing
> > the following 8-bit read. sunxi_rsb_read() will then return
> > a result that contains high byte from 16-bit read mixed with
> > the 8-bit result.
> >
> > The consequence is that after this happens the PMIC's regmap will
> > look like this: (0x33 is the high byte from the 16-bit read)
> >
> > % cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
> > 00: 33
> > 01: 33
> > 02: 33
> > 03: 33
> > 04: 33
> > 05: 33
> > 06: 33
> > 07: 33
> > 08: 33
> > 09: 33
> > 0a: 33
> > 0b: 33
> > 0c: 33
> > 0d: 33
> > 0e: 33
> > [snip]
> >
> > Fix this by masking the result of the read with the correct mask
> > based on the size of the read. There are no 16-bit users in the
> > mainline kernel, so this doesn't need to get into the stable tree.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/bus/sunxi-rsb.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
> > index b8043b58568ac..8ab6a3865f569 100644
> > --- a/drivers/bus/sunxi-rsb.c
> > +++ b/drivers/bus/sunxi-rsb.c
> > @@ -316,6 +316,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8
> > rtaddr, u8 addr,
> > {
> > u32 cmd;
> > int ret;
> > + u32 mask;
> >
> > if (!buf)
> > return -EINVAL;
> > @@ -323,12 +324,15 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8
> > rtaddr, u8 addr,
> > switch (len) {
> > case 1:
> > cmd = RSB_CMD_RD8;
> > + mask = 0xffu;
> > break;
> > case 2:
> > cmd = RSB_CMD_RD16;
> > + mask = 0xu;
> > break;
> > case 4:
> > cmd = RSB_CMD_RD32;
> > + mask = 0xu;
> > break;
> > default:
> > dev_err(rsb->dev, "Invalid access width: %zd\n", len);
> > @@ -345,7 +349,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8
> > rtaddr, u8 addr,
> > if (ret)
> > goto unlock;
> >
> > - *buf = readl(rsb->regs + RSB_DATA);
> > + *buf = readl(rsb->regs + RSB_DATA) & mask;
>
> Thanks for debugging this and the extensive commit log.
>
> I guess it would be cleaner to just use GENMASK(len * 8, 0) here?
GENMASK most probably fails with value (32,0) I think.
#define GENMASK(h, l) \
(((~UL(0)) - (UL(1) << (l)) + 1) & \
(~UL(0) >> (BITS_PER_LONG - 1 - (h
would give ~0 >> -1
regards,
o.
> Maxime
--
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/20200220174319.k2icqoxlubu5o2fu%40core.my.home.
[linux-sunxi] Re: [PATCH] bus: sunxi-rsb: Return correct data when mixing 16-bit and 8-bit reads
On Wed, Feb 19, 2020 at 10:49:18AM +0800, Chen-Yu Tsai wrote:
> On Wed, Feb 19, 2020 at 9:10 AM Ondrej Jirman wrote:
> >
> > When doing a 16-bit read that returns data in the MSB byte, the
> > RSB_DATA register will keep the MSB byte unchanged when doing
> > the following 8-bit read. sunxi_rsb_read() will then return
> > a result that contains high byte from 16-bit read mixed with
> > the 8-bit result.
> >
> > The consequence is that after this happens the PMIC's regmap will
> > look like this: (0x33 is the high byte from the 16-bit read)
> >
> > % cat /sys/kernel/debug/regmap/sunxi-rsb-3a3/registers
> > 00: 33
> > 01: 33
> > 02: 33
> > 03: 33
> > 04: 33
> > 05: 33
> > 06: 33
> > 07: 33
> > 08: 33
> > 09: 33
> > 0a: 33
> > 0b: 33
> > 0c: 33
> > 0d: 33
> > 0e: 33
> > [snip]
> >
> > Fix this by masking the result of the read with the correct mask
> > based on the size of the read. There are no 16-bit users in the
> > mainline kernel, so this doesn't need to get into the stable tree.
> >
> > Signed-off-by: Ondrej Jirman
>
> Acked-by: Chen-Yu Tsai
>
> for the fix, however it's not entirely clear to me how the MSB 0x33
> value got into the regmap. Looks like I expected the regmap core to
> handle any overflows, or didn't expect the lingering MSB from 16-bit
> reads, as I didn't have any 16-bit register devices back when I wrote
> this.
Now I feel like I masked some other bug. Though explanation may be quite simple.
For example when AXP core does regmap_read on some values for showing charging
current or battery voltage, because regmap_read works with unsigned int, it
will simply get a number that's too big. And that was the major symptom
I observed. I got readings from sysfs that my tablet is consuming 600A or 200A,
etc. And this value was jumping around based on AC100 activity (as the MSB
byte got changed).
In other places where the driver does regmap_update_bits, I think nothing bad
happened. The write after the read would simply discard the MSB byte.
And for the debugfs/regmap/*/registers, those are printed such:
https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap-debugfs.c#L256
snprintf(buf + buf_pos, count - buf_pos,
"%.*x", map->debugfs_val_len, val);
This doesn't truncate values, so the larger number gets printed to (for
example):
33fe
But regmap debugfs code truncates this by cutting off the formatted string to
this length:
https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap-debugfs.c#L189
So in the end, only:
00: 33
remains, instead of the correct value of:
00: fe
So in the case of debugfs this is just a cosmetic/formatting issue, that didn't
affect anything else.
I think regmap_bus->reg_read API simply expects the returned value to not exceed
the sensible range.
regards,
o.
> ChenYu
>
>
> > ---
> > drivers/bus/sunxi-rsb.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
> > index b8043b58568ac..8ab6a3865f569 100644
> > --- a/drivers/bus/sunxi-rsb.c
> > +++ b/drivers/bus/sunxi-rsb.c
> > @@ -316,6 +316,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8
> > rtaddr, u8 addr,
> > {
> > u32 cmd;
> > int ret;
> > + u32 mask;
> >
> > if (!buf)
> > return -EINVAL;
> > @@ -323,12 +324,15 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8
> > rtaddr, u8 addr,
> > switch (len) {
> > case 1:
> > cmd = RSB_CMD_RD8;
> > + mask = 0xffu;
> > break;
> > case 2:
> > cmd = RSB_CMD_RD16;
> > + mask = 0xu;
> > break;
> > case 4:
> > cmd = RSB_CMD_RD32;
> > + mask = 0xu;
> > break;
> > default:
> > dev_err(rsb->dev, "Invalid access width: %zd\n", len);
> > @@ -345,7 +349,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8
> > rtaddr, u8 addr,
> > if (ret)
> > goto unlock;
> >
> > - *buf = readl(rsb->regs + RSB_DATA);
> > + *buf = readl(rsb->regs + RSB_DATA) & mask;
> >
> > unlock:
> > mutex_unlock(&rsb->lock);
> > --
> > 2.25.1
> >
--
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/20200219121424.dfvrwfcavupmwbvw%40core.my.home.
Re: [linux-sunxi] [PATCH v2] arm64: dts: allwinner: h6: orangepi-3: Add eMMC node
Hi,
On Mon, Feb 10, 2020 at 06:40:07PM +0100, Jernej Skrabec wrote:
> OrangePi 3 can optionally have 8 GiB eMMC (soldered on board). Because
> those pins are dedicated to eMMC exclusively, node can be added for both
> variants (with and without eMMC). Kernel will then scan bus for presence
> of eMMC and act accordingly.
Tested-by: Ondrej Jirman (on a variant without eMMC)
It didn't magically add extra 8GiB of storage, but it didn't break anything
either. :)
regards,
o.
> Signed-off-by: Jernej Skrabec
> ---
> Changes since v1:
> - don't make separate DT just for -emmc variant - add node to existing
> orangepi 3 DT
>
> arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index c311eee52a35..1e0abd9d047f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -144,6 +144,15 @@ brcm: sdio-wifi@1 {
> };
> };
>
> +&mmc2 {
> + vmmc-supply = <®_cldo1>;
> + vqmmc-supply = <®_bldo2>;
> + cap-mmc-hw-reset;
> + non-removable;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
> &ohci0 {
> status = "okay";
> };
> --
> 2.25.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.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/20200210174007.118575-1-jernej.skrabec%40siol.net.
--
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/20200212122511.5gr6m4ppmytq4ajj%40core.my.home.
Re: [linux-sunxi] [PATCH] media: sun6i-csi: Fix incorrect HSYNC/VSYNC/PCLK polarity configuration
On Thu, Nov 28, 2019 at 11:26:24AM +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 28, 2019 at 11:06 AM Ondřej Jirman wrote:
> >
> > Hi,
> >
> > On Thu, Nov 28, 2019 at 10:26:08AM +0800, Yong wrote:
> > > Hi Ondrej,
> > >
> > > This has been discussed.
> > > And Maxime sent a patch for this:
> > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg127149.html
> >
> > Thanks for pointing to the previous patch. But that patch doesn't make any
> > sense, and breaks things for me, and doesn't even match BSP code, which
> > has no such reversal, and works fine with about 30 cam drivers.
> >
> > Also how do you explain my findings?
> >
> > My camera is sending correct signals, verified by looking at them actually
> > (see
> > below), and CSI is not receiving the image. I have to flip HSYNC/VSYNC to be
> > oposite of that what CSI driver expects and I get a noisy image and if I fix
> > PCLK polarity too, the noise goes away, which means now I'm also sampling
> > when
> > the data are stable and not when they're changing.
> >
> > Here: (output from my cam, that I configured to have VSYNC ACTIVE LOW, HSYNC
> > ACTIVE LOW) And the signal is clearly that, as you can see yourself:
> >
> > https://megous.com/dl/tmp/98df81b7ed0126ec.png
>
> From the looks of things you have active-high VSYNC with active-low HREF.
> HREF is not the same as HSYNC, in fact quite the opposite. V/H SYNC are
> pulses, active only when there should be no data and the line/frame switch
> happens, while V/H REF are held active when there is data. I personally
> find these terms very confusing. :(
>
> Now the timing diagrams in the Allwinner manuals would suggest that when
> they are talking about H/V SYNC, they are actually referring to H/V REF.
> The HSYNC line is high/active when there is valid data, and the VSYNC line
> is high/active for the duration of the frame.
>
> I think both sides need to be checked that they are using the correct
> polarity, and maybe also have the media maintainers clarify how the
> polarity should be interpreted when the hardware uses H/V ref instead
> of H/V sync.
Oh my, so it's just a terminology issue? :)
This probably should be docummented somewhere. I just thought xSYNC_ACTIVE_HIGH
meant the respective signals are supposed to be HIGH during active phase of data
transmission: that is VSYNC HIGH during entire frame, and HSYNC high during row.
DT bindings documentation doesn't help much either.
And obviously manufacturers are confused too.
https://megous.com/dl/tmp/fae07dfb4897bbb3.png
HSYNC/VSYNC "low valid" produces what you see on the previous signal capture
I posted. ;)
regards,
o.
>
> ChenYu
>
> > The above signals are received with CSI driver configured with
> > V4L2_MBUS_VSYNC_ACTIVE_HIGH V4L2_MBUS_HSYNC_ACTIVE_HIGH. So CSI driver is
> > clearly wrong.
> >
> > I think this is pretty clear the driver is buggy. At least for A83T SoC.
> >
> > I'm not sure what Maxime found out, but he should probably re-check his
> > findings. Maxime, can you comment on this?
> >
> > regards,
> > o.
> >
> > > On Thu, 28 Nov 2019 03:02:59 +0100
> > > Ondrej Jirman wrote:
> > >
> > > > This was discovered by writing a new camera driver and wondering, why
> > > > hsync/vsync polarity setting behaves in reverse to what would be
> > > > expected. Verified by looking at the actual signals and the SoC
> > > > user manual.
> > > >
> > > > Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> > > > Signed-off-by: Ondrej Jirman
> > > > ---
> > > > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > index f17e5550602d..98bbcca59a90 100644
> > > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > @@ -417,12 +417,12 @@ static void sun6i_csi_setup_bus(struct
> > > > sun6i_csi_dev *sdev)
> > > > if (flags & V4L2_MBUS_FIELD_EVEN_LOW)
> > > > cfg |= CSI_IF_CFG_FIELD_POSITIVE;
> > > >
> > > > - if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> > > > + if (flags & V4L2_MBUS_VS
Re: [linux-sunxi] [PATCH] media: sun6i-csi: Fix incorrect HSYNC/VSYNC/PCLK polarity configuration
Hi,
On Thu, Nov 28, 2019 at 10:26:08AM +0800, Yong wrote:
> Hi Ondrej,
>
> This has been discussed.
> And Maxime sent a patch for this:
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg127149.html
Thanks for pointing to the previous patch. But that patch doesn't make any
sense, and breaks things for me, and doesn't even match BSP code, which
has no such reversal, and works fine with about 30 cam drivers.
Also how do you explain my findings?
My camera is sending correct signals, verified by looking at them actually (see
below), and CSI is not receiving the image. I have to flip HSYNC/VSYNC to be
oposite of that what CSI driver expects and I get a noisy image and if I fix
PCLK polarity too, the noise goes away, which means now I'm also sampling when
the data are stable and not when they're changing.
Here: (output from my cam, that I configured to have VSYNC ACTIVE LOW, HSYNC
ACTIVE LOW) And the signal is clearly that, as you can see yourself:
https://megous.com/dl/tmp/98df81b7ed0126ec.png
The above signals are received with CSI driver configured with
V4L2_MBUS_VSYNC_ACTIVE_HIGH V4L2_MBUS_HSYNC_ACTIVE_HIGH. So CSI driver is
clearly wrong.
I think this is pretty clear the driver is buggy. At least for A83T SoC.
I'm not sure what Maxime found out, but he should probably re-check his
findings. Maxime, can you comment on this?
regards,
o.
> On Thu, 28 Nov 2019 03:02:59 +0100
> Ondrej Jirman wrote:
>
> > This was discovered by writing a new camera driver and wondering, why
> > hsync/vsync polarity setting behaves in reverse to what would be
> > expected. Verified by looking at the actual signals and the SoC
> > user manual.
> >
> > Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > index f17e5550602d..98bbcca59a90 100644
> > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > @@ -417,12 +417,12 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev
> > *sdev)
> > if (flags & V4L2_MBUS_FIELD_EVEN_LOW)
> > cfg |= CSI_IF_CFG_FIELD_POSITIVE;
> >
> > - if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> > + if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> > cfg |= CSI_IF_CFG_VREF_POL_POSITIVE;
> > - if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> > + if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> > cfg |= CSI_IF_CFG_HREF_POL_POSITIVE;
> >
> > - if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> > + if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> > cfg |= CSI_IF_CFG_CLK_POL_FALLING_EDGE;
> > break;
> > case V4L2_MBUS_BT656:
> > --
> > 2.24.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.
> > To view this discussion on the web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20191128020259.1338188-1-megous%40megous.com.
>
>
> Thanks,
> Yong
--
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/20191128030653.5fhcolvib6tzf4zc%40core.my.home.
[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse
On Fri, Nov 08, 2019 at 12:41:39PM +0100, megous hlavni wrote:
> On Fri, Nov 08, 2019 at 07:29:21PM +0800, Icenowy Zheng wrote:
> >
> >
> > 于 2019年11月8日 GMT+08:00 上午5:45:14, "Ondřej Jirman" 写到:
> > >Hello Rikard,
> > >
> > >On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote:
> > >> Arguments are supposed to be ordered high then low.
> > >>
> > >> Signed-off-by: Rikard Falkeborn
> > >> ---
> > >> Spotted while trying to add compile time checks of GENMASK arguments.
> > >> Patch has only been compile tested.
> > >
> > >thank you!
> > >
> > >Tested-by: Ondrej Jirman
> >
> > Does it affect or fix the performance?
>
> See here:
> https://forum.armbian.com/topic/10131-orange-pi-lite2-usb3-now-working/?do=findComment&comment=88904
>
> Quote:
>
> > It may or may not help. On Opi3 I see no change, probably because HUB is
> > really close to the SoC, but on boards without a HUB, SoC's USB3 phy will
> > have to drive the signal over the longer cable and this patch might benefit
> > those boards.
>
> Maybe someone with boards without PHY will test it more.
Eh, on boards without a USB3 HUB.
> regards,
> o.
>
> > >
> > >regards,
> > > o.
> > >
> > >> drivers/phy/allwinner/phy-sun50i-usb3.c | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >b/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >> index 1169f3e83a6f..b1c04f71a31d 100644
> > >> --- a/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> > >> @@ -49,7 +49,7 @@
> > >> #define SUNXI_LOS_BIAS(n) ((n) << 3)
> > >> #define SUNXI_LOS_BIAS_MASK GENMASK(5, 3)
> > >> #define SUNXI_TXVBOOSTLVL(n)((n) << 0)
> > >> -#define SUNXI_TXVBOOSTLVL_MASK GENMASK(0, 2)
> > >> +#define SUNXI_TXVBOOSTLVL_MASK GENMASK(2, 0)
> > >>
> > >> struct sun50i_usb3_phy {
> > >> struct phy *phy;
> > >> --
> > >> 2.24.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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20191108114301.v3663hs5ftjsoec3%40core.my.home.
[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse
On Fri, Nov 08, 2019 at 07:29:21PM +0800, Icenowy Zheng wrote:
>
>
> 于 2019年11月8日 GMT+08:00 上午5:45:14, "Ondřej Jirman" 写到:
> >Hello Rikard,
> >
> >On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote:
> >> Arguments are supposed to be ordered high then low.
> >>
> >> Signed-off-by: Rikard Falkeborn
> >> ---
> >> Spotted while trying to add compile time checks of GENMASK arguments.
> >> Patch has only been compile tested.
> >
> >thank you!
> >
> >Tested-by: Ondrej Jirman
>
> Does it affect or fix the performance?
See here:
https://forum.armbian.com/topic/10131-orange-pi-lite2-usb3-now-working/?do=findComment&comment=88904
Quote:
> It may or may not help. On Opi3 I see no change, probably because HUB is
> really close to the SoC, but on boards without a HUB, SoC's USB3 phy will
> have to drive the signal over the longer cable and this patch might benefit
> those boards.
Maybe someone with boards without PHY will test it more.
regards,
o.
> >
> >regards,
> > o.
> >
> >> drivers/phy/allwinner/phy-sun50i-usb3.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c
> >b/drivers/phy/allwinner/phy-sun50i-usb3.c
> >> index 1169f3e83a6f..b1c04f71a31d 100644
> >> --- a/drivers/phy/allwinner/phy-sun50i-usb3.c
> >> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> >> @@ -49,7 +49,7 @@
> >> #define SUNXI_LOS_BIAS(n) ((n) << 3)
> >> #define SUNXI_LOS_BIAS_MASK GENMASK(5, 3)
> >> #define SUNXI_TXVBOOSTLVL(n) ((n) << 0)
> >> -#define SUNXI_TXVBOOSTLVL_MASKGENMASK(0, 2)
> >> +#define SUNXI_TXVBOOSTLVL_MASKGENMASK(2, 0)
> >>
> >> struct sun50i_usb3_phy {
> >>struct phy *phy;
> >> --
> >> 2.24.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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20191108114138.snghk5n7kwuw7zz3%40core.my.home.
[linux-sunxi] Re: [PATCH] phy: allwinner: Fix GENMASK misuse
Hello Rikard,
On Thu, Nov 07, 2019 at 09:46:45PM +0100, Rikard Falkeborn wrote:
> Arguments are supposed to be ordered high then low.
>
> Signed-off-by: Rikard Falkeborn
> ---
> Spotted while trying to add compile time checks of GENMASK arguments.
> Patch has only been compile tested.
thank you!
Tested-by: Ondrej Jirman
regards,
o.
> drivers/phy/allwinner/phy-sun50i-usb3.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c
> b/drivers/phy/allwinner/phy-sun50i-usb3.c
> index 1169f3e83a6f..b1c04f71a31d 100644
> --- a/drivers/phy/allwinner/phy-sun50i-usb3.c
> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> @@ -49,7 +49,7 @@
> #define SUNXI_LOS_BIAS(n)((n) << 3)
> #define SUNXI_LOS_BIAS_MASK GENMASK(5, 3)
> #define SUNXI_TXVBOOSTLVL(n) ((n) << 0)
> -#define SUNXI_TXVBOOSTLVL_MASK GENMASK(0, 2)
> +#define SUNXI_TXVBOOSTLVL_MASK GENMASK(2, 0)
>
> struct sun50i_usb3_phy {
> struct phy *phy;
> --
> 2.24.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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20191107214514.kcz42mcehyrrif4o%40core.my.home.
[linux-sunxi] Re: [PATCH 4/4] arm64: dts: allwinner: orange-pi-3: Enable USB 3.0 host support
Hello Maxime, On Mon, Oct 21, 2019 at 01:09:46PM +0200, Maxime Ripard wrote: > On Sun, Oct 20, 2019 at 03:42:29PM +0200, meg...@megous.com wrote: > > From: Ondrej Jirman > > > > Enable Allwinner's USB 3.0 phy and the host controller. Orange Pi 3 > > board has GL3510 USB 3.0 4-port hub connected to the SoC's USB 3.0 > > port. All four ports are exposed via USB3-A connectors. VBUS is > > always on, since it's powered directly from DCIN (VCC-5V) and > > not switchable. > > > > Signed-off-by: Ondrej Jirman > > Those last two patches are fine with me, I'll merge them once the phy > driver will be merged. PHY driver has been merged. You can now pull these patches too, when you like. See here: https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git/log/?h=next Thank you, o. > Maxime -- 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/20191104121648.jxgs2eoj6loh2as2%40core.my.home.
[linux-sunxi] Re: [PATCH] cpufreq: sun50i: Fix CPU speed bin detection
On Fri, Nov 01, 2019 at 04:07:01PM +0100, Maxime Ripard wrote:
> On Thu, Oct 31, 2019 at 07:13:58PM +0100, Ondrej Jirman wrote:
> > I have failures to boot on Orange Pi 3, because this driver determined
> > that my SoC is from the normal bin, but my SoC only works reliably with
> > the OPP values for the slowest bin.
> >
> > Looking at BSP code, I found that efuse values have following meanings
> > on H6:
> >
> > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > - 0b001 slowest bin
> > - 0b011 normal bin
> > - 0b111 fastest bin
> >
> > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > of other bins to match vendor code.
> >
> > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > Signed-off-by: Ondrej Jirman
>
> Acked-by: Maxime Ripard
Self-NACK :) Please don't merge.
Please see the other e-mail for why.
thank you and regards,
o.
> Out of curiosity, which OPP table is being used? I guess it's one of
> the dozens of patches sitting there...
>
> Maxime
--
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/20191101161537.xqywdnwlrxgjf7hf%40core.my.home.
Re: [linux-sunxi] [PATCH] cpufreq: sun50i: Fix CPU speed bin detection
Hi,
On Thu, Oct 31, 2019 at 08:12:57PM +0100, megous hlavni wrote:
> Hi,
>
> On Thu, Oct 31, 2019 at 07:55:43PM +0100, Clément Péron wrote:
> > Hi Ondrej,
> >
> > On Thu, 31 Oct 2019 at 19:14, Ondrej Jirman wrote:
> > >
> > > I have failures to boot on Orange Pi 3, because this driver determined
> > > that my SoC is from the normal bin, but my SoC only works reliably with
> > > the OPP values for the slowest bin.
> > >
> > > Looking at BSP code, I found that efuse values have following meanings
> > > on H6:
> > >
> > > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > > - 0b001 slowest bin
> > > - 0b011 normal bin
> > > - 0b111 fastest bin
> >
> > Maybe have some defines will be more readable no ?
> > https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n213
>
> Hmm, Alwwinner is really funny. Unused macros that just confuse things.
>
> #if defined(CONFIG_ARCH_SUN50IW6)
> #define TYPE_SB (0b001)
> #define TYPE_NB (0b010)
> #define TYPE_FB (0b011)
So this table is likely used on H6, from my research I was able to find
no owners of H6 with efuse value of 0b111 and one owner with efuse value
of 0b010, and one with 0b011.
So the bins map directly to decimal numbers efuse=1 (slow bin),
efuse=2 (normal bin), efuse=3 (fast bin).
So it looks like vendor code is wrong and works accidentally, due to
fast bin being interpretted as normal bin, and normal bin being interpretted
as having a wrong efuse value, which is then interpretted alter as normal bin.
https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/page/24/#comments
https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/page/25/#comments
This will still need to be verified, by respective owners using the optimized
OPP tables for their supposed SoC bins successfully, but meanwhile I think
we should base the efuse->speed grade mapping based on values observed in the
wild. That seems most prudent at the moment.
I'll send v2 with speed grade selection matching these observations, so
please don't merge this yet.
regards,
o.
> #else
> #define TYPE_SB (0b001)
> #define TYPE_NB (0b011)
> #define TYPE_FB (0b111)
> #endif
>
> So for H6 they define special bin values and actually use different ones
> in code. Fun.
>
> I've sent out some testing program to Armbian forums, so hopefully, we'll
> collect some real efuse_values from real SoCs, to see what's really being
> used in the wild. If we see value 0b010, the BSP code is probably just
> wrong.
>
> Interestingly, TYPE_NB 0b010 would be interpreted as normal bin even with
> the current BSP code, and TYPE_FB would be misdetected as TYPE_NB.
>
> > #define SUN50I_NVEM_INVALID_CPU_OPP (0b000)
> > #define SUN50I_NVEM_LOW_CPU_OPP (0b001)
> > #define SUN50I_NVEM_NORMAL_CPU_OPP (0b011)
> > #define SUN50I_NVEM_HIGH_CPU_OPP (0b111)
>
> I'd rather not describe meanings just yet, until we get some real-world
> data from H6 owners.
>
> https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/?do=findComment&comment=88439
>
> regards,
> o.
>
> > Regards,
> > Clément
> >
> > >
> > > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > > of other bins to match vendor code.
> > >
> > > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > > Signed-off-by: Ondrej Jirman
> > > ---
> > >
> > > See
> > > https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n484
> > > and
> > > https://megous.com/git/linux/tree/drivers/cpufreq/sunxi-cpufreq.c?h=h6-4.9-bsp#n428
> > > (1 is substracted from soc_bin number here!)
> > >
> > > drivers/cpufreq/sun50i-cpufreq-nvmem.c | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > index df35ef3ef567..41dad03e245c 100644
> > > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > > @@ -71,9 +71,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
> > > efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> > > switch (efuse_value) {
> > > case 0b0001:
> > > - *versions = 1;
> > > + *versions = 0;
> > > break;
> > > case 0b0011:
> > > + *versions = 1;
> > > + break;
> > > + case 0b0111:
> > > *versions = 2;
> > > break;
> > > default:
> > > --
> > > 2.23.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.
> > > To view this discussion on the web, visit
> > > https://groups.google.com/d/msgid/linux-sunxi/20191031181359.282617-1-megous%40megous.com.
--
You received this message because you are subscri
[linux-sunxi] Re: [PATCH] cpufreq: sun50i: Fix CPU speed bin detection
On Fri, Nov 01, 2019 at 04:07:01PM +0100, Maxime Ripard wrote:
> On Thu, Oct 31, 2019 at 07:13:58PM +0100, Ondrej Jirman wrote:
> > I have failures to boot on Orange Pi 3, because this driver determined
> > that my SoC is from the normal bin, but my SoC only works reliably with
> > the OPP values for the slowest bin.
> >
> > Looking at BSP code, I found that efuse values have following meanings
> > on H6:
> >
> > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > - 0b001 slowest bin
> > - 0b011 normal bin
> > - 0b111 fastest bin
> >
> > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > of other bins to match vendor code.
> >
> > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > Signed-off-by: Ondrej Jirman
>
> Acked-by: Maxime Ripard
>
> Out of curiosity, which OPP table is being used? I guess it's one of
> the dozens of patches sitting there...
I'm using one from Orange Pi 3's fex file from Xunlong:
https://github.com/orangepi-xunlong/OrangePiH6_external/blob/master/sys_config/OrangePiH6_3_sys_config.fex
https://megous.com/git/linux/commit/?h=ths-5.4&id=7b409e83b4ac70f3435886da6a26cecf9af77213
This one doesn't really differentiate between normal/fast bins.
There's also another one in the Allwinner DTS files:
https://github.com/orangepi-xunlong/OrangePiH6_Linux4_9/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi#L349
which seems to be the one used by Yangtao Li in the dt-bindings
docummentation.
regards,
o.
> Maxime
--
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/20191101160134.n7ay2jl7j5vzofo2%40core.my.home.
Re: [linux-sunxi] [PATCH] cpufreq: sun50i: Fix CPU speed bin detection
Hi,
On Thu, Oct 31, 2019 at 07:55:43PM +0100, Clément Péron wrote:
> Hi Ondrej,
>
> On Thu, 31 Oct 2019 at 19:14, Ondrej Jirman wrote:
> >
> > I have failures to boot on Orange Pi 3, because this driver determined
> > that my SoC is from the normal bin, but my SoC only works reliably with
> > the OPP values for the slowest bin.
> >
> > Looking at BSP code, I found that efuse values have following meanings
> > on H6:
> >
> > - 0b000 invalid (interpreted in vendor's BSP as normal bin)
> > - 0b001 slowest bin
> > - 0b011 normal bin
> > - 0b111 fastest bin
>
> Maybe have some defines will be more readable no ?
> https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n213
Hmm, Alwwinner is really funny. Unused macros that just confuse things.
#if defined(CONFIG_ARCH_SUN50IW6)
#define TYPE_SB (0b001)
#define TYPE_NB (0b010)
#define TYPE_FB (0b011)
#else
#define TYPE_SB (0b001)
#define TYPE_NB (0b011)
#define TYPE_FB (0b111)
#endif
So for H6 they define special bin values and actually use different ones
in code. Fun.
I've sent out some testing program to Armbian forums, so hopefully, we'll
collect some real efuse_values from real SoCs, to see what's really being
used in the wild. If we see value 0b010, the BSP code is probably just
wrong.
Interestingly, TYPE_NB 0b010 would be interpreted as normal bin even with
the current BSP code, and TYPE_FB would be misdetected as TYPE_NB.
> #define SUN50I_NVEM_INVALID_CPU_OPP (0b000)
> #define SUN50I_NVEM_LOW_CPU_OPP (0b001)
> #define SUN50I_NVEM_NORMAL_CPU_OPP (0b011)
> #define SUN50I_NVEM_HIGH_CPU_OPP (0b111)
I'd rather not describe meanings just yet, until we get some real-world
data from H6 owners.
https://forum.armbian.com/topic/9368-orangepi-3-h6-allwiner-chip/?do=findComment&comment=88439
regards,
o.
> Regards,
> Clément
>
> >
> > Let's play it safe and interpret 0 as the slowest bin, but fix detection
> > of other bins to match vendor code.
> >
> > Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver")
> > Signed-off-by: Ondrej Jirman
> > ---
> >
> > See
> > https://megous.com/git/linux/tree/drivers/soc/sunxi/sunxi-sid.c?h=h6-4.9-bsp#n484
> > and
> > https://megous.com/git/linux/tree/drivers/cpufreq/sunxi-cpufreq.c?h=h6-4.9-bsp#n428
> > (1 is substracted from soc_bin number here!)
> >
> > drivers/cpufreq/sun50i-cpufreq-nvmem.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > index df35ef3ef567..41dad03e245c 100644
> > --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
> > @@ -71,9 +71,12 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
> > efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
> > switch (efuse_value) {
> > case 0b0001:
> > - *versions = 1;
> > + *versions = 0;
> > break;
> > case 0b0011:
> > + *versions = 1;
> > + break;
> > + case 0b0111:
> > *versions = 2;
> > break;
> > default:
> > --
> > 2.23.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.
> > To view this discussion on the web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20191031181359.282617-1-megous%40megous.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/20191031191257.j7bpxx5xyot2ay2i%40core.my.home.
Re: [linux-sunxi] Re: [PATCH] input: sun4i-lradc-keys: Add wakup support
On Mon, Oct 28, 2019 at 09:18:04PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 29, 2019 at 02:45:59AM +0100, Ondřej Jirman wrote:
> > On Mon, Oct 28, 2019 at 05:12:50PM -0700, Dmitry Torokhov wrote:
> > > On Tue, Oct 29, 2019 at 12:56:26AM +0100, Ondřej Jirman wrote:
> > > > On Mon, Oct 28, 2019 at 04:38:28PM -0700, Dmitry Torokhov wrote:
> > > > > > +
> > > > > > + error = dev_pm_set_wake_irq(dev, irq);
> > > > > > + if (error) {
> > > > > > + dev_err(dev, "Could not set wake IRQ\n");
> > > > > > + return error;
> > > > > > + }
> > > > > > +
> > > > >
> > > > > I wonder if we could teach platform driver core to handle this for us.
> > > >
> > > > Not sure, some drivers do enable/disable wake_irq by hand in
> > > > suspend/resume
> > > > callbacks, so it would probably need to be opt-in somehow. I guess
> > > > calling the
> > > > function like this is one way to make it opt-in.
> > > >
> > > > The other way may be by passing a flag somewhere, like to
> > > > request_threaded_irq. Did you have something more concrete in mind?
> > >
> > > I think it is perfectly fine to continue using enable_irq_wake and
> > > disable_irq_wake from the driver while marking irq as being wake irq
> > > form the core.
> >
> > I see, it looks like irq_set_irq_wake will track the calls via wake_depth
> >
> > https://elixir.bootlin.com/linux/latest/source/kernel/irq/manage.c#L714
> >
> > But all irqs are not necessarily wake irqs, no? So it still may need to be
> > opt-in somehow.
>
> I thought we'd do that for IRQ named "wakeirq" or the very first IRQ if
> there is no named IRQ, and when we have the "wakeup-source" property,
> similarly to what we do in I2C bus.
I see. I've looked at drivers using dev_pm_set_wake_irq and
dev_pm_set_dedicated_wake_irq and not many platform drivers would potentially
benefit (~25 out of 2300), of those only some use OF and are platform
drivers, maybe 15-20:
https://elixir.bootlin.com/linux/latest/ident/dev_pm_set_wake_irq
https://elixir.bootlin.com/linux/latest/ident/dev_pm_set_dedicated_wake_irq
I don't think it's worth it.
regards,
o.
> Thanks.
>
> --
> Dmitry
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/20191029124331.7yh5kccsq2syxm47%40core.my.home.
[linux-sunxi] Re: [PATCH 1/3] input: edt-ft5x06: Add support for regulator
Hi Marco,
On Tue, Oct 29, 2019 at 09:55:45AM +0100, Marco Felsch wrote:
> Hi Dmitry,
>
> On 19-10-28 21:12, Dmitry Torokhov wrote:
> > On Tue, Oct 29, 2019 at 01:58:04AM +0100, Ondrej Jirman wrote:
> > > From: Mylčne Josserand
> > >
> > > Add the support for enabling optional regulator that may be used as VCC
> > > source.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > Signed-off-by: Mylčne Josserand
> >
> > Applied, thank you.
>
> What happens with my vdd patches?
Sorry for not noticing your patches, I was only aware of Mylčne's older series.
It looks like you can just skip regulator enable support from your series, and
re-send the deep-sleep mechanism and wakeup source patches only.
I'll test it with my board, and give you a tested-by.
thank you and regards,
o.
> Regards,
> Marco
>
> >
> > > ---
> > > drivers/input/touchscreen/edt-ft5x06.c | 30 ++
> > > 1 file changed, 30 insertions(+)
> > >
> > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c
> > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > index 5525f1fb1526..d61731c0037d 100644
> > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > @@ -28,6 +28,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #define WORK_REGISTER_THRESHOLD 0x00
> > > #define WORK_REGISTER_REPORT_RATE0x08
> > > @@ -88,6 +89,7 @@ struct edt_ft5x06_ts_data {
> > > struct touchscreen_properties prop;
> > > u16 num_x;
> > > u16 num_y;
> > > + struct regulator *vcc;
> > >
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *wake_gpio;
> > > @@ -1036,6 +1038,13 @@ edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data
> > > *tsdata)
> > > }
> > > }
> > >
> > > +static void edt_ft5x06_disable_regulator(void *arg)
> > > +{
> > > + struct edt_ft5x06_ts_data *data = arg;
> > > +
> > > + regulator_disable(data->vcc);
> > > +}
> > > +
> > > static int edt_ft5x06_ts_probe(struct i2c_client *client,
> > >const struct i2c_device_id *id)
> > > {
> > > @@ -1064,6 +1073,27 @@ static int edt_ft5x06_ts_probe(struct i2c_client
> > > *client,
> > >
> > > tsdata->max_support_points = chip_data->max_support_points;
> > >
> > > + tsdata->vcc = devm_regulator_get(&client->dev, "vcc");
> > > + if (IS_ERR(tsdata->vcc)) {
> > > + error = PTR_ERR(tsdata->vcc);
> > > + if (error != -EPROBE_DEFER)
> > > + dev_err(&client->dev,
> > > + "failed to request regulator: %d\n", error);
> > > + return error;
> > > + }
> > > +
> > > + error = regulator_enable(tsdata->vcc);
> > > + if (error < 0) {
> > > + dev_err(&client->dev, "failed to enable vcc: %d\n", error);
> > > + return error;
> > > + }
> > > +
> > > + error = devm_add_action_or_reset(&client->dev,
> > > + edt_ft5x06_disable_regulator,
> > > + tsdata);
> > > + if (error)
> > > + return error;
> > > +
> > > tsdata->reset_gpio = devm_gpiod_get_optional(&client->dev,
> > >"reset", GPIOD_OUT_HIGH);
> > > if (IS_ERR(tsdata->reset_gpio)) {
> > > --
> > > 2.23.0
> > >
> >
> > --
> > Dmitry
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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/20191029112129.t4mxqyybltjbuyhj%40core.my.home.
[linux-sunxi] Re: [PATCH 3/3] arm: dts: sun8i: a83t: a711: Add touchscreen node
Hello Marco,
On Tue, Oct 29, 2019 at 10:08:01AM +0100, Marco Felsch wrote:
> Hi,
>
> On 19-10-29 01:58, Ondrej Jirman wrote:
> > From: Mylčne Josserand
> >
> > Enable a FocalTech EDT-FT5x06 Polytouch touchscreen.
> >
> > Signed-off-by: Ondrej Jirman
> > Signed-off-by: Mylčne Josserand
> > ---
> > arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > index 568b90ece342..19f520252dc5 100644
> > --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
> > @@ -164,6 +164,22 @@
> > status = "okay";
> > };
> >
> > +&i2c0 {
> > + clock-frequency = <40>;
> > + status = "okay";
> > +
> > + touchscreen@38 {
> > + compatible = "edt,edt-ft5x06";
> > + reg = <0x38>;
> > + interrupt-parent = <&r_pio>;
> > + interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>; /* PL7 */
> > + reset-gpios = <&pio 3 5 GPIO_ACTIVE_LOW>; /* PD5 */
> > + vcc-supply = <®_ldo_io0>;
> > + touchscreen-size-x = <1024>;
> > + touchscreen-size-y = <600>;
>
> Do you want this touchscreen as wakeup-src? If so please add the
> property here. I've send patches converting the driver from the default
> behaviour: https://patchwork.kernel.org/cover/11149039/ and all agreed
> to break backward compatibility.
Not at this moment, thank you.
regards,
o.
> Regards,
> Marco
>
> > + };
> > +};
> > +
> > &i2c1 {
> > clock-frequency = <40>;
> > status = "okay";
> > --
> > 2.23.0
> >
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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/20191029111339.7okiyig3tbehn5kj%40core.my.home.
Re: [linux-sunxi] Re: [PATCH] input: sun4i-lradc-keys: Add wakup support
On Mon, Oct 28, 2019 at 05:12:50PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 29, 2019 at 12:56:26AM +0100, Ondřej Jirman wrote:
> > On Mon, Oct 28, 2019 at 04:38:28PM -0700, Dmitry Torokhov wrote:
> > > > +
> > > > + error = dev_pm_set_wake_irq(dev, irq);
> > > > + if (error) {
> > > > + dev_err(dev, "Could not set wake IRQ\n");
> > > > + return error;
> > > > + }
> > > > +
> > >
> > > I wonder if we could teach platform driver core to handle this for us.
> >
> > Not sure, some drivers do enable/disable wake_irq by hand in suspend/resume
> > callbacks, so it would probably need to be opt-in somehow. I guess calling
> > the
> > function like this is one way to make it opt-in.
> >
> > The other way may be by passing a flag somewhere, like to
> > request_threaded_irq. Did you have something more concrete in mind?
>
> I think it is perfectly fine to continue using enable_irq_wake and
> disable_irq_wake from the driver while marking irq as being wake irq
> form the core.
I see, it looks like irq_set_irq_wake will track the calls via wake_depth
https://elixir.bootlin.com/linux/latest/source/kernel/irq/manage.c#L714
But all irqs are not necessarily wake irqs, no? So it still may need to be
opt-in somehow.
Anyway, I'm no PM expert. I started looking at PM code about two weeks ago, and
I really don't feel like I can contribute much to these kinds of decisions with
my current level of understanding, right now.
regards,
o.
> Thanks.
>
> --
> Dmitry
>
> --
> 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/20191029001250.GB57214%40dtor-ws.
--
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/20191029014559.gif3ay7anq24un2i%40core.my.home.
Re: [linux-sunxi] [PATCH] ARM: sunxi: Fix CPU powerdown on A83T
On Tue, Oct 29, 2019 at 09:09:40AM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 29, 2019 at 5:49 AM Ondrej Jirman wrote:
> >
> > PRCM_PWROFF_GATING_REG has CPU0 at bit 4 on A83T. So without this
> > patch, instead of gating the CPU0, the whole cluster was power gated,
> > when shutting down first CPU in the cluster.
> >
> > Fixes: 6961275e72a8c1 ("ARM: sun8i: smp: Add support for A83T")
> > Signed-off-by: Ondrej Jirman
> > Cc: sta...@vger.kernel.org
>
> Acked-by: Chen-Yu Tsai
>
> Though I distinctly remember the BSP had some code dealing with chip
> revisions in which the two bits were reversed. :(
Actually, it's a bit more complicated. There's a special check in BSP
code (grep for SUN8IW6P1_REV_A) that instead of power gating, just
holds the core in reset for that revision.
regards,
o.
--
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/20191029012517.eddekmphtxyslevx%40core.my.home.
[linux-sunxi] Re: [PATCH] input: sun4i-lradc-keys: Add wakup support
Hello Dmitry,
On Mon, Oct 28, 2019 at 04:38:28PM -0700, Dmitry Torokhov wrote:
> Hi Ondrej,
>
> On Mon, Oct 28, 2019 at 11:15:02PM +0100, Ondrej Jirman wrote:
> > Allow the driver to wakeup the system on key press.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/input/keyboard/sun4i-lradc-keys.c | 22 ++
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c
> > b/drivers/input/keyboard/sun4i-lradc-keys.c
> > index 4a796bed48ac..bba679d7b54b 100644
> > --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> > +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> > @@ -22,6 +22,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> >
> > @@ -226,8 +228,7 @@ static int sun4i_lradc_probe(struct platform_device
> > *pdev)
> > {
> > struct sun4i_lradc_data *lradc;
> > struct device *dev = &pdev->dev;
> > - int i;
> > - int error;
> > + int i, error, irq;
> >
> > lradc = devm_kzalloc(dev, sizeof(struct sun4i_lradc_data), GFP_KERNEL);
> > if (!lradc)
> > @@ -272,8 +273,13 @@ static int sun4i_lradc_probe(struct platform_device
> > *pdev)
> > if (IS_ERR(lradc->base))
> > return PTR_ERR(lradc->base);
> >
> > - error = devm_request_irq(dev, platform_get_irq(pdev, 0),
> > -sun4i_lradc_irq, 0,
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(&pdev->dev, "Failed to get IRQ\n");
> > + return irq;
> > + }
> > +
> > + error = devm_request_irq(dev, irq, sun4i_lradc_irq, 0,
> > "sun4i-a10-lradc-keys", lradc);
> > if (error)
> > return error;
> > @@ -282,6 +288,14 @@ static int sun4i_lradc_probe(struct platform_device
> > *pdev)
> > if (error)
> > return error;
> >
> > + device_init_wakeup(dev, true);
>
> I do not think we want to do this unconditionally. Can we maybe key off
> "wakeup-source" device property.
Sure thing.
> > +
> > + error = dev_pm_set_wake_irq(dev, irq);
> > + if (error) {
> > + dev_err(dev, "Could not set wake IRQ\n");
> > + return error;
> > + }
> > +
>
> I wonder if we could teach platform driver core to handle this for us.
Not sure, some drivers do enable/disable wake_irq by hand in suspend/resume
callbacks, so it would probably need to be opt-in somehow. I guess calling the
function like this is one way to make it opt-in.
The other way may be by passing a flag somewhere, like to
request_threaded_irq. Did you have something more concrete in mind?
regards,
o.
> Thanks.
>
> --
> Dmitry
--
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/20191028235626.5afvszxtppsieywi%40core.my.home.
[linux-sunxi] Re: [U-Boot] [PATCH] sunxi: set PIO voltage to hardware-detected value on startup on H6
Hi,
On Wed, Apr 24, 2019 at 01:44:12PM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC has a register to set the PIO banks' voltage. When
> it mismatches the real voltage supplied to the VCC to the PIO supply,
> the PIO will work improperly.
>
> The PIO controller also has a register that contains the status of each
> VCC rail of the PIO supplies, and it has the same definition with the
> configuration register. so we can just copy the content of this register
> to the configuration register at startup, to ensure the configuration is
> correct at startup stage.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/include/asm/arch-sunxi/gpio.h | 3 +++
> arch/arm/mach-sunxi/board.c| 9 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 40a3f845d0..a646ea6a3c 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -73,6 +73,9 @@ struct sunxi_gpio_reg {
> struct sunxi_gpio_int gpio_int;
> };
>
> +#define SUN50I_H6_GPIO_POW_MOD_SEL 0x340
> +#define SUN50I_H6_GPIO_POW_MOD_VAL 0x348
> +
> #define BANK_TO_GPIO(bank) (((bank) < SUNXI_GPIO_L) ? \
> &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank] : \
> &((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)->gpio_bank[(bank) -
> SUNXI_GPIO_L])
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index c6dd7b8e54..bd3b5d8303 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -65,6 +65,7 @@ struct mm_region *mem_map = sunxi_mem_map;
>
> static int gpio_init(void)
Does this really run after regulators are turned on? If not, how will the SoC
detect voltages correctly?
regards,
o.
> {
> + __maybe__unused uint val;
> #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
> #if defined(CONFIG_MACH_SUN4I) || \
> defined(CONFIG_MACH_SUN7I) || \
> @@ -139,6 +140,14 @@ static int gpio_init(void)
> #error Unsupported console port number. Please fix pin mux settings in
> board.c
> #endif
>
> +#ifdef CONFIG_MACH_SUN50I_H6
> + /* Update PIO power bias configuration by copy hardware detected value
> */
> + val = readl(SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> + writel(val, SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> + val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> + writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> +#endif
> +
> return 0;
> }
>
> --
> 2.18.1
>
> ___
> U-Boot mailing list
> u-b...@lists.denx.de
> https://lists.denx.de/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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20191025125917.grpeemrlq45pupjz%40core.my.home.
Re: [linux-sunxi] [PATCH 3/3] Revert "drm/sun4i: dsi: Rework a bit the hblk calculation"
HI Icenowy, On Sun, Oct 06, 2019 at 11:12:43PM +0800, Icenowy Zheng wrote: > 在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道： > > 在 2019-10-03四的 09:53 +0530，Jagan Teki写道： > > > Hi Wens, > > > > > > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng > > > wrote: > > > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b. > > > > > > > > This commit, although claimed as a refactor, in fact changed the > > > > formula. > > > > > > > > By expanding the original formula, we can find that the const 10 > > > > is > > > > not > > > > substracted, instead it's added to the value (because 10 is > > > > negative > > > > when calculating hsa, and hsa itself is negative when calculating > > > > hblk). > > > > This breaks the similar pattern to other formulas, so restoring > > > > the > > > > original formula is more proper. > > > > > > > > Signed-off-by: Icenowy Zheng > > > > --- > > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 9 ++--- > > > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > > index 2d3e822a7739..cb5fd19c0d0d 100644 > > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c > > > > @@ -577,14 +577,9 @@ static void sun6i_dsi_setup_timings(struct > > > > sun6i_dsi *dsi, > > > > (mode->hsync_start - mode->hdisplay) * > > > > Bpp - HFP_PACKET_OVERHEAD); > > > > > > > > /* > > > > -* The blanking is set using a sync event (4 > > > > bytes) > > > > -* and a blanking packet (4 bytes + payload + 2 > > > > -* bytes). Its minimal size is therefore 10 > > > > bytes. > > > > +* hblk seems to be the line + porches length. > > > > */ > > > > -#define HBLK_PACKET_OVERHEAD 10 > > > > - hblk = max((unsigned int)HBLK_PACKET_OVERHEAD, > > > > - (mode->htotal - (mode->hsync_end - > > > > mode- > > > > > hsync_start)) * Bpp - > > > > - HBLK_PACKET_OVERHEAD); > > > > + hblk = mode->htotal * Bpp - hsa; > > > > > > The original formula is correct according to BSP [1] and work with > > > my > > > panels which I have tested before. May be the horizontal timings on > > > panels you have leads to negative value. > > > > Do you tested the same timing with BSP kernel? > > > > It's quite difficult to get a negative value here, because the value > > is > > quite big (includes mode->hdisplay * Bpp). > > By re-checking with the BSP source code, I found that the constant in > the HFP formula is indeed wrong -- it should be 16, not 6. I'm not sure if it's relevant to the discussion, but I've recently found a LCD configuration manual for A10, that may contain some useful info: See this: https://github.com/pocketbook/Platform_A13/blob/master/Kernel/drivers/video/sun5i/lcd/a10_lcd_config_nanual_v1.0.pdf regards, o. > > > > Strangely, only change the formula here back makes the timing > > translated from FEX file works (tested on PineTab and PinePhone > > production ver). The translation rule is from [1]. > > > > So I still insist on the patch because it's needed by experiment. > > > > [1] http://linux-sunxi.org/LCD > > > > > [1] > > > https://github.com/ayufan-pine64/linux-pine64/blob/my-hacks-1.2-with-drm/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L919 > > -- > 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/14da3ae768c439e387f6609553bd465e945d4a33.camel%40aosc.io. -- 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/20191007151919.4uraoe374lui22gi%40core.my.home.
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Tue, Sep 17, 2019 at 08:55:42AM -0700, security researcher wrote:
> What's the latest solution here? I see a few patches in the thread, but not
> sure which ones to pick and choose?
Use both:
https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab09103075a133f3c0d5f7b48cc
https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350fc0fba8419e9662e9bb7
> On Monday, September 9, 2019 at 1:27:08 AM UTC, 张宁 wrote:
> >
> > thanks for your patches.
> >
> > BR.
> > Ning.
> >
> > On Sunday, September 8, 2019 at 6:20:54 PM UTC+8, Ondřej Jirman wrote:
> >>
> >> Hi,
> >>
> >> On Sun, Sep 08, 2019 at 12:21:45AM +0200, megous hlavni wrote:
> >> > On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> >> > > Update my test result:
> >> > >
> >> > > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor
> >> plane.
> >> > > display normally but slow with fbdev
> >> > > display abnormally (only cursor shows) with modesetting (lima
> >> enabled)
> >> >
> >> > You can "fix" this by switching to console and back. I've debugged this
> >> > somewhat and it the sun4i drm driver is probably buggy. The drm layers/
> >> > framebuffers are exactly same before and after the switch.
> >> >
> >> > I have not yet dumped mixer registers before/after, but I suspect,
> >> there
> >> > will be some difference, for whatever reason.
> >>
> >> So I have dumped registers, and found out this:
> >>
> >> mixer0:
> >>
> >> first Xorg run:
> >>
> >> 0x01101000 : 0201
> >> 0x01101080 : 0030
> >>
> >> BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
> >> P1_EN
> >>
> >> BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
> >> P0_RTCTL channel0
> >> P1_RTCTL channel3
> >>
> >>
> >> after switch to console and back to Xorg:
> >>
> >> 0x01101000 : 0301
> >> 0x01101080 : 0031
> >>
> >> BLD_FILL_COLOR_CTL:
> >> P1_EN and P0_EN
> >>
> >> BLD_CH_RTCTL:
> >> P0_RTCTL channel1
> >> P1_RTCTL channel3
> >>
> >>
> >> This is despite the layers config being exactly the same as indicated
> >> in /sys/kernel/debug/dri/0/{state,framebuffer}.
> >>
> >> sun4i-drm driver just doesn't handle layer change correctly in all cases.
> >>
> >> For example when enabling a layer, it may disable a different layer if
> >> old_zpos matches the zpos of the other layer.
> >>
> >> I've made a fix for this:
> >>
> >>
> >> https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab09103075a133f3c0d5f7b48cc
> >>
> >>
> >> https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350fc0fba8419e9662e9bb7
> >>
> >>
> >> So with these two patches, Xorg server/modesetting driver will use the
> >> cursor
> >> plane, and plane enable/switching issues are gone (in general, even if
> >> you
> >> don't use the cursor plane patch).
> >>
> >> Anyway, this makes Xorg server work nicely with lima/panfrost without the
> >> need to hack Xorg's modesetting driver to use non-cursor plane for
> >> cursor.
> >>
> >> regards,
> >> o.
> >>
> >> > regards,
> >> > o.
> >> >
> >> > > 2, use VI layer as primary plane, and toppest UI layer as cursor
> >> plane
> >> > > display abnormal in both fbdev and modesetting( lima enabled)
> >> > >
> >> > > so as said by Jernej: these sub-layers don't fit in current DRM
> >> design.
> >> > >
> >> > >
> >> > > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec
> >> wrote:
> >> > > >
> >> > > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman
> >> > > > napisal(a):
> >> > > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote:
> >> > > > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman
> >> > > > napisal(a):
> >> > > > > &
[linux-sunxi] Re: [PATCH v4 00/10] Allwinner sunxi message box support
Hi, On Sun, Sep 08, 2019 at 10:54:17PM -0500, Samuel Holland wrote: > On 9/8/19 10:22 PM, Ondřej Jirman wrote: > > Hello Samuel, > > > > On Mon, Aug 19, 2019 at 10:23:01PM -0500, Samuel Holland wrote: > >> This series adds support for the "hardware message box" in sun8i, sun9i, > >> and sun50i SoCs, used for communication with the ARISC management > >> processor (the platform's equivalent of the ARM SCP). The end goal is to > >> use the arm_scpi driver as a client, communicating with firmware running > >> on the AR100 CPU, or to use the mailbox to forward NMIs that the > >> firmware picks up from R_INTC. > >> > >> Unfortunately, the ARM SCPI client no longer works with this driver > >> since it now exposes all 8 hardware FIFOs individually. The SCPI client > >> could be made to work (and I posted proof-of-concept code to that effect > >> with v1 of this series), but that is a low priority, as Linux does not > >> directly use SCPI with the current firmware version; all SCPI use goes > >> through ATF via PSCI. > >> > >> As requested in the comments to v3 of this patchset, a demo client is > >> provided in the final patch. This demo goes along with a toy firmware > >> which shows that the driver does indeed work for two-way communication > >> on all channels. To build the firmware component, run: > > > > I've tried using this driver with mainline arm_scpi driver (which is > > probably > > an expected future use, since crust provides SCPI interface). > > If you've verified in some way that this driver works on A83T, I'd appreciate > your Tested-by, so I can send a patch for the A83T device tree node. Tested-by: Ondrej Jirman (on A83T) > > The problem I've found is that arm_scpi expects message box to be > > bi-directional, but this driver provides uni-directional interface. > > > > What do you think about making this driver provide bi-directional interface? > > We could halve the number of channels to 4 and mandate TX/RX configuration > > (from main CPU's PoV) as ABI. > > Funny you mention that. That's what I did originally for v1, but it got NAKed > by > Maxime, Andre, and Jassi: > > https://lkml.org/lkml/2018/2/28/125 > https://lkml.org/lkml/2018/2/28/944 > > > Otherwise it's impossible to use it with the arm_scpi driver. > > > > Or do you have any other ideas? I guess arm_scpi can be fixed to add a > > property that would make it possible to use single shmem with two > > mailboxes, one for rx and one for tx, but making sun6i mailbox have > > bi-directional interface sounds easier. > > Yes, you can use the existence of the mbox-names property to determine if the > driver needs one mailbox or two, as I did in this driver: > > https://lkml.org/lkml/2019/3/1/789 > > I'll have a patch available soon that implements this for arm_scpi. Yeah, I've patched arm_scpi too. :) https://megous.com/git/linux/commit/?h=tbs-5.3&id=69a0cd0093a63039ace2f763e8d82009c50ff03c (but that's just for the test, because it breaks the existing interface for other uses) Anyway, using mbox-names looks like a nice solution! Thanks! Though, arm_scpi driver has a bit more complicated existing interface, where it can use multiple mailboxes and rotates through them after every message. BTW, I'm slowly laboring through understanding how to get suspend to ram working on one A83T tablet. https://xnux.eu/tablet-hacking/ Which is how I tested this driver. regards, o. > Cheers, > Samuel > > > regards, > > o. > > > >> git clone https://github.com/crust-firmware/meta meta > >> git clone -b mailbox-demo https://github.com/crust-firmware/crust > >> meta/crust > >> cd meta > >> make > >> > >> That will by default produce a U-Boot + ATF + SCP firmware image in > >> [meta/]build/pinebook/u-boot-sunxi-with-spl.bin. See the top-level > >> README.md for more information, such as cross-compiler setup. > >> > >> I've now used this driver with three separate clients over the past two > >> years, and they all work. If there are no remaining concerns with the > >> driver, I'd like it to get merged. > >> > >> Even without the driver, the clock patches (1-2) can go in at any time. > >> > >> Changes from v3: > >> - Rebased on sunxi-next > >> - Added Rob's Reviewed-by for patch 3 > >> - Fixed a crash when receiving a message on a disabled channel > >> - Cleaned up some comments/for
[linux-sunxi] Re: [PATCH v4 00/10] Allwinner sunxi message box support
Hello Samuel, On Mon, Aug 19, 2019 at 10:23:01PM -0500, Samuel Holland wrote: > This series adds support for the "hardware message box" in sun8i, sun9i, > and sun50i SoCs, used for communication with the ARISC management > processor (the platform's equivalent of the ARM SCP). The end goal is to > use the arm_scpi driver as a client, communicating with firmware running > on the AR100 CPU, or to use the mailbox to forward NMIs that the > firmware picks up from R_INTC. > > Unfortunately, the ARM SCPI client no longer works with this driver > since it now exposes all 8 hardware FIFOs individually. The SCPI client > could be made to work (and I posted proof-of-concept code to that effect > with v1 of this series), but that is a low priority, as Linux does not > directly use SCPI with the current firmware version; all SCPI use goes > through ATF via PSCI. > > As requested in the comments to v3 of this patchset, a demo client is > provided in the final patch. This demo goes along with a toy firmware > which shows that the driver does indeed work for two-way communication > on all channels. To build the firmware component, run: I've tried using this driver with mainline arm_scpi driver (which is probably an expected future use, since crust provides SCPI interface). The problem I've found is that arm_scpi expects message box to be bi-directional, but this driver provides uni-directional interface. What do you think about making this driver provide bi-directional interface? We could halve the number of channels to 4 and mandate TX/RX configuration (from main CPU's PoV) as ABI. Otherwise it's impossible to use it with the arm_scpi driver. Or do you have any other ideas? I guess arm_scpi can be fixed to add a property that would make it possible to use single shmem with two mailboxes, one for rx and one for tx, but making sun6i mailbox have bi-directional interface sounds easier. regards, o. > git clone https://github.com/crust-firmware/meta meta > git clone -b mailbox-demo https://github.com/crust-firmware/crust meta/crust > cd meta > make > > That will by default produce a U-Boot + ATF + SCP firmware image in > [meta/]build/pinebook/u-boot-sunxi-with-spl.bin. See the top-level > README.md for more information, such as cross-compiler setup. > > I've now used this driver with three separate clients over the past two > years, and they all work. If there are no remaining concerns with the > driver, I'd like it to get merged. > > Even without the driver, the clock patches (1-2) can go in at any time. > > Changes from v3: > - Rebased on sunxi-next > - Added Rob's Reviewed-by for patch 3 > - Fixed a crash when receiving a message on a disabled channel > - Cleaned up some comments/formatting in the driver > - Fixed #mbox-cells in sunxi-h3-h5.dtsi (patch 7) > - Removed the irqchip example (no longer relevant to the fw design) > - Added a demo/example client that uses the driver and a toy firmware > > Changes from v2: > - Merge patches 1-3 > - Add a comment in the code explaining the CLK_IS_CRITICAL usage > - Add a patch to mark the AR100 clocks as critical > - Use YAML for the device tree binding > - Include a not-for-merge example usage of the mailbox > > Changes from v1: > - Marked message box clocks as critical instead of hacks in the driver > - 8 unidirectional channels instead of 4 bidirectional pairs > - Use per-SoC compatible strings and an A31 fallback compatible > - Dropped the mailbox framework patch > - Include DT patches for SoCs that document the message box > > Samuel Holland (10): > clk: sunxi-ng: Mark msgbox clocks as critical > clk: sunxi-ng: Mark AR100 clocks as critical > dt-bindings: mailbox: Add a sunxi message box binding > mailbox: sunxi-msgbox: Add a new mailbox driver > ARM: dts: sunxi: a80: Add msgbox node > ARM: dts: sunxi: a83t: Add msgbox node > ARM: dts: sunxi: h3/h5: Add msgbox node > arm64: dts: allwinner: a64: Add msgbox node > arm64: dts: allwinner: h6: Add msgbox node > [DO NOT MERGE] drivers: firmware: msgbox demo > > .../mailbox/allwinner,sunxi-msgbox.yaml | 79 + > arch/arm/boot/dts/sun8i-a83t.dtsi | 10 + > arch/arm/boot/dts/sun9i-a80.dtsi | 10 + > arch/arm/boot/dts/sunxi-h3-h5.dtsi| 10 + > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 34 ++ > arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 24 ++ > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 + > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 3 +- > drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c| 2 +- > drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 3 +- > drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 3 +- > drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 3 +- > drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 3 +- > drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 3 +- > drivers/clk/sunxi-ng/ccu-sun8i-r.c| 2 +- > drivers/clk/sunxi-ng/ccu-sun9i-a
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Wed, Sep 04, 2019 at 11:38:01PM +0200, Jernej Škrabec wrote: > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman napisal(a): > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman > napisal(a): > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): > > > > > > just check drm_mode_cursor_universal, cursor plane needs to support > > > > > > DRM_FORMAT_ARGB > > > > > > > > > > > > but VI layer doesn't support alpha, directly change VI layer to > > > > > > cursor > > > > > > plane is not possible. > > > > > > > > > > > > could we use UI layers? > > > > > > > > > > Sure, but note that second mixer usually supports only one VI and one > > > > > UI > > > > > plane. Note that primary plane is always on first UI, so you can run > > > > > out > > > > > of UI planes. > > > > > > > > > > Most notable example of that combination is A64 HDMI, while LCD output > > > > > on > > > > > A64 has one VI and three UI planes. There is a switch in hardware to > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and > > > > > user > > > > > space would have to be aware of that. > > > > > > > > Each mixer channel has 4 sub-layers, so it should be possible even with > > > > one > > > > UI channel to have a a cursor plane within it (with some constraints). > > > > > > If it's acceptable that cursor is square image then yes. There is no > > > blending between sub-layers. > > > > Ah, bummer. > > > > Looking at DE2 documentation, sub-layer concept is very simple from HW point > of view. There is no adjustable Z-pos, scaling, blending or pixel format > conversion (doc states that they must be in same format) between sub-layers. > To no surprise DMA engine is not part of sub-layer according to mixer block > diagram. It seems like that sub-layers part only feeds DMA with correct order > of memory locations which DMA needs to transfer to the next unit (scaler in > this case). > > I don't think these sub-layers fit in current DRM design. I'm also not sure > in > which case they would be usable. It would probably be usable if you don't need transparency and scaling inside the square areas for each sub-layer. Myabe some hypothetical tiling WM would be able to use that many layers. The layers would not even need to overlap, or have differnent FB formats. Z-ordering can be done by not having a fixed mapping between DRM planes and DE2 layers/sub-layers and doing the mapping dynamically based on the desired zpos for each sub-layer. Anyway if the sub-layers don't overlap there's no need for Z-ordering. I aggree that the current DRM API is not a great match for exposing this. regards, o. > /offtopic > > > > > > Best regards, > > > > > Jernej > > > > > > > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: > > > > > > > Hi, Vasily > > > > > > > > > > > > > > from source, it looks like VI layer is a video plane, right? > > > > > > > > > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer is > > > > > > > a > > > > > > > way to > > > > > > > support HW cursor, > > > > > > > I want to ask whether it's possible to change VI layer type to > > > > > > > cursor > > > > > > > plane, then no changes in modesetting driver? > > > > > > > > > > > > > > BR. > > > > > > > Ning. > > > > > > > > > > > > > > On Tuesday, September 3, 2019 at 11:21:48 PM UTC+8, Vasily > > > > > > > Khoruzhick > > > > > > > > > > > > > > wrote: > > > > > > >> On Tue, Sep 3, 2019 at 1:49 AM 张宁 wrote: > > > > > > >> > Hi, Maxime, Icenowy and other developers > > > > > > >> > > > > > > > >> > In https://linux-sunxi.org/Xorg, it says legacy display engine > > > &
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
Hi,
On Sun, Sep 08, 2019 at 07:01:42PM +0200, Jernej Škrabec wrote:
> Dne nedelja, 08. september 2019 ob 12:20:50 CEST je Ondřej Jirman napisal(a):
> > Hi,
> >
> > On Sun, Sep 08, 2019 at 12:21:45AM +0200, megous hlavni wrote:
> > > On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> > > > Update my test result:
> > > >
> > > > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane.
> > > > display normally but slow with fbdev
> > > > display abnormally (only cursor shows) with modesetting (lima enabled)
> > >
> > > You can "fix" this by switching to console and back. I've debugged this
> > > somewhat and it the sun4i drm driver is probably buggy. The drm layers/
> > > framebuffers are exactly same before and after the switch.
> > >
> > > I have not yet dumped mixer registers before/after, but I suspect, there
> > > will be some difference, for whatever reason.
> >
> > So I have dumped registers, and found out this:
> >
> > mixer0:
> >
> > first Xorg run:
> >
> > 0x01101000 : 0201
> > 0x01101080 : 0030
> >
> > BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
> > P1_EN
> >
> > BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
> > P0_RTCTL channel0
> > P1_RTCTL channel3
> >
> >
> > after switch to console and back to Xorg:
> >
> > 0x01101000 : 0301
> > 0x01101080 : 0031
> >
> > BLD_FILL_COLOR_CTL:
> > P1_EN and P0_EN
> >
> > BLD_CH_RTCTL:
> > P0_RTCTL channel1
> > P1_RTCTL channel3
> >
> >
> > This is despite the layers config being exactly the same as indicated
> > in /sys/kernel/debug/dri/0/{state,framebuffer}.
> >
> > sun4i-drm driver just doesn't handle layer change correctly in all cases.
> >
> > For example when enabling a layer, it may disable a different layer if
> > old_zpos matches the zpos of the other layer.
> >
> > I've made a fix for this:
> >
> > https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab0910307
> > 5a133f3c0d5f7b48cc
> > https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350f
> > c0fba8419e9662e9bb7
> >
> > So with these two patches, Xorg server/modesetting driver will use the
> > cursor plane, and plane enable/switching issues are gone (in general, even
> > if you don't use the cursor plane patch).
> >
> > Anyway, this makes Xorg server work nicely with lima/panfrost without the
> > need to hack Xorg's modesetting driver to use non-cursor plane for cursor.
>
> Why would that be a hack? AFAIK overlay plane has all and additional
> functionality of cursor plane. I think it's better to change modesetting
> driver to use overlay planes. Some (most?) cursor planes are limited and
> really useful only for cursors, so apps might just skip them.
Read that as a synonym for "program". :)
Modesetting driver is a builtin and Xorg server releases are few and far
between, and I'm not going to wait for years and have to manage, compile, and
distribute my own patched Xorg server in the meantime if I don't have to. This
solution works and is pretty much equivalent. One layer would be lost to the
cursor use either way. And kernel change works with existing and legacy code.
I didn't even look at how hard it would be to change just for this reason alone.
Anyway, while having a special cursor plane is nice and lowers the CPU load
quite a bit while moving a mouse, the layer management bugs in the current code
need fixing first.
Maybe later we can add kernel command line option for optionally marking one of
the layers as a cursor one, so that people can choose what they want, depending
on their use case.
regards,
o.
> Best regards,
> Jernej
>
> >
> > regards,
> > o.
> >
> > > regards,
> > >
> > > o.
> > >
> > > > 2, use VI layer as primary plane, and toppest UI layer as cursor plane
> > > > display abnormal in both fbdev and modesetting( lima enabled)
> > > >
> > > > so as said by Jernej: these sub-layers don't fit in current DRM design.
> > > >
> > > > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec
> wrote:
> > > > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman
> > > > >
> > > > > napisal(a):
> > > > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jerne
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
Hi,
On Sun, Sep 08, 2019 at 12:21:45AM +0200, megous hlavni wrote:
> On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote:
> > Update my test result:
> >
> > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane.
> > display normally but slow with fbdev
> > display abnormally (only cursor shows) with modesetting (lima enabled)
>
> You can "fix" this by switching to console and back. I've debugged this
> somewhat and it the sun4i drm driver is probably buggy. The drm layers/
> framebuffers are exactly same before and after the switch.
>
> I have not yet dumped mixer registers before/after, but I suspect, there
> will be some difference, for whatever reason.
So I have dumped registers, and found out this:
mixer0:
first Xorg run:
0x01101000 : 0201
0x01101080 : 0030
BLD_FILL_COLOR_CTL: (aka SUN8I_MIXER_BLEND_PIPE_CTL)
P1_EN
BLD_CH_RTCTL: (aka SUN8I_MIXER_BLEND_ROUTE)
P0_RTCTL channel0
P1_RTCTL channel3
after switch to console and back to Xorg:
0x01101000 : 0301
0x01101080 : 0031
BLD_FILL_COLOR_CTL:
P1_EN and P0_EN
BLD_CH_RTCTL:
P0_RTCTL channel1
P1_RTCTL channel3
This is despite the layers config being exactly the same as indicated
in /sys/kernel/debug/dri/0/{state,framebuffer}.
sun4i-drm driver just doesn't handle layer change correctly in all cases.
For example when enabling a layer, it may disable a different layer if
old_zpos matches the zpos of the other layer.
I've made a fix for this:
https://megous.com/git/linux/commit/?h=private-5.3&id=c186b256a869bab09103075a133f3c0d5f7b48cc
https://megous.com/git/linux/commit/?h=private-5.3&id=5af208e90de5ced30350fc0fba8419e9662e9bb7
So with these two patches, Xorg server/modesetting driver will use the cursor
plane, and plane enable/switching issues are gone (in general, even if you
don't use the cursor plane patch).
Anyway, this makes Xorg server work nicely with lima/panfrost without the
need to hack Xorg's modesetting driver to use non-cursor plane for cursor.
regards,
o.
> regards,
> o.
>
> > 2, use VI layer as primary plane, and toppest UI layer as cursor plane
> > display abnormal in both fbdev and modesetting( lima enabled)
> >
> > so as said by Jernej: these sub-layers don't fit in current DRM design.
> >
> >
> > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec wrote:
> > >
> > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman
> > > napisal(a):
> > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote:
> > > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman
> > > napisal(a):
> > > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote:
> > > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a):
> > > > > > > > just check drm_mode_cursor_universal, cursor plane needs to
> > > support
> > > > > > > > DRM_FORMAT_ARGB
> > > > > > > >
> > > > > > > > but VI layer doesn't support alpha, directly change VI layer to
> > > > > > > > cursor
> > > > > > > > plane is not possible.
> > > > > > > >
> > > > > > > > could we use UI layers?
> > > > > > >
> > > > > > > Sure, but note that second mixer usually supports only one VI and
> > > one
> > > > > > > UI
> > > > > > > plane. Note that primary plane is always on first UI, so you can
> > > run
> > > > > > > out
> > > > > > > of UI planes.
> > > > > > >
> > > > > > > Most notable example of that combination is A64 HDMI, while LCD
> > > output
> > > > > > > on
> > > > > > > A64 has one VI and three UI planes. There is a switch in hardware
> > > to
> > > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented
> > > > > > > and
> > > > > > > user
> > > > > > > space would have to be aware of that.
> > > > > >
> > > > > > Each mixer channel has 4 sub-layers, so it should be possible even
> > > with
> > > > > > one
> > > > > > UI channel to have a a cursor plane within it (with some
> > > constraints).
> > > > >
> > > > > If it's acceptable that cursor is squar
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote: > Update my test result: > > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane. > display normally but slow with fbdev > display abnormally (only cursor shows) with modesetting (lima enabled) BTW, I use this patch: https://megous.com/dl/tmp/0001-drm-sun4i-Mark-one-of-the-UI-planes-as-a-cursor-one.patch o. > 2, use VI layer as primary plane, and toppest UI layer as cursor plane > display abnormal in both fbdev and modesetting( lima enabled) > > so as said by Jernej: these sub-layers don't fit in current DRM design. > > > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec wrote: > > > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman > > napisal(a): > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: > > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman > > napisal(a): > > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: > > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): > > > > > > > just check drm_mode_cursor_universal, cursor plane needs to > > support > > > > > > > DRM_FORMAT_ARGB > > > > > > > > > > > > > > but VI layer doesn't support alpha, directly change VI layer to > > > > > > > cursor > > > > > > > plane is not possible. > > > > > > > > > > > > > > could we use UI layers? > > > > > > > > > > > > Sure, but note that second mixer usually supports only one VI and > > one > > > > > > UI > > > > > > plane. Note that primary plane is always on first UI, so you can > > run > > > > > > out > > > > > > of UI planes. > > > > > > > > > > > > Most notable example of that combination is A64 HDMI, while LCD > > output > > > > > > on > > > > > > A64 has one VI and three UI planes. There is a switch in hardware > > to > > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and > > > > > > user > > > > > > space would have to be aware of that. > > > > > > > > > > Each mixer channel has 4 sub-layers, so it should be possible even > > with > > > > > one > > > > > UI channel to have a a cursor plane within it (with some > > constraints). > > > > > > > > If it's acceptable that cursor is square image then yes. There is no > > > > blending between sub-layers. > > > > > > Ah, bummer. > > > > > > > Looking at DE2 documentation, sub-layer concept is very simple from HW > > point > > of view. There is no adjustable Z-pos, scaling, blending or pixel format > > conversion (doc states that they must be in same format) between > > sub-layers. > > To no surprise DMA engine is not part of sub-layer according to mixer > > block > > diagram. It seems like that sub-layers part only feeds DMA with correct > > order > > of memory locations which DMA needs to transfer to the next unit (scaler > > in > > this case). > > > > I don't think these sub-layers fit in current DRM design. I'm also not > > sure in > > which case they would be usable. > > > > /offtopic > > > > > > > > Best regards, > > > > > > Jernej > > > > > > > > > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: > > > > > > > > Hi, Vasily > > > > > > > > > > > > > > > > from source, it looks like VI layer is a video plane, right? > > > > > > > > > > > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer > > is > > > > > > > > a > > > > > > > > way to > > > > > > > > support HW cursor, > > > > > > > > I want to ask whether it's possible to change VI layer type to > > > > > > > > cursor > > > > > > > > plane, then no changes in modesetting driver? > > > > > > > > > > > > > > > > BR. > > > > > > > >
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Thu, Sep 05, 2019 at 06:30:42PM -0700, 张宁 wrote: > Update my test result: > > 1, use 1st UI layer as primary plane and 3rd UI layer as cursor plane. > display normally but slow with fbdev > display abnormally (only cursor shows) with modesetting (lima enabled) You can "fix" this by switching to console and back. I've debugged this somewhat and it the sun4i drm driver is probably buggy. The drm layers/ framebuffers are exactly same before and after the switch. I have not yet dumped mixer registers before/after, but I suspect, there will be some difference, for whatever reason. regards, o. > 2, use VI layer as primary plane, and toppest UI layer as cursor plane > display abnormal in both fbdev and modesetting( lima enabled) > > so as said by Jernej: these sub-layers don't fit in current DRM design. > > > On Thursday, September 5, 2019 at 5:38:05 AM UTC+8, Jernej Škrabec wrote: > > > > Dne sreda, 04. september 2019 ob 23:10:15 CEST je Ondřej Jirman > > napisal(a): > > > On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: > > > > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman > > napisal(a): > > > > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: > > > > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): > > > > > > > just check drm_mode_cursor_universal, cursor plane needs to > > support > > > > > > > DRM_FORMAT_ARGB > > > > > > > > > > > > > > but VI layer doesn't support alpha, directly change VI layer to > > > > > > > cursor > > > > > > > plane is not possible. > > > > > > > > > > > > > > could we use UI layers? > > > > > > > > > > > > Sure, but note that second mixer usually supports only one VI and > > one > > > > > > UI > > > > > > plane. Note that primary plane is always on first UI, so you can > > run > > > > > > out > > > > > > of UI planes. > > > > > > > > > > > > Most notable example of that combination is A64 HDMI, while LCD > > output > > > > > > on > > > > > > A64 has one VI and three UI planes. There is a switch in hardware > > to > > > > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and > > > > > > user > > > > > > space would have to be aware of that. > > > > > > > > > > Each mixer channel has 4 sub-layers, so it should be possible even > > with > > > > > one > > > > > UI channel to have a a cursor plane within it (with some > > constraints). > > > > > > > > If it's acceptable that cursor is square image then yes. There is no > > > > blending between sub-layers. > > > > > > Ah, bummer. > > > > > > > Looking at DE2 documentation, sub-layer concept is very simple from HW > > point > > of view. There is no adjustable Z-pos, scaling, blending or pixel format > > conversion (doc states that they must be in same format) between > > sub-layers. > > To no surprise DMA engine is not part of sub-layer according to mixer > > block > > diagram. It seems like that sub-layers part only feeds DMA with correct > > order > > of memory locations which DMA needs to transfer to the next unit (scaler > > in > > this case). > > > > I don't think these sub-layers fit in current DRM design. I'm also not > > sure in > > which case they would be usable. > > > > /offtopic > > > > > > > > Best regards, > > > > > > Jernej > > > > > > > > > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: > > > > > > > > Hi, Vasily > > > > > > > > > > > > > > > > from source, it looks like VI layer is a video plane, right? > > > > > > > > > > > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer > > is > > > > > > > > a > > > > > > > > way to > > > > > > > > support HW cursor, > > > > > > > > I want to ask whether it's possible to change VI layer type to > > > > > >
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Wed, Sep 04, 2019 at 11:02:33PM +0200, Jernej Škrabec wrote: > Dne sreda, 04. september 2019 ob 22:45:47 CEST je Ondřej Jirman napisal(a): > > On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: > > > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): > > > > just check drm_mode_cursor_universal, cursor plane needs to support > > > > DRM_FORMAT_ARGB > > > > > > > > but VI layer doesn't support alpha, directly change VI layer to cursor > > > > plane is not possible. > > > > > > > > could we use UI layers? > > > > > > Sure, but note that second mixer usually supports only one VI and one UI > > > plane. Note that primary plane is always on first UI, so you can run out > > > of UI planes. > > > > > > Most notable example of that combination is A64 HDMI, while LCD output on > > > A64 has one VI and three UI planes. There is a switch in hardware to > > > connect 1 VI/ 3 UI mixer to A64 HDMI, but it's not implemented and user > > > space would have to be aware of that. > > > > Each mixer channel has 4 sub-layers, so it should be possible even with one > > UI channel to have a a cursor plane within it (with some constraints). > > If it's acceptable that cursor is square image then yes. There is no blending > between sub-layers. Ah, bummer. > > > Best regards, > > > Jernej > > > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: > > > > > Hi, Vasily > > > > > > > > > > from source, it looks like VI layer is a video plane, right? > > > > > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer is a > > > > > way to > > > > > support HW cursor, > > > > > I want to ask whether it's possible to change VI layer type to cursor > > > > > plane, then no changes in modesetting driver? > > > > > > > > > > BR. > > > > > Ning. > > > > > > > > > > On Tuesday, September 3, 2019 at 11:21:48 PM UTC+8, Vasily Khoruzhick > > > > > > > > > > wrote: > > > > >> On Tue, Sep 3, 2019 at 1:49 AM 张宁 wrote: > > > > >> > Hi, Maxime, Icenowy and other developers > > > > >> > > > > > >> > In https://linux-sunxi.org/Xorg, it says legacy display engine > > > > >> > driver > > > > >> > > > > >> supports HW cursor, but there is no code actually creates a cursor > > > > >> plane > > > > >> in > > > > >> mainline linux, this is also said in: > > > > >> https://groups.google.com/forum/#!searchin/linux-sunxi/subject$3A$20c > > > > >> urso > > > > >> r|sort:date/linux-sunxi/6dZVBtNgh5Q/dpBDfvEjBgAJ>> > > > > >> > > > > >> > currently, lima usespace driver in mesa already has the basic > > > > >> > function > > > > >> > > > > >> for desktop, if lima is enabled, cursor rendering will possibly go > > > > >> GPU, > > > > >> this will be less efficient than HW cursor. > > > > >> > > > > >> > do you have plan to enable cursor plane? > > > > >> > > > > >> That's up to X11 developers. sun4i-drm exposes UI and VI planes on > > > > >> SoCs with DE2, and there's no dedicated cursor plane in hardware. > > > > >> Basically sun4i-drm exposes what's available in hardware. But > > > > >> xf86-video-modesetting doesn't use VI plane for anything while it > > > > >> could use it for cursor. > > > > >> > > > > >> Groups "linux-sunxi" group. > > > > >> > > > > >> > To unsubscribe from this group and stop receiving emails from it, > > > > >> > send > > > > >> > > > > >> an email to linux...@googlegroups.com. > > > > >> > > > > >> > To view this discussion on the web, visit > > > > >> > > > > >> https://groups.google.com/d/msgid/linux-sunxi/8d091584-8e01-431d-b9b0 > > > > >> -93d > > > > >> d7e0f0cec%40googlegroups.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/20190904211015.r2nx5tohrhkxk7cc%40core.my.home.
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Wed, Sep 04, 2019 at 07:29:39AM +0200, Jernej Škrabec wrote: > Dne sreda, 04. september 2019 ob 05:08:14 CEST je 张宁 napisal(a): > > just check drm_mode_cursor_universal, cursor plane needs to support > > DRM_FORMAT_ARGB > > > > but VI layer doesn't support alpha, directly change VI layer to cursor > > plane is not possible. > > > > could we use UI layers? > > Sure, but note that second mixer usually supports only one VI and one UI > plane. Note that primary plane is always on first UI, so you can run out of > UI > planes. > > Most notable example of that combination is A64 HDMI, while LCD output on A64 > has one VI and three UI planes. There is a switch in hardware to connect 1 VI/ > 3 UI mixer to A64 HDMI, but it's not implemented and user space would have to > be aware of that. Each mixer channel has 4 sub-layers, so it should be possible even with one UI channel to have a a cursor plane within it (with some constraints). > Best regards, > Jernej > > > > > On Wednesday, September 4, 2019 at 9:26:03 AM UTC+8, 张宁 wrote: > > > Hi, Vasily > > > > > > from source, it looks like VI layer is a video plane, right? > > > > > > let xf86-vidoe-modesetting driver support sun4i-drm's VI layer is a way to > > > support HW cursor, > > > I want to ask whether it's possible to change VI layer type to cursor > > > plane, then no changes in modesetting driver? > > > > > > BR. > > > Ning. > > > > > > On Tuesday, September 3, 2019 at 11:21:48 PM UTC+8, Vasily Khoruzhick > > > > > > wrote: > > >> On Tue, Sep 3, 2019 at 1:49 AM 张宁 wrote: > > >> > Hi, Maxime, Icenowy and other developers > > >> > > > >> > In https://linux-sunxi.org/Xorg, it says legacy display engine driver > > >> > > >> supports HW cursor, but there is no code actually creates a cursor plane > > >> in > > >> mainline linux, this is also said in: > > >> https://groups.google.com/forum/#!searchin/linux-sunxi/subject$3A$20curso > > >> r|sort:date/linux-sunxi/6dZVBtNgh5Q/dpBDfvEjBgAJ>> > > >> > currently, lima usespace driver in mesa already has the basic function > > >> > > >> for desktop, if lima is enabled, cursor rendering will possibly go GPU, > > >> this will be less efficient than HW cursor. > > >> > > >> > do you have plan to enable cursor plane? > > >> > > >> That's up to X11 developers. sun4i-drm exposes UI and VI planes on > > >> SoCs with DE2, and there's no dedicated cursor plane in hardware. > > >> Basically sun4i-drm exposes what's available in hardware. But > > >> xf86-video-modesetting doesn't use VI plane for anything while it > > >> could use it for cursor. > > >> > > >> Groups "linux-sunxi" group. > > >> > > >> > To unsubscribe from this group and stop receiving emails from it, send > > >> > > >> an email to linux...@googlegroups.com. > > >> > > >> > To view this discussion on the web, visit > > >> > > >> https://groups.google.com/d/msgid/linux-sunxi/8d091584-8e01-431d-b9b0-93d > > >> d7e0f0cec%40googlegroups.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/8613808.bs98POC9MK%40jernej-laptop. -- 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/20190904204547.oizi6hzi6ftanunp%40core.my.home.
[linux-sunxi] Re: [PATCH 00/10] arm64: dts: allwinner: h5: Enable CPU DVFS (cpufreq)
Hi, On Wed, Jan 30, 2019 at 04:41:53PM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This series enables DVFS for the CPU cores (aka cpufreq) on the > Allwinner H5 SoC. The OPP table was taken from Armbian, with minor > tweaks to the maximum voltage to account for slightly increased voltage > on some of the boards. > > This has been tested on the Bananapi M2+ v1.2 and Libre Computer > ALL-H3-CC H5 ver.. I do not have the remaining boards so I've CC-ed > people who did the original submission or have modified the board > specifically later on. > > Patch 1 fixes the voltages specified for the GPIO-controlled regulator > on the Bananapi M2+ v1.2. The voltages are slightly higher than what > was originally written. > > Patch 2 adds a fixed regulator for the CPU on the original Bananapi M2+. > This is for the retail version, not the engineering samples that had an > even higher voltage setting. > > Patch 3 hooks up the CPU regulator supply for H5 boards that already > define the regulator, but were missing the property to tie it to the > CPUs. > > Patch 4 ~ 8 adds the CPU regulator for boards that don't have it > defined. This is based on each vendor's schematics. I need people > to test each of these specifically and the whole series. > > Patch 9 ties the CPU clock to the CPU cores. > > Patch 10 adds the OPP table, based on the one from Armbian. > > Please have a look and please help test this. Looks like this patch series got forgotten. Or is it waiting for some user testing? regards, o. > > Regards > ChenYu > > > Chen-Yu Tsai (10): > ARM: dts: sunxi: bananapi-m2-plus-v1.2: Fix CPU supply voltages > ARM: dts: bananapi-m2-plus: Add CPU supply regulator > arm64: dts: allwinner: h5: Hook up cpu regulator supplies > arm64: dts: allwinner: h5: nanopi-neo2: Add CPU regulator supply > arm64: dts: allwinner: h5: orange-pi-zero-plus: Add CPU regulator > supply > arm64: dts: allwinner: h5: orange-pi-zero-plus2: Add CPU regulator > supply > arm64: dts: allwinner: h5: orange-pi-pc2: Add CPU regulator supply > arm64: dts: allwinner: h5: orange-pi-prime: Add CPU regulator supply > arm64: dts: allwinner: h5: Add clock to CPU cores > arm64: dts: allwinner: h5: Add CPU Operating Performance Points table > > .../boot/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 30 +++- > arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 14 > .../sun50i-h5-emlid-neutis-n5-devboard.dts| 4 + > .../allwinner/sun50i-h5-nanopi-neo-plus2.dts | 4 + > .../dts/allwinner/sun50i-h5-nanopi-neo2.dts | 20 + > .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 28 +++ > .../allwinner/sun50i-h5-orangepi-prime.dts| 28 +++ > .../sun50i-h5-orangepi-zero-plus.dts | 20 + > .../sun50i-h5-orangepi-zero-plus2.dts | 20 + > arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 75 +++ > 10 files changed, 224 insertions(+), 19 deletions(-) > > -- > 2.20.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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/20190902140323.fgfrifyow5qgoce4%40core.my.home.
[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay
Hi,
On Tue, Aug 27, 2019 at 03:34:43PM +0200, Maxime Ripard wrote:
> On Sun, Aug 25, 2019 at 03:03:36PM +0200, Jernej Skrabec wrote:
> > Depending on kernel and bootloader configuration, it's possible that
> > Realtek ethernet PHY isn't powered on properly. It needs some time
> > before it can be used.
> >
> > Fix that by adding 100ms ramp delay to regulator responsible for
> > powering PHY.
> >
> > Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i")
> > Suggested-by: Ondrej Jirman
> > Signed-off-by: Jernej Skrabec
>
> How was that delay found?
I suggested it. There's no delay in the dwmac-sun8i driver, so after enabling
the phy power, it will start accessing it over MDIO right away, which is not
good.
I suggested the value based on post-reset delay in the PHY's datasheet (30ms).
Multiplied ~3x (if I remember correctly) to get some safety margin. Chip has
more to do then after the HW reset, and regulator also needs some time to
ramp-up.
regards,
o.
> It should at least have a comment explaining why it's there.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.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/20190827134806.5l7dxyvzjrvabh7o%40core.my.home.
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
On Sat, Aug 24, 2019 at 11:36:26PM +0200, Jernej Škrabec wrote: > Dne sobota, 24. avgust 2019 ob 23:27:46 CEST je Ondřej Jirman napisal(a): > > Hello Jernej, > > > > On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > > > Visually? > > > > > > > > That would explain why it doesn't work for you. The mainline RTC driver > > > > disables auto-switch feature, and if your board doesn't have a crystal > > > > for > > > > LOSC, RTC will not generate a clock for the RTC. > > > > > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > > > doesn't have the crystal. You need to fix this in the DTS for your board > > > > instead of patching the driver. > > > > > > I see that reparenting is supported, but I'm not sure how to fix that in > > > DT. Any suggestion? > > > > You may try removing the clocks property from rtc node. > > I don't think this would work: > https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L246 Well, I don't know. There has to be some way to make it work, since the code deals with it here: https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L270 Number of parents for LOSC is calculated from the DT somehow. Maybne something to do with the #clock-cells property? Sorry I can't be of more help here. > > > > > > The driver has parent clock selection logic in case the LOSC crystal is > > > > not > > > > used. > > > > > > > > Your patch enables automatic detection of LOSC failure and RTC changes > > > > clock to LOSC automatically, despite what's described in the DTS. That > > > > may fix the issue, but is not the correct solution. > > > > > > > > Registers on my board look like this (external 32k osc is used) for > > > > reference: > > > > > > > > LOSC_CTRL_REG[700]: 8011 > > > > > > > > KEY_FIELD ??? (0) > > > > LOSC_AUTO_SWT_BYPASS EN (1) > > > > LOSC_AUTO_SWT_EN DIS (0) > > > > EXT_LOSC_ENEN (1) > > > > EXT_LOSC_GSM LOW (0) > > > > BATTERY_DIRDISCHARGE(0) > > > > LOSC_SRC_SEL EXT32k (1) > > > > > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > > > > > > > EXT_LOSC_STA OK (0) > > > > LOSC_AUTO_SWT_PEND NOEFF(0) > > > > LOSC_SRC_SEL_STA EXT32K (1) > > > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > > > has value 0x4, so there is issue with external crystal (it's missing) and > > > RTC switched to internal one. > > > > > > BTW, what's wrong with automatic switching? Why is it disabled? > > > > It always was disabled on mainline (bit 14 was set to 0 even before my > > patch). H6 just probably has another extra undocummented bit, that's needed > > to disables it properly. > > > > You probably don't want a glitch to switch your RTC from high-precision > > clock to a low precision one possibly without any indication in the > > userspace or a kernel log. > > > > Regardless of all this, DTS needs to have a correct description of the HW, > > which means if RTC module is not connected to the 32.757kHz crystal/clock, > > clocks property should be empty. > > If we are talking about correct HW description, then clock property should > actually have possibility that two clocks are defined - one for internal RC > (always present) and one external crystal (optional). In such case I could > really just omit external clock and be done with it. But I'm not sure if such Internal RC is thought to be part of the RTC module, so it's not defined as an input clock to the RTC module. regards, Ondrej > > Best regards, > Jernej > > > > > regards, > > o. > > > > > Best regards, > > > Jernej > > > > > > > regards, > > > > > > > > o. > > > > > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-b > > > > > > sp#n > > > > > > 650 > > > > > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > Jernej > > > > > > > > > > > regards, > > > > > > > > > > > > o. > > > > -- 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/20190824221638.ztoqpp5y6btshgit%40core.my.home.
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Hello Jernej, On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > Visually? > > > > That would explain why it doesn't work for you. The mainline RTC driver > > disables auto-switch feature, and if your board doesn't have a crystal for > > LOSC, RTC will not generate a clock for the RTC. > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > doesn't have the crystal. You need to fix this in the DTS for your board > > instead of patching the driver. > > I see that reparenting is supported, but I'm not sure how to fix that in DT. > Any suggestion? You may try removing the clocks property from rtc node. > > > > The driver has parent clock selection logic in case the LOSC crystal is not > > used. > > > > Your patch enables automatic detection of LOSC failure and RTC changes clock > > to LOSC automatically, despite what's described in the DTS. That may fix > > the issue, but is not the correct solution. > > > > Registers on my board look like this (external 32k osc is used) for > > reference: > > > > LOSC_CTRL_REG[700]: 8011 > > KEY_FIELD ??? (0) > > LOSC_AUTO_SWT_BYPASS EN (1) > > LOSC_AUTO_SWT_EN DIS (0) > > EXT_LOSC_ENEN (1) > > EXT_LOSC_GSM LOW (0) > > BATTERY_DIRDISCHARGE(0) > > LOSC_SRC_SEL EXT32k (1) > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > EXT_LOSC_STA OK (0) > > LOSC_AUTO_SWT_PEND NOEFF(0) > > LOSC_SRC_SEL_STA EXT32K (1) > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > has value 0x4, so there is issue with external crystal (it's missing) and RTC > switched to internal one. > > BTW, what's wrong with automatic switching? Why is it disabled? It always was disabled on mainline (bit 14 was set to 0 even before my patch). H6 just probably has another extra undocummented bit, that's needed to disables it properly. You probably don't want a glitch to switch your RTC from high-precision clock to a low precision one possibly without any indication in the userspace or a kernel log. Regardless of all this, DTS needs to have a correct description of the HW, which means if RTC module is not connected to the 32.757kHz crystal/clock, clocks property should be empty. regards, o. > Best regards, > Jernej > > > regards, > > o. > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n > > > > 650 > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > Best regards, > > > Jernej > > > > > > > regards, > > > > > > > > o. > > > > -- 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/20190824212746.a5pyilkrrvysjjbd%40core.my.home.
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
On Sat, Aug 24, 2019 at 03:16:41PM +0200, Jernej Škrabec wrote: > Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > > Hi, > > > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > > Hi! > > > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > > > napisal(a): > > > > > > From: Ondrej Jirman > > > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > > differences > > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > > code. > > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > > called > > > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator. > > > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > > whether > > > > > > external low speed oscillator is working correctly. > > > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > > > - during reparenting > > > > > > - when probing the clock > > > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > > external crystal oscillator, to internal RC oscillator, if external > > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > > probe. > > > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > Reviewed-by: Chen-Yu Tsai > > > > > > --- > > > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > > ++-- > > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > > > /* Control register */ > > > > > > #define SUN6I_LOSC_CTRL0x > > > > > > #define SUN6I_LOSC_CTRL_KEY(0x16aa > << 16) > > > > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15) > > > > > > > > > > User manual says that above field is bit 14. > > > > > > > > See the previous discussion, this is from BSP. > > > > > > I have two versions of BSP (don't ask me which) which have this set as bit > > > 14 and changing this to 14 actually solves all my problems with LOSC (no > > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > > parent) on Tanix TX6 box. > > > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > > crystal oscillator on your board? > > I really don't know, but here is DT: http://ix.io/1ThI > > > > > Anyway, see here: > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649 > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652 > > Interesting, 4.9 BSP has additional bit definition, which is not documented > in > manual and 3.10 BSP to which I refer. > > I was referring to 3.10 BSP, which uses only bit 14. I thought that you named > it differently. > > > > > It would be nice to know what's really happening. > > > > My output is: > > > > [0.832252] sun6i-rtc 700.rtc: registered as rtc0 > > [0.832257] sun6i-rtc 700.rtc: RTC enabled > > [1.728968] sun6i-rtc 700.rtc: setting system clock to > > 1970-01-01T00:00:07 UTC (7) > > With change, I get same output. >
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> > Hi,
> >
> > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > > Hi!
> > >
> > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com
> napisal(a):
> > > > From: Ondrej Jirman
> > > >
> > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > mostly in features that are not yet supported by this driver.
> > > >
> > > > Some differences are already stated in the comments in existing code.
> > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > >
> > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > external low speed oscillator is working correctly.
> > > >
> > > > This patch adds support for enabling LOSC when necessary:
> > > >
> > > > - during reparenting
> > > > - when probing the clock
> > > >
> > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > external crystal oscillator, to internal RC oscillator, if external
> > > > oscillator fails. This is enabled by default. Disable it during
> > > > probe.
> > > >
> > > > Signed-off-by: Ondrej Jirman
> > > > Reviewed-by: Chen-Yu Tsai
> > > > ---
> > > >
> > > > drivers/rtc/rtc-sun6i.c | 40 ++--
> > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > index d50ee023b559..b0c3752bed3f 100644
> > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > @@ -32,9 +32,11 @@
> > > >
> > > > /* Control register */
> > > > #define SUN6I_LOSC_CTRL0x
> > > > #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > > >
> > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
> > >
> > > User manual says that above field is bit 14.
> >
> > See the previous discussion, this is from BSP.
>
> I have two versions of BSP (don't ask me which) which have this set as bit 14
> and changing this to 14 actually solves all my problems with LOSC (no more
> issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on
> Tanix TX6 box.
Interesting. Is LOSC fed externally generated clock, or is it setup as a crystal
oscillator on your board?
Anyway, see here:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652
It would be nice to know what's really happening.
My output is:
[0.832252] sun6i-rtc 700.rtc: registered as rtc0
[0.832257] sun6i-rtc 700.rtc: RTC enabled
[1.728968] sun6i-rtc 700.rtc: setting system clock to
1970-01-01T00:00:07 UTC (7)
I think, you may have just enabled the auto switch feature, and running the
clock from low precision RC oscillator with your patch.
The real issue probably is that the mainline driver is missing this:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650
regards,
o.
> Best regards,
> Jernej
>
> >
> > regards,
> > o.
> >
> > > Best regards,
> > > Jernej
> > >
> > > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
> > > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
> > > >
> > > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_ENBIT(4)
> > > >
> > > > #define SUN6I_LOSC_CTRL_EXT_OSCBIT(0)
> > > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > > >
> > > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > > >
> > > > unsigned int has_prescaler : 1;
> > > > unsigned int has_out_clk : 1;
> > > > unsigned int export_iosc : 1;
> > > >
> > > > + unsigned int has_losc_en : 1;
> > > > + unsigned int has_auto_swt : 1;
> > > >
> > > > };
> >
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Hi, On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote: > Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > > Hi! > > > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > > From: Ondrej Jirman > > > > > > I went through the datasheets for H6 and H5, and compared the differences. > > > RTCs are largely similar, but not entirely compatible. Incompatibilities > > > are in details not yet implemented by the rtc driver though. > > > > > > I also corrected the clock tree in H6 DTSI. > > > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > > on boards using H6 SoC. > > > > > > There was some discussion previously of describing HOSC, DCXO and XO > > > oscillators and clocks as part of RTC in DT, but I decided against it > > > because it's not necessary, becuse information that would be provided > > > as a part of DT can already be determined at runtime from RTC registers, > > > so this woudn't add any value and would only introduce complications > > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > > > Please take a look. > > > > > > > > > Thank you and regards, > > > > > > Ondrej Jirman > > > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get this > > in dmesg: > > > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > > > Last line is repeated non-stop. > > > > Any idea what could be wrong? > > Additional info - this is on kernel 5.2.6 with your patches applied. Do you have schematics, or a FEX file for the board or any other info on how the RTC is set up on that board? Can you dump the RTC register range? regards, o. > Best regards, > Jernej > > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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/20190824125612.zq5qsay2wv62wykt%40core.my.home.
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Hi,
On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com napisal(a):
> > From: Ondrej Jirman
> >
> > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > mostly in features that are not yet supported by this driver.
> >
> > Some differences are already stated in the comments in existing code.
> > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> >
> > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > external low speed oscillator is working correctly.
> >
> > This patch adds support for enabling LOSC when necessary:
> >
> > - during reparenting
> > - when probing the clock
> >
> > H6 also has capacbility to automatically reparent RTC clock from
> > external crystal oscillator, to internal RC oscillator, if external
> > oscillator fails. This is enabled by default. Disable it during
> > probe.
> >
> > Signed-off-by: Ondrej Jirman
> > Reviewed-by: Chen-Yu Tsai
> > ---
> > drivers/rtc/rtc-sun6i.c | 40 ++--
> > 1 file changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index d50ee023b559..b0c3752bed3f 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -32,9 +32,11 @@
> > /* Control register */
> > #define SUN6I_LOSC_CTRL0x
> > #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
>
> User manual says that above field is bit 14.
See the previous discussion, this is from BSP.
regards,
o.
> Best regards,
> Jernej
>
> > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > #define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
> > #define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
> > +#define SUN6I_LOSC_CTRL_EXT_LOSC_ENBIT(4)
> > #define SUN6I_LOSC_CTRL_EXT_OSCBIT(0)
> > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> >
> > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > unsigned int has_prescaler : 1;
> > unsigned int has_out_clk : 1;
> > unsigned int export_iosc : 1;
> > + unsigned int has_losc_en : 1;
> > + unsigned int has_auto_swt : 1;
> > };
> >
> > struct sun6i_rtc_dev {
> > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > val |= SUN6I_LOSC_CTRL_KEY;
> > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > + if (rtc->data->has_losc_en) {
> > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > + }
> > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > spin_unlock_irqrestore(&rtc->lock, flags);
> >
> > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node
> > *node, const char *iosc_name = "rtc-int-osc";
> > const char *clkout_name = "osc32k-out";
> > const char *parents[2];
> > + u32 reg;
> >
> > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > if (!rtc)
> > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > device_node *node, goto err;
> > }
> >
> > + reg = SUN6I_LOSC_CTRL_KEY;
> > + if (rtc->data->has_auto_swt) {
> > + /* Bypass auto-switch to int osc, on ext losc failure */
> > + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > + }
> > +
> > /* Switch to the external, more precise, oscillator */
> > - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> > - rtc->base + SUN6I_LOSC_CTRL);
> > + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > + if (rtc->data->has_losc_en)
> > + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> >
> > /* Yes, I know, this is ugly. */
> > sun6i_rtc = rtc;
> > @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> > "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> > "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
> >
> > +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> > + .rc_osc_rate = 1600,
> > + .fixed_prescaler = 32,
> > + .has_prescaler = 1,
> > + .has_out_clk = 1,
> > + .export_iosc = 1,
> > + .has_losc_en = 1,
> > + .has_auto_swt = 1,
> > +};
> > +
> > +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> > +{
> > + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> > +}
> > +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> > + sun50i_h6_rtc_clk_init);
> > +
> > static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> > .rc_osc_rate = 32000,
> > .has_out_clk = 1,
> > @@ -675,6 +710,7 @@ static cons
[linux-sunxi] Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
Hi,
On Tue, Aug 20, 2019 at 08:07:53AM -0500, Samuel Holland wrote:
> On 8/20/19 6:18 AM, Ondřej Jirman wrote:
> > Hi Samuel,
> >
> > On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> >> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> >> used for communication between the ARM CPUs and the ARISC management
> >> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
> >>
> >> Add a driver for it, so it can be used for SCPI or other communication
> >> protocols.
> >>
> >> Signed-off-by: Samuel Holland
> >> ---
> >> drivers/mailbox/Kconfig| 10 +
> >> drivers/mailbox/Makefile | 2 +
> >> drivers/mailbox/sunxi-msgbox.c | 323 +
> >> 3 files changed, 335 insertions(+)
> >> create mode 100644 drivers/mailbox/sunxi-msgbox.c
> >>
> >> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> >> index ab4eb750bbdd..57d12936175e 100644
> >> --- a/drivers/mailbox/Kconfig
> >> +++ b/drivers/mailbox/Kconfig
> >> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
> >> message to the IPI buffer and will access the IPI control
> >> registers to kick the other processor or enquire status.
> >>
> >> +config SUNXI_MSGBOX
> >> + tristate "Allwinner sunxi Message Box"
> >> + depends on ARCH_SUNXI || COMPILE_TEST
> >> + default ARCH_SUNXI
> >> + help
> >> +Mailbox implementation for the hardware message box present in
> >> +Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
> >> +used for communication between the application CPUs and the power
> >> +management coprocessor.
> >> +
> >> endif
> >> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> >> index c22fad6f696b..bec2d50b0976 100644
> >> --- a/drivers/mailbox/Makefile
> >> +++ b/drivers/mailbox/Makefile
> >> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
> >> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
> >>
> >> obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o
> >> +
> >> +obj-$(CONFIG_SUNXI_MSGBOX)+= sunxi-msgbox.o
> >> diff --git a/drivers/mailbox/sunxi-msgbox.c
> >> b/drivers/mailbox/sunxi-msgbox.c
> >> new file mode 100644
> >> index ..29a5101a5390
> >> --- /dev/null
> >> +++ b/drivers/mailbox/sunxi-msgbox.c
> >> @@ -0,0 +1,323 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +//
> >> +// Copyright (c) 2017-2019 Samuel Holland
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#define NUM_CHANS 8
> >> +
> >> +#define CTRL_REG(n) (0x + 0x4 * ((n) / 4))
> >> +#define CTRL_RX(n)BIT(0 + 8 * ((n) % 4))
> >> +#define CTRL_TX(n)BIT(4 + 8 * ((n) % 4))
> >> +
> >> +#define REMOTE_IRQ_EN_REG 0x0040
> >> +#define REMOTE_IRQ_STAT_REG 0x0050
> >> +#define LOCAL_IRQ_EN_REG 0x0060
> >> +#define LOCAL_IRQ_STAT_REG0x0070
> >> +
> >> +#define RX_IRQ(n) BIT(0 + 2 * (n))
> >> +#define RX_IRQ_MASK 0x
> >> +#define TX_IRQ(n) BIT(1 + 2 * (n))
> >> +#define TX_IRQ_MASK 0x
> >> +
> >> +#define FIFO_STAT_REG(n) (0x0100 + 0x4 * (n))
> >> +#define FIFO_STAT_MASKGENMASK(0, 0)
> >> +
> >> +#define MSG_STAT_REG(n) (0x0140 + 0x4 * (n))
> >> +#define MSG_STAT_MASK GENMASK(2, 0)
> >> +
> >> +#define MSG_DATA_REG(n) (0x0180 + 0x4 * (n))
> >> +
> >> +#define mbox_dbg(mbox, ...) dev_dbg((mbox)->controller.dev,
> >> __VA_ARGS__)
> >> +
> >> +struct sunxi_msgbox {
> >> + struct mbox_controller controller;
> >> + struct clk *clk;
> >> + spinlock_t lock;
> >> + void __iomem *regs;
> >> +};
> >> +
> >> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
> >> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
>
[linux-sunxi] Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
Hi Samuel,
On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> used for communication between the ARM CPUs and the ARISC management
> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
>
> Add a driver for it, so it can be used for SCPI or other communication
> protocols.
>
> Signed-off-by: Samuel Holland
> ---
> drivers/mailbox/Kconfig| 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/sunxi-msgbox.c | 323 +
> 3 files changed, 335 insertions(+)
> create mode 100644 drivers/mailbox/sunxi-msgbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index ab4eb750bbdd..57d12936175e 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
> message to the IPI buffer and will access the IPI control
> registers to kick the other processor or enquire status.
>
> +config SUNXI_MSGBOX
> + tristate "Allwinner sunxi Message Box"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + default ARCH_SUNXI
> + help
> + Mailbox implementation for the hardware message box present in
> + Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
> + used for communication between the application CPUs and the power
> + management coprocessor.
> +
> endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index c22fad6f696b..bec2d50b0976 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC)+= stm32-ipcc.o
> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
>
> obj-$(CONFIG_ZYNQMP_IPI_MBOX)+= zynqmp-ipi-mailbox.o
> +
> +obj-$(CONFIG_SUNXI_MSGBOX) += sunxi-msgbox.o
> diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
> new file mode 100644
> index ..29a5101a5390
> --- /dev/null
> +++ b/drivers/mailbox/sunxi-msgbox.c
> @@ -0,0 +1,323 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2017-2019 Samuel Holland
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NUM_CHANS8
> +
> +#define CTRL_REG(n) (0x + 0x4 * ((n) / 4))
> +#define CTRL_RX(n) BIT(0 + 8 * ((n) % 4))
> +#define CTRL_TX(n) BIT(4 + 8 * ((n) % 4))
> +
> +#define REMOTE_IRQ_EN_REG0x0040
> +#define REMOTE_IRQ_STAT_REG 0x0050
> +#define LOCAL_IRQ_EN_REG 0x0060
> +#define LOCAL_IRQ_STAT_REG 0x0070
> +
> +#define RX_IRQ(n)BIT(0 + 2 * (n))
> +#define RX_IRQ_MASK 0x
> +#define TX_IRQ(n)BIT(1 + 2 * (n))
> +#define TX_IRQ_MASK 0x
> +
> +#define FIFO_STAT_REG(n) (0x0100 + 0x4 * (n))
> +#define FIFO_STAT_MASK GENMASK(0, 0)
> +
> +#define MSG_STAT_REG(n) (0x0140 + 0x4 * (n))
> +#define MSG_STAT_MASKGENMASK(2, 0)
> +
> +#define MSG_DATA_REG(n) (0x0180 + 0x4 * (n))
> +
> +#define mbox_dbg(mbox, ...) dev_dbg((mbox)->controller.dev, __VA_ARGS__)
> +
> +struct sunxi_msgbox {
> + struct mbox_controller controller;
> + struct clk *clk;
> + spinlock_t lock;
> + void __iomem *regs;
> +};
> +
> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
> +
> +static inline int channel_number(struct mbox_chan *chan)
> +{
> + return chan - chan->mbox->chans;
> +}
> +
> +static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
> +{
> + return chan->con_priv;
> +}
> +
> +static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
> +{
> + struct sunxi_msgbox *mbox = dev_id;
> + uint32_t status;
> + int n;
> +
> + /* Only examine channels that are currently enabled. */
> + status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
> + readl(mbox->regs + LOCAL_IRQ_STAT_REG);
> +
> + if (!(status & RX_IRQ_MASK))
> + return IRQ_NONE;
> +
> + for (n = 0; n < NUM_CHANS; ++n) {
> + struct mbox_chan *chan = &mbox->controller.chans[n];
> +
> + if (!(status & RX_IRQ(n)))
> + continue;
> +
> + while (sunxi_msgbox_peek_data(chan)) {
> + uint32_t msg = readl(mbox->regs + MSG_DATA_REG(n));
> +
> + mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
> + mbox_chan_received_data(chan, &msg);
> + }
> +
> + /* The IRQ can be cleared only once the FIFO is empty. */
> + writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int sunxi_msgbox_send_data(struct mbox_chan *chan, void *data)
> +{
