Re: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck

[Peter Robinson]

>>> On Sun, 2015-09-27 at 12:37 +0200, Hans de Goede wrote:
>>>
 This is likely a problem with your kernel config, make sure that
 you've the axp209 mfd and regulator drivers enabled and loaded.
>>>
>>>
>>> Thanks, Hans. I really should have figured that out on my own!
>>>
>>> Do you think it's worth asking PeterR if he will change the default
>>> Fedora armv7 config to CONFIG_REGULATOR_AXP20X=y rather than the
>>> current CONFIG_REGULATOR_AXP20X=m? (I suspect that request might
>>> carry more weight if it comes from you rather than me. ;)
>>>
>>
>> Hans,
>>
>> Do you have an opinion, (or anyone else for that matter), on what would be
>> the upstream preferred way of getting the axp20x regulator driver to
>> auto-load, from a DT reference, assuming it is built as a module?
>> Something
>> like the attached patch? (Not tested, just thinking out loud.)
>
>
> This is already fixed by this patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/axp20x-regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec

I've pulled this patch into the F-23/4.2.x kernel, it'll be in the
4.2.2 build, it's already in rawhide.

Peter

-- 
You received this message because you are subscribed to the Google 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: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck

[Peter Robinson]

>> > This is already fixed by this patch:
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>> > mit/drivers/regulator/axp20x
>> > -regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec
>>
>> I've pulled this patch into the F-23/4.2.x kernel, it'll be in the
>> 4.2.2 build, it's already in rawhide.
>
> Thanks, Peter.
>
> One other thing to think about. Although the cpufreq-dt module will
> autoload from dt ref, it needs to be in the initramfs image created by
> dracut. This doesn't happen automatically. Currently have created a
> /etc/dracut.conf.d/sunxi.conf with...

Weird, it appears to load and work post initrd with the BeagleBone.

In /sys/devices/system/cpu/cpu0/cpufreq I get all the bits I would
expect with cur/max/mon freqs etc.

I'll have a look when I get a spare moment on a A20 device.

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH v4 0/3] Allwinner DE2 HDMI SimpleFB support

[Peter Robinson]

On Fri, Sep 15, 2017 at 2:59 AM, Icenowy Zheng  wrote:
> This patchset is for Allwinner DE2 HDMI SimpleFB support.
>
> The framebuffer initialized by the Allwinner DE2 driver can be
> passed by to the kernel as simplefb, and this can enable the
> kernel to display graphics without having full DE2 driver.
>
> Add the suppot of simplefb in DE2 code.
>
> The code to find a simplefb with sunxi extension and a suitable
> pipeline is extracted to a new source file in video/sunxi/.
>
> An option is added for device tree simplefb, and furtherly
> other simplefb support code should also be converted to it.

There was a generic simplefb driver recently added [1], is it worth
basing it on that?

[1] https://lists.denx.de/pipermail/u-boot/2017-September/306273.html

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH v6 0/7] sunxi: sync H3, H5, A64 DTs from mainline Linux

[Peter Robinson]

On Wed, May 16, 2018 at 9:00 AM, Andre Przywara  wrote:
> This is an updated version of the series which brings the exact mainline
> Linux device tree files for various Allwinner boards into U-Boot.
> Apart from using the usually more correct reference DT files, this offers
> the big benefit of being able to use U-Boot's DT copy for directly passing
> it to the kernel. This avoids to actually load a .dtb file from somewhere,
> and allows seamless and automatic UEFI booting, so distribution installer
> images should just work (TM).
>
> This cover the ARMv8 SoCs (H5, A64), but also all boards with the H3, as
> this is somewhat married to the H5 and can only be updated together.
> The H3 and H5 DT files have diverged quite a bit, but as U-Boot's own
> usage of the DT is (yet) quite limited, there should be no regressions.
> The patches are split to first update the SoC .dtsi file, then the board
> .dts files in a second patch. They are grouped to handle the A64 first,
> then the H5 and H3. I put the respective kernel commit IDs in the commit
> messages.
> Patch 6 brings in the mainline DT for the SoPine baseboard, for which we
> didn't have a separate .dts in U-Boot so far.
> Patch 7 adds a separate .dts file for the Pine64-LTS board, which is
> virtually identical to the SoPine baseboard, but, due to the SoC being
> named differently, deserves a separate file.
>
> This is based on origin/master (ca70cbabdcd1).
>
> Maxime, I kept you Acked-by: from the previous posts, as I literally
> just updated to the latest Linux master, which went through your review
> anyway. Hope that's OK for you.
>
> Cheers,
> Andre.
>
> Changelog v5 .. v6:
> - bring back DT update patches
> - update to Linux v4.17-rc5

