Re: [linux-sunxi] [PATCH 0/2] sunxi-tools: stuff to possibly go into 0.3
On Thu, 19 Nov 2015 18:11:33 +0100 Bernhard Nortmann wrote: > Am 19.11.2015 um 16:43 schrieb Peter Korsgaard: > > Both look good to me, thanks. > > > > Acked-by: Peter Korsgaard > > > > Thanks! Applied to linux-sunxi/sunxi-tools > > And in turn that also means: No objections from me against tagging a 0.3 > release. Thanks, tagged: https://github.com/linux-sunxi/sunxi-tools/releases/tag/v1.3 But I'm not a big fan of last minute changes. Sometimes they lead to "brown paper bag" releases :-) I have done some quick tests and hopefully everything is fine. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google 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 v3 3/3] ARM: dts: sun4i: gemei-g9: Enable sun4i audio codec support
On Fri, Nov 20, 2015 at 12:09 AM, Maxime Ripard
wrote:
> Hi,
>
> On Thu, Nov 12, 2015 at 08:53:19PM +0200, Priit Laes wrote:
>> On Mon, 2015-11-09 at 11:59 +0800, Chen-Yu Tsai wrote:
>> > On Sat, Nov 7, 2015 at 1:54 AM, Priit Laes wrote:
>> > > Gemei G9 has internal speakers and headphone jack. Audio switching
>> > > from internal speakers to headphones is automatically handled by
>> > > extra FT2012Q audio amplifier chip that works out of the box.
>> >
>> > Nice that it works out of the box. The FEX file does mention:
>> >
>> > audio_pa_ctrl = port:PH15<1><0>
>>
>> Nice catch.
>>
>> Setting it low mutes audio, and setting it back high unmutes.
>
> Then you just volunteered yourself to fix the FIXME in the driver ;)
>
Hans seems to have a patch for this in his sunxi-wip branch.
I haven't looked at it though.
ChenYu
>> > So either it is floating or pulled up by default? Since it works
>> > now I don't see any reason to block it. On the other hand once
>> > that binding is introduced it would be nice to add it for power
>> > management reasons.
>>
>> Should I just add comment about it or do something like this:
>>
>> &codec {
>> status = "okay";
>> /*
>>* TODO: Add codec_ext_pwr_pin to turn off external audio AMP
>>&pio {
>> codec_ext_pwr_pin: codec_ext_pwr_pin@0 {
>>allwinner,pins = "PH15";
>>allwinner,function = "gpio_out";
>>allwinner,drive = ;
>>allwinner,pull = ;
>> }
>>}
>>*/
>> }
>
> More like
>
> &pio {
> codec_ext_pwr_pin: codec_ext_pwr_pin@0 {
> allwinner,pins = "PH15";
> allwinner,function = "gpio_out";
> allwinner,drive = ;
> allwinner,pull = ;
> };
> };
>
> &codec {
> /* This pin is used to turn off the GPIO amp pin */
> pinctrl-names = "default";
> pinctrl-0 <&codec_ext_pwr_pin>;
> status = "okay";
> };
>
> Of course, that's a temporary measure, and you should actually use
> that GPIO to enable / disable the Amplifier when you are playing
> sound. It shouldn't be that hard with ASoC.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig
On Fri, Nov 20, 2015 at 9:46 AM, 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
> 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
Acked-by: Chen-Yu Tsai
--
You received this message because you are subscribed to the Google 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
> ---
> 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] Re: [PATCH v2 2/3] ARM: sunxi: Really enable LRADC keys in sunxi_defconfig
On Fri, Nov 20, 2015 at 9:46 AM, Timo Sigurdsson
wrote:
> 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
Acked-by: Chen-Yu Tsai
--
You received this message because you are subscribed to the Google 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/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 --- 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
---
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] [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
---
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] 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
> > >
> > > 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] Re: [PATCH v2] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig
On 20.11.2015 06:33, 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 symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
> in multi_v7_defconfig.
>
> Signed-off-by: Timo Sigurdsson
> ---
> 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(-)
>
Fully satisfies my v1's comments:
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
You received this message because you are subscribed to the Google 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,
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
> >
> > 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.
Also why CONFIG_PM CONFIG_KEYBOARD_SUN4I_LRADC and CONFIG_HIGHPTE got
removed ?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
Re: [linux-sunxi] [PATCH] spi: dts: sun4i: Add support for inter-word wait cycles using the SPI Wait Clock Register
Hi Marcus, On Fri, Nov 20, 2015 at 2:53 AM, Marcus Weseloh wrote: > Adds support and documentation for a new slave device property > "sun4i,spi-wdelay" that allows to set the SPI Wait Clock Register per > device / transfer. The SPI hardware will wait the specified amount of > SPI clock periods (plus a constant 3 clock periods) before transmitting > the next word. Should you possibly hide the 3 clock periods from the user? I.e. they set whatever they want for the wdelay, we set it to the closest number we can that's greater or equal to what they ask for. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to the Google 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
>
> 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] [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
---
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 03/27] mtd: nand: update examples in the documentation to use mtd_to_nand()
On Mon, Nov 16, 2015 at 02:37:36PM +0100, Boris Brezillon wrote: > mtd_to_nand() has been introduced to hide accesses to mtd->priv. > All NAND controller drivers should use it instead of directly accessing > the ->priv field. > > Signed-off-by: Boris Brezillon Pushed to l2-mtd.git -- You received this message because you are subscribed to the Google 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 02/27] mtd: nand: add an mtd_to_nand() helper
On Mon, Nov 16, 2015 at 02:37:35PM +0100, Boris Brezillon wrote:
> Some drivers are retrieving the nand_chip pointer using the container_of
> macro on a struct wrapping both the nand_chip and the mtd_info struct while
> the standard way of retrieving this pointer is through mtd->priv.
> Provide an helper to do that.
>
> Signed-off-by: Boris Brezillon
> ---
> include/linux/mtd/nand.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 4f7c9b9..056d165 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -730,6 +730,11 @@ static inline struct device_node
> *nand_get_flash_node(struct nand_chip *chip)
> return chip->flash_node;
> }
>
> +static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
> +{
> + return mtd->priv;
> +}
> +
Pushed this patch to l2-mtd.git, though I rebased it directly onto
4.4-rc1 and then merged it in. That way, if any other subsystems want to
start using this in the 4.5 -next cycle (e.g., for patches 4-8), they
can pull it in without taking the rest of MTD.
I can push this to a separate branch or signed tag, if anyone wants.
Or, I can take the arch/ patches via MTD, if that's a better option.
Brian
--
You received this message because you are subscribed to the Google 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 01/27] mtd: nand: fix drivers abusing mtd->priv
On Mon, Nov 16, 2015 at 02:37:34PM +0100, Boris Brezillon wrote: > The ->priv field of the mtd_info object attached to a nand_chip device > should point to the nand_chip device. The pxa and cafe drivers are > assigning this field their own private structure, which works fine as long > as the nand_chip field is the first one in the driver private struct but > seems a bit fragile. > Fix that by setting mtd->priv to point the nand_chip field and assigning > chip->priv to the private structure head. > > Signed-off-by: Boris Brezillon Applied to l2-mtd.git -- You received this message because you are subscribed to the Google 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 0/2] sunxi-tools: stuff to possibly go into 0.3
Am 19.11.2015 um 16:43 schrieb Peter Korsgaard: Both look good to me, thanks. Acked-by: Peter Korsgaard Thanks! Applied to linux-sunxi/sunxi-tools And in turn that also means: No objections from me against tagging a 0.3 release. Regards, B. Nortmann -- You received this message because you are subscribed to the Google 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 v3 3/3] ARM: dts: sun4i: gemei-g9: Enable sun4i audio codec support
Hi,
On Thu, Nov 12, 2015 at 08:53:19PM +0200, Priit Laes wrote:
> On Mon, 2015-11-09 at 11:59 +0800, Chen-Yu Tsai wrote:
> > On Sat, Nov 7, 2015 at 1:54 AM, Priit Laes wrote:
> > > Gemei G9 has internal speakers and headphone jack. Audio switching
> > > from internal speakers to headphones is automatically handled by
> > > extra FT2012Q audio amplifier chip that works out of the box.
> >
> > Nice that it works out of the box. The FEX file does mention:
> >
> > audio_pa_ctrl = port:PH15<1><0>
>
> Nice catch.
>
> Setting it low mutes audio, and setting it back high unmutes.
Then you just volunteered yourself to fix the FIXME in the driver ;)
> > So either it is floating or pulled up by default? Since it works
> > now I don't see any reason to block it. On the other hand once
> > that binding is introduced it would be nice to add it for power
> > management reasons.
>
> Should I just add comment about it or do something like this:
>
> &codec {
> status = "okay";
> /*
> * TODO: Add codec_ext_pwr_pin to turn off external audio AMP
> &pio {
> codec_ext_pwr_pin: codec_ext_pwr_pin@0 {
> allwinner,pins = "PH15";
> allwinner,function = "gpio_out";
> allwinner,drive = ;
> allwinner,pull = ;
> }
> }
> */
> }
More like
&pio {
codec_ext_pwr_pin: codec_ext_pwr_pin@0 {
allwinner,pins = "PH15";
allwinner,function = "gpio_out";
allwinner,drive = ;
allwinner,pull = ;
};
};
&codec {
/* This pin is used to turn off the GPIO amp pin */
pinctrl-names = "default";
pinctrl-0 <&codec_ext_pwr_pin>;
status = "okay";
};
Of course, that's a temporary measure, and you should actually use
that GPIO to enable / disable the Amplifier when you are playing
sound. It shouldn't be that hard with ASoC.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
[linux-sunxi] [PATCH] spi: dts: sun4i: Add support for inter-word wait cycles using the SPI Wait Clock Register
Adds support and documentation for a new slave device property
"sun4i,spi-wdelay" that allows to set the SPI Wait Clock Register per
device / transfer. The SPI hardware will wait the specified amount of
SPI clock periods (plus a constant 3 clock periods) before transmitting
the next word.
The constant additional 3 clock periods are not documented by the vendor
and have been determined by analyzing the generated waveforms across
many different transmission speeds.
Signed-off-by: Marcus Weseloh
---
Documentation/devicetree/bindings/spi/spi-sun4i.txt | 11 +++
drivers/spi/spi-sun4i.c | 7 +++
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
index de827f5..9c4d723 100644
--- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
+++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
@@ -10,6 +10,10 @@ Required properties:
- "mod": the parent module clock
- clock-names: Must contain the clock names described just above
+Optional properties for slave devices:
+- sun4i,spi-wdelay : delay between transmission of words, specified in number
+ of SPI clock periods (actual delay is wdelay + 3 clock periods)
+
Example:
spi1: spi@01c06000 {
@@ -21,4 +25,11 @@ spi1: spi@01c06000 {
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
+
+ spi1_0 {
+ compatible = "example,dummy";
+ reg = <0>;
+ spi-max-frequency = <100>; /* 1Mhz = 1us clock period */
+ sun4i,spi-wdelay = <2>; /* delay 5us (2 + 3 clock periods) */
+ };
};
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index f60a6d6..a8e39f1 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
@@ -173,6 +174,7 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
+ u32 wdelay = 0;
/* We don't support transfer larger than the FIFO */
if (tfr->len > SUN4I_FIFO_DEPTH)
@@ -261,6 +263,11 @@ static int sun4i_spi_transfer_one(struct spi_master
*master,
sun4i_spi_write(sspi, SUN4I_CLK_CTL_REG, reg);
+ /* Set optional inter-word wait cycles */
+ of_property_read_u32(spi->dev.of_node, "sun4i,spi-wdelay",
+&wdelay);
+ sun4i_spi_write(sspi, SUN4I_WAIT_REG, (u16)wdelay);
+
/* Setup the transfer now... */
if (sspi->tx_buf)
tx_len = tfr->len;
--
1.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] spi: dts: sun4i: Add support for inter-word wait cycles
Hi all,
the Allwinner A10/A20 SPI module supports an option to configure a number of
clock periods to wait between each word ("SPI Wait Clock Register" in the A20
manual). This is a very useful option if talking to devices which specify a
minimum amount of inter-word wait time.
I initially tried to find a way to let SPI protocol drivers specify this
option, but I couldn't find a mechanism to pass additional options to the spi
master. So I took the spi-davinci driver as an example (it implements a very
similiar functionality) and added a new devicetree property.
While testing this patch I noticed that the SPI module always adds a constant
3 clock cycles to the number set in the Wait Clock Register. That number stays
constant across many different baud rates, so I documented it in the
devicetree binding file.
One thing I am unsure of is the device example in the binding
documentation. I used "example,dummy" as compatible... is this acceptable or
should I use a device/compatible that actually exists somewhere?
Oh... and should I split binding documentation and code changing patch?
Best regards,
Marcus
Marcus Weseloh (1):
spi: dts: sun4i: Add support for inter-word wait cycles using the SPI
Wait Clock Register
Documentation/devicetree/bindings/spi/spi-sun4i.txt | 11 +++
drivers/spi/spi-sun4i.c | 7 +++
2 files changed, 18 insertions(+)
--
1.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] Re: [PATCH 05/19] clk: sunxi: add DRAM gates
On Fri, Nov 13, 2015 at 04:08:53PM +0800, Chen-Yu Tsai wrote: > On Mon, Nov 9, 2015 at 12:18 PM, Chen-Yu Tsai wrote: > > On Fri, Oct 30, 2015 at 10:20 PM, Maxime Ripard > > wrote: > >> The Allwinner SoCs have a gate controller to gate the access to the DRAM > >> clock to the some devices that need to access the DRAM directly (mostly > >> display / image related IPs). > >> > >> Use a simple gates driver to support it. > >> > >> Signed-off-by: Maxime Ripard > > > > Acked-by: Chen-Yu Tsai > > > >> --- > >> drivers/clk/sunxi/clk-simple-gates.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/clk/sunxi/clk-simple-gates.c > >> b/drivers/clk/sunxi/clk-simple-gates.c > >> index 0214c6548afd..5666c767fa14 100644 > >> --- a/drivers/clk/sunxi/clk-simple-gates.c > >> +++ b/drivers/clk/sunxi/clk-simple-gates.c > >> @@ -112,6 +112,8 @@ CLK_OF_DECLARE(sun5i_a13_apb0, > >> "allwinner,sun5i-a13-apb0-gates-clk", > >>sunxi_simple_gates_init); > >> CLK_OF_DECLARE(sun5i_a13_apb1, "allwinner,sun5i-a13-apb1-gates-clk", > >>sunxi_simple_gates_init); > >> +CLK_OF_DECLARE(sun5i_a13_dram, "allwinner,sun5i-a13-dram-gates-clk", > >> + sunxi_simple_gates_init); > > Nit: Since the compatible added is sun5i, could you mention it in the > commit message, > to avoid confusion when we do this for the other families? It will be fixed in the v2. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/2] sunxi-tools: stuff to possibly go into 0.3
> "Bernhard" == Bernhard Nortmann writes: > Siarhei: Here are the proposed changes that I would like to go into > sunxi-tools, possibly before you tag a 0.3 release. It's not urgent > (could be postponed to a later point in time), but I think it would > be nice to include these into a "release point". > Regards, B. Nortmann > Bernhard Nortmann (2): > sunxi-tools: some trivial fixes > sunxi-tools: make use of proper boolean data types Both look good to me, thanks. Acked-by: Peter Korsgaard -- Bye, Peter Korsgaard -- You received this message because you are subscribed to the Google 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 01/19] clk: sunxi: Add display clock
On Thu, Nov 12, 2015 at 12:31:54PM -0800, Stephen Boyd wrote: > On 11/06, Maxime Ripard wrote: > > Hi Stephen, > > > > Thanks for your feedback! > > > > On Fri, Oct 30, 2015 at 02:29:02PM -0700, Stephen Boyd wrote: > > > > + > > > > + mux = kzalloc(sizeof(*mux), GFP_KERNEL); > > > > + if (!mux) > > > [..] > > > > + goto free_reset; > > > > + } > > > > + > > > > + return; > > > > + > > > > +free_reset: > > > > + kfree(reset_data); > > > > +free_clk: > > > > + clk_unregister(clk); > > > > > > We really ought to have a clk_composite_unregister() API. > > > > Can we? > > > > We can always unregister the clock itself, but do we have a way to > > retrieve the structure that has been allocated in there? > > > > (note that it also applies to the generic clocks registration: muxes, > > dividers, and so on). > > Yes we have a way. We've done the same sort of design for other > generic clocks. Do the __clk_get_hw() thing like in clk-divider.c Ack. I'll cook up a patch for this then. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 04/19] clk: sunxi: Add TCON channel1 clock
On Mon, Nov 09, 2015 at 11:36:15AM +0800, Chen-Yu Tsai wrote: > >> > + sclk1_parents[0] = sclk2_name; > >> > + sclk1_parents[1] = sclk2d2_name; > >> > >> Is there any need to expose these 2 clocks via DT using > >> of_clk_add_provider? > > > > No, as far as I'm aware, there's no user external to this clock > > driver. > > > >> Note that these complex clock trees within a clock node breaks the > >> assigned-clock-parents mechanism, as you can no longer specify the output > >> clock's direct parents. > > > > There's no point of changing the parent either. Hardware blocks are > > always connected to the leaf clock (sclk1). We could also model it as > > an extra 1-bit divider, which would simplify a bit the logic though. > > Probably not. You still have a gate to handle. It's just moving the > divider from 1 clock to the other. I think the current approach of > modeling it like the hardware is better. Not really if you model it using sclk2 being a mux + gate, and sclk1 being a divider + gate. It works great using the composite clocks. > About reparenting, what I meant was if sclk2 is not exposed through > of_clk_add_provider, then we can't do assigned-clocks stuff on it, > like setting a default parent or making each channel use a different > source pll. And we don't really want to. Using the divider allow us to simply set the rate of sclk1, and the mux / divider will do the rest. Since only sclk1 is exposed to the rest of the system, we do not really care about the rate of sclk2 anyway. > What I'm saying is if it is not expected to work with another core > binding, we should probably note it somewhere. Indeed. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] [PATCH 1/2] sunxi-tools: some trivial fixes
- get rid of double includes
- fix U-Boot source reference
- get rid of "uboot_autostart" variable
Signed-off-by: Bernhard Nortmann
---
fel.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/fel.c b/fel.c
index e9f6450..4561d02 100644
--- a/fel.c
+++ b/fel.c
@@ -28,8 +28,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -988,8 +986,8 @@ int have_sunxi_spl(libusb_device_handle *usb, uint32_t
spl_addr)
/*
* Pass information to U-Boot via specialized fields in the SPL header
- * (see "boot_file_head" in ${U-BOOT}/tools/mksunxiboot.c), providing
- * information about the boot script address (DRAM location of boot.scr).
+ * (see "boot_file_head" in ${U-BOOT}/arch/arm/include/asm/arch-sunxi/spl.h),
+ * providing the boot script address (DRAM location of boot.scr).
*/
void pass_fel_information(libusb_device_handle *usb, uint32_t script_address)
{
@@ -1054,7 +1052,6 @@ static double gettime(void)
int main(int argc, char **argv)
{
- int uboot_autostart = 0; /* flag for "uboot" command = U-Boot autostart
*/
int rc;
libusb_device_handle *handle = NULL;
int iface_detached = -1;
@@ -1175,8 +1172,7 @@ int main(int argc, char **argv)
skip=2;
} else if (strcmp(argv[1], "uboot") == 0 && argc > 2) {
aw_fel_process_spl_and_uboot(handle, argv[2]);
- uboot_autostart = (uboot_entry > 0 && uboot_size > 0);
- if (!uboot_autostart)
+ if (!uboot_entry)
printf("Warning: \"uboot\" command failed to
detect image! Can't execute U-Boot.\n");
skip=2;
} else {
@@ -1188,7 +1184,7 @@ int main(int argc, char **argv)
}
// auto-start U-Boot if requested (by the "uboot" command)
- if (uboot_autostart) {
+ if (uboot_entry > 0 && uboot_size > 0) {
pr_info("Starting U-Boot (0x%08X).\n", uboot_entry);
aw_fel_execute(handle, uboot_entry);
}
--
2.4.6
--
You received this message because you are subscribed to the Google 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 0/2] sunxi-tools: stuff to possibly go into 0.3
Siarhei: Here are the proposed changes that I would like to go into sunxi-tools, possibly before you tag a 0.3 release. It's not urgent (could be postponed to a later point in time), but I think it would be nice to include these into a "release point". Regards, B. Nortmann Bernhard Nortmann (2): sunxi-tools: some trivial fixes sunxi-tools: make use of proper boolean data types fel.c | 27 --- 1 file changed, 12 insertions(+), 15 deletions(-) -- 2.4.6 -- You received this message because you are subscribed to the Google 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/2] sunxi-tools: make use of proper boolean data types
Signed-off-by: Bernhard Nortmann
---
fel.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/fel.c b/fel.c
index 4561d02..348f01c 100644
--- a/fel.c
+++ b/fel.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
@@ -61,7 +62,7 @@ static const int AW_USB_WRITE = 0x12;
static int AW_USB_FEL_BULK_EP_OUT;
static int AW_USB_FEL_BULK_EP_IN;
static int timeout = 6;
-static int verbose = 0; /* Makes the 'fel' tool more talkative if non-zero */
+static bool verbose = false; /* If set, makes the 'fel' tool more talkative */
static uint32_t uboot_entry = 0; /* entry point (address) of U-Boot */
static uint32_t uboot_size = 0; /* size of U-Boot binary */
@@ -957,7 +958,7 @@ void aw_fel_process_spl_and_uboot(libusb_device_handle *usb,
#define SPL_SIGNATURE "SPL" /* marks "sunxi" header */
#define SPL_MIN_VERSION1 /* minimum required version */
#define SPL_MAX_VERSION1 /* maximum supported version
*/
-int have_sunxi_spl(libusb_device_handle *usb, uint32_t spl_addr)
+bool have_sunxi_spl(libusb_device_handle *usb, uint32_t spl_addr)
{
uint8_t spl_signature[4];
@@ -965,23 +966,23 @@ int have_sunxi_spl(libusb_device_handle *usb, uint32_t
spl_addr)
&spl_signature, sizeof(spl_signature));
if (memcmp(spl_signature, SPL_SIGNATURE, 3) != 0)
- return 0; /* signature mismatch, no "sunxi" SPL */
+ return false; /* signature mismatch, no "sunxi" SPL */
if (spl_signature[3] < SPL_MIN_VERSION) {
fprintf(stderr, "sunxi SPL version mismatch: "
"found 0x%02X < required minimum 0x%02X\n",
spl_signature[3], SPL_MIN_VERSION);
fprintf(stderr, "You need to update your U-Boot (mksunxiboot)
to a more recent version.\n");
- return 0;
+ return false;
}
if (spl_signature[3] > SPL_MAX_VERSION) {
fprintf(stderr, "sunxi SPL version mismatch: "
"found 0x%02X > maximum supported 0x%02X\n",
spl_signature[3], SPL_MAX_VERSION);
fprintf(stderr, "You need a more recent version of this
(sunxi-tools) fel utility.\n");
- return 0;
+ return false;
}
- return 1; /* sunxi SPL and suitable version */
+ return true; /* sunxi SPL and suitable version */
}
/*
@@ -1113,7 +1114,7 @@ int main(int argc, char **argv)
if (argc > 1 && (strcmp(argv[1], "--verbose") == 0 ||
strcmp(argv[1], "-v") == 0)) {
- verbose = 1;
+ verbose = true;
argc -= 1;
argv += 1;
}
--
2.4.6
--
You received this message because you are subscribed to the Google 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] thermal: Add support for Sunxi THS on the Allwinner H3
On Wed, Nov 18, 2015 at 09:51:48PM +0100, Josef Gajdusek wrote:
> This patch adds support for the Sunxi thermal sensor on the Allwinner H3.
> Also adds declaration of the H3 THS clock to clk-sunxi.c ignoring the
> dividers as they are not continuous (clk-divider.c cannot be used as it
> does not support setting an enable bit).
> Should be easily extendable for the A33/A83T/... as they have similar but
> not completely identical sensors.
>
> Signed-off-by: Josef Gajdusek
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> .../devicetree/bindings/thermal/sunxi-ths.txt | 24 ++
> arch/arm/boot/dts/sun8i-h3.dtsi| 27 +++
For the binding:
Acked-by: Rob Herring
> drivers/clk/sunxi/clk-sunxi.c | 16 ++
> drivers/thermal/Kconfig| 7 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/sunxi_ths.c| 263
> +
> 7 files changed, 339 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> create mode 100644 drivers/thermal/sunxi_ths.c
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 23e7bce..6d63b35 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -73,6 +73,7 @@ Required properties:
> "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
> "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
> "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
> + "allwinner,sun8i-h3-ths-clk" - for THS on H3
>
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> diff --git a/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> new file mode 100644
> index 000..75c9211
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> @@ -0,0 +1,24 @@
> +* sunxi THS
> +
> +Required properties:
> +- compatible : "allwinner,sun8i-h3-ths"
> +- reg : Address range of the thermal registers and location of the
> calibration
> +value
> +- resets : Must contain an entry for each entry in reset-names.
> + see ../reset/reset.txt for details
> +- reset-names : Must include the name "ahb"
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
> + clock
> +
> +Example:
> +ths: ths@01c25000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
> + interrupts = ;
> + resets = <&bus_rst 136>;
> + reset-names = "ahb";
> + clocks = <&bus_gates 72>, <&ths_clk>;
> + clock-names = "ahb", "ths";
> +};
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 0faa38a..b82881d 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -77,6 +77,14 @@
> };
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = <&ths 0>;
> + };
> + };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupts = IRQ_TYPE_LEVEL_LOW)>,
> @@ -236,6 +244,14 @@
> "ahb1_ephy", "ahb1_dbg";
> };
>
> + ths_clk: clk@01c20074 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ths-clk";
> + reg = <0x01c20074 0x4>;
> + clocks = <&osc24M>;
> + clock-output-names = "ths";
> + };
> +
> mmc0_clk: clk@01c20088 {
> #clock-cells = <1>;
> compatible = "allwinner,sun4i-a10-mmc-clk";
> @@ -522,6 +538,17 @@
> interrupts = ;
> };
>
> + ths: ths@01c25000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
> + interrupts = ;
> + resets = <&bus_rst 104>;
> + reset-names = "ahb";
> + clocks = <&bus_gates 72>, <&ths_clk>;
> + clock-names = "ahb", "ths";
> + };
> +
> uart0: serial@01c28000 {
> compatible = "snps,dw-apb-uart";
> reg = <0x01c28000 0x400>;
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 6293c65..637
[linux-sunxi] Re: [PATCH v3 0/9] sunxi-tools: support progress display for FEL utility
Hi Siarhei!
Am 19.11.2015 um 09:04 schrieb Siarhei Siamashka:
[...]
My biggest concern is the command line interface. It is basically
stateless vs. stateful approach. You are in favour of allowing
switches, which modify the state anywhere in the command line and
then have regular commands changing behaviour, based on this state.
I'm in favour of just adding more commands. It is easier to document
these extended commands than all kind of permutations of active
switches used together with commands. The current '-v' ('--verbose')
switch is somewhat special because it is intended for debugging and
does not need to be documented. It allows arbitrary human readable
debugging messages coming to stderr, but we don't enforce any
particular format of these message. The progressbar related switches
are different and we need to document them. The "multiwrite" command
does not offer any advantages over the "write" command unless it is
used with an active progressbar. This all is somewhat similar to an
old discussion about introducing a new "uboot" command versus adding
a new switch to use it as a modifier for the existing "spl" command
(in the form of "--exec spl").
If I understand you correctly, you'd do away with the "-p" and "-g[g]"
switches and instead use dedicated "[multi]progress" and "[multi][x]gauge"
commands, behaving like what would now be achieved with one of the
progress options combined with "write" or "multi[write]"?
It's easy enough to switch over to that, and stick with the special
treatment of the leading "-v" option (for extra/debugging output).
@Alex, what do you think of this?
We don't care about the performance of the "fill" and "clear"
commands and don't really need a progressbar for them. The point is
that these commands can be implemented as uploading and executing a
memset function directly on the device. After doing this, the "fill"
and "clear" commands will be faster than 1 GB/s. I can implement a
patch for this.
This is why they currently enforce `false` on aw_write_buffer().
Regarding the code itself. Does it really make sense to have all
these arguments for the callback function? Only the size of the new
data chunk is necessary. And the rest can be deducted from the
current progressbar state. For example, the sequence of calls
would then look like ('progress_expect' could be renamed to
'progress_start' for better clarity):
progress_expect(total_size)
progress_update(chunk_size)
progress_update(chunk_size)
progress_update(chunk_size)
progress_update(last_chunk_size)
All the other information can be calculated inside of the progressbar
code. In the progress_expect() function you can save the timestamp,
clear the transferred bytes counter and save the total_size. Then in
the progress_update() function you can update the transferred bytes
counter and do other calculations. Or am I missing something? The
current implementation seems to be overly complicated and even
probably a bit buggy. The "multiwrite" command currently inserts
line breaks on stdout between different files, which does not look
good to me.
I agree that it should be possible to set the total size (only) once. Due
to the way the numbers passed to the callback function are modified, I'd
still want a way to tell if there's a "multi"-transfer pending - but that
could be done nicely using something like:
void progress_start(size_t total_bytes, bool multi);
Getting rid of the "quick" might be a bit tricky. Currently it's there to
allow suppressing those small (and therefore very fast) transfers that
users mostly won't be interested in when using the "classic" 'write'
command (boot script, DTB). If we discard that feature (i.e. simply show
progress updates for each and every transfer) or work around that some way,
it gets obsolete too.
Do we really want to have the SoC dependent chunk size? Normally we
should expect the transfer speed to be somewhere between 500 KB/s and
1000 KB/s (the speeds below 500 KB/s can be improved and we are
working on it). But even if we set the chunk size to only 128K, does
it really have any negative impact on anything?
For those SoCs that could "do better" with larger chunk size, it does have
a small (but negligible) impact on performance / peek transfer rate, due
to frequent progress updates. I'd be fine with a larger default, too - like
the 512 KiB I selected initially; just wanted to "play it safe" for those
oddball devices somehow ending up with sluggish transfers. If we agree that
these might be lacking a bit in terms of (progress) update frequency, then
I'm happy to get rid of a SoC-based chunk selection.
About the boolean flag. You could probably just use the progress
callback function pointer instead of it and lose nothing.
And finally, the new progressbar feature fully replaces the old
transfer speed calculation/printing that was done under the '-v'
switch. So its removal can be probably done as a part of your
patch set.
That probably makes sen
Re: [linux-sunxi] [PATCH] thermal: Add support for Sunxi THS on the Allwinner H3
On Wed, Nov 18, 2015 at 09:51:48PM +0100, Josef Gajdusek wrote:
> This patch adds support for the Sunxi thermal sensor on the Allwinner H3.
> Also adds declaration of the H3 THS clock to clk-sunxi.c ignoring the
> dividers as they are not continuous (clk-divider.c cannot be used as it
> does not support setting an enable bit).
> Should be easily extendable for the A33/A83T/... as they have similar but
> not completely identical sensors.
>
> Signed-off-by: Josef Gajdusek
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> .../devicetree/bindings/thermal/sunxi-ths.txt | 24 ++
> arch/arm/boot/dts/sun8i-h3.dtsi| 27 +++
> drivers/clk/sunxi/clk-sunxi.c | 16 ++
> drivers/thermal/Kconfig| 7 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/sunxi_ths.c| 263
> +
> 7 files changed, 339 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> create mode 100644 drivers/thermal/sunxi_ths.c
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 23e7bce..6d63b35 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -73,6 +73,7 @@ Required properties:
> "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
> "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
> "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
> + "allwinner,sun8i-h3-ths-clk" - for THS on H3
>
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> diff --git a/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> new file mode 100644
> index 000..75c9211
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> @@ -0,0 +1,24 @@
> +* sunxi THS
> +
> +Required properties:
> +- compatible : "allwinner,sun8i-h3-ths"
> +- reg : Address range of the thermal registers and location of the
> calibration
> +value
> +- resets : Must contain an entry for each entry in reset-names.
> + see ../reset/reset.txt for details
> +- reset-names : Must include the name "ahb"
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
> + clock
> +
> +Example:
> +ths: ths@01c25000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
> + interrupts = ;
> + resets = <&bus_rst 136>;
> + reset-names = "ahb";
> + clocks = <&bus_gates 72>, <&ths_clk>;
> + clock-names = "ahb", "ths";
> +};
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 0faa38a..b82881d 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -77,6 +77,14 @@
> };
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>;
> + polling-delay = <5000>;
> + thermal-sensors = <&ths 0>;
> + };
> + };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupts = IRQ_TYPE_LEVEL_LOW)>,
> @@ -236,6 +244,14 @@
> "ahb1_ephy", "ahb1_dbg";
> };
>
> + ths_clk: clk@01c20074 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ths-clk";
> + reg = <0x01c20074 0x4>;
> + clocks = <&osc24M>;
> + clock-output-names = "ths";
> + };
> +
> mmc0_clk: clk@01c20088 {
> #clock-cells = <1>;
> compatible = "allwinner,sun4i-a10-mmc-clk";
> @@ -522,6 +538,17 @@
> interrupts = ;
> };
>
> + ths: ths@01c25000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "allwinner,sun8i-h3-ths";
> + reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
> + interrupts = ;
> + resets = <&bus_rst 104>;
> + reset-names = "ahb";
> + clocks = <&bus_gates 72>, <&ths_clk>;
> + clock-names = "ahb", "ths";
> + };
> +
> uart0: serial@01c28000 {
> compatible = "snps,dw-apb-uart";
> reg = <0x01c28000 0x400>;
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 6293c65..637401a 100644
> --- a/drivers/clk/sunxi/clk-s
[linux-sunxi] Re: [PATCH v3 0/9] sunxi-tools: support progress display for FEL utility
On Fri, 13 Nov 2015 21:58:38 +0100
Bernhard Nortmann wrote:
> This series of patches picks up on the discussion at
> https://groups.google.com/forum/#!topic/linux-sunxi/lz0oQBwjex0
> It's based on first patches submitted there, but has been extensively
> reworked to provide a flexible "progress framework" for USB uploads via
> the sunxi-fel utility.
>
> The large number of patches is partly due to the fact that I've tried to
> introduce several features in discrete steps, with a logical separation
> between them. Patch 4/9 already provides a simple, "proof of concept"
> progress bar display based on what was proposed initially.
>
> Other patches extend on that, while demonstrating that the framework
> allows progress routines and sunxi-fel 'core' to be updated mostly
> independent of each other.
Hi,
My opinion (as a user) is that the progress bar with the transfer speed
and ETA looks great. Thanks for implementing it.
> @Siarhei:
> I'd like your comment on 2/9 "refactor aw_fel_write()", if that addresses
> the concerns you've expressed regarding that function.
Yes, the 2/9 patch is fine.
Overall, I like the move of the progressbar handling to a separate
source file. It's nice to have this stuff isolated from the rest of
the code and used via a clearly documented API. The global state of
the progressbar is also probably ok. Because we have only one stdout
and we are unlikely to have multiple progressbars simultaneously.
My biggest concern is the command line interface. It is basically
stateless vs. stateful approach. You are in favour of allowing
switches, which modify the state anywhere in the command line and
then have regular commands changing behaviour, based on this state.
I'm in favour of just adding more commands. It is easier to document
these extended commands than all kind of permutations of active
switches used together with commands. The current '-v' ('--verbose')
switch is somewhat special because it is intended for debugging and
does not need to be documented. It allows arbitrary human readable
debugging messages coming to stderr, but we don't enforce any
particular format of these message. The progressbar related switches
are different and we need to document them. The "multiwrite" command
does not offer any advantages over the "write" command unless it is
used with an active progressbar. This all is somewhat similar to an
old discussion about introducing a new "uboot" command versus adding
a new switch to use it as a modifier for the existing "spl" command
(in the form of "--exec spl").
We don't care about the performance of the "fill" and "clear"
commands and don't really need a progressbar for them. The point is
that these commands can be implemented as uploading and executing a
memset function directly on the device. After doing this, the "fill"
and "clear" commands will be faster than 1 GB/s. I can implement a
patch for this.
Regarding the code itself. Does it really make sense to have all
these arguments for the callback function? Only the size of the new
data chunk is necessary. And the rest can be deducted from the
current progressbar state. For example, the sequence of calls
would then look like ('progress_expect' could be renamed to
'progress_start' for better clarity):
progress_expect(total_size)
progress_update(chunk_size)
progress_update(chunk_size)
progress_update(chunk_size)
progress_update(last_chunk_size)
All the other information can be calculated inside of the progressbar
code. In the progress_expect() function you can save the timestamp,
clear the transferred bytes counter and save the total_size. Then in
the progress_update() function you can update the transferred bytes
counter and do other calculations. Or am I missing something? The
current implementation seems to be overly complicated and even
probably a bit buggy. The "multiwrite" command currently inserts
line breaks on stdout between different files, which does not look
good to me.
Do we really want to have the SoC dependent chunk size? Normally we
should expect the transfer speed to be somewhere between 500 KB/s and
1000 KB/s (the speeds below 500 KB/s can be improved and we are
working on it). But even if we set the chunk size to only 128K, does
it really have any negative impact on anything?
About the boolean flag. You could probably just use the progress
callback function pointer instead of it and lose nothing.
And finally, the new progressbar feature fully replaces the old
transfer speed calculation/printing that was done under the '-v'
switch. So its removal can be probably done as a part of your
patch set.
I also think that we can just tag the 0.3 release right now. And
then in a few days/weeks release the next 0.4 version with the
progressbar feature and other improvements. Do you have any
objections?
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this
