[linux-sunxi] [PATCH v2 3/3] ARM: sunxi: Clean up sunxi_defconfig
Clean up sunxi_defconfig by generating a fresh file via make sunxi_defconfig make savedefconfig While this moves around a few lines and removes unnecessary symbols, it doesn't introduce any functional changes. The resulting .config is identical before and after this patch. Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> --- arch/arm/configs/sunxi_defconfig | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 90252ca..95b51fc 100644 --- a/arch/arm/configs/sunxi_defconfig +++ b/arch/arm/configs/sunxi_defconfig @@ -11,14 +11,12 @@ CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_AEABI=y CONFIG_HIGHMEM=y -CONFIG_HIGHPTE=y CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CPU_FREQ=y CONFIG_CPUFREQ_DT=y CONFIG_VFP=y CONFIG_NEON=y -CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -60,12 +58,12 @@ CONFIG_STMMAC_ETH=y # CONFIG_NET_VENDOR_WIZNET is not set # CONFIG_WLAN is not set # CONFIG_INPUT_MOUSEDEV is not set +CONFIG_KEYBOARD_SUN4I_LRADC=y # CONFIG_INPUT_MOUSE is not set -CONFIG_INPUT_MISC=y -CONFIG_INPUT_AXP20X_PEK=y CONFIG_INPUT_TOUCHSCREEN=y -CONFIG_KEYBOARD_SUN4I_LRADC=y CONFIG_TOUCHSCREEN_SUN4I=y +CONFIG_INPUT_MISC=y +CONFIG_INPUT_AXP20X_PEK=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=8 -- 2.1.4 -- You received this message because you are subscribed to the Google 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/3] ARM: sunxi: Really enable LRADC keys in sunxi_defconfig
Commit be8becb81bdc ("ARM: sunxi_defconfig: Enable LRADC keys
(KEYBOARD_SUN4I_LRADC)") added CONFIG_KEYBOARD_SUN4I_LRADC=y to
sunxi_defconfig. However, it depends on CONFIG_KEYBOARD which is
explicitly disabled in sunxi_defconfig. Hence, the LRADC keys were
never actually enabled. Remove the line disabling CONFIG_KEYBOARD in
order to really enable KEYBOARD_SUN4I_LRADC.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
arch/arm/configs/sunxi_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 0bbc2ee..90252ca 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -60,7 +60,6 @@ CONFIG_STMMAC_ETH=y
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_WLAN is not set
# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_AXP20X_PEK=y
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Sorry, sent out the reply first to Maxime only and forgot to include the
rest of the bunch. So, here we go again...
Hi Maxime,
Am Freitag, den 20.11.2015, 00:43 +0100 schrieb Maxime Ripard:
> Hi,
>
> On Thu, Nov 19, 2015 at 10:48:35PM +0100, Timo Sigurdsson wrote:
> > Hi Maxime,
> > Hi Chen-Yu,
> >
> > Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> > > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the
nvmem
> > > framework") moved the the sunxi SID driver to a new framework, but
left
> > > sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the
driver
> > > in sunxi_defconfig.
> > >
> > > While at it, clean up sunxi_defconfig by generating a fresh file
via
> > > make sunxi_defconfig
> > > make savedefconfig
> > > While this moves around a few lines and removes unnecessary
symbols,
> > > it doesn't introduce any functional changes.
> > >
> > > Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> > >
> > > diff --git a/arch/arm/configs/sunxi_defconfig
b/arch/arm/configs/sunxi_defconfig
> > > index 3c36e16..904ea52 100644
> > > --- a/arch/arm/configs/sunxi_defconfig
> > > +++ b/arch/arm/configs/sunxi_defconfig
> > > @@ -11,14 +11,12 @@ CONFIG_SMP=y
> > > CONFIG_NR_CPUS=8
> > > CONFIG_AEABI=y
> > > CONFIG_HIGHMEM=y
> > > -CONFIG_HIGHPTE=y
> > > CONFIG_ARM_APPENDED_DTB=y
> > > CONFIG_ARM_ATAG_DTB_COMPAT=y
> > > CONFIG_CPU_FREQ=y
> > > CONFIG_CPUFREQ_DT=y
> > > CONFIG_VFP=y
> > > CONFIG_NEON=y
> > > -CONFIG_PM=y
> > > CONFIG_NET=y
> > > CONFIG_PACKET=y
> > > CONFIG_UNIX=y
> > > @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
> > > # CONFIG_WIRELESS is not set
> > > CONFIG_DEVTMPFS=y
> > > CONFIG_DEVTMPFS_MOUNT=y
> > > -CONFIG_EEPROM_SUNXI_SID=y
> > > CONFIG_BLK_DEV_SD=y
> > > CONFIG_ATA=y
> > > CONFIG_AHCI_SUNXI=y
> > > @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
> > > # CONFIG_INPUT_MOUSEDEV is not set
> > > # CONFIG_INPUT_KEYBOARD is not set
> > > # CONFIG_INPUT_MOUSE is not set
> > > -CONFIG_INPUT_MISC=y
> > > -CONFIG_INPUT_AXP20X_PEK=y
> > > CONFIG_INPUT_TOUCHSCREEN=y
> > > -CONFIG_KEYBOARD_SUN4I_LRADC=y
> > > CONFIG_TOUCHSCREEN_SUN4I=y
> > > +CONFIG_INPUT_MISC=y
> > > +CONFIG_INPUT_AXP20X_PEK=y
> > > CONFIG_SERIAL_8250=y
> > > CONFIG_SERIAL_8250_CONSOLE=y
> > > CONFIG_SERIAL_8250_NR_UARTS=8
> > > @@ -123,6 +119,8 @@ CONFIG_PWM=y
> > > CONFIG_PWM_SUN4I=y
> > > CONFIG_PHY_SUN4I_USB=y
> > > CONFIG_PHY_SUN9I_USB=y
> > > +CONFIG_NVMEM=y
> > > +CONFIG_NVMEM_SUNXI_SID=y
> > > CONFIG_EXT4_FS=y
> > > CONFIG_VFAT_FS=y
> > > CONFIG_TMPFS=y
> >
> > Would you also prefer to see this patch split up into two patches
(one
> > for re-enabling the SID driver and one for the extra cleanup of
> > sunxi_defconfg) as I was asked to do for my other patch for
> > multi_v7_defconfig?
>
> Yes, please do.
Ok.
>
> Also why CONFIG_PM CONFIG_KEYBOARD_SUN4I_LRADC and CONFIG_HIGHPTE got
> removed ?
CONFIG_HIGHPTE defaults to yes since 4.4-rc1 in arch/arm/Kconfig, so we
don't need it in sunxi_defconfig anymore. CONFIG_PM is already selected
by CONFIG_ARCH_MULTI_V7, so also no need to set that explicitly.
What's interesting is CONFIG_KEYBOARD_SUN4I_LRADC, because that actually
does _NOT_ get enabled by sunxi_defconfig. I didn't notice earlier,
because before and after my patch, the resulting .config was identical.
The problem with CONFIG_KEYBOARD_SUN4I_LRADC is that keyboard support is
explicitly disabled in sunxi_defconfig which is why
CONFIG_KEYBOARD_SUN4I_LRADC is simply ignored.
So, we need to remove the line
# CONFIG_INPUT_KEYBOARD is not set
in order to actually have CONFIG_KEYBOARD_SUN4I_LRADC enabled.
I'll write another patch for it.
Regards,
Timo
>
> Thanks,
> 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.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
arch/arm/configs/sunxi_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..0bbc2ee 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
@@ -123,6 +122,8 @@ CONFIG_PWM=y
CONFIG_PWM_SUN4I=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
--
2.1.4
--
You received this message because you are subscribed to the Google 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 v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Sorry, I probably shouldn't send patches at an hour I should rather be
sleeping... As a result, I forgot to add the patch history.
Here it is:
Changes in v2:
- Move the extra cleanup work for sunxi_defconfig to a separate patch
- Add another patch to meet the dependencies of
CONFIG_KEYBOARD_SUN4I_LRADC and not have it removed while cleaning up
Good night,
Timo
Am Freitag, den 20.11.2015, 02:46 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
>
> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> ---
> arch/arm/configs/sunxi_defconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..0bbc2ee 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
> # CONFIG_WIRELESS is not set
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_ATA=y
> CONFIG_AHCI_SUNXI=y
> @@ -123,6 +122,8 @@ CONFIG_PWM=y
> CONFIG_PWM_SUN4I=y
> CONFIG_PHY_SUN4I_USB=y
> CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
> CONFIG_EXT4_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_TMPFS=y
--
You received this message because you are subscribed to the Google 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] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
Changes in v2:
- Move the extra cleanup work for multi_v7_defconfig to a separate
patch (to be submitted at a later point to avoid conflicts with
another patch waiting to be merged)
---
arch/arm/configs/multi_v7_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index eefcab1..59d3d3a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -188,7 +188,6 @@ CONFIG_ATMEL_SSC=m
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_MULTI_LUN=y
@@ -714,6 +713,8 @@ CONFIG_PHY_STIH407_USB=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_SUN9I_USB=y
CONFIG_PHY_SAMSUNG_USB2=m
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
CONFIG_EXT4_FS=y
CONFIG_AUTOFS4_FS=y
CONFIG_MSDOS_FS=y
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
Hi Maxime,
Hi Chen-Yu,
Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
>
> While at it, clean up sunxi_defconfig by generating a fresh file via
> make sunxi_defconfig
> make savedefconfig
> While this moves around a few lines and removes unnecessary symbols,
> it doesn't introduce any functional changes.
>
> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
>
> diff --git a/arch/arm/configs/sunxi_defconfig
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..904ea52 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -11,14 +11,12 @@ CONFIG_SMP=y
> CONFIG_NR_CPUS=8
> CONFIG_AEABI=y
> CONFIG_HIGHMEM=y
> -CONFIG_HIGHPTE=y
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_CPU_FREQ=y
> CONFIG_CPUFREQ_DT=y
> CONFIG_VFP=y
> CONFIG_NEON=y
> -CONFIG_PM=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
> # CONFIG_WIRELESS is not set
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_ATA=y
> CONFIG_AHCI_SUNXI=y
> @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
> # CONFIG_INPUT_MOUSEDEV is not set
> # CONFIG_INPUT_KEYBOARD is not set
> # CONFIG_INPUT_MOUSE is not set
> -CONFIG_INPUT_MISC=y
> -CONFIG_INPUT_AXP20X_PEK=y
> CONFIG_INPUT_TOUCHSCREEN=y
> -CONFIG_KEYBOARD_SUN4I_LRADC=y
> CONFIG_TOUCHSCREEN_SUN4I=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_AXP20X_PEK=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_NR_UARTS=8
> @@ -123,6 +119,8 @@ CONFIG_PWM=y
> CONFIG_PWM_SUN4I=y
> CONFIG_PHY_SUN4I_USB=y
> CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
> CONFIG_EXT4_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_TMPFS=y
Would you also prefer to see this patch split up into two patches (one
for re-enabling the SID driver and one for the extra cleanup of
sunxi_defconfg) as I was asked to do for my other patch for
multi_v7_defconfig?
Thanks,
Timo
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Hi,
Lee Jones schrieb am 17.11.2015 09:07:
> On Tue, 17 Nov 2015, Timo Sigurdsson wrote:
>
>> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
>> framework") moved the the sunxi SID driver to a new framework, but left
>> multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
>> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
>> in multi_v7_defconfig.
>>
>> While at it, clean up multi_v7_defconfig by generating a fresh file via
>> make multi_v7_defconfig
>> make savedefconfig
>> While this moves around a few lines and removes unnecessary symbols,
>> it doesn't introduce any functional changes.
>>
>> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
>
> Please either use Git to submit your changes, or add a diffstat in
> manually. They *are* helpful.
I do use git. But I guess I messed up the command somehow so the diffstat
wasn't included. Sorry about that. I'll make sure it's there next time.
Thanks,
Timo
[...]
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Hi, Krzysztof Kozlowski schrieb am 17.11.2015 09:21: [...] >>> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y >>> > CONFIG_MEDIA_CONTROLLER=y >>> > CONFIG_VIDEO_V4L2_SUBDEV_API=y >>> > CONFIG_MEDIA_USB_SUPPORT=y >>> > -CONFIG_USB_VIDEO_CLASS=y >>> > -CONFIG_USB_GSPCA=y >>> > +CONFIG_USB_VIDEO_CLASS=m >>> > CONFIG_V4L_PLATFORM_DRIVERS=y >>> > CONFIG_SOC_CAMERA=m >>> > CONFIG_SOC_CAMERA_PLATFORM=m >>> > @@ -465,28 +445,25 @@ CONFIG_DRM=y >>> > CONFIG_DRM_I2C_ADV7511=m >>> > # CONFIG_DRM_I2C_CH7006 is not set >>> > # CONFIG_DRM_I2C_SIL164 is not set >>> > -CONFIG_DRM_NXP_PTN3460=m >>> > -CONFIG_DRM_PARADE_PS8622=m >>> > CONFIG_DRM_NOUVEAU=m >>> > CONFIG_DRM_EXYNOS=m >>> > -CONFIG_DRM_EXYNOS_DSI=y >>> > CONFIG_DRM_EXYNOS_FIMD=y >>> > -CONFIG_DRM_EXYNOS_HDMI=y >>> >>> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled >>> but we are fixing it in: >>> http://www.spinics.net/lists/dri-devel/msg93299.html >> >> I think the problem here is that I don't see this patch in linux-next >> yet. >> > > Indeed... and I don't know when it will go there so actually maybe it > should be removed... but in the same time removing DRM_EXYNOS_HDMI > will probably make some conflicts because mentioned patch will go > through Exynos DRM tree or Samsung SoC. Since you suggested to split my patch into two, I might as well just hold off the "cleanup" patch until Andrzejs patch hits linux-next. Is that ok? Regards, Timo -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
Hi,
Am Dienstag, den 17.11.2015, 11:10 +0900 schrieb Krzysztof Kozlowski:
> On 17.11.2015 10:49, Timo Sigurdsson wrote:
> > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> > framework") moved the the sunxi SID driver to a new framework, but left
> > multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> > in multi_v7_defconfig.
> >
> > While at it, clean up multi_v7_defconfig by generating a fresh file via
> > make multi_v7_defconfig
> > make savedefconfig
> > While this moves around a few lines and removes unnecessary symbols,
> > it doesn't introduce any functional changes.
>
> Split it per change. One change is savedefconfig and second is removing
> or enabling other drivers.
Ok, I can do that.
>
> On which tree you generated the defconfig? There is a minor nit below
> (at least for Exynos platform, I did not checked the others).
The patch was based on torvalds/master (at v4.4-rc1), but I checked
and it applies on linux-next/master just fine.
>
> >
> > Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> >
> > diff --git a/arch/arm/configs/multi_v7_defconfig
> > b/arch/arm/configs/multi_v7_defconfig
> > index 69a22fd..f712ea3 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
>
> (...)
>
> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
> > CONFIG_MEDIA_CONTROLLER=y
> > CONFIG_VIDEO_V4L2_SUBDEV_API=y
> > CONFIG_MEDIA_USB_SUPPORT=y
> > -CONFIG_USB_VIDEO_CLASS=y
> > -CONFIG_USB_GSPCA=y
> > +CONFIG_USB_VIDEO_CLASS=m
> > CONFIG_V4L_PLATFORM_DRIVERS=y
> > CONFIG_SOC_CAMERA=m
> > CONFIG_SOC_CAMERA_PLATFORM=m
> > @@ -465,28 +445,25 @@ CONFIG_DRM=y
> > CONFIG_DRM_I2C_ADV7511=m
> > # CONFIG_DRM_I2C_CH7006 is not set
> > # CONFIG_DRM_I2C_SIL164 is not set
> > -CONFIG_DRM_NXP_PTN3460=m
> > -CONFIG_DRM_PARADE_PS8622=m
> > CONFIG_DRM_NOUVEAU=m
> > CONFIG_DRM_EXYNOS=m
> > -CONFIG_DRM_EXYNOS_DSI=y
> > CONFIG_DRM_EXYNOS_FIMD=y
> > -CONFIG_DRM_EXYNOS_HDMI=y
>
> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
> but we are fixing it in:
> http://www.spinics.net/lists/dri-devel/msg93299.html
I think the problem here is that I don't see this patch in linux-next
yet.
Regards,
Timo
[...]
--
You received this message because you are subscribed to the Google 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: Re-enable SID driver in sunxi_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.
While at it, clean up sunxi_defconfig by generating a fresh file via
make sunxi_defconfig
make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..904ea52 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
CONFIG_VFP=y
CONFIG_NEON=y
-CONFIG_PM=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
@@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=8
@@ -123,6 +119,8 @@ CONFIG_PWM=y
CONFIG_PWM_SUN4I=y
CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
--
2.1.4
--
You received this message because you are subscribed to the Google 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: Re-enable SID driver in multi_v7_defconfig
Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.
While at it, clean up multi_v7_defconfig by generating a fresh file via
make multi_v7_defconfig
make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..f712ea3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,7 +12,6 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_CMDLINE_PARTITION=y
CONFIG_ARCH_VIRT=y
-CONFIG_ARCH_ALPINE=y
CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_375=y
@@ -20,6 +19,7 @@ CONFIG_MACH_ARMADA_38X=y
CONFIG_MACH_ARMADA_39X=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_MACH_DOVE=y
+CONFIG_ARCH_ALPINE=y
CONFIG_ARCH_AT91=y
CONFIG_SOC_SAMA5D2=y
CONFIG_SOC_SAMA5D3=y
@@ -27,9 +27,9 @@ CONFIG_SOC_SAMA5D4=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_CYGNUS=y
CONFIG_ARCH_BCM_NSP=y
-CONFIG_ARCH_BCM_21664=y
-CONFIG_ARCH_BCM_281XX=y
CONFIG_ARCH_BCM_5301X=y
+CONFIG_ARCH_BCM_281XX=y
+CONFIG_ARCH_BCM_21664=y
CONFIG_ARCH_BRCMSTB=y
CONFIG_ARCH_BERLIN=y
CONFIG_MACH_BERLIN_BG2=y
@@ -39,9 +39,9 @@ CONFIG_ARCH_DIGICOLOR=y
CONFIG_ARCH_HIGHBANK=y
CONFIG_ARCH_HISI=y
CONFIG_ARCH_HI3xxx=y
-CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_HIP01=y
CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HIX5HD2=y
CONFIG_ARCH_KEYSTONE=y
CONFIG_ARCH_MESON=y
CONFIG_ARCH_MXC=y
@@ -53,8 +53,9 @@ CONFIG_SOC_IMX6SL=y
CONFIG_SOC_IMX6SX=y
CONFIG_SOC_IMX6UL=y
CONFIG_SOC_IMX7D=y
-CONFIG_SOC_VF610=y
CONFIG_SOC_LS1021A=y
+CONFIG_SOC_VF610=y
+CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP4=y
CONFIG_SOC_OMAP5=y
@@ -62,7 +63,6 @@ CONFIG_SOC_AM33XX=y
CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MEDIATEK=y
CONFIG_ARCH_MSM8X60=y
CONFIG_ARCH_MSM8960=y
CONFIG_ARCH_MSM8974=y
@@ -94,30 +94,22 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
CONFIG_ARCH_TEGRA_3x_SOC=y
CONFIG_ARCH_TEGRA_114_SOC=y
CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
CONFIG_ARCH_UNIPHIER=y
CONFIG_ARCH_U8500=y
CONFIG_MACH_HREFV60=y
CONFIG_MACH_SNOWBALL=y
-CONFIG_MACH_UX500_DT=y
CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_ARCH_VEXPRESS_TC2_PM=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-CONFIG_PCI=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_KEYSTONE=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MVEBU=y
CONFIG_PCI_TEGRA=y
CONFIG_PCI_RCAR_GEN2=y
CONFIG_PCI_RCAR_GEN2_PCIE=y
-CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_KEYSTONE=y
CONFIG_SMP=y
CONFIG_NR_CPUS=16
-CONFIG_HIGHPTE=y
CONFIG_CMA=y
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -125,12 +117,12 @@ CONFIG_KEXEC=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
-CONFIG_NEON=y
-CONFIG_KERNEL_MODE_NEON=y
CONFIG_ARM_ZYNQ_CPUIDLE=y
CONFIG_ARM_EXYNOS_CPUIDLE=y
+CONFIG_KERNEL_MODE_NEON=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -148,13 +140,10 @@ CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
CONFIG_CAN_AT91=m
+CONFIG_CAN_SUN4I=y
CONFIG_CAN_XILINXCAN=y
CONFIG_CAN_MCP251X=y
-CONFIG_CAN_SUN4I=y
CONFIG_BT=m
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
@@ -188,10 +177,8 @@ CONFIG_ATMEL_SSC=m
CONFIG_APDS9802ALS=y
CONFIG_ISL29003=y
CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
-CONFIG_SCSI_MULTI_LUN=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y
@@ -202,10 +189,10 @@ CONFIG_SATA_HIGHBANK=y
CONFIG_SATA_MV=y
CONFIG_SATA_RCAR=y
CONFIG_NETDEVICES=y
-CONFIG_HIX5HD2_GMAC=y
CONFIG_SUN4I_EMAC=y
CONFIG_MACB=y
CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_HIX5HD2_GMAC=y
CONFIG_IGB=y
CONFIG_MV643XX_ETH=y
CONFIG_MVNETA=y
@@ -223,7 +210,6 @@ CONFIG_SMSC_PHY=y
CONFIG_BROADCOM_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_MICREL_PHY=y
-CONFIG_FIXED_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_RTL8152=m
CONFIG_USB_USBNET=y
@@ -239,18 +225,18 @@ CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_QT1070=m
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_CYAPA=m
CONFIG_MOUSE_ELAN_I2C=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=y
+CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_TOUCHSCREEN_ST1232=m
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_TOUCHSCREEN_SUN4I=y
-CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MPU3050=y
CONFIG_INPUT_AXP20X_PEK=y
@@
[linux-sunxi] Re: Hardware Reliability Tests: How reliable are the tests mentioned on the wiki?
Am Mittwoch, den 04.11.2015, 18:39 +0100 schrieb Timo Sigurdsson: > Hi, > > since I have an extra A20 board that doesn't have a specific purpose at the > moment, I thought I do some experiments with it and test performance and > reliability (among other things). > One of my tests involved overclocking the board at stock voltage (1.4V) to > see what the board can do. So I used cpufreq-ljt-stress-test and cpuburn-a7 > as mentioned on the wiki[1]. What surprised me, though, was that the stress > test neither runs for a very long time nor on both cores simultaniously. So, > the test results suggest that my board can do 1104MHz at 1.4V (I didn't try > higher frequencies because I didn't even expect that it would run stable at > 1104 MHz without raising the voltage). > > But I'm wondering - how reliable are these tests actually? I would have > assumed that for the results to be meaningful it would be best to put as much > stress on the CPU as possible and do that over a prolonged period. And if you > have multiple cores, to put them under load simultaniously. It this > assumption wrong? Is such extensive testing neglible in real life? > > Since I didn't trust the quick test, I quickly changed the script to to 600 > iterations instead of 60. But, of course, that doesn't make it run on two > cores. So, while running cpufreq-ljt-stress-test, I also ran cpuburn-a7 in > the background which put both cores under load. The board still passed the > test. > > What kind of tests or setups do you use to determine reliable settings? > > > Thanks, > > Timo > > > [1] http://linux-sunxi.org/Hardware_Reliability_Tests I did some more testing and can answer the main question myself now: I reran my tests again, this time with frequencies up to 1200MHz@1.4V. The unchanged cpufreq-ljt-stress-test fails at 1200MHz but passes at 1152MHz. If I change the test duration by increasing the iterations to 600 and have cpuburn-a7 running in the background while running the stress test, the 1152MHz setting runs fine for quite a while but eventuelly fails on the second core at a late stage - just a few more iterations until it would pass. At 1104MHz it still passes the test. So I guess it's better to take the test result of the unmodified script with a grain of salt and test with more intensive workloads. I'd still be interested to hear what kind of reliable test setups are used or recommended. Maybe we can add some recommendations to the wiki then. Thanks, Timo -- You received this message because you are subscribed to the Google 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: Hardware Reliability Tests: How reliable are the tests mentioned on the wiki?
Hi, Am Mittwoch, den 04.11.2015, 11:07 -0800 schrieb null: > By my tests, A20 with small heatsink can run 1Ghz 24/7 at 1.275mv with > prolonged heavy load(emerge world, gentoo). > > > Without heatsink, it unstable even at 0.8Ghz. > > > my dmesg: > [cpu_freq] INF: voltage = 1625mvfrequency = 1296MHz > [cpu_freq] INF: voltage = 1475mvfrequency = 1200MHz > [cpu_freq] INF: voltage = 1275mvfrequency = 1008MHz that's interesting, although it doesn't really answer my question about how reliable the mentioned tools are. In the meantime, I found out that maybe they are better not considered reliable in absolute terms. But I still think they are useful with regards to the validation of the results of calculations. I also did some kernel compilation before to put the device under heavy load, but there you lack the validation part (other than knowing the system didn't crash). Is that different with gentoo/emerge? (Sorry, not a gentoo user.) Regards, Timo P.S.: Sorry. I forgot to include the mailinglist when I first sent this reply - so this is a "resend". -- You received this message because you are subscribed to the Google 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] Hardware Reliability Tests: How reliable are the tests mentioned on the wiki?
Hi, since I have an extra A20 board that doesn't have a specific purpose at the moment, I thought I do some experiments with it and test performance and reliability (among other things). One of my tests involved overclocking the board at stock voltage (1.4V) to see what the board can do. So I used cpufreq-ljt-stress-test and cpuburn-a7 as mentioned on the wiki[1]. What surprised me, though, was that the stress test neither runs for a very long time nor on both cores simultaniously. So, the test results suggest that my board can do 1104MHz at 1.4V (I didn't try higher frequencies because I didn't even expect that it would run stable at 1104 MHz without raising the voltage). But I'm wondering - how reliable are these tests actually? I would have assumed that for the results to be meaningful it would be best to put as much stress on the CPU as possible and do that over a prolonged period. And if you have multiple cores, to put them under load simultaniously. It this assumption wrong? Is such extensive testing neglible in real life? Since I didn't trust the quick test, I quickly changed the script to to 600 iterations instead of 60. But, of course, that doesn't make it run on two cores. So, while running cpufreq-ljt-stress-test, I also ran cpuburn-a7 in the background which put both cores under load. The board still passed the test. What kind of tests or setups do you use to determine reliable settings? Thanks, Timo [1] http://linux-sunxi.org/Hardware_Reliability_Tests -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v3] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. Also
add board-specific OPP to use slightly higher voltages at lower
frequencies since Kevin Hilman reported that not all BananaPi boards run
stable at the default voltages inherited by sun7i-a20.dtsi.
Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
Changes since v2:
- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 45 +---
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,20 @@
status = "okay";
};
+ {
+ cpu-supply = <_dcdc2>;
+ operating-points = <
+ /* kHzuV */
+ 96 140
+ 912000 140
+ 864000 135
+ 72 125
+ 528000 115
+ 312000 110
+ 144000 105
+ >;
+};
+
{
status = "okay";
};
@@ -119,13 +133,9 @@
status = "okay";
axp209: pmic@34 {
- compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
};
};
@@ -182,6 +192,33 @@
};
};
+#include "axp209.dtsi"
+
+_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "avcc";
+};
+
_usb1_vbus {
status = "okay";
};
--
2.1.4
--
You received this message because you are subscribed to the Google 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 v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Kevin, Hi Maxime, Kevin Hilman schrieb am 07.10.2015 16:36: > "Timo Sigurdsson" <public_tim...@silentcreek.de> writes: >> I still think that the lower voltages may be the cause of your problem >> with that specific board, so could you please test the attached patch on >> top of my patch that you first experienced the problem with? Please let >> us know whether this solves your issue or whether we need to dig deeper. > > Thanks for the patch. Looks like it's the OPPs. > > I went back to next-20150923 and verified it still fails. Then, I > applied your patch and saw that it boots just fine. Good. Then we can easily fix this, I guess. @Maxime: How should we handle this? In its current form, the patch applies only to the BananaPi dts by overriding the inherited opp from the SoC dtsi. In an earlier discussion, it was said that this can be done, even though it might not be the most elegant approach. But then again, I think it shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20 boards since this is - to my knowledge - the first and only report that an A20 board has stability issues at the lower voltages (although not too many boards use voltage scaling yet). So, would you prefer to keep this as a patch for BananaPi only, or change the dtsi for all A20 devices instead? In case we keep it as it is, what is the correct commit to point to as "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since that's where these voltages were defined. But then again, if we don't change the dtsi, should I point to my regulator patch instead? Thanks and regards, Timo -- You received this message because you are subscribed to the Google 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 v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Maxime, Maxime Ripard schrieb am 07.10.2015 19:49: > Hi Timo, > > On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote: >> Hi Kevin, >> Hi Maxime, >> >> Kevin Hilman schrieb am 07.10.2015 16:36: >> >> > "Timo Sigurdsson" <public_tim...@silentcreek.de> writes: >> >> I still think that the lower voltages may be the cause of your problem >> >> with that specific board, so could you please test the attached patch on >> >> top of my patch that you first experienced the problem with? Please let >> >> us know whether this solves your issue or whether we need to dig deeper. >> > >> > Thanks for the patch. Looks like it's the OPPs. >> > >> > I went back to next-20150923 and verified it still fails. Then, I >> > applied your patch and saw that it boots just fine. >> >> Good. Then we can easily fix this, I guess. >> >> @Maxime: How should we handle this? In its current form, the patch applies >> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi. >> In an earlier discussion, it was said that this can be done, even though it >> might not be the most elegant approach. But then again, I think it >> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20 >> boards since this is - to my knowledge - the first and only report that an >> A20 board has stability issues at the lower voltages (although not too many >> boards use voltage scaling yet). > > If you count only the number of boards, indeed, but if you count the > number of devices actually used in the field, we cover already a > significant portion of them. > >> So, would you prefer to keep this as a patch for BananaPi only, or >> change the dtsi for all A20 devices instead? > > Yeah, we probably can keep that for bananapi only at the moment, and > try to generalize that afterwards. Ok. > >> In case we keep it as it is, what is the correct commit to point to as >> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since >> that's where these voltages were defined. But then again, if we don't >> change the dtsi, should I point to my regulator patch instead? > > I don't think it fixes anything at this point. We droped your commit > that was using the A20 OPPs, so in the history so far we don't have > anything to fix, just enable cpufreq again. Ok. I'll send a third version of the regulator patch then with the updated opp included. Thanks, Timo -- You received this message because you are subscribed to the Google 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 v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Kevin,
Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others. I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi. Reverting that commit on top of next-20150923
> gets my bananapi booting again.
>
> Note it's kind of an interesting boot failure. The kernel boots fully
> to a shell, but panics after running a few commands. In particular
> 'dmesg -n1' seems to trigger it usually[2].
>
> Kevin
>
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
following up on my last email: I'm back from my vacation and I tried to
reproduce your problem, but my board doesn't seem to be affected, so I
cannot trigger it.
I still think that the lower voltages may be the cause of your problem
with that specific board, so could you please test the attached patch on
top of my patch that you first experienced the problem with? Please let
us know whether this solves your issue or whether we need to dig deeper.
Has anybody else been able to reproduce Kevin's issue?
Kind regards,
Timo
--
You received this message because you are subscribed to the Google 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.
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 74382f3..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -94,6 +94,16 @@
{
cpu-supply = <_dcdc2>;
+ operating-points = <
+ /* kHz uV */
+ 96 140
+ 912000 140
+ 864000 135
+ 72 125
+ 528000 115
+ 312000 110
+ 144000 105
+ >;
};
{
--
2.1.4
[linux-sunxi] Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Kevin, Kevin Hilman schrieb am 25. Sept 2015 01:57: > On Tue, Aug 18, 2015 at 8:36 AM, Maxime Ripard > <maxime.rip...@free-electrons.com> wrote: >> On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote: >>> sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 >>> PMU >>> driver, so add them to allow for voltage-scaling with cpufreq-dt. >>> >>> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de> >> >> Queued, thanks! >> Maxime > > kernelci.org started finding boot faiulres[1] on bananapi linux-next > around next-20150918, but it was only failing in some labs and not > others. I finally bisected it down to this patch, which landed in > linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators > for LeMaker BananaPi. Reverting that commit on top of next-20150923 > gets my bananapi booting again. > > Note it's kind of an interesting boot failure. The kernel boots fully > to a shell, but panics after running a few commands. In particular > 'dmesg -n1' seems to trigger it usually[2]. > > Kevin > > [1] > http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f > [2] > http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html > Thanks for your feedback. I'm traveling at the moment, so I can't do any testing but just guess wildly. I know, though, that I used dmesg frequently when I did my own testing before submitting the patch and could not see such behavior. Before this commit, the CPU of your BananaPi runs at 1.4 volts constantly. With this commit applied, the CPU voltage should vary between 1.0-1.4 volts depending on the frequency and defined operating points. Hence, one of my guesses would be that your CPU is not stable at the lower voltages. Could you modify the voltages for the defined frequencies in sun7i-a20.dtsi and test if that solves your issue? Say, raise the voltage by 0.1 volts for each operating point (but no higher than 1.4). I actually had a different patch that applied slightly higher voltages taken from the original fex for by LeMaker, but the feedback was, unless there are actual reports about boards not running stable at the current settings, we just keep them instead. So, I'm curious if you happen to have a board that requires slightly higher voltages to run stable. Regards, Timo -- You received this message because you are subscribed to the Google 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] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Maxime, Maxime Ripard schrieb am 03.08.2015 11:34: On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote: Julian Calaby schrieb am 03.08.2015 06:22: My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. Guys, isn't this whole discussion a bit moot? We're not doing any kind of power management but cpufreq, so maybe there's a lot more to do before we actually can have these kind of arguments? Plus this OPP has never been used anyway, so this patch is not going to increase the power consumption either. You are right. When I wrote that, I was under the impression that the Olinuxino Lime 2 board at least used this setting since it has has a cpu regulator defined to go as low as 0.7V. But now I checked again and see the regulator is not referenced in the cpu node, so I guess cpufreq doesn't use it. So, this discussion was really hypothetical and more importantly, as you mentioned, it's an out-of-spec opp that shouldn't be supported anyway. Thanks, Timo -- You received this message because you are subscribed to the Google 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 v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
Hi Maxime, Maxime Ripard schrieb am 03.08.2015 11:47: What regulator provides the 3.3V regulator used in the rest of this DT then (MMC, GMAC) ? For GMAC, there is a reg_gmac_3v3 defined in sun7i-a20-bananapi.dts [1]. MMC uses reg_vcc3v3 included from sunxi-common-regulators.dtsi. Am I missing something? Is this not sufficient? Thanks, Timo [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=v4.2-rc5#n78 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Maxime, Maxime Ripard schrieb am 03.08.2015 11:13: On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. This is not a property of a board, but is the actual limit documented by Allwinner for the A20. Some individual SoCs might have wider tolerances, but that's not a property of a board, it's really a property of a single SoC, and we cannot make any assumption on the board. Thanks for the clarification. That was a misunderstanding on my side. I can update the commit message in a second version of the patch, but the actual code change can be kept as is then, I guess. (and please make sure to run checkpatch before sending your patches) Sorry about that. Will do when I post a second version of the patch. Thanks, Timo -- You received this message because you are subscribed to the Google 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] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications
sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise the voltage for the lowest operating point to 1.0 volts in order to stay within the SoC specifications. It is an undervolted setting that isn't stable across all SoCs and boards out there. Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de --- Changes since v1: - Fixed checkpatch warnings - Changed the commit message and title to clarify that this is not a board-specific issue, but rather a limitation by the SoC --- arch/arm/boot/dts/sun7i-a20.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index 6a63f30..f5f384c 100644 --- a/arch/arm/boot/dts/sun7i-a20.dtsi +++ b/arch/arm/boot/dts/sun7i-a20.dtsi @@ -107,7 +107,7 @@ 72 120 528000 110 312000 100 - 144000 90 + 144000 100 ; #cooling-cells = 2; cooling-min-level = 0; -- 2.1.4 -- You received this message because you are subscribed to the Google 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] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi again, Julian Calaby schrieb am 03.08.2015 06:22: My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. However, Stefan Monnier (added to CC) mentioned in an earlier discussion that the savings for the lowest opp are rather small and thus the benefit of the 144MHz opp would be questionable. Unfortunately, I don't have measurement equipment precise enough to test this myself and haven't found a way to read power consumption internally via the PMU in mainline yet. Thanks, Timo -- You received this message because you are subscribed to the Google 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] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Julian, Julian Calaby schrieb am 03.08.2015 01:35: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Surely it wouldn't be added here if some could supply 0.9v. Maybe. I just know some boards don't (e.g. Cubieboard 2, Cubietruck, BananaPi) and don't know of any that does. But that's not my point. I think that a common minimum operating point, defined on the SOC level, should be defined in a way that works on all boards. Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? I never tried and I probably won't have time to test that before the weekend. The current behaviour is this, though: On boards that set their minimum CPU voltage to 1.0V, the lowest operating point will simply not be available to the user. (Alternatively, would it make sense to modify the code that uses this to use frequencies with voltages specified that are lower than can be supplied with the lowest voltage it can?) Considering OPPv2 is in the works, maybe not? Thanks, Timo -- You received this message because you are subscribed to the Google 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] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt.
Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de
---
Changes since v1 (RFC):
- Dropped the changes to the cpufreq operating points and renamed the patch
accordingly
- Limited the CPU voltage range so it doesn't exceed the SOC specifications
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 35
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..74382f3 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,10 @@
status = okay;
};
+cpu0 {
+ cpu-supply = reg_dcdc2;
+};
+
ehci0 {
status = okay;
};
@@ -119,13 +123,9 @@
status = okay;
axp209: pmic@34 {
- compatible = x-powers,axp209;
reg = 0x34;
interrupt-parent = nmi_intc;
interrupts = 0 IRQ_TYPE_LEVEL_LOW;
-
- interrupt-controller;
- #interrupt-cells = 1;
};
};
@@ -182,6 +182,33 @@
};
};
+#include axp209.dtsi
+
+reg_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ regulator-name = vdd-cpu;
+};
+
+reg_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ regulator-name = vdd-int-dll;
+};
+
+reg_ldo1 {
+ regulator-name = vdd-rtc;
+};
+
+reg_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-name = avcc;
+};
+
reg_usb1_vbus {
status = okay;
};
--
2.1.4
--
You received this message because you are subscribed to the Google 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: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de --- arch/arm/boot/dts/sun7i-a20.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi index 6a63f30..f5f384c 100644 --- a/arch/arm/boot/dts/sun7i-a20.dtsi +++ b/arch/arm/boot/dts/sun7i-a20.dtsi @@ -107,7 +107,7 @@ 72 120 528000 110 312000 100 - 144000 90 + 144000 100 ; #cooling-cells = 2; cooling-min-level = 0; -- 2.1.4 -- You received this message because you are subscribed to the Google 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi Stefan, you didn't include me in your answer, hence the late reply... Stefan Monnier schrieb am 29.07.2015 02:02: IMHO for a common maximum opp that's a good approach. But for the lowest frequency setting, it would seem more logical to me, to raise the voltage to a point where all boards will run fine with them, unless those boards cannot handle the frequency regardless of the higher voltage. I generally agre, tho IIRC some measurements seem to indicate that the lowest frequency settings did not bring much (if any) reduction in power consumption, making them rather useless. That's an interesting point. However, that would be a different discussion. I wouldn't mind if the 144MHz would be removed - my point was just that if it's supposed to be a common setting, it should work on all boards. I posted a patch today to fix this. [1] That might be a good place to discuss whether this setting should be removed entirely. Regards, Timo [1] https://groups.google.com/forum/#!topic/linux-sunxi/fIfbdn7mrQA -- You received this message because you are subscribed to the Google 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Hans de Goede schrieb am 27.07.2015 14:43: I've a simular patch here: https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1 I did not submit this upstream yet as it is part of a series to enable the otg controller on the bananapi which needs axp-usb-power-supply support for which the actual powersupply driver changes are still pending. Oops, I see. Are you planning to submit this for 4.3 or later? I plan to submit this for 4.3. Ok, then I guess we can drop my patch. IMHO we should just stick with the standard operating points unless we know that there are stability issues with them (such as e.g. on the A10 OlinuxIno Lime). I'd be fine with that as I don't have any stability issues with the lower voltages. What about the 1008MHz operating point that I reintroduced? It was dropped here [1] because there was no regulator support. That is in essence an overclocked setting, the max CPU voltage officially is 1.4V, I do not think that we should provide any overclocked settings in the official dts files. If people really want to overclock they will have to modify there dts themselves IMHO. Personally, I would be fine with that. Even though I think, it might be good to have them in the official files just for convenience and because people who are used to the sunxi-3.4 kernels are used to having the 1008MHz opp (and it was in mainline for a short while, too). For those who don't want to use that setting, it's easier to limit the maximum in userspace compared to compiling a new device tree blob. But I do understand your point, so I guess it's just something that maintainers have to make a decision for. As I said, either way is fine for me. Can this be reenabled on board level (which means overriding the defaults inherited from sun7i-a20.dtsi) or should this be done at SOC level for all boards (which means we have to add regulator nodes for all boards in the first place)? Technically this is possible, but I do not think that it is a good idea. I guess the same applies here, too. It's something maintainers should have a common understanding on. I don't know how much variation there is among the A20 boards in terms of frequencies and voltages. If there is a lot, I'd say it would be desireable to have board-specific opp. The downside I see in my approach is that it impacts readability of the dts(i) files when settings are overridden further down the tree. Thanks and regards, Timo -- You received this message because you are subscribed to the Google 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Chen-Yu Tsai schrieb am 27.07.2015 15:14: ChenYu (in the CC), since you did most of the original work here, do you know why we have an op at 0.9 volt, but none of our boards allow the voltage to go that low in the regulator settings ? I'm on vacation now, so apologies for the bad formatting. The OPPs are from a common subset of the settings from the fex files available at the time. Some fex files actually set min and max voltage thus eliminating the highest and lowest OPPs. At least that is how Maxime and I interpreted them. IMHO for a common maximum opp that's a good approach. But for the lowest frequency setting, it would seem more logical to me, to raise the voltage to a point where all boards will run fine with them, unless those boards cannot handle the frequency regardless of the higher voltage. Regards, Timo -- You received this message because you are subscribed to the Google 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:49: I don't feel like holding patches that were posted before you did because you did them some time ago and never submitted them is reasonnable and / or encouraging for new submitters of patches. I'd really like to get more sunxi-people contributing, and that starts with that kind of trivial stuff. Holding them back because one of the usual (and experienced) developpers is a bit counter-productive (and I'm sure you still have a lot of patches to submit anyway ;)). Just for the record: I wouldn't be discouraged by that. The only thing that matters to me here is that regulator support will be added, regardless of who submitted the patch. But anyway, I will rework the patch along the statements made during this discussion. Regards, Timo -- You received this message because you are subscribed to the Google 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:55: IMHO for a common maximum opp that's a good approach. But for the lowest frequency setting, it would seem more logical to me, to raise the voltage to a point where all boards will run fine with them, unless those boards cannot handle the frequency regardless of the higher voltage. Agreed. Ok, then I will write another patch for this as well, unless Chen-Yu or someone else objects. Regards, Timo -- You received this message because you are subscribed to the Google 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. With the
regulators enabled, we can define board-specific operating points. The defined
CPU voltages are more conservative (based on the values used by the vendor),
so they should be more failsafe across all boards of this kind out there.
I'm posting this as RFC as I would like to make a few more remarks and raise
questions along the way (plus, I'm anything but an experienced developer, so a
a critical review might help).
I checked the regulator definitions against the schematics released by LeMaker.
I also compared that to the DT and schematics of Cubiboard 2 and Cubietruck. Of
course, I also tested the patch on the actual hardware and it works fine for me.
The CPU voltages are slightly higher than those set in sun7i-a20.dtsi and even
though they work well for me, I thought it might be safer to use the more
conservative values used by LeMaker in their old fex file. Would you agree?
Besides, it it ok to have this in one patch or should it be splitted in two
(one for the regulators and one for the opp)? Did I miss something important?
Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 47 +---
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..2bcbb0e 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,22 @@
status = okay;
};
+cpu0 {
+ cpu-supply = reg_dcdc2;
+ operating-points =
+ /* kHzuV */
+ 1008000 145
+ 96 1425000
+ 912000 1425000
+ 864000 135
+ 72 125
+ 528000 115
+ 312000 110
+ 144000 105
+ ;
+ cooling-max-level = 7;
+};
+
ehci0 {
status = okay;
};
@@ -119,13 +135,9 @@
status = okay;
axp209: pmic@34 {
- compatible = x-powers,axp209;
reg = 0x34;
interrupt-parent = nmi_intc;
interrupts = 0 IRQ_TYPE_LEVEL_LOW;
-
- interrupt-controller;
- #interrupt-cells = 1;
};
};
@@ -182,6 +194,33 @@
};
};
+#include axp209.dtsi
+
+reg_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = 105;
+ regulator-max-microvolt = 145;
+ regulator-name = vdd-cpu;
+};
+
+reg_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ regulator-name = vdd-int-dll;
+};
+
+reg_ldo1 {
+ regulator-name = vdd-rtc;
+};
+
+reg_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-name = avcc;
+};
+
reg_usb1_vbus {
status = okay;
};
--
2.1.4
--
You received this message because you are subscribed to the Google 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.