Are these based purely on 4.17rc5 because I don't see
sun50i-a64-pine64-lts.dts in Linus's upstream.

Peter

> Changelog v4 .. v5:
> - drop Linux DT update patches for now
> - fix minor checkpatch complaints
>
> Changelog v3 .. v4:
> - remove MMC environment for all Allwinner boards (including 32 bit ones)
> - keep MMC environment offset to the old values
> - drop DT adjustments to use fixed MMC regulator
>
> Changelog v2 .. v3:
> 01: added, was on the list before
> 02: drop redundant H5 line
> 03-08: unchanged
> 09-20: added
>
> Changelog v1 .. v2:
> 01, 02, 03: unchanged
> 04, 05, 06, 07: added
>
> Andre Przywara (7):
>   sunxi: DT: A64: update device tree file for Allwinner A64 SoC
>   sunxi: DT: A64: update board .dts files from Linux
>   sunxi: DT: update device tree files for Allwinner H3 and H5 SoCs
>   sunxi: DT: H5: update board .dts files from Linux
>   sunxi: DT: H3: update board .dts files from Linux
>   sunxi: DT: A64: add proper SoPine baseboard device tree
>   sunxi: DT: A64: add Pine64-LTS support
>
>  arch/arm/dts/Makefile   |   4 +-
>  arch/arm/dts/axp803.dtsi| 150 +
>  arch/arm/dts/sun50i-a64-bananapi-m64.dts| 200 +-
>  arch/arm/dts/sun50i-a64-nanopi-a64.dts  | 111 +++-
>  arch/arm/dts/sun50i-a64-olinuxino.dts   | 153 -
>  arch/arm/dts/sun50i-a64-orangepi-win.dts| 135 +++-
>  arch/arm/dts/sun50i-a64-pine64-lts.dts  |  13 +
>  arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi |  59 --
>  arch/arm/dts/sun50i-a64-pine64-plus.dts |  17 +-
>  arch/arm/dts/sun50i-a64-pine64.dts  | 186 +-
>  arch/arm/dts/sun50i-a64-sopine-baseboard.dts| 150 +
>  arch/arm/dts/sun50i-a64-sopine.dtsi | 142 
>  arch/arm/dts/sun50i-a64.dtsi| 303 -
>  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts | 122 +++-
>  arch/arm/dts/sun50i-h5-nanopi-neo2.dts  |  91 ++-
>  arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 186 +-
>  arch/arm/dts/sun50i-h5-orangepi-prime.dts   | 189 +-
>  arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dts  |  64 +-
>  arch/arm/dts/sun50i-h5.dtsi |  36 +-
>  arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts|  55 +-
>  arch/arm/dts/sun8i-h3-bananapi-m2-plus.dts  | 109 ++-
>  arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts|  78 +++
>  arch/arm/dts/sun8i-h3-nanopi-m1.dts |  42 ++
>  arch/arm/dts/sun8i-h3-nanopi-neo-air.dts|  28 +-
>  arch/arm/dts/sun8i-h3-nanopi-neo.dts|  17 +
>  arch/arm/dts/sun8i-h3-nanopi.dtsi   |  13 +-
>  arch/arm/dts/sun8i-h3-orangepi-2.dts|  92 ++-
>  arch/arm/dts/sun8i-h3-orangepi-lite.dts |  57 +-
>  arch/arm/dts/sun8i-h3-orangepi-one.dts  |  94 ++-
>  arch/arm/dts/sun8i-h3-orangepi-pc-plus.dts  |  11 +-
>  arch/arm/dts/sun8i-h3-orangepi-pc.dts   | 113 +++-
>  arch/arm/dts/sun8i-h3-orangepi-plus.dts |  29 +-
>  arch/arm/dts/sun8i-h3-orangepi-plus2e.dts   |  15 +-
>  arch/arm/dts/sun8i-h3.dtsi  | 544 ++-
>  arch/arm/dts/sunxi-h3-h5.dtsi   | 842 
> 
>  

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Peter Robinson]

