Re: [linux-sunxi] [PATCH RESEND v3] arm64: dts: allwinner: a64: olinuxino: Enable audio
On Tue, Jan 11, 2022 at 09:08:23PM +0100, 'Philip Rinn' via linux-sunxi wrote:
> Enable the audio hardware on the Olimex A64-OLinuXino board family.
> Tested on the A64-OLinuXino-2Ge8G-IND variant.
I have similar patch in one of my "long forgotten branches", but I'm not 100%
sure whether the cpvdd-supply is required for codec_analog. IIRC, sound worked
for me without the issues on A64-Olinuxino board (Rev D).
'cpvdd-supply = <_eldo1>' for codec_analog
And we also need to enable these configuration options in the defconfig:
+CONFIG_SND_SUN8I_CODEC=m
+CONFIG_SND_SUN50I_CODEC_ANALOG=m
>
> Signed-off-by: Philip Rinn
>
> ---
>
>
> Changes in v2: added missing {...} part
> Changes in v3: removed HDMI audio part as requested by Jernej Škrabec
>
> arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts| 30
> +++
>
> 1 file changed, 30 insertions(+)
>
>
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>
> index ec7e2c0e82c1..6f2674bb1b7f 100644
>
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>
> @@ -58,6 +58,15 @@ wifi_pwrseq: wifi_pwrseq {
>
> };
>
> };
>
>
> + {
>
> + status = "okay";
>
> +};
>
> +
>
> +_analog {
>
> + cpvdd-supply = <_eldo1>;
>
> + status = "okay";
>
> +};
>
> +
>
> {
>
> cpu-supply = <_dcdc2>;
>
> };
>
> @@ -74,6 +83,10 @@ {
>
> cpu-supply = <_dcdc2>;
>
> };
>
>
> + {
>
> + status = "okay";
>
> +};
>
> +
>
> {
>
> status = "okay";
>
> };
>
> @@ -328,6 +341,23 @@ _hdmi {
>
> vcc-hdmi-supply = <_dldo1>;
>
> };
>
>
> + {
>
> + simple-audio-card,aux-devs = <_analog>;
>
> + simple-audio-card,widgets = "Microphone", "Microphone Jack Left",
>
> + "Microphone", "Microphone Jack Right",
>
> + "Headphone", "Headphone Jack";
>
> + simple-audio-card,routing = "Left DAC", "DACL",
>
> + "Right DAC", "DACR",
>
> + "Headphone Jack", "HP",
>
> + "ADCL", "Left ADC",
>
> + "ADCR", "Right ADC",
>
> + "Microphone Jack Left", "MBIAS",
>
> + "MIC1", "Microphone Jack Left",
>
> + "Microphone Jack Left", "HBIAS",
>
> + "MIC2", "Microphone Jack Right";
>
> + status = "okay";
>
> +};
>
> +
>
> {
>
> pinctrl-names = "default";
>
> pinctrl-0 = <_pb_pins>;
>
> --
>
> 2.34.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/87654fd3-6007-6067-1851-7bc4b6de2f05%40inventati.org.
--
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/Yd6axIURzudUq5Ah%40plaes.org.
Re: [linux-sunxi] [PATCH v4 1/2] drm/sun4i: Add mode_set callback to the engine
On Fri, May 28, 2021 at 11:30:35PM +0300, Roman Stratiienko wrote:
> Create callback to allow updating engine's registers on mode change.
>
> Signed-off-by: Roman Stratiienko
> Reviewed-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 3 +++
> drivers/gpu/drm/sun4i/sunxi_engine.h | 12
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> index 45d9eb552d86..8f01a6b2bbef 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> @@ -146,6 +146,9 @@ static void sun4i_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
>
> sun4i_tcon_mode_set(scrtc->tcon, encoder, mode);
> +
> + if (scrtc->engine->ops->mode_set)
> + scrtc->engine->ops->mode_set(scrtc->engine, mode);
> }
>
> static const struct drm_crtc_helper_funcs sun4i_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h
> b/drivers/gpu/drm/sun4i/sunxi_engine.h
> index 548710a936d5..7faa844646ff 100644
> --- a/drivers/gpu/drm/sun4i/sunxi_engine.h
> +++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
> @@ -9,6 +9,7 @@
> struct drm_plane;
> struct drm_device;
> struct drm_crtc_state;
> +struct drm_display_mode;
>
> struct sunxi_engine;
>
> @@ -108,6 +109,17 @@ struct sunxi_engine_ops {
>* This function is optional.
>*/
> void (*vblank_quirk)(struct sunxi_engine *engine);
> +
> + /**
> + * @mode_set:
> + *
> + * This callback is used to update engine registers that
> + * responsible for display frame size and other mode attributes.
This sentence needs a little grammatical fixup.
> + *
> + * This function is optional.
> + */
> + void (*mode_set)(struct sunxi_engine *engine,
> + struct drm_display_mode *mode);
> };
>
> /**
> --
> 2.30.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/20210528203036.17999-2-r.stratiienko%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/20210531083812.GB7041%40plaes.org.
Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support
On Thu, Nov 19, 2020 at 10:54:42AM +, Andre Przywara wrote: > So far we did not support the BootROM based FEL USB debug mode on the > 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the > SPL runs in AArch64. > Returning back to AArch32 was not working as expected, since the RMR > reset into 32-bit mode always starts execution in the BootROM, but not > in the FEL routine. > > After some debug and research and with help via IRC, the CPU hotplug > mechanism emerged as a solution: If a certain R_CPUCFG register contains > some magic, the BootROM will immediately branch to an address stored in > some other register. This works well for our purposes. > > Enable the FEL feature by providing early AArch32 code to first save the > FEL state, *before* initially entering AArch64. > If we eventually determine that we should return to FEL, we reset back > into AArch32, and use the CPU hotplug mechanism to run some small > AArch32 code snippet that restores the initially saved FEL state. > > That allows the normal AArch64 SPL build to be loaded via the sunxi-fel > tool, with it returning into FEL mode, so that other payloads can be > transferred via FEL as well. > > Tested on A64, H5 and H6. For A64 (on Olimex A64-Olinuxino): Tested-by: Priit Laes Also writing down the command to run as it was not that obvious: $ sunxi-fel spl sunxi-spl.bin \ write 0x4a00 u-boot.bin \ write 0x44000 bl31.bin \ write 0x5 scp.bin \ reset64 0x44000 > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv8/Makefile | 2 + > arch/arm/cpu/armv8/fel_utils.S | 78 + > arch/arm/include/asm/arch-sunxi/boot0.h | 14 + > include/configs/sunxi-common.h | 2 - > 4 files changed, 94 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/cpu/armv8/fel_utils.S > > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile > index 93d26f98568..f7b4a5ee46c 100644 > --- a/arch/arm/cpu/armv8/Makefile > +++ b/arch/arm/cpu/armv8/Makefile > @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o > > ifndef CONFIG_SPL_BUILD > obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o > +else > +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o > endif > obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o > sec_firmware_asm.o > > diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S > new file mode 100644 > index 000..334fdef7fa0 > --- /dev/null > +++ b/arch/arm/cpu/armv8/fel_utils.S > @@ -0,0 +1,78 @@ > +/* > + * Utility functions for FEL mode, when running SPL in AArch64. > + * > + * Copyright (c) 2017 Arm Ltd. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > + > +/* > + * We don't overwrite save_boot_params() here, to save the FEL state upon > + * entry, since this would run *after* the RMR reset, which clobbers that > + * state. > + * Instead we store the state _very_ early in the boot0 hook, *before* > + * resetting to AArch64. > + */ > + > +/* > + * The FEL routines in BROM run in AArch32. > + * Reset back into 32-bit mode here and restore the saved FEL state > + * afterwards. > + * Resetting back into AArch32/EL3 using the RMR always enters the BROM, > + * but we can use the CPU hotplug mechanism to branch back to our code > + * immediately. > + */ > +ENTRY(return_to_fel) > + /* > + * the RMR reset will clear all registers, so save the arguments > + * (LR and SP) in the fel_stash structure, which we read anyways later > + */ > + adr x2, fel_stash > + str w0, [x2] > + str w1, [x2, #4] > + > + adr x1, fel_stash_addr // to find the fel_stash address in AA32 > + str w2, [x1] > + > + ldr x0, =0xfa50392f // CPU hotplug magic > +#ifndef CONFIG_MACH_SUN50I_H6 > + ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base > + str w0, [x2, #0x8] > +#else > + ldr x2, =(SUNXI_RTC_BASE + 0x1b8) // BOOT_CPU_HP_FLAG_REG > + str w0, [x2], #0x4 > +#endif > + adr x0, back_in_32 > + str w0, [x2] > + > + dsb sy > + isb sy > + mov x0, #2 // RMR reset into AArch32 > + dsb sy > + msr RMR_EL3, x0 > + isb sy > +1: wfi > + b 1b > + > +/* AArch32 code to restore the state from fel_stash and return back to FEL. > */ > +back_in_32: > + .word 0xe59f0028 // ldr r0, [pc, #40] ; load fel_stash address > + .word 0xe5901008
Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support
On Thu, Nov 19, 2020 at 10:54:42AM +, Andre Przywara wrote:
> So far we did not support the BootROM based FEL USB debug mode on the
> 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
> SPL runs in AArch64.
> Returning back to AArch32 was not working as expected, since the RMR
> reset into 32-bit mode always starts execution in the BootROM, but not
> in the FEL routine.
>
> After some debug and research and with help via IRC, the CPU hotplug
> mechanism emerged as a solution: If a certain R_CPUCFG register contains
> some magic, the BootROM will immediately branch to an address stored in
> some other register. This works well for our purposes.
>
> Enable the FEL feature by providing early AArch32 code to first save the
> FEL state, *before* initially entering AArch64.
> If we eventually determine that we should return to FEL, we reset back
> into AArch32, and use the CPU hotplug mechanism to run some small
> AArch32 code snippet that restores the initially saved FEL state.
>
> That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
> tool, with it returning into FEL mode, so that other payloads can be
> transferred via FEL as well.
>
> Tested on A64, H5 and H6.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/cpu/armv8/Makefile | 2 +
> arch/arm/cpu/armv8/fel_utils.S | 78 +
> arch/arm/include/asm/arch-sunxi/boot0.h | 14 +
> include/configs/sunxi-common.h | 2 -
> 4 files changed, 94 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/cpu/armv8/fel_utils.S
Don't you want to also update board/sunxi/README.sunxi64 ?
>
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index 93d26f98568..f7b4a5ee46c 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o
>
> ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
> +else
> +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o
> endif
> obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o
> sec_firmware_asm.o
>
> diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
> new file mode 100644
> index 000..334fdef7fa0
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fel_utils.S
> @@ -0,0 +1,78 @@
> +/*
> + * Utility functions for FEL mode, when running SPL in AArch64.
> + *
> + * Copyright (c) 2017 Arm Ltd.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * We don't overwrite save_boot_params() here, to save the FEL state upon
> + * entry, since this would run *after* the RMR reset, which clobbers that
> + * state.
> + * Instead we store the state _very_ early in the boot0 hook, *before*
> + * resetting to AArch64.
> + */
> +
> +/*
> + * The FEL routines in BROM run in AArch32.
> + * Reset back into 32-bit mode here and restore the saved FEL state
> + * afterwards.
> + * Resetting back into AArch32/EL3 using the RMR always enters the BROM,
> + * but we can use the CPU hotplug mechanism to branch back to our code
> + * immediately.
> + */
> +ENTRY(return_to_fel)
> + /*
> + * the RMR reset will clear all registers, so save the arguments
> + * (LR and SP) in the fel_stash structure, which we read anyways later
> + */
> + adr x2, fel_stash
> + str w0, [x2]
> + str w1, [x2, #4]
> +
> + adr x1, fel_stash_addr // to find the fel_stash address in AA32
> + str w2, [x1]
> +
> + ldr x0, =0xfa50392f // CPU hotplug magic
> +#ifndef CONFIG_MACH_SUN50I_H6
> + ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
> + str w0, [x2, #0x8]
> +#else
> + ldr x2, =(SUNXI_RTC_BASE + 0x1b8) // BOOT_CPU_HP_FLAG_REG
> + str w0, [x2], #0x4
> +#endif
> + adr x0, back_in_32
> + str w0, [x2]
> +
> + dsb sy
> + isb sy
> + mov x0, #2 // RMR reset into AArch32
> + dsb sy
> + msr RMR_EL3, x0
> + isb sy
> +1: wfi
> + b 1b
> +
> +/* AArch32 code to restore the state from fel_stash and return back to FEL.
> */
> +back_in_32:
> + .word 0xe59f0028 // ldr r0, [pc, #40] ; load fel_stash address
> + .word 0xe5901008 // ldr r1, [r0, #8]
> + .word 0xe129f001 // msr CPSR_fc, r1
> + .word 0xf57ff06f // isb
> + .word 0xe590d000 // ldr sp, [r0]
> + .word 0xe590e004 // ldr lr, [r0, #4]
> + .word 0xe5901010 // ldr r1, [r0, #16]
> + .word 0xee0c1f10 // mcr 15, 0, r1, cr12, cr0, {0} ; VBAR
> + .word 0xe590100c // ldr r1, [r0, #12]
> + .word 0xee011f10 // mcr 15, 0, r1, cr1, cr0, {0} ; SCTLR
> + .word 0xf57ff06f // isb
> + .word 0xe12fff1e // bx lr ; return to FEL
>
Re: [linux-sunxi] A20 mainline kernel 5.8.0 - some GPIO ports does not works
On Thu, Jul 09, 2020 at 02:38:17PM -0700, Milos Ladni wrote: > Hi, thank you very much! > > It works now. I totally forgot to enable ldo3 and ldo4:) > I am using my custom board and i want to migrate from legacy 3.4 to > mainline. Sample patch for Olimex Lime2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd42ca0515d3952fc78a591618d57dd54f881d1f > > Thanks, > Milos > > четвртак, 09. јул 2020. 19.06.05 UTC+2, Chen-Yu Tsai је написао/ла: > > > > Hi, > > > > On Fri, Jul 10, 2020 at 12:51 AM Milos Ladni > > wrote: > > > > > > Hi, > > > > > > I am using mainline kernel on my A20 board and can not get GPIO working > > for some ports. > > > I tested them through standard sysfs and for pin number id i used next : > > (position of letter in alphabet - 1) * 32 + pin number > > > I tried with PE0, PE1, PE2, and PE4, i think that whole PE port does not > > work. Pin is exported in /sys/class/gpioX and direction is set to 'out' but > > when i write 1 or 0 to value nothing happens (actually it changed value for > > 0.2~0.4V between logical 0 and 1). Pin numbers for that port was > > (5-1)*32+pinNumber => 128 + pinNumber. > > > In dtsi for A20 port E is by default intendent for CSI0 but CSI0 is not > > enabled in my case and i also tried to completly remove SCI0 from linux > > kernel and comment pin confiruration for CSI0 in dtsi file but it still > > does not works. > > > I noticed this issue because i use LVDS display and my display standby > > pin is connected to PE2. > > > After system is started i can login normally. After ~10 seconds i can > > see only this message in dmesg: > > > > > > [ 27.180481] random: crng init done > > > [ 31.896048] vcc3v0: disabling > > > [ 31.899038] vcc5v0: disabling > > > [ 31.902015] ldo3: disabling > > > [ 31.905150] ldo4: disabling > > > [ 31.908346] ahci-5v: disabling > > > [ 31.911416] usb0-vbus: disabling > > > [ 31.914644] usb1-vbus: disabling > > > > > > After this message PE2 goes to LOW and never come back to HIGH level. > > > I also tried to completelly remove my LVDS display and i got the same > > behavior for all pins on PE port. > > > I also tried to connect PE2 to pull-up 3V3 through 10k resistor but > > without success. After ~30 seconds after i turn on device PE2 goes LOW > > forever. > > > Interesting part is that when it is HIGH it is 2.8, not 3.3V. Maybe i > > missed some configuration in dts file. > > > > What board are you using? > > > > Any board based on Allwinner's reference design will use one of the > > LDOs at 2.8V to power the > > PE and PG pin groups. This is because the two pingroups are almost > > exclusively used for camera > > sensors, which a lot of use 2.8V I/O levels. Now if you don't have > > power for the pingroups, > > i.e. the LDOs are off, then of course the pins don't work. > > > > First check your schematics to see if that's the case. Then you need > > to properly wire up > > pin power supplies using the vcc-pX-supply properties in the pinctrl > > node. See other newer > > boards for how that works. > > > > ChenYu > > > > > Also tried PG1 and does not works. > > > Tried PH18, PH21 and it works. > > > Tried PB14 and it works. > > > Another ports i did not tried. > > > > > > Interesting part is that because i enegled gpio debug in kernel setup i > > always get message "gpio gpiochip0: Persistence not supported for GPIO XXX" > > does not matter if if it is PE port which does not work or PH port which > > works. > > > > > > Can someone check this issue or check my dts files? > > > > > > Thank you, > > > Milos Ladicorbic > > > > > > -- > > > 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...@googlegroups.com . > > > To view this discussion on the web, visit > > https://groups.google.com/d/msgid/linux-sunxi/3526d3a3-64ae-403c-9fa1-8507bfd693f1o%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/da353c0a-2623-401e-816d-d1956b866aa5o%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/20200710060640.GA24608%40plaes.org.
Re: [linux-sunxi] Boot to FEL mode with fastboot or adb shell
On Tue, May 26, 2020 at 03:21:45PM -0700, Matt Krenik wrote: > I'm trying to write a script that can entirely flash an image onto my > device (A64) using the USB and without needing press any buttons or a > serial port. I have read through the FEL page several times and it seems > like the only option to do this is if all of the other boot options fail. > Is there a way that I can overwrite or corrupt the bootloader partition > from the adb shell or with a fastboot command so that it will fail on the > next reboot and enter FEL mode? What kind of storage does your device use and how is it mapped (aka if it's eMMC then on which pins it is mapped). This is how I am doing it for eMMC-based device 0. (In case bootloader is already flashed) - Insert the fel-sdboot formatted sdcard (search from wiki) that puts device in FEL mode. 1. Connect USB and load uboot via FEL to put device into fastboot mode $ cat my.env #=uEnv bootcmd=fastboot usb 0 $ sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x4310 my.env 2. Now device should end up in fastboot mode $ fastboot oem format 3. Reboot the device (should end up in FEL mode because fel-sdboot sdcard) $ fastboot reboot 4. Another boot into fastboot mode $ sunxi-fel uboot u-boot-sunxi-with-spl.bin write 0x4310 my.env 5. Do the flashing $ fastboot flash loader1 sunxi-spl.bin $ fastboot flash loader2 u-boot.img $ fastboot flash esp esp.img $ fastboot flash system system.img > -- > 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/d602bb08-e8c6-49c3-a4fd-3425e262621c%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/20200619062928.GC18663%40plaes.org.
[linux-sunxi] [PATCH v3 2/6] clk: sunxi-ng: a31: Register regmap for sun6i CCU
On sun6i, the gmac clock is handled by the dwmac-sunxi driver, but
its configuration register is located in the CCU register range,
requiring proper regmap setup.
In order to do that, we use CLK_OF_DECLARE_DRIVER to initialize
sun7i ccu, which clears the OF_POPULATED flag, allowing the
platform device to probe the same resource with device node.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 62 +++-
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 9b40d53266a3..3f6f9824b2ca 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include "ccu_common.h"
#include "ccu_reset.h"
@@ -1262,5 +1264,61 @@ static void __init sun6i_a31_ccu_setup(struct
device_node *node)
ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
_a31_cpu_nb);
}
-CLK_OF_DECLARE(sun6i_a31_ccu, "allwinner,sun6i-a31-ccu",
- sun6i_a31_ccu_setup);
+CLK_OF_DECLARE_DRIVER(sun6i_a31_ccu, "allwinner,sun6i-a31-ccu",
+ sun6i_a31_ccu_setup);
+
+/*
+ * Regmap for the GMAC driver (dwmac-sunxi) to allow access to
+ * GMAC configuration register.
+ */
+#define SUN6I_A31_GMAC_CFG_REG 0xD0
+static bool sun6i_a31_ccu_regmap_accessible_reg(struct device *dev,
+ unsigned int reg)
+{
+ if (reg == SUN6I_A31_GMAC_CFG_REG)
+ return true;
+ return false;
+}
+
+static struct regmap_config sun6i_a31_ccu_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x308, /* clk_out_b */
+
+ .readable_reg = sun6i_a31_ccu_regmap_accessible_reg,
+ .writeable_reg = sun6i_a31_ccu_regmap_accessible_reg,
+};
+
+static int sun6i_a31_ccu_probe_regmap(struct platform_device *pdev)
+{
+ void __iomem *reg;
+ struct resource *res;
+ struct regmap *regmap;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap(>dev, res->start, resource_size(res));
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ regmap = devm_regmap_init_mmio(>dev, reg,
+ _a31_ccu_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return 0;
+}
+
+static const struct of_device_id sun6i_a31_ccu_ids[] = {
+ { .compatible = "allwinner,sun6i-a31-ccu"},
+ { }
+};
+
+static struct platform_driver sun6i_a31_ccu_driver = {
+ .probe = sun6i_a31_ccu_probe_regmap,
+ .driver = {
+ .name = "sun6i-a31-ccu",
+ .of_match_table = sun6i_a31_ccu_ids,
+ },
+};
+builtin_platform_driver(sun6i_a31_ccu_driver);
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200430115702.5768-3-plaes%40plaes.org.
[linux-sunxi] [PATCH v3 5/6] ARM: dts: sun7i: Use syscon-based implementation for gmac
Use syscon-based approach to access gmac clock configuration
register, instead of relying on a custom clock driver.
As a bonus, we can now drop the custom clock implementation
and dummy clocks making sun7i fully CCU-compatible.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20.dtsi | 36 +++-
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index ffe1d10a1a84..750962a94fad 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -219,37 +219,6 @@ osc32k: clk-32k {
clock-frequency = <32768>;
clock-output-names = "osc32k";
};
-
- /*
-* The following two are dummy clocks, placeholders
-* used in the gmac_tx clock. The gmac driver will
-* choose one parent depending on the PHY interface
-* mode, using clk_set_rate auto-reparenting.
-*
-* The actual TX clock rate is not controlled by the
-* gmac_tx clock.
-*/
- mii_phy_tx_clk: clk-mii-phy-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <2500>;
- clock-output-names = "mii_phy_tx";
- };
-
- gmac_int_tx_clk: clk-gmac-int-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "gmac_int_tx";
- };
-
- gmac_tx_clk: clk@1c20164 {
- #clock-cells = <0>;
- compatible = "allwinner,sun7i-a20-gmac-clk";
- reg = <0x01c20164 0x4>;
- clocks = <_phy_tx_clk>, <_int_tx_clk>;
- clock-output-names = "gmac_tx";
- };
};
@@ -1511,11 +1480,12 @@ mali: gpu@1c4 {
gmac: ethernet@1c5 {
compatible = "allwinner,sun7i-a20-gmac";
+ syscon = <>;
reg = <0x01c5 0x1>;
interrupts = ;
interrupt-names = "macirq";
- clocks = < CLK_AHB_GMAC>, <_tx_clk>;
- clock-names = "stmmaceth", "allwinner_gmac_tx";
+ clocks = < CLK_AHB_GMAC>;
+ clock-names = "stmmaceth";
snps,pbl = <2>;
snps,fixed-burst;
snps,force_sf_dma_mode;
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200430115702.5768-6-plaes%40plaes.org.
[linux-sunxi] [PATCH v3 4/6] dt-bindings: net: sun7i-gmac: Add syscon support
Now that driver supports syscon-based regmap access, document also the
devicetree binding.
Signed-off-by: Priit Laes
---
.../bindings/net/allwinner,sun7i-a20-gmac.yaml| 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 703d0d886884..c41d7c598c19 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -29,17 +29,26 @@ properties:
clocks:
items:
- description: GMAC main clock
+
+ # Deprecated
- description: TX clock
clock-names:
items:
- const: stmmaceth
+
+ # Deprecated
- const: allwinner_gmac_tx
phy-supply:
description:
PHY regulator
+ syscon:
+$ref: /schemas/types.yaml#definitions/phandle
+description:
+ Phandle to the device containing the GMAC clock register
+
required:
- compatible
- reg
@@ -48,6 +57,7 @@ required:
- clocks
- clock-names
- phy-mode
+ - syscon
unevaluatedProperties: false
@@ -55,11 +65,12 @@ examples:
- |
gmac: ethernet@1c5 {
compatible = "allwinner,sun7i-a20-gmac";
+syscon = <>;
reg = <0x01c5 0x1>;
interrupts = <0 85 1>;
interrupt-names = "macirq";
-clocks = <_gates 49>, <_tx>;
-clock-names = "stmmaceth", "allwinner_gmac_tx";
+clocks = <_gates 49>;
+clock-names = "stmmaceth";
phy-mode = "mii";
};
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200430115702.5768-5-plaes%40plaes.org.
[linux-sunxi] [PATCH v2 0/6] ARM: sunxi: Clean up sun7i-a20-gmac-clk usage
This serie implements syscon-based regmap access to dwmac-sunxi driver, allowing to deprecate the allwinner,sun7i-a20-gmac-clk clock driver. In order to register regmap, we firstly need to change existing clock setups (sun7i-a20 and sun6i-a31) from CLK_OF_DECLARE to CLK_OF_DECLARE_DRIVER to allow probing the same driver again via the platform driver framework. This patchset touches 3 areas: - sun7i and sun6i CCUs now set up regmap to allow dwmac-sunxi driver to access GMAC clock register. - dwmac-sunxi can now handle syscon-based clock register to handle its own clock. - sun7i and sun6i devicetrees are converted to use the new syscon-based access. After this patchset: - sun7i-a20 works fully without legacy sunxi clocks (CLK_SUNXI) - only sun9i-a80 SoC remains as a single sun7i-a20-gmac-clk user. Please note that sun6i-a31 changes are only build-tested, as I lack the hardware to test this. Changes since v2: * Fix broken sun6i-a31 CCU patch. * Rename series to "Clean up sun7i-a20-gmac-clk usage" Changes since v1: * Use CLK_OF_DECLARE_DRIVER to make it possible to probe again and set up regmap using platform device probe. * Clarify the meaning of "legacy" in dwmac-sunxi driver. * Make sure we don't mess with the RX/TX delay settings when updating clock registers. * Update devicetree bindings * Add sun6i-A31 support. (not tested due to lack of hardware) Priit Laes (6): clk: sunxi-ng: a20: Register regmap for sun7i CCU clk: sunxi-ng: a31: Register regmap for sun6i CCU net: stmmac: dwmac-sunxi: Implement syscon-based clock handling dt-bindings: net: sun7i-gmac: Add syscon support ARM: dts: sun7i: Use syscon-based implementation for gmac ARM: dts: sun6i: Use syscon-based implementation for gmac .../net/allwinner,sun7i-a20-gmac.yaml | 15 +- arch/arm/boot/dts/sun6i-a31.dtsi | 35 + arch/arm/boot/dts/sun7i-a20.dtsi | 36 + drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 62 - drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 62 - .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 130 -- 6 files changed, 261 insertions(+), 79 deletions(-) -- 2.26.2 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200430115702.5768-1-plaes%40plaes.org.
[linux-sunxi] [PATCH v3 1/6] clk: sunxi-ng: a20: Register regmap for sun7i CCU
On sun7i, the gmac clock is handled by the dwmac-sunxi driver, but
its configuration register is located in the CCU register range,
requiring proper regmap setup.
In order to do that, we use CLK_OF_DECLARE_DRIVER to initialize
sun7i ccu, which clears the OF_POPULATED flag, allowing the
platform device to probe the same resource with proper device node.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 62 +++-
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
index f32366d9336e..fa147b8ce705 100644
--- a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
+++ b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "ccu_common.h"
#include "ccu_reset.h"
@@ -1478,5 +1480,61 @@ static void __init sun7i_a20_ccu_setup(struct
device_node *node)
{
sun4i_ccu_init(node, _a20_ccu_desc);
}
-CLK_OF_DECLARE(sun7i_a20_ccu, "allwinner,sun7i-a20-ccu",
- sun7i_a20_ccu_setup);
+CLK_OF_DECLARE_DRIVER(sun7i_a20_ccu, "allwinner,sun7i-a20-ccu",
+ sun7i_a20_ccu_setup);
+
+/*
+ * Regmap for the GMAC driver (dwmac-sunxi) to allow access to
+ * GMAC configuration register.
+ */
+#define SUN7I_A20_GMAC_CFG_REG 0x164
+static bool sun7i_a20_ccu_regmap_accessible_reg(struct device *dev,
+ unsigned int reg)
+{
+ if (reg == SUN7I_A20_GMAC_CFG_REG)
+ return true;
+ return false;
+}
+
+static struct regmap_config sun7i_a20_ccu_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x1f4, /* clk_out_b */
+
+ .readable_reg = sun7i_a20_ccu_regmap_accessible_reg,
+ .writeable_reg = sun7i_a20_ccu_regmap_accessible_reg,
+};
+
+static int sun7i_a20_ccu_probe_regmap(struct platform_device *pdev)
+{
+ void __iomem *reg;
+ struct resource *res;
+ struct regmap *regmap;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap(>dev, res->start, resource_size(res));
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ regmap = devm_regmap_init_mmio(>dev, reg,
+ _a20_ccu_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return 0;
+}
+
+static const struct of_device_id sun7i_a20_ccu_ids[] = {
+ { .compatible = "allwinner,sun7i-a20-ccu"},
+ { }
+};
+
+static struct platform_driver sun7i_a20_ccu_driver = {
+ .probe = sun7i_a20_ccu_probe_regmap,
+ .driver = {
+ .name = "sun7i-a20-ccu",
+ .of_match_table = sun7i_a20_ccu_ids,
+ },
+};
+builtin_platform_driver(sun7i_a20_ccu_driver);
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200430115702.5768-2-plaes%40plaes.org.
[linux-sunxi] [PATCH v3 3/6] net: stmmac: dwmac-sunxi: Implement syscon-based clock handling
Convert the sun7i-gmac driver to use a regmap-based driver,
instead of relying on the custom clock implementation.
This allows to get rid of the last custom clock in the sun7i
device tree making the sun7i fully CCU-compatible.
Compatibility with existing devicetrees is retained.
Signed-off-by: Priit Laes
---
.../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 130 --
1 file changed, 122 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
index 0e1ca2cba3c7..206398f7a2af 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -12,8 +12,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include "stmmac_platform.h"
@@ -22,11 +25,23 @@ struct sunxi_priv_data {
int clk_enabled;
struct clk *tx_clk;
struct regulator *regulator;
+ struct regmap_field *regmap_field;
+};
+
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field ccu_reg_field = {
+ .reg = 0x164,
+ .lsb = 0,
+ .msb = 31,
};
#define SUN7I_GMAC_GMII_RGMII_RATE 12500
#define SUN7I_GMAC_MII_RATE2500
+#define SUN7I_A20_CLK_MASK GENMASK(2, 0)
+#define SUN7I_A20_RGMII_CLK(BIT(2) | BIT(1))
+#define SUN7I_A20_MII_CLK 0
+
static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
{
struct sunxi_priv_data *gmac = priv;
@@ -38,7 +53,20 @@ static int sun7i_gmac_init(struct platform_device *pdev,
void *priv)
return ret;
}
- /* Set GMAC interface port mode
+ if (gmac->regmap_field) {
+ if (phy_interface_mode_is_rgmii(gmac->interface)) {
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK,
+SUN7I_A20_RGMII_CLK);
+ return clk_prepare_enable(gmac->tx_clk);
+ }
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK,
+SUN7I_A20_MII_CLK);
+ return clk_enable(gmac->tx_clk);
+ }
+
+ /* Legacy devicetree clock (allwinner,sun7i-a20-gmac-clk) support:
*
* The GMAC TX clock lines are configured by setting the clock
* rate, which then uses the auto-reparenting feature of the
@@ -62,9 +90,16 @@ static void sun7i_gmac_exit(struct platform_device *pdev,
void *priv)
{
struct sunxi_priv_data *gmac = priv;
- if (gmac->clk_enabled) {
+ if (gmac->regmap_field) {
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK, 0);
clk_disable(gmac->tx_clk);
- gmac->clk_enabled = 0;
+ } else {
+ /* Handle legacy devicetree clock (sun7i-a20-gmac-clk) */
+ if (gmac->clk_enabled) {
+ clk_disable(gmac->tx_clk);
+ gmac->clk_enabled = 0;
+ }
}
clk_unprepare(gmac->tx_clk);
@@ -72,10 +107,55 @@ static void sun7i_gmac_exit(struct platform_device *pdev,
void *priv)
regulator_disable(gmac->regulator);
}
+static struct regmap *sun7i_gmac_get_syscon_from_dev(struct device_node *node)
+{
+ struct device_node *syscon_node;
+ struct platform_device *syscon_pdev;
+ struct regmap *regmap = NULL;
+
+ syscon_node = of_parse_phandle(node, "syscon", 0);
+ if (!syscon_node)
+ return ERR_PTR(-ENODEV);
+
+ syscon_pdev = of_find_device_by_node(syscon_node);
+ if (!syscon_pdev) {
+ /* platform device might not be probed yet */
+ regmap = ERR_PTR(-EPROBE_DEFER);
+ goto out_put_node;
+ }
+
+ /* If no regmap is found then the other device driver is at fault */
+ regmap = dev_get_regmap(_pdev->dev, NULL);
+ if (!regmap)
+ regmap = ERR_PTR(-EINVAL);
+
+ platform_device_put(syscon_pdev);
+out_put_node:
+ of_node_put(syscon_node);
+ return regmap;
+}
+
static void sun7i_fix_speed(void *priv, unsigned int speed)
{
struct sunxi_priv_data *gmac = priv;
+ if (gmac->regmap_field) {
+ clk_disable(gmac->tx_clk);
+ clk_unprepare(gmac->tx_clk);
+ if (speed == 1000)
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK,
+SUN7I_A20_RGMII_CLK);
+
[linux-sunxi] [PATCH v3 6/6] ARM: dts: sun6i: Use syscon-based implementation for gmac
Use syscon-based approach to access gmac clock configuration
register instead of relying on a custom clock driver.
As a bonus, we can now drop the custom clock implementation
and the dummy clocks.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun6i-a31.dtsi | 35 +++-
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index f3425a66fc0a..fcf8a242741f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -228,36 +228,6 @@ osc32k: clk-32k {
clock-output-names = "ext_osc32k";
};
- /*
-* The following two are dummy clocks, placeholders
-* used in the gmac_tx clock. The gmac driver will
-* choose one parent depending on the PHY interface
-* mode, using clk_set_rate auto-reparenting.
-*
-* The actual TX clock rate is not controlled by the
-* gmac_tx clock.
-*/
- mii_phy_tx_clk: clk-mii-phy-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <2500>;
- clock-output-names = "mii_phy_tx";
- };
-
- gmac_int_tx_clk: clk-gmac-int-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "gmac_int_tx";
- };
-
- gmac_tx_clk: clk@1c200d0 {
- #clock-cells = <0>;
- compatible = "allwinner,sun7i-a20-gmac-clk";
- reg = <0x01c200d0 0x4>;
- clocks = <_phy_tx_clk>, <_int_tx_clk>;
- clock-output-names = "gmac_tx";
- };
};
de: display-engine {
@@ -943,11 +913,12 @@ i2c3: i2c@1c2b800 {
gmac: ethernet@1c3 {
compatible = "allwinner,sun7i-a20-gmac";
+ syscon = <>;
reg = <0x01c3 0x1054>;
interrupts = ;
interrupt-names = "macirq";
- clocks = < CLK_AHB1_EMAC>, <_tx_clk>;
- clock-names = "stmmaceth", "allwinner_gmac_tx";
+ clocks = < CLK_AHB1_EMAC>;
+ clock-names = "stmmaceth";
resets = < RST_AHB1_EMAC>;
reset-names = "stmmaceth";
snps,pbl = <2>;
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200430115702.5768-7-plaes%40plaes.org.
[linux-sunxi] Re: [PATCH v2 2/6] clk: sunxi-ng: a31: Register regmap for sun6i CCU
On Wed, Apr 29, 2020 at 11:46:08PM +0300, Priit Laes wrote:
I somehow messed up this patch when preparing the patchset,
so I'll resend the fixed patch with v3.
> On sun6i, the gmac clock is handled by the dwmac-sunxi driver, but
> its configuration register is located in the CCU register range,
> requiring proper regmap setup.
>
> In order to do that, we use CLK_OF_DECLARE_DRIVER to initialize
> sun7i ccu, which clears the OF_POPULATED flag, allowing the
> platform device to probe the same resource with device node.
>
> Signed-off-by: Priit Laes
> ---
> drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 60 +++-
> 1 file changed, 58 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> index 9b40d53266a3..086eb93a4efd 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> @@ -1262,5 +1262,61 @@ static void __init sun6i_a31_ccu_setup(struct
> device_node *node)
> ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
> _a31_cpu_nb);
> }
> -CLK_OF_DECLARE(sun6i_a31_ccu, "allwinner,sun6i-a31-ccu",
> -sun6i_a31_ccu_setup);
> +CLK_OF_DECLARE_DRIVER(sun6i_a31_ccu, "allwinner,sun6i-a31-ccu",
> + sun6i_a31_ccu_setup);
> +
> +/*
> + * Regmap for the GMAC driver (dwmac-sunxi) to allow access to
> + * GMAC configuration register.
> + */
> +#define SUN6I_A31_GMAC_CFG_REG 0xD0
> +static bool sun6i_a31_ccu_regmap_accessible_reg(struct device *dev,
> + unsigned int reg)
> +{
> + if (reg == SUN6I_A31_GMAC_CFG_REG)
> + return true;
> + return false;
> +}
> +
> +static struct regmap_config sun6i_a31_ccu_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x308, /* clk_out_b */
> +
> + .readable_reg = sun6i_a31_ccu_regmap_accessible_reg,
> + .writeable_reg = sun6i_a31_ccu_regmap_accessible_reg,
> +};
> +
> +static int sun6i_a31_ccu_probe_regmap(struct platform_device *pdev)
> +{
> + void __iomem *reg;
> + struct resource *res;
> + struct regmap *regmap;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reg = devm_ioremap(>dev, res->start, resource_size(res));
> + if (IS_ERR(reg))
> + return PTR_ERR(reg);
> +
> + regmap = devm_regmap_init_mmio(>dev, reg,
> +_a31_ccu_regmap_accessible_reg);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id sun6i_a31_ccu_ids[] = {
> + { .compatible = "allwinner,sun6i-a31-ccu"},
> + { }
> +};
> +
> +static struct platform_driver sun6i_a31_ccu_driver = {
> + .probe = sun6i_a31_ccu_probe_regmap,
> + .driver = {
> + .name = "sun6i-a31-ccu",
> + .of_match_table = sun6i_a31_ccu_ids,
> + },
> +};
> +builtin_platform_driver(sun6i_a31_ccu_driver);
> --
> 2.26.2
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200430111036.GB32281%40plaes.org.
[linux-sunxi] Re: [PATCH 1/4] clk: sunxi-ng: a10/a20: rewrite init code to a platform driver
On Wed, Apr 29, 2020 at 04:35:10PM +0200, Maxime Ripard wrote: > Hi, > > On Mon, Apr 20, 2020 at 08:32:28PM +0000, Priit Laes wrote: > > On Mon, Apr 20, 2020 at 02:49:35PM +0200, Maxime Ripard wrote: > > > On Sat, Apr 18, 2020 at 01:17:27AM +0300, Priit Laes wrote: > > > > In order to register regmap for sun7i CCU, there needs to be > > > > a device structure already bound to the CCU device node. > > > > > > > > Convert the sun4i/sun7i CCU setup to platform driver to use > > > > it later as platform device. > > > > > > > > Signed-off-by: Priit Laes > > > > > > You can't relly do that though. We have timers that need those clocks > > > before the > > > device model is initialized. > > > > Ok, I'm somewhat lost now... are these the affected timers on sun7i > > following: > > - allwinner,sun4i-a10-timer (timer@1c20c00) > > - allwinner,sun7i-a20-hstimer (hstimer@1c6) > > Yep > > > Any ideas on what approach I could actually use? > > I guess you could keep the CLK_OF_DECLARE registration, and then have a > platform_driver probe and register the regmap? > Thanks this did the trick. > > Also, similar timer dependency would affect then sun6i-a31 and sun9i-a80 > > platforms too... I didn't check this before, but sun9i-a80 CCU is initialized currently via platform device. Should it be converted first to clock driver (CLK_OF_DECLARE)? I have sent out the v2 which contains sun7i/sun6i changes. > > Indeed. > > 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/20200430062137.GA32281%40plaes.org.
[linux-sunxi] [PATCH v2 4/6] dt-bindings: net: sun7i-gmac: Add syscon support
Now that driver supports syscon-based regmap access, document also the
devicetree binding.
Signed-off-by: Priit Laes
---
.../bindings/net/allwinner,sun7i-a20-gmac.yaml| 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 703d0d886884..c41d7c598c19 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -29,17 +29,26 @@ properties:
clocks:
items:
- description: GMAC main clock
+
+ # Deprecated
- description: TX clock
clock-names:
items:
- const: stmmaceth
+
+ # Deprecated
- const: allwinner_gmac_tx
phy-supply:
description:
PHY regulator
+ syscon:
+$ref: /schemas/types.yaml#definitions/phandle
+description:
+ Phandle to the device containing the GMAC clock register
+
required:
- compatible
- reg
@@ -48,6 +57,7 @@ required:
- clocks
- clock-names
- phy-mode
+ - syscon
unevaluatedProperties: false
@@ -55,11 +65,12 @@ examples:
- |
gmac: ethernet@1c5 {
compatible = "allwinner,sun7i-a20-gmac";
+syscon = <>;
reg = <0x01c5 0x1>;
interrupts = <0 85 1>;
interrupt-names = "macirq";
-clocks = <_gates 49>, <_tx>;
-clock-names = "stmmaceth", "allwinner_gmac_tx";
+clocks = <_gates 49>;
+clock-names = "stmmaceth";
phy-mode = "mii";
};
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200429204612.31883-5-plaes%40plaes.org.
[linux-sunxi] [PATCH v2 6/6] ARM: dts: sun6i: Use syscon-based implementation for gmac
Use syscon-based approach to access gmac clock configuration
register instead of relying on a custom clock driver.
As a bonus, we can now drop the custom clock implementation
and the dummy clocks.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun6i-a31.dtsi | 35 +++-
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index f3425a66fc0a..fcf8a242741f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -228,36 +228,6 @@ osc32k: clk-32k {
clock-output-names = "ext_osc32k";
};
- /*
-* The following two are dummy clocks, placeholders
-* used in the gmac_tx clock. The gmac driver will
-* choose one parent depending on the PHY interface
-* mode, using clk_set_rate auto-reparenting.
-*
-* The actual TX clock rate is not controlled by the
-* gmac_tx clock.
-*/
- mii_phy_tx_clk: clk-mii-phy-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <2500>;
- clock-output-names = "mii_phy_tx";
- };
-
- gmac_int_tx_clk: clk-gmac-int-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "gmac_int_tx";
- };
-
- gmac_tx_clk: clk@1c200d0 {
- #clock-cells = <0>;
- compatible = "allwinner,sun7i-a20-gmac-clk";
- reg = <0x01c200d0 0x4>;
- clocks = <_phy_tx_clk>, <_int_tx_clk>;
- clock-output-names = "gmac_tx";
- };
};
de: display-engine {
@@ -943,11 +913,12 @@ i2c3: i2c@1c2b800 {
gmac: ethernet@1c3 {
compatible = "allwinner,sun7i-a20-gmac";
+ syscon = <>;
reg = <0x01c3 0x1054>;
interrupts = ;
interrupt-names = "macirq";
- clocks = < CLK_AHB1_EMAC>, <_tx_clk>;
- clock-names = "stmmaceth", "allwinner_gmac_tx";
+ clocks = < CLK_AHB1_EMAC>;
+ clock-names = "stmmaceth";
resets = < RST_AHB1_EMAC>;
reset-names = "stmmaceth";
snps,pbl = <2>;
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200429204612.31883-7-plaes%40plaes.org.
[linux-sunxi] [PATCH v2 3/6] net: stmmac: dwmac-sunxi: Implement syscon-based clock handling
Convert the sun7i-gmac driver to use a regmap-based driver,
instead of relying on the custom clock implementation.
This allows to get rid of the last custom clock in the sun7i
device tree making the sun7i fully CCU-compatible.
Compatibility with existing devicetrees is retained.
Signed-off-by: Priit Laes
---
.../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 130 --
1 file changed, 122 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
index 0e1ca2cba3c7..206398f7a2af 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -12,8 +12,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include "stmmac_platform.h"
@@ -22,11 +25,23 @@ struct sunxi_priv_data {
int clk_enabled;
struct clk *tx_clk;
struct regulator *regulator;
+ struct regmap_field *regmap_field;
+};
+
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field ccu_reg_field = {
+ .reg = 0x164,
+ .lsb = 0,
+ .msb = 31,
};
#define SUN7I_GMAC_GMII_RGMII_RATE 12500
#define SUN7I_GMAC_MII_RATE2500
+#define SUN7I_A20_CLK_MASK GENMASK(2, 0)
+#define SUN7I_A20_RGMII_CLK(BIT(2) | BIT(1))
+#define SUN7I_A20_MII_CLK 0
+
static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
{
struct sunxi_priv_data *gmac = priv;
@@ -38,7 +53,20 @@ static int sun7i_gmac_init(struct platform_device *pdev,
void *priv)
return ret;
}
- /* Set GMAC interface port mode
+ if (gmac->regmap_field) {
+ if (phy_interface_mode_is_rgmii(gmac->interface)) {
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK,
+SUN7I_A20_RGMII_CLK);
+ return clk_prepare_enable(gmac->tx_clk);
+ }
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK,
+SUN7I_A20_MII_CLK);
+ return clk_enable(gmac->tx_clk);
+ }
+
+ /* Legacy devicetree clock (allwinner,sun7i-a20-gmac-clk) support:
*
* The GMAC TX clock lines are configured by setting the clock
* rate, which then uses the auto-reparenting feature of the
@@ -62,9 +90,16 @@ static void sun7i_gmac_exit(struct platform_device *pdev,
void *priv)
{
struct sunxi_priv_data *gmac = priv;
- if (gmac->clk_enabled) {
+ if (gmac->regmap_field) {
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK, 0);
clk_disable(gmac->tx_clk);
- gmac->clk_enabled = 0;
+ } else {
+ /* Handle legacy devicetree clock (sun7i-a20-gmac-clk) */
+ if (gmac->clk_enabled) {
+ clk_disable(gmac->tx_clk);
+ gmac->clk_enabled = 0;
+ }
}
clk_unprepare(gmac->tx_clk);
@@ -72,10 +107,55 @@ static void sun7i_gmac_exit(struct platform_device *pdev,
void *priv)
regulator_disable(gmac->regulator);
}
+static struct regmap *sun7i_gmac_get_syscon_from_dev(struct device_node *node)
+{
+ struct device_node *syscon_node;
+ struct platform_device *syscon_pdev;
+ struct regmap *regmap = NULL;
+
+ syscon_node = of_parse_phandle(node, "syscon", 0);
+ if (!syscon_node)
+ return ERR_PTR(-ENODEV);
+
+ syscon_pdev = of_find_device_by_node(syscon_node);
+ if (!syscon_pdev) {
+ /* platform device might not be probed yet */
+ regmap = ERR_PTR(-EPROBE_DEFER);
+ goto out_put_node;
+ }
+
+ /* If no regmap is found then the other device driver is at fault */
+ regmap = dev_get_regmap(_pdev->dev, NULL);
+ if (!regmap)
+ regmap = ERR_PTR(-EINVAL);
+
+ platform_device_put(syscon_pdev);
+out_put_node:
+ of_node_put(syscon_node);
+ return regmap;
+}
+
static void sun7i_fix_speed(void *priv, unsigned int speed)
{
struct sunxi_priv_data *gmac = priv;
+ if (gmac->regmap_field) {
+ clk_disable(gmac->tx_clk);
+ clk_unprepare(gmac->tx_clk);
+ if (speed == 1000)
+ regmap_field_update_bits(gmac->regmap_field,
+SUN7I_A20_CLK_MASK,
+SUN7I_A20_RGMII_CLK);
+
[linux-sunxi] [PATCH v2 2/6] clk: sunxi-ng: a31: Register regmap for sun6i CCU
On sun6i, the gmac clock is handled by the dwmac-sunxi driver, but
its configuration register is located in the CCU register range,
requiring proper regmap setup.
In order to do that, we use CLK_OF_DECLARE_DRIVER to initialize
sun7i ccu, which clears the OF_POPULATED flag, allowing the
platform device to probe the same resource with device node.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 60 +++-
1 file changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 9b40d53266a3..086eb93a4efd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -1262,5 +1262,61 @@ static void __init sun6i_a31_ccu_setup(struct
device_node *node)
ccu_mux_notifier_register(pll_cpu_clk.common.hw.clk,
_a31_cpu_nb);
}
-CLK_OF_DECLARE(sun6i_a31_ccu, "allwinner,sun6i-a31-ccu",
- sun6i_a31_ccu_setup);
+CLK_OF_DECLARE_DRIVER(sun6i_a31_ccu, "allwinner,sun6i-a31-ccu",
+ sun6i_a31_ccu_setup);
+
+/*
+ * Regmap for the GMAC driver (dwmac-sunxi) to allow access to
+ * GMAC configuration register.
+ */
+#define SUN6I_A31_GMAC_CFG_REG 0xD0
+static bool sun6i_a31_ccu_regmap_accessible_reg(struct device *dev,
+ unsigned int reg)
+{
+ if (reg == SUN6I_A31_GMAC_CFG_REG)
+ return true;
+ return false;
+}
+
+static struct regmap_config sun6i_a31_ccu_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x308, /* clk_out_b */
+
+ .readable_reg = sun6i_a31_ccu_regmap_accessible_reg,
+ .writeable_reg = sun6i_a31_ccu_regmap_accessible_reg,
+};
+
+static int sun6i_a31_ccu_probe_regmap(struct platform_device *pdev)
+{
+ void __iomem *reg;
+ struct resource *res;
+ struct regmap *regmap;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap(>dev, res->start, resource_size(res));
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ regmap = devm_regmap_init_mmio(>dev, reg,
+ _a31_ccu_regmap_accessible_reg);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return 0;
+}
+
+static const struct of_device_id sun6i_a31_ccu_ids[] = {
+ { .compatible = "allwinner,sun6i-a31-ccu"},
+ { }
+};
+
+static struct platform_driver sun6i_a31_ccu_driver = {
+ .probe = sun6i_a31_ccu_probe_regmap,
+ .driver = {
+ .name = "sun6i-a31-ccu",
+ .of_match_table = sun6i_a31_ccu_ids,
+ },
+};
+builtin_platform_driver(sun6i_a31_ccu_driver);
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200429204612.31883-3-plaes%40plaes.org.
[linux-sunxi] [PATCH v2 5/6] ARM: dts: sun7i: Use syscon-based implementation for gmac
Use syscon-based approach to access gmac clock configuration
register, instead of relying on a custom clock driver.
As a bonus, we can now drop the custom clock implementation
and dummy clocks making sun7i fully CCU-compatible.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20.dtsi | 36 +++-
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index ffe1d10a1a84..750962a94fad 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -219,37 +219,6 @@ osc32k: clk-32k {
clock-frequency = <32768>;
clock-output-names = "osc32k";
};
-
- /*
-* The following two are dummy clocks, placeholders
-* used in the gmac_tx clock. The gmac driver will
-* choose one parent depending on the PHY interface
-* mode, using clk_set_rate auto-reparenting.
-*
-* The actual TX clock rate is not controlled by the
-* gmac_tx clock.
-*/
- mii_phy_tx_clk: clk-mii-phy-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <2500>;
- clock-output-names = "mii_phy_tx";
- };
-
- gmac_int_tx_clk: clk-gmac-int-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "gmac_int_tx";
- };
-
- gmac_tx_clk: clk@1c20164 {
- #clock-cells = <0>;
- compatible = "allwinner,sun7i-a20-gmac-clk";
- reg = <0x01c20164 0x4>;
- clocks = <_phy_tx_clk>, <_int_tx_clk>;
- clock-output-names = "gmac_tx";
- };
};
@@ -1511,11 +1480,12 @@ mali: gpu@1c4 {
gmac: ethernet@1c5 {
compatible = "allwinner,sun7i-a20-gmac";
+ syscon = <>;
reg = <0x01c5 0x1>;
interrupts = ;
interrupt-names = "macirq";
- clocks = < CLK_AHB_GMAC>, <_tx_clk>;
- clock-names = "stmmaceth", "allwinner_gmac_tx";
+ clocks = < CLK_AHB_GMAC>;
+ clock-names = "stmmaceth";
snps,pbl = <2>;
snps,fixed-burst;
snps,force_sf_dma_mode;
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200429204612.31883-6-plaes%40plaes.org.
[linux-sunxi] [PATCH v2 1/6] clk: sunxi-ng: a20: Register regmap for sun7i CCU
On sun7i, the gmac clock is handled by the dwmac-sunxi driver, but
its configuration register is located in the CCU register range,
requiring proper regmap setup.
In order to do that, we use CLK_OF_DECLARE_DRIVER to initialize
sun7i ccu, which clears the OF_POPULATED flag, allowing the
platform device to probe the same resource with proper device node.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 60 +++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
index f32366d9336e..fbdf9ecf21b8 100644
--- a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
+++ b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "ccu_common.h"
#include "ccu_reset.h"
@@ -1478,5 +1480,61 @@ static void __init sun7i_a20_ccu_setup(struct
device_node *node)
{
sun4i_ccu_init(node, _a20_ccu_desc);
}
-CLK_OF_DECLARE(sun7i_a20_ccu, "allwinner,sun7i-a20-ccu",
+CLK_OF_DECLARE_DRIVER(sun7i_a20_ccu, "allwinner,sun7i-a20-ccu",
sun7i_a20_ccu_setup);
+
+/*
+ * Regmap for the GMAC driver (dwmac-sunxi) to allow access to
+ * GMAC configuration register.
+ */
+#define SUN7I_A20_GMAC_CFG_REG 0x164
+static bool sun7i_a20_ccu_regmap_accessible_reg(struct device *dev,
+ unsigned int reg)
+{
+ if (reg == SUN7I_A20_GMAC_CFG_REG)
+ return true;
+ return false;
+}
+
+static struct regmap_config sun7i_a20_ccu_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x1f4, /* clk_out_b */
+
+ .readable_reg = sun7i_a20_ccu_regmap_accessible_reg,
+ .writeable_reg = sun7i_a20_ccu_regmap_accessible_reg,
+};
+
+static int sun7i_a20_ccu_probe_regmap(struct platform_device *pdev)
+{
+ void __iomem *reg;
+ struct resource *res;
+ struct regmap *regmap;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap(>dev, res->start, resource_size(res));
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ regmap = devm_regmap_init_mmio(>dev, reg,
+ _a20_ccu_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return 0;
+}
+
+static const struct of_device_id sun7i_a20_ccu_ids[] = {
+ { .compatible = "allwinner,sun7i-a20-ccu"},
+ { }
+};
+
+static struct platform_driver sun7i_a20_ccu_driver = {
+ .probe = sun7i_a20_ccu_probe_regmap,
+ .driver = {
+ .name = "sun7i-a20-ccu",
+ .of_match_table = sun7i_a20_ccu_ids,
+ },
+};
+builtin_platform_driver(sun7i_a20_ccu_driver);
--
2.26.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200429204612.31883-2-plaes%40plaes.org.
[linux-sunxi] [PATCH v2 0/6] ARM: sunxi: Convert A20/A31 GMAC driver to use CCU
This serie converts Allwinner A20 and A31 GMAC driver to CCU while still retaining compatibility with existing devicetrees. This patchset touches 3 areas: - sun7i and sun6i CCUs now set up regmap to allow dwmac-sunxi driver to properly access the GMAC clock register. - dwmac-sunxi can now handle syscon-based clock register to handle clock itself. - sun7i and sun6i devicetrees are converted to use the new syscon-based access. Changes since v1: * Use CLK_OF_DECLARE_DRIVER to make it possible to probe again and set up regmap using platform device probe. * Clarify the meaning of "legacy" in dwmac-sunxi driver. * Make sure we don't mess with the RX/TX delay settings when updating clock registers. * Update devicetree bindings * Add sun6i-A31 support. (not tested due to lack of hardware) Priit Laes (6): clk: sunxi-ng: a20: Register regmap for sun7i CCU clk: sunxi-ng: a31: Register regmap for sun6i CCU net: stmmac: dwmac-sunxi: Implement syscon-based clock handling dt-bindings: net: sun7i-gmac: Add syscon support ARM: dts: sun7i: Use syscon-based implementation for gmac ARM: dts: sun6i: Use syscon-based implementation for gmac .../net/allwinner,sun7i-a20-gmac.yaml | 15 +- arch/arm/boot/dts/sun6i-a31.dtsi | 35 + arch/arm/boot/dts/sun7i-a20.dtsi | 36 + drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 60 +++- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 60 +++- .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 130 -- 6 files changed, 258 insertions(+), 78 deletions(-) -- 2.26.2 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200429204612.31883-1-plaes%40plaes.org.
[linux-sunxi] Re: [PATCH 1/4] clk: sunxi-ng: a10/a20: rewrite init code to a platform driver
On Mon, Apr 20, 2020 at 02:49:35PM +0200, Maxime Ripard wrote: > On Sat, Apr 18, 2020 at 01:17:27AM +0300, Priit Laes wrote: > > In order to register regmap for sun7i CCU, there needs to be > > a device structure already bound to the CCU device node. > > > > Convert the sun4i/sun7i CCU setup to platform driver to use > > it later as platform device. > > > > Signed-off-by: Priit Laes > > You can't relly do that though. We have timers that need those clocks before > the > device model is initialized. Ok, I'm somewhat lost now... are these the affected timers on sun7i following: - allwinner,sun4i-a10-timer (timer@1c20c00) - allwinner,sun7i-a20-hstimer (hstimer@1c6) Any ideas on what approach I could actually use? Also, similar timer dependency would affect then sun6i-a31 and sun9i-a80 platforms too... > > 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/20200420203228.GA4734%40plaes.org.
[linux-sunxi] Re: [PATCH 4/4] ARM: dts: sun7i: Use syscon-based implementation for gmac
On Mon, Apr 20, 2020 at 02:59:19PM +0200, Maxime Ripard wrote:
> On Sat, Apr 18, 2020 at 01:17:30AM +0300, Priit Laes wrote:
> > Use syscon-based approach to access gmac clock configuration
> > register, instead of relying on a custom clock driver.
> >
> > As a bonus, we can now drop the custom clock implementation
> > and dummy clocks making sun7i fully CCU-compatible.
> >
> > Signed-off-by: Priit Laes
> > ---
> > arch/arm/boot/dts/sun7i-a20.dtsi | 36 +++-
> > 1 file changed, 3 insertions(+), 33 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> > b/arch/arm/boot/dts/sun7i-a20.dtsi
> > index ffe1d10a1a84..750962a94fad 100644
> > --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> > +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> > @@ -219,37 +219,6 @@ osc32k: clk-32k {
> > clock-frequency = <32768>;
> > clock-output-names = "osc32k";
> > };
> > -
> > - /*
> > -* The following two are dummy clocks, placeholders
> > -* used in the gmac_tx clock. The gmac driver will
> > -* choose one parent depending on the PHY interface
> > -* mode, using clk_set_rate auto-reparenting.
> > -*
> > -* The actual TX clock rate is not controlled by the
> > -* gmac_tx clock.
> > -*/
> > - mii_phy_tx_clk: clk-mii-phy-tx {
> > - #clock-cells = <0>;
> > - compatible = "fixed-clock";
> > - clock-frequency = <2500>;
> > - clock-output-names = "mii_phy_tx";
> > - };
> > -
> > - gmac_int_tx_clk: clk-gmac-int-tx {
> > - #clock-cells = <0>;
> > - compatible = "fixed-clock";
> > - clock-frequency = <12500>;
> > - clock-output-names = "gmac_int_tx";
> > - };
> > -
> > - gmac_tx_clk: clk@1c20164 {
> > - #clock-cells = <0>;
> > - compatible = "allwinner,sun7i-a20-gmac-clk";
> > - reg = <0x01c20164 0x4>;
> > - clocks = <_phy_tx_clk>, <_int_tx_clk>;
> > - clock-output-names = "gmac_tx";
> > - };
> > };
> >
> >
> > @@ -1511,11 +1480,12 @@ mali: gpu@1c4 {
> >
> > gmac: ethernet@1c5 {
> > compatible = "allwinner,sun7i-a20-gmac";
> > + syscon = <>;
> > reg = <0x01c5 0x1>;
> > interrupts = ;
> > interrupt-names = "macirq";
> > - clocks = < CLK_AHB_GMAC>, <_tx_clk>;
> > - clock-names = "stmmaceth", "allwinner_gmac_tx";
> > + clocks = < CLK_AHB_GMAC>;
> > + clock-names = "stmmaceth";
>
> I guess you also need to update the binding so that it considers it valid?
Yes, will do it in the next round.
>
> 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/20200420132331.GB18522%40plaes.org.
[linux-sunxi] Re: [PATCH 0/4] ARM: sun7i: Convert A20 GMAC driver to CCU
On Sat, Apr 18, 2020 at 01:17:26AM +0300, Priit Laes wrote: > This serie converts Allwinner A20 (sun7i) GMAC driver to CCU > while still retaining compatibility with existing devicetrees. > > First two patches contain preliminary work which convert > sun4i/sun7i clock drivers to platform devices and creates regmap > to access gmac register from the sun7i gmac driver. > > Third patch implements syscon-based regmap to allow driver manage > its own clock source. > > Fourth patch updates the devicetree and drops the unused clocks. > > While testing the driver I noticed following bugs with the existing > sun7i gmac driver: > - driver relies on u-boot for initialization (fixed in this > implementation) Scratch that.. this is actually due to unhandled rx and tx delays, which I "accidentally" fixed by copying the value BIT(12) from the u-boot.. > - `systemctl restart networking` fails to bring the link up again. > > > Priit Laes (4): > clk: sunxi-ng: a10/a20: rewrite init code to a platform driver > clk: sunxi-ng: a20: export a regmap to access the GMAC register > net: stmmac: dwmac-sunxi: Implement syscon-based clock handling > ARM: dts: sun7i: Use syscon-based implementation for gmac > > arch/arm/boot/dts/sun7i-a20.dtsi | 36 + > drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 108 --- > .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 124 -- > 3 files changed, 206 insertions(+), 62 deletions(-) > > -- > 2.25.2 > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200420123257.GA18522%40plaes.org.
[linux-sunxi] [PATCH 4/4] ARM: dts: sun7i: Use syscon-based implementation for gmac
Use syscon-based approach to access gmac clock configuration
register, instead of relying on a custom clock driver.
As a bonus, we can now drop the custom clock implementation
and dummy clocks making sun7i fully CCU-compatible.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20.dtsi | 36 +++-
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index ffe1d10a1a84..750962a94fad 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -219,37 +219,6 @@ osc32k: clk-32k {
clock-frequency = <32768>;
clock-output-names = "osc32k";
};
-
- /*
-* The following two are dummy clocks, placeholders
-* used in the gmac_tx clock. The gmac driver will
-* choose one parent depending on the PHY interface
-* mode, using clk_set_rate auto-reparenting.
-*
-* The actual TX clock rate is not controlled by the
-* gmac_tx clock.
-*/
- mii_phy_tx_clk: clk-mii-phy-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <2500>;
- clock-output-names = "mii_phy_tx";
- };
-
- gmac_int_tx_clk: clk-gmac-int-tx {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "gmac_int_tx";
- };
-
- gmac_tx_clk: clk@1c20164 {
- #clock-cells = <0>;
- compatible = "allwinner,sun7i-a20-gmac-clk";
- reg = <0x01c20164 0x4>;
- clocks = <_phy_tx_clk>, <_int_tx_clk>;
- clock-output-names = "gmac_tx";
- };
};
@@ -1511,11 +1480,12 @@ mali: gpu@1c4 {
gmac: ethernet@1c5 {
compatible = "allwinner,sun7i-a20-gmac";
+ syscon = <>;
reg = <0x01c5 0x1>;
interrupts = ;
interrupt-names = "macirq";
- clocks = < CLK_AHB_GMAC>, <_tx_clk>;
- clock-names = "stmmaceth", "allwinner_gmac_tx";
+ clocks = < CLK_AHB_GMAC>;
+ clock-names = "stmmaceth";
snps,pbl = <2>;
snps,fixed-burst;
snps,force_sf_dma_mode;
--
2.25.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200417221730.555954-5-plaes%40plaes.org.
[linux-sunxi] [PATCH 1/4] clk: sunxi-ng: a10/a20: rewrite init code to a platform driver
In order to register regmap for sun7i CCU, there needs to be
a device structure already bound to the CCU device node.
Convert the sun4i/sun7i CCU setup to platform driver to use
it later as platform device.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 77
1 file changed, 56 insertions(+), 21 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
index f32366d9336e..839e9d5a1cff 100644
--- a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
+++ b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
@@ -7,7 +7,8 @@
#include
#include
-#include
+#include
+#include
#include "ccu_common.h"
#include "ccu_reset.h"
@@ -1425,19 +1426,10 @@ static const struct sunxi_ccu_desc sun7i_a20_ccu_desc =
{
.num_resets = ARRAY_SIZE(sunxi_a10_a20_ccu_resets),
};
-static void __init sun4i_ccu_init(struct device_node *node,
- const struct sunxi_ccu_desc *desc)
+static void bootstrap_clocks(void __iomem *reg)
{
- void __iomem *reg;
u32 val;
- reg = of_io_request_and_map(node, 0, of_node_full_name(node));
- if (IS_ERR(reg)) {
- pr_err("%s: Could not map the clock registers\n",
- of_node_full_name(node));
- return;
- }
-
val = readl(reg + SUN4I_PLL_AUDIO_REG);
/*
@@ -1463,20 +1455,63 @@ static void __init sun4i_ccu_init(struct device_node
*node,
val = readl(reg + SUN4I_AHB_REG);
val &= ~GENMASK(7, 6);
writel(val | (2 << 6), reg + SUN4I_AHB_REG);
-
- sunxi_ccu_probe(node, reg, desc);
}
-static void __init sun4i_a10_ccu_setup(struct device_node *node)
+static int sun4i_a10_ccu_probe(struct platform_device *pdev)
{
- sun4i_ccu_init(node, _a10_ccu_desc);
+ struct resource *res;
+ void __iomem *reg;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ bootstrap_clocks(reg);
+
+ return sunxi_ccu_probe(pdev->dev.of_node, reg, _a10_ccu_desc);
}
-CLK_OF_DECLARE(sun4i_a10_ccu, "allwinner,sun4i-a10-ccu",
- sun4i_a10_ccu_setup);
-static void __init sun7i_a20_ccu_setup(struct device_node *node)
+static int sun7i_a20_ccu_probe(struct platform_device *pdev)
{
- sun4i_ccu_init(node, _a20_ccu_desc);
+ struct resource *res;
+ void __iomem *reg;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ bootstrap_clocks(reg);
+
+ return sunxi_ccu_probe(pdev->dev.of_node, reg, _a20_ccu_desc);
}
-CLK_OF_DECLARE(sun7i_a20_ccu, "allwinner,sun7i-a20-ccu",
- sun7i_a20_ccu_setup);
+
+
+static const struct of_device_id sun4i_a10_ccu_ids[] = {
+ { .compatible = "allwinner,sun4i-a10-ccu"},
+ { }
+};
+
+static struct platform_driver sun4i_a10_ccu_driver = {
+ .probe = sun4i_a10_ccu_probe,
+ .driver = {
+ .name = "sun4i-a10-ccu",
+ .of_match_table = sun4i_a10_ccu_ids,
+ },
+};
+builtin_platform_driver(sun4i_a10_ccu_driver);
+
+static const struct of_device_id sun7i_a20_ccu_ids[] = {
+ { .compatible = "allwinner,sun7i-a20-ccu"},
+ { }
+};
+
+static struct platform_driver sun7i_a20_ccu_driver = {
+ .probe = sun7i_a20_ccu_probe,
+ .driver = {
+ .name = "sun7i-a20-ccu",
+ .of_match_table = sun7i_a20_ccu_ids,
+ },
+};
+builtin_platform_driver(sun7i_a20_ccu_driver);
--
2.25.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200417221730.555954-2-plaes%40plaes.org.
[linux-sunxi] [PATCH 2/4] clk: sunxi-ng: a20: export a regmap to access the GMAC register
Only GMAC register is allowed to be written, read access to registers
is not restricted.
Export a regmap of the CCU.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 31
1 file changed, 31 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
index 839e9d5a1cff..cba51c2c7eba 100644
--- a/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
+++ b/drivers/clk/sunxi-ng/ccu-sun4i-a10.c
@@ -1426,6 +1426,30 @@ static const struct sunxi_ccu_desc sun7i_a20_ccu_desc = {
.num_resets = ARRAY_SIZE(sunxi_a10_a20_ccu_resets),
};
+/*
+ * Add regmap for the GMAC driver (dwmac-sun8i) to allow access to
+ * GMAC configuration register.
+ */
+
+#define SUN7I_A20_GMAC_CFG_REG 0x164
+static bool sun7i_a20_ccu_regmap_accessible_reg(struct device *dev,
+ unsigned int reg)
+{
+ if (reg == SUN7I_A20_GMAC_CFG_REG)
+ return true;
+ return false;
+}
+
+static struct regmap_config sun7i_a20_ccu_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x1f4, /* clk_out_b */
+
+ .readable_reg = sun7i_a20_ccu_regmap_accessible_reg,
+ .writeable_reg = sun7i_a20_ccu_regmap_accessible_reg,
+};
+
static void bootstrap_clocks(void __iomem *reg)
{
u32 val;
@@ -1474,6 +1498,7 @@ static int sun4i_a10_ccu_probe(struct platform_device
*pdev)
static int sun7i_a20_ccu_probe(struct platform_device *pdev)
{
+ struct regmap *regmap;
struct resource *res;
void __iomem *reg;
@@ -1484,6 +1509,12 @@ static int sun7i_a20_ccu_probe(struct platform_device
*pdev)
bootstrap_clocks(reg);
+ regmap = devm_regmap_init_mmio(>dev, reg,
+ _a20_ccu_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+
return sunxi_ccu_probe(pdev->dev.of_node, reg, _a20_ccu_desc);
}
--
2.25.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200417221730.555954-3-plaes%40plaes.org.
[linux-sunxi] [PATCH 0/4] ARM: sun7i: Convert A20 GMAC driver to CCU
This serie converts Allwinner A20 (sun7i) GMAC driver to CCU while still retaining compatibility with existing devicetrees. First two patches contain preliminary work which convert sun4i/sun7i clock drivers to platform devices and creates regmap to access gmac register from the sun7i gmac driver. Third patch implements syscon-based regmap to allow driver manage its own clock source. Fourth patch updates the devicetree and drops the unused clocks. While testing the driver I noticed following bugs with the existing sun7i gmac driver: - driver relies on u-boot for initialization (fixed in this implementation) - `systemctl restart networking` fails to bring the link up again. Priit Laes (4): clk: sunxi-ng: a10/a20: rewrite init code to a platform driver clk: sunxi-ng: a20: export a regmap to access the GMAC register net: stmmac: dwmac-sunxi: Implement syscon-based clock handling ARM: dts: sun7i: Use syscon-based implementation for gmac arch/arm/boot/dts/sun7i-a20.dtsi | 36 + drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 108 --- .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 124 -- 3 files changed, 206 insertions(+), 62 deletions(-) -- 2.25.2 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200417221730.555954-1-plaes%40plaes.org.
[linux-sunxi] [PATCH 3/4] net: stmmac: dwmac-sunxi: Implement syscon-based clock handling
Convert the sun7i-gmac driver to use a regmap-based driver,
instead of relying on the custom clock implementation.
This allows to get rid of the last custom clock in the sun7i
device tree making the sun7i fully CCU-compatible.
Compatibility with existing devicetrees is retained.
Signed-off-by: Priit Laes
---
.../net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 124 --
1 file changed, 116 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
index 0e1ca2cba3c7..3476920bc762 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -12,8 +12,11 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include "stmmac_platform.h"
@@ -22,10 +25,20 @@ struct sunxi_priv_data {
int clk_enabled;
struct clk *tx_clk;
struct regulator *regulator;
+ struct regmap_field *regmap_field;
+};
+
+/* EMAC clock register @ 0x164 in the CCU address range */
+static const struct reg_field ccu_reg_field = {
+ .reg = 0x164,
+ .lsb = 0,
+ .msb = 31,
};
#define SUN7I_GMAC_GMII_RGMII_RATE 12500
#define SUN7I_GMAC_MII_RATE2500
+#define SUN7I_A20_RGMII_CLK((3 << 1) | (1 << 12))
+#define SUN7I_A20_MII_CLK (1 << 12)
static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
{
@@ -38,7 +51,20 @@ static int sun7i_gmac_init(struct platform_device *pdev,
void *priv)
return ret;
}
- /* Set GMAC interface port mode
+ if (gmac->regmap_field) {
+ if (phy_interface_mode_is_rgmii(gmac->interface)) {
+ regmap_field_write(gmac->regmap_field,
+ SUN7I_A20_RGMII_CLK);
+ return clk_prepare_enable(gmac->tx_clk);
+ }
+ regmap_field_write(gmac->regmap_field, SUN7I_A20_MII_CLK);
+ return clk_enable(gmac->tx_clk);
+ }
+
+ /* Legacy devicetree support */
+
+ /*
+* Set GMAC interface port mode
*
* The GMAC TX clock lines are configured by setting the clock
* rate, which then uses the auto-reparenting feature of the
@@ -62,9 +88,15 @@ static void sun7i_gmac_exit(struct platform_device *pdev,
void *priv)
{
struct sunxi_priv_data *gmac = priv;
- if (gmac->clk_enabled) {
+ if (gmac->regmap_field) {
+ regmap_field_write(gmac->regmap_field, 0);
clk_disable(gmac->tx_clk);
- gmac->clk_enabled = 0;
+ } else {
+ /* Legacy devicetree support */
+ if (gmac->clk_enabled) {
+ clk_disable(gmac->tx_clk);
+ gmac->clk_enabled = 0;
+ }
}
clk_unprepare(gmac->tx_clk);
@@ -72,10 +104,53 @@ static void sun7i_gmac_exit(struct platform_device *pdev,
void *priv)
regulator_disable(gmac->regulator);
}
+static struct regmap *sun7i_gmac_get_syscon_from_dev(struct device_node *node)
+{
+ struct device_node *syscon_node;
+ struct platform_device *syscon_pdev;
+ struct regmap *regmap = NULL;
+
+ syscon_node = of_parse_phandle(node, "syscon", 0);
+ if (!syscon_node)
+ return ERR_PTR(-ENODEV);
+
+ syscon_pdev = of_find_device_by_node(syscon_node);
+ if (!syscon_pdev) {
+ /* platform device might not be probed yet */
+ regmap = ERR_PTR(-EPROBE_DEFER);
+ goto out_put_node;
+ }
+
+ /* If no regmap is found then the other device driver is at fault */
+ regmap = dev_get_regmap(_pdev->dev, NULL);
+ if (!regmap)
+ regmap = ERR_PTR(-EINVAL);
+
+ platform_device_put(syscon_pdev);
+out_put_node:
+ of_node_put(syscon_node);
+ return regmap;
+}
+
static void sun7i_fix_speed(void *priv, unsigned int speed)
{
struct sunxi_priv_data *gmac = priv;
+ if (gmac->regmap_field) {
+ clk_disable(gmac->tx_clk);
+ clk_unprepare(gmac->tx_clk);
+ if (speed == 1000)
+ regmap_field_write(gmac->regmap_field,
+ SUN7I_A20_RGMII_CLK);
+ else
+ regmap_field_write(gmac->regmap_field,
+ SUN7I_A20_MII_CLK);
+ clk_prepare_enable(gmac->tx_clk);
+ return;
+ }
+
+ /* Legacy devicetree support... */
+
/* only GMII mode requires us to reconfigure the clock lines */
if (gmac->interface != PHY_INTERFACE_MODE_GMII)
return;
@@ -102,6 +177,8 @@ static
Re: [linux-sunxi] Query about Lemaker LCD 3.5 patch
On Mon, Apr 06, 2020 at 01:07:54AM -0700, 'destroyedlolo' via linux-sunxi wrote: > Hi Clement and thanks for your reply. > > I sent a mail to Paul :) > > I'm using the 1st BananaPI released by LeMaker. > > I downloaded on Friday the latest stable kernel from kernel.org (using the > git clone command from Sunxi website). > > I'll will try to apply provided fixes (links doesn't work but I found them > :) ). > > Why are they marked "Not for merge" ? Does it mean I'll have to reapply > them for next kernel updgrade ? "Not for merge" is used for hardware that is not integrated by default with the devices and are only used for demonstration purposes to show how the functionality works. Those patches should be either applied by users of this hardware themselves either by patching kernel or using devicetree overlays. > > Thanks > > Laurent > > -- > 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/a0d4ce79-63b5-478b-beb8-35eb1d3eb373%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/20200406084456.GA31329%40plaes.org.
Re: [linux-sunxi] CVE-2020-8597
On Tue, Mar 10, 2020 at 05:58:55AM -0700, Paolo Cremonese wrote: > Hi All, > does anybody know if for linux-sunxi distribution is applicable the > vulnerability *CVE-2020-8597 ?* > If yes, there is a patch available ? No. This is a bug in pppd package. > > Thanks in advance > > Paolo > > -- > 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/9f64fdb3-000d-4bb4-8dc6-4e1b2f47729e%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/20200310132407.GB31679%40plaes.org.
Re: [linux-sunxi] LVDS screen on Cubieboard 2 (Allwinner A20) via DRM/KMS
On Thu, Feb 06, 2020 at 12:38:49PM -0800, Andrey Lebedev wrote:
> Hello,
>
> We at https://openvario.org/ are trying to upgrade our device from legacy
> linux-3.4 with proprietary mali drivers to modern linux with DRM/KMS-based
> graphics. The device we are building is based on Cubieboard 2 with
> Allwinner A20 (sun7i) SoC. It has a LCD screen connected via LVDS
> interface.
>
> We have a problem making this screen running under sun4i-drm display
> pipeline.
LVDS support for A20 is currently unimplemented.
I have a very old WIP branch that needs to be updated against current
kernel here: https://github.com/plaes/linux/commits/sun4i-lvds-wip
>
> We are building an SD image using Yocto-based build system, that builds
> u-boot and linux kernel-5.2-rc2. Under current setup (which I will describe
> below), device is booted by u-boot, that successfully initializes the LCD
> and outputs a splash image on it (that's how I know LCD itself is connected
> correctly and works). When u-boot passes control to the kernel, that splash
> image slowly fades into all-white and the screen stays bright-white until
> device is turned off. I have full access to the machine via serial (ttyS0)
> interface.
>
> U-boot is compiled with these config options (among others):
>
> CONFIG_ARCH_SUNXI=y
> CONFIG_MACH_SUN7I=y
> CONFIG_VIDEO_LCD_MODE="x:640,y:480,depth:18,pclk_khz:25000,hs:1,vs:1,le:157,ri:2,up:42,lo:2,sync:3,vmode:0"
> CONFIG_VIDEO_LCD_PANEL_LVDS=y
>
> Kernel is configured to compile these drm-related modules (among others):
> drm, panel_lvds, lima, sun4i_drm, gpu_sched, sun4i_drm_hdmi, sun4i_backend,
> sun4i_tcon, sun4i_frontend, drm_kms_helper.
>
> They all load automatically during boot and together with lima module
> produce /dev/dri/card0 and /dev/dri/card1 devices. I have created the
> device tree for the kernel with "panel-lvds" connected directly to tcon0,
> port 1, endpoint 0. I have also provided additional reset line, as per
> sun4i-drm.txt doc (see [1]). There is a pipeline for HDMI is set up in DT
> too, but I'm omitting it for brevity.
>
> When kernel loads, I see sun4i-drm modules initialize without apparent
> errors (see [2]).
>
> Since this set up didn't work out-of-the-box, I started to dig deeper and
> added more trace logging to parts of drivers/gpu/drm/sun4i/sun4i_tcon.c
> that deal with LVDS. It turned out that all LVDS initialization was
> basically skipped, because current sun4i_tcon_quirks object
> (sun7i_a20_quirks in my case) did not have "supports_lvds" property
> (compare to sun8i_a83t_lcd_quirks). My naive attempt to simply add that
> property didn't result to LCD working (no notable changes in panel'
> behavior), however my tracing output indicate that sun4i_lvds_init() is
> called before "sun4i-drm display-engine: bound 1c0c000.lcd-controller"
> message. sun4i_tcon_lvds_set_status() function is called too (with
> enabled=true), just after "fbcon: Taking over console" message. Effectively
> what you see in [2] is a log after I introduced
> sun7i_a20_quirks.supports_lvds.
>
> Do you see anything I missed trying to make LCD work? Is it expected to
> work at all with current kernel? If not, what is missing? Can I provide any
> additional info?
>
> I (and all Openvario users) would really appreciate any help making the LCD
> to run!
>
>
> [1] Device tree excerpt:
>
> panel {
> compatible = "openvario,lvds57", "panel-lvds";
> width-mm = <261>;
> height-mm = <163>;
> data-mapping = "jeida-18";
> panel-timing {
> /* 640x480 @60Hz */
> clock-frequency = <2500>;
> hactive = <640>;
> vactive = <480>;
> hsync-len = <1>;
> hfront-porch = <2>;
> hback-porch = <157>;
> vsync-len = <1>;
> vfront-porch = <2>;
> vback-porch = <42>;
> };
> port {
> lvds_panel_in: endpoint {
> remote-endpoint = <_out_rgb>;
> };
> };
> };
> {
> resets = < RST_TCON0>, < RST_LVDS>;
> reset-names = "lcd", "lvds";
> ports {
> tcon0_out: port@1 {
> display_out_rgb: endpoint@0 {
> reg = <0>;
> remote-endpoint = <_panel_in>;
> allwinner,tcon-channel = <0>;
> };
> };
> };
> };
>
>
> [2] dmesg report excerpt
>
> ...
> [5.017228] lima 1c4.gpu: bus rate = 3
> [5.022129] lima 1c4.gpu: mod rate = 38400
> [5.090519] lima 1c4.gpu: gp - mali400 version major 1 minor 1
> [5.096905] lima 1c4.gpu: pp0 - mali400 version major 1 minor 1
> [5.103562] lima 1c4.gpu: pp1 - mali400 version major 1 minor 1
> [5.109985] lima 1c4.gpu: l2 cache 64K, 4-way, 64byte cache line,
> 64bit external bus
> [5.122207] sun4i-drm display-engine: bound 1e0.display-frontend
> (ops sun4i_frontend_driver_exit
[linux-sunxi] Re: sun7i-dwmac: link detection failure with 1000Mbit parters
On Thu, Oct 31, 2019 at 10:38:41AM +, Russell King - ARM Linux admin wrote: > On Thu, Oct 31, 2019 at 08:39:06AM +, Jose Abreu wrote: > > ++ Florian, Andrew, Heiner, Russell > > > > Can you please attach your dmesg log ? PHYLINK provides some useful > > debug logs. > > > > From: Priit Laes > > Date: Oct/30/2019, 20:21:17 (UTC+00:00) > > > > > Heya! > > > > > > I have noticed that with sun7i-dwmac driver (OLinuxino Lime2 eMMC), link > > > detection fails consistently with certain 1000Mbit partners (for example > > > Huawei > > > B525s-23a 4g modem ethernet outputs and RTL8153-based USB3.0 ethernet > > > dongle), > > > but the same hardware works properly with certain other link partners > > > (100Mbit GL AR150 > > > for example). > > > > > > (Just need to test with another 1000Mbit switch at the office). > > > > > > I first thought it could be a regression, but I went from current master > > > to as far back > > > as 5.2.0-rc6 where it was still broken. > > The stmmac conversion to phylink was v5.3-rc1, so that's likely not the > issue if v5.2-rc6 also exhibits this behaviour. > > My guess is that the problem lies in phylib, especially as the link LEDs > go off when the link is configured. I notice that it's using the > generic PHY driver rather than a specific driver. Yup, it turned out to be a phy-related issue - I was using generic PHY driver, but the board is using Micrel KSZ9031 which has some quirks that MICREL_PHY=y managed to work around. > > mii-diag -v eth0 > > would be useful to see for the case where the link has failed, without > replugging the ethernet cable. mii-diag seems to be quite an useful tool, but unfortunately has not been packaged anymore on newer distro releases like Debian stable and latest Ubuntu LTS. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up -- 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/20191101094920.GB12834%40plaes.org.
[linux-sunxi] Re: sun7i-dwmac: link detection failure with 1000Mbit parters
On Thu, Oct 31, 2019 at 02:14:04PM +0100, Andrew Lunn wrote: > On Thu, Oct 31, 2019 at 02:04:22PM +0100, Andrew Lunn wrote: > > On Wed, Oct 30, 2019 at 08:21:17PM +0000, Priit Laes wrote: > > > Heya! > > > > > > I have noticed that with sun7i-dwmac driver (OLinuxino Lime2 eMMC), link > > > detection fails consistently with certain 1000Mbit partners (for example > > > Huawei > > > B525s-23a 4g modem ethernet outputs and RTL8153-based USB3.0 ethernet > > > dongle), > > > but the same hardware works properly with certain other link partners > > > (100Mbit GL AR150 > > > for example). > > > > Hi Pritt > > > > What PHY is used? And what happens if you use the specific PHY driver, > > not the generic PHY driver? > > Schematics of the board are here: > > https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A20-OLinuXino-LIME2/1.%20Latest%20hardware%20revision/A20-OLinuXino-Lime2_Rev_K2_COLOR.pdf > > So it has a KSZ9031. The micrel driver supports that device. And there > is a patch which might be relevant: > > commit 3aed3e2a143c9619f4c8d0a3b8fe74d7d3d79c93 > Author: Antoine Tenart ... > Please test using the Micrel PHY driver and see if that solves your > problem. Thanks, CONFIG_MICREL_PHY=y helped! > > Andrew -- 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/20191031161939.GA12834%40plaes.org.
[linux-sunxi] sun7i-dwmac: link detection failure with 1000Mbit parters
Heya! I have noticed that with sun7i-dwmac driver (OLinuxino Lime2 eMMC), link detection fails consistently with certain 1000Mbit partners (for example Huawei B525s-23a 4g modem ethernet outputs and RTL8153-based USB3.0 ethernet dongle), but the same hardware works properly with certain other link partners (100Mbit GL AR150 for example). (Just need to test with another 1000Mbit switch at the office). I first thought it could be a regression, but I went from current master to as far back as 5.2.0-rc6 where it was still broken. Failure is basically following: [ 10.971485] sun7i-dwmac 1c5.ethernet eth0: PHY [stmmac-0:01] driver [Generic PHY] [ 10.980841] sun7i-dwmac 1c5.ethernet eth0: No Safety Features support found [ 10.988291] sun7i-dwmac 1c5.ethernet eth0: RX IPC Checksum Offload disabled [ 10.995694] sun7i-dwmac 1c5.ethernet eth0: No MAC Management Counters available [ 11.003381] sun7i-dwmac 1c5.ethernet eth0: PTP not supported by HW [ 11.009927] sun7i-dwmac 1c5.ethernet eth0: configuring for phy/rgmii link mode ... link and activity leds go blank ... ... remove and replug and link is detected again ... [ 19.371894] sun7i-dwmac 1c5.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Ethtool output in case link is down: [snip] Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x003f (63) drv probe link timer ifdown ifup Link detected: no [/snip] And ethtool output in case cable is removed and replugged: [snip] ethtool eth0 Settings for eth0: ...cut... Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x003f (63) drv probe link timer ifdown ifup Link detected: yes [/snip] With 100Mbit link partner (GL Inet AR150), the link is pulled up almost immediately: [ 15.531754] sun7i-dwmac 1c5.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [snip] Settings for eth0: ... cut ... Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x003f (63) drv probe link timer ifdown ifup Link detected: yes [/snip] -- 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/20191030202117.GA29022%40plaes.org.
Re: [linux-sunxi] [PATCH v2 04/11] ARM: dts: sun8i: R40: add crypto engine node
On Tue, Oct 01, 2019 at 08:41:34PM +0200, Corentin Labbe wrote:
> The Crypto Engine is a hardware cryptographic offloader that supports
> many algorithms.
> It could be found on most Allwinner SoCs.
>
> This patch enables the Crypto Engine on the Allwinner R40 SoC Device-tree.
>
> Signed-off-by: Corentin Labbe
> ---
> arch/arm/boot/dts/sun8i-r40.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> b/arch/arm/boot/dts/sun8i-r40.dtsi
> index bde068111b85..1fc3297a55ec 100644
> --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> @@ -266,6 +266,16 @@
> #phy-cells = <1>;
> };
>
> + crypto: crypto-engine@1c15000 {
All the other .dtsi files have `crypto: crypto@...` instead of crypto-engine.
> + compatible = "allwinner,sun8i-r40-crypto";
> + reg = <0x01c15000 0x1000>;
> + interrupts = ;
> + clocks = < CLK_BUS_CE>, < CLK_CE>;
> + clock-names = "bus", "mod";
> + resets = < RST_BUS_CE>;
> + reset-names = "bus";
> + };
> +
> ehci1: usb@1c19000 {
> compatible = "allwinner,sun8i-r40-ehci", "generic-ehci";
> reg = <0x01c19000 0x100>;
> --
> 2.21.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/20191001184141.27956-5-clabbe.montjoie%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/20191002080827.GB6347%40plaes.org.
[linux-sunxi] [BUG] sun4i: axp209: no atomic i2c transfer handler
Heya! I have seen following warning message for few times when shutting down the machine (Olinuxino Lime2-emmc) running the mainline kernel. [snip] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:41 i2c_transfer+0xe8/0xf4 No atomic I2C transfer handler for 'i2c-1' Modules linked in: enc28j60 CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.3.0-rc8-paf+ #28 Hardware name: Allwinner sun7i (A20) Family [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x88/0x9c) [] (dump_stack) from [] (__warn+0xd4/0xf0) [] (__warn) from [] (warn_slowpath_fmt+0x48/0x6c) [] (warn_slowpath_fmt) from [] (i2c_transfer+0xe8/0xf4) [] (i2c_transfer) from [] (i2c_transfer_buffer_flags+0x4c/0x70) [] (i2c_transfer_buffer_flags) from [] (regmap_i2c_write+0x14/0x30) [] (regmap_i2c_write) from [] (_regmap_raw_write_impl+0x588/0x63c) [] (_regmap_raw_write_impl) from [] (regmap_write+0x3c/0x5c) [] (regmap_write) from [] (axp20x_power_off+0x2c/0x38) [] (axp20x_power_off) from [] (sys_reboot+0x14c/0x1e0) [] (sys_reboot) from [] (ret_fast_syscall+0x0/0x54) Exception stack(0xef04ffa8 to 0xef04fff0) ffa0: 00427954 fee1dead 28121969 4321fedc 16814300 ffc0: 00427954 0058 bec15c78 bec15c10 004266f8 ffe0: 0058 bec15b6c b6f69d45 b6eeb746 [/snip] The enc28j60 module is SPI, so it has nothing to do with the message. Any ideas where to look? Päikest, Priit :) -- 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/20190920083237.GA11657%40plaes.org.
Re: [linux-sunxi] is there any plan to enable cursor plane for sun4i-drm?
On Sun, Sep 08, 2019 at 12:20:50PM +0200, 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=c186b256a869bab09103075a133f3c0d5f7b48cc
> https://megous.com/git/linux/commit/?h=private-5.3=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.
Please CC these patches also to Maxime and Wens.
>
> 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 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
Re: [linux-sunxi] [RESEND PATCH] ARM: dts: sun7i: olimex-lime2: Enable ac and power supplies
On Tue, May 28, 2019 at 02:58:57PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Tue, 2019-05-28 at 09:35 +0300, Priit Laes wrote:
> > Lime2 has battery connector so enable these supplies.
>
> Out of curiosity, what is reported to userspace when no battery is
> attached?
Data from /sys/class/power_supply/axp20x-battery:
[snip]
$ for i in $(ls -1); do echo "cat $i"; cat $i; done
cat capacity
100
cat constant_charge_current
120
cat constant_charge_current_max
120
cat current_now
0
cat health
Good
cat online
0
cat present
0
cat status
Not charging
cat type
Battery
cat uevent
POWER_SUPPLY_NAME=axp20x-battery
POWER_SUPPLY_PRESENT=0
POWER_SUPPLY_ONLINE=0
POWER_SUPPLY_STATUS=Not charging
POWEROSUPPLY_VOLTAGE_NOW=0
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CON/TANT_CHARGE_CURRENT=120
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=120
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_VOLTAGE_MAXODESIGN=420
POWEROSUPPLY_VOLTAGE_MIN_DESIGN=290
POWER_SUPPLY_CAPACITY=100
cat voltage_max_design
420
cat voltage_min_design
290
cat voltage_now
0
[/snip]
> Looks good otherwise:
> Reviewed-by: Paul Kocialkowski
>
> Cheers,
>
> Paul
>
> > Signed-off-by: Priit Laes
> > ---
> > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> > b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> > index 9c8eecf4337a..9001b5527615 100644
> > --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> > +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> > @@ -206,6 +206,14 @@
> >
> > #include "axp209.dtsi"
> >
> > +_power_supply {
> > + status = "okay";
> > +};
> > +
> > +_power_supply {
> > + status = "okay";
> > +};
> > +
> > _dcdc2 {
> > regulator-always-on;
> > regulator-min-microvolt = <100>;
> > --
> > 2.11.0
> >
> --
> Paul Kocialkowski, 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/20190528134342.25fep6kpmrr4p7vw%40plaes.org.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RESEND PATCH] ARM: dts: sun7i: olimex-lime2: Enable ac and power supplies
Lime2 has battery connector so enable these supplies.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 9c8eecf4337a..9001b5527615 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -206,6 +206,14 @@
#include "axp209.dtsi"
+_power_supply {
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
_dcdc2 {
regulator-always-on;
regulator-min-microvolt = <100>;
--
2.11.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/20190528063544.17408-1-plaes%40plaes.org.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner H3 boot from eMMC boot partition
On Wed, May 22, 2019 at 10:58:25PM -0700, Wei-Hung Yang wrote: > Hi All, > > I found this wiki said SoC seems not boot via eMMC boot partition. > http://linux-sunxi.org/Bootable_eMMC > I have a Banana Pi M2+ with 8 GB eMMC. I try to write U-Boot (with SPL) to > eMMC boot partition, i.e. mmcblk2boot0 or mmcblk2boot1, and cannot get it > to work neither. > > Can H3 boot from boot0 or boot1 partition of eMMC? If yes, how to achieve > that? I'm using following fastboot-based flashing method on A20: http://linux-sunxi.org/Fastboot > > > Best regards, > Wei-Hung Yang > > -- > 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/7b225300-92bc-4ce1-8c9d-4edc24983f2a%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/20190523152619.e3bteg3pmrtebwzr%40plaes.org. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Bringing LVDS on A64 (VDP7) to work
On Tue, May 21, 2019 at 07:24:32AM +, Kamps, John-Eric wrote:
> Hi Jagan
>
> >Possible checks.
>
> >01. Try the bsp first, since we don't have any kind of reference documents.
> OK I will compare them
>
> >02: Identify the working pixel clock rates along with dividers
> I will check the kernel log from the original device.
>
> >03: Better get the regmap of tcon0 and other sequence for cross
> >verification.
> How can I get these values? Is there a bash command, or debugging, log
> output, syslog interface file?
Using busybox `devmem` applet or devmem2 utility.
If you're using Armbian/Debian just `apt install busybox`.
And sample usage of the devmem applet I used to debug hdmi issues on A20:
[snip]
#! /bin/bash
function dump {
base=$1
size=$2
for((i=0;i<$size;i=i+4)) ; do
addr=$(($base + $i))
data=$(busybox devmem $addr)
echo $(printf '%#x: %s' $addr $data)
done
}
function f {
dump $(( $1 )) $(( $2 ))
}
# XXX: These are A20 addresses and block sizes
# tcon0
f 0x01c0c000 0x1000
# ccu
f 0x01c2 0x400
[/snip]
--
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/20190521083909.7b5kdtbuc23emu7l%40plaes.org.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Mon, Jan 21, 2019 at 07:13:07PM +0100, Jernej Škrabec wrote: > Dne ponedeljek, 21. januar 2019 ob 14:34:33 CET je Priit Laes napisal(a): > > On Mon, Jan 21, 2019 at 08:37:29AM +0000, Priit Laes wrote: > > > On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote: > > > > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a): > > > > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > > > > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > > > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes > napisal(a): > > > > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec > wrote: > > > > > > > > > > Currently MP clocks don't consider adjusting parent rate > > > > > > > > > > even if > > > > > > > > > > they > > > > > > > > > > are allowed to do so. Such behaviour considerably lowers > > > > > > > > > > amount of > > > > > > > > > > possible rates, which is very inconvenient when such clock > > > > > > > > > > is used > > > > > > > > > > for > > > > > > > > > > pixel clock, for example. > > > > > > > > > > > > > > > > > > > > In order to improve the situation, adjusting parent rate is > > > > > > > > > > considered > > > > > > > > > > when allowed. > > > > > > > > > > > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, > > > > > > > > > > which > > > > > > > > > > does > > > > > > > > > > basically the same thing for different clock type. > > > > > > > > > > > > > > > > > > This patch seems to break the eMMC support on > > > > > > > > > Olinuxino-Lime2-eMMC > > > > > > > > > boards: > > > > > > > > > > > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly > > > > > > > > > filesystem > > > > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during > > > > > > > > > recovery > > > > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > > > > > > > > > > > I'm not familiar with A20. What is interesting is that emmc > > > > > > > > clocks > > > > > > > > don't > > > > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any > > > > > > > > difference. > > > > > > > > > > > > > > > > Can you post content of clk_summary with and without this patch? > > > > > > > > > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to > > > > > > > mount > > > > > > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > > > > > > > > > > > pre-patch working: > > > > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 > > > > > > > is > > > > > > > off?) > > > > > > > > > > > > > > post-patch not working: > > > > > > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > > > > > > > > > > > Also, attached the logs. > > > > > > > > > > > > Thanks. Just one more request. Can you enable debug messages in mmc > > > > > > driver? > > > > > > I'm interested in output of this line: > > > > > > > > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > > > > > > > > > > > > clock, rate); > > > > > > > > > > 1c11000 is eMMC: > > > > > [snip] > >
[linux-sunxi] [RESEND PATCH] drm/sun4i: hdmi: Improve compatibility with hpd-less HDMI displays
From: Priit Laes
Even though HDMI connector features hotplug detect pin (HPD), there
are older devices which do not support it. For these devices fall
back to additional check on I2C bus to probe for EDID data.
One known example is HDMI/DVI display with following edid:
$ xxd -p display.edid
000005a1e0030100150f0103800f05780a0f6ea05748
9a2610474f20010101010101010101010101010101012a08804520e0
0b10200040009536001800fd0034441a2403000a202020202020
001000310a202020202020202020202000102a4030701300
782d111e006b
$ edid-decode display.edid
EDID version: 1.3
Manufacturer: AMA Model 3e0 Serial Number 1
Digital display
Maximum image size: 15 cm x 5 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
Red: 0.6250, 0.3398
Green: 0.2841, 0.6044
Blue: 0.1494, 0.0644
White: 0.2802, 0.3105
Established timings supported:
640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
Standard timings supported:
Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
640 672 672 709 hborder 0
480 484 484 491 vborder 0
-hsync -vsync
VertFreq: 60 Hz, HorFreq: 29478 Hz
Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
Dummy block
Dummy block
Checksum: 0x6b (valid)
Now, current implementation is still flawed, as HDMI uses the
HPD signal to indicate that the source should re-read the EDID
due to change in device capabilities. With current HPD polling
implementation we would most certainly miss those notifications
as one can try just swapping two HDMI monitors really fast.
Proper fix would be skipping the HPD pin detection and relying
on just EDID fetching and acting on its changes.
CC: Russell King
Signed-off-by: Priit Laes
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 416da5376701..44d5d50b7ada 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -242,14 +242,18 @@ sun4i_hdmi_connector_detect(struct drm_connector
*connector, bool force)
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
unsigned long reg;
- if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
- reg & SUN4I_HDMI_HPD_HIGH,
- 0, 50)) {
- cec_phys_addr_invalidate(hdmi->cec_adap);
- return connector_status_disconnected;
- }
-
- return connector_status_connected;
+ /* TODO: Drop HPD polling and instead keep track of EDID changes */
+ if (!readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
+ reg & SUN4I_HDMI_HPD_HIGH,
+ 0, 50))
+ return connector_status_connected;
+
+ /* Fall back to EDID in case display does not support HPD */
+ if (!IS_ERR(hdmi->i2c) && drm_probe_ddc(hdmi->i2c))
+ return connector_status_connected;
+
+ cec_phys_addr_invalidate(hdmi->cec_adap);
+ return connector_status_disconnected;
}
static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
--
2.11.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH] ARM: dts: sun7i: olimex-lime2: Add regulators for GPIO banks
From: Priit Laes
Make sure that A20 Olimex Lime2 pin bank regulators are
properly represented.
While pin banks A, B and F are connected to 3.3V static
regulator, pin banks E and G tied with LDO3 and LDO4 regulators
with 2.8V reference.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 4e1c590eb098..3de479bfa4cf 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -174,6 +174,12 @@
};
{
+ vcc-pa-supply = <_vcc3v3>;
+ vcc-pc-supply = <_vcc3v3>;
+ vcc-pe-supply = <_ldo3>;
+ vcc-pf-supply = <_vcc3v3>;
+ vcc-pg-supply = <_ldo4>;
+
led_pins_olinuxinolime: led-pins {
pins = "PH2";
function = "gpio_out";
--
2.11.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 05/11] drm/bridge: Add Analogix anx6345 support
On Thu, Feb 14, 2019 at 09:09:51PM -0800, Vasily Khoruzhick wrote:
> From: Icenowy Zheng
>
> The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> for portable devices. This driver adds initial support for RGB to eDP
> mode, without HPD and interrupts.
>
> This is a configuration usually seen in eDP applications.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 11 +
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> .../drm/bridge/analogix/analogix-anx6345.c| 845 ++
> .../drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
> .../drm/bridge/analogix/analogix-i2c-dptx.h | 8 +
> .../bridge/analogix/analogix-i2c-txcommon.h | 3 +
> 6 files changed, 869 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
>
[ ... ]
> +
> +static int anx6345_start(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + if (!anx6345->powered)
> + anx6345_poweron(anx6345);
> +
> + /* Power on needed modules */
> + err = anx6345_clear_bits(anx6345->map[I2C_IDX_TXCOM],
> + SP_POWERDOWN_CTRL_REG,
> + SP_VIDEO_PD | SP_LINK_PD);
> +
> + err = anx6345_tx_initialization(anx6345);
> + if (err) {
> + DRM_ERROR("Failed transmitter initialization: %d\n", err);
> + goto err_poweroff;
You can move the whole err_poweroff section from below here and drop the goto.
> + }
> +
> + /*
> + * This delay seems to help keep the hardware in a good state. Without
> + * it, there are times where it fails silently.
> + */
> + usleep_range(1, 15000);
> +
> + return 0;
> +
> +err_poweroff:
> + DRM_ERROR("Failed DisplayPort transmitter initialization: %d\n", err);
> + anx6345_poweroff(anx6345);
> +
> + return err;
> +}
> +
[ ... ]
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH 1/3] videomodes: Allow EDID timings where hsync/vsync pulse is 0
On Thu, Feb 14, 2019 at 10:42:51PM +0530, Jagan Teki wrote: > Hi Anatolij, > > On Wed, Dec 19, 2018 at 6:36 PM Priit Laes wrote: > > > > From: Priit Laes > > > > Current EDID detailed timing parser errors out when either > > horizontal or vertical pulse sync width is 0, thus not > > allowing a display with EDID listed below work properly. > > > > Of-course, this is somewhat quirky HDMI display with following > > anti-features: > > - HPD pin is not usable > > - although resolution is 640x480, only top 240 pixels are visible > > > > $ xxd -p display.edid > > 000005a1e0030100150f0103800f05780a0f6ea05748 > > 9a2610474f20010101010101010101010101010101012a08804520e0 > > 0b10200040009536001800fd0034441a2403000a202020202020 > > 001000310a202020202020202020202000102a4030701300 > > 782d111e006b > > > > $ edid-decode display.edid > > EDID version: 1.3 > > Manufacturer: AMA Model 3e0 Serial Number 1 > > Digital display > > Maximum image size: 15 cm x 5 cm > > Gamma: 2.20 > > RGB color display > > First detailed timing is preferred timing > > Display x,y Chromaticity: > > Red: 0.6250, 0.3398 > > Green: 0.2841, 0.6044 > > Blue: 0.1494, 0.0644 > > White: 0.2802, 0.3105 > > Established timings supported: > > 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz > > Standard timings supported: > > Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm > > 640 672 672 709 hborder 0 > > 480 484 484 491 vborder 0 > > -hsync -vsync > >VertFreq: 60 Hz, HorFreq: 29478 Hz > > Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz > > Dummy block > > Dummy block > > Checksum: 0x6b (valid) > > > > Signed-off-by: Priit Laes > > --- > > drivers/video/videomodes.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c > > index 74bafff011..1cfeaa980f 100644 > > --- a/drivers/video/videomodes.c > > +++ b/drivers/video/videomodes.c > > @@ -396,9 +396,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct > > edid_detailed_timing *t, > > EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 || > > EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 || > > EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 || > > - EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 || > > EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 || > > - EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0 || > > /* 3d formats are not supported*/ > > EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0) > > return -EINVAL; > > Any comments? I will mark these patches to you will that be OK? This has been already applied via u-boot-video tree. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [RFT PATCH 7/9] mfd: axp20x: add USB power supply mfd cell to AXP813
On Thu, Feb 07, 2019 at 02:45:33PM +0800, Chen-Yu Tsai wrote:
> From: Quentin Schulz
>
> The AXP813 has a VBUS power input. Now that the axp20x_usb_power driver
> supports this variant, we can add an mfd cell for it to use it.
>
> Signed-off-by: Quentin Schulz
> [w...@csie.org: add commit message]
> Signed-off-by: Chen-Yu Tsai
> ---
> drivers/mfd/axp20x.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 3c97f2c0fdfe..17b115845993 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -198,6 +198,12 @@ static const struct resource
> axp22x_usb_power_supply_resources[] = {
> DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
> };
>
> +/* AXP803 and AXP813/AXP818 share the same interrupts */
> +static struct resource axp803_usb_power_supply_resources[] = {
const, if possible?
> + DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_PLUGIN, "VBUS_PLUGIN"),
> + DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
> +};
> +
> static const struct resource axp22x_pek_resources[] = {
> DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
> DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
> @@ -793,6 +799,11 @@ static const struct mfd_cell axp813_cells[] = {
> .of_compatible = "x-powers,axp813-ac-power-supply",
> .num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
> .resources = axp20x_ac_power_supply_resources,
> + }, {
> + .name = "axp20x-usb-power-supply",
> + .num_resources = ARRAY_SIZE(axp803_usb_power_supply_resources),
> + .resources = axp803_usb_power_supply_resources,
> + .of_compatible = "x-powers,axp813-usb-power-supply",
> },
> };
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote: > On Fri, Jan 18, 2019 at 02:51:26PM +0000, Priit Laes wrote: > > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > > > On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote: > > > > > > > > > It doesn't look related to the clock rate itself, since it > > > > > > > > > doesn't > > > > > > > > > change between the two cases. However, in one case the DDC > > > > > > > > > clock is > > > > > > > > > enabled and in the other it's disabled. > > > > > > > > > > > > > > > > > > Was it taken at the same time? Maybe you can try with that > > > > > > > > > patch? > > > > > > > > > http://code.bulix.org/z7jmkm-555344?raw > > > > > > > > > > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single failure. > > > > > > > > > > > > > > > > Previously I had following failure cases which are now both > > > > > > > > fixed: > > > > > > > > > > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots > > > > > > > > failed. > > > > > > > > b) u--boot with hdmi enabled switching to simplefb and then > > > > > > > > switching > > > > > > > > to kms, where previously all boots ended up with garbled screen. > > > > > > > > > > > > > > So it's not really a fix, but it really looks like the clock is > > > > > > > not > > > > > > > enabled when it should. > > > > > > > > > > > > > > Can you describe your test scenario a bit more? What are you doing > > > > > > > exactly, just booting? When do you start using the display? When > > > > > > > did > > > > > > > you capture the debugfs output that you pasted? > > > > > > > > > > > > Display is already connected via HDMI to the board. I don't really > > > > > > remove it, I just boot the device and let it start Xorg. > > > > > > Meanwhile I just ssh into the device and capture debugfs output. > > > > > > See my 3 testing scenarios below. > > > > > > > > > > > > Kernel also includes one extra patch to fall back to DDC, in case > > > > > > HPD > > > > > > fails. Mostly the same I already submitted last November [1]. > > > > > > > > > > Do you have the same issue without that patch? > > > > > > > > Can't really test this display without this patch and I do not have > > > > other > > > > HDMI/DVI screens. And this issue does not happen with other HDMI > > > > displays > > > > that I have here. > > > > > > Can't you just force the monitor to be reported as present? It's not > > > great and we don't want to merge it, but that would allow you to test > > > that setup without too many interferences. > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > 1) Booting Linux with drm.debug=0xe > > > > * Linux does not detect/enable display > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > * Linux detects display, but display is garbled, and proper edid data is > > detected: > > > > [snip] > > pll-video1 000 32700 0 > > 0 5 > >pll-video1-2x 000 65400 0 > > 0 5 > > hdmi-tmds00025153846 0 > > 0 5 > > hdmi-ddc 000 89835 0 > > 0 5 > > [/snip] > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > And also one extra patch for Linux where HDMI DDC clock marked as critical > > > > Linux detects and initializes display properly: > > [snip] > > pll-video1 110 32700 0 > > 0 5 > >pll-video1-2x 110 65400 0 > > 0 5 > > hdmi-tmds1
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Mon, Jan 21, 2019 at 08:37:29AM +, Priit Laes wrote: > On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote: > > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a): > > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes > > > > > > napisal(a): > > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > > > > Currently MP clocks don't consider adjusting parent rate even if > > > > > > > > they > > > > > > > > are allowed to do so. Such behaviour considerably lowers amount > > > > > > > > of > > > > > > > > possible rates, which is very inconvenient when such clock is > > > > > > > > used > > > > > > > > for > > > > > > > > pixel clock, for example. > > > > > > > > > > > > > > > > In order to improve the situation, adjusting parent rate is > > > > > > > > considered > > > > > > > > when allowed. > > > > > > > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which > > > > > > > > does > > > > > > > > basically the same thing for different clock type. > > > > > > > > > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > > > > > boards: > > > > > > > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly > > > > > > > filesystem > > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > > > > > > > I'm not familiar with A20. What is interesting is that emmc clocks > > > > > > don't > > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any > > > > > > difference. > > > > > > > > > > > > Can you post content of clk_summary with and without this patch? > > > > > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to > > > > > mount > > > > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > > > > > > > pre-patch working: > > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is > > > > > off?) > > > > > > > > > > post-patch not working: > > > > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > > > > > > > Also, attached the logs. > > > > > > > > Thanks. Just one more request. Can you enable debug messages in mmc > > > > driver? > > > > I'm interested in output of this line: > > > > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > > > > > > > > clock, rate); > > > > > > 1c11000 is eMMC: > > > [snip] > > > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200
Re: [linux-sunxi] [PATCH 0/9] sunxi: enable DM_MMC
On Mon, Jan 21, 2019 at 08:51:10AM +, Andre Przywara wrote:
> Hi,
>
>
>
> >>> Testing with A10 Gemei G9 Tablet, FEL mode is broken:
> >>>
> >>> a) With usb-boot via fel:
> >>>
> >>> I get following error/warning:
> >>> Loading Environment from FAT... Card did not respond to voltage select!
> >>>
> >>> => mmc list
> >>> mmc@1c0f000: 0
> >>> ### All commands below stalls for a bit (~2 seconds), but return nothing
> >>> => mmc info
> >>> => mmc dev 0
> >>> => mmc part
> >>>
> > Similar issue with A20 Olinuxino Lime2 revk with SPI.
> >
> > a) Fel mode usb-boot failure (cannot properly initialize sd / emmc)
> > b) SPI boot failure (cannot properly initialize sd / emmc)
> >
> > c) Regular SD-card boot works ok!
> > d) eMMC boot works ok!
>
> Can you please try whether the patch below fixes this? At least it worked
> for me with FEL booting my Pine64-LTS.
>
> Not totally happy with it, but it seems like we do a similar trick for
> I2C anyway, so ...
Yes, it fixes it.
Tested on A20-Olinuxino-Lime2-emmc.
PS. Comment regarding i2c looks a bit odd..
>
> Cheers,
> Andre
>
> ---
> board/sunxi/board.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ad14837291..e330367d1d 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -208,6 +208,10 @@ enum env_location env_get_location(enum env_operation
> op, int prio)
> }
> #endif
>
> +#ifdef CONFIG_DM_MMC
> +static void mmc_pinmux_setup(int sdc);
> +#endif
> +
> /* add board specific code here */
> int board_init(void)
> {
> @@ -269,6 +273,17 @@ int board_init(void)
> i2c_init_board();
> #endif
>
> +#ifdef CONFIG_DM_MMC
> + /*
> + * Temporary workaround for enabling I2C clocks until proper sunxi DM
> + * clk, reset and pinctrl drivers land.
> + */
> + mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
> +#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
> + mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
> +#endif
> +#endif /* CONFIG_DM_MMC */
> +
> /* Uses dm gpio code so do this here and not in i2c_init_board() */
> return soft_i2c_board_init();
> }
> --
> 2.14.5
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote: > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a): > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > > > Currently MP clocks don't consider adjusting parent rate even if > > > > > > > they > > > > > > > are allowed to do so. Such behaviour considerably lowers amount of > > > > > > > possible rates, which is very inconvenient when such clock is used > > > > > > > for > > > > > > > pixel clock, for example. > > > > > > > > > > > > > > In order to improve the situation, adjusting parent rate is > > > > > > > considered > > > > > > > when allowed. > > > > > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which > > > > > > > does > > > > > > > basically the same thing for different clock type. > > > > > > > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > > > > boards: > > > > > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > > > > > I'm not familiar with A20. What is interesting is that emmc clocks > > > > > don't > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any > > > > > difference. > > > > > > > > > > Can you post content of clk_summary with and without this patch? > > > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to mount > > > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > > > > > pre-patch working: > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is > > > > off?) > > > > > > > > post-patch not working: > > > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > > > > > Also, attached the logs. > > > > > > Thanks. Just one more request. Can you enable debug messages in mmc > > > driver? > > > I'm interested in output of this line: > > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > > > > > > clock, rate); > > > > 1c11000 is eMMC: > > [snip] > > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 > > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > > 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200, > > rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to > > 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: setting > > clk to 5200, rounded 5200 [8.755345] sunxi-mmc 1c11000.mmc: > > setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc > > 1c11000.mmc: setting clk to 5200, rounded 5200 > > > > Here I tried to mount partition from eMMC... > > > > [ 72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > > 5200 [ 72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop > &g
Re: [linux-sunxi] [PATCH 0/9] sunxi: enable DM_MMC
On Mon, Jan 21, 2019 at 12:54:52AM +, André Przywara wrote: > On 20/01/2019 19:51, Priit Laes wrote: > > Hi, > > > On Sat, Jan 19, 2019 at 01:30:46AM +, Andre Przywara wrote: > >> This series enables the Allwinner MMC driver to drive all SoCs with its > >> DM_MMC variant. We use the gates clock and reset support from the new > >> clock driver, but keep the actual mod clock in its somewhat hackish > >> state. Properly supporting this via the clock driver is a bit more work. > >> The per-compatible variant struct for now only holds the mod clock > >> address (which will go away), but we will need the struct later again > >> for the various timing modes. > >> > >> This allows us to eventually enable DM_MMC for all SoCs, and get rid of > >> the nasty deprecation warning. > >> > >> The first patch adds the MMC clock gates and resets to the clock driver. > >> Patch 2/9 adds support for the A80 MMC config clock, which is a bit > >> special. I can't test this, so please give this a try if you have a board. > >> > >> Patch 3 uses the new clocks in the MMC driver, the following three patches > >> add the remaining compatible strings along with their required mod clock > >> addresses. > >> > >> Patch 7 fixes the Pine64-LTS board, while patch 8 eventually enables > >> everything. Patch 9 is some comment fix to make it easier to reason > >> about what part of the driver is for DM_MMC and which is not. > >> > >> I successfully compiled the HEAD for all 142 Allwinner boards, also > >> compiled all patches for selected boards. > >> > >> This was briefly tested on Pine-H64 (H6), Pine64-LTS (A64), OrangePi PC 2 > >> (H5), OrangePi Zero (H2+) and BananaPi-M1 (A20). > >> > >> Please run it on every board that you can get hold of to give this series > >> a good shake. > > > > Testing with A10 Gemei G9 Tablet, FEL mode is broken: > > > > a) With usb-boot via fel: > > > > I get following error/warning: > > Loading Environment from FAT... Card did not respond to voltage select! > > > > => mmc list > > mmc@1c0f000: 0 > > ### All commands below stalls for a bit (~2 seconds), but return nothing > > => mmc info > > => mmc dev 0 > > => mmc part Similar issue with A20 Olinuxino Lime2 revk with SPI. a) Fel mode usb-boot failure (cannot properly initialize sd / emmc) b) SPI boot failure (cannot properly initialize sd / emmc) c) Regular SD-card boot works ok! d) eMMC boot works ok! > Ah, thanks for mentioning that. Can reproduce this on the Pine64-LTS. > And I was already wondering why we wouldn't need the pinctrl parts I was > working on ... > > So if we boot from SD card, the SPL sets up the pinmux for the SD pins, > and stuff works. For U-Boot proper we rely on board_mmc_init() to do > this for us, but this gets only called for !DM_MMC configurations. > If we boot with a SPL which doesn't initialise the MMC (booting via FEL > or SPI or NAND), the pinmux setup is missing and it fails. > > If anyone has a clever idea how to fix this without too much hacking and > without bringing in a DM_PINCTRL driver, I am all ears. Well, we know that there are basically only a few SPL boot options.. > > Thanks for testing and the report! > > Cheers, > Andre. > > > > > b) When booting from SD-card [1], card is properly found, identified and > > even partitions are there. > > > > dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 seek=8 bs=1024 > > > > > >> This goes on top of current sunxi/master (543049ab5906) and is available > >> on https://github.com/apritzel/u-boot/commits/sunxi-dm. > >> > >> This replaces Jagan's v2 series "mmc: sunxi: Enable DM_MMC" in a more > >> driver model compliant way, borrowing two patches from him. > >> > >> Cheers, > >> Andre. > >> > >> Andre Przywara (7): > >> sunxi: clk: add MMC gates/resets > >> sunxi: clk: A80: add MMC clock support > >> mmc: sunxi: Add DM clk and reset support > >> mmc: sunxi: Add H6 support > >> mmc: sunxi: Add A80 support > >> mmc: sunxi: Honour non-removable property in DT > >> mmc: sunxi: Mark end of DM_MMC #ifdefs > >> > >> Jagan Teki (2): > >> mmc: sunxi: Add missing compatible strings > >> arm: sunxi: Enable DM_MMC > >> > >> arch/arm/Kconfig | 1 + > >> arch/arm/mach-sunxi/Kconfig | 1 - > >> configs/L
Re: [linux-sunxi] [PATCH 0/9] sunxi: enable DM_MMC
On Sat, Jan 19, 2019 at 01:30:46AM +, Andre Przywara wrote: > This series enables the Allwinner MMC driver to drive all SoCs with its > DM_MMC variant. We use the gates clock and reset support from the new > clock driver, but keep the actual mod clock in its somewhat hackish > state. Properly supporting this via the clock driver is a bit more work. > The per-compatible variant struct for now only holds the mod clock > address (which will go away), but we will need the struct later again > for the various timing modes. > > This allows us to eventually enable DM_MMC for all SoCs, and get rid of > the nasty deprecation warning. > > The first patch adds the MMC clock gates and resets to the clock driver. > Patch 2/9 adds support for the A80 MMC config clock, which is a bit > special. I can't test this, so please give this a try if you have a board. > > Patch 3 uses the new clocks in the MMC driver, the following three patches > add the remaining compatible strings along with their required mod clock > addresses. > > Patch 7 fixes the Pine64-LTS board, while patch 8 eventually enables > everything. Patch 9 is some comment fix to make it easier to reason > about what part of the driver is for DM_MMC and which is not. > > I successfully compiled the HEAD for all 142 Allwinner boards, also > compiled all patches for selected boards. > > This was briefly tested on Pine-H64 (H6), Pine64-LTS (A64), OrangePi PC 2 > (H5), OrangePi Zero (H2+) and BananaPi-M1 (A20). > > Please run it on every board that you can get hold of to give this series > a good shake. Testing with A10 Gemei G9 Tablet, FEL mode is broken: a) With usb-boot via fel: I get following error/warning: Loading Environment from FAT... Card did not respond to voltage select! => mmc list mmc@1c0f000: 0 ### All commands below stalls for a bit (~2 seconds), but return nothing => mmc info => mmc dev 0 => mmc part b) When booting from SD-card [1], card is properly found, identified and even partitions are there. dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 seek=8 bs=1024 > This goes on top of current sunxi/master (543049ab5906) and is available > on https://github.com/apritzel/u-boot/commits/sunxi-dm. > > This replaces Jagan's v2 series "mmc: sunxi: Enable DM_MMC" in a more > driver model compliant way, borrowing two patches from him. > > Cheers, > Andre. > > Andre Przywara (7): > sunxi: clk: add MMC gates/resets > sunxi: clk: A80: add MMC clock support > mmc: sunxi: Add DM clk and reset support > mmc: sunxi: Add H6 support > mmc: sunxi: Add A80 support > mmc: sunxi: Honour non-removable property in DT > mmc: sunxi: Mark end of DM_MMC #ifdefs > > Jagan Teki (2): > mmc: sunxi: Add missing compatible strings > arm: sunxi: Enable DM_MMC > > arch/arm/Kconfig | 1 + > arch/arm/mach-sunxi/Kconfig | 1 - > configs/Linksprite_pcDuino3_defconfig | 1 - > drivers/clk/sunxi/clk_a10.c | 4 +++ > drivers/clk/sunxi/clk_a10s.c | 3 ++ > drivers/clk/sunxi/clk_a23.c | 6 > drivers/clk/sunxi/clk_a31.c | 8 + > drivers/clk/sunxi/clk_a64.c | 6 > drivers/clk/sunxi/clk_a80.c | 28 - > drivers/clk/sunxi/clk_a83t.c | 6 > drivers/clk/sunxi/clk_h3.c| 6 > drivers/clk/sunxi/clk_h6.c| 6 > drivers/clk/sunxi/clk_r40.c | 8 + > drivers/mmc/sunxi_mmc.c | 59 > +-- > 14 files changed, 131 insertions(+), 12 deletions(-) > > -- > 2.14.5 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > On Fri, Jan 18, 2019 at 10:10:53AM +0000, Priit Laes wrote: > > > > > > > It doesn't look related to the clock rate itself, since it doesn't > > > > > > > change between the two cases. However, in one case the DDC clock > > > > > > > is > > > > > > > enabled and in the other it's disabled. > > > > > > > > > > > > > > Was it taken at the same time? Maybe you can try with that patch? > > > > > > > http://code.bulix.org/z7jmkm-555344?raw > > > > > > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single failure. > > > > > > > > > > > > Previously I had following failure cases which are now both fixed: > > > > > > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots failed. > > > > > > b) u--boot with hdmi enabled switching to simplefb and then > > > > > > switching > > > > > > to kms, where previously all boots ended up with garbled screen. > > > > > > > > > > So it's not really a fix, but it really looks like the clock is not > > > > > enabled when it should. > > > > > > > > > > Can you describe your test scenario a bit more? What are you doing > > > > > exactly, just booting? When do you start using the display? When did > > > > > you capture the debugfs output that you pasted? > > > > > > > > Display is already connected via HDMI to the board. I don't really > > > > remove it, I just boot the device and let it start Xorg. > > > > Meanwhile I just ssh into the device and capture debugfs output. > > > > See my 3 testing scenarios below. > > > > > > > > Kernel also includes one extra patch to fall back to DDC, in case HPD > > > > fails. Mostly the same I already submitted last November [1]. > > > > > > Do you have the same issue without that patch? > > > > Can't really test this display without this patch and I do not have other > > HDMI/DVI screens. And this issue does not happen with other HDMI displays > > that I have here. > > Can't you just force the monitor to be reported as present? It's not > great and we don't want to merge it, but that would allow you to test > that setup without too many interferences. Baseline is clean u-boot / linux. U-boot does not detect/enable display. 1) Booting Linux with drm.debug=0xe * Linux does not detect/enable display 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e * Linux detects display, but display is garbled, and proper edid data is detected: [snip] pll-video1 000 32700 0 0 5 pll-video1-2x 000 65400 0 0 5 hdmi-tmds00025153846 0 0 5 hdmi-ddc 000 89835 0 0 5 [/snip] 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e And also one extra patch for Linux where HDMI DDC clock marked as critical Linux detects and initializes display properly: [snip] pll-video1 110 32700 0 0 5 pll-video1-2x 110 65400 0 0 5 hdmi-tmds11025153846 0 0 5 hdmi-ddc 110 89835 0 0 5 [/snip] > 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. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Thu, Jan 17, 2019 at 12:33:40PM +0100, Maxime Ripard wrote: > On Wed, Jan 16, 2019 at 08:35:16PM +0000, Priit Laes wrote: > > On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote: > > > Hi Priit, > > > > > > On Wed, Jan 16, 2019 at 07:58:54AM +, Priit Laes wrote: > > > > > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote: > > > > > > I have a somewhat curious case with one HDMI/DVI screen that fails > > > > > > to initialize properly every 6-7 boots. The display itself is also > > > > > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width > > > > > > is set to 0 in EDID), but I suspect there could be some issues > > > > > > regarding timing in A20 HDMI driver in Linux. > > > > > > > > > > ... > > > > > > > > > It doesn't look related to the clock rate itself, since it doesn't > > > > > change between the two cases. However, in one case the DDC clock is > > > > > enabled and in the other it's disabled. > > > > > > > > > > Was it taken at the same time? Maybe you can try with that patch? > > > > > http://code.bulix.org/z7jmkm-555344?raw > > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single failure. > > > > > > > > Previously I had following failure cases which are now both fixed: > > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots failed. > > > > b) u--boot with hdmi enabled switching to simplefb and then switching > > > > to kms, where previously all boots ended up with garbled screen. > > > > > > So it's not really a fix, but it really looks like the clock is not > > > enabled when it should. > > > > > > Can you describe your test scenario a bit more? What are you doing > > > exactly, just booting? When do you start using the display? When did > > > you capture the debugfs output that you pasted? > > > > Display is already connected via HDMI to the board. I don't really > > remove it, I just boot the device and let it start Xorg. > > Meanwhile I just ssh into the device and capture debugfs output. > > See my 3 testing scenarios below. > > > > Kernel also includes one extra patch to fall back to DDC, in case HPD > > fails. Mostly the same I already submitted last November [1]. > > Do you have the same issue without that patch? Can't really test this display without this patch and I do not have other HDMI/DVI screens. And this issue does not happen with other HDMI displays that I have here. > > For u-boot I have also some extra patches, to detect HPD-less HDMI > > displays [2] + relax some EDID timing checks [3] so u-boot can actually > > initialize my screen. > > Do you have the same issues without those patches? Yes. Without those patches display is not detected by u-boot (issues with missing hpd pin and stricter edid checks), so kernel initializes display. Disabling those patches is mostly the same as disabling the HDMI support in u-boot the kernel side. > > So first configuration with 100% failures: > > 1) u-boot initializes HDMI ( A20-OLinuXino-Lime2-eMMC_defconfig ) > > 2) Linux switches to simplefb > > ... somewhere around here blinking cursor is replaced with garbage > > on screen > > 3) Linux switches to kms > > 4) Xorg starts > > > > Second scenario with failure every 6-7 boots: > > 1) Disabled HDMI in u-boot for my board > > 2) Linux sets up kms (sometimes fails here) > > 3) Xorg starts > > 4) ssh to machine and take the clock dump > > Do you have the DRM fbdev emulation enabled in that case or is Xorg > the first to setup the kms driver? Do you have some logs and a > configuration? Xorg logs for scenario 1 and 2 are basically the same whether or not HDMI is enabled in u-boot. Now, differences arise when DDC clock is marked as critical. Attached files: * Xorg.0.ddc-critical.log * Xorg.0.ddc-default.log Also attached drm.debug outputs. > 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. For more options, visit https://groups.google.com/d/optout. Linux with (edid fallback + clk_critical patch) [12.552] X.Org X Server 1.19.2 Release Date: 2017-03-02 [12.553] X Protocol Version 11, Rev
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > Currently MP clocks don't consider adjusting parent rate even if they > > > > > are allowed to do so. Such behaviour considerably lowers amount of > > > > > possible rates, which is very inconvenient when such clock is used for > > > > > pixel clock, for example. > > > > > > > > > > In order to improve the situation, adjusting parent rate is considered > > > > > when allowed. > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which does > > > > > basically the same thing for different clock type. > > > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > > boards: > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > I'm not familiar with A20. What is interesting is that emmc clocks don't > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any difference. > > > > > > Can you post content of clk_summary with and without this patch? > > > > In both cases I booted from FEL with rootfs on sdcard and tried to mount > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > pre-patch working: > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is off?) > > > > post-patch not working: > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > Also, attached the logs. > > Thanks. Just one more request. Can you enable debug messages in mmc driver? > I'm interested in output of this line: > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > clock, rate); 1c11000 is eMMC: [snip] [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded 40 [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [8.755345] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 Here I tried to mount partition from eMMC... [ 72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5200 [ 72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop command [ 73.268999] sunxi-mmc 1c11000.mmc: send stop command failed [/snip] And clock tree: [snip] pll-periph-base330 12 0 0 5 pll-periph 660 6 0 0 5 mmc2 3305000 0 0 5 mmc2_sample 1105000 0 120 5 mmc2_output 1105000 060 5 ahb 18 180 3 0 0 5 ahb-mmc2 110 3 0 0 5 [/snip] And without patch: [snip] [2.003341] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.019479] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.039144] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [2.047129] sunxi-mmc 1c11000.mmc: XXX: setting clk to 40, rounded 40 [
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Wed, Jan 16, 2019 at 08:24:42PM +0100, Maxime Ripard wrote: > Hi Priit, > > On Wed, Jan 16, 2019 at 07:58:54AM +0000, Priit Laes wrote: > > > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote: > > > > I have a somewhat curious case with one HDMI/DVI screen that fails > > > > to initialize properly every 6-7 boots. The display itself is also > > > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width > > > > is set to 0 in EDID), but I suspect there could be some issues > > > > regarding timing in A20 HDMI driver in Linux. > > > > > > ... > > > > > It doesn't look related to the clock rate itself, since it doesn't > > > change between the two cases. However, in one case the DDC clock is > > > enabled and in the other it's disabled. > > > > > > Was it taken at the same time? Maybe you can try with that patch? > > > http://code.bulix.org/z7jmkm-555344?raw > > > > Thanks, after doing ~50+ boots I haven't seen a single failure. > > > > Previously I had following failure cases which are now both fixed: > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots failed. > > b) u--boot with hdmi enabled switching to simplefb and then switching > > to kms, where previously all boots ended up with garbled screen. > > So it's not really a fix, but it really looks like the clock is not > enabled when it should. > > Can you describe your test scenario a bit more? What are you doing > exactly, just booting? When do you start using the display? When did > you capture the debugfs output that you pasted? Display is already connected via HDMI to the board. I don't really remove it, I just boot the device and let it start Xorg. Meanwhile I just ssh into the device and capture debugfs output. See my 3 testing scenarios below. Kernel also includes one extra patch to fall back to DDC, in case HPD fails. Mostly the same I already submitted last November [1]. For u-boot I have also some extra patches, to detect HPD-less HDMI displays [2] + relax some EDID timing checks [3] so u-boot can actually initialize my screen. So first configuration with 100% failures: 1) u-boot initializes HDMI ( A20-OLinuXino-Lime2-eMMC_defconfig ) 2) Linux switches to simplefb ... somewhere around here blinking cursor is replaced with garbage on screen 3) Linux switches to kms 4) Xorg starts Second scenario with failure every 6-7 boots: 1) Disabled HDMI in u-boot for my board 2) Linux sets up kms (sometimes fails here) 3) Xorg starts 4) ssh to machine and take the clock dump Third scenario with no failures (but not suitable in long term..) 1) Disabled sun4i HDMI driver (CONFIG_DRM_SUN4I_HDMI=n) in Linux 2) u-boot sets up HDMI 3) Linux continues with simplefb 4) Xorg (with fbdev) starts [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/613168.html [2] https://lists.denx.de/pipermail/u-boot/2018-December/352541.html [3] https://lists.denx.de/pipermail/u-boot/2018-December/352540.html > > 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. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > Currently MP clocks don't consider adjusting parent rate even if they > > > are allowed to do so. Such behaviour considerably lowers amount of > > > possible rates, which is very inconvenient when such clock is used for > > > pixel clock, for example. > > > > > > In order to improve the situation, adjusting parent rate is considered > > > when allowed. > > > > > > This code is inspired by clk_divider_bestdiv() function, which does > > > basically the same thing for different clock type. > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC boards: > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > I'm not familiar with A20. What is interesting is that emmc clocks don't have > CLK_SET_RATE_PARENT flag set, so you shouldn't see any difference. > > Can you post content of clk_summary with and without this patch? In both cases I booted from FEL with rootfs on sdcard and tried to mount partition from eMMC to /mnt. With your patch, last step it fails. pre-patch working: pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is off?) post-patch not working: pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) Also, attached the logs. > > Best regards, > Jernej > > > > > $ git bisect log > > git bisect start > > # good: [3df407b2a5346db1c48809706ece7a8616c79e0b] mmc: dw_mmc-bluefield: > > simplify the probe() function git bisect good > > 3df407b2a5346db1c48809706ece7a8616c79e0b > > # bad: [00d59fde8532b2d42e80909d2e58678755e04da9] Merge tag 'mmc-v4.21' of > > git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect bad > > 00d59fde8532b2d42e80909d2e58678755e04da9 > > # good: [01e421feec0817bb3141eaae4c517410d193d440] Merge branch 'fixes' into > > next git bisect good 01e421feec0817bb3141eaae4c517410d193d440 > > # bad: [1eefdec18eded41833401cfd64749643ff72e7da] Merge branch > > 'locking-core-for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad > > 1eefdec18eded41833401cfd64749643ff72e7da > > # good: [eaa76499711535fd64d747cc4ef0d78ab0fd41c6] Merge tag 'mtd/for-4.21' > > of git://git.infradead.org/linux-mtd git bisect good > > eaa76499711535fd64d747cc4ef0d78ab0fd41c6 > > # good: [4e4390ad067a61ce4e7607bd0df31f19a4caa36a] Merge tag > > 'leds-for-4.21-rc1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds git > > bisect good 4e4390ad067a61ce4e7607bd0df31f19a4caa36a > > # bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next git bisect > > bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698 > > # bad: [e4b99d415c3908581d4703203e1e805f043a3e71] Merge branch > > 'irq-core-for-linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad > > e4b99d415c3908581d4703203e1e805f043a3e71 > > # bad: [ffe05540d18013db62c43627836a3638e9a2c7aa] Merge branches > > 'clk-renesas', 'clk-allwinner', 'clk-tegra', 'clk-meson' and 'clk-rockchip' > > into clk-next git bisect bad ffe05540d18013db62c43627836a3638e9a2c7aa > > # good: [1a501c8defe950571316d5ddd917bf44f5ed7bd4] Merge branches > > 'clk-managed-registration', 'clk-spdx', 'clk-remove-basic' and > > 'clk-ops-const' into clk-next git bisect good > > 1a501c8defe950571316d5ddd917bf44f5ed7bd4 > > # good: [e74581b79ddd9b49b8c61e2791fc4dffc0245afb] Merge tag > > 'meson-clk-4.21-2' of https://github.com/BayLibre/clk-meson into clk-meson > > git bisect good e74581b79ddd9b49b8c61e2791fc4dffc0245afb > > # good: [60baf75e3f5b76043c25328ac0c5320aaef5ea41] Merge tag > > 'clk-renesas-for-v4.21-tag2' of > > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into > > clk-renesas git bisect good 60baf75e3f5b76043c25328ac0c5320aaef5ea41 > > # bad: [a41f85b6017ee20952a60e4330bcae2527fe2c2a] Merge tag > > 'sunxi-clk-for-4.21' of > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into > > clk-allwinner git bisect bad a41f85b6017ee20952a60e4330bcae2527fe2c2a > > # bad: [ee678706e46d0d185c27cc214ad97828e0643159] clk: sunxi-ng: a64: Fix > > gate bit of DSI DPHY git bisect bad > > ee678
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Tue, Jan 15, 2019 at 10:49:51AM +0100, Maxime Ripard wrote: > Hi, > > (Sending those kind of bug reports to linux-sunxi doesn't really work, > you should Cc at least the ML involved in the development of the > driver at fault). OK, sorry for that. > > On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote: > > I have a somewhat curious case with one HDMI/DVI screen that fails > > to initialize properly every 6-7 boots. The display itself is also > > somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width > > is set to 0 in EDID), but I suspect there could be some issues > > regarding timing in A20 HDMI driver in Linux. > > ... > It doesn't look related to the clock rate itself, since it doesn't > change between the two cases. However, in one case the DDC clock is > enabled and in the other it's disabled. > > Was it taken at the same time? Maybe you can try with that patch? > http://code.bulix.org/z7jmkm-555344?raw Thanks, after doing ~50+ boots I haven't seen a single failure. Previously I had following failure cases which are now both fixed: a) Linux without u-boot HDMI, where one in every 6-7 boots failed. b) u--boot with hdmi enabled switching to simplefb and then switching to kms, where previously all boots ended up with garbled screen. Priit :) > > 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. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] HDMI/DVI spurious failure
Heya! I have a somewhat curious case with one HDMI/DVI screen that fails to initialize properly every 6-7 boots. The display itself is also somewhat flawed (missing HPD pin and the VSYNC/HSYNC pulse width is set to 0 in EDID), but I suspect there could be some issues regarding timing in A20 HDMI driver in Linux. HW: Olinuxino Lime2 eMMC The same display works out of the box on Raspberry Pi. And I haven't seen it failing in u-boot on A20 Lime2 hw. I have disabled HDMI support in U-boot (there's another issue with simplefb handover to modesetting, but I currently try to leave u-boot out of the equation), so kernel itselfs sets up the display. Basically the only differences I have found are some timing differences in DRM logs and following discrepancey in clock tree when comparing failing and working boots: --- clks-failing.dump 2019-01-14 14:45:24.026279493 +0200 +++ clks-ok.dump2019-01-14 14:29:59.799715126 +0200 @@ -6,7 +6,7 @@ mii_phy_tx 0002500 0 0 5 osc32k 000 32768 0 0 5 osc24M 2212400 0 0 5 -hosc 5512400 0 0 5 +hosc 6612400 0 0 5 out-b 000 32000 0 0 5 out-a 000 32000 0 0 5 hdmi1-slow 0002400 0 0 5 @@ -52,10 +52,10 @@ apb1-i2c1 1102400 0 0 5 apb1-i2c0 1102400 0 0 5 pll-gpu000 12 0 0 5 - pll-video1 000 32700 0 0 5 - pll-video1-2x 000 65400 0 0 5 - hdmi-tmds00025153846 0 0 5 -hdmi-ddc 000 89835 0 0 5 + pll-video1 110 32700 0 0 5 + pll-video1-2x 110 65400 0 0 5 + hdmi-tmds11025153846 0 0 5 +hdmi-ddc 110 89835 0 0 5 pll-periph-base330 12 0 0 5 mbus110 3 0 0 5 pll-periph-sata 110 1 0 0 5 Any hints what else to debug? Päikest, Priit :) -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/7] mmc: sunxi: Enable DM_MMC
On Mon, Jan 14, 2019 at 10:39:37AM +, Priit Laes wrote:
> On Mon, Jan 14, 2019 at 04:00:44PM +0530, Jagan Teki wrote:
> > On Mon 14 Jan, 2019, 3:53 PM Priit Laes >
> > > On Mon, Jan 14, 2019 at 03:40:37PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 14, 2019 at 3:05 PM Priit Laes wrote:
> > > > >
> > > > > On Fri, Jan 11, 2019 at 11:34:07PM +0530, Jagan Teki wrote:
> > > > > > I thought of waiting this till CLK framework gets Mainline,
> > > > > > but migration deadline for DM_MMC and BLK seems expiring in
> > > > > > next release. So instead of doing so huddle and make some last
> > > > > > minute changes, I have managed to add CLK, Reset code for mmc
> > > > > > driver via driver data.
> > > > >
> > > > > U-Boot 2019.01-rc3-00084-g0ce29380cf (Jan 14 2019 - 11:22:13 +0200)
> > > Allwinner Technology
> > > > >
> > > > > CPU: Allwinner A20 (SUN7I)
> > > > > Model: Olimex A20-OLinuXino-LIME2-eMMC
> > > > > I2C: ready
> > > > > DRAM: 1 GiB
> > > > > MMC: mmc@1c0f000: 0, mmc@1c11000: 1
> > > > > Loading Environment from FAT... Card did not respond to voltage
> > > > > select!
> > > > >
> > > > > eMMC seems to be broken:
> > > > > => mmc list
> > > > > mmc@1c0f000: 0
> > > > > mmc@1c11000: 1
> > > > > => mmc dev 1
> > > > > => mmc dev 0
> > > > > MMC: no card present
> > > > > => mmc part
> > > > > MMC: no card present
> > > > > => mmc info
> > > > > MMC: no card present
> > > >
> > > > Can you try this
> > > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > > > index 33f1ec5e5a..7fab88c47f 100644
> > > > --- a/drivers/mmc/sunxi_mmc.c
> > > > +++ b/drivers/mmc/sunxi_mmc.c
> > > > @@ -648,7 +648,7 @@ static int sunxi_mmc_probe(struct udevice *dev)
> > > > gate_reg = (void *)ccu_reg + priv->variant->gate_offset;
> > > > setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no)));
> > > >
> > > > - if ((!IS_ENABLED(CONFIG_MACH_SUN4I)) &&
> > > priv->variant->has_reset) {
> > > > + if ((!IS_ENABLED(CONFIG_MACH_SUN7I)) &&
> > > priv->variant->has_reset) {
> > > > reset_reg = (void *)ccu_reg +
> > > priv->variant->reset_offset;
> > > > setbits_le32(reset_reg, BIT(priv->mmc_no +
> > > > priv->variant->reset_start_bit));
> > >
> > > Still fails:
> > >
> > > MMC: no card present
> > > scanning bus for devices...
> > > Found 0 device(s).
> > >
> > > Device 0: unknown device
> > >
> > > Device 0: unknown device
> > >
> >
> > Can you print the reg values mclk and gate_reg. I have Lime2 which is fine
> > but doesn't have eMMC.
>
> mclk0: 0x0
> gate0: 0x200c141
> mclk2: 0x0
> gate2: 0x200c541
I managed to mess it up:
XXX: mclk0: 0x8050
XXX: gate0: 0x200c141
XXX: mclk2: 0x8050
XXX: gate2: 0x200c541
This is what you want:
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 33f1ec5e5a..ac396d8d89 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -684,6 +684,9 @@ static int sunxi_mmc_probe(struct udevice *dev)
upriv->mmc = >mmc;
+printf("XXX: mclk%d: 0x%x\n", priv->mmc_no, *priv->mclkreg);
+printf("XXX: gate%d: 0x%x\n", priv->mmc_no, *gate_reg);
+
/* Reset controller */
writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
udelay(1000);
>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/7] mmc: sunxi: Enable DM_MMC
On Mon, Jan 14, 2019 at 04:00:44PM +0530, Jagan Teki wrote:
> On Mon 14 Jan, 2019, 3:53 PM Priit Laes
> > On Mon, Jan 14, 2019 at 03:40:37PM +0530, Jagan Teki wrote:
> > > On Mon, Jan 14, 2019 at 3:05 PM Priit Laes wrote:
> > > >
> > > > On Fri, Jan 11, 2019 at 11:34:07PM +0530, Jagan Teki wrote:
> > > > > I thought of waiting this till CLK framework gets Mainline,
> > > > > but migration deadline for DM_MMC and BLK seems expiring in
> > > > > next release. So instead of doing so huddle and make some last
> > > > > minute changes, I have managed to add CLK, Reset code for mmc
> > > > > driver via driver data.
> > > >
> > > > U-Boot 2019.01-rc3-00084-g0ce29380cf (Jan 14 2019 - 11:22:13 +0200)
> > Allwinner Technology
> > > >
> > > > CPU: Allwinner A20 (SUN7I)
> > > > Model: Olimex A20-OLinuXino-LIME2-eMMC
> > > > I2C: ready
> > > > DRAM: 1 GiB
> > > > MMC: mmc@1c0f000: 0, mmc@1c11000: 1
> > > > Loading Environment from FAT... Card did not respond to voltage select!
> > > >
> > > > eMMC seems to be broken:
> > > > => mmc list
> > > > mmc@1c0f000: 0
> > > > mmc@1c11000: 1
> > > > => mmc dev 1
> > > > => mmc dev 0
> > > > MMC: no card present
> > > > => mmc part
> > > > MMC: no card present
> > > > => mmc info
> > > > MMC: no card present
> > >
> > > Can you try this
> > > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> > > index 33f1ec5e5a..7fab88c47f 100644
> > > --- a/drivers/mmc/sunxi_mmc.c
> > > +++ b/drivers/mmc/sunxi_mmc.c
> > > @@ -648,7 +648,7 @@ static int sunxi_mmc_probe(struct udevice *dev)
> > > gate_reg = (void *)ccu_reg + priv->variant->gate_offset;
> > > setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no)));
> > >
> > > - if ((!IS_ENABLED(CONFIG_MACH_SUN4I)) &&
> > priv->variant->has_reset) {
> > > + if ((!IS_ENABLED(CONFIG_MACH_SUN7I)) &&
> > priv->variant->has_reset) {
> > > reset_reg = (void *)ccu_reg +
> > priv->variant->reset_offset;
> > > setbits_le32(reset_reg, BIT(priv->mmc_no +
> > > priv->variant->reset_start_bit));
> >
> > Still fails:
> >
> > MMC: no card present
> > scanning bus for devices...
> > Found 0 device(s).
> >
> > Device 0: unknown device
> >
> > Device 0: unknown device
> >
>
> Can you print the reg values mclk and gate_reg. I have Lime2 which is fine
> but doesn't have eMMC.
mclk0: 0x0
gate0: 0x200c141
mclk2: 0x0
gate2: 0x200c541
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/7] mmc: sunxi: Enable DM_MMC
On Mon, Jan 14, 2019 at 03:40:37PM +0530, Jagan Teki wrote:
> On Mon, Jan 14, 2019 at 3:05 PM Priit Laes wrote:
> >
> > On Fri, Jan 11, 2019 at 11:34:07PM +0530, Jagan Teki wrote:
> > > I thought of waiting this till CLK framework gets Mainline,
> > > but migration deadline for DM_MMC and BLK seems expiring in
> > > next release. So instead of doing so huddle and make some last
> > > minute changes, I have managed to add CLK, Reset code for mmc
> > > driver via driver data.
> >
> > U-Boot 2019.01-rc3-00084-g0ce29380cf (Jan 14 2019 - 11:22:13 +0200)
> > Allwinner Technology
> >
> > CPU: Allwinner A20 (SUN7I)
> > Model: Olimex A20-OLinuXino-LIME2-eMMC
> > I2C: ready
> > DRAM: 1 GiB
> > MMC: mmc@1c0f000: 0, mmc@1c11000: 1
> > Loading Environment from FAT... Card did not respond to voltage select!
> >
> > eMMC seems to be broken:
> > => mmc list
> > mmc@1c0f000: 0
> > mmc@1c11000: 1
> > => mmc dev 1
> > => mmc dev 0
> > MMC: no card present
> > => mmc part
> > MMC: no card present
> > => mmc info
> > MMC: no card present
>
> Can you try this
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 33f1ec5e5a..7fab88c47f 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -648,7 +648,7 @@ static int sunxi_mmc_probe(struct udevice *dev)
> gate_reg = (void *)ccu_reg + priv->variant->gate_offset;
> setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no)));
>
> - if ((!IS_ENABLED(CONFIG_MACH_SUN4I)) && priv->variant->has_reset) {
> + if ((!IS_ENABLED(CONFIG_MACH_SUN7I)) && priv->variant->has_reset) {
> reset_reg = (void *)ccu_reg + priv->variant->reset_offset;
> setbits_le32(reset_reg, BIT(priv->mmc_no +
> priv->variant->reset_start_bit));
Still fails:
MMC: no card present
scanning bus for devices...
Found 0 device(s).
Device 0: unknown device
Device 0: unknown device
> >
> > Setting up a 640x480 dvi console (overscan 0x0)
> > In:serial
> > Out: vga
> > Err: vga
> > Allwinner mUSB OTG (Peripheral)
> > SCSI: SATA link 0 timeout.
> > AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> > flags: ncq stag pm led clo only pmp pio slum part ccc apst
> >
> > Net: sunxi_set_gate: (CLK#66) unhandled
> > eth0: ethernet@1c5
> >
> >
> > And also CLK#66 message
>
> This is expected, looking EMAC clock from dw driver, will handle in
> next series. to be noted we enable print.
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 0/7] mmc: sunxi: Enable DM_MMC
On Fri, Jan 11, 2019 at 11:34:07PM +0530, Jagan Teki wrote: > I thought of waiting this till CLK framework gets Mainline, > but migration deadline for DM_MMC and BLK seems expiring in > next release. So instead of doing so huddle and make some last > minute changes, I have managed to add CLK, Reset code for mmc > driver via driver data. U-Boot 2019.01-rc3-00084-g0ce29380cf (Jan 14 2019 - 11:22:13 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-OLinuXino-LIME2-eMMC I2C: ready DRAM: 1 GiB MMC: mmc@1c0f000: 0, mmc@1c11000: 1 Loading Environment from FAT... Card did not respond to voltage select! eMMC seems to be broken: => mmc list mmc@1c0f000: 0 mmc@1c11000: 1 => mmc dev 1 => mmc dev 0 MMC: no card present => mmc part MMC: no card present => mmc info MMC: no card present Setting up a 640x480 dvi console (overscan 0x0) In:serial Out: vga Err: vga Allwinner mUSB OTG (Peripheral) SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: sunxi_set_gate: (CLK#66) unhandled eth0: ethernet@1c5 And also CLK#66 message > > Add for all Allwinner SoC's and enable at arch/arm/Kconfig. > > I shall merge this in comming MW, so early test feel better > to go for the release. Request to test respective board takers. > > Any inputs, > Jagan. > > Jagan Teki (7): > mmc: sunxi: Configure reset support for DM_MMC > mmc: sunxi: Add A83T emmc compatible > mmc: sunxi: Add mmc, emmc H5/A64 compatible > mmc: sunxi: Add DM_MMC support for H6 > mmc: sunxi: Add DM_MMC support for A80 > arm: sunxi: Enable DM_MMC > arm: dts: sunxi: Enumerate MMC2 as MMC1 > > arch/arm/Kconfig | 1 + > arch/arm/dts/sunxi-u-boot.dtsi| 4 + > .../include/asm/arch-sunxi/clock_sun50i_h6.h | 3 + > arch/arm/mach-sunxi/Kconfig | 1 - > configs/Linksprite_pcDuino3_defconfig | 1 - > drivers/mmc/sunxi_mmc.c | 73 ++- > 6 files changed, 79 insertions(+), 4 deletions(-) > > -- > 2.18.0.321.gffc6fa0e3 > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH] arm: sunxi: Enable SPL/SPI boot for Olinuxino Lime2-eMMC boards
From: Priit Laes Starting from revision K the Olimex-Lime2-eMMC boards include eMMC 5.x chip. Unfortunately, the internal brom in the A20 cannot reliably initialize those chips resulting in random boot failures on those boards. To overcome this, all the latest Lime2-eMMC boards are populated with 16MB SPI flash and therefore enable support for SPI SPL boot. For now, SPI flash can be managed using sunxi-fel's spiflash tools. Signed-off-by: Priit Laes --- configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig b/configs/A20-OLinuXino-Lime2-eMMC_defconfig index d37dc2906a..ac6213e364 100644 --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_SPL=y +CONFIG_SPL_SPI_SUNXI=y CONFIG_MACH_SUN7I=y CONFIG_DRAM_CLK=384 CONFIG_MMC0_CD_PIN="PH1" -- 2.11.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > Currently MP clocks don't consider adjusting parent rate even if they > are allowed to do so. Such behaviour considerably lowers amount of > possible rates, which is very inconvenient when such clock is used for > pixel clock, for example. > > In order to improve the situation, adjusting parent rate is considered > when allowed. > > This code is inspired by clk_divider_bestdiv() function, which does > basically the same thing for different clock type. This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC boards: EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem EXT4-fs (mmcblk1p4): write access will be enabled during recovery sunxi-mmc 1c11000.mmc: data error, sending stop command sunxi-mmc 1c11000.mmc: send stop command failed $ git bisect log git bisect start # good: [3df407b2a5346db1c48809706ece7a8616c79e0b] mmc: dw_mmc-bluefield: simplify the probe() function git bisect good 3df407b2a5346db1c48809706ece7a8616c79e0b # bad: [00d59fde8532b2d42e80909d2e58678755e04da9] Merge tag 'mmc-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect bad 00d59fde8532b2d42e80909d2e58678755e04da9 # good: [01e421feec0817bb3141eaae4c517410d193d440] Merge branch 'fixes' into next git bisect good 01e421feec0817bb3141eaae4c517410d193d440 # bad: [1eefdec18eded41833401cfd64749643ff72e7da] Merge branch 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 1eefdec18eded41833401cfd64749643ff72e7da # good: [eaa76499711535fd64d747cc4ef0d78ab0fd41c6] Merge tag 'mtd/for-4.21' of git://git.infradead.org/linux-mtd git bisect good eaa76499711535fd64d747cc4ef0d78ab0fd41c6 # good: [4e4390ad067a61ce4e7607bd0df31f19a4caa36a] Merge tag 'leds-for-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds git bisect good 4e4390ad067a61ce4e7607bd0df31f19a4caa36a # bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next git bisect bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698 # bad: [e4b99d415c3908581d4703203e1e805f043a3e71] Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad e4b99d415c3908581d4703203e1e805f043a3e71 # bad: [ffe05540d18013db62c43627836a3638e9a2c7aa] Merge branches 'clk-renesas', 'clk-allwinner', 'clk-tegra', 'clk-meson' and 'clk-rockchip' into clk-next git bisect bad ffe05540d18013db62c43627836a3638e9a2c7aa # good: [1a501c8defe950571316d5ddd917bf44f5ed7bd4] Merge branches 'clk-managed-registration', 'clk-spdx', 'clk-remove-basic' and 'clk-ops-const' into clk-next git bisect good 1a501c8defe950571316d5ddd917bf44f5ed7bd4 # good: [e74581b79ddd9b49b8c61e2791fc4dffc0245afb] Merge tag 'meson-clk-4.21-2' of https://github.com/BayLibre/clk-meson into clk-meson git bisect good e74581b79ddd9b49b8c61e2791fc4dffc0245afb # good: [60baf75e3f5b76043c25328ac0c5320aaef5ea41] Merge tag 'clk-renesas-for-v4.21-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-renesas git bisect good 60baf75e3f5b76043c25328ac0c5320aaef5ea41 # bad: [a41f85b6017ee20952a60e4330bcae2527fe2c2a] Merge tag 'sunxi-clk-for-4.21' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-allwinner git bisect bad a41f85b6017ee20952a60e4330bcae2527fe2c2a # bad: [ee678706e46d0d185c27cc214ad97828e0643159] clk: sunxi-ng: a64: Fix gate bit of DSI DPHY git bisect bad ee678706e46d0d185c27cc214ad97828e0643159 # bad: [65b6657672388b72822e0367f06d41c1e3ffb5bb] clk: sunxi-ng: Use u64 for calculation of NM rate git bisect bad 65b6657672388b72822e0367f06d41c1e3ffb5bb # good: [db7548934603d9eda12649dff97ea5c29884405d] clk: sunxi-ng: sun50i: h6: Fix MMC clock mux width git bisect good db7548934603d9eda12649dff97ea5c29884405d # bad: [3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15] clk: sunxi-ng: Adjust MP clock parent rate when allowed git bisect bad 3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15 # first bad commit: [3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15] clk: sunxi-ng: Adjust MP clock parent rate when allowed > > Signed-off-by: Jernej Skrabec > --- > drivers/clk/sunxi-ng/ccu_mp.c | 64 +-- > 1 file changed, 62 insertions(+), 2 deletions(-) > > diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c > index 5d0af4051737..0357349eb767 100644 > --- a/drivers/clk/sunxi-ng/ccu_mp.c > +++ b/drivers/clk/sunxi-ng/ccu_mp.c > @@ -40,6 +40,61 @@ static void ccu_mp_find_best(unsigned long parent, > unsigned long rate, > *p = best_p; > } > > +static unsigned long ccu_mp_find_best_with_parent_adj(struct clk_hw *hw, > + unsigned long *parent, > + unsigned long rate, > + unsigned int max_m, > +
Re: [linux-sunxi] u-boot: MMC broken on Linksprite A10/A20 boards in 2018.11
On Tue, Jan 08, 2019 at 11:54:32PM +0530, Jagan Teki wrote: > On Thu, Jan 3, 2019 at 9:33 PM Zoltan HERPAI wrote: > > > > Hi Jagan, Adam, > > > > On Thu, 3 Jan 2019, Jagan Teki wrote: > > > > > On Thu, Jan 3, 2019 at 6:57 PM Zoltan HERPAI wrote: > > >> > > >> Hi all, > > >> > > >> The DTS resync between 2018.09 and 2018.11 seems to have broken the MMC > > >> support for the Linksprite pcDuino (A10) and pcDuino v3 (A20) boards. > > >> The resync happened in b9d59d0 [1] and 3c92cca [2], after which u-boot > > >> doesn't recognize the MMC controller and freezes the board (exactly the > > >> same happens on the v3 board). > > >> > > >> CUT HERE > > >> U-Boot SPL 2018.11 (Dec 31 2018 - 14:36:52 +) > > >> DRAM: 1024 MiB > > >> CPU: 100800Hz, AXI/AHB/APB: 3/2/2 > > >> Trying to boot from MMC1 > > >> > > >> > > >> U-Boot 2018.11 (Dec 31 2018 - 14:36:52 +) Allwinner Technology > > >> > > >> CPU: Allwinner A10 (SUN4I) > > >> Model: LinkSprite pcDuino > > >> I2C: ready > > >> DRAM: 1 GiB > > >> MMC: > > >> CUT HERE > > >> > > >> Reverting these commits solve the problem and the boards boot correctly. > > >> Initially I thought this might be due to removing the > > >> mmc0_cd_pin_reference_design (syncing that from the kernel into u-boot), > > >> which was discussed here [3] and was considered as a move that might > > >> break MMC on some boards, but re-adding that reference pin only in the > > >> pcduino DTSes did not resolve the freeze. > > >> > > >> Questions: > > >> - A similar board - where the reference pin is used for CD - is the > > >> Cubieboard 2. Can someone test 2018.11 on it to see if it freezes as > > >> well? Out of A20, I have a Bananapro, but that's using a non-reference > > >> pin for CD, and boots fine. > > > > > > A10, enable DM_MMC so it can effect DT. or enable CONFIG_MMC0_CD_PIN="PH1" > > > > > > Added Adam, (who actually tested DM_MMC on A10) > > > > I tested with "either" and "both", neither worked - see below. Along with > > CONFIG_DM_MMC, I've also enabled CONFIG_DM_DEBUG to see what's happening - > > here is the output: > > > > [...] > > MMC: uclass_find_device_by_seq: 0 0 > > - -1 -1 'mmc@1c0f000' > > - not found > > uclass_find_device_by_seq: 1 0 > > - -1 -1 'mmc@1c0f000' > > - not found > > uclass_find_device_by_seq: 0 -1 > > uclass_find_device_by_seq: 0 0 > > - -1 -1 'mmc@1c0f000' > > - not found > > Entering sunxi_mmc_probe > > ofnode_read_u32: bus-width: 0x4 (4) > > sunxi_mmc: priv->reg: 1c0f000 > > sunxi_mmc: priv->mclkreg: 1c2 > > I'm looking for gate and clk register values, print at the end of probe > 1c2 + 0x60 > 1c2 + 0x88 With current master: sunxi_mmc_probe: gate_reg: 0x4141 sunxi_mmc_probe: clk_reg: 0x0 With 3c92cca3cda0d72c11c41bc0b07edcff127cf194 reverted: sunxi_mmc_probe: gate_reg: 0x4141 sunxi_mmc_probe: clk_reg: 0x8000 > > > ofnode_read_bool: cd-inverted: false > > > > > > > > > A20, can boot as it is, it doesn't effect mmc node on DT, since DM_MMC > > > is not available. > > > > > >> - There are some clock-related changes in this DTS resync, however I > > >> have less than optimal experience with clocks. Can someone help check if > > >> these changes might cause the issue? > > > > > > OK, better dump the clock reg value at the end of sunxi_mmc_probe > > > > For A20 it looks like this: > > > > > > MMC: Entering sunxi_mmc_probe > > sunxi_mmc: priv->reg: 1c0f000 > > sunxi_mmc: priv->mclkreg: 1c2 > > Same for here? > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] u-boot: MMC broken on Linksprite A10/A20 boards in 2018.11
On Thu, Jan 03, 2019 at 05:03:13PM +0100, Zoltan HERPAI wrote: > Hi Jagan, Adam, > > On Thu, 3 Jan 2019, Jagan Teki wrote: > > > On Thu, Jan 3, 2019 at 6:57 PM Zoltan HERPAI wrote: > > > > > > Hi all, > > > > > > The DTS resync between 2018.09 and 2018.11 seems to have broken the MMC > > > support for the Linksprite pcDuino (A10) and pcDuino v3 (A20) boards. > > > The resync happened in b9d59d0 [1] and 3c92cca [2], after which u-boot > > > doesn't recognize the MMC controller and freezes the board (exactly the > > > same happens on the v3 board). ... > > A10, enable DM_MMC so it can effect DT. or enable CONFIG_MMC0_CD_PIN="PH1" > > > > Added Adam, (who actually tested DM_MMC on A10) > > I tested with "either" and "both", neither worked - see below. Along with > CONFIG_DM_MMC, I've also enabled CONFIG_DM_DEBUG to see what's happening - > here is the output: Also broken on Gemei G9 A10 tablet with similar symptoms. Anything else we could try? Priit -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
On Sat, Dec 29, 2018 at 11:10:36PM +0100, Olliver Schinagl wrote:
> Luckily we have had no problem with this on our boards, but its sad to see
> this patch reverted due to the buggy ddr implementation ...
>
> Curiosity is getting the better of me and I cant seem to be able to reproduce
> the problem. So could you be a little bit more specific on the bug please?
It broke on some H2+ devices.
Just tested this also on H3 Orange Pi PC Plus and here it works fine.
>
> On December 29, 2018 7:53:49 PM GMT+01:00, Jagan Teki
> wrote:
> >On Wed, Dec 19, 2018 at 6:32 PM Andre Przywara
> >wrote:
> >>
> >> From: "From: Karl Palsson"
> >>
> >> Commit a8011eb84dfa("sunxi: board: Print error after power
> >initialization
> >> fails") moved the DRAM init after the increase of the CPU clock
> >> frequency. This lead to various DRAM initialisation failures on some
> >> boards (hangs or wrong size reported, on a NanoPi Duo2 and OrangePi
> >> Zero, for instance). Lowering the CPU frequency significantly (for
> >instance
> >> to 408 MHz) seems to work around the problem, so this points to some
> >timing
> >> issues in the DRAM code.
> >>
> >> Debugging this sounds like a larger job, so let's just revert this
> >patch
> >> to bring back those boards.
> >> Beside this probably unintended change the patch just moved the error
> >> message around, so reverting this is not a real loss.
> >
> >Better mark this as TODO somewhere, may be some one look it later.
> >
> >>
> >> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1.
> >>
> >> Tested-By: Priit Laes
> >> Signed-off-by: Karl Palsson
> >> Signed-off-by: Andre Przywara
> >
> >Applied to u-boot-sunxi/master
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] Add NFC register definitions for Allwinner A20 SoC
On Wed, Dec 26, 2018 at 02:37:26PM +0300, Nikolai Zhubr wrote:
> And while at it, why not finally add the DT register definitions for
> Allwinner A20 NFC. I'm certainly not the author of these, and they have been
> around for many years already. Its quite unlikely they will suddenly change,
> or vary between different A20-based devices. The A20 SoC is gradually
> becoming obsolete, so why wait any more. Note: one whould typically need to
> also add NFC node definition on top of this in order to actually use it.
>
> Signed-off-by: Nikolai Zhubr
> ---
> arch/arm/dts/sun7i-a20.dtsi | 69
> +
> 1 file changed, 69 insertions(+)
>
> diff --git a/arch/arm/dts/sun7i-a20.dtsi b/arch/arm/dts/sun7i-a20.dtsi
> index e529e4f..6f96693 100644
> --- a/arch/arm/dts/sun7i-a20.dtsi
> +++ b/arch/arm/dts/sun7i-a20.dtsi
> @@ -920,6 +920,75 @@
> pins = "PI20", "PI21";
> function = "uart7";
> };
> + nand_pins_a: nand_base0@0 {
> + allwinner,pins = "PC0", "PC1", "PC2",
> + "PC5", "PC8", "PC9", "PC10",
> + "PC11", "PC12", "PC13", "PC14",
> + "PC15", "PC16";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
allwinner,{pins,function,drive,pull} syntax has been deprecated in
favor or general pinctrl syntax.
You can check how sun5i.dtsi defines these blocks.
> + };
> + nand_cs0_pins_a: nand_cs@0 {
> + allwinner,pins = "PC4";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs1_pins_a: nand_cs@1 {
> + allwinner,pins = "PC3";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs2_pins_a: nand_cs@2 {
> + allwinner,pins = "PC17";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs3_pins_a: nand_cs@3 {
> + allwinner,pins = "PC18";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs4_pins_a: nand_cs@4 {
> + allwinner,pins = "PC19";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs5_pins_a: nand_cs@5 {
> + allwinner,pins = "PC20";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs6_pins_a: nand_cs@6 {
> + allwinner,pins = "PC21";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_cs7_pins_a: nand_cs@7 {
> + allwinner,pins = "PC22";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_rb0_pins_a: nand_rb@0 {
> + allwinner,pins = "PC6";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + nand_rb1_pins_a: nand_rb@1 {
> + allwinner,pins = "PC7";
> + allwinner,function = "nand0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> };
>
> timer@1c20c00 {
> --
> 2.1.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and
Re: [linux-sunxi] Re: [PATCH v2 1/8] mfd: axp20x: name voltage ramping define properly
On Fri, Dec 21, 2018 at 09:26:58AM +, Lee Jones wrote:
> On Fri, 21 Dec 2018, Priit Laes wrote:
>
> > On Fri, Dec 21, 2018 at 08:39:27AM +, Lee Jones wrote:
> > > On Tue, 11 Dec 2018, Priit Laes wrote:
> > >
> > > > From: Olliver Schinagl
> > > >
> > > > The current axp20x names the ramping register 'scal' which probably
> > > > means scaling. Since the register really has nothing to do with
> > > > scaling, but really is the voltage ramp we rename it appropriately.
> > > >
> > > > Signed-off-by: Olliver Schinagl
> > > > Signed-off-by: Priit Laes
> > > > Acked-for-MFD-by: Lee Jones
> > > > ---
> > > > include/linux/mfd/axp20x.h | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > I've lost track of what's happening with this set now.
> > >
> > > Mark,
> > >
> > > Did you take this patch in the end?
> >
> > Yes, this is in linux-next.
>
> I have no idea why Mark's tracker isn't mailing me (this is not the
> first time this has happened).
>
> Could you please rebase this set and resubmit all of the patches which
> have not yet been applied?
Whole serie has been applied.
> Thank you.
>
> > > > diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> > > > index 2302b62..a353cd2 100644
> > > > --- a/include/linux/mfd/axp20x.h
> > > > +++ b/include/linux/mfd/axp20x.h
> > > > @@ -35,7 +35,7 @@ enum axp20x_variants {
> > > > #define AXP152_ALDO_OP_MODE0x13
> > > > #define AXP152_LDO0_CTRL 0x15
> > > > #define AXP152_DCDC2_V_OUT 0x23
> > > > -#define AXP152_DCDC2_V_SCAL0x25
> > > > +#define AXP152_DCDC2_V_RAMP0x25
> > > > #define AXP152_DCDC1_V_OUT 0x26
> > > > #define AXP152_DCDC3_V_OUT 0x27
> > > > #define AXP152_ALDO12_V_OUT0x28
> > > > @@ -53,7 +53,7 @@ enum axp20x_variants {
> > > > #define AXP20X_USB_OTG_STATUS 0x02
> > > > #define AXP20X_PWR_OUT_CTRL0x12
> > > > #define AXP20X_DCDC2_V_OUT 0x23
> > > > -#define AXP20X_DCDC2_LDO3_V_SCAL 0x25
> > > > +#define AXP20X_DCDC2_LDO3_V_RAMP 0x25
> > > > #define AXP20X_DCDC3_V_OUT 0x27
> > > > #define AXP20X_LDO24_V_OUT 0x28
> > > > #define AXP20X_LDO3_V_OUT 0x29
> > >
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v2 1/8] mfd: axp20x: name voltage ramping define properly
On Fri, Dec 21, 2018 at 08:39:27AM +, Lee Jones wrote:
> On Tue, 11 Dec 2018, Priit Laes wrote:
>
> > From: Olliver Schinagl
> >
> > The current axp20x names the ramping register 'scal' which probably
> > means scaling. Since the register really has nothing to do with
> > scaling, but really is the voltage ramp we rename it appropriately.
> >
> > Signed-off-by: Olliver Schinagl
> > Signed-off-by: Priit Laes
> > Acked-for-MFD-by: Lee Jones
> > ---
> > include/linux/mfd/axp20x.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> I've lost track of what's happening with this set now.
>
> Mark,
>
> Did you take this patch in the end?
Yes, this is in linux-next.
>
> > diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> > index 2302b62..a353cd2 100644
> > --- a/include/linux/mfd/axp20x.h
> > +++ b/include/linux/mfd/axp20x.h
> > @@ -35,7 +35,7 @@ enum axp20x_variants {
> > #define AXP152_ALDO_OP_MODE0x13
> > #define AXP152_LDO0_CTRL 0x15
> > #define AXP152_DCDC2_V_OUT 0x23
> > -#define AXP152_DCDC2_V_SCAL0x25
> > +#define AXP152_DCDC2_V_RAMP0x25
> > #define AXP152_DCDC1_V_OUT 0x26
> > #define AXP152_DCDC3_V_OUT 0x27
> > #define AXP152_ALDO12_V_OUT0x28
> > @@ -53,7 +53,7 @@ enum axp20x_variants {
> > #define AXP20X_USB_OTG_STATUS 0x02
> > #define AXP20X_PWR_OUT_CTRL0x12
> > #define AXP20X_DCDC2_V_OUT 0x23
> > -#define AXP20X_DCDC2_LDO3_V_SCAL 0x25
> > +#define AXP20X_DCDC2_LDO3_V_RAMP 0x25
> > #define AXP20X_DCDC3_V_OUT 0x27
> > #define AXP20X_LDO24_V_OUT 0x28
> > #define AXP20X_LDO3_V_OUT 0x29
>
> --
> Lee Jones [李琼斯]
> Linaro Services Technical Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] nand support on sun7i-a20-olinuxino-micro
On Thu, Dec 20, 2018 at 03:44:19AM +0300, Nikolai Zhubr wrote: > Hello all, > > I'm trying to get NAND working on an a20-olinuxino-micro board and it does > not quite work for me yet. I know the support of NAND storage supposed to be > somewhat incomplete or unstable at the moment, but actually I'd like to just > properly install a reasonably new u-boot (with ethernet support) to NAND so > as to avoid having the opaque boot0 and boot1, and I've read such > configuration was proven possible, although on some cubie device, not > olinuxino. There's README.nand in mainline u-boot's board/sunxi directory. Make sure that your board's configuration has CONFIG_NAND=y. This will trigger building of spl/sunxi-spl-with-ecc.bin > > Currently, I've got 2 ways of installing u-boot with subsequent successfull > OS boot from network: > > 1. Mainline U-boot on a micro-sd card. All is working fine, except I'd > prefer to avoid any removable parts and wiggling junctures as much as > possible. > > 2. Mainline U-boot without SPL stored into a special partition on NAND > memory, which is only accessible when booted some outdated debian image with > 3.x kernel by means of some severely non-standard Allwinner drivers. This is > not only inconvenient to setup/modify/access, but sometimes booting just > randomly fails somewhere between boot0 and boot1. Retrying after several > seconds (after plugging off the power) usually helps. Also, I've found that > some time-critical application works more reliably wrt performance when > booted from sd-card as compared to this NAND-boot0-boot1-uboot scenario, > although uboot is the same and the kernel and all userspace is the same. I > suspect boot0/boot1 does some unwanted (and unnecessary) hardware tweaking > which then negatively affects performance. > > So, using various instructions and patches floating around, I've enabled > "Support for NAND on Allwinner SoCs" in my kernel (4.14), added to dts, > prepared mtd-utils, attempted to load sunxi_nand. > > [ 67.072646] nand: Could not find valid ONFI parameter page; aborting > [ 67.079082] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7 > [ 67.085509] nand: Hynix NAND 4GiB 3,3V 8-bit > [ 67.089777] nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, > OOB size: 640 > [ 67.100973] Bad block table not found for chip 0 > [ 67.108481] Bad block table not found for chip 0 > [ 67.113126] Scanning device for bad blocks > [ 67.147285] Bad eraseblock 16 at 0x021fe000 > (repeated a lot) > > Then I had to use a hack in nand_erase_nand() in order to workaround the > eraseblocks flood. My next findings are the following: > > nanddump seem to dump something, but the actual data in first 200Mb does not > contain anything recognizable (32Kb@0 and 32Kb@2M look like filled with > random bytes, the rest looks like uninitialized or random bytes). > > flash_erase does something, but it does not fix the "Bad eraseblock..." > flood however. > > nandwrite and subsequent nanddump of e.g. u-boot-sunxi-with-spl.bin shows > that apparently something got stored, because the read data matches > perfectly the source. > > Now leaving alone preparation of u-boot for NAND, I see two problems > already: > > 1. Initializing bad block table fails, also after flash_erase, probably > indicating something goes wrong; > > 2. Reading original (bootable Debian) NAND contents does not give any > recognizable strings but random garbage. > > This feels like maybe physically some access takes place, but the "encoding" > is somehow wrong. I've seen some mentions of ECC_STRENGTH setting, but I'm > rather unsure how to deal with it. > > Maybe it could be of some help that I have the debug serial output from > CT_Nandboot utility, see below. > > Any hints? > > > Thank you! > > Regards, > Nikolai > > > CT_Nandboot output (trimmed): > [SCAN_DBG] ==Nand Architecture Parameter== > [SCAN_DBG]Nand Chip ID: 0xda94d7ad 0x > [SCAN_DBG]Nand Chip Count: 0x1 > [SCAN_DBG]Nand Chip Connect:0x1 > [SCAN_DBG]Nand Rb Connect Mode: 0x1 > [SCAN_DBG]Sector Count Of Page: 0x10 > [SCAN_DBG]Page Count Of Block: 0x100 > [SCAN_DBG]Block Count Of Die: 0x800 > [SCAN_DBG]Plane Count Of Die: 0x2 > [SCAN_DBG]Die Count Of Chip:0x1 > [SCAN_DBG]Bank Count Of Chip: 0x1 > [SCAN_DBG]Optional Operation: 0x1188 > [SCAN_DBG]Access Frequence: 0x1e > [SCAN_DBG]ECC Mode: 0x3 > [SCAN_DBG]Read Retry Type: 0x10604 > [SCAN_DBG]DDR Type: 0x0 > [SCAN_DBG] === > > [SCAN_DBG] ==Optional Operaion Parameter== > [SCAN_DBG]MultiPlaneReadCmd: 0x60, 0x60 > [SCAN_DBG]MultiPlaneWriteCmd: 0x11, 0x81 > [SCAN_DBG]MultiPlaneCopyReadCmd: 0x60, 0x60, 0x35 >
Re: [linux-sunxi] CONFIG_DM_USB breakage on sunxi boards with musb?
On Wed, Dec 19, 2018 at 01:14:22PM +0100, Jean-Jacques Hiblot wrote: > > On 19/12/2018 12:37, Priit Laes wrote: > > On Wed, Dec 19, 2018 at 01:26:18PM +0530, Jagan Teki wrote: > > > On Wed, Dec 19, 2018 at 1:23 PM Priit Laes wrote: > > > > Heya! > > > > > > > > I ran into following error when trying to fel-boot > > > > A20 OLinuxino Lime2 eMMC board with latest u-boot: > > > > > > > > [snip] > > > > U-Boot 2019.01-rc2-5-gbf60dae9dd (Dec 19 2018 - 09:47:08 +0200) > > > > Allwinner Technology > > > > > > > > CPU: Allwinner A20 (SUN7I) > > > > Model: Olimex A20-OLinuXino-LIME2-eMMC > > > > I2C: ready > > > > DRAM: 1 GiB > > > > Error binding driver 'sunxi-musb': -96 > > > > Some drivers failed to bind > > > > Error binding driver 'generic_simple_bus': -96 > > > > Some drivers failed to bind > > > > initcall sequence 7efbdfc8 failed at call 4a00d07b (err=-96) > > > > ### ERROR ### Please RESET the board ### > > > > [/snip] > > > > > > > > > > > > Could it be caused by a side effect of the upcoming CONFIG_DM_USB > > > > changes? > > > No, board file change wrt this commit > > > 0131162439508801b9f8a330fa731f04273c9337 > > > > > > Need to figure out. > > Yup, bisecting points to the same commit and reverting fixes the issue. > > Can you try with DM_USB_GADGET enabled? Yes, the result is: drivers/usb/gadget/udc/udc-uclass.c:52: undefined reference to `dm_usb_gadget_handle_interrupts u-boot configuration file is A20-OLinuXino-Lime2-eMMC_defconfig > > > > > > 0131162439508801b9f8a330fa731f04273c9337 is the first bad commit > > commit 0131162439508801b9f8a330fa731f04273c9337 > > Author: Jean-Jacques Hiblot > > Date: Thu Nov 29 10:52:46 2018 +0100 > > > > dm: usb: create a new UCLASS ID for USB gadget devices > > UCLASS_USB_DEV_GENERIC was meant for USB devices connected to host > > controllers, not gadget devices. > > Adding a new UCLASS for gadget devices alone. > > Also move the generic DM code for USB gadgets in a separate file for > > clarity. > > Signed-off-by: Jean-Jacques Hiblot > > > > :04 04 5223a6058a0c4a1e877f32355c947d4a607fef1b > > d3f89658db63ec26d887163740cf5d974dd2c0e5 M board > > :04 04 67c4404917ada478595b408d7747a6f5c17c0c99 > > 8c67ea39df65e4e982d9b9eeb984d66678a33fc8 M drivers > > :04 04 89243fd62729e128489d80e206db4fa9b946dc99 > > 16783bd1f210ae3454255cb1c4eaa05fe7eaa6ed M include > > > > $ git bisect log > > git bisect start > > # bad: [058701534ffde8032649ba8421a0428959519b79] WIP > > git bisect bad 058701534ffde8032649ba8421a0428959519b79 > > # bad: [d94604d558cda9f89722c967d6f8d6269a2db21c] Merge tag > > 'fsl-qoriq-for-v2019.01-rc2' of git://git.denx.de/u-boot-fsl-qoriq > > git bisect bad d94604d558cda9f89722c967d6f8d6269a2db21c > > # good: [c49aff3e66b930aa06936afee401cf5e19377958] Merge branch 'master' of > > git://git.denx.de/u-boot-sunxi > > git bisect good c49aff3e66b930aa06936afee401cf5e19377958 > > # bad: [7ff485c68b7e5573e5a4a877066e98398283a24f] Merge branch 'master' of > > git://git.denx.de/u-boot-i2c > > git bisect bad 7ff485c68b7e5573e5a4a877066e98398283a24f > > # good: [19f8c4dfb6e744a31da59bdd23b24d144152f1dc] cmd: i2c: Fix help > > output of i2c command. > > git bisect good 19f8c4dfb6e744a31da59bdd23b24d144152f1dc > > # bad: [b491afa0f3c0df88027b08f18934cc034c40d659] configs: enable DM_USB > > and DM_USB_DEV for all DRA7 platforms > > git bisect bad b491afa0f3c0df88027b08f18934cc034c40d659 > > # bad: [93991cf1969077108ae36e90acb3cd25a6a449ac] dwc3-generic: Add > > select_dr_mode operation > > git bisect bad 93991cf1969077108ae36e90acb3cd25a6a449ac > > # good: [20bebd866690bb09dd1c1cb8ac674c3b17b63c6d] dwc3_generic: do not > > probe the USB device driver when it's bound > > git bisect good 20bebd866690bb09dd1c1cb8ac674c3b17b63c6d > > # bad: [0131162439508801b9f8a330fa731f04273c9337] dm: usb: create a new > > UCLASS ID for USB gadget devices > > git bisect bad 0131162439508801b9f8a330fa731f04273c9337 > > # good: [d648a50c0a27452a5439e7982b23b97c64820430] dwc3: move phy operation > > to core.c > > git bisect good d648a50c0a27452a5439e7982b23b97c64820430 > > # first bad commit: [0131162439508801b9f8a330fa731f04273c9337] dm: usb: > > create a new UCLASS ID for USB gadget devices > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "linux-sunxi" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to linux-sunxi+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/3] sunxi: display: Move DDC PLL setup to HDMI init
From: Priit Laes
Move PLL initialization code to single place so
we won't call it every time we query for EDID data.
Signed-off-by: Priit Laes
---
drivers/video/sunxi/sunxi_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_display.c
b/drivers/video/sunxi/sunxi_display.c
index 6dd9bec351..0362071f72 100644
--- a/drivers/video/sunxi/sunxi_display.c
+++ b/drivers/video/sunxi/sunxi_display.c
@@ -113,6 +113,13 @@ static int sunxi_hdmi_hpd_detect(int hpd_delay)
writel(SUNXI_HDMI_CTRL_ENABLE, >ctrl);
writel(SUNXI_HDMI_PAD_CTRL0_HDP, >pad_ctrl0);
+ /* Enable PLLs for eventual DDC */
+ writel(SUNXI_HDMI_PAD_CTRL1 | SUNXI_HDMI_PAD_CTRL1_HALVE,
+ >pad_ctrl1);
+ writel(SUNXI_HDMI_PLL_CTRL | SUNXI_HDMI_PLL_CTRL_DIV(15),
+ >pll_ctrl);
+ writel(SUNXI_HDMI_PLL_DBG0_PLL3, >pll_dbg0);
+
while (timer_get_us() < tmo) {
if (readl(>hpd) & SUNXI_HDMI_HPD_DETECT)
return 1;
@@ -215,13 +222,6 @@ static int sunxi_hdmi_edid_get_mode(struct ctfb_res_modes
*mode)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
int i, r, ext_blocks = 0;
- /* SUNXI_HDMI_CTRL_ENABLE & PAD_CTRL0 are already set by hpd_detect */
- writel(SUNXI_HDMI_PAD_CTRL1 | SUNXI_HDMI_PAD_CTRL1_HALVE,
- >pad_ctrl1);
- writel(SUNXI_HDMI_PLL_CTRL | SUNXI_HDMI_PLL_CTRL_DIV(15),
- >pll_ctrl);
- writel(SUNXI_HDMI_PLL_DBG0_PLL3, >pll_dbg0);
-
/* Reset i2c controller */
setbits_le32(>hdmi_clk_cfg, CCM_HDMI_CTRL_DDC_GATE);
writel(SUNXI_HMDI_DDC_CTRL_ENABLE |
--
2.11.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/3] videomodes: Allow EDID timings where hsync/vsync pulse is 0
From: Priit Laes Current EDID detailed timing parser errors out when either horizontal or vertical pulse sync width is 0, thus not allowing a display with EDID listed below work properly. Of-course, this is somewhat quirky HDMI display with following anti-features: - HPD pin is not usable - although resolution is 640x480, only top 240 pixels are visible $ xxd -p display.edid 000005a1e0030100150f0103800f05780a0f6ea05748 9a2610474f20010101010101010101010101010101012a08804520e0 0b10200040009536001800fd0034441a2403000a202020202020 001000310a202020202020202020202000102a4030701300 782d111e006b $ edid-decode display.edid EDID version: 1.3 Manufacturer: AMA Model 3e0 Serial Number 1 Digital display Maximum image size: 15 cm x 5 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6250, 0.3398 Green: 0.2841, 0.6044 Blue: 0.1494, 0.0644 White: 0.2802, 0.3105 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz Standard timings supported: Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm 640 672 672 709 hborder 0 480 484 484 491 vborder 0 -hsync -vsync VertFreq: 60 Hz, HorFreq: 29478 Hz Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz Dummy block Dummy block Checksum: 0x6b (valid) Signed-off-by: Priit Laes --- drivers/video/videomodes.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c index 74bafff011..1cfeaa980f 100644 --- a/drivers/video/videomodes.c +++ b/drivers/video/videomodes.c @@ -396,9 +396,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct edid_detailed_timing *t, EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*t) == 0 || EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 || EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 || - EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*t) == 0 || EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 || - EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*t) == 0 || /* 3d formats are not supported*/ EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0) return -EINVAL; -- 2.11.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3/3] sunxi: display: Implement fallback to ddc probe when hpd fails
From: Priit Laes
There are HDMI displays where hpd pin is not connected, thus
we cannot get it to work unless we specifically set the resolution.
Rework the display probing, so hotplug detect failure causes
fallback to probing ddc for EDID data.
Signed-off-by: Priit Laes
---
drivers/video/sunxi/sunxi_display.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_display.c
b/drivers/video/sunxi/sunxi_display.c
index 0362071f72..46436b88c5 100644
--- a/drivers/video/sunxi/sunxi_display.c
+++ b/drivers/video/sunxi/sunxi_display.c
@@ -210,7 +210,8 @@ static int sunxi_hdmi_edid_get_block(int block, u8 *buf)
return r;
}
-static int sunxi_hdmi_edid_get_mode(struct ctfb_res_modes *mode)
+static int sunxi_hdmi_edid_get_mode(struct ctfb_res_modes *mode,
+ bool verbose_mode)
{
struct edid1_info edid1;
struct edid_cea861_info cea681[4];
@@ -241,7 +242,8 @@ static int sunxi_hdmi_edid_get_mode(struct ctfb_res_modes
*mode)
if (r == 0) {
r = edid_check_info();
if (r) {
- printf("EDID: invalid EDID data\n");
+ if (verbose_mode)
+ printf("EDID: invalid EDID data\n");
r = -EINVAL;
}
}
@@ -1082,7 +1084,8 @@ void *video_hw_init(void)
struct ctfb_res_modes custom;
const char *options;
#ifdef CONFIG_VIDEO_HDMI
- int ret, hpd, hpd_delay, edid;
+ int hpd, hpd_delay, edid;
+ bool hdmi_present;
#endif
int i, overscan_offset, overscan_x, overscan_y;
unsigned int fb_dma_addr;
@@ -1118,12 +1121,23 @@ void *video_hw_init(void)
if (sunxi_display.monitor == sunxi_monitor_dvi ||
sunxi_display.monitor == sunxi_monitor_hdmi) {
/* Always call hdp_detect, as it also enables clocks, etc. */
- ret = sunxi_hdmi_hpd_detect(hpd_delay);
- if (ret) {
+ hdmi_present = (sunxi_hdmi_hpd_detect(hpd_delay) == 1);
+ if (hdmi_present && edid) {
printf("HDMI connected: ");
- if (edid && sunxi_hdmi_edid_get_mode() == 0)
+ if (sunxi_hdmi_edid_get_mode(, true) == 0)
mode =
- } else if (hpd) {
+ else
+ hdmi_present = false;
+ }
+ /* Fall back to EDID in case HPD failed */
+ if (edid && !hdmi_present) {
+ if (sunxi_hdmi_edid_get_mode(, false) == 0) {
+ mode =
+ hdmi_present = true;
+ }
+ }
+ /* Shut down when display was not found */
+ if ((hpd || edid) && !hdmi_present) {
sunxi_hdmi_shutdown();
sunxi_display.monitor = sunxi_get_default_mon(false);
} /* else continue with hdmi/dvi without a cable connected */
--
2.11.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CONFIG_DM_USB breakage on sunxi boards with musb?
On Wed, Dec 19, 2018 at 01:26:18PM +0530, Jagan Teki wrote: > On Wed, Dec 19, 2018 at 1:23 PM Priit Laes wrote: > > > > Heya! > > > > I ran into following error when trying to fel-boot > > A20 OLinuxino Lime2 eMMC board with latest u-boot: > > > > [snip] > > U-Boot 2019.01-rc2-5-gbf60dae9dd (Dec 19 2018 - 09:47:08 +0200) > > Allwinner Technology > > > > CPU: Allwinner A20 (SUN7I) > > Model: Olimex A20-OLinuXino-LIME2-eMMC > > I2C: ready > > DRAM: 1 GiB > > Error binding driver 'sunxi-musb': -96 > > Some drivers failed to bind > > Error binding driver 'generic_simple_bus': -96 > > Some drivers failed to bind > > initcall sequence 7efbdfc8 failed at call 4a00d07b (err=-96) > > ### ERROR ### Please RESET the board ### > > [/snip] > > > > > > Could it be caused by a side effect of the upcoming CONFIG_DM_USB > > changes? > > No, board file change wrt this commit 0131162439508801b9f8a330fa731f04273c9337 > > Need to figure out. Yup, bisecting points to the same commit and reverting fixes the issue. 0131162439508801b9f8a330fa731f04273c9337 is the first bad commit commit 0131162439508801b9f8a330fa731f04273c9337 Author: Jean-Jacques Hiblot Date: Thu Nov 29 10:52:46 2018 +0100 dm: usb: create a new UCLASS ID for USB gadget devices UCLASS_USB_DEV_GENERIC was meant for USB devices connected to host controllers, not gadget devices. Adding a new UCLASS for gadget devices alone. Also move the generic DM code for USB gadgets in a separate file for clarity. Signed-off-by: Jean-Jacques Hiblot :04 04 5223a6058a0c4a1e877f32355c947d4a607fef1b d3f89658db63ec26d887163740cf5d974dd2c0e5 M board :04 04 67c4404917ada478595b408d7747a6f5c17c0c99 8c67ea39df65e4e982d9b9eeb984d66678a33fc8 M drivers :04 04 89243fd62729e128489d80e206db4fa9b946dc99 16783bd1f210ae3454255cb1c4eaa05fe7eaa6ed M include $ git bisect log git bisect start # bad: [058701534ffde8032649ba8421a0428959519b79] WIP git bisect bad 058701534ffde8032649ba8421a0428959519b79 # bad: [d94604d558cda9f89722c967d6f8d6269a2db21c] Merge tag 'fsl-qoriq-for-v2019.01-rc2' of git://git.denx.de/u-boot-fsl-qoriq git bisect bad d94604d558cda9f89722c967d6f8d6269a2db21c # good: [c49aff3e66b930aa06936afee401cf5e19377958] Merge branch 'master' of git://git.denx.de/u-boot-sunxi git bisect good c49aff3e66b930aa06936afee401cf5e19377958 # bad: [7ff485c68b7e5573e5a4a877066e98398283a24f] Merge branch 'master' of git://git.denx.de/u-boot-i2c git bisect bad 7ff485c68b7e5573e5a4a877066e98398283a24f # good: [19f8c4dfb6e744a31da59bdd23b24d144152f1dc] cmd: i2c: Fix help output of i2c command. git bisect good 19f8c4dfb6e744a31da59bdd23b24d144152f1dc # bad: [b491afa0f3c0df88027b08f18934cc034c40d659] configs: enable DM_USB and DM_USB_DEV for all DRA7 platforms git bisect bad b491afa0f3c0df88027b08f18934cc034c40d659 # bad: [93991cf1969077108ae36e90acb3cd25a6a449ac] dwc3-generic: Add select_dr_mode operation git bisect bad 93991cf1969077108ae36e90acb3cd25a6a449ac # good: [20bebd866690bb09dd1c1cb8ac674c3b17b63c6d] dwc3_generic: do not probe the USB device driver when it's bound git bisect good 20bebd866690bb09dd1c1cb8ac674c3b17b63c6d # bad: [0131162439508801b9f8a330fa731f04273c9337] dm: usb: create a new UCLASS ID for USB gadget devices git bisect bad 0131162439508801b9f8a330fa731f04273c9337 # good: [d648a50c0a27452a5439e7982b23b97c64820430] dwc3: move phy operation to core.c git bisect good d648a50c0a27452a5439e7982b23b97c64820430 # first bad commit: [0131162439508801b9f8a330fa731f04273c9337] dm: usb: create a new UCLASS ID for USB gadget devices > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
On Wed, Dec 19, 2018 at 01:45:29AM +, André Przywara wrote: > On 19/12/2018 00:51, André Przywara wrote: > > On 18/12/2018 12:06, Jagan Teki wrote: > >> On Tue, Dec 18, 2018 at 4:09 PM wrote: > >>> > >>> From: Karl Palsson > >>> > >>> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1 > >>> > >>> This causes DRAM init failures on (at least) > >>> * allwinner h3 nanopi-duo2 > >>> * allwinner h2+ orangepi zero v1.1 > >>> > >>> Signed-off-by: Karl Palsson > >>> --- > >>> > >>> Ideally, this should get into 2019.01, so that this release is not > >>> broken on those targets. > >> > >> Better to understand the issue here, since I have BPI-M2+ which boots > >> fine w/o this revert. > > > > Could this be a .bss issue? This lies in DRAM and is thus only available > > *after* DRAM init. IIRC we silently rely on not accessing anything in > > .bss before the DRAM is up, see 59d07ee08e85 for instance. > > I don't immediately spot any .bss usage in clock_set_pll1(), though. > > > > Or is the 1GHz CPU clock speed too fast for the DRAM init? If I am not > > mistaken, we run with 24MHz before, so there might be some "natural" > > delay in some setup routines. Some DRAM chips or board layout might be > > more susceptible to this than others, which might explain why it only > > fails on some boards. > > Just did some testing on my OrangePi Zero: if I force the CPU frequency > to 408 MHz, it works, but fails with the standard 1008 MHz. > So this smells that we indeed miss some delays in the DRAM setup code, > which sounds tedious to find. There are a number of delays, but those > are fine as they are timer controlled, so independent from the CPU > frequency. With latest u-boot, I got it only working when lowering DRAM_CLK to 312MHz (default being 624 MHz(. Even with 336 and 360 MHz it hung just after displaying the 'Trying to boot from FEL' message, while reporting wrong DRAM size (1GiB and 2048MiB). > > For now I think that reverting would be the easiest solution. Somewhat > in contrast to what the commit message says, we don't really change > anything in terms of error *checking*, as the code carries on anyways > (just without increasing the CPU frequency). The only real difference is > the order of CPU clock setup and DRAM init. > > Karl, can you please amend the commit message to mention the CPU > frequency issue? > > > So if the original patch is about bailing out on error early, can't we > > just do *that* before the DRAM init, keeping the CPU clock setup still > > after DRAM? > > Just checked, this works as well, but is a bit pointless. Just reverting > this and meanwhile checking the DRAM init code seems the easier solution. > > Cheers, > Andre > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] CONFIG_DM_USB breakage on sunxi boards with musb?
Heya! I ran into following error when trying to fel-boot A20 OLinuxino Lime2 eMMC board with latest u-boot: [snip] U-Boot 2019.01-rc2-5-gbf60dae9dd (Dec 19 2018 - 09:47:08 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Olimex A20-OLinuXino-LIME2-eMMC I2C: ready DRAM: 1 GiB Error binding driver 'sunxi-musb': -96 Some drivers failed to bind Error binding driver 'generic_simple_bus': -96 Some drivers failed to bind initcall sequence 7efbdfc8 failed at call 4a00d07b (err=-96) ### ERROR ### Please RESET the board ### [/snip] Could it be caused by a side effect of the upcoming CONFIG_DM_USB changes? Priit -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [U-Boot] [linux-sunxi] [PATCH] Revert "sunxi: board: Print error after power initialization fails"
On Tue, Dec 18, 2018 at 09:17:27PM +0100, Michael Nazzareno Trimarchi wrote: > Hi Karl > > On Tue, Dec 18, 2018 at 7:12 PM Karl Palsson wrote: > > > > > > Jagan Teki wrote: > > > It's 4 days before, "U-Boot] sunxi: regression in dram init for > > > h3 board" > > > > > > 7 days is not 4-days :) > > > > True, it was last week, not a week ago. > > > > > I would expect some debugging on this during these days and > > > find the real root cause. > > > > Just so there's no unmet expectations here, I'm not doing any > > _debugging_ of this. (Nor do I have any planned) Given that this > > is a regression in working devices, I would _presume_ (quite > > likely wrongly) that the honus of debugging this would be on the > > people who suggested this patch, not people affected by it. I'm > > happy to test things, but I have zero experience with dram init, > > (only marginally greater than zero experience with uboot overall) > > and no sane methods for debugging this further, nor enough > > devices to give any test confidence that any debugging I could do > > would be useful. > > > > Do you have error after relocation or before relocation? Does it go > outside and print DRAM size? When I tested, I replaced hang there with reboot and got following outputs after multiple FEL uboot uploads commands: [snip] U-Boot SPL 2019.01-rc1-00341-gb2f6eec007-dirty (Dec 18 2018 - 09:31:01 +0200) DRAM: 0 MiB resetting ... U-Boot SPL 2019.01-rc1-00341-gb2f6eec007-dirty (Dec 18 2018 - 09:31:01 +0200) DRAM: 2048 MiB Trying to boot from FEL U-Boot SPL 2019.01-rc1-00341-gb2f6eec007-dirty (Dec 18 2018 - 09:31:01 +0200) DRAM: 1024 MiB Trying to boot from FEL [/snip] > > Michael > > > Sincerely, > > Karl P___ > > U-Boot mailing list > > u-b...@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > > > -- > | Michael Nazzareno Trimarchi Amarula Solutions BV | > | COO - Founder Cruquiuskade 47 | > | +31(0)851119172 Amsterdam 1018 AM NL | > | [`as] http://www.amarulasolutions.com | > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] Revert "sunxi: board: Print error after power initialization fails"
On Tue, Dec 18, 2018 at 11:11:54AM +, ka...@tweak.net.au wrote:
> From: Karl Palsson
>
> This reverts commit a8011eb84dfac5187cebf00ed8bc981bdb5c1fa1
>
> This causes DRAM init failures on (at least)
> * allwinner h3 nanopi-duo2
> * allwinner h2+ orangepi zero v1.1
>
> Signed-off-by: Karl Palsson
Tested-By: Priit Laes
Tested with A20 Olinuxino Lime2 (where original works too)
and H2+ OrangePi Zero V1.1 (where the original patch caused
breakage).
> ---
>
> Ideally, this should get into 2019.01, so that this release is not
> broken on those targets.
>
> board/sunxi/board.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 917f5b18f6..f022f365e9 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -637,6 +637,13 @@ void sunxi_board_init(void)
> power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
> #endif
> #endif
> + printf("DRAM:");
> + gd->ram_size = sunxi_dram_init();
> + printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> + if (!gd->ram_size)
> + hang();
> +
> + sunxi_spl_store_dram_size(gd->ram_size);
>
> /*
>* Only clock up the CPU to full speed if we are reasonably
> @@ -645,16 +652,7 @@ void sunxi_board_init(void)
> if (!power_failed)
> clock_set_pll1(CONFIG_SYS_CLK_FREQ);
> else
> - printf("Error setting up the power controller.\n"
> -"CPU frequency not set.\n");
> -
> - printf("DRAM:");
> - gd->ram_size = sunxi_dram_init();
> - printf(" %d MiB\n", (int)(gd->ram_size >> 20));
> - if (!gd->ram_size)
> - hang();
> -
> - sunxi_spl_store_dram_size(gd->ram_size);
> + printf("Failed to set core voltage! Can't set CPU frequency\n");
> }
> #endif
>
> --
> 2.14.5
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH] regulator: axp20x: fix set_ramp_delay for AXP209/dcdc2
Initial commit of set_ramp_delay feature was missing an assignment which
should have populated slew_rate table for dcdc2 regulator. Add it.
Fixes: d29f54df8b16 ("regulator: axp20x: add support for set_ramp_delay for
AXP209")
Signed-off-by: Priit Laes
---
drivers/regulator/axp20x-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index e8a895b81c90..48af859fd053 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -378,6 +378,7 @@ static int axp20x_set_ramp_delay(struct regulator_dev
*rdev, int ramp)
switch (axp20x->variant) {
case AXP209_ID:
if (desc->id == AXP20X_DCDC2) {
+ slew_rates = axp209_dcdc2_ldo3_slew_rates;
rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
reg = AXP20X_DCDC2_LDO3_V_RAMP;
mask = AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK |
--
2.11.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/8] regulator: axp20x: add support for set_ramp_delay for AXP209
On Wed, Dec 12, 2018 at 12:14:57AM +1100, Julian Calaby wrote:
> Hi Priit and Olliver,
>
> On Tue, Dec 11, 2018 at 5:42 AM Priit Laes wrote:
> >
> > From: Olliver Schinagl
> >
> > The AXP209 supports ramping up voltages on several regulators such as
> > DCDC2 and LDO3.
> >
> > This patch adds preliminary support for the regulator-ramp-delay property
> > for these 2 regulators. Note that the voltage ramp only works when
> > regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V.
> >
> > When turning on the regulator, no voltage ramp is performed in hardware.
> >
> > What this means, is that if the bootloader brings up the voltage at 0.7 V,
> > the ramp delay property is properly applied. If however, the bootloader
> > leaves the power off, no ramp delay is applied when the power is
> > enabled by the regulator framework.
> >
> > Signed-off-by: Olliver Schinagl
> > Signed-off-by: Priit Laes
> > ---
> > drivers/regulator/axp20x-regulator.c | 85 +-
> > 1 file changed, 85 insertions(+)
> >
> > diff --git a/drivers/regulator/axp20x-regulator.c
> > b/drivers/regulator/axp20x-regulator.c
> > index 9a2db28..1d9fa62 100644
> > --- a/drivers/regulator/axp20x-regulator.c
> > +++ b/drivers/regulator/axp20x-regulator.c
> > @@ -346,6 +357,79 @@
> > .ops= _ops_range,
> > \
> > }
> >
> > +static const int axp209_dcdc2_ldo3_slew_rates[] = {
> > + 1600,
> > +800,
> > +};
> > +
> > +static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
> > +{
> > + struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
> > + const struct regulator_desc *desc = rdev->desc;
> > + u8 reg, mask, enable, cfg = 0xff;
> > + const int *slew_rates;
> > + int rate_count = 0;
> > +
> > + if (!rdev)
> > + return -EINVAL;
> > +
> > + switch (axp20x->variant) {
> > + case AXP209_ID:
> > + if (desc->id == AXP20X_DCDC2) {
>
> Is slew_rates supposed to be set here?
Yes, nice catch.
>
> > + rate_count =
> > ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
> > + reg = AXP20X_DCDC2_LDO3_V_RAMP;
> > + mask = AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK |
> > + AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK;
> > + enable = (ramp > 0) ?
> > +AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN :
> > +!AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN;
> > + break;
> > + }
> > +
> > + if (desc->id == AXP20X_LDO3) {
> > + slew_rates = axp209_dcdc2_ldo3_slew_rates;
> > + rate_count =
> > ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
> > + reg = AXP20X_DCDC2_LDO3_V_RAMP;
> > + mask = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASK |
> > + AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK;
> > + enable = (ramp > 0) ?
> > +AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN :
> > +!AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN;
> > + break;
> > + }
> > +
> > + if (rate_count > 0)
> > + break;
>
> You could save one to two tests by combining the above three if statements,
> i.e.
>
> if (DCDC2) {
> // set DCDC2 stuff
>
> break;
> } else if (LDO3) {
> // set LDO3 stuff
>
> break;
> }
OK, will look into it.
>
> As written, the rate_count > 0 test will never be true as every block
> that sets rate_count breaks out of the switch block.
Yes, it is somewhat superfluous, as each regulator which supports ramping
should break out of the switch itself.
> You could then calculate rate_count below the switch block.
>
> > +
> > + /* fall through */
> > + default:
> > + /* Not supported for this regulator */
> > + return -ENOTSUPP;
> > + }
> > +
> > + if (ramp == 0) {
> > + cfg = enable;
> > + } else {
> > + int i;
> > +
> > + for (i = 0; i < rate_count; i++) {
> > + if (ramp
[linux-sunxi] [PATCH v2 6/8] regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2
From: Olliver Schinagl
The OLinuXino Lime2 has a big capacitor on its LDO3 output. It is
actually too large, causing the PMIC to shutdown when toggling the LDO3.
By enabling soft-start and ramp delay we increase the time for the
capacitor to charge lowering the current drain on the power regulator.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index 55c9086..4e1c590 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -232,6 +232,8 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-name = "vddio-csi0";
+ regulator-soft-start;
+ regulator-ramp-delay = <1600>;
};
_ldo4 {
--
git-series 0.9.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.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 7/8] mfd: axp20x: Clean up included headers
From: Olliver Schinagl Add the bitops.h header as we need it, alphabetize header order. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes Acked-for-MFD-by: Lee Jones --- drivers/mfd/axp20x.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index dfc3cff..c3f3dbd 100644 --- a/drivers/mfd/axp20x.c +++ b/drivers/mfd/axp20x.c @@ -16,18 +16,19 @@ * published by the Free Software Foundation. */ -#include +#include +#include #include +#include #include #include +#include +#include #include +#include #include #include #include -#include -#include -#include -#include #define AXP20X_OFF 0x80 -- git-series 0.9.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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 4/8] regulator: axp20x: add software based soft_start for AXP209 LDO3
From: Olliver Schinagl
In the past, there have been words on various lists that if LDO3 is
disabled in u-boot, but enabled in the DTS, the axp209 driver would
fail to continue/hang. Several enable/disable patches have been
issues to devicetree's in both the kernel and u-boot to address
this issue.
What really happened however, was that the AXP209 shuts down without
a notice and without setting an interrupt. This is caused when LDO3
gets overloaded, for example with large capacitors on the LDO3 output.
Normally, we would expect that AXP209 would source 200 mA as per
datasheet and set and trigger an interrupt when being overloaded.
For some reason however, this does not happen.
As a work-around, we use the soft-start constraint of the regulator
node to first bring up the LDO3 to the lowest possible voltage and
then enable the LDO. After that, we can set the requested voltage
as usual.
Combining this setting with the regulator-ramp-delay allows LDO3 to
enable voltage slowly and staggered, potentially reducing overall
inrush current.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
---
drivers/regulator/axp20x-regulator.c | 57 -
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 1d9fa62..e8a895b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
#include
#include
#include
+#include
#include
#define AXP20X_GPIO0_FUNC_MASK GENMASK(3, 0)
@@ -430,6 +432,59 @@ static int axp20x_set_ramp_delay(struct regulator_dev
*rdev, int ramp)
return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
}
+static int axp20x_regulator_enable_regmap(struct regulator_dev *rdev)
+{
+ struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
+ const struct regulator_desc *desc = rdev->desc;
+
+ if (!rdev)
+ return -EINVAL;
+
+ switch (axp20x->variant) {
+ case AXP209_ID:
+ if ((desc->id == AXP20X_LDO3) &&
+ rdev->constraints && rdev->constraints->soft_start) {
+ int v_out;
+ int ret;
+
+ /*
+* On some boards, the LDO3 can be overloaded when
+* turning on, causing the entire PMIC to shutdown
+* without warning. Turning it on at the minimal voltage
+* and then setting the voltage to the requested value
+* works reliably.
+*/
+ if (regulator_is_enabled_regmap(rdev))
+ break;
+
+ v_out = regulator_get_voltage_sel_regmap(rdev);
+ if (v_out < 0)
+ return v_out;
+
+ if (v_out == 0)
+ break;
+
+ ret = regulator_set_voltage_sel_regmap(rdev, 0x00);
+ /*
+* A small pause is needed between
+* setting the voltage and enabling the LDO to give the
+* internal state machine time to process the request.
+*/
+ usleep_range(1000, 5000);
+ ret |= regulator_enable_regmap(rdev);
+ ret |= regulator_set_voltage_sel_regmap(rdev, v_out);
+
+ return ret;
+ }
+ break;
+ default:
+ /* No quirks */
+ break;
+ }
+
+ return regulator_enable_regmap(rdev);
+};
+
static const struct regulator_ops axp20x_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
};
@@ -447,7 +502,7 @@ static const struct regulator_ops axp20x_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear,
- .enable = regulator_enable_regmap,
+ .enable = axp20x_regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
.set_ramp_delay = axp20x_set_ramp_delay,
--
git-series 0.9.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.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 3/8] dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209
From: Olliver Schinagl The AXP209 supports ramping up voltages on several regulators such as DCDC2 and LDO3, therefore we can use the standard 'regulator-ramp-delay' property for those 2 regulators. Note that the voltage ramp only works when the regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V. When turning on the regulator, no voltage ramp is performed in hardware. What this means, is that if the bootloader brings up the voltage at 0.7 V, the ramp delay property is properly applied. If however, the bootloader leaves the power off, no ramp delay is applied when the power is enabled by the regulator framework. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes Acked-for-MFD-by: Lee Jones --- Documentation/devicetree/bindings/mfd/axp20x.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 188f037..c626605 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -32,6 +32,12 @@ Required properties: - interrupt-controller: The PMIC has its own internal IRQs - #interrupt-cells: Should be set to 1 +Supported common regulator properties, see ../regulator/regulator.txt for +more information: +- regulator-ramp-delay: sets the ramp up delay in uV/us + AXP20x/DCDC2: 1600, 800 + AXP20x/LDO3: 1600, 800 + Optional properties: - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz AXP152/20X: range: 750-1875, Default: 1.5 MHz -- git-series 0.9.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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 5/8] dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3
From: Olliver Schinagl In the past, there have been words on various lists that if LDO3 is disabled in u-boot, but enabled in the DTS, the axp209 driver would fail to continue/hang. Several enable/disable patches have been issues to devicetree's in both the kernel and u-boot to address this issue. What really happened however, was that the AXP209 shuts down without a notice and without setting an interrupt. This is caused when LDO3 gets overloaded, for example with large capacitors on the LDO3 output. Normally, we would expect that AXP209 would source 200 mA as per datasheet and set and trigger an interrupt when being overloaded. For some reason however, this does not happen. As a work-around, implement software-based 'regulator-soft-start' property for AXP209 LDO3 regulator, which is used to first bring up the LDO3 to the lowest possible voltage and then enable the LDO. After that, we can set the requested voltage as usual. Combining this setting with the regulator-ramp-delay allows LDO3 to come up slowly and staggered, potentially reducing overall inrush current. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes --- Documentation/devicetree/bindings/mfd/axp20x.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index c626605..2af4ff9 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -37,6 +37,9 @@ more information: - regulator-ramp-delay: sets the ramp up delay in uV/us AXP20x/DCDC2: 1600, 800 AXP20x/LDO3: 1600, 800 +- regulator-soft-start:enable the output at the lowest possible voltage and + only then set the desired voltage + AXP20x/LDO3: software-based implementation Optional properties: - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz -- git-series 0.9.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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 8/8] mfd: axp20x: use explicit bit defines
From: Olliver Schinagl The AXP20X_OFF define is an actual specific bit, define it as such. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes Acked-for-MFD-by: Lee Jones --- drivers/mfd/axp20x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index c3f3dbd..d183ed8 100644 --- a/drivers/mfd/axp20x.c +++ b/drivers/mfd/axp20x.c @@ -30,7 +30,7 @@ #include #include -#define AXP20X_OFF 0x80 +#define AXP20X_OFF BIT(7) #define AXP806_REG_ADDR_EXT_ADDR_MASTER_MODE 0 #define AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODEBIT(4) -- git-series 0.9.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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 0/8] regulator: axp20x: Stop AXP209 from crashing when enabling LDO3
This is a second edition of a series that implements voltage ramping for AXP209 DCDC2 and LDO3 regulators and software based soft-start for AXP209 LDO3 regulator. Both features are needed to work around a PMIC shutdown when toggling LDO3 on certain boards with high capacitance on the LDO3 output. Similar features (or workarounds) have been also implemented on u-boot side [1]. Changes since v1: - Rebased on top of next and dropped already merged patches. - Dropped LDO4 full range devicetree change for Lime2 (prev patch 9) in favor of general pin-bank regulator dependency [2]. - Fixed paths in devicetree bindings (patch 3) - Added note about software based soft-start for LDO3 (patch 5) [1] https://lists.denx.de/pipermail/u-boot/2018-November/348612.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-December/618459.html Olliver Schinagl (8): mfd: axp20x: name voltage ramping define properly regulator: axp20x: add support for set_ramp_delay for AXP209 dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209 regulator: axp20x: add software based soft_start for AXP209 LDO3 dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3 regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2 mfd: axp20x: Clean up included headers mfd: axp20x: use explicit bit defines Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +- arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +- drivers/mfd/axp20x.c | 13 +- drivers/regulator/axp20x-regulator.c | 142 +++- include/linux/mfd/axp20x.h | 4 +- 5 files changed, 161 insertions(+), 9 deletions(-) base-commit: 14cf8c1d5b90a0cf6a8ba51ef59db8da8c7a2622 -- git-series 0.9.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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 1/8] mfd: axp20x: name voltage ramping define properly
From: Olliver Schinagl
The current axp20x names the ramping register 'scal' which probably
means scaling. Since the register really has nothing to do with
scaling, but really is the voltage ramp we rename it appropriately.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
Acked-for-MFD-by: Lee Jones
---
include/linux/mfd/axp20x.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 2302b62..a353cd2 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -35,7 +35,7 @@ enum axp20x_variants {
#define AXP152_ALDO_OP_MODE0x13
#define AXP152_LDO0_CTRL 0x15
#define AXP152_DCDC2_V_OUT 0x23
-#define AXP152_DCDC2_V_SCAL0x25
+#define AXP152_DCDC2_V_RAMP0x25
#define AXP152_DCDC1_V_OUT 0x26
#define AXP152_DCDC3_V_OUT 0x27
#define AXP152_ALDO12_V_OUT0x28
@@ -53,7 +53,7 @@ enum axp20x_variants {
#define AXP20X_USB_OTG_STATUS 0x02
#define AXP20X_PWR_OUT_CTRL0x12
#define AXP20X_DCDC2_V_OUT 0x23
-#define AXP20X_DCDC2_LDO3_V_SCAL 0x25
+#define AXP20X_DCDC2_LDO3_V_RAMP 0x25
#define AXP20X_DCDC3_V_OUT 0x27
#define AXP20X_LDO24_V_OUT 0x28
#define AXP20X_LDO3_V_OUT 0x29
--
git-series 0.9.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.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 2/8] regulator: axp20x: add support for set_ramp_delay for AXP209
From: Olliver Schinagl
The AXP209 supports ramping up voltages on several regulators such as
DCDC2 and LDO3.
This patch adds preliminary support for the regulator-ramp-delay property
for these 2 regulators. Note that the voltage ramp only works when
regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V.
When turning on the regulator, no voltage ramp is performed in hardware.
What this means, is that if the bootloader brings up the voltage at 0.7 V,
the ramp delay property is properly applied. If however, the bootloader
leaves the power off, no ramp delay is applied when the power is
enabled by the regulator framework.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
---
drivers/regulator/axp20x-regulator.c | 85 +-
1 file changed, 85 insertions(+)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 9a2db28..1d9fa62 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -51,6 +51,17 @@
#define AXP20X_PWR_OUT_DCDC2_MASK BIT_MASK(4)
#define AXP20X_PWR_OUT_LDO3_MASK BIT_MASK(6)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK BIT_MASK(0)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE(x) \
+ ((x) << 0)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASKBIT_MASK(1)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(x) \
+ ((x) << 1)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK BIT_MASK(2)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN BIT(2)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK BIT_MASK(3)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN BIT(3)
+
#define AXP20X_LDO4_V_OUT_1250mV_START 0x0
#define AXP20X_LDO4_V_OUT_1250mV_STEPS 0
#define AXP20X_LDO4_V_OUT_1250mV_END \
@@ -346,6 +357,79 @@
.ops= _ops_range,
\
}
+static const int axp209_dcdc2_ldo3_slew_rates[] = {
+ 1600,
+800,
+};
+
+static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
+{
+ struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
+ const struct regulator_desc *desc = rdev->desc;
+ u8 reg, mask, enable, cfg = 0xff;
+ const int *slew_rates;
+ int rate_count = 0;
+
+ if (!rdev)
+ return -EINVAL;
+
+ switch (axp20x->variant) {
+ case AXP209_ID:
+ if (desc->id == AXP20X_DCDC2) {
+ rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
+ reg = AXP20X_DCDC2_LDO3_V_RAMP;
+ mask = AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK |
+ AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK;
+ enable = (ramp > 0) ?
+AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN :
+!AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN;
+ break;
+ }
+
+ if (desc->id == AXP20X_LDO3) {
+ slew_rates = axp209_dcdc2_ldo3_slew_rates;
+ rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
+ reg = AXP20X_DCDC2_LDO3_V_RAMP;
+ mask = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASK |
+ AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK;
+ enable = (ramp > 0) ?
+AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN :
+!AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN;
+ break;
+ }
+
+ if (rate_count > 0)
+ break;
+
+ /* fall through */
+ default:
+ /* Not supported for this regulator */
+ return -ENOTSUPP;
+ }
+
+ if (ramp == 0) {
+ cfg = enable;
+ } else {
+ int i;
+
+ for (i = 0; i < rate_count; i++) {
+ if (ramp <= slew_rates[i])
+ cfg = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(i);
+ else
+ break;
+ }
+
+ if (cfg == 0xff) {
+ dev_err(axp20x->dev, "unsupported ramp value %d", ramp);
+ return -EINVAL;
+ }
+
+ cfg |= enable;
+ }
+
+ return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
+}
+
static const struct regulator_ops axp20x_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
};
@@ -366,6 +450,7 @@ static const struct regulator_ops axp20x_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
+ .set_ramp_delay = axp20x_set_ramp_delay,
};
static cons
Re: [linux-sunxi] [PATCH 0/8] This is a second edition of a series that implements voltage
On Mon, Dec 10, 2018 at 08:42:11PM +0200, Priit Laes wrote: > ramping for AXP209 DCDC2 and LDO3 regulators and software > based soft-start for AXP209 LDO3 regulator. Ugh.. managed to botch this series. I'll send a fixed one today. > > Both features are needed to work around a PMIC shutdown when > toggling LDO3 on certain boards with high capacitance on the > LDO3 output. > > Similar features (or workarounds) have been also implemented > on u-boot side [1]. > > Changes since v1: > - Rebased on top of next and dropped already merged patches. > - Dropped LDO4 full range devicetree change for Lime2 (prev patch 9) > in favor of general pin-bank regulator dependency [2]. > - Fixed paths in devicetree bindings (patch 3) > - Added note about software based soft-start for LDO3 (patch 5) > > [1] https://lists.denx.de/pipermail/u-boot/2018-November/348612.html > [2] > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-December/618459.html > > Olliver Schinagl (8): > mfd: axp20x: name voltage ramping define properly > regulator: axp20x: add support for set_ramp_delay for AXP209 > dt-bindings: mfd: axp20x: add support for regulator-ramp-delay for AXP209 > regulator: axp20x: add software based soft_start for AXP209 LDO3 > dt-bindings: mfd: axp20x: Add software based soft_start for AXP209 LDO3 > regulator: dts: enable soft-start and ramp delay for the OLinuXino Lime2 > mfd: axp20x: Clean up included headers > mfd: axp20x: use explicit bit defines > > Documentation/devicetree/bindings/mfd/axp20x.txt | 9 +- > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +- > drivers/mfd/axp20x.c | 13 +- > drivers/regulator/axp20x-regulator.c | 142 +++- > include/linux/mfd/axp20x.h | 4 +- > 5 files changed, 161 insertions(+), 9 deletions(-) > > base-commit: 14cf8c1d5b90a0cf6a8ba51ef59db8da8c7a2622 > -- > git-series 0.9.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. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 8/8] mfd: axp20x: use explicit bit defines
From: Olliver Schinagl The AXP20X_OFF define is an actual specific bit, define it as such. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes Acked-for-MFD-by: Lee Jones --- drivers/mfd/axp20x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c index c3f3dbd..d183ed8 100644 --- a/drivers/mfd/axp20x.c +++ b/drivers/mfd/axp20x.c @@ -30,7 +30,7 @@ #include #include -#define AXP20X_OFF 0x80 +#define AXP20X_OFF BIT(7) #define AXP806_REG_ADDR_EXT_ADDR_MASTER_MODE 0 #define AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODEBIT(4) -- git-series 0.9.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. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/8] regulator: axp20x: add support for set_ramp_delay for AXP209
From: Olliver Schinagl
The AXP209 supports ramping up voltages on several regulators such as
DCDC2 and LDO3.
This patch adds preliminary support for the regulator-ramp-delay property
for these 2 regulators. Note that the voltage ramp only works when
regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V.
When turning on the regulator, no voltage ramp is performed in hardware.
What this means, is that if the bootloader brings up the voltage at 0.7 V,
the ramp delay property is properly applied. If however, the bootloader
leaves the power off, no ramp delay is applied when the power is
enabled by the regulator framework.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
---
drivers/regulator/axp20x-regulator.c | 85 +-
1 file changed, 85 insertions(+)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 9a2db28..1d9fa62 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -51,6 +51,17 @@
#define AXP20X_PWR_OUT_DCDC2_MASK BIT_MASK(4)
#define AXP20X_PWR_OUT_LDO3_MASK BIT_MASK(6)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK BIT_MASK(0)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE(x) \
+ ((x) << 0)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASKBIT_MASK(1)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(x) \
+ ((x) << 1)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK BIT_MASK(2)
+#define AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN BIT(2)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK BIT_MASK(3)
+#define AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN BIT(3)
+
#define AXP20X_LDO4_V_OUT_1250mV_START 0x0
#define AXP20X_LDO4_V_OUT_1250mV_STEPS 0
#define AXP20X_LDO4_V_OUT_1250mV_END \
@@ -346,6 +357,79 @@
.ops= _ops_range,
\
}
+static const int axp209_dcdc2_ldo3_slew_rates[] = {
+ 1600,
+800,
+};
+
+static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
+{
+ struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
+ const struct regulator_desc *desc = rdev->desc;
+ u8 reg, mask, enable, cfg = 0xff;
+ const int *slew_rates;
+ int rate_count = 0;
+
+ if (!rdev)
+ return -EINVAL;
+
+ switch (axp20x->variant) {
+ case AXP209_ID:
+ if (desc->id == AXP20X_DCDC2) {
+ rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
+ reg = AXP20X_DCDC2_LDO3_V_RAMP;
+ mask = AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK |
+ AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK;
+ enable = (ramp > 0) ?
+AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN :
+!AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN;
+ break;
+ }
+
+ if (desc->id == AXP20X_LDO3) {
+ slew_rates = axp209_dcdc2_ldo3_slew_rates;
+ rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
+ reg = AXP20X_DCDC2_LDO3_V_RAMP;
+ mask = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASK |
+ AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK;
+ enable = (ramp > 0) ?
+AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN :
+!AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN;
+ break;
+ }
+
+ if (rate_count > 0)
+ break;
+
+ /* fall through */
+ default:
+ /* Not supported for this regulator */
+ return -ENOTSUPP;
+ }
+
+ if (ramp == 0) {
+ cfg = enable;
+ } else {
+ int i;
+
+ for (i = 0; i < rate_count; i++) {
+ if (ramp <= slew_rates[i])
+ cfg = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(i);
+ else
+ break;
+ }
+
+ if (cfg == 0xff) {
+ dev_err(axp20x->dev, "unsupported ramp value %d", ramp);
+ return -EINVAL;
+ }
+
+ cfg |= enable;
+ }
+
+ return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
+}
+
static const struct regulator_ops axp20x_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
};
@@ -366,6 +450,7 @@ static const struct regulator_ops axp20x_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
+ .set_ramp_delay = axp20x_set_ramp_delay,
};
static cons
[linux-sunxi] [PATCH 4/8] regulator: axp20x: add software based soft_start for AXP209 LDO3
From: Olliver Schinagl
In the past, there have been words on various lists that if LDO3 is
disabled in u-boot, but enabled in the DTS, the axp209 driver would
fail to continue/hang. Several enable/disable patches have been
issues to devicetree's in both the kernel and u-boot to address
this issue.
What really happened however, was that the AXP209 shuts down without
a notice and without setting an interrupt. This is caused when LDO3
gets overloaded, for example with large capacitors on the LDO3 output.
Normally, we would expect that AXP209 would source 200 mA as per
datasheet and set and trigger an interrupt when being overloaded.
For some reason however, this does not happen.
As a work-around, we use the soft-start constraint of the regulator
node to first bring up the LDO3 to the lowest possible voltage and
then enable the LDO. After that, we can set the requested voltage
as usual.
Combining this setting with the regulator-ramp-delay allows LDO3 to
enable voltage slowly and staggered, potentially reducing overall
inrush current.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
---
drivers/regulator/axp20x-regulator.c | 57 -
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 1d9fa62..e8a895b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
#include
#include
#include
+#include
#include
#define AXP20X_GPIO0_FUNC_MASK GENMASK(3, 0)
@@ -430,6 +432,59 @@ static int axp20x_set_ramp_delay(struct regulator_dev
*rdev, int ramp)
return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
}
+static int axp20x_regulator_enable_regmap(struct regulator_dev *rdev)
+{
+ struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
+ const struct regulator_desc *desc = rdev->desc;
+
+ if (!rdev)
+ return -EINVAL;
+
+ switch (axp20x->variant) {
+ case AXP209_ID:
+ if ((desc->id == AXP20X_LDO3) &&
+ rdev->constraints && rdev->constraints->soft_start) {
+ int v_out;
+ int ret;
+
+ /*
+* On some boards, the LDO3 can be overloaded when
+* turning on, causing the entire PMIC to shutdown
+* without warning. Turning it on at the minimal voltage
+* and then setting the voltage to the requested value
+* works reliably.
+*/
+ if (regulator_is_enabled_regmap(rdev))
+ break;
+
+ v_out = regulator_get_voltage_sel_regmap(rdev);
+ if (v_out < 0)
+ return v_out;
+
+ if (v_out == 0)
+ break;
+
+ ret = regulator_set_voltage_sel_regmap(rdev, 0x00);
+ /*
+* A small pause is needed between
+* setting the voltage and enabling the LDO to give the
+* internal state machine time to process the request.
+*/
+ usleep_range(1000, 5000);
+ ret |= regulator_enable_regmap(rdev);
+ ret |= regulator_set_voltage_sel_regmap(rdev, v_out);
+
+ return ret;
+ }
+ break;
+ default:
+ /* No quirks */
+ break;
+ }
+
+ return regulator_enable_regmap(rdev);
+};
+
static const struct regulator_ops axp20x_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
};
@@ -447,7 +502,7 @@ static const struct regulator_ops axp20x_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear,
- .enable = regulator_enable_regmap,
+ .enable = axp20x_regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
.set_ramp_delay = axp20x_set_ramp_delay,
--
git-series 0.9.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.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/8] mfd: axp20x: name voltage ramping define properly
From: Olliver Schinagl
The current axp20x names the ramping register 'scal' which probably
means scaling. Since the register really has nothing to do with
scaling, but really is the voltage ramp we rename it appropriately.
Signed-off-by: Olliver Schinagl
Signed-off-by: Priit Laes
Acked-for-MFD-by: Lee Jones
---
include/linux/mfd/axp20x.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 2302b62..a353cd2 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -35,7 +35,7 @@ enum axp20x_variants {
#define AXP152_ALDO_OP_MODE0x13
#define AXP152_LDO0_CTRL 0x15
#define AXP152_DCDC2_V_OUT 0x23
-#define AXP152_DCDC2_V_SCAL0x25
+#define AXP152_DCDC2_V_RAMP0x25
#define AXP152_DCDC1_V_OUT 0x26
#define AXP152_DCDC3_V_OUT 0x27
#define AXP152_ALDO12_V_OUT0x28
@@ -53,7 +53,7 @@ enum axp20x_variants {
#define AXP20X_USB_OTG_STATUS 0x02
#define AXP20X_PWR_OUT_CTRL0x12
#define AXP20X_DCDC2_V_OUT 0x23
-#define AXP20X_DCDC2_LDO3_V_SCAL 0x25
+#define AXP20X_DCDC2_LDO3_V_RAMP 0x25
#define AXP20X_DCDC3_V_OUT 0x27
#define AXP20X_LDO24_V_OUT 0x28
#define AXP20X_LDO3_V_OUT 0x29
--
git-series 0.9.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.
For more options, visit https://groups.google.com/d/optout.