On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass  wrote:
> Hi Andre,
>
> On 2 April 2018 at 09:43, André Przywara  wrote:
>> Hi,
>>
>> On 01/04/18 14:19, Tom Rini wrote:
>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
 On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> Hi Tom,
>
> On 7 August 2017 at 09:39, Tom Rini  wrote:
>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>
>>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>>> code, with #ifdefs and different code paths. We should try to move over 
>>> to
>>> this soon so we can drop the old code.

 I hope this will applicable to SPL too?

 If so, we are having SPL size issues with few Allwinner families, if
 enable SPL_DM any suggestions?
>>>
>>> How close, and have you looked at the u-boot-spl.map to see what you can
>>> maybe trim?  Or areas to look at reducing in code complexity?
>>
>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>> and picked most low hanging fruits already.
>> So far we discussed several mitigations, but mostly to cover the
>> "natural" SPL code size grow over time:
>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>> padding (for a 2KB architectural alignment). Given that the vectors are
>> used only for debugging purposes, we could scrap them entirely or
>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>> ideally. Lowest hanging fruit so far.
>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>> encoding. This reduces the size significantly, to about 20KB. The
>> disadvantage is using a second cross-compiler or even a additional
>> cross-compiler for native builds, complicating the build process.
>> I maintain a branch for enabling FEL booting here [1], which provides
>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>> There are no technical disadvantages in running the SPL in 32-bit, so
>> this is mostly a build issue.
>
> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> ARMv7. It should be fairly easy to do,

ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in
the case of Allwinner A64

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Peter Robinson]

On Mon, Apr 2, 2018 at 3:56 AM, Simon Glass <s...@chromium.org> wrote:
> Hi Peter,
>
> On 2 April 2018 at 10:45, Peter Robinson <pbrobin...@gmail.com> wrote:
>> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass <s...@google.com> wrote:
>>> Hi Andre,
>>>
>>> On 2 April 2018 at 09:43, André Przywara <andre.przyw...@arm.com> wrote:
>>>> Hi,
>>>>
>>>> On 01/04/18 14:19, Tom Rini wrote:
>>>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>>>>>> On Mon, Sep 4, 2017 at 9:57 PM,  <s...@google.com> wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> On 7 August 2017 at 09:39, Tom Rini <tr...@konsulko.com> wrote:
>>>>>>>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>>>>>>>
>>>>>>>>> The CONFIG_BLK conversion involves quite invasive changes in the 
>>>>>>>>> U-Boot
>>>>>>>>> code, with #ifdefs and different code paths. We should try to move 
>>>>>>>>> over to
>>>>>>>>> this soon so we can drop the old code.
>>>>>>
>>>>>> I hope this will applicable to SPL too?
>>>>>>
>>>>>> If so, we are having SPL size issues with few Allwinner families, if
>>>>>> enable SPL_DM any suggestions?
>>>>>
>>>>> How close, and have you looked at the u-boot-spl.map to see what you can
>>>>> maybe trim?  Or areas to look at reducing in code complexity?
>>>>
>>>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>>>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>>>> and picked most low hanging fruits already.
>>>> So far we discussed several mitigations, but mostly to cover the
>>>> "natural" SPL code size grow over time:
>>>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>>>> padding (for a 2KB architectural alignment). Given that the vectors are
>>>> used only for debugging purposes, we could scrap them entirely or
>>>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>>>> ideally. Lowest hanging fruit so far.
>>>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>>>> encoding. This reduces the size significantly, to about 20KB. The
>>>> disadvantage is using a second cross-compiler or even a additional
>>>> cross-compiler for native builds, complicating the build process.
>>>> I maintain a branch for enabling FEL booting here [1], which provides
>>>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>>>> There are no technical disadvantages in running the SPL in 32-bit, so
>>>> this is mostly a build issue.
>>>
>>> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
>>> ARMv7. It should be fairly easy to do,
>>
>> ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in
>> the case of Allwinner A64
>
> Yes, but that is just a matter of compiler or compiler flags. My point
> was we should be able to use different build for each without too much
> work.

It's a lot more work for the way most distros build u-boot, but TBH
the sooner I don't need to the better ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

[Peter Robinson]

On Thu, May 16, 2019 at 1:47 AM Andre Przywara  wrote:
>
> The first USB controller on the A64 SoC shares a PHY with the OTG
> controller. Reportedly to avoid problems with the VBUS regulator under
> Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file.
>
> However on boards which can't use peripheral mode (because they have an
> always-on VBUS supply on an USB-A socket) we don't need this trick, and
> can properly connect host controller 0 to the PHY 0.
>
> Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the
> upper USB port in U-Boot on those boards.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/dts/sun50i-a64-pine64.dts   | 5 -
>  arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 -
>  2 files changed, 8 insertions(+), 2 deletions(-)

Are these changes going to go upstream to Linux too? If not it's
probably best to add it to a u-boot.dtsi so the changes don't get lost
when the DT files are re-synced from Linux. Same with the similar
patches for the H6 boards.

Peter

> diff --git a/arch/arm/dts/sun50i-a64-pine64.dts 
> b/arch/arm/dts/sun50i-a64-pine64.dts
> index c077b6c1f4..523a4d5bff 100644
> --- a/arch/arm/dts/sun50i-a64-pine64.dts
> +++ b/arch/arm/dts/sun50i-a64-pine64.dts
> @@ -80,6 +80,8 @@
>  };
>
>   {
> +   phys = < 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -136,6 +138,8 @@
>  };
>
>   {
> +   phys = < 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -301,7 +305,6 @@
>
>  _otg {
> dr_mode = "host";
> -   status = "okay";
>  };
>
>   {
> diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts 
> b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> index 53fcc9098d..1986897177 100644
> --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> @@ -85,6 +85,8 @@
>  };
>
>   {
> +   phys = < 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -131,6 +133,8 @@
>  };
>
>   {
> +   phys = < 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -172,7 +176,6 @@
>
>  _otg {
> dr_mode = "host";
> -   status = "okay";
>  };
>
>   {
> --
> 2.14.5
>
> ___
> U-Boot mailing list
> u-b...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CALeDE9PQ4XGUeSr2D0rY%3D4ueBtYJHHV2mnz0WotQPCXvhtTeUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support

[Peter Robinson]

On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara  wrote:
>
> The eMMC standard describes the concept of boot partitions, consisting
> of two storage areas separate from the main user data partition.
> The Allwinner BootROM supports loading SPL/Boot0 from such a boot
> partition, if that is configured in the eMMC device [1].
>
> To load U-Boot proper along with the SPL from there, currently this
> requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this
> build won't boot from the normal eMMC user partition anymore.
> Also the raw MMC sector offset needs to be adjusted manually, preventing
> a boot from an SD card.
>
> This series introduces automatic detection of eMMC boot partition boot.
> Patch 3/5 automates the raw MMC sector offset decision, allowing such
> a build to also boot from an SD card.
> Unfortunately the BootROM does not mark an eMMC boot partition boot
> differently from the normal eMMC user data partition boot, so patch 4/5
> introduces a function that repeats the BootROM algorithm, so that the SPL
> comes to the same conclusion as the BootROM. This allows to build one
> single image that boots from everywhere: eMMC user data, eMMC boot,
> SD card, SPI flash.
> Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5
> extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible.
>
> Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by
> 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size
> goes up by 444 bytes (AArch64) and 260 bytes (ARMv7).
> Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5
> enables this new mechanism for some boards I could test this on.
>
> Please have a look and test this if you have a board with eMMC.
> I put installation instructions into the linux-sunxi Wiki:
> http://linux-sunxi.org/Bootable_eMMC

It would probably be good to put that link in the local Allwinner docs
so it's easier for people to find.

Peter

> Cheers,
> Andre
>
> [1] http://linux-sunxi.org/Bootable_eMMC#The_BROM_implementation_details
>
> Andre Przywara (5):
>   sunxi: Fix is_boot0_magic macro
>   spl: mmc: extend spl_mmc_boot_mode() to take mmc argument
>   sunxi: Simplify eMMC boot partition booting
>   sunxi: eMMC: Add automatic boot detection
>   sunxi: defconfig: enable eMMC boot partition support
>
>  arch/arm/include/asm/arch-sunxi/spl.h  |  2 +-
>  arch/arm/mach-imx/spl.c|  2 +-
>  arch/arm/mach-k3/am6_init.c|  2 +-
>  arch/arm/mach-k3/j721e_init.c  |  2 +-
>  arch/arm/mach-omap2/boot-common.c  |  2 +-
>  arch/arm/mach-rockchip/spl.c   |  2 +-
>  arch/arm/mach-socfpga/spl_a10.c|  2 +-
>  arch/arm/mach-socfpga/spl_agilex.c |  2 +-
>  arch/arm/mach-socfpga/spl_gen5.c   |  2 +-
>  arch/arm/mach-socfpga/spl_s10.c|  2 +-
>  arch/arm/mach-stm32mp/spl.c|  2 +-
>  arch/arm/mach-sunxi/board.c| 94 +-
>  arch/arm/mach-uniphier/mmc-boot-mode.c |  5 +-
>  common/spl/spl_mmc.c   |  4 +-
>  configs/bananapi_m64_defconfig |  1 +
>  configs/emlid_neutis_n5_devboard_defconfig |  1 +
>  configs/pine64-lts_defconfig   |  1 +
>  configs/pine_h64_defconfig |  1 +
>  include/spl.h  |  3 +-
>  19 files changed, 113 insertions(+), 19 deletions(-)
>
> --
> 2.17.5
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CALeDE9Oo8vvwADE5M%2BDz17d5Zf7mTmerC3Lid9%2B-9iTX1nMVdg%40mail.gmail.com.

[linux-sunxi] Re: [PATCH] sunxi: Properly check for SATAPWR and MACPWR

[Peter Robinson]

On Tue, Jan 19, 2021 at 1:06 AM Andre Przywara  wrote:
>
> The #ifdef CONFIG_xxxPWR conditionals were not working as expected, as
> string Kconfig symbols are always "defined" from the preprocessor's
> perspective. This lead to unnecessary calls to the GPIO routines, but
> also always added a half a second delay to wait for a SATA disk to power
> up. Many thanks to Peter for pointing this out!
>
> Fix this by properly comparing the Kconfig symbols against the empty
> string. strcmp() would be nicer for this, but GCC does not optimise this
> away, probably due to our standalone compiler switches.
>
> Reported-by: Peter Robinson 
> Signed-off-by: Andre Przywara 
Tested-by: Peter Robinson 

Tested on Pine64, Cubietruck with root fs on SATA SSD, and an orangepi_pc
> ---
>  board/sunxi/board.c | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 4f058952b5b..a0b5778b3bc 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -265,18 +265,28 @@ int board_init(void)
> if (ret)
> return ret;
>
> -#ifdef CONFIG_SATAPWR
> -   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> -   gpio_request(satapwr_pin, "satapwr");
> -   gpio_direction_output(satapwr_pin, 1);
> -   /* Give attached sata device time to power-up to avoid link timeouts 
> */
> -   mdelay(500);
> -#endif
> -#ifdef CONFIG_MACPWR
> -   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> -   gpio_request(macpwr_pin, "macpwr");
> -   gpio_direction_output(macpwr_pin, 1);
> -#endif
> +   /* strcmp() would look better, but doesn't get optimised away. */
> +   if (CONFIG_SATAPWR[0]) {
> +   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> +   if (satapwr_pin >= 0) {
> +   gpio_request(satapwr_pin, "satapwr");
> +   gpio_direction_output(satapwr_pin, 1);
> +
> +   /*
> +* Give the attached SATA device time to power-up
> +* to avoid link timeouts
> +*/
> +   mdelay(500);
> +   }
> +   }
> +
> +   if (CONFIG_MACPWR[0]) {
> +   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> +   if (macpwr_pin >= 0) {
> +   gpio_request(macpwr_pin, "macpwr");
> +   gpio_direction_output(macpwr_pin, 1);
> +   }
> +   }
>
>  #ifdef CONFIG_DM_I2C
> /*
> --
> 2.17.5
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CALeDE9O%2BBgOrU%3DAcCGqhggH4zTaYX4SwadvGBHOcL3qJOca5JA%40mail.gmail.com.

[linux-sunxi] Re: [PATCH 1/2] sunxi: support asymmetric dual rank DRAM on A64/R40

[Peter Robinson]

On Thu, Feb 25, 2021 at 4:14 PM Icenowy Zheng  wrote:
>
> Previously we have known that R40 has a configuration register for its
> rank 1, which allows different configuration than rank 0. Reverse
> engineering of newest libdram of A64 from Allwinner shows that A64 has
> this register too. It's bit 0 (which enables dual rank in rank 0
> configuration register) means a dedicated rank size setup is used for
> rank 1.
>
> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
> DRAM support necessary.
>
> Add this support. The code could support both A64 and R40, but because
> dual rank detection is broken on R40 now, we cannot really use it on R40
> currently.
>
> Signed-off-by: Icenowy Zheng 
Tested-by: Peter Robinson 

Tested on Pinephone Braveheart and 3Gb variants plus a Pine64 and all
work as expected.

> ---
>  .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 ++-
>  arch/arm/mach-sunxi/dram_sunxi_dw.c   | 94 +++
>  2 files changed, 82 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> index a5a7ebde44..e843c14202 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
>  #define NR_OF_BYTE_LANES   (32 / BITS_PER_BYTE)
>  /* The eight data lines (DQn) plus DM, DQS and DQSN */
>  #define LINES_PER_BYTE_LANE(BITS_PER_BYTE + 3)
> -struct dram_para {
> +
> +struct rank_para {
> u16 page_size;
> -   u8 bus_full_width;
> -   u8 dual_rank;
> u8 row_bits;
> u8 bank_bits;
> +};
> +
> +struct dram_para {
> +   u8 dual_rank;
> +   u8 bus_full_width;
> +   struct rank_para ranks[2];
> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> const u8 ac_delays[31];
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index d0600011ff..2b9d631d49 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -399,11 +399,19 @@ static void mctl_set_cr(uint16_t socid, struct 
> dram_para *para)
>  #else
>  #error Unsupported DRAM type!
>  #endif
> -  (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
> +  (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
>MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
>(para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
> -  MCTL_CR_PAGE_SIZE(para->page_size) |
> -  MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
> +  MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
> +  MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
> +
> +   if (para->dual_rank && (socid == SOCID_A64 || socid == SOCID_R40)) {
> +   writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS : 
> MCTL_CR_FOUR_BANKS) |
> +  MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> +  MCTL_CR_DUAL_RANK |
> +  MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
> +  MCTL_CR_ROW_BITS(para->ranks[1].row_bits), 
> _com->cr_r1);
> +   }
>
> if (socid == SOCID_R40) {
> if (para->dual_rank)
> @@ -646,35 +654,63 @@ static int mctl_channel_init(uint16_t socid, struct 
> dram_para *para)
> return 0;
>  }
>
> -static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para 
> *para)
> +/*
> + * Test if memory at offset offset matches memory at a certain base
> + */
> +static bool mctl_mem_matches_base(u32 offset, ulong base)
> +{
> +   /* Try to write different values to RAM at two addresses */
> +   writel(0, base);
> +   writel(0xaa55aa55, base + offset);
> +   dsb();
> +   /* Check if the same value is actually observed when reading back */
> +   return readl(base) ==
> +  readl(base + offset);
> +}
> +
> +static void mctl_auto_detect_dram_size_rank(uint16_t socid, struct dram_para 
> *para, ulong base, struct rank_para *rank)
>  {
> /* detect row address bits */
> -   para->page_size = 512;
> -   para->row_bits = 16;
> -   para->bank_bits = 2;
> +   rank->page_size = 512;
> +   rank->row_bits = 16;
> +   rank->bank_b

[linux-sunxi] Re: [PATCH 20/20] Enable led on boot to notify user of boot status

[Peter Robinson]

On Thu, Feb 25, 2021 at 3:17 PM André Przywara  wrote:
>
> On 20/02/2021 12:14, Nicolas Boulenguez wrote:
> > From: Marius Gripsgard 
>
> Hi,
>
> This is not really Pinephone specific, actually not even sunxi specific.
> I see two better ways of solving this:
>
> - We introduce some generic code to find "gpio-leds" subnodes in the DT,
> which have a default-state = "on" property. This could be either added
> to drivers/led/led_gpio.c, or in some higher level.
>
> - We introduce a generic boot LED GPIO config symbol. Maybe there is
> already something, that sounds like a generally useful feature? That
> would have the advantage of being already enabled in the SPL (admittedly
> a sunxi specific problem).
>
> Any opinions?

I believe there's already a way to use LEDs for status during the boot
process using the CONFIG_LED_STATUS selection of config options. A
grep of the defconfig already shows a number of boards using this. I
wonder why the already existing infrastructure isn't useful.

Peter

> Cheers,
> Andre
>
> > ---
> >  arch/arm/mach-sunxi/Kconfig | 5 +
> >  board/sunxi/board.c | 4 ++--
> >  configs/pinephone_defconfig | 1 +
> >  3 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 8421f3b685..2bfdf7738b 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -1,5 +1,10 @@
> >  if ARCH_SUNXI
> >
> > +config PINEPHONE_LEDS
> > + bool "Notify boot status via LEDs on PinePhone"
> > + ---help---
> > + LED boot notification.
> > +
> >  config SPL_LDSCRIPT
> >   default "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" if !ARM64
> >
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index abd7e390b2..a117b89ba2 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -637,6 +638,12 @@ void sunxi_board_init(void)
> >  {
> >   int power_failed = 0;
> >
> > +#ifdef CONFIG_PINEPHONE_LEDS
> > + /* PD18:G PD19:R PD20:B */
> > + gpio_request(SUNXI_GPD(18), "led:green");
> > + gpio_direction_output(SUNXI_GPD(18), 1);
> > +#endif
> > +
> >  #ifdef CONFIG_SY8106A_POWER
> >   power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
> >  #endif
> > diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
> > index ff5da42ce0..9de6ab2316 100644
> > --- a/configs/pinephone_defconfig
> > +++ b/configs/pinephone_defconfig
> > @@ -1,6 +21,7 @@
> >  CONFIG_ARM=y
> >  CONFIG_ARCH_SUNXI=y
> >  CONFIG_SPL=y
> > +CONFIG_PINEPHONE_LEDS=y
> >  CONFIG_MACH_SUN50I=y
> >  CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> >  CONFIG_DRAM_CLK=552
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CALeDE9PwOZuGz1dxN87UqCZf1Weker6%3DW4gJ-_p3rX%2BWgME8Cg%40mail.gmail.com.