Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[Alexander Graf]

On 11.01.19 05:29, AKASHI Takahiro wrote:
> Alex, Heinrich and Simon,
> 
> Thank you for your comments, they are all valuable but also make me
> confused as different people have different requirements :)
> I'm not sure that all of us share the same *ultimate* goal here.

The shared ultimate goal is to "merge" (as Simon put it) dm and efi objects.

But we have this annoying interim state where we would lose a few boards
because they haven't been converted to DM. That's what keeps us from it.

I think what this discussion boils down to is that someone needs to
start prototyping the DM/EFI integration. Start off with a simple
subsystem, like BLK. Then provide a DM path and have a non-DM fallback
still in its own source file that also provides EFI BLK devices.
Eventually we just remove the latter.

That way we can then work on getting hotplug working in the DM path,
which is the one we want anyway. For non-DM, you simply miss out on that
amazing new feature, but we don't regress users.

> So, first, let me reply to each of your comments.
> Through this process, I hope we will have better understandings
> of long-term solution as well as a tentative fix.
> 
> On Thu, Jan 10, 2019 at 10:22:04AM +0100, Alexander Graf wrote:
>>
>>
>>> Am 10.01.2019 um 10:16 schrieb AKASHI Takahiro :
>>>
 On Thu, Jan 10, 2019 at 09:15:36AM +0100, Alexander Graf wrote:


>> Am 10.01.2019 um 09:02 schrieb AKASHI Takahiro 
>> :
>>
>> On Thu, Jan 10, 2019 at 08:30:13AM +0100, Alexander Graf wrote:
>>
>>
>>> On 10.01.19 08:26, AKASHI Takahiro wrote:
>>> Alex,
>>>
 On Thu, Jan 10, 2019 at 07:21:12AM +0100, Alexander Graf wrote:


> On 10.01.19 03:13, AKASHI Takahiro wrote:
> Alex,
>
>> On Wed, Jan 09, 2019 at 10:06:16AM +0100, Alexander Graf wrote:
>>
>>
>>> On 13.12.18 08:58, AKASHI Takahiro wrote:
>>> Heinrich,
>>>
> On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt 
> wrote:
> On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
> Currently, efi_init_obj_list() scan disk devices only once, and 
> never
> change a list of efi disk devices. This will possibly result in 
> failing
> to find a removable storage which may be added later on. See [1].
>
> In this patch, called is efi_disk_update() which is responsible 
> for
> re-scanning UCLASS_BLK devices and removing/adding efi disks if 
> necessary.
>
> For example,
>
> => efishell devices
> Scanning disk pci_mmc.blk...
> Found 3 disks
> Device Name
> 
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> => usb start
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 3 USB Device(s) found
>  scanning usb for storage devices... 1 Storage Device(s) found
> => efishell devices
> Scanning disk usb_mass_storage.lun0...
> Device Name
> 
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
>
> Without this patch, the last device, USB mass storage, won't show 
> up.
>
> [1] 
> https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
>
> Signed-off-by: AKASHI Takahiro 

 Why should we try to fix something in the EFI subsystems that goes 
 wrong
 in the handling of device enumeration.
>>>
>>> No.
>>> This is a natural result from how efi disks are currently 
>>> implemented on u-boot.
>>> Do you want to totally re-write/re-implement efi disks?
>>
>> Could we just make this event based for now? Call a hook from the
>> storage dm subsystem when a new u-boot block device gets created to
>> issue a sync of that in the efi subsystem?
>
> If I correctly understand you, your suggestion here corresponds
> with my proposal#3 in [1] while my current approach is #2.
>
> [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html

Re: [U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 1:57 PM Simon Glass  wrote:
>
> Hi Simon,
>
> On Fri, 4 Jan 2019 at 00:15, Simon Goldschmidt
>  wrote:
> >
> > On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt
> >  wrote:
> > >
> > >
> > >
> > > Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass  
> > > geschrieben:
> > >>
> > >> Hi Simon,
> > >>
> > >> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
> > >>  wrote:
> > >> >
> > >> > Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
> > >> > > Am 20.12.2018 um 18:37 schrieb Simon Glass:
> > >> > >> Hi Simon,
> > >> > >>
> > >> > >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
> > >> > >>  wrote:
> > >> > >>>
> > >> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
> > >> >  Hi Simon,
> > >> > 
> > >> >  On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
> > >> >   wrote:
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > while searching for bytes to save in SPL in order to add FIT 
> > >> > > signature
> > >> > > handling, I am currently trying to get socfpga-gen5 to use 
> > >> > > OF_PLATDATA.
> > >> > >
> > >> > > To begin, I stripped down socfpga_socrates_defconfig to 
> > >> > > absolutely
> > >> > > nothing but serial drivers in SPL (with some modifications to the
> > >> > > Kconfig) and enabled DEBUG_UART to see what's going on.
> > >> > >
> > >> > > Now while this config runs OK with a dtb (it just won't boot as 
> > >> > > drivers
> > >> > > are missing -> "failed to boot from all boot devices"), it does 
> > >> > > not find
> > >> > > the serial driver after enabling OF_PLATDATA.
> > >> > >
> > >> > > So since serial_rockchip.c already uses OF_PLATDATA and is based 
> > >> > > on
> > >> > > ns16550 that my socfpga-gen5 platform is using: what do I have 
> > >> > > to do
> > >> > > besides enabling OF_PLATDATA to get this working?
> > >> > >
> > >> > > I just seems like uclass_first_device does not find any 
> > >> > > UCLASS_SERIAL
> > >> > > deivce when OF_PLATDATA is enabled.
> > >> > 
> > >> >  There is the of-plat.txt README.
> > >> > >>>
> > >> > >>> Yes, I should have mentioned I already read that and still had 
> > >> > >>> those
> > >> > >>> questions. Kconfig help says README.platdata though. We probably 
> > >> > >>> should
> > >> > >>> update that link.
> > >> > >>>
> > >> >  Basically the dtoc tool creates U_BOOT_DEVICE() declarations and 
> > >> >  links
> > >> >  them with SPL. These should show up in your image and therefore be
> > >> >  bound. You can call dm_dump_all() in SPL to see what what devices 
> > >> >  are
> > >> >  bound. I presume you are calling spl_init()?
> > >> > 
> > >> >  You can look at what dtoc produces. The example serial driver for
> > >> >  Rockchip is serial_rockchip.c
> > >> > >>>
> > >> > >>> I saw that as an example (because I also have an ns16550 
> > >> > >>> compatible on
> > >> > >>> my board) but couldn't figure out why it is not bound. By debugging
> > >> > >>> 'dm_scan_platdata', 'lists_bind_drivers' and 
> > >> > >>> 'device_bind_by_name', by
> > >> > >>> now I know the driver names don't match. That is something I did 
> > >> > >>> not get
> > >> > >>> just by reading of-plat.txt. I'll work on a patch to clarify that 
> > >> > >>> document.
> > >> > >>
> > >> > >> Yes I'd really appreciate some patches here. It is hard to know what
> > >> > >> people won't understand and this feature could really do with a more
> > >> > >> details docs or a walk-through.
> > >> > >>
> > >> > >>>
> > >> > >>> Right now, serial works. I had to add a new platform specific 
> > >> > >>> driver
> > >> > >>> just like serial_rockchip though. For DTS, we can pass multiple
> > >> > >>> 'compatible' strings, but for platdata, we have to create multiple
> > >> > >>> drivers. That's a bit strange when porting boards...
> > >> > >>
> > >> > >> Yes it is. I'm not sure how to solve that though. Probably dtoc can 
> > >> > >> be
> > >> > >> made smarter. Ideally you only need one device of each uclass in 
> > >> > >> SPL.
> > >> > >
> > >> > > Would it work to use the unchanged 'compatible' string for the 
> > >> > > '.name'
> > >> > > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
> > >> > > could change from comparing names to comparing to compatibles. That
> > >> > > would make it more DTS-like.
> > >> > >
> > >> > > Then, I think we could need some kind of fallback code for properties
> > >> > > that are optional in the DTS. Maybe we can create defines for each 
> > >> > > dtd
> > >> > > struct so that drivers can test the existence of dtd sturct fields 
> > >> > > using
> > >> > > #ifdef. [Given the special usage, I guess it's OK to assume that 
> > >> > > theses
> > >> > > structs are only used once per DTS so that we don't have to worry 
> > >> > > about
> > >> > > how to solve this for multiple occurrences with different optional
> > >> > > parameters?]
> > >> 

Re: [U-Boot] [PATCH] of-platdata: improve documentation

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 1:57 PM Simon Glass  wrote:
>
> On Mon, 7 Jan 2019 at 12:23, Simon Goldschmidt
>  wrote:
> >
> > Improve some things in the documentation of OF_PLATDATA that I found
> > while porting socfgpa_gen5 to it.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> >  doc/driver-model/of-plat.txt | 18 --
> >  dts/Kconfig  |  6 ++
> >  2 files changed, 14 insertions(+), 10 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> >
> > diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt
> > index 732bc34f06..ecb5f1724b 100644
> > --- a/doc/driver-model/of-plat.txt
> > +++ b/doc/driver-model/of-plat.txt
> > @@ -69,12 +69,12 @@ How it works
> >  
> >
> >  The feature is enabled by CONFIG SPL_OF_PLATDATA. This is only available
> > -in SPL and should be tested with:
> > +in SPL/TPL and should be tested with:
> >
> >  #if CONFIG_IS_ENABLED(SPL_OF_PLATDATA)
>
> Actually that seems wrong. Shouldn't it omit the SPL_ part?

Right, didn't catch that.

> >
> >  A new tool called 'dtoc' converts a device tree file either into a set of
> > -struct declarations, one for each compatible node, or a set of
> > +struct declarations, one for each compatible node, and a set of
> >  U_BOOT_DEVICE() declarations along with the actual platform data for each
> >  device. As an example, consider this MMC node:
> >
> > @@ -156,6 +156,12 @@ This avoids the code overhead of converting the device 
> > tree data to
> >  platform data in the driver. The ofdata_to_platdata() method should
> >  therefore do nothing in such a driver.
> >
> > +Note that for the platform data to be matched with a driver, the 'name'
> > +property of the U_BOOT_DEVICE() declaration has to match a driver declared
> > +via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a
> > +'name' identical to the devicetree 'compatible' string is needed, so a
> > +dedicated driver is required for each 'compatible' string.
>
> Not identical - e.g. hyphens change to underscores.

Ehrm, yeah. Seems like I need a V2...

> > +
> >  Where a node has multiple compatible strings, a #define is used to make 
> > them
> >  equivalent, e.g.:
> >
> > @@ -165,8 +171,8 @@ equivalent, e.g.:
> >  Converting of-platdata to a useful form
> >  ---
> >
> > -Of course it would be possible use the of-platdata directly in your driver
> > -whenever configuration information is required. However this meands that 
> > the
> > +Of course it would be possible to use the of-platdata directly in your 
> > driver
> > +whenever configuration information is required. However this means that the
> >  driver will not be able to support device tree, since the of-platdata
> >  structure is not available when device tree is used. It would make no sense
> >  to use this structure if device tree were available, since the structure 
> > has
> > @@ -282,8 +288,8 @@ prevents them being used inadvertently. All usage must 
> > be bracketed with
> >  The dt-platdata.c file contains the device declarations and is is built in
> >  spl/dt-platdata.c.
> >
> > -Some phandles (thsoe that are recognised as such) are converted into
> > -points to platform data. This pointer can potentially be used to access the
> > +Some phandles (those that are recognised as such) are converted into
> > +pointer to platform data. This pointer can potentially be used to access 
> > the
>
> a pointer to platform data

I'll change that as well in V2.

Regards,
Simon

>
> >  referenced device (by searching for the pointer value). This feature is not
> >  yet implemented, however.
> >
> > diff --git a/dts/Kconfig b/dts/Kconfig
> > index 8917f42444..3e85914d11 100644
> > --- a/dts/Kconfig
> > +++ b/dts/Kconfig
> > @@ -265,8 +265,7 @@ config SPL_OF_PLATDATA
> >
> >   This option works by generating C structure declarations for each
> >   compatible string, then adding platform data and U_BOOT_DEVICE
> > - declarations for each node. See README.platdata for more
> > - information.
> > + declarations for each node. See of-plat.txt for more information.
> >
> >  config TPL_OF_PLATDATA
> > bool "Generate platform data for use in TPL"
> > @@ -287,8 +286,7 @@ config TPL_OF_PLATDATA
> >
> >   This option works by generating C structure declarations for each
> >   compatible string, then adding platform data and U_BOOT_DEVICE
> > - declarations for each node. See README.platdata for more
> > - information.
> > + declarations for each node. See of-plat.txt for more information.
> >
> >  endmenu
> >
> > --
> > 2.17.1
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 5:54 PM Tom Rini  wrote:
>
> On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> > Am 10.01.2019 um 16:56 schrieb Tom Rini:
> > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic  wrote:
> > >>>
> > >>>Hi Tom, Soeren,
> > >>>
> > >>>On 09/01/19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > >Hi Soeren,
> > >
> > >On 08/01/19 12:03, Soeren Moch wrote:
> > >>Hi Stefano,
> > >>
> > >>On 08.01.19 11:24, Stefano Babic wrote:
> > >>>Hi Soeren,
> > >>>
> > >>>On 08/01/19 11:14, Soeren Moch wrote:
> > Stefano,
> > 
> > can you apply this for v2019.01? This is really a important fix to 
> > avoid
> >   environment and u-boot binary overwriting each other.
> > It is also a small local fix which cannot hurt anybody else.
> > >>>I will apply and I send a new PR. This is not the first fix in this
> > >>>direction, u-boot becomes pretty large, it is becoming a common 
> > >>>problem.
> > >>>
> > >>Thank you very much.
> > >>
> > >>Yes, "in the good old days (tm)" there was much effort put into not
> > >>increasing the binary size for existing boards when adding new 
> > >>features.
> > >
> > >Right, fully agree.
> > >
> > >>Unfortunately this is not true anymore.
> > >
> > >I get in the same trouble with more as one project. A previous rule of
> > >thumb was to reserve 512KB to the bootloader because it was pretty
> > >unthinkable that bootloader could be larger. Mhmmhhthis remember me
> > >someone else who said that 640Kb is enough for everything.
> > >
> > >Anyway, as you noted, this is a big problem in field and it makes
> > >difficult an upgrade without returning back the device to factory, what
> > >nobody wants.
> > 
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.
> > >>>
> > >>>I am not sure if we should point to EFI as responsible for the increased
> > >>>footprint or it is due to the sum of several components / factors. I
> > >>>just report my experience in last month : I had to port U-Boot for a
> > >>>customer from a not very old release (2017.01) to the current. 2017.01
> > >>>had already (apart of FIT support) all features the customer needed, but
> > >>>there are issues(NAND, UBI) and I kew that they were solved later.
> > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > >>>a lot in board code, but of course I had to reconfigure a lot. At the
> > >>>end, everything worked but I was quite astonished about footprint. I had:
> > >>>
> > >>>2017.01 u-boot.bin 443452
> > >>>2018.11 u-boot.bin 654684
> > >>>
> > >>>  But the new footprint overwrote the space for the env, and I had to
> > >>>change the layout.It was not something that I could not manage and in
> > >>>this specific case, customer could handle it. I cannot say I did
> > >>>something pretty wrong to bloat the bootloader, so my feeling was that
> > >>>there is not a specific part responsible for the increased size, but
> > >>>each component is slightly bigger and they sizes sum at the end.
> > >>>
> > >>>
> >   Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
> > >>>
> > >>>I am unsure about this - just my two cents.
> > >>>
> > >>>I agree with you if we are talking about evaluation boards and / or
> > >>>boards supposed to run different distros (or in any case, more flavour
> > >>>of software).
> > >>>
> > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > >>>for a specific project and won't run any other kind of software. If a
> > >>>device is a navigation system, a network controller, or whatever, it
> > >>>will just do this job until its EOL.
> > >>>
> > >>>Specially for older boards, a new feature should not be activated as
> > >>>default. At the beginning, police in U-Boot was to set just what should
> > >>>be required in the bootloader, without setting what is not needed as
> > >>>default. So default was off instead of on.
> > >>
> > >>I aslo think that would suit U-Boot better. For example, I have one
> > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> > >>currently means I have to re-check the defconfig for every update to
> > >>disable new features that are now on by default. I think having those
> > >>default to off and enabling them via defconfig if required would be 
> > >>better.
> > >
> > >Can SoCFPGA not set the option to make a link failure if you grow beyond
> > >204KiB?  

Re: [U-Boot] [linux-sunxi] [PATCH 2/3] tools: mkimage: Add Allwinner eGON support

[Jagan Teki]

On Sat, Dec 22, 2018 at 7:06 AM Andre Przywara  wrote:
>
> So far we used the separate mksunxiboot tool for generating a bootable
> image for Allwinner SPLs, probably just for historical reasons.
>
> Use the mkimage framework to generate a so called eGON image the
> Allwinner BROM expects.
> The new image type is called "sunxi_egon", to differentiate it
> from the (still to be implemented) secure boot TOC0 image.
>
> Signed-off-by: Andre Przywara 
> ---
>  common/image.c |   1 +
>  include/image.h|   1 +
>  tools/Makefile |   1 +
>  tools/sunxi_egon.c | 136 
> +
>  4 files changed, 139 insertions(+)
>  create mode 100644 tools/sunxi_egon.c
>
> diff --git a/common/image.c b/common/image.c
> index 3ff713a521..17150093d6 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -169,6 +169,7 @@ static const table_entry_t uimage_type[] = {
> {   IH_TYPE_PMMC,"pmmc","TI Power Management 
> Micro-Controller Firmware",},
> {   IH_TYPE_STM32IMAGE, "stm32image", "STMicroelectronics STM32 
> Image" },
> {   IH_TYPE_MTKIMAGE,   "mtk_image",   "MediaTek BootROM loadable 
> Image" },
> +   {   IH_TYPE_SUNXI_EGON, "sunxi_egon",  "Allwinner eGON Boot 
> Image" },
> {   -1, "",   "",   },
>  };
>
> diff --git a/include/image.h b/include/image.h
> index 765ffecee0..35f43b3074 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -284,6 +284,7 @@ enum {
> IH_TYPE_MTKIMAGE,   /* MediaTek BootROM loadable Image */
> IH_TYPE_IMX8MIMAGE, /* Freescale IMX8MBoot Image*/
> IH_TYPE_IMX8IMAGE,  /* Freescale IMX8Boot Image */
> +   IH_TYPE_SUNXI_EGON, /* Allwinner eGON Boot Image */
>
> IH_TYPE_COUNT,  /* Number of image types */
>  };
> diff --git a/tools/Makefile b/tools/Makefile
> index 2c4d91f199..9f2533f048 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -106,6 +106,7 @@ dumpimage-mkimage-objs := aisimage.o \
> stm32image.o \
> $(ROCKCHIP_OBS) \
> socfpgaimage.o \
> +   sunxi_egon.o \
> lib/crc16.o \
> lib/sha1.o \
> lib/sha256.o \
> diff --git a/tools/sunxi_egon.c b/tools/sunxi_egon.c
> new file mode 100644
> index 00..9b38149280
> --- /dev/null
> +++ b/tools/sunxi_egon.c
> @@ -0,0 +1,136 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2018 Arm Ltd.
> + */
> +
> +#include "imagetool.h"
> +#include 
> +
> +#include "../arch/arm/include/asm/arch-sunxi/spl.h"

This can be done as #include 

Reviewed-by: Jagan Teki 
Tested-by: Jagan Teki  # BPI-M64
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH 1/3] tools: mkimage: Add missing names for imx8mimage and loadables

[Jagan Teki]

On Sat, Dec 22, 2018 at 7:06 AM Andre Przywara  wrote:
>
> At the moment "mkimage -T list" starts with two unknown entries, because
> their IH_TYPE_ name is not listed in the uimage_type table.
>
> Add those two entries to get an OCD-compatible image type listing.
>
> Signed-off-by: Andre Przywara 
> ---
>  common/image.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/common/image.c b/common/image.c
> index 0659133fcc..3ff713a521 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -140,7 +140,9 @@ static const table_entry_t uimage_type[] = {
> {   IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
> {   IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot 
> Image",},
> {   IH_TYPE_IMX8IMAGE,  "imx8image",  "NXP i.MX8 Boot Image",},
> +   {   IH_TYPE_IMX8MIMAGE, "imx8mimage", "NXP i.MX8M Boot Image",},

This change already in, 6609c2663c9c9699f3d279ccea599e5d18578b20
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] sunxi: board: Add i2c initialization for sun50i

[Jagan Teki]

On Tue, Jan 8, 2019 at 3:47 PM Maxime Ripard  wrote:
>
> On Tue, Jan 08, 2019 at 12:04:30PM +0200, Stefan Mavrodiev wrote:
> > To use TWI0/1/2 the user can select CONFIG_I2C#_ENABLE.
> > However even the controller is enabled, the mux for the pins
> > are not set.
> >
> > This patch follows the existing mux method. Since the pads are
> > different, separate check is added for each i2c.
> >
> > Tested with A64-SOM204 board.
> >
> > Signed-off-by: Stefan Mavrodiev 
>
>
> Acked-by: Maxime Ripard 

Applied to u-boot-sunxi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 5:54 PM Tom Rini  wrote:
>
> On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> > Am 10.01.2019 um 16:56 schrieb Tom Rini:
> > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic  wrote:
> > >>>
> > >>>Hi Tom, Soeren,
> > >>>
> > >>>On 09/01/19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > >Hi Soeren,
> > >
> > >On 08/01/19 12:03, Soeren Moch wrote:
> > >>Hi Stefano,
> > >>
> > >>On 08.01.19 11:24, Stefano Babic wrote:
> > >>>Hi Soeren,
> > >>>
> > >>>On 08/01/19 11:14, Soeren Moch wrote:
> > Stefano,
> > 
> > can you apply this for v2019.01? This is really a important fix to 
> > avoid
> >   environment and u-boot binary overwriting each other.
> > It is also a small local fix which cannot hurt anybody else.
> > >>>I will apply and I send a new PR. This is not the first fix in this
> > >>>direction, u-boot becomes pretty large, it is becoming a common 
> > >>>problem.
> > >>>
> > >>Thank you very much.
> > >>
> > >>Yes, "in the good old days (tm)" there was much effort put into not
> > >>increasing the binary size for existing boards when adding new 
> > >>features.
> > >
> > >Right, fully agree.
> > >
> > >>Unfortunately this is not true anymore.
> > >
> > >I get in the same trouble with more as one project. A previous rule of
> > >thumb was to reserve 512KB to the bootloader because it was pretty
> > >unthinkable that bootloader could be larger. Mhmmhhthis remember me
> > >someone else who said that 640Kb is enough for everything.
> > >
> > >Anyway, as you noted, this is a big problem in field and it makes
> > >difficult an upgrade without returning back the device to factory, what
> > >nobody wants.
> > 
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.
> > >>>
> > >>>I am not sure if we should point to EFI as responsible for the increased
> > >>>footprint or it is due to the sum of several components / factors. I
> > >>>just report my experience in last month : I had to port U-Boot for a
> > >>>customer from a not very old release (2017.01) to the current. 2017.01
> > >>>had already (apart of FIT support) all features the customer needed, but
> > >>>there are issues(NAND, UBI) and I kew that they were solved later.
> > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > >>>a lot in board code, but of course I had to reconfigure a lot. At the
> > >>>end, everything worked but I was quite astonished about footprint. I had:
> > >>>
> > >>>2017.01 u-boot.bin 443452
> > >>>2018.11 u-boot.bin 654684
> > >>>
> > >>>  But the new footprint overwrote the space for the env, and I had to
> > >>>change the layout.It was not something that I could not manage and in
> > >>>this specific case, customer could handle it. I cannot say I did
> > >>>something pretty wrong to bloat the bootloader, so my feeling was that
> > >>>there is not a specific part responsible for the increased size, but
> > >>>each component is slightly bigger and they sizes sum at the end.
> > >>>
> > >>>
> >   Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
> > >>>
> > >>>I am unsure about this - just my two cents.
> > >>>
> > >>>I agree with you if we are talking about evaluation boards and / or
> > >>>boards supposed to run different distros (or in any case, more flavour
> > >>>of software).
> > >>>
> > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > >>>for a specific project and won't run any other kind of software. If a
> > >>>device is a navigation system, a network controller, or whatever, it
> > >>>will just do this job until its EOL.
> > >>>
> > >>>Specially for older boards, a new feature should not be activated as
> > >>>default. At the beginning, police in U-Boot was to set just what should
> > >>>be required in the bootloader, without setting what is not needed as
> > >>>default. So default was off instead of on.
> > >>
> > >>I aslo think that would suit U-Boot better. For example, I have one
> > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> > >>currently means I have to re-check the defconfig for every update to
> > >>disable new features that are now on by default. I think having those
> > >>default to off and enabling them via defconfig if required would be 
> > >>better.
> > >
> > >Can SoCFPGA not set the option to make a link failure if you grow beyond
> > >204KiB?  

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 11:47 PM Stefano Babic  wrote:
>
> Hi Tom,
>
> On 10/01/19 16:12, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote:
> >> Hi Tom,
> >>
> >> On 10/01/19 15:44, Tom Rini wrote:
> >>> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>  Hi Tom, Soeren,
> 
>  On 09/01/19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 12:03, Soeren Moch wrote:
> >>> Hi Stefano,
> >>>
> >>> On 08.01.19 11:24, Stefano Babic wrote:
>  Hi Soeren,
> 
>  On 08/01/19 11:14, Soeren Moch wrote:
> > Stefano,
> >
> > can you apply this for v2019.01? This is really a important fix to 
> > avoid
> >  environment and u-boot binary overwriting each other.
> > It is also a small local fix which cannot hurt anybody else.
>  I will apply and I send a new PR. This is not the first fix in this
>  direction, u-boot becomes pretty large, it is becoming a common 
>  problem.
> 
> >>> Thank you very much.
> >>>
> >>> Yes, "in the good old days (tm)" there was much effort put into not
> >>> increasing the binary size for existing boards when adding new 
> >>> features.
> >>
> >> Right, fully agree.
> >>
> >>> Unfortunately this is not true anymore.
> >>
> >> I get in the same trouble with more as one project. A previous rule of
> >> thumb was to reserve 512KB to the bootloader because it was pretty
> >> unthinkable that bootloader could be larger. Mhmmhhthis remember me
> >> someone else who said that 640Kb is enough for everything.
> >>
> >> Anyway, as you noted, this is a big problem in field and it makes
> >> difficult an upgrade without returning back the device to factory, what
> >> nobody wants.
> >
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.
> 
>  I am not sure if we should point to EFI as responsible for the increased
>  footprint or it is due to the sum of several components / factors. I
>  just report my experience in last month : I had to port U-Boot for a
>  customer from a not very old release (2017.01) to the current. 2017.01
>  had already (apart of FIT support) all features the customer needed, but
>  there are issues(NAND, UBI) and I kew that they were solved later.
>  Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
>  a lot in board code, but of course I had to reconfigure a lot. At the
>  end, everything worked but I was quite astonished about footprint. I had:
> 
>  2017.01u-boot.bin 443452
>  2018.11 u-boot.bin 654684
>  I'm splitting my reply here into two emails.  This here concerns the
> >>> heck out of me.  But I don't see it on MPC8308RDB.  There I see:
> >>>powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text 
> >>> +6847.0
> >>> MPC8308RDB : all -124241 bss -131040 data -48 text +6847
> >>>u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 
> >>> (-125646)
> >>
> >> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
> >> it is not MPC8308RDB. But nevertheless, I could not understand the
> >> difference is sitze.
> >
> > Right, I understand, that's just the first MPC83xx board I spotted, and
> > I wanted to see if all platforms had such unreasonable growth.  You're
> > showing your custom platform went up by _200_ kilobytes.
>
> I have found that one of the major reason is the different toolchain.
> 2018.11 was built with the toolchain requested by customer, it was gcc
> 6.4. I built 2017.01 with buildman and fetching the toolchain, that
> means 7.3. The same U-Boot versione produces very different footprint,
> much better with the newer toolchain. At least 50-60KB are due to the
> toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more
> code. But then, yes, I want to have them. So at the end, one big
> responsible is the toolchain. So partially I am responsible for new
> footprint (new features), the rest is done by toolchain.

That looked promising, so I gave it a try as well: I'm normally using gcc 6.3
from Debian 9. Comparing the sizes of this and buildman-provided 7.3, I
got a reduction of 100-200 Bytes only (both for SPL and U-Boot) with 7.3.

So your 50 KiB reduction must have been a corner case I guess...

Regards,
Simon

>
>
> >
> >>> And in terms of .bins:
> >>> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 
> >>> /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
> 

Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[AKASHI Takahiro]

Heinrich,

On Thu, Jan 10, 2019 at 08:22:25PM +0100, Heinrich Schuchardt wrote:
> On 1/10/19 10:22 AM, Alexander Graf wrote:
> > 
> > 
> >> Am 10.01.2019 um 10:16 schrieb AKASHI Takahiro 
> >> :
> >>
> >>> On Thu, Jan 10, 2019 at 09:15:36AM +0100, Alexander Graf wrote:
> >>>
> >>>
> > Am 10.01.2019 um 09:02 schrieb AKASHI Takahiro 
> > :
> >
> > On Thu, Jan 10, 2019 at 08:30:13AM +0100, Alexander Graf wrote:
> >
> >
> >> On 10.01.19 08:26, AKASHI Takahiro wrote:
> >> Alex,
> >>
> >>> On Thu, Jan 10, 2019 at 07:21:12AM +0100, Alexander Graf wrote:
> >>>
> >>>
>  On 10.01.19 03:13, AKASHI Takahiro wrote:
>  Alex,
> 
> > On Wed, Jan 09, 2019 at 10:06:16AM +0100, Alexander Graf wrote:
> >
> >
> >> On 13.12.18 08:58, AKASHI Takahiro wrote:
> >> Heinrich,
> >>
>  On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt 
>  wrote:
>  On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
>  Currently, efi_init_obj_list() scan disk devices only once, and 
>  never
>  change a list of efi disk devices. This will possibly result in 
>  failing
>  to find a removable storage which may be added later on. See [1].
> 
>  In this patch, called is efi_disk_update() which is responsible 
>  for
>  re-scanning UCLASS_BLK devices and removing/adding efi disks if 
>  necessary.
> 
>  For example,
> 
>  => efishell devices
>  Scanning disk pci_mmc.blk...
>  Found 3 disks
>  Device Name
>  
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
>  => usb start
>  starting USB...
>  USB0:   USB EHCI 1.00
>  scanning bus 0 for devices... 3 USB Device(s) found
>   scanning usb for storage devices... 1 Storage Device(s) 
>  found
>  => efishell devices
>  Scanning disk usb_mass_storage.lun0...
>  Device Name
>  
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
>  /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
> 
>  Without this patch, the last device, USB mass storage, won't 
>  show up.
> 
>  [1] 
>  https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> 
>  Signed-off-by: AKASHI Takahiro 
> >>>
> >>> Why should we try to fix something in the EFI subsystems that 
> >>> goes wrong
> >>> in the handling of device enumeration.
> >>
> >> No.
> >> This is a natural result from how efi disks are currently 
> >> implemented on u-boot.
> >> Do you want to totally re-write/re-implement efi disks?
> >
> > Could we just make this event based for now? Call a hook from the
> > storage dm subsystem when a new u-boot block device gets created to
> > issue a sync of that in the efi subsystem?
> 
>  If I correctly understand you, your suggestion here corresponds
>  with my proposal#3 in [1] while my current approach is #2.
> 
>  [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> >>>
> >>> Yes, I think so.
> >>>
>  So we will call, say, efi_disk_create(struct udevice *) in
>  blk_create_device() and efi_dsik_delete() in blk_unbind_all().
> >>>
> >>> I would prefer if we didn't call them directly, but through an event
> >>> mechanism. So the efi_disk subsystem registers an event with the dm
> >>> block subsystem and that will just call all events when block devices
> >>> get created which will automatically also include the efi disk 
> >>> creation
> >>> callback. Same for reverse.
> >>
> >> Do you mean efi event by "event?"
> >> (I don't think there is any generic event interface on DM side.)
> >>
> >> Whatever an "event" is or whether we call efi_disk_create() directly
> >> or indirectly via an event, there is one (big?) issue in this approach
> >> (while I've almost finished prototyping):
> >>
> >> We cannot call efi_disk_create() within blk_create_device() because
> >> 

Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[AKASHI Takahiro]

On Thu, Jan 10, 2019 at 05:57:11AM -0700, Simon Glass wrote:
> Hi,
> 
> On Wed, 9 Jan 2019 at 02:06, Alexander Graf  wrote:
> >
> >
> >
> > On 13.12.18 08:58, AKASHI Takahiro wrote:
> > > Heinrich,
> > >
> > > On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt wrote:
> > >> On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
> > >>> Currently, efi_init_obj_list() scan disk devices only once, and never
> > >>> change a list of efi disk devices. This will possibly result in failing
> > >>> to find a removable storage which may be added later on. See [1].
> > >>>
> > >>> In this patch, called is efi_disk_update() which is responsible for
> > >>> re-scanning UCLASS_BLK devices and removing/adding efi disks if 
> > >>> necessary.
> > >>>
> > >>> For example,
> > >>>
> > >>> => efishell devices
> > >>> Scanning disk pci_mmc.blk...
> > >>> Found 3 disks
> > >>> Device Name
> > >>> 
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > >>> => usb start
> > >>> starting USB...
> > >>> USB0:   USB EHCI 1.00
> > >>> scanning bus 0 for devices... 3 USB Device(s) found
> > >>>scanning usb for storage devices... 1 Storage Device(s) found
> > >>> => efishell devices
> > >>> Scanning disk usb_mass_storage.lun0...
> > >>> Device Name
> > >>> 
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
> > >>>
> > >>> Without this patch, the last device, USB mass storage, won't show up.
> > >>>
> > >>> [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> > >>>
> > >>> Signed-off-by: AKASHI Takahiro 
> > >>
> > >> Why should we try to fix something in the EFI subsystems that goes wrong
> > >> in the handling of device enumeration.
> > >
> > > No.
> > > This is a natural result from how efi disks are currently implemented on 
> > > u-boot.
> > > Do you want to totally re-write/re-implement efi disks?
> >
> > Could we just make this event based for now? Call a hook from the
> > storage dm subsystem when a new u-boot block device gets created to
> > issue a sync of that in the efi subsystem?
> >
> 
> Please no. We don't want EFI hooks around the place. EFI should use
> DM, not the other way around.

Right, but every efi disk is associated with a backing "u-boot"
block devices (even more, this is not 1-to-1 mapping but many-to-1 due to
partitions).
Without any sort of event/hook mechanism, we can know of all block
devices only by enumerating them at some point as in my current
approach. Do you want to accept this?

(Even in a hacky way. See efi_disk_register():
for (if_type = 0; if_type < IF_TYPE_COUNT; if_type++)
...
printf("Scanning disks on %s...\n", if_typename);
for (i = 0; i < 4; i++) {<= !!!
desc = blk_get_devnum_by_type(if_type, i);
...
)

> > That hook would obviously only do something (or get registered?) when
i 
> > the efi object stack is initialized.
> >
> > The long term goal IMHO should still be though to just merge DM and EFI
> > objects. But we're still waiting on the deprecation of non-DM devices
> > for that.
> 
> I think think 'merge' is the right word. Perhaps 'create EFI devices
> in DM' is a better term.

How different is your idea from UCLASS_BLK device(efi_block_device.c)?

The current implementation of UCLASS_BLK, in my opinion, is somehow
in a half way; an instance of UCLASS_BLK is created only when a
efi driver is bound to a controller.
In the meantime, efi disks (efi objects which support UEFI_BLOCK_IO_PROTOCOL)
is implicitly created in efi_disk_add_dev() without any *binding*.

> Anyway, let's do that now. As I may have mentioned we should never
> have enabled EFI on pre-DM boards :-) It has just lead to duplication.
> 
> In any case, the migration deadline for DM_MMC (for example) is the
> upcoming merge window, so the time is now.
> 
> As things stand this patch looks reasonable to me. It is a natural
> consequence of duplicating the DM tables.

I think so, yes.

-Takahiro Akashi

> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[AKASHI Takahiro]

Alex, Heinrich and Simon,

Thank you for your comments, they are all valuable but also make me
confused as different people have different requirements :)
I'm not sure that all of us share the same *ultimate* goal here.

So, first, let me reply to each of your comments.
Through this process, I hope we will have better understandings
of long-term solution as well as a tentative fix.

On Thu, Jan 10, 2019 at 10:22:04AM +0100, Alexander Graf wrote:
> 
> 
> > Am 10.01.2019 um 10:16 schrieb AKASHI Takahiro :
> > 
> >> On Thu, Jan 10, 2019 at 09:15:36AM +0100, Alexander Graf wrote:
> >> 
> >> 
>  Am 10.01.2019 um 09:02 schrieb AKASHI Takahiro 
>  :
>  
>  On Thu, Jan 10, 2019 at 08:30:13AM +0100, Alexander Graf wrote:
>  
>  
> > On 10.01.19 08:26, AKASHI Takahiro wrote:
> > Alex,
> > 
> >> On Thu, Jan 10, 2019 at 07:21:12AM +0100, Alexander Graf wrote:
> >> 
> >> 
> >>> On 10.01.19 03:13, AKASHI Takahiro wrote:
> >>> Alex,
> >>> 
>  On Wed, Jan 09, 2019 at 10:06:16AM +0100, Alexander Graf wrote:
>  
>  
> > On 13.12.18 08:58, AKASHI Takahiro wrote:
> > Heinrich,
> > 
> >>> On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt 
> >>> wrote:
> >>> On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
> >>> Currently, efi_init_obj_list() scan disk devices only once, and 
> >>> never
> >>> change a list of efi disk devices. This will possibly result in 
> >>> failing
> >>> to find a removable storage which may be added later on. See [1].
> >>> 
> >>> In this patch, called is efi_disk_update() which is responsible 
> >>> for
> >>> re-scanning UCLASS_BLK devices and removing/adding efi disks if 
> >>> necessary.
> >>> 
> >>> For example,
> >>> 
> >>> => efishell devices
> >>> Scanning disk pci_mmc.blk...
> >>> Found 3 disks
> >>> Device Name
> >>> 
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> >>> => usb start
> >>> starting USB...
> >>> USB0:   USB EHCI 1.00
> >>> scanning bus 0 for devices... 3 USB Device(s) found
> >>>  scanning usb for storage devices... 1 Storage Device(s) found
> >>> => efishell devices
> >>> Scanning disk usb_mass_storage.lun0...
> >>> Device Name
> >>> 
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
> >>> 
> >>> Without this patch, the last device, USB mass storage, won't show 
> >>> up.
> >>> 
> >>> [1] 
> >>> https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> >>> 
> >>> Signed-off-by: AKASHI Takahiro 
> >> 
> >> Why should we try to fix something in the EFI subsystems that goes 
> >> wrong
> >> in the handling of device enumeration.
> > 
> > No.
> > This is a natural result from how efi disks are currently 
> > implemented on u-boot.
> > Do you want to totally re-write/re-implement efi disks?
>  
>  Could we just make this event based for now? Call a hook from the
>  storage dm subsystem when a new u-boot block device gets created to
>  issue a sync of that in the efi subsystem?
> >>> 
> >>> If I correctly understand you, your suggestion here corresponds
> >>> with my proposal#3 in [1] while my current approach is #2.
> >>> 
> >>> [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> >> 
> >> Yes, I think so.
> >> 
> >>> So we will call, say, efi_disk_create(struct udevice *) in
> >>> blk_create_device() and efi_dsik_delete() in blk_unbind_all().
> >> 
> >> I would prefer if we didn't call them directly, but through an event
> >> mechanism. So the efi_disk subsystem registers an event with the dm
> >> block subsystem and that will just call all events when block devices
> >> get created which will automatically also include the efi disk creation
> >> callback. Same for reverse.
> > 
> > Do you mean efi event by "event?"
> > (I don't think there is any generic event interface on DM side.)
> > 
> > Whatever an "event" is or whether we call efi_disk_create() directly
> > or 

[U-Boot] [PATCH] common: Kconfig: miscellaneous spelling fixes

[Chris Packham]

Signed-off-by: Chris Packham 
---

 common/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 57bd16d9623c..2c017df4087c 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -308,7 +308,7 @@ config SILENT_CONSOLE
help
  This option allows the console to be silenced, meaning that no
  output will appear on the console devices. This is controlled by
- setting the environment vaariable 'silent' to a non-empty value.
+ setting the environment variable 'silent' to a non-empty value.
  Note this also silences the console when booting Linux.
 
  When the console is set up, the variable is checked, and the
@@ -430,7 +430,7 @@ config SYS_CONSOLE_INFO_QUIET
help
  Normally U-Boot displays the current settings for stdout, stdin
  and stderr on boot when the post-relocation console is set up.
- Enable this option to supress this output. It can be obtained by
+ Enable this option to suppress this output. It can be obtained by
  calling stdio_print_current_devices() from board code.
 
 config SYS_STDIO_DEREGISTER
@@ -565,14 +565,14 @@ config LOG_TEST
  This enables a 'log test' command to test logging. It is normally
  executed from a pytest and simply outputs logging information
  in various different ways to test that the logging system works
- correctly with varoius settings.
+ correctly with various settings.
 
 config LOG_ERROR_RETURN
bool "Log all functions which return an error"
depends on LOG
help
  When an error is returned in U-Boot it is sometimes difficult to
- figure out the root cause. For eaxmple, reading from SPI flash may
+ figure out the root cause. For example, reading from SPI flash may
  fail due to a problem in the SPI controller or due to the flash part
  not returning the expected information. This option changes
  log_ret() to log any errors it sees. With this option disabled,
@@ -661,7 +661,7 @@ config ARCH_MISC_INIT
  With this option U-Boot will call arch_misc_init() after
  relocation to allow miscellaneous arch-dependent initialisation
  to be performed. This function should be defined by the board
- and will be called after the console is set up, after relocaiton.
+ and will be called after the console is set up, after relocation.
 
 config BOARD_EARLY_INIT_F
bool "Call board-specific init before relocation"
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/3] sunxi: H6: use writel_relaxed for DRAM timing register accesses

[Andre Przywara]

The timing registers in the DRAM controller can be programmed in any
order, as they will only take effect once the controller is eventually
"activated".

Switch the MMIO writes in mctl_set_timing_lpddr3() over to use
writel_relaxed(), since we don't need the stronger guarantee of the
normal writel(). We satisfy the overall ordering requirement by ending
the function with an explicit DMB barrier.

In this case we are not interested in the performance benefit this
usually gives, but in the saved instructions, which sum up for the many
writes we have in the timing setup.
Due to alignment effects this shrinks our chronically tight H6 SPL by a
whopping 2KB, which brings it in the same region as for the other
AArch64 Allwinner SPL builds.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/dram_sun50i_h6.c | 79 +++-
 1 file changed, 42 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index 5da90a2835..84a33a63d6 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -241,51 +241,55 @@ static void mctl_set_timing_lpddr3(struct dram_para *para)
memcpy(mctl_phy->mr, mr_lpddr3, sizeof(mr_lpddr3));
 
/* set DRAM timing */
-   writel((twtp << 24) | (tfaw << 16) | (trasmax << 8) | tras,
-  _ctl->dramtmg[0]);
-   writel((txp << 16) | (trtp << 8) | trc, _ctl->dramtmg[1]);
-   writel((tcwl << 24) | (tcl << 16) | (trd2wr << 8) | twr2rd,
-  _ctl->dramtmg[2]);
-   writel((tmrw << 20) | (tmrd << 12) | tmod, _ctl->dramtmg[3]);
-   writel((trcd << 24) | (tccd << 16) | (trrd << 8) | trp,
-  _ctl->dramtmg[4]);
-   writel((tcksrx << 24) | (tcksre << 16) | (tckesr << 8) | tcke,
-  _ctl->dramtmg[5]);
+   writel_relaxed((twtp << 24) | (tfaw << 16) | (trasmax << 8) | tras,
+  _ctl->dramtmg[0]);
+   writel_relaxed((txp << 16) | (trtp << 8) | trc, _ctl->dramtmg[1]);
+   writel_relaxed((tcwl << 24) | (tcl << 16) | (trd2wr << 8) | twr2rd,
+  _ctl->dramtmg[2]);
+   writel_relaxed((tmrw << 20) | (tmrd << 12) | tmod,
+  _ctl->dramtmg[3]);
+   writel_relaxed((trcd << 24) | (tccd << 16) | (trrd << 8) | trp,
+  _ctl->dramtmg[4]);
+   writel_relaxed((tcksrx << 24) | (tcksre << 16) | (tckesr << 8) | tcke,
+  _ctl->dramtmg[5]);
/* Value suggested by ZynqMP manual and used by libdram */
-   writel((txp + 2) | 0x0202, _ctl->dramtmg[6]);
-   writel((txsfast << 24) | (txsabort << 16) | (txsdll << 8) | txs,
-  _ctl->dramtmg[8]);
-   writel(txsr, _ctl->dramtmg[14]);
+   writel_relaxed((txp + 2) | 0x0202, _ctl->dramtmg[6]);
+   writel_relaxed((txsfast << 24) | (txsabort << 16) | (txsdll << 8) | txs,
+  _ctl->dramtmg[8]);
+   writel_relaxed(txsr, _ctl->dramtmg[14]);
 
clrsetbits_le32(_ctl->init[0], (3 << 30), (1 << 30));
-   writel(0, _ctl->dfimisc);
+   writel_relaxed(0, _ctl->dfimisc);
clrsetbits_le32(_ctl->rankctl, 0xff0, 0x660);
 
/*
 * Set timing registers of the PHY.
 * Note: the PHY is clocked 2x from the DRAM frequency.
 */
-   writel((trrd << 25) | (tras << 17) | (trp << 9) | (trtp << 1),
+   writel_relaxed((trrd << 25) | (tras << 17) | (trp << 9) | (trtp << 1),
   _phy->dtpr[0]);
-   writel((tfaw << 17) | 0x28000400 | (tmrd << 1), _phy->dtpr[1]);
-   writel(((txs << 6) - 1) | (tcke << 17), _phy->dtpr[2]);
-   writel(((txsdll << 22) - (0x1 << 16)) | twtr_sa | (tcksrea << 8),
-  _phy->dtpr[3]);
-   writel((txp << 1) | (trfc << 17) | 0x800, _phy->dtpr[4]);
-   writel((trc << 17) | (trcd << 9) | (twtr << 1), _phy->dtpr[5]);
-   writel(0x0505, _phy->dtpr[6]);
+   writel_relaxed((tfaw << 17) | 0x28000400 | (tmrd << 1),
+  _phy->dtpr[1]);
+   writel_relaxed(((txs << 6) - 1) | (tcke << 17), _phy->dtpr[2]);
+   writel_relaxed(((txsdll << 22) - (0x1 << 16)) | twtr_sa |
+  (tcksrea << 8), _phy->dtpr[3]);
+   writel_relaxed((txp << 1) | (trfc << 17) | 0x800, _phy->dtpr[4]);
+   writel_relaxed((trc << 17) | (trcd << 9) | (twtr << 1),
+  _phy->dtpr[5]);
+   writel_relaxed(0x0505, _phy->dtpr[6]);
 
/* Configure DFI timing */
-   writel(tcl | 0x2000200 | (t_rdata_en << 16) | 0x808000,
-  _ctl->dfitmg0);
-   writel(0x040201, _ctl->dfitmg1);
+   writel_relaxed(tcl | 0x2000200 | (t_rdata_en << 16) | 0x808000,
+  _ctl->dfitmg0);
+   writel_relaxed(0x040201, _ctl->dfitmg1);
 
/* Configure PHY timing */
-   writel(tdinit0 | (tdinit1 << 20), _phy->ptr[3]);
-   writel(tdinit2 | (tdinit3 << 18), _phy->ptr[4]);
+   writel_relaxed(tdinit0 | (tdinit1 << 20), _phy->ptr[3]);
+ 

[U-Boot] [PATCH 2/3] arm: introduce _relaxed MMIO accessors

[Andre Przywara]

The normal MMIO accessor macros (readX/writeX) guarantee a strong ordering,
even with normal memory accesses [1].
For some MMIO operations (framebuffers being a prominent example) this is
not needed, and the rather costly barrier inserted on weakly ordered
systems like ARM costs some performance.
To mitigate this issue, Linux introduced readX_relaxed and
writeX_relaxed primitives, which only guarantee ordering between each
other, so are typically faster due to the missing barrier.

We probably do not care so much about performance in U-Boot, but want to
have those primitives for two other reasons:
- Being able to use the _relaxed macros simplifies porting drivers from
  Linux.
- The missing barrier typically allows to generate smaller code, which can
  relieve some chronically tight SPL builds.

Add those macros definitions by using the __raw versions of the
accessors, which matches an earlier (and less complicated) version of
the Linux implementation.

[1] https://lwn.net/Articles/698014/
---
 arch/arm/include/asm/io.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index bcbaf0d83c..5b24b88efc 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -98,11 +98,21 @@ static inline void __raw_readsl(unsigned long addr, void 
*data, int longlen)
 #define writel(v,c)({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
 #define writeq(v,c)({ u64 __v = v; __iowmb(); __arch_putq(__v,c); __v; })
 
+#define writeb_relaxed(v,c)__raw_writeb(v, c)
+#define writew_relaxed(v,c)__raw_writew(v, c)
+#define writel_relaxed(v,c)__raw_writel(v, c)
+#define writeq_relaxed(v,c)__raw_writeq(v, c)
+
 #define readb(c)   ({ u8  __v = __arch_getb(c); __iormb(); __v; })
 #define readw(c)   ({ u16 __v = __arch_getw(c); __iormb(); __v; })
 #define readl(c)   ({ u32 __v = __arch_getl(c); __iormb(); __v; })
 #define readq(c)   ({ u64 __v = __arch_getq(c); __iormb(); __v; })
 
+#define readb_relaxed(c)   __raw_readb(c)
+#define readw_relaxed(c)   __raw_readw(c)
+#define readl_relaxed(c)   __raw_readl(c)
+#define readq_relaxed(c)   __raw_readq(c)
+
 /*
  * The compiler seems to be incapable of optimising constants
  * properly.  Spell it out to the compiler in some cases.
-- 
2.14.5

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] arm: clean up asm/io.h

[Andre Przywara]

asm/io.h is the header file containing the central MMIO accessor macros.
Judging by the header and the comments, it was apparently once copied
from the Linux kernel, but has deviated since then heavily.

Clean up the definitions by:
- removing pointless Linux history
- removing commented code
- removing outdated comments
- removing unused definitions, for instance for mem_isa and mem_pci

This massively improves the readability of the file.

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/io.h | 154 +-
 1 file changed, 2 insertions(+), 152 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 12bc7fbe06..bcbaf0d83c 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -1,44 +1,25 @@
 /*
- *  linux/include/asm-arm/io.h
+ * I/O device access primitives. Based on early versions from the Linux kernel.
  *
  *  Copyright (C) 1996-2000 Russell King
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- *
- * Modifications:
- *  16-Sep-1996RMK Inlined the inx/outx functions & optimised for 
both
- * constant addresses and variable addresses.
- *  04-Dec-1997RMK Moved a lot of this stuff to the new 
architecture
- * specific IO header files.
- *  27-Mar-1999PJB Second parameter of memcpy_toio is const..
- *  04-Apr-1999PJB Added check_signature.
- *  12-Dec-1999RMK More cleanups
- *  18-Jun-2000 RMKRemoved virt_to_* and friends definitions
  */
 #ifndef __ASM_ARM_IO_H
 #define __ASM_ARM_IO_H
 
-#ifdef __KERNEL__
-
 #include 
 #include 
 #include 
 #include 
-#if 0  /* XXX###XXX */
-#include 
-#endif /* XXX###XXX */
 
 static inline void sync(void)
 {
 }
 
-/*
- * Generic virtual read/write.  Note that we don't support half-word
- * read/writes.  We define __arch_*[bl] here, and leave __arch_*w
- * to the architecture specific code.
- */
+/* Generic virtual read/write. */
 #define __arch_getb(a) (*(volatile unsigned char *)(a))
 #define __arch_getw(a) (*(volatile unsigned short *)(a))
 #define __arch_getl(a) (*(volatile unsigned int *)(a))
@@ -205,13 +186,6 @@ static inline void __raw_readsl(unsigned long addr, void 
*data, int longlen)
 #define setbits_8(addr, set) setbits(8, addr, set)
 #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
 
-/*
- * Now, pick up the machine-defined IO definitions
- */
-#if 0  /* XXX###XXX */
-#include 
-#endif /* XXX###XXX */
-
 /*
  *  IO port access primitives
  *  -
@@ -275,16 +249,6 @@ static inline void __raw_readsl(unsigned long addr, void 
*data, int longlen)
 #define writesb(a, d, s)   __raw_writesb((unsigned long)a, d, s)
 #define readsb(a, d, s)__raw_readsb((unsigned long)a, d, s)
 
-/*
- * DMA-consistent mapping functions.  These allocate/free a region of
- * uncached, unwrite-buffered mapped memory space for use with DMA
- * devices.  This is the "generic" version.  The PCI specific version
- * is in pci.h
- */
-extern void *consistent_alloc(int gfp, size_t size, dma_addr_t *handle);
-extern void consistent_free(void *vaddr, size_t size, dma_addr_t handle);
-extern void consistent_sync(void *vaddr, size_t size, int rw);
-
 /*
  * String version of IO memory access ops:
  */
@@ -292,124 +256,10 @@ extern void _memcpy_fromio(void *, unsigned long, 
size_t);
 extern void _memcpy_toio(unsigned long, const void *, size_t);
 extern void _memset_io(unsigned long, int, size_t);
 
-extern void __readwrite_bug(const char *fn);
-
-/*
- * If this architecture has PCI memory IO, then define the read/write
- * macros.  These should only be used with the cookie passed from
- * ioremap.
- */
-#ifdef __mem_pci
-
-#define readb(c) ({ unsigned int __v = __raw_readb(__mem_pci(c)); __v; })
-#define readw(c) ({ unsigned int __v = le16_to_cpu(__raw_readw(__mem_pci(c))); 
__v; })
-#define readl(c) ({ unsigned int __v = le32_to_cpu(__raw_readl(__mem_pci(c))); 
__v; })
-
-#define writeb(v,c)__raw_writeb(v,__mem_pci(c))
-#define writew(v,c)__raw_writew(cpu_to_le16(v),__mem_pci(c))
-#define writel(v,c)__raw_writel(cpu_to_le32(v),__mem_pci(c))
-
-#define memset_io(c,v,l)   _memset_io(__mem_pci(c),(v),(l))
-#define memcpy_fromio(a,c,l)   _memcpy_fromio((a),__mem_pci(c),(l))
-#define memcpy_toio(c,a,l) _memcpy_toio(__mem_pci(c),(a),(l))
-
-#define eth_io_copy_and_sum(s,c,l,b) \
-   eth_copy_and_sum((s),__mem_pci(c),(l),(b))
-
-static inline int
-check_signature(unsigned long io_addr, const unsigned char *signature,
-   int length)
-{
-   int retval = 0;
-   do {
-   if (readb(io_addr) != *signature)
- 

[U-Boot] [PATCH 0/3] arm: Introduce writel/readl_relaxed accessors

[Andre Przywara]

Admittedly this is the long way round to solve some nasty SPL code size
problem, but it looked beneficial to others as well, so here we go:

arch/arm/include/asm/io.h looks like it's been around since the dawn of
time, and was more or less blindly copied from Linux.
We don't use and don't need most of the definitions, and mainline Linux
got rid of them anyway, so patch 1/3 cleans up this header file to
just contain what we need in U-Boot.

Patch 2/3 introduces readl/writel_relaxed accessors, which are cheaper,
but more importantly save one (barrier) instruction per accessor. This
helps to bring down code size, since especially DRAM controller inits in
SPLs tend to do a lot of MMIO.

Consequently patch 3/3 introduces them in the Allwinner H6 DRAM driver,
which reduces the SPL size by a whopping 2KB, due to a twist:
The AArch64 exception table needs to be 2KB aligned, but we don't do
anything special about it the linker script. So depending on where the
code before the vectors ends, we have potentially large padding:
At the moment this last address is 0x1824 for the H6, so the vectors can
only start at 0x2000. By reducing the code size before the vectors by just 
(at least) 9 instructions, the vectors start at 0x1800 and we save most of
the padding.

I understand that the proper solution is to fill the gap before the vectors
with code instead of NOPs, but I couldn't find any obvious way doing this
in the linker script. If anyone has any idea here, I am all ears.

Cheers,
Andre.

Andre Przywara (3):
  arm: clean up asm/io.h
  arm: introduce _relaxed MMIO accessors
  sunxi: H6: use writel_relaxed for DRAM timing register accesses

 arch/arm/include/asm/io.h| 164 +++
 arch/arm/mach-sunxi/dram_sun50i_h6.c |  79 +
 2 files changed, 54 insertions(+), 189 deletions(-)

-- 
2.14.5

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 15/20] sunxi: Enable CLK

[André Przywara]

On 10/01/2019 18:40, Jagan Teki wrote:
> CLK and DM_RESET drivers are now available for most
> of the Allwinner platforms, so enable in mach-sunxi/Kconfig
> 
> Enabling CLK will select DM_RESET by default.

Shame we don't have the new A80 DTs in our tree, otherwise we would have
got away with a one-liner instead ...

> Signed-off-by: Jagan Teki 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  arch/arm/mach-sunxi/Kconfig | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 3c54f5106d..5f51bbbed0 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -132,6 +132,7 @@ endif
>  
>  config MACH_SUNXI_H3_H5
>   bool
> + select CLK
>   select DM_I2C
>   select PHY_SUN4I_USB
>   select SUNXI_DE2
> @@ -154,6 +155,7 @@ config MACH_SUN4I
>   bool "sun4i (Allwinner A10)"
>   select CPU_V7A
>   select ARM_CORTEX_CPU_IS_UP
> + select CLK
>   select DM_MMC if MMC
>   select DM_SCSI if SCSI
>   select PHY_SUN4I_USB
> @@ -165,6 +167,7 @@ config MACH_SUN5I
>   bool "sun5i (Allwinner A13)"
>   select CPU_V7A
>   select ARM_CORTEX_CPU_IS_UP
> + select CLK
>   select DRAM_SUN4I
>   select PHY_SUN4I_USB
>   select SUNXI_GEN_SUN4I
> @@ -177,6 +180,7 @@ config MACH_SUN6I
>   select CPU_V7_HAS_NONSEC
>   select CPU_V7_HAS_VIRT
>   select ARCH_SUPPORT_PSCI
> + select CLK
>   select DRAM_SUN6I
>   select PHY_SUN4I_USB
>   select SUN6I_P2WI
> @@ -191,6 +195,7 @@ config MACH_SUN7I
>   select CPU_V7_HAS_NONSEC
>   select CPU_V7_HAS_VIRT
>   select ARCH_SUPPORT_PSCI
> + select CLK
>   select DRAM_SUN4I
>   select PHY_SUN4I_USB
>   select SUNXI_GEN_SUN4I
> @@ -203,6 +208,7 @@ config MACH_SUN8I_A23
>   select CPU_V7_HAS_NONSEC
>   select CPU_V7_HAS_VIRT
>   select ARCH_SUPPORT_PSCI
> + select CLK
>   select DRAM_SUN8I_A23
>   select PHY_SUN4I_USB
>   select SUNXI_GEN_SUN6I
> @@ -216,6 +222,7 @@ config MACH_SUN8I_A33
>   select CPU_V7_HAS_NONSEC
>   select CPU_V7_HAS_VIRT
>   select ARCH_SUPPORT_PSCI
> + select CLK
>   select DRAM_SUN8I_A33
>   select PHY_SUN4I_USB
>   select SUNXI_GEN_SUN6I
> @@ -226,6 +233,7 @@ config MACH_SUN8I_A33
>  config MACH_SUN8I_A83T
>   bool "sun8i (Allwinner A83T)"
>   select CPU_V7A
> + select CLK
>   select DRAM_SUN8I_A83T
>   select PHY_SUN4I_USB
>   select SUNXI_GEN_SUN6I
> @@ -248,6 +256,7 @@ config MACH_SUN8I_R40
>   select CPU_V7_HAS_NONSEC
>   select CPU_V7_HAS_VIRT
>   select ARCH_SUPPORT_PSCI
> + select CLK
>   select SUNXI_GEN_SUN6I
>   select SUPPORT_SPL
>   select SUNXI_DRAM_DW
> @@ -259,6 +268,7 @@ config MACH_SUN8I_V3S
>   select CPU_V7_HAS_NONSEC
>   select CPU_V7_HAS_VIRT
>   select ARCH_SUPPORT_PSCI
> + select CLK
>   select SUNXI_GEN_SUN6I
>   select SUNXI_DRAM_DW
>   select SUNXI_DRAM_DW_16BIT
> @@ -277,6 +287,7 @@ config MACH_SUN9I
>  config MACH_SUN50I
>   bool "sun50i (Allwinner A64)"
>   select ARM64
> + select CLK
>   select DM_I2C
>   select PHY_SUN4I_USB
>   select SUN6I_PRCM
> @@ -300,6 +311,7 @@ config MACH_SUN50I_H5
>  config MACH_SUN50I_H6
>   bool "sun50i (Allwinner H6)"
>   select ARM64
> + select CLK
>   select SUPPORT_SPL
>   select FIT
>   select SPL_LOAD_FIT
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 14/20] sunxi: A64: Update sun50i-a64-ccu.h

[André Przywara]

On 10/01/2019 18:40, Jagan Teki wrote:
> Update sun50i-a64-ccu.h from the Linux sunxi/dt64-for-4.20 tree:
> commit 679294497be31596e1c9c61507746d72b6b05f26
> Author: Rodrigo Exterckötter Tjäder 
> Date:   Wed Sep 26 19:48:24 2018 +
> arm64: dts: allwinner: a64: a64-olinuxino: set the PHY TX delay
> 
> This should be a part of previous sync patch from
> commit 1b39a1834ed182bbd8036a5cd74a9ea111fa4691
> Author: Andre Przywara 
> Date:   Mon Oct 29 00:56:47 2018 +
> 
> sunxi: A64: Update .dts/.dtsi files
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  include/dt-bindings/clock/sun50i-a64-ccu.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/dt-bindings/clock/sun50i-a64-ccu.h 
> b/include/dt-bindings/clock/sun50i-a64-ccu.h
> index 370c0a0473..d66432c6e6 100644
> --- a/include/dt-bindings/clock/sun50i-a64-ccu.h
> +++ b/include/dt-bindings/clock/sun50i-a64-ccu.h
> @@ -43,6 +43,8 @@
>  #ifndef _DT_BINDINGS_CLK_SUN50I_A64_H_
>  #define _DT_BINDINGS_CLK_SUN50I_A64_H_
>  
> +#define CLK_PLL_PERIPH0  11
> +
>  #define CLK_BUS_MIPI_DSI 28
>  #define CLK_BUS_CE   29
>  #define CLK_BUS_DMA  30
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 13/20] clk: sunxi: Add Allwinner H6 CLK driver

[André Przywara]

On 10/01/2019 18:40, Jagan Teki wrote:
> Add initial clock driver for Allwinner H6.
> 
> - Implement UART bus clocks via ccu_clk_gate table for
>   H6, so it can accessed in common clk enable and disable
>   functions from clk_sunxi.c
> - Implement UART bus resets via ccu_reset table for H6,
>   so it can accessed in common reset deassert and assert
>   functions from reset-sunxi.c
> 
> Signed-off-by: Jagan Teki 

Compared against the manual, boot tested on Pine H64.

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  drivers/clk/sunxi/Kconfig  |  7 +
>  drivers/clk/sunxi/Makefile |  1 +
>  drivers/clk/sunxi/clk_h6.c | 53 ++
>  3 files changed, 61 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk_h6.c
> 
> diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
> index a6f84e9e56..cb11c7c21e 100644
> --- a/drivers/clk/sunxi/Kconfig
> +++ b/drivers/clk/sunxi/Kconfig
> @@ -65,6 +65,13 @@ config CLK_SUN8I_H3
> This enables common clock driver support for platforms based
> on Allwinner H3/H5 SoC.
>  
> +config CLK_SUN50I_H6
> + bool "Clock driver for Allwinner H6"
> + default MACH_SUN50I_H6
> + help
> +   This enables common clock driver support for platforms based
> +   on Allwinner H6 SoC.
> +
>  config CLK_SUN50I_A64
>   bool "Clock driver for Allwinner A64"
>   default MACH_SUN50I
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index fbd43527a6..794aa2461c 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -14,4 +14,5 @@ obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
>  obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
>  obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
>  obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
> +obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
>  obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
> diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c
> new file mode 100644
> index 00..0da3a40e3d
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk_h6.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2018 Amarula Solutions.
> + * Author: Jagan Teki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct ccu_clk_gate h6_gates[] = {
> + [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
> + [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
> + [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
> + [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
> +};
> +
> +static struct ccu_reset h6_resets[] = {
> + [RST_BUS_UART0] = RESET(0x90c, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x90c, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x90c, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x90c, BIT(19)),
> +};
> +
> +static const struct ccu_desc h6_ccu_desc = {
> + .gates = h6_gates,
> + .resets = h6_resets,
> +};
> +
> +static int h6_clk_bind(struct udevice *dev)
> +{
> + return sunxi_reset_bind(dev, ARRAY_SIZE(h6_resets));
> +}
> +
> +static const struct udevice_id h6_ccu_ids[] = {
> + { .compatible = "allwinner,sun50i-h6-ccu",
> +   .data = (ulong)_ccu_desc },
> + { }
> +};
> +
> +U_BOOT_DRIVER(clk_sun50i_h6) = {
> + .name   = "sun50i_h6_ccu",
> + .id = UCLASS_CLK,
> + .of_match   = h6_ccu_ids,
> + .priv_auto_alloc_size   = sizeof(struct ccu_priv),
> + .ops= _clk_ops,
> + .probe  = sunxi_clk_probe,
> + .bind   = h6_clk_bind,
> +};
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-sunxi/master

[Tom Rini]

On Thu, Jan 10, 2019 at 02:50:53PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this fix for the release v2019.01
> 
> Sorry for last minute trouble.
> 
> thanks,
> Jagan.
> 
> The following changes since commit 54707a942009fae083dd78b58ff057127ba0e900:
> 
>   Prepare v2019.01-rc3 (2019-01-07 22:58:17 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to e8f37f4203983f75cadd857c9c7e6d6477bf3e54:
> 
>   mmc: sunxi: Fix mmc clocks for DM_MMC (2019-01-10 14:45:15 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx u -boot-imx-20190110

[Tom Rini]

On Thu, Jan 10, 2019 at 09:06:52AM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> some fixes for 2019.01.
> Tag: u -boot-imx-20190110
> Travis: https://travis-ci.org/sbabic/u-boot-imx
> 
> The following changes since commit 54707a942009fae083dd78b58ff057127ba0e900:
> 
>   Prepare v2019.01-rc3 (2019-01-07 22:58:17 -0500)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git tags/u-boot-imx-20190110
> 
> for you to fetch changes up to d4a0c098925d4594355506a12ae0dbbe6eed00f2:
> 
>   imx8m: clock: Fix oscillator values (2019-01-09 17:10:30 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v6 11/20] clk: sunxi: Implement UART clocks

[André Przywara]

On 10/01/2019 18:40, Jagan Teki wrote:
> Implement UART clocks for all Allwinner SoC
> clock drivers via ccu clock gate table.
> 
> Signed-off-by: Jagan Teki 

Compared against each manual:

Reviewed-by: Andre Przywara 

Thanks,
Andre

> ---
>  drivers/clk/sunxi/clk_a10.c  | 9 +
>  drivers/clk/sunxi/clk_a10s.c | 5 +
>  drivers/clk/sunxi/clk_a23.c  | 6 ++
>  drivers/clk/sunxi/clk_a31.c  | 7 +++
>  drivers/clk/sunxi/clk_a64.c  | 6 ++
>  drivers/clk/sunxi/clk_a83t.c | 6 ++
>  drivers/clk/sunxi/clk_h3.c   | 5 +
>  drivers/clk/sunxi/clk_r40.c  | 9 +
>  drivers/clk/sunxi/clk_v3s.c  | 4 
>  9 files changed, 57 insertions(+)
> 
> diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
> index a8a7b7d41e..b00f51af8b 100644
> --- a/drivers/clk/sunxi/clk_a10.c
> +++ b/drivers/clk/sunxi/clk_a10.c
> @@ -19,6 +19,15 @@ static struct ccu_clk_gate a10_gates[] = {
>   [CLK_AHB_EHCI1] = GATE(0x060, BIT(3)),
>   [CLK_AHB_OHCI1] = GATE(0x060, BIT(4)),
>  
> + [CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
> + [CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
> + [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
> + [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
> + [CLK_APB1_UART4]= GATE(0x06c, BIT(20)),
> + [CLK_APB1_UART5]= GATE(0x06c, BIT(21)),
> + [CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
> + [CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
> +
>   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
>   [CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
>   [CLK_USB_PHY]   = GATE(0x0cc, BIT(8)),
> diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
> index bf91018fc2..aa904ce067 100644
> --- a/drivers/clk/sunxi/clk_a10s.c
> +++ b/drivers/clk/sunxi/clk_a10s.c
> @@ -17,6 +17,11 @@ static struct ccu_clk_gate a10s_gates[] = {
>   [CLK_AHB_EHCI]  = GATE(0x060, BIT(1)),
>   [CLK_AHB_OHCI]  = GATE(0x060, BIT(2)),
>  
> + [CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
> + [CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
> + [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
> + [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
> +
>   [CLK_USB_OHCI]  = GATE(0x0cc, BIT(6)),
>   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
> diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
> index 2a504ebdad..ebe8d0002c 100644
> --- a/drivers/clk/sunxi/clk_a23.c
> +++ b/drivers/clk/sunxi/clk_a23.c
> @@ -17,6 +17,12 @@ static struct ccu_clk_gate a23_gates[] = {
>   [CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
>   [CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
>  
> + [CLK_BUS_UART0] = GATE(0x06c, BIT(16)),
> + [CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
> + [CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
> + [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
> + [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
> +
>   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
>   [CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
> diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
> index 723d17dff2..145df5c19f 100644
> --- a/drivers/clk/sunxi/clk_a31.c
> +++ b/drivers/clk/sunxi/clk_a31.c
> @@ -20,6 +20,13 @@ static struct ccu_clk_gate a31_gates[] = {
>   [CLK_AHB1_OHCI1]= GATE(0x060, BIT(30)),
>   [CLK_AHB1_OHCI2]= GATE(0x060, BIT(31)),
>  
> + [CLK_APB2_UART0]= GATE(0x06c, BIT(16)),
> + [CLK_APB2_UART1]= GATE(0x06c, BIT(17)),
> + [CLK_APB2_UART2]= GATE(0x06c, BIT(18)),
> + [CLK_APB2_UART3]= GATE(0x06c, BIT(19)),
> + [CLK_APB2_UART4]= GATE(0x06c, BIT(20)),
> + [CLK_APB2_UART5]= GATE(0x06c, BIT(21)),
> +
>   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
>   [CLK_USB_PHY2]  = GATE(0x0cc, BIT(10)),
> diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
> index eb0a45d97f..63424a9e2d 100644
> --- a/drivers/clk/sunxi/clk_a64.c
> +++ b/drivers/clk/sunxi/clk_a64.c
> @@ -19,6 +19,12 @@ static const struct ccu_clk_gate a64_gates[] = {
>   [CLK_BUS_OHCI0] = GATE(0x060, BIT(28)),
>   [CLK_BUS_OHCI1] = GATE(0x060, BIT(29)),
>  
> + [CLK_BUS_UART0] = GATE(0x06c, BIT(16)),
> + [CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
> + [CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
> + [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
> + [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
> +
>   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
>   [CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
> diff --git a/drivers/clk/sunxi/clk_a83t.c b/drivers/clk/sunxi/clk_a83t.c
> index 

Re: [U-Boot] [PATCH v6 12/20] clk: sunxi: Implement UART resets

[André Przywara]

On 10/01/2019 18:40, Jagan Teki wrote:
> Implement UART resets for all relevant Allwinner SoC
> clock drivers via ccu reset table.
> 
> Signed-off-by: Jagan Teki 

Compared against each manual:

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  drivers/clk/sunxi/clk_a23.c  | 6 ++
>  drivers/clk/sunxi/clk_a31.c  | 7 +++
>  drivers/clk/sunxi/clk_a64.c  | 6 ++
>  drivers/clk/sunxi/clk_a83t.c | 6 ++
>  drivers/clk/sunxi/clk_h3.c   | 5 +
>  drivers/clk/sunxi/clk_r40.c  | 9 +
>  drivers/clk/sunxi/clk_v3s.c  | 4 
>  7 files changed, 43 insertions(+)
> 
> diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
> index ebe8d0002c..854259bf81 100644
> --- a/drivers/clk/sunxi/clk_a23.c
> +++ b/drivers/clk/sunxi/clk_a23.c
> @@ -38,6 +38,12 @@ static struct ccu_reset a23_resets[] = {
>   [RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
>   [RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
>   [RST_BUS_OHCI]  = RESET(0x2c0, BIT(29)),
> +
> + [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
> + [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
>  };
>  
>  static const struct ccu_desc a23_ccu_desc = {
> diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
> index 145df5c19f..a38d76cb7c 100644
> --- a/drivers/clk/sunxi/clk_a31.c
> +++ b/drivers/clk/sunxi/clk_a31.c
> @@ -46,6 +46,13 @@ static struct ccu_reset a31_resets[] = {
>   [RST_AHB1_OHCI0]= RESET(0x2c0, BIT(29)),
>   [RST_AHB1_OHCI1]= RESET(0x2c0, BIT(30)),
>   [RST_AHB1_OHCI2]= RESET(0x2c0, BIT(31)),
> +
> + [RST_APB2_UART0]= RESET(0x2d8, BIT(16)),
> + [RST_APB2_UART1]= RESET(0x2d8, BIT(17)),
> + [RST_APB2_UART2]= RESET(0x2d8, BIT(18)),
> + [RST_APB2_UART3]= RESET(0x2d8, BIT(19)),
> + [RST_APB2_UART4]= RESET(0x2d8, BIT(20)),
> + [RST_APB2_UART5]= RESET(0x2d8, BIT(21)),
>  };
>  
>  static const struct ccu_desc a31_ccu_desc = {
> diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
> index 63424a9e2d..a2ba6eefc5 100644
> --- a/drivers/clk/sunxi/clk_a64.c
> +++ b/drivers/clk/sunxi/clk_a64.c
> @@ -43,6 +43,12 @@ static const struct ccu_reset a64_resets[] = {
>   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(25)),
>   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
>   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
> +
> + [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
> + [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
>  };
>  
>  static const struct ccu_desc a64_ccu_desc = {
> diff --git a/drivers/clk/sunxi/clk_a83t.c b/drivers/clk/sunxi/clk_a83t.c
> index 76099fd154..1ef6ac5b25 100644
> --- a/drivers/clk/sunxi/clk_a83t.c
> +++ b/drivers/clk/sunxi/clk_a83t.c
> @@ -40,6 +40,12 @@ static struct ccu_reset a83t_resets[] = {
>   [RST_BUS_EHCI0] = RESET(0x2c0, BIT(26)),
>   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(27)),
>   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(29)),
> +
> + [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
> + [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
>  };
>  
>  static const struct ccu_desc a83t_ccu_desc = {
> diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
> index 69c2aa34a3..f82949b3b6 100644
> --- a/drivers/clk/sunxi/clk_h3.c
> +++ b/drivers/clk/sunxi/clk_h3.c
> @@ -53,6 +53,11 @@ static struct ccu_reset h3_resets[] = {
>   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
>   [RST_BUS_OHCI2] = RESET(0x2c0, BIT(30)),
>   [RST_BUS_OHCI3] = RESET(0x2c0, BIT(31)),
> +
> + [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
> + [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
>  };
>  
>  static const struct ccu_desc h3_ccu_desc = {
> diff --git a/drivers/clk/sunxi/clk_r40.c b/drivers/clk/sunxi/clk_r40.c
> index 9a632b2603..fd7aae97ea 100644
> --- a/drivers/clk/sunxi/clk_r40.c
> +++ b/drivers/clk/sunxi/clk_r40.c
> @@ -50,6 +50,15 @@ static struct ccu_reset r40_resets[] = {
>   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(29)),
>   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(30)),
>   [RST_BUS_OHCI2] = RESET(0x2c0, BIT(31)),
> +
> + [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
> + [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
> + [RST_BUS_UART2] = RESET(0x2d8, 

Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Move ifdef to CONFIG_IS_ENABLED

[Lukasz Majewski]

Hi Adam,

> For some boards, DM_REGULATOR and DM_GPIO may not be enabled in
> SPL but enabled in U-Boot.  So switching to CONFIG_IS_ENABLED from
> ifdef allows the esdhc driver to function with some limited
> functionality in SPL.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 74007e2ad4..1faae1987a 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -1395,7 +1395,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
>   int node = dev_of_offset(dev);
>   struct esdhc_soc_data *data =
>   (struct esdhc_soc_data *)dev_get_driver_data(dev);
> -#ifdef CONFIG_DM_REGULATOR
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   struct udevice *vqmmc_dev;
>  #endif
>   fdt_addr_t addr;
> @@ -1436,7 +1436,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
>   priv->non_removable = 1;
>} else {
>   priv->non_removable = 0;
> -#ifdef CONFIG_DM_GPIO
> +#if CONFIG_IS_ENABLED(DM_GPIO)
>   gpio_request_by_name(dev, "cd-gpios", 0,
> >cd_gpio, GPIOD_IS_IN);
>  #endif
> @@ -1453,7 +1453,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
>  
>   priv->vs18_enable = 0;
>  
> -#ifdef CONFIG_DM_REGULATOR
> +#if CONFIG_IS_ENABLED(DM_REGULATOR)
>   /*
>* If emmc I/O has a fixed voltage at 1.8V, this must be
> provided,
>* otherwise, emmc will work abnormally.

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpppubh1Q2tL.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Tom,

On 10/01/19 16:12, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote:
>> Hi Tom,
>>
>> On 10/01/19 15:44, Tom Rini wrote:
>>> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
 Hi Tom, Soeren,

 On 09/01/19 23:39, Tom Rini wrote:
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>> Hi Soeren,
>>
>> On 08/01/19 12:03, Soeren Moch wrote:
>>> Hi Stefano,
>>>
>>> On 08.01.19 11:24, Stefano Babic wrote:
 Hi Soeren,

 On 08/01/19 11:14, Soeren Moch wrote:
> Stefano,
>
> can you apply this for v2019.01? This is really a important fix to 
> avoid
>  environment and u-boot binary overwriting each other.
> It is also a small local fix which cannot hurt anybody else.
 I will apply and I send a new PR. This is not the first fix in this
 direction, u-boot becomes pretty large, it is becoming a common 
 problem.

>>> Thank you very much.
>>>
>>> Yes, "in the good old days (tm)" there was much effort put into not
>>> increasing the binary size for existing boards when adding new features.
>>
>> Right, fully agree.
>>
>>> Unfortunately this is not true anymore.
>>
>> I get in the same trouble with more as one project. A previous rule of
>> thumb was to reserve 512KB to the bootloader because it was pretty
>> unthinkable that bootloader could be larger. Mhmmhhthis remember me
>> someone else who said that 640Kb is enough for everything.
>>
>> Anyway, as you noted, this is a big problem in field and it makes
>> difficult an upgrade without returning back the device to factory, what
>> nobody wants.
>
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.

 I am not sure if we should point to EFI as responsible for the increased
 footprint or it is due to the sum of several components / factors. I
 just report my experience in last month : I had to port U-Boot for a
 customer from a not very old release (2017.01) to the current. 2017.01
 had already (apart of FIT support) all features the customer needed, but
 there are issues(NAND, UBI) and I kew that they were solved later.
 Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
 a lot in board code, but of course I had to reconfigure a lot. At the
 end, everything worked but I was quite astonished about footprint. I had:

 2017.01u-boot.bin 443452
 2018.11 u-boot.bin 654684
 I'm splitting my reply here into two emails.  This here concerns the
>>> heck out of me.  But I don't see it on MPC8308RDB.  There I see:
>>>powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text 
>>> +6847.0
>>> MPC8308RDB : all -124241 bss -131040 data -48 text +6847
>>>u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 
>>> (-125646)
>>
>> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
>> it is not MPC8308RDB. But nevertheless, I could not understand the
>> difference is sitze.
> 
> Right, I understand, that's just the first MPC83xx board I spotted, and
> I wanted to see if all platforms had such unreasonable growth.  You're
> showing your custom platform went up by _200_ kilobytes.

I have found that one of the major reason is the different toolchain.
2018.11 was built with the toolchain requested by customer, it was gcc
6.4. I built 2017.01 with buildman and fetching the toolchain, that
means 7.3. The same U-Boot versione produces very different footprint,
much better with the newer toolchain. At least 50-60KB are due to the
toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more
code. But then, yes, I want to have them. So at the end, one big
responsible is the toolchain. So partially I am responsible for new
footprint (new features), the rest is done by toolchain.


> 
>>> And in terms of .bins:
>>> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 
>>> /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
>>> -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 
>>> /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
>>>
>>> I am doing all of mpc83xx now to see if something else trips such a
>>> large growth.
>>>
>>
>> I will do the same here on this board and try to understand where the
>> difference is coming from. I will report to you, then.
> 
> Thanks!
> 

Regards,
Stefano
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/2] x86: edison: Switch to CONFIG_OF_SEPARATE

[Ferry Toth]

Op 08-01-19 om 15:17 schreef Andy Shevchenko:

There is no need for Intel Edison to have CONFIG_OF_EMBED to be enabled.
Replace it with CONFIG_OF_SEPARATE.

There is no functional change since u-boot.bin always contains DTB
either embedded or attached.

Signed-off-by: Andy Shevchenko 

Tested-by: Ferry Toth 

---
  configs/edison_defconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/edison_defconfig b/configs/edison_defconfig
index e376c0cea6..dc7d86aafe 100644
--- a/configs/edison_defconfig
+++ b/configs/edison_defconfig
@@ -26,7 +26,7 @@ CONFIG_CMD_EXT4=y
  CONFIG_CMD_EXT4_WRITE=y
  CONFIG_CMD_FAT=y
  CONFIG_CMD_FS_GENERIC=y
-CONFIG_OF_EMBED=y
+CONFIG_OF_SEPARATE=y
  CONFIG_DEFAULT_DEVICE_TREE="edison"
  CONFIG_ENV_IS_IN_MMC=y
  CONFIG_CPU=y




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mmc: fsl_esdhc: Move ifdef to CONFIG_IS_ENABLED

[Adam Ford]

For some boards, DM_REGULATOR and DM_GPIO may not be enabled in
SPL but enabled in U-Boot.  So switching to CONFIG_IS_ENABLED from
ifdef allows the esdhc driver to function with some limited
functionality in SPL.

Signed-off-by: Adam Ford 

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 74007e2ad4..1faae1987a 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -1395,7 +1395,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
int node = dev_of_offset(dev);
struct esdhc_soc_data *data =
(struct esdhc_soc_data *)dev_get_driver_data(dev);
-#ifdef CONFIG_DM_REGULATOR
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
struct udevice *vqmmc_dev;
 #endif
fdt_addr_t addr;
@@ -1436,7 +1436,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
priv->non_removable = 1;
 } else {
priv->non_removable = 0;
-#ifdef CONFIG_DM_GPIO
+#if CONFIG_IS_ENABLED(DM_GPIO)
gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
 GPIOD_IS_IN);
 #endif
@@ -1453,7 +1453,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
 
priv->vs18_enable = 0;
 
-#ifdef CONFIG_DM_REGULATOR
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
/*
 * If emmc I/O has a fixed voltage at 1.8V, this must be provided,
 * otherwise, emmc will work abnormally.
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] arm: socfpga: gen5: remove hacked ETH RST handling

[Marek Vasut]

On 1/10/19 9:46 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 10. Jan. 2019, 21:40 hat Marek Vasut  > geschrieben:
> 
> On 1/10/19 8:49 PM, Simon Goldschmidt wrote:
> > The 'designware_socfpga' ETH driver can now get the MACs out of reset
> > via the socfpga reset driver and can set PHY mode via syscon.
> >
> > This means we can now remove the ad-hoc code to do this from
> > arch/arm/mach-socfpga.
> >
> > Signed-off-by: Simon Goldschmdit  >
> > Signed-off-by: Simon Goldschmidt  >
> 
> I very much like this patch, except for the dual SoB line.
> 
> 
> D'oh! The first one was may typo, the 2nd one was by patman.
> 
> Seems like I need a V2 anyway...

I usually use git commit -sm "stuff" or git commit --amend -s

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] arm: socfpga: gen5: remove hacked ETH RST handling

[Simon Goldschmidt]

Am Do., 10. Jan. 2019, 21:40 hat Marek Vasut  geschrieben:

> On 1/10/19 8:49 PM, Simon Goldschmidt wrote:
> > The 'designware_socfpga' ETH driver can now get the MACs out of reset
> > via the socfpga reset driver and can set PHY mode via syscon.
> >
> > This means we can now remove the ad-hoc code to do this from
> > arch/arm/mach-socfpga.
> >
> > Signed-off-by: Simon Goldschmdit 
> > Signed-off-by: Simon Goldschmidt 
>
> I very much like this patch, except for the dual SoB line.
>

D'oh! The first one was may typo, the 2nd one was by patman.

Seems like I need a V2 anyway...

Regards,
Simon

>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] arm: socfpga: gen5 enable designware_socfpga

[Marek Vasut]

On 1/10/19 9:43 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 10. Jan. 2019, 21:40 hat Marek Vasut  > geschrieben:
> 
> On 1/10/19 8:49 PM, Simon Goldschmidt wrote:
> > Enable the socfpga specific designeware ethernet driver for all Gen5
> > and Arria10 defconfigs. To make it work, enable REGMAP and SYSCON,
> > too.
> >
> > This is required to remove the hacky reset and phy mode handling in
> > arch/arm/mach-socfpga.
> 
> Can the Gen5/A10 just "imply" those two options or can the DWMAC driver
> "select" those two options in Kconfig ?
> 
> 
> Hmm, I'll try that.

And if you get bored, you can imply as much common stuff from the
defconfigs as possible ;-)

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] net: designware: socfpga: adapt to Gen5

[Marek Vasut]

On 1/10/19 9:42 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 10. Jan. 2019, 21:38 hat Marek Vasut  > geschrieben:
> 
> On 1/10/19 8:54 PM, Simon Goldschmidt wrote:
> > Hi Marek,
> >
> > Am 10.01.2019 um 20:49 schrieb Simon Goldschmidt:
> >> This driver was written for Arria10, but it applies to Gen5, too.
> >>
> >> The main difference is that Gen5 has 2 MACs (Arria10 has 3) and the
> >> syscon bits are encoded in the same register, thus an offset is
> needed.
> >>
> >> This offset is already read from the devicetree, but for Arria10
> it is
> >> always 0, which is probably why it has been ignored. By using this
> >> offset when writing the phy mode into the syscon regiter, we can use
> >> this driver to set the phy mode for both of the MACs on Gen5.
> >>
> >> Tested on socfpga_socrates (where the 2nd MAC is connected, so a
> shift
> >> offset is required).
> >>
> >> Signed-off-by: Simon Goldschmidt  >
> >> ---
> >>
> >>   drivers/net/dwmac_socfpga.c | 14 +-
> >>   1 file changed, 9 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/dwmac_socfpga.c
> b/drivers/net/dwmac_socfpga.c
> >> index 08fc9677c4..309da69647 100644
> >> --- a/drivers/net/dwmac_socfpga.c
> >> +++ b/drivers/net/dwmac_socfpga.c
> >> @@ -27,6 +27,7 @@ struct dwmac_socfpga_platdata {
> >>   struct dw_eth_pdata    dw_eth_pdata;
> >>   enum dwmac_type    type;
> >>   void    *phy_intf;
> >> +    u32    reg_shift;
> >>   };
> >>     static int dwmac_socfpga_ofdata_to_platdata(struct udevice *dev)
> >> @@ -63,6 +64,7 @@ static int dwmac_socfpga_ofdata_to_platdata(struct
> >> udevice *dev)
> >>   }
> >>     pdata->phy_intf = range + args.args[0];
> >> +    pdata->reg_shift = args.args[1];
> >>     /*
> >>    * Sadly, the Altera DT bindings don't have SoC-specific
> >> compatibles,
> >> @@ -88,9 +90,11 @@ static int dwmac_socfpga_probe(struct udevice
> *dev)
> >>   struct eth_pdata *edata = >dw_eth_pdata.eth_pdata;
> >>   struct reset_ctl_bulk reset_bulk;
> >>   int ret;
> >> -    u8 modereg;
> >> +    u32 modereg;
> >> +    u32 modemask;
> >>   -    if (pdata->type == DWMAC_SOCFPGA_ARRIA10) {
> >> +    if (pdata->type == DWMAC_SOCFPGA_ARRIA10 ||
> >> +    pdata->type == DWMAC_SOCFPGA_GEN5) {
> >
> > I just checked: the Linux driver does not seem to have special
> handling
> > for Gen5/Arria10/Stratix10. Since Gen5 and Arria10 now both work
> and the
> > registers for Stratix10 seem the same as for Arria10, could we maybe
> > drop this special handling?
> >
> > That would mean we could drop this whole 'type' and the 'enum
> > dwmac_type'...
> 
> I seem to remember the register layout for selecting the PHY mode on
> Gen5 and Arria10 was different, please check the datasheets. Of course,
> the less special-casing, the better.
> 
> 
> Yes, the register layout is different. But the reg_shift value takes
> care of that. Luckily, the bits have the same meaning even if the offset
> is different.

Fantastic

> What remains is the special case for Stratix10. Looking at the Linux
> driver and the register descriptions, I think we can drop the special
> cases, but someone would need to test it on Stratix10...

+CC Joyce.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] arm: socfpga: gen5 enable designware_socfpga

[Simon Goldschmidt]

Am Do., 10. Jan. 2019, 21:40 hat Marek Vasut  geschrieben:

> On 1/10/19 8:49 PM, Simon Goldschmidt wrote:
> > Enable the socfpga specific designeware ethernet driver for all Gen5
> > and Arria10 defconfigs. To make it work, enable REGMAP and SYSCON,
> > too.
> >
> > This is required to remove the hacky reset and phy mode handling in
> > arch/arm/mach-socfpga.
>
> Can the Gen5/A10 just "imply" those two options or can the DWMAC driver
> "select" those two options in Kconfig ?
>

Hmm, I'll try that.

Regards,
Simon

>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] net: designware: socfpga: adapt to Gen5

[Simon Goldschmidt]

Am Do., 10. Jan. 2019, 21:38 hat Marek Vasut  geschrieben:

> On 1/10/19 8:54 PM, Simon Goldschmidt wrote:
> > Hi Marek,
> >
> > Am 10.01.2019 um 20:49 schrieb Simon Goldschmidt:
> >> This driver was written for Arria10, but it applies to Gen5, too.
> >>
> >> The main difference is that Gen5 has 2 MACs (Arria10 has 3) and the
> >> syscon bits are encoded in the same register, thus an offset is needed.
> >>
> >> This offset is already read from the devicetree, but for Arria10 it is
> >> always 0, which is probably why it has been ignored. By using this
> >> offset when writing the phy mode into the syscon regiter, we can use
> >> this driver to set the phy mode for both of the MACs on Gen5.
> >>
> >> Tested on socfpga_socrates (where the 2nd MAC is connected, so a shift
> >> offset is required).
> >>
> >> Signed-off-by: Simon Goldschmidt 
> >> ---
> >>
> >>   drivers/net/dwmac_socfpga.c | 14 +-
> >>   1 file changed, 9 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
> >> index 08fc9677c4..309da69647 100644
> >> --- a/drivers/net/dwmac_socfpga.c
> >> +++ b/drivers/net/dwmac_socfpga.c
> >> @@ -27,6 +27,7 @@ struct dwmac_socfpga_platdata {
> >>   struct dw_eth_pdatadw_eth_pdata;
> >>   enum dwmac_typetype;
> >>   void*phy_intf;
> >> +u32reg_shift;
> >>   };
> >> static int dwmac_socfpga_ofdata_to_platdata(struct udevice *dev)
> >> @@ -63,6 +64,7 @@ static int dwmac_socfpga_ofdata_to_platdata(struct
> >> udevice *dev)
> >>   }
> >> pdata->phy_intf = range + args.args[0];
> >> +pdata->reg_shift = args.args[1];
> >> /*
> >>* Sadly, the Altera DT bindings don't have SoC-specific
> >> compatibles,
> >> @@ -88,9 +90,11 @@ static int dwmac_socfpga_probe(struct udevice *dev)
> >>   struct eth_pdata *edata = >dw_eth_pdata.eth_pdata;
> >>   struct reset_ctl_bulk reset_bulk;
> >>   int ret;
> >> -u8 modereg;
> >> +u32 modereg;
> >> +u32 modemask;
> >>   -if (pdata->type == DWMAC_SOCFPGA_ARRIA10) {
> >> +if (pdata->type == DWMAC_SOCFPGA_ARRIA10 ||
> >> +pdata->type == DWMAC_SOCFPGA_GEN5) {
> >
> > I just checked: the Linux driver does not seem to have special handling
> > for Gen5/Arria10/Stratix10. Since Gen5 and Arria10 now both work and the
> > registers for Stratix10 seem the same as for Arria10, could we maybe
> > drop this special handling?
> >
> > That would mean we could drop this whole 'type' and the 'enum
> > dwmac_type'...
>
> I seem to remember the register layout for selecting the PHY mode on
> Gen5 and Arria10 was different, please check the datasheets. Of course,
> the less special-casing, the better.
>

Yes, the register layout is different. But the reg_shift value takes care
of that. Luckily, the bits have the same meaning even if the offset is
different.

What remains is the special case for Stratix10. Looking at the Linux driver
and the register descriptions, I think we can drop the special cases, but
someone would need to test it on Stratix10...

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] arm: socfpga: gen5: remove hacked ETH RST handling

[Marek Vasut]

On 1/10/19 8:49 PM, Simon Goldschmidt wrote:
> The 'designware_socfpga' ETH driver can now get the MACs out of reset
> via the socfpga reset driver and can set PHY mode via syscon.
> 
> This means we can now remove the ad-hoc code to do this from
> arch/arm/mach-socfpga.
> 
> Signed-off-by: Simon Goldschmdit 
> Signed-off-by: Simon Goldschmidt 

I very much like this patch, except for the dual SoB line.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] arm: socfpga: gen5 enable designware_socfpga

[Marek Vasut]

On 1/10/19 8:49 PM, Simon Goldschmidt wrote:
> Enable the socfpga specific designeware ethernet driver for all Gen5
> and Arria10 defconfigs. To make it work, enable REGMAP and SYSCON,
> too.
> 
> This is required to remove the hacky reset and phy mode handling in
> arch/arm/mach-socfpga.

Can the Gen5/A10 just "imply" those two options or can the DWMAC driver
"select" those two options in Kconfig ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] net: designware: socfpga: adapt to Gen5

[Marek Vasut]

On 1/10/19 8:54 PM, Simon Goldschmidt wrote:
> Hi Marek,
> 
> Am 10.01.2019 um 20:49 schrieb Simon Goldschmidt:
>> This driver was written for Arria10, but it applies to Gen5, too.
>>
>> The main difference is that Gen5 has 2 MACs (Arria10 has 3) and the
>> syscon bits are encoded in the same register, thus an offset is needed.
>>
>> This offset is already read from the devicetree, but for Arria10 it is
>> always 0, which is probably why it has been ignored. By using this
>> offset when writing the phy mode into the syscon regiter, we can use
>> this driver to set the phy mode for both of the MACs on Gen5.
>>
>> Tested on socfpga_socrates (where the 2nd MAC is connected, so a shift
>> offset is required).
>>
>> Signed-off-by: Simon Goldschmidt 
>> ---
>>
>>   drivers/net/dwmac_socfpga.c | 14 +-
>>   1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
>> index 08fc9677c4..309da69647 100644
>> --- a/drivers/net/dwmac_socfpga.c
>> +++ b/drivers/net/dwmac_socfpga.c
>> @@ -27,6 +27,7 @@ struct dwmac_socfpga_platdata {
>>   struct dw_eth_pdata    dw_eth_pdata;
>>   enum dwmac_type    type;
>>   void    *phy_intf;
>> +    u32    reg_shift;
>>   };
>>     static int dwmac_socfpga_ofdata_to_platdata(struct udevice *dev)
>> @@ -63,6 +64,7 @@ static int dwmac_socfpga_ofdata_to_platdata(struct
>> udevice *dev)
>>   }
>>     pdata->phy_intf = range + args.args[0];
>> +    pdata->reg_shift = args.args[1];
>>     /*
>>    * Sadly, the Altera DT bindings don't have SoC-specific
>> compatibles,
>> @@ -88,9 +90,11 @@ static int dwmac_socfpga_probe(struct udevice *dev)
>>   struct eth_pdata *edata = >dw_eth_pdata.eth_pdata;
>>   struct reset_ctl_bulk reset_bulk;
>>   int ret;
>> -    u8 modereg;
>> +    u32 modereg;
>> +    u32 modemask;
>>   -    if (pdata->type == DWMAC_SOCFPGA_ARRIA10) {
>> +    if (pdata->type == DWMAC_SOCFPGA_ARRIA10 ||
>> +    pdata->type == DWMAC_SOCFPGA_GEN5) {
> 
> I just checked: the Linux driver does not seem to have special handling
> for Gen5/Arria10/Stratix10. Since Gen5 and Arria10 now both work and the
> registers for Stratix10 seem the same as for Arria10, could we maybe
> drop this special handling?
> 
> That would mean we could drop this whole 'type' and the 'enum
> dwmac_type'...

I seem to remember the register layout for selecting the PHY mode on
Gen5 and Arria10 was different, please check the datasheets. Of course,
the less special-casing, the better.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1] dm: led: add TI LP5562 LED driver

[Doug Zobel]

Driver for the TI LP5562 4 channel LED controller.  Supports
independent on/off control of all 4 channels.  Supports LED_BLINK
on 3 independent channels: blue/green/red.  The white channel can
blink, but shares the blue channel blink rate.
---
 doc/device-tree-bindings/leds/leds-lp5562.txt |  61 +++
 drivers/led/Kconfig   |   8 +
 drivers/led/Makefile  |   1 +
 drivers/led/led_lp5562.c  | 571 ++
 4 files changed, 641 insertions(+)
 create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt
 create mode 100644 drivers/led/led_lp5562.c

diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt 
b/doc/device-tree-bindings/leds/leds-lp5562.txt
new file mode 100644
index 000..d6e3192
--- /dev/null
+++ b/doc/device-tree-bindings/leds/leds-lp5562.txt
@@ -0,0 +1,61 @@
+LEDs connected to TI LP5562 controller
+
+This driver works with a TI LP5562 4-channel LED controller.
+CONFIG_LED_BLINK is supported using the controller engines.  However
+there are only 3 engines available for the 4 channels.  This means
+that the blue and white channels share the same engine.  When both
+blue and white LEDs are set to blink, they will share the same blink
+rate.  Changing the blink rate of the blue LED will affect the white
+LED and vice-versa.  Manual on/off is handled independtly for all
+4 channels.
+
+Required properties:
+  - compatible : should be "ti,lp5562-leds".
+  - #address-cells : must be 1.
+  - #size-cells : must be 0.
+  - reg : LP5562 LED controller I2C address.
+
+Optional properties:
+  - gpios : Enable GPIO
+  - ti,external_clock : Boolean, configures controller for external
+32 kHZ clock input.  Default : false (use internal clock)
+
+Each LED is represented as a sub-node of the ti,lp5562-leds device.
+
+LED sub-node required properties:
+  - reg : PWM register number for channel
+
+LED sub-node optional properties:
+  - label : see Documentation/devicetree/bindings/leds/common.txt
+  - ti,led_current : LED current at max brightness in 100uA steps (0x00 - 0xFF)
+Default : 0x64 (10 ma)
+
+Example:
+leds0: lp5562@30 {
+compatible = "ti,lp5562-leds";
+#address-cells = <1>;
+#size-cells = <0>;
+gpios = < 9 GPIO_ACTIVE_HIGH>;
+reg = <0x30>;
+
+blue@0 {
+reg = <0x2>;
+label = "blue";
+ti,led_current = <0xC8>; /* 20ma */
+};
+green@1 {
+reg = <0x3>;
+label = "green";
+ti,led_current = <0xC8>; /* 20ma */
+};
+red@2 {
+reg = <0x4>;
+label = "red";
+ti,led_current = <0xC8>; /* 20ma */
+};
+white@3 {
+reg = <0xE>;
+label = "white";
+ti,led_current = <0xC8>; /* 20ma */
+};
+};
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index 5da5c4a..101ad94 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -28,6 +28,14 @@ config LED_BCM6358
  LED HW controller accessed via MMIO registers.
  HW has no blinking capabilities and up to 32 LEDs can be controlled.
 
+config LED_LP5562
+   bool "LED Support for LP5562"
+   depends on LED && DM_I2C
+   help
+ This option enables support for LEDs connected to the TI LP5562
+ 4 channel I2C LED controller.  Driver fully supports blink on the
+ B/G/R LEDs.  White LED can blink, but re-uses the period from blue.
+
 config LED_BLINK
bool "Support LED blinking"
depends on LED
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 160a8f3..ef2ce1c 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -7,3 +7,4 @@ obj-y += led-uclass.o
 obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
 obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
 obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
+obj-$(CONFIG_LED_LP5562) += led_lp5562.o
diff --git a/drivers/led/led_lp5562.c b/drivers/led/led_lp5562.c
new file mode 100644
index 000..357b175
--- /dev/null
+++ b/drivers/led/led_lp5562.c
@@ -0,0 +1,571 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Doug Zobel 
+ *
+ * Driver for TI lp5562 4 channel LED driver.  There are only 3
+ * engines available for the 4 LEDs, so white and blue LEDs share
+ * the same engine.  This means that the blink period is shared
+ * between them.  Changing the period of blue blink will affect
+ * the white period (and vice-versa).  Blue and white On/Off
+ * states remain independent (as would PWM brightness if that's
+ * ever added to the LED core).
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CURRENT   

[U-Boot] [PATCH v1] Add LED driver for TI LP5562 controller

[Doug Zobel]

Add a DM driver for the TI LP5562 4 channel LED controller.  Supports
independent on/off control of all 4 channels (blue/green/red/white).  
Supports LED_BLINK on blue/green/red channels.  White channel supports 
LED_BLINK, but the blink period is shared with the blue channel due
to controller limitations.

Doug Zobel (1):
  dm: led: add TI LP5562 LED driver

 doc/device-tree-bindings/leds/leds-lp5562.txt |  61 +++
 drivers/led/Kconfig   |   8 +
 drivers/led/Makefile  |   1 +
 drivers/led/led_lp5562.c  | 571 ++
 4 files changed, 641 insertions(+)
 create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt
 create mode 100644 drivers/led/led_lp5562.c

-- 
2.7.4


-- 










This email and any attachments are for the exclusive use of the 
intended recipient(s) and may contain confidential and/or privileged 
information.  Inadvertent disclosure of this message does not constitute a 
waiver of any privilege, right or remedy.  If you are not the intended 
recipient, please do not directly or indirectly use, disclose or distribute 
this message, and please contact the sender and delete this email, any 
attachments and all copies.  Climate and its affiliates may use, read or 
archive email communications (including attachments) through its computer 
network, as permitted by applicable law.  Climate and its affiliates (or an 
external service provider) may also scan emails and attachments on its 
computer network to ensure systems operate efficiently and to minimize 
security risks. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] net: designware: socfpga: adapt to Gen5

[Simon Goldschmidt]

Hi Marek,

Am 10.01.2019 um 20:49 schrieb Simon Goldschmidt:

This driver was written for Arria10, but it applies to Gen5, too.

The main difference is that Gen5 has 2 MACs (Arria10 has 3) and the
syscon bits are encoded in the same register, thus an offset is needed.

This offset is already read from the devicetree, but for Arria10 it is
always 0, which is probably why it has been ignored. By using this
offset when writing the phy mode into the syscon regiter, we can use
this driver to set the phy mode for both of the MACs on Gen5.

Tested on socfpga_socrates (where the 2nd MAC is connected, so a shift
offset is required).

Signed-off-by: Simon Goldschmidt 
---

  drivers/net/dwmac_socfpga.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index 08fc9677c4..309da69647 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -27,6 +27,7 @@ struct dwmac_socfpga_platdata {
struct dw_eth_pdata dw_eth_pdata;
enum dwmac_type type;
void*phy_intf;
+   u32 reg_shift;
  };
  
  static int dwmac_socfpga_ofdata_to_platdata(struct udevice *dev)

@@ -63,6 +64,7 @@ static int dwmac_socfpga_ofdata_to_platdata(struct udevice 
*dev)
}
  
  	pdata->phy_intf = range + args.args[0];

+   pdata->reg_shift = args.args[1];
  
  	/*

 * Sadly, the Altera DT bindings don't have SoC-specific compatibles,
@@ -88,9 +90,11 @@ static int dwmac_socfpga_probe(struct udevice *dev)
struct eth_pdata *edata = >dw_eth_pdata.eth_pdata;
struct reset_ctl_bulk reset_bulk;
int ret;
-   u8 modereg;
+   u32 modereg;
+   u32 modemask;
  
-	if (pdata->type == DWMAC_SOCFPGA_ARRIA10) {

+   if (pdata->type == DWMAC_SOCFPGA_ARRIA10 ||
+   pdata->type == DWMAC_SOCFPGA_GEN5) {


I just checked: the Linux driver does not seem to have special handling 
for Gen5/Arria10/Stratix10. Since Gen5 and Arria10 now both work and the 
registers for Stratix10 seem the same as for Arria10, could we maybe 
drop this special handling?


That would mean we could drop this whole 'type' and the 'enum dwmac_type'...

Regards,
Simon


switch (edata->phy_interface) {
case PHY_INTERFACE_MODE_MII:
case PHY_INTERFACE_MODE_GMII:
@@ -115,9 +119,9 @@ static int dwmac_socfpga_probe(struct udevice *dev)
  
  		reset_assert_bulk(_bulk);
  
-		clrsetbits_le32(pdata->phy_intf,

-   SYSMGR_EMACGRP_CTRL_PHYSEL_MASK,
-   modereg);
+   modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
+   clrsetbits_le32(pdata->phy_intf, modemask,
+   modereg << pdata->reg_shift);
  
  		reset_release_bulk(_bulk);

}



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH PATCH v2 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Marek Vasut]

On 1/10/19 3:44 PM, Jean-Jacques Hiblot wrote:
> 
> This series applies on top of u-boot-usb.
> 
> This series renames CONFIG_SPL_USB_GADGET_SUPPORT to CONFIG_SPL_USB_GADGET
> for consistency.
> It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
> sure that the code is not included if it is not needed. Some defconfigs
> had to be updated as they relied on the gadget code to be always compiled.
> 
> 
> Changes in v2:
> - rebased on top of latest u-boot-usb
Thanks, I picked them into u-boot-usb/master instead of the ones in DFU PR.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH PATCH v2 1/2] Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET

[Jean-Jacques Hiblot]

The SPL option for USB gadget should be named after the option for u-boot
(CONFIG_USB_GADGET)

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v2: None

 arch/arm/mach-imx/mx6/Kconfig| 2 +-
 arch/arm/mach-imx/spl.c  | 2 +-
 common/spl/Kconfig   | 4 ++--
 configs/am335x_boneblack_vboot_defconfig | 2 +-
 configs/am335x_evm_usbspl_defconfig  | 2 +-
 configs/am43xx_evm_defconfig | 2 +-
 configs/am43xx_hs_evm_defconfig  | 2 +-
 configs/apalis_imx6_defconfig| 2 +-
 configs/colibri_imx6_defconfig   | 2 +-
 configs/display5_factory_defconfig   | 2 +-
 configs/imx6q_logic_defconfig| 2 +-
 configs/mx6memcal_defconfig  | 2 +-
 configs/mx6sabresd_defconfig | 2 +-
 configs/pico-hobbit-imx6ul_defconfig | 2 +-
 configs/pico-hobbit-imx7d_defconfig  | 2 +-
 configs/pico-imx6ul_defconfig| 2 +-
 configs/pico-imx7d_defconfig | 2 +-
 configs/pico-pi-imx6ul_defconfig | 2 +-
 configs/pico-pi-imx7d_defconfig  | 2 +-
 drivers/Makefile | 6 +++---
 drivers/usb/gadget/Makefile  | 2 +-
 scripts/Makefile.spl | 2 +-
 22 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index e7cce46e03..3d56346ccb 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -263,7 +263,7 @@ config TARGET_MX6DL_MAMOJ
select SPL_PINCTRL if SPL
select SPL_SEPARATE_BSS if SPL
select SPL_SERIAL_SUPPORT if SPL
-   select SPL_USB_GADGET_SUPPORT if SPL
+   select SPL_USB_GADGET if SPL
select SPL_USB_HOST_SUPPORT if SPL
select SPL_USB_SDP_SUPPORT if SPL
select SPL_WATCHDOG_SUPPORT if SPL
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 58a92278df..397d6d4a91 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -154,7 +154,7 @@ u32 spl_boot_device(void)
 }
 #endif /* CONFIG_MX7 || CONFIG_IMX8M */
 
-#ifdef CONFIG_SPL_USB_GADGET_SUPPORT
+#ifdef CONFIG_SPL_USB_GADGET
 int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
 {
put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, >idProduct);
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 35472f4a92..37ecbc6b1c 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -776,13 +776,13 @@ config SPL_USB_SUPPORT
  config options. This enables loading from USB using a configured
  device.
 
-config SPL_USB_GADGET_SUPPORT
+config SPL_USB_GADGET
bool "Suppport USB Gadget drivers"
help
  Enable USB Gadget API which allows to enable USB device functions
  in SPL.
 
-if SPL_USB_GADGET_SUPPORT
+if SPL_USB_GADGET
 
 config SPL_USB_ETHER
bool "Support USB Ethernet drivers"
diff --git a/configs/am335x_boneblack_vboot_defconfig 
b/configs/am335x_boneblack_vboot_defconfig
index c62e8322fb..f455b01e1e 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_MUSB_NEW_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM33xx U-Boot SPL"
 CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
diff --git a/configs/am335x_evm_usbspl_defconfig 
b/configs/am335x_evm_usbspl_defconfig
index 1c315025d1..bda1785e7e 100644
--- a/configs/am335x_evm_usbspl_defconfig
+++ b/configs/am335x_evm_usbspl_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_MUSB_NEW_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL"
 CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 # CONFIG_SPL_YMODEM_SUPPORT is not set
 CONFIG_CMD_SPL=y
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 481aa4fad9..e3464145eb 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL"
 CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 CONFIG_CMD_SPL=y
 CONFIG_CMD_SPL_NAND_OFS=0x0010
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 5d98e0edee..99e4ccb592 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -25,7 +25,7 @@ CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL"
 CONFIG_SPL_USB_HOST_SUPPORT=y
 CONFIG_SPL_USB_SUPPORT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_NAND=y
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 133fc1a4db..e02d9bc7de 100644
--- 

[U-Boot] [PATCH PATCH v2 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Jean-Jacques Hiblot]

This series applies on top of u-boot-usb.

This series renames CONFIG_SPL_USB_GADGET_SUPPORT to CONFIG_SPL_USB_GADGET
for consistency.
It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
sure that the code is not included if it is not needed. Some defconfigs
had to be updated as they relied on the gadget code to be always compiled.


Changes in v2:
- rebased on top of latest u-boot-usb

Jean-Jacques Hiblot (2):
  Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET
  usb: Make compiling gadget support optional

 Makefile | 4 ++--
 arch/arm/mach-imx/mx6/Kconfig| 2 +-
 arch/arm/mach-imx/spl.c  | 2 +-
 common/spl/Kconfig   | 4 ++--
 configs/am335x_boneblack_vboot_defconfig | 2 +-
 configs/am335x_evm_usbspl_defconfig  | 2 +-
 configs/am43xx_evm_defconfig | 2 +-
 configs/am43xx_hs_evm_defconfig  | 2 +-
 configs/apalis_imx6_defconfig| 2 +-
 configs/cm_t3517_defconfig   | 1 +
 configs/cm_t35_defconfig | 1 +
 configs/colibri_imx6_defconfig   | 2 +-
 configs/display5_factory_defconfig   | 2 +-
 configs/duovero_defconfig| 1 +
 configs/igep0032_defconfig   | 1 +
 configs/igep00x0_defconfig   | 1 +
 configs/imx6q_logic_defconfig| 2 +-
 configs/mx6memcal_defconfig  | 2 +-
 configs/mx6sabresd_defconfig | 2 +-
 configs/omap3_zoom1_defconfig| 1 +
 configs/omap4_panda_defconfig| 1 +
 configs/omap4_sdp4430_defconfig  | 1 +
 configs/pico-hobbit-imx6ul_defconfig | 2 +-
 configs/pico-hobbit-imx7d_defconfig  | 2 +-
 configs/pico-imx6ul_defconfig| 2 +-
 configs/pico-imx7d_defconfig | 2 +-
 configs/pico-pi-imx6ul_defconfig | 2 +-
 configs/pico-pi-imx7d_defconfig  | 2 +-
 configs/spear300_usbtty_defconfig| 2 ++
 configs/spear300_usbtty_nand_defconfig   | 2 ++
 configs/spear310_usbtty_defconfig| 2 ++
 configs/spear310_usbtty_nand_defconfig   | 2 ++
 configs/spear310_usbtty_pnor_defconfig   | 2 ++
 configs/spear320_usbtty_defconfig| 2 ++
 configs/spear320_usbtty_nand_defconfig   | 2 ++
 configs/spear320_usbtty_pnor_defconfig   | 2 ++
 configs/spear600_usbtty_defconfig| 2 ++
 configs/spear600_usbtty_nand_defconfig   | 2 ++
 drivers/Makefile | 6 +++---
 drivers/usb/gadget/Makefile  | 2 +-
 scripts/Makefile.spl | 2 +-
 41 files changed, 55 insertions(+), 27 deletions(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/3] arm: socfpga: gen5 enable designware_socfpga

[Simon Goldschmidt]

Enable the socfpga specific designeware ethernet driver for all Gen5
and Arria10 defconfigs. To make it work, enable REGMAP and SYSCON,
too.

This is required to remove the hacky reset and phy mode handling in
arch/arm/mach-socfpga.

Signed-off-by: Simon Goldschmidt 
---

 configs/socfpga_arria5_defconfig   | 3 +++
 configs/socfpga_cyclone5_defconfig | 3 +++
 configs/socfpga_dbm_soc1_defconfig | 3 +++
 configs/socfpga_de0_nano_soc_defconfig | 3 +++
 configs/socfpga_de10_nano_defconfig| 3 +++
 configs/socfpga_de1_soc_defconfig  | 3 +++
 configs/socfpga_is1_defconfig  | 3 +++
 configs/socfpga_sockit_defconfig   | 3 +++
 configs/socfpga_socrates_defconfig | 3 +++
 configs/socfpga_sr1500_defconfig   | 3 +++
 configs/socfpga_vining_fpga_defconfig  | 3 +++
 11 files changed, 33 insertions(+)

diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig
index 0e5e74a621..15cc16b111 100644
--- a/configs/socfpga_arria5_defconfig
+++ b/configs/socfpga_arria5_defconfig
@@ -41,6 +41,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria5_socdk"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_DFU_MMC=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
@@ -59,6 +61,7 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_ETH_DESIGNWARE_SOCFPGA=y
 CONFIG_MII=y
 CONFIG_DM_RESET=y
 CONFIG_SPI=y
diff --git a/configs/socfpga_cyclone5_defconfig 
b/configs/socfpga_cyclone5_defconfig
index e8de0f5709..2a432d2007 100644
--- a/configs/socfpga_cyclone5_defconfig
+++ b/configs/socfpga_cyclone5_defconfig
@@ -41,6 +41,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_socdk"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_DFU_MMC=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
@@ -60,6 +62,7 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_ETH_DESIGNWARE_SOCFPGA=y
 CONFIG_MII=y
 CONFIG_DM_RESET=y
 CONFIG_SPI=y
diff --git a/configs/socfpga_dbm_soc1_defconfig 
b/configs/socfpga_dbm_soc1_defconfig
index b6f4f8a3dd..e7726dc3cc 100644
--- a/configs/socfpga_dbm_soc1_defconfig
+++ b/configs/socfpga_dbm_soc1_defconfig
@@ -42,6 +42,8 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_dbm_soc1"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_DFU_MMC=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
@@ -54,6 +56,7 @@ CONFIG_MTD_DEVICE=y
 CONFIG_DM_ETH=y
 CONFIG_PHY_GIGE=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_ETH_DESIGNWARE_SOCFPGA=y
 CONFIG_MII=y
 CONFIG_DM_RESET=y
 CONFIG_SPI=y
diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index 9a89bb5d68..33a412d340 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -41,6 +41,8 @@ CONFIG_CMD_UBI=y
 CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de0_nano_soc"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_DFU_MMC=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
@@ -54,6 +56,7 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_ETH_DESIGNWARE_SOCFPGA=y
 CONFIG_MII=y
 CONFIG_DM_RESET=y
 CONFIG_SPI=y
diff --git a/configs/socfpga_de10_nano_defconfig 
b/configs/socfpga_de10_nano_defconfig
index db516891ba..662e895af2 100644
--- a/configs/socfpga_de10_nano_defconfig
+++ b/configs/socfpga_de10_nano_defconfig
@@ -37,6 +37,8 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de10_nano"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_DFU_MMC=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
@@ -50,6 +52,7 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_ETH_DESIGNWARE_SOCFPGA=y
 CONFIG_MII=y
 CONFIG_DM_RESET=y
 CONFIG_SPI=y
diff --git a/configs/socfpga_de1_soc_defconfig 
b/configs/socfpga_de1_soc_defconfig
index 5bed755723..d02bf1c6cf 100644
--- a/configs/socfpga_de1_soc_defconfig
+++ b/configs/socfpga_de1_soc_defconfig
@@ -37,6 +37,8 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de1_soc"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
 CONFIG_DWAPB_GPIO=y
@@ -49,6 +51,7 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
+CONFIG_ETH_DESIGNWARE_SOCFPGA=y
 CONFIG_MII=y
 CONFIG_DM_RESET=y
 CONFIG_SPI=y
diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig
index 682e58fdb8..97125efae4 100644
--- a/configs/socfpga_is1_defconfig
+++ b/configs/socfpga_is1_defconfig
@@ -38,6 +38,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_is1"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
 

[U-Boot] [PATCH 3/3] arm: socfpga: gen5: remove hacked ETH RST handling

[Simon Goldschmidt]

The 'designware_socfpga' ETH driver can now get the MACs out of reset
via the socfpga reset driver and can set PHY mode via syscon.

This means we can now remove the ad-hoc code to do this from
arch/arm/mach-socfpga.

Signed-off-by: Simon Goldschmdit 
Signed-off-by: Simon Goldschmidt 
---

 .../mach-socfpga/include/mach/reset_manager.h |  2 -
 arch/arm/mach-socfpga/misc.c  | 65 ---
 arch/arm/mach-socfpga/misc_gen5.c | 44 +
 3 files changed, 1 insertion(+), 110 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index d9e0b33c60..42beaecdd6 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -10,8 +10,6 @@ void reset_cpu(ulong addr);
 
 void socfpga_per_reset(u32 reset, int set);
 void socfpga_per_reset_all(void);
-int socfpga_eth_reset_common(void (*resetfn)(const u8 of_reset_id,
-const u8 phymode));
 
 #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1
 
diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 78fbe28724..e1adea143c 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -120,71 +120,6 @@ int arch_cpu_init(void)
return 0;
 }
 
-#ifdef CONFIG_ETH_DESIGNWARE
-static int dwmac_phymode_to_modereg(const char *phymode, u32 *modereg)
-{
-   if (!phymode)
-   return -EINVAL;
-
-   if (!strcmp(phymode, "mii") || !strcmp(phymode, "gmii")) {
-   *modereg = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
-   return 0;
-   }
-
-   if (!strcmp(phymode, "rgmii")) {
-   *modereg = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII;
-   return 0;
-   }
-
-   if (!strcmp(phymode, "rmii")) {
-   *modereg = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII;
-   return 0;
-   }
-
-   return -EINVAL;
-}
-
-int socfpga_eth_reset_common(void (*resetfn)(const u8 of_reset_id,
-const u8 phymode))
-{
-   const void *fdt = gd->fdt_blob;
-   struct fdtdec_phandle_args args;
-   const char *phy_mode;
-   u32 phy_modereg;
-   int nodes[2];   /* Max. two GMACs */
-   int ret, count;
-   int i, node;
-
-   count = fdtdec_find_aliases_for_id(fdt, "ethernet",
-  COMPAT_ALTERA_SOCFPGA_DWMAC,
-  nodes, ARRAY_SIZE(nodes));
-   for (i = 0; i < count; i++) {
-   node = nodes[i];
-   if (node <= 0)
-   continue;
-
-   ret = fdtdec_parse_phandle_with_args(fdt, node, "resets",
-"#reset-cells", 1, 0,
-);
-   if (ret || (args.args_count != 1)) {
-   debug("GMAC%i: Failed to parse DT 'resets'!\n", i);
-   continue;
-   }
-
-   phy_mode = fdt_getprop(fdt, node, "phy-mode", NULL);
-   ret = dwmac_phymode_to_modereg(phy_mode, _modereg);
-   if (ret) {
-   debug("GMAC%i: Failed to parse DT 'phy-mode'!\n", i);
-   continue;
-   }
-
-   resetfn(args.args[0], phy_modereg);
-   }
-
-   return 0;
-}
-#endif
-
 #ifndef CONFIG_SPL_BUILD
 static int do_bridge(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
b/arch/arm/mach-socfpga/misc_gen5.c
index 04f237d100..6e11ba6cb2 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -54,48 +54,6 @@ static Altera_desc altera_fpga[] = {
},
 };
 
-/*
- * DesignWare Ethernet initialization
- */
-#ifdef CONFIG_ETH_DESIGNWARE
-static void gen5_dwmac_reset(const u8 of_reset_id, const u8 phymode)
-{
-   u32 physhift, reset;
-
-   if (of_reset_id == EMAC0_RESET) {
-   physhift = SYSMGR_EMACGRP_CTRL_PHYSEL0_LSB;
-   reset = SOCFPGA_RESET(EMAC0);
-   } else if (of_reset_id == EMAC1_RESET) {
-   physhift = SYSMGR_EMACGRP_CTRL_PHYSEL1_LSB;
-   reset = SOCFPGA_RESET(EMAC1);
-   } else {
-   printf("GMAC: Invalid reset ID (%i)!\n", of_reset_id);
-   return;
-   }
-
-   /* configure to PHY interface select choosed */
-   clrsetbits_le32(_regs->emacgrp_ctrl,
-   SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << physhift,
-   phymode << physhift);
-
-   /* Release the EMAC controller from reset */
-   socfpga_per_reset(reset, 0);
-}
-
-static int socfpga_eth_reset(void)
-{
-   /* Put all GMACs into RESET state. */
-   socfpga_per_reset(SOCFPGA_RESET(EMAC0), 1);
-   socfpga_per_reset(SOCFPGA_RESET(EMAC1), 1);
-   return 

[U-Boot] [PATCH 1/3] net: designware: socfpga: adapt to Gen5

[Simon Goldschmidt]

This driver was written for Arria10, but it applies to Gen5, too.

The main difference is that Gen5 has 2 MACs (Arria10 has 3) and the
syscon bits are encoded in the same register, thus an offset is needed.

This offset is already read from the devicetree, but for Arria10 it is
always 0, which is probably why it has been ignored. By using this
offset when writing the phy mode into the syscon regiter, we can use
this driver to set the phy mode for both of the MACs on Gen5.

Tested on socfpga_socrates (where the 2nd MAC is connected, so a shift
offset is required).

Signed-off-by: Simon Goldschmidt 
---

 drivers/net/dwmac_socfpga.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index 08fc9677c4..309da69647 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -27,6 +27,7 @@ struct dwmac_socfpga_platdata {
struct dw_eth_pdata dw_eth_pdata;
enum dwmac_type type;
void*phy_intf;
+   u32 reg_shift;
 };
 
 static int dwmac_socfpga_ofdata_to_platdata(struct udevice *dev)
@@ -63,6 +64,7 @@ static int dwmac_socfpga_ofdata_to_platdata(struct udevice 
*dev)
}
 
pdata->phy_intf = range + args.args[0];
+   pdata->reg_shift = args.args[1];
 
/*
 * Sadly, the Altera DT bindings don't have SoC-specific compatibles,
@@ -88,9 +90,11 @@ static int dwmac_socfpga_probe(struct udevice *dev)
struct eth_pdata *edata = >dw_eth_pdata.eth_pdata;
struct reset_ctl_bulk reset_bulk;
int ret;
-   u8 modereg;
+   u32 modereg;
+   u32 modemask;
 
-   if (pdata->type == DWMAC_SOCFPGA_ARRIA10) {
+   if (pdata->type == DWMAC_SOCFPGA_ARRIA10 ||
+   pdata->type == DWMAC_SOCFPGA_GEN5) {
switch (edata->phy_interface) {
case PHY_INTERFACE_MODE_MII:
case PHY_INTERFACE_MODE_GMII:
@@ -115,9 +119,9 @@ static int dwmac_socfpga_probe(struct udevice *dev)
 
reset_assert_bulk(_bulk);
 
-   clrsetbits_le32(pdata->phy_intf,
-   SYSMGR_EMACGRP_CTRL_PHYSEL_MASK,
-   modereg);
+   modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
+   clrsetbits_le32(pdata->phy_intf, modemask,
+   modereg << pdata->reg_shift);
 
reset_release_bulk(_bulk);
}
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/3] arm: socpfpga: gen5 clean up ETH RST & PHY mode

[Simon Goldschmidt]

Socfpga Gen5 uses ad-hoc code to unreset the ETH MACs and set their
PHY mode.

Change this to use the designware_socfpga net driver and remove the old
ad-hoc code.


Simon Goldschmidt (3):
  net: designware: socfpga: adapt to Gen5
  arm: socfpga: gen5 enable designware_socfpga
  arm: socfpga: gen5: remove hacked ETH RST handling

 .../mach-socfpga/include/mach/reset_manager.h |  2 -
 arch/arm/mach-socfpga/misc.c  | 65 ---
 arch/arm/mach-socfpga/misc_gen5.c | 44 +
 configs/socfpga_arria5_defconfig  |  3 +
 configs/socfpga_cyclone5_defconfig|  3 +
 configs/socfpga_dbm_soc1_defconfig|  3 +
 configs/socfpga_de0_nano_soc_defconfig|  3 +
 configs/socfpga_de10_nano_defconfig   |  3 +
 configs/socfpga_de1_soc_defconfig |  3 +
 configs/socfpga_is1_defconfig |  3 +
 configs/socfpga_sockit_defconfig  |  3 +
 configs/socfpga_socrates_defconfig|  3 +
 configs/socfpga_sr1500_defconfig  |  3 +
 configs/socfpga_vining_fpga_defconfig |  3 +
 drivers/net/dwmac_socfpga.c   | 14 ++--
 15 files changed, 43 insertions(+), 115 deletions(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[Heinrich Schuchardt]

On 1/10/19 10:22 AM, Alexander Graf wrote:
> 
> 
>> Am 10.01.2019 um 10:16 schrieb AKASHI Takahiro :
>>
>>> On Thu, Jan 10, 2019 at 09:15:36AM +0100, Alexander Graf wrote:
>>>
>>>
> Am 10.01.2019 um 09:02 schrieb AKASHI Takahiro 
> :
>
> On Thu, Jan 10, 2019 at 08:30:13AM +0100, Alexander Graf wrote:
>
>
>> On 10.01.19 08:26, AKASHI Takahiro wrote:
>> Alex,
>>
>>> On Thu, Jan 10, 2019 at 07:21:12AM +0100, Alexander Graf wrote:
>>>
>>>
 On 10.01.19 03:13, AKASHI Takahiro wrote:
 Alex,

> On Wed, Jan 09, 2019 at 10:06:16AM +0100, Alexander Graf wrote:
>
>
>> On 13.12.18 08:58, AKASHI Takahiro wrote:
>> Heinrich,
>>
 On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt 
 wrote:
 On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
 Currently, efi_init_obj_list() scan disk devices only once, and 
 never
 change a list of efi disk devices. This will possibly result in 
 failing
 to find a removable storage which may be added later on. See [1].

 In this patch, called is efi_disk_update() which is responsible for
 re-scanning UCLASS_BLK devices and removing/adding efi disks if 
 necessary.

 For example,

 => efishell devices
 Scanning disk pci_mmc.blk...
 Found 3 disks
 Device Name
 
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
 => usb start
 starting USB...
 USB0:   USB EHCI 1.00
 scanning bus 0 for devices... 3 USB Device(s) found
  scanning usb for storage devices... 1 Storage Device(s) found
 => efishell devices
 Scanning disk usb_mass_storage.lun0...
 Device Name
 
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)

 Without this patch, the last device, USB mass storage, won't show 
 up.

 [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html

 Signed-off-by: AKASHI Takahiro 
>>>
>>> Why should we try to fix something in the EFI subsystems that goes 
>>> wrong
>>> in the handling of device enumeration.
>>
>> No.
>> This is a natural result from how efi disks are currently 
>> implemented on u-boot.
>> Do you want to totally re-write/re-implement efi disks?
>
> Could we just make this event based for now? Call a hook from the
> storage dm subsystem when a new u-boot block device gets created to
> issue a sync of that in the efi subsystem?

 If I correctly understand you, your suggestion here corresponds
 with my proposal#3 in [1] while my current approach is #2.

 [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
>>>
>>> Yes, I think so.
>>>
 So we will call, say, efi_disk_create(struct udevice *) in
 blk_create_device() and efi_dsik_delete() in blk_unbind_all().
>>>
>>> I would prefer if we didn't call them directly, but through an event
>>> mechanism. So the efi_disk subsystem registers an event with the dm
>>> block subsystem and that will just call all events when block devices
>>> get created which will automatically also include the efi disk creation
>>> callback. Same for reverse.
>>
>> Do you mean efi event by "event?"
>> (I don't think there is any generic event interface on DM side.)
>>
>> Whatever an "event" is or whether we call efi_disk_create() directly
>> or indirectly via an event, there is one (big?) issue in this approach
>> (while I've almost finished prototyping):
>>
>> We cannot call efi_disk_create() within blk_create_device() because
>> some data fields of struct blk_desc, which are to be used by efi disk,
>> are initialized *after* blk_create_device() in driver side.
>>
>> So we need to add a hook at/after every occurrence of blk_create_device()
>> on driver side. For example,
>>
>> === drivers/scsi/scsi.c ===
>> int do_scsi_scan_one(struct udevice *dev, int id, int 

[U-Boot] [PATCH v6 20/20] usb: host: Drop [e-o]hci-sunxi drivers

[Jagan Teki]

Now Allwinner platform is all set to use Generic USB
controller drivers, so remove the legacy sunxi drivers.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/usb/host/Makefile |   2 -
 drivers/usb/host/ehci-sunxi.c | 204 -
 drivers/usb/host/ohci-sunxi.c | 233 --
 scripts/config_whitelist.txt  |   2 -
 4 files changed, 441 deletions(-)
 delete mode 100644 drivers/usb/host/ehci-sunxi.c
 delete mode 100644 drivers/usb/host/ohci-sunxi.c

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 948683a52b..6aa574f6f7 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_USB_OHCI_DA8XX) += ohci-da8xx.o
 obj-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o
 obj-$(CONFIG_USB_SL811HS) += sl811-hcd.o
 obj-$(CONFIG_USB_OHCI_EP93XX) += ohci-ep93xx.o
-obj-$(CONFIG_USB_OHCI_SUNXI) += ohci-sunxi.o
 obj-$(CONFIG_USB_OHCI_LPC32XX) += ohci-lpc32xx.o
 obj-$(CONFIG_USB_OHCI_GENERIC) += ohci-generic.o
 
@@ -37,7 +36,6 @@ obj-$(CONFIG_USB_EHCI_MARVELL) += ehci-marvell.o
 obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
 obj-$(CONFIG_USB_EHCI_SPEAR) += ehci-spear.o
-obj-$(CONFIG_USB_EHCI_SUNXI) += ehci-sunxi.o
 obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o
 obj-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o
 obj-$(CONFIG_USB_EHCI_VF) += ehci-vf.o
diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
deleted file mode 100644
index 7a79931a97..00
--- a/drivers/usb/host/ehci-sunxi.c
+++ /dev/null
@@ -1,204 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Sunxi ehci glue
- *
- * Copyright (C) 2015 Hans de Goede 
- * Copyright (C) 2014 Roman Byshko 
- *
- * Based on code from
- * Allwinner Technology Co., Ltd. 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include "ehci.h"
-#include 
-
-#ifdef CONFIG_SUNXI_GEN_SUN4I
-#define BASE_DIST  0x8000
-#define AHB_CLK_DIST   2
-#else
-#define BASE_DIST  0x1000
-#define AHB_CLK_DIST   1
-#endif
-
-#define SUN6I_AHB_RESET0_CFG_OFFSET 0x2c0
-#define SUN9I_AHB_RESET0_CFG_OFFSET 0x5a0
-
-struct ehci_sunxi_cfg {
-   bool has_reset;
-   u32 extra_ahb_gate_mask;
-   u32 reset0_cfg_offset;
-};
-
-struct ehci_sunxi_priv {
-   struct ehci_ctrl ehci;
-   struct sunxi_ccm_reg *ccm;
-   u32 *reset0_cfg;
-   int ahb_gate_mask; /* Mask of ahb_gate0 clk gate bits for this hcd */
-   struct phy phy;
-   const struct ehci_sunxi_cfg *cfg;
-};
-
-static int ehci_usb_probe(struct udevice *dev)
-{
-   struct usb_platdata *plat = dev_get_platdata(dev);
-   struct ehci_sunxi_priv *priv = dev_get_priv(dev);
-   struct ehci_hccr *hccr = (struct ehci_hccr *)devfdt_get_addr(dev);
-   struct ehci_hcor *hcor;
-   int extra_ahb_gate_mask = 0;
-   u8 reg_mask = 0;
-   int phys, ret;
-
-   priv->cfg = (const struct ehci_sunxi_cfg *)dev_get_driver_data(dev);
-   priv->ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   if (IS_ERR(priv->ccm))
-   return PTR_ERR(priv->ccm);
-
-   priv->reset0_cfg = (void *)priv->ccm +
-  priv->cfg->reset0_cfg_offset;
-
-   phys = dev_count_phandle_with_args(dev, "phys", "#phy-cells");
-   if (phys < 0) {
-   phys = 0;
-   goto no_phy;
-   }
-
-   ret = generic_phy_get_by_name(dev, "usb", >phy);
-   if (ret) {
-   pr_err("failed to get %s usb PHY\n", dev->name);
-   return ret;
-   }
-
-   ret = generic_phy_init(>phy);
-   if (ret) {
-   pr_err("failed to init %s USB PHY\n", dev->name);
-   return ret;
-   }
-
-   ret = generic_phy_power_on(>phy);
-   if (ret) {
-   pr_err("failed to power on %s USB PHY\n", dev->name);
-   return ret;
-   }
-
-no_phy:
-   /*
-* This should go away once we've moved to the driver model for
-* clocks resp. phys.
-*/
-   reg_mask = ((uintptr_t)hccr - SUNXI_USB1_BASE) / BASE_DIST;
-   priv->ahb_gate_mask = 1 << AHB_GATE_OFFSET_USB_EHCI0;
-   extra_ahb_gate_mask = priv->cfg->extra_ahb_gate_mask;
-   priv->ahb_gate_mask <<= reg_mask * AHB_CLK_DIST;
-   extra_ahb_gate_mask <<= reg_mask * AHB_CLK_DIST;
-
-   setbits_le32(>ccm->ahb_gate0,
-priv->ahb_gate_mask | extra_ahb_gate_mask);
-   if (priv->cfg->has_reset)
-   setbits_le32(priv->reset0_cfg,
-priv->ahb_gate_mask | extra_ahb_gate_mask);
-
-   hcor = (struct ehci_hcor *)((uintptr_t)hccr +
-   HC_LENGTH(ehci_readl(>cr_capbase)));
-
-   return ehci_register(dev, hccr, hcor, NULL, 0, plat->init_type);
-}
-
-static int ehci_usb_remove(struct udevice *dev)
-{
-   struct ehci_sunxi_priv *priv = dev_get_priv(dev);
-   int ret;
-
-   if 

[U-Boot] [PATCH v6 18/20] musb-new: sunxi: Use CLK and RESET support

[Jagan Teki]

Now clock and reset drivers are available for respective
SoC's so use clk and reset ops on musb driver.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
Reviewed-by: Marek Vasut 
---
 drivers/usb/musb-new/sunxi.c | 79 ++--
 1 file changed, 39 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index f3deb9bc66..906c08ece9 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -16,9 +16,11 @@
  * This file is part of the Inventra Controller Driver for Linux.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,16 +82,12 @@
 
 struct sunxi_musb_config {
struct musb_hdrc_config *config;
-   bool has_reset;
-   u8 rst_bit;
-   u8 clkgate_bit;
-   u32 off_reset0;
 };
 
 struct sunxi_glue {
struct musb_host_data mdata;
-   struct sunxi_ccm_reg *ccm;
-   u32 *reg_reset0;
+   struct clk clk;
+   struct reset_ctl rst;
struct sunxi_musb_config *cfg;
struct device dev;
struct phy phy;
@@ -296,24 +294,27 @@ static int sunxi_musb_init(struct musb *musb)
 
pr_debug("%s():\n", __func__);
 
-   ret = generic_phy_init(>phy);
+   ret = clk_enable(>clk);
if (ret) {
-   pr_err("failed to init USB PHY\n");
+   dev_err(dev, "failed to enable clock\n");
return ret;
}
 
-   musb->isr = sunxi_musb_interrupt;
-
-   setbits_le32(>ccm->ahb_gate0, BIT(AHB_GATE_OFFSET_USB0));
-   if (glue->cfg->clkgate_bit)
-   setbits_le32(>ccm->ahb_gate0,
-BIT(glue->cfg->clkgate_bit));
+   if (reset_valid(>rst)) {
+   ret = reset_deassert(>rst);
+   if (ret) {
+   dev_err(dev, "failed to deassert reset\n");
+   goto err_clk;
+   }
+   }
 
-   if (glue->cfg->has_reset)
-   setbits_le32(glue->reg_reset0, BIT(AHB_GATE_OFFSET_USB0));
+   ret = generic_phy_init(>phy);
+   if (ret) {
+   dev_err(dev, "failed to init USB PHY\n");
+   goto err_rst;
+   }
 
-   if (glue->cfg->rst_bit)
-   setbits_le32(glue->reg_reset0, BIT(glue->cfg->rst_bit));
+   musb->isr = sunxi_musb_interrupt;
 
USBC_ConfigFIFO_Base();
USBC_EnableDpDmPullUp(musb->mregs);
@@ -329,6 +330,13 @@ static int sunxi_musb_init(struct musb *musb)
USBC_ForceVbusValidToHigh(musb->mregs);
 
return 0;
+
+err_rst:
+   if (reset_valid(>rst))
+   reset_assert(>rst);
+err_clk:
+   clk_disable(>clk);
+   return ret;
 }
 
 static int sunxi_musb_exit(struct musb *musb)
@@ -344,16 +352,9 @@ static int sunxi_musb_exit(struct musb *musb)
}
}
 
-   if (glue->cfg->has_reset)
-   clrbits_le32(glue->reg_reset0, BIT(AHB_GATE_OFFSET_USB0));
-
-   if (glue->cfg->rst_bit)
-   clrbits_le32(glue->reg_reset0, BIT(glue->cfg->rst_bit));
-
-   clrbits_le32(>ccm->ahb_gate0, BIT(AHB_GATE_OFFSET_USB0));
-   if (glue->cfg->clkgate_bit)
-   clrbits_le32(>ccm->ahb_gate0,
-BIT(glue->cfg->clkgate_bit));
+   if (reset_valid(>rst))
+   reset_assert(>rst);
+   clk_disable(>clk);
 
return 0;
 }
@@ -450,11 +451,17 @@ static int musb_usb_probe(struct udevice *dev)
if (!glue->cfg)
return -EINVAL;
 
-   glue->ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   if (IS_ERR(glue->ccm))
-   return PTR_ERR(glue->ccm);
+   ret = clk_get_by_index(dev, 0, >clk);
+   if (ret) {
+   dev_err(dev, "failed to get clock\n");
+   return ret;
+   }
 
-   glue->reg_reset0 = (void *)glue->ccm + glue->cfg->off_reset0;
+   ret = reset_get_by_index(dev, 0, >rst);
+   if (ret && ret != -ENOENT) {
+   dev_err(dev, "failed to get reset\n");
+   return ret;
+   }
 
ret = generic_phy_get_by_name(dev, "usb", >phy);
if (ret) {
@@ -462,7 +469,6 @@ static int musb_usb_probe(struct udevice *dev)
return ret;
}
 
-
memset(, 0, sizeof(pdata));
pdata.power = 250;
pdata.platform_ops = _musb_ops;
@@ -505,21 +511,14 @@ static int musb_usb_remove(struct udevice *dev)
 
 static const struct sunxi_musb_config sun4i_a10_cfg = {
.config = _config,
-   .has_reset = false,
 };
 
 static const struct sunxi_musb_config sun6i_a31_cfg = {
.config = _config,
-   .has_reset = true,
-   .off_reset0 = OFF_SUN6I_AHB_RESET0,
 };
 
 static const struct sunxi_musb_config sun8i_h3_cfg = {
.config = _config_h3,
-   .has_reset = true,
-   .rst_bit = 23,
-   .clkgate_bit = 23,
-   .off_reset0 = OFF_SUN6I_AHB_RESET0,
 };
 
 static const struct udevice_id sunxi_musb_ids[] = 

[U-Boot] [PATCH v6 16/20] phy: sun4i-usb: Use CLK and RESET support

[Jagan Teki]

Now clock and reset drivers are available for respective
SoC's so use clk and reset ops on phy driver.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
Reviewed-by: Marek Vasut 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 77 ---
 1 file changed, 57 insertions(+), 20 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index a7d7e3f044..f206fa3f5d 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -11,10 +11,12 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,6 +82,7 @@ struct sun4i_usb_phy_cfg {
enum sun4i_usb_phy_type type;
u32 disc_thresh;
u8 phyctl_offset;
+   bool dedicated_clocks;
bool enable_pmu_unk1;
bool phy0_dual_route;
 };
@@ -88,30 +91,21 @@ struct sun4i_usb_phy_info {
const char *gpio_vbus;
const char *gpio_vbus_det;
const char *gpio_id_det;
-   int rst_mask;
 } phy_info[] = {
{
.gpio_vbus = CONFIG_USB0_VBUS_PIN,
.gpio_vbus_det = CONFIG_USB0_VBUS_DET,
.gpio_id_det = CONFIG_USB0_ID_DET,
-   .rst_mask = (CCM_USB_CTRL_PHY0_RST | CCM_USB_CTRL_PHY0_CLK),
},
{
.gpio_vbus = CONFIG_USB1_VBUS_PIN,
.gpio_vbus_det = NULL,
.gpio_id_det = NULL,
-   .rst_mask = (CCM_USB_CTRL_PHY1_RST | CCM_USB_CTRL_PHY1_CLK),
},
{
.gpio_vbus = CONFIG_USB2_VBUS_PIN,
.gpio_vbus_det = NULL,
.gpio_id_det = NULL,
-#ifdef CONFIG_MACH_SUN8I_A83T
-   .rst_mask = (CCM_USB_CTRL_HSIC_RST | CCM_USB_CTRL_HSIC_CLK |
-CCM_USB_CTRL_12M_CLK),
-#else
-   .rst_mask = (CCM_USB_CTRL_PHY2_RST | CCM_USB_CTRL_PHY2_CLK),
-#endif
},
{
.gpio_vbus = CONFIG_USB3_VBUS_PIN,
@@ -126,13 +120,13 @@ struct sun4i_usb_phy_plat {
int gpio_vbus;
int gpio_vbus_det;
int gpio_id_det;
-   int rst_mask;
+   struct clk clocks;
+   struct reset_ctl resets;
int id;
 };
 
 struct sun4i_usb_phy_data {
void __iomem *base;
-   struct sunxi_ccm_reg *ccm;
const struct sun4i_usb_phy_cfg *cfg;
struct sun4i_usb_phy_plat *usb_phy;
 };
@@ -266,8 +260,19 @@ static int sun4i_usb_phy_init(struct phy *phy)
struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);
struct sun4i_usb_phy_plat *usb_phy = >usb_phy[phy->id];
u32 val;
+   int ret;
 
-   setbits_le32(>ccm->usb_clk_cfg, usb_phy->rst_mask);
+   ret = clk_enable(_phy->clocks);
+   if (ret) {
+   dev_err(dev, "failed to enable usb_%ldphy clock\n", phy->id);
+   return ret;
+   }
+
+   ret = reset_deassert(_phy->resets);
+   if (ret) {
+   dev_err(dev, "failed to deassert usb_%ldreset reset\n", 
phy->id);
+   return ret;
+   }
 
if (data->cfg->type == sun8i_a83t_phy) {
if (phy->id == 0) {
@@ -308,6 +313,7 @@ static int sun4i_usb_phy_exit(struct phy *phy)
 {
struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);
struct sun4i_usb_phy_plat *usb_phy = >usb_phy[phy->id];
+   int ret;
 
if (phy->id == 0) {
if (data->cfg->type == sun8i_a83t_phy) {
@@ -320,7 +326,17 @@ static int sun4i_usb_phy_exit(struct phy *phy)
 
sun4i_usb_phy_passby(phy, false);
 
-   clrbits_le32(>ccm->usb_clk_cfg, usb_phy->rst_mask);
+   ret = clk_disable(_phy->clocks);
+   if (ret) {
+   dev_err(dev, "failed to disable usb_%ldphy clock\n", phy->id);
+   return ret;
+   }
+
+   ret = reset_assert(_phy->resets);
+   if (ret) {
+   dev_err(dev, "failed to assert usb_%ldreset reset\n", phy->id);
+   return ret;
+   }
 
return 0;
 }
@@ -407,10 +423,6 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
if (IS_ERR(data->base))
return PTR_ERR(data->base);
 
-   data->ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-   if (IS_ERR(data->ccm))
-   return PTR_ERR(data->ccm);
-
data->usb_phy = plat;
for (i = 0; i < data->cfg->num_phys; i++) {
struct sun4i_usb_phy_plat *phy = [i];
@@ -448,6 +460,24 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
sunxi_gpio_set_pull(phy->gpio_id_det, 
SUNXI_GPIO_PULL_UP);
}
 
+   if (data->cfg->dedicated_clocks)
+   snprintf(name, sizeof(name), "usb%d_phy", i);
+   else
+   strlcpy(name, "usb_phy", sizeof(name));
+
+   ret = clk_get_by_name(dev, name, >clocks);
+   if (ret) {
+   dev_err(dev, "failed to get usb%d_phy clock 

[U-Boot] [PATCH v6 17/20] reset: Add reset valid

[Jagan Teki]

Add reset_valid to check whether given reset is valid
or not.

Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
 include/reset.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/reset.h b/include/reset.h
index bc495a90c2..65aa7a4ce5 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -306,4 +306,15 @@ static inline int reset_release_bulk(struct reset_ctl_bulk 
*bulk)
 }
 #endif
 
+/**
+ * reset_valid() - check if reset is valid
+ *
+ * @reset_ctl: the reset to check
+ * @return TRUE if valid, or FALSE
+ */
+static inline bool reset_valid(struct reset_ctl *reset_ctl)
+{
+   return !!reset_ctl->dev;
+}
+
 #endif
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 19/20] sunxi: usb: Switch to Generic host controllers

[Jagan Teki]

Onc of key blocker for using USB Generic host controller
drivers in Allwinner are CLK and RESET drivers, now these
available for USB usage.

So switch sunxi USB use EHCI and OHCI Generic controllers.

Enabling USB is wisely a board choise, So Enable USB_OHCI_HCD
where it already have USB_EHCI_HCD

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 configs/A10-OLinuXino-Lime_defconfig  | 1 +
 configs/A10s-OLinuXino-M_defconfig| 1 +
 configs/A13-OLinuXinoM_defconfig  | 1 +
 configs/A13-OLinuXino_defconfig   | 1 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig| 1 +
 configs/A20-OLinuXino-Lime2_defconfig | 1 +
 configs/A20-OLinuXino-Lime_defconfig  | 1 +
 configs/A20-OLinuXino_MICRO-eMMC_defconfig| 1 +
 configs/A20-OLinuXino_MICRO_defconfig | 1 +
 configs/A20-Olimex-SOM-EVB_defconfig  | 1 +
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig  | 1 +
 configs/A20-Olimex-SOM204-EVB_defconfig   | 1 +
 configs/Auxtek-T003_defconfig | 1 +
 configs/Auxtek-T004_defconfig | 1 +
 configs/Bananapi_defconfig| 1 +
 configs/Bananapi_m2m_defconfig| 1 +
 configs/Bananapro_defconfig   | 1 +
 configs/CHIP_defconfig| 1 +
 configs/CHIP_pro_defconfig| 1 +
 configs/CSQ_CS908_defconfig   | 1 +
 configs/Colombus_defconfig| 1 +
 configs/Cubieboard2_defconfig | 1 +
 configs/Cubieboard_defconfig  | 1 +
 configs/Cubietruck_defconfig  | 1 +
 configs/Cubietruck_plus_defconfig | 1 +
 configs/Hummingbird_A31_defconfig | 1 +
 configs/Itead_Ibox_A20_defconfig  | 1 +
 configs/Lamobo_R1_defconfig   | 1 +
 configs/Linksprite_pcDuino3_Nano_defconfig| 1 +
 configs/Linksprite_pcDuino3_defconfig | 1 +
 configs/Linksprite_pcDuino_defconfig  | 1 +
 configs/MK808C_defconfig  | 1 +
 configs/Marsboard_A10_defconfig   | 1 +
 configs/Mele_A1000G_quad_defconfig| 1 +
 configs/Mele_A1000_defconfig  | 1 +
 configs/Mele_I7_defconfig | 1 +
 configs/Mele_M3_defconfig | 1 +
 configs/Mele_M5_defconfig | 1 +
 configs/Mele_M9_defconfig | 1 +
 configs/Mini-X_defconfig  | 1 +
 configs/Orangepi_defconfig| 1 +
 configs/Orangepi_mini_defconfig   | 1 +
 configs/Sinlinx_SinA31s_defconfig | 1 +
 configs/Sinlinx_SinA33_defconfig  | 1 +
 configs/Sinovoip_BPI_M2_Plus_defconfig| 1 +
 configs/Sinovoip_BPI_M2_defconfig | 1 +
 configs/Sinovoip_BPI_M3_defconfig | 1 +
 configs/Wexler_TAB7200_defconfig  | 1 +
 configs/Wits_Pro_A20_DKT_defconfig| 1 +
 configs/Wobo_i5_defconfig | 1 +
 configs/a64-olinuxino_defconfig   | 1 +
 configs/ba10_tv_box_defconfig | 1 +
 configs/bananapi_m1_plus_defconfig| 1 +
 configs/bananapi_m64_defconfig| 1 +
 configs/ga10h_v1_1_defconfig  | 1 +
 configs/h8_homlet_v2_defconfig| 1 +
 configs/i12-tvbox_defconfig   | 1 +
 configs/icnova-a20-swac_defconfig | 1 +
 configs/inet1_defconfig   | 1 +
 configs/inet_q972_defconfig   | 1 +
 configs/jesurun_q5_defconfig  | 1 +
 configs/libretech_all_h3_cc_h2_plus_defconfig | 1 +
 configs/libretech_all_h3_cc_h3_defconfig  | 1 +
 configs/libretech_all_h3_cc_h5_defconfig  | 1 +
 configs/mixtile_loftq_defconfig   | 1 +
 configs/mk802_a10s_defconfig  | 1 +
 configs/mk802_defconfig   | 1 +
 configs/mk802ii_defconfig | 1 +
 configs/nanopi_a64_defconfig  | 1 +
 configs/nanopi_m1_defconfig   | 1 +
 configs/nanopi_m1_plus_defconfig  | 1 +
 configs/nanopi_neo2_defconfig | 1 +
 configs/nanopi_neo_air_defconfig  | 1 +
 configs/nanopi_neo_defconfig  | 1 +
 configs/nanopi_neo_plus2_defconfig| 1 +
 configs/orangepi_2_defconfig  | 1 +
 configs/orangepi_lite_defconfig   | 1 +
 configs/orangepi_one_defconfig| 1 +
 configs/orangepi_pc2_defconfig| 1 +
 configs/orangepi_pc_defconfig | 1 +
 configs/orangepi_pc_plus_defconfig| 1 +
 configs/orangepi_plus2e_defconfig | 1 +
 configs/orangepi_plus_defconfig   | 1 +
 configs/orangepi_prime_defconfig  | 1 +
 configs/orangepi_r1_defconfig | 1 +
 configs/orangepi_win_defconfig| 1 +
 configs/orangepi_zero_defconfig   | 1 +
 

[U-Boot] [PATCH v6 15/20] sunxi: Enable CLK

[Jagan Teki]

CLK and DM_RESET drivers are now available for most
of the Allwinner platforms, so enable in mach-sunxi/Kconfig

Enabling CLK will select DM_RESET by default.

Signed-off-by: Jagan Teki 
---
 arch/arm/mach-sunxi/Kconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3c54f5106d..5f51bbbed0 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -132,6 +132,7 @@ endif
 
 config MACH_SUNXI_H3_H5
bool
+   select CLK
select DM_I2C
select PHY_SUN4I_USB
select SUNXI_DE2
@@ -154,6 +155,7 @@ config MACH_SUN4I
bool "sun4i (Allwinner A10)"
select CPU_V7A
select ARM_CORTEX_CPU_IS_UP
+   select CLK
select DM_MMC if MMC
select DM_SCSI if SCSI
select PHY_SUN4I_USB
@@ -165,6 +167,7 @@ config MACH_SUN5I
bool "sun5i (Allwinner A13)"
select CPU_V7A
select ARM_CORTEX_CPU_IS_UP
+   select CLK
select DRAM_SUN4I
select PHY_SUN4I_USB
select SUNXI_GEN_SUN4I
@@ -177,6 +180,7 @@ config MACH_SUN6I
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
+   select CLK
select DRAM_SUN6I
select PHY_SUN4I_USB
select SUN6I_P2WI
@@ -191,6 +195,7 @@ config MACH_SUN7I
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
+   select CLK
select DRAM_SUN4I
select PHY_SUN4I_USB
select SUNXI_GEN_SUN4I
@@ -203,6 +208,7 @@ config MACH_SUN8I_A23
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
+   select CLK
select DRAM_SUN8I_A23
select PHY_SUN4I_USB
select SUNXI_GEN_SUN6I
@@ -216,6 +222,7 @@ config MACH_SUN8I_A33
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
+   select CLK
select DRAM_SUN8I_A33
select PHY_SUN4I_USB
select SUNXI_GEN_SUN6I
@@ -226,6 +233,7 @@ config MACH_SUN8I_A33
 config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7A
+   select CLK
select DRAM_SUN8I_A83T
select PHY_SUN4I_USB
select SUNXI_GEN_SUN6I
@@ -248,6 +256,7 @@ config MACH_SUN8I_R40
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
+   select CLK
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
select SUNXI_DRAM_DW
@@ -259,6 +268,7 @@ config MACH_SUN8I_V3S
select CPU_V7_HAS_NONSEC
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
+   select CLK
select SUNXI_GEN_SUN6I
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_16BIT
@@ -277,6 +287,7 @@ config MACH_SUN9I
 config MACH_SUN50I
bool "sun50i (Allwinner A64)"
select ARM64
+   select CLK
select DM_I2C
select PHY_SUN4I_USB
select SUN6I_PRCM
@@ -300,6 +311,7 @@ config MACH_SUN50I_H5
 config MACH_SUN50I_H6
bool "sun50i (Allwinner H6)"
select ARM64
+   select CLK
select SUPPORT_SPL
select FIT
select SPL_LOAD_FIT
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 10/20] clk: sunxi: Add Allwinner V3S CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner V3S.

- Implement USB bus and USB clocks via ccu_clk_gate table
  for V3S, so it can accessed in common clk enable and disable
  functions from clk_sunxi.c
- Implement USB bus and USB resets via ccu_reset table
  for V3S, so it can accessed in common reset deassert
  and assert functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig   |  7 +
 drivers/clk/sunxi/Makefile  |  1 +
 drivers/clk/sunxi/clk_v3s.c | 51 +
 3 files changed, 59 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_v3s.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index c45a4ba378..a6f84e9e56 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -51,6 +51,13 @@ config CLK_SUN8I_R40
  This enables common clock driver support for platforms based
  on Allwinner R40 SoC.
 
+config CLK_SUN8I_V3S
+   bool "Clock driver for Allwinner V3S"
+   default MACH_SUN8I_V3S
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner V3S SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 61f8b87396..fbd43527a6 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
 obj-$(CONFIG_CLK_SUN8I_A23) += clk_a23.o
 obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
 obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
+obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_v3s.c b/drivers/clk/sunxi/clk_v3s.c
new file mode 100644
index 00..623b1601d4
--- /dev/null
+++ b/drivers/clk/sunxi/clk_v3s.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate v3s_gates[] = {
+   [CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
+
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+};
+
+static struct ccu_reset v3s_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
+};
+
+static const struct ccu_desc v3s_ccu_desc = {
+   .gates = v3s_gates,
+   .resets = v3s_resets,
+};
+
+static int v3s_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(v3s_resets));
+}
+
+static const struct udevice_id v3s_clk_ids[] = {
+   { .compatible = "allwinner,sun8i-v3s-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun8i_v3s) = {
+   .name   = "sun8i_v3s_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = v3s_clk_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = v3s_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 08/20] clk: sunxi: Add Allwinner A83T CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A83T.

- Implement USB bus and USB clocks via ccu_clk_gate table
  for A83T, so it can accessed in common clk enable and
  disable functions from clk_sunxi.c
- Implement USB bus and USB resets via ccu_reset table
  for A83T, so it can accessed in common reset deassert
  and assert functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig|  7 
 drivers/clk/sunxi/Makefile   |  1 +
 drivers/clk/sunxi/clk_a83t.c | 63 
 3 files changed, 71 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_a83t.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index 38ff99d345..90af70d171 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -37,6 +37,13 @@ config CLK_SUN8I_A23
  This enables common clock driver support for platforms based
  on Allwinner A23/A33 SoC.
 
+config CLK_SUN8I_A83T
+   bool "Clock driver for Allwinner A83T"
+   default MACH_SUN8I_A83T
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A83T SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 6924897036..4a254c8671 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_CLK_SUN4I_A10) += clk_a10.o
 obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
 obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
 obj-$(CONFIG_CLK_SUN8I_A23) += clk_a23.o
+obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a83t.c b/drivers/clk/sunxi/clk_a83t.c
new file mode 100644
index 00..3160f7f700
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a83t.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate a83t_gates[] = {
+   [CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
+   [CLK_BUS_EHCI0] = GATE(0x060, BIT(26)),
+   [CLK_BUS_EHCI1] = GATE(0x060, BIT(27)),
+   [CLK_BUS_OHCI0] = GATE(0x060, BIT(29)),
+
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
+   [CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
+   [CLK_USB_HSIC_12M]  = GATE(0x0cc, BIT(11)),
+   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(16)),
+};
+
+static struct ccu_reset a83t_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_HSIC]  = RESET(0x0cc, BIT(2)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
+   [RST_BUS_EHCI0] = RESET(0x2c0, BIT(26)),
+   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(27)),
+   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(29)),
+};
+
+static const struct ccu_desc a83t_ccu_desc = {
+   .gates = a83t_gates,
+   .resets = a83t_resets,
+};
+
+static int a83t_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(a83t_resets));
+}
+
+static const struct udevice_id a83t_clk_ids[] = {
+   { .compatible = "allwinner,sun8i-a83t-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun8i_a83t) = {
+   .name   = "sun8i_a83t_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = a83t_clk_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = a83t_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 07/20] clk: sunxi: Add Allwinner A23/A33 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A23/A33.

- Implement USB bus and USB clocks via ccu_clk_gate table
  for A23/A33, so it can accessed in common clk enable and
  disable functions from clk_sunxi.c
- Implement USB bus and USB resets via ccu_reset table
  for A23/A33, so it can accessed in common reset deassert
  and assert functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig   |  7 +
 drivers/clk/sunxi/Makefile  |  1 +
 drivers/clk/sunxi/clk_a23.c | 63 +
 3 files changed, 71 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_a23.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index 535b0dc02c..38ff99d345 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -30,6 +30,13 @@ config CLK_SUN6I_A31
  This enables common clock driver support for platforms based
  on Allwinner A31/A31s SoC.
 
+config CLK_SUN8I_A23
+   bool "Clock driver for Allwinner A23/A33"
+   default MACH_SUN8I_A23 || MACH_SUN8I_A33
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A23/A33 SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3cf0071b0c..6924897036 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
 obj-$(CONFIG_CLK_SUN4I_A10) += clk_a10.o
 obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
 obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
+obj-$(CONFIG_CLK_SUN8I_A23) += clk_a23.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
new file mode 100644
index 00..2a504ebdad
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate a23_gates[] = {
+   [CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
+   [CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
+   [CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
+
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
+   [CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
+   [CLK_USB_HSIC_12M]  = GATE(0x0cc, BIT(11)),
+   [CLK_USB_OHCI]  = GATE(0x0cc, BIT(16)),
+};
+
+static struct ccu_reset a23_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_HSIC]  = RESET(0x0cc, BIT(2)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
+   [RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
+   [RST_BUS_OHCI]  = RESET(0x2c0, BIT(29)),
+};
+
+static const struct ccu_desc a23_ccu_desc = {
+   .gates = a23_gates,
+   .resets = a23_resets,
+};
+
+static int a23_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(a23_resets));
+}
+
+static const struct udevice_id a23_clk_ids[] = {
+   { .compatible = "allwinner,sun8i-a23-ccu",
+ .data = (ulong)_ccu_desc },
+   { .compatible = "allwinner,sun8i-a33-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun8i_a23) = {
+   .name   = "sun8i_a23_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = a23_clk_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = a23_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 13/20] clk: sunxi: Add Allwinner H6 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner H6.

- Implement UART bus clocks via ccu_clk_gate table for
  H6, so it can accessed in common clk enable and disable
  functions from clk_sunxi.c
- Implement UART bus resets via ccu_reset table for H6,
  so it can accessed in common reset deassert and assert
  functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
---
 drivers/clk/sunxi/Kconfig  |  7 +
 drivers/clk/sunxi/Makefile |  1 +
 drivers/clk/sunxi/clk_h6.c | 53 ++
 3 files changed, 61 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_h6.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index a6f84e9e56..cb11c7c21e 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -65,6 +65,13 @@ config CLK_SUN8I_H3
  This enables common clock driver support for platforms based
  on Allwinner H3/H5 SoC.
 
+config CLK_SUN50I_H6
+   bool "Clock driver for Allwinner H6"
+   default MACH_SUN50I_H6
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner H6 SoC.
+
 config CLK_SUN50I_A64
bool "Clock driver for Allwinner A64"
default MACH_SUN50I
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index fbd43527a6..794aa2461c 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
 obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
 obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
+obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c
new file mode 100644
index 00..0da3a40e3d
--- /dev/null
+++ b/drivers/clk/sunxi/clk_h6.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate h6_gates[] = {
+   [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
+   [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
+   [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
+   [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
+};
+
+static struct ccu_reset h6_resets[] = {
+   [RST_BUS_UART0] = RESET(0x90c, BIT(16)),
+   [RST_BUS_UART1] = RESET(0x90c, BIT(17)),
+   [RST_BUS_UART2] = RESET(0x90c, BIT(18)),
+   [RST_BUS_UART3] = RESET(0x90c, BIT(19)),
+};
+
+static const struct ccu_desc h6_ccu_desc = {
+   .gates = h6_gates,
+   .resets = h6_resets,
+};
+
+static int h6_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(h6_resets));
+}
+
+static const struct udevice_id h6_ccu_ids[] = {
+   { .compatible = "allwinner,sun50i-h6-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun50i_h6) = {
+   .name   = "sun50i_h6_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = h6_ccu_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = h6_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 14/20] sunxi: A64: Update sun50i-a64-ccu.h

[Jagan Teki]

Update sun50i-a64-ccu.h from the Linux sunxi/dt64-for-4.20 tree:
commit 679294497be31596e1c9c61507746d72b6b05f26
Author: Rodrigo Exterckötter Tjäder 
Date:   Wed Sep 26 19:48:24 2018 +
arm64: dts: allwinner: a64: a64-olinuxino: set the PHY TX delay

This should be a part of previous sync patch from
commit 1b39a1834ed182bbd8036a5cd74a9ea111fa4691
Author: Andre Przywara 
Date:   Mon Oct 29 00:56:47 2018 +

sunxi: A64: Update .dts/.dtsi files

Signed-off-by: Jagan Teki 
---
 include/dt-bindings/clock/sun50i-a64-ccu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/clock/sun50i-a64-ccu.h 
b/include/dt-bindings/clock/sun50i-a64-ccu.h
index 370c0a0473..d66432c6e6 100644
--- a/include/dt-bindings/clock/sun50i-a64-ccu.h
+++ b/include/dt-bindings/clock/sun50i-a64-ccu.h
@@ -43,6 +43,8 @@
 #ifndef _DT_BINDINGS_CLK_SUN50I_A64_H_
 #define _DT_BINDINGS_CLK_SUN50I_A64_H_
 
+#define CLK_PLL_PERIPH011
+
 #define CLK_BUS_MIPI_DSI   28
 #define CLK_BUS_CE 29
 #define CLK_BUS_DMA30
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 05/20] clk: sunxi: Add Allwinner A10s/A13 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A10s/A13.

- Implement USB ahb and USB clocks via ccu_clk_gate table
  for A10s/A13, so it can accessed in common clk enable and
  disable functions from clk_sunxi.c
- Implement USB resets via ccu_reset table for A10s/A13,
  so it can accessed in common reset deassert and assert
  functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig|  7 +
 drivers/clk/sunxi/Makefile   |  1 +
 drivers/clk/sunxi/clk_a10s.c | 56 
 3 files changed, 64 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_a10s.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index fbbf94ef55..b228c2fa3a 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -16,6 +16,13 @@ config CLK_SUN4I_A10
  This enables common clock driver support for platforms based
  on Allwinner A10/A20 SoC.
 
+config CLK_SUN5I_A10S
+   bool "Clock driver for Allwinner A10s/A13"
+   default MACH_SUN5I
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A10s/A13 SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index bba830922f..466d4b79d6 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -7,5 +7,6 @@
 obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
 
 obj-$(CONFIG_CLK_SUN4I_A10) += clk_a10.o
+obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
new file mode 100644
index 00..bf91018fc2
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate a10s_gates[] = {
+   [CLK_AHB_OTG]   = GATE(0x060, BIT(0)),
+   [CLK_AHB_EHCI]  = GATE(0x060, BIT(1)),
+   [CLK_AHB_OHCI]  = GATE(0x060, BIT(2)),
+
+   [CLK_USB_OHCI]  = GATE(0x0cc, BIT(6)),
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
+};
+
+static struct ccu_reset a10s_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+};
+
+static const struct ccu_desc a10s_ccu_desc = {
+   .gates = a10s_gates,
+   .resets = a10s_resets,
+};
+
+static int a10s_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(a10s_resets));
+}
+
+static const struct udevice_id a10s_ccu_ids[] = {
+   { .compatible = "allwinner,sun5i-a10s-ccu",
+ .data = (ulong)_ccu_desc },
+   { .compatible = "allwinner,sun5i-a13-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun5i_a10s) = {
+   .name   = "sun5i_a10s_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = a10s_ccu_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = a10s_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 12/20] clk: sunxi: Implement UART resets

[Jagan Teki]

Implement UART resets for all relevant Allwinner SoC
clock drivers via ccu reset table.

Signed-off-by: Jagan Teki 
---
 drivers/clk/sunxi/clk_a23.c  | 6 ++
 drivers/clk/sunxi/clk_a31.c  | 7 +++
 drivers/clk/sunxi/clk_a64.c  | 6 ++
 drivers/clk/sunxi/clk_a83t.c | 6 ++
 drivers/clk/sunxi/clk_h3.c   | 5 +
 drivers/clk/sunxi/clk_r40.c  | 9 +
 drivers/clk/sunxi/clk_v3s.c  | 4 
 7 files changed, 43 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index ebe8d0002c..854259bf81 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -38,6 +38,12 @@ static struct ccu_reset a23_resets[] = {
[RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
[RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
[RST_BUS_OHCI]  = RESET(0x2c0, BIT(29)),
+
+   [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
+   [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
+   [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
+   [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
+   [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
 };
 
 static const struct ccu_desc a23_ccu_desc = {
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index 145df5c19f..a38d76cb7c 100644
--- a/drivers/clk/sunxi/clk_a31.c
+++ b/drivers/clk/sunxi/clk_a31.c
@@ -46,6 +46,13 @@ static struct ccu_reset a31_resets[] = {
[RST_AHB1_OHCI0]= RESET(0x2c0, BIT(29)),
[RST_AHB1_OHCI1]= RESET(0x2c0, BIT(30)),
[RST_AHB1_OHCI2]= RESET(0x2c0, BIT(31)),
+
+   [RST_APB2_UART0]= RESET(0x2d8, BIT(16)),
+   [RST_APB2_UART1]= RESET(0x2d8, BIT(17)),
+   [RST_APB2_UART2]= RESET(0x2d8, BIT(18)),
+   [RST_APB2_UART3]= RESET(0x2d8, BIT(19)),
+   [RST_APB2_UART4]= RESET(0x2d8, BIT(20)),
+   [RST_APB2_UART5]= RESET(0x2d8, BIT(21)),
 };
 
 static const struct ccu_desc a31_ccu_desc = {
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index 63424a9e2d..a2ba6eefc5 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -43,6 +43,12 @@ static const struct ccu_reset a64_resets[] = {
[RST_BUS_EHCI1] = RESET(0x2c0, BIT(25)),
[RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
[RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
+
+   [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
+   [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
+   [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
+   [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
+   [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
 };
 
 static const struct ccu_desc a64_ccu_desc = {
diff --git a/drivers/clk/sunxi/clk_a83t.c b/drivers/clk/sunxi/clk_a83t.c
index 76099fd154..1ef6ac5b25 100644
--- a/drivers/clk/sunxi/clk_a83t.c
+++ b/drivers/clk/sunxi/clk_a83t.c
@@ -40,6 +40,12 @@ static struct ccu_reset a83t_resets[] = {
[RST_BUS_EHCI0] = RESET(0x2c0, BIT(26)),
[RST_BUS_EHCI1] = RESET(0x2c0, BIT(27)),
[RST_BUS_OHCI0] = RESET(0x2c0, BIT(29)),
+
+   [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
+   [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
+   [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
+   [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
+   [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
 };
 
 static const struct ccu_desc a83t_ccu_desc = {
diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
index 69c2aa34a3..f82949b3b6 100644
--- a/drivers/clk/sunxi/clk_h3.c
+++ b/drivers/clk/sunxi/clk_h3.c
@@ -53,6 +53,11 @@ static struct ccu_reset h3_resets[] = {
[RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
[RST_BUS_OHCI2] = RESET(0x2c0, BIT(30)),
[RST_BUS_OHCI3] = RESET(0x2c0, BIT(31)),
+
+   [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
+   [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
+   [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
+   [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
 };
 
 static const struct ccu_desc h3_ccu_desc = {
diff --git a/drivers/clk/sunxi/clk_r40.c b/drivers/clk/sunxi/clk_r40.c
index 9a632b2603..fd7aae97ea 100644
--- a/drivers/clk/sunxi/clk_r40.c
+++ b/drivers/clk/sunxi/clk_r40.c
@@ -50,6 +50,15 @@ static struct ccu_reset r40_resets[] = {
[RST_BUS_OHCI0] = RESET(0x2c0, BIT(29)),
[RST_BUS_OHCI1] = RESET(0x2c0, BIT(30)),
[RST_BUS_OHCI2] = RESET(0x2c0, BIT(31)),
+
+   [RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
+   [RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
+   [RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
+   [RST_BUS_UART3] = RESET(0x2d8, BIT(19)),
+   [RST_BUS_UART4] = RESET(0x2d8, BIT(20)),
+   [RST_BUS_UART5] = RESET(0x2d8, BIT(21)),
+   [RST_BUS_UART6] = RESET(0x2d8, BIT(22)),
+   

[U-Boot] [PATCH v6 11/20] clk: sunxi: Implement UART clocks

[Jagan Teki]

Implement UART clocks for all Allwinner SoC
clock drivers via ccu clock gate table.

Signed-off-by: Jagan Teki 
---
 drivers/clk/sunxi/clk_a10.c  | 9 +
 drivers/clk/sunxi/clk_a10s.c | 5 +
 drivers/clk/sunxi/clk_a23.c  | 6 ++
 drivers/clk/sunxi/clk_a31.c  | 7 +++
 drivers/clk/sunxi/clk_a64.c  | 6 ++
 drivers/clk/sunxi/clk_a83t.c | 6 ++
 drivers/clk/sunxi/clk_h3.c   | 5 +
 drivers/clk/sunxi/clk_r40.c  | 9 +
 drivers/clk/sunxi/clk_v3s.c  | 4 
 9 files changed, 57 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index a8a7b7d41e..b00f51af8b 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -19,6 +19,15 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_EHCI1] = GATE(0x060, BIT(3)),
[CLK_AHB_OHCI1] = GATE(0x060, BIT(4)),
 
+   [CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
+   [CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
+   [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
+   [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
+   [CLK_APB1_UART4]= GATE(0x06c, BIT(20)),
+   [CLK_APB1_UART5]= GATE(0x06c, BIT(21)),
+   [CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
+   [CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
+
[CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
[CLK_USB_PHY]   = GATE(0x0cc, BIT(8)),
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index bf91018fc2..aa904ce067 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -17,6 +17,11 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_EHCI]  = GATE(0x060, BIT(1)),
[CLK_AHB_OHCI]  = GATE(0x060, BIT(2)),
 
+   [CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
+   [CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
+   [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
+   [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
+
[CLK_USB_OHCI]  = GATE(0x0cc, BIT(6)),
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index 2a504ebdad..ebe8d0002c 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -17,6 +17,12 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
[CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
 
+   [CLK_BUS_UART0] = GATE(0x06c, BIT(16)),
+   [CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
+   [CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
+   [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
+   [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
+
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
[CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index 723d17dff2..145df5c19f 100644
--- a/drivers/clk/sunxi/clk_a31.c
+++ b/drivers/clk/sunxi/clk_a31.c
@@ -20,6 +20,13 @@ static struct ccu_clk_gate a31_gates[] = {
[CLK_AHB1_OHCI1]= GATE(0x060, BIT(30)),
[CLK_AHB1_OHCI2]= GATE(0x060, BIT(31)),
 
+   [CLK_APB2_UART0]= GATE(0x06c, BIT(16)),
+   [CLK_APB2_UART1]= GATE(0x06c, BIT(17)),
+   [CLK_APB2_UART2]= GATE(0x06c, BIT(18)),
+   [CLK_APB2_UART3]= GATE(0x06c, BIT(19)),
+   [CLK_APB2_UART4]= GATE(0x06c, BIT(20)),
+   [CLK_APB2_UART5]= GATE(0x06c, BIT(21)),
+
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
[CLK_USB_PHY2]  = GATE(0x0cc, BIT(10)),
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index eb0a45d97f..63424a9e2d 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -19,6 +19,12 @@ static const struct ccu_clk_gate a64_gates[] = {
[CLK_BUS_OHCI0] = GATE(0x060, BIT(28)),
[CLK_BUS_OHCI1] = GATE(0x060, BIT(29)),
 
+   [CLK_BUS_UART0] = GATE(0x06c, BIT(16)),
+   [CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
+   [CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
+   [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
+   [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
+
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
[CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
diff --git a/drivers/clk/sunxi/clk_a83t.c b/drivers/clk/sunxi/clk_a83t.c
index 3160f7f700..76099fd154 100644
--- a/drivers/clk/sunxi/clk_a83t.c
+++ b/drivers/clk/sunxi/clk_a83t.c
@@ -18,6 +18,12 @@ static struct ccu_clk_gate a83t_gates[] = {
[CLK_BUS_EHCI1] = GATE(0x060, BIT(27)),

[U-Boot] [PATCH v6 09/20] clk: sunxi: Add Allwinner R40 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner R40.

- Implement USB bus and USB clocks via ccu_clk_gate
  for R40, so it can accessed in common clk enable
  and disable functions from clk_sunxi.c
- Implement USB bus and USB resets via ccu_reset table
  for R40, so it can accessed in common reset deassert
  and assert functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig   |  7 
 drivers/clk/sunxi/Makefile  |  1 +
 drivers/clk/sunxi/clk_r40.c | 70 +
 3 files changed, 78 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_r40.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index 90af70d171..c45a4ba378 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -44,6 +44,13 @@ config CLK_SUN8I_A83T
  This enables common clock driver support for platforms based
  on Allwinner A83T SoC.
 
+config CLK_SUN8I_R40
+   bool "Clock driver for Allwinner R40"
+   default MACH_SUN8I_R40
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner R40 SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 4a254c8671..61f8b87396 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,5 +11,6 @@ obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
 obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
 obj-$(CONFIG_CLK_SUN8I_A23) += clk_a23.o
 obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
+obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_r40.c b/drivers/clk/sunxi/clk_r40.c
new file mode 100644
index 00..cdf54da027
--- /dev/null
+++ b/drivers/clk/sunxi/clk_r40.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate r40_gates[] = {
+   [CLK_BUS_OTG]   = GATE(0x060, BIT(25)),
+   [CLK_BUS_EHCI0] = GATE(0x060, BIT(26)),
+   [CLK_BUS_EHCI1] = GATE(0x060, BIT(27)),
+   [CLK_BUS_EHCI2] = GATE(0x060, BIT(28)),
+   [CLK_BUS_OHCI0] = GATE(0x060, BIT(29)),
+   [CLK_BUS_OHCI1] = GATE(0x060, BIT(30)),
+   [CLK_BUS_OHCI2] = GATE(0x060, BIT(31)),
+
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
+   [CLK_USB_PHY2]  = GATE(0x0cc, BIT(10)),
+   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(16)),
+   [CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
+   [CLK_USB_OHCI2] = GATE(0x0cc, BIT(18)),
+};
+
+static struct ccu_reset r40_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_PHY2]  = RESET(0x0cc, BIT(2)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(25)),
+   [RST_BUS_EHCI0] = RESET(0x2c0, BIT(26)),
+   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(27)),
+   [RST_BUS_EHCI2] = RESET(0x2c0, BIT(28)),
+   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(29)),
+   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(30)),
+   [RST_BUS_OHCI2] = RESET(0x2c0, BIT(31)),
+};
+
+static const struct ccu_desc r40_ccu_desc = {
+   .gates = r40_gates,
+   .resets = r40_resets,
+};
+
+static int r40_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(r40_resets));
+}
+
+static const struct udevice_id r40_clk_ids[] = {
+   { .compatible = "allwinner,sun8i-r40-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun8i_r40) = {
+   .name   = "sun8i_r40_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = r40_clk_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = r40_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 06/20] clk: sunxi: Add Allwinner A31 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A31.

- Implement USB ahb1 and USB clocks via ccu_clk_gate table
  for A31, so it can accessed in common clk enable and disable
  functions from clk_sunxi.c
- Implement USB ahb1 and USB resets via ccu_reset table
  for A31, so it can accessed in common reset deassert
  and assert functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig   |  7 
 drivers/clk/sunxi/Makefile  |  1 +
 drivers/clk/sunxi/clk_a31.c | 68 +
 3 files changed, 76 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_a31.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index b228c2fa3a..535b0dc02c 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -23,6 +23,13 @@ config CLK_SUN5I_A10S
  This enables common clock driver support for platforms based
  on Allwinner A10s/A13 SoC.
 
+config CLK_SUN6I_A31
+   bool "Clock driver for Allwinner A31/A31s"
+   default MACH_SUN6I
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A31/A31s SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 466d4b79d6..3cf0071b0c 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
 
 obj-$(CONFIG_CLK_SUN4I_A10) += clk_a10.o
 obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
+obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
new file mode 100644
index 00..723d17dff2
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a31.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate a31_gates[] = {
+   [CLK_AHB1_OTG]  = GATE(0x060, BIT(24)),
+   [CLK_AHB1_EHCI0]= GATE(0x060, BIT(26)),
+   [CLK_AHB1_EHCI1]= GATE(0x060, BIT(27)),
+   [CLK_AHB1_OHCI0]= GATE(0x060, BIT(29)),
+   [CLK_AHB1_OHCI1]= GATE(0x060, BIT(30)),
+   [CLK_AHB1_OHCI2]= GATE(0x060, BIT(31)),
+
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
+   [CLK_USB_PHY2]  = GATE(0x0cc, BIT(10)),
+   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(16)),
+   [CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
+   [CLK_USB_OHCI2] = GATE(0x0cc, BIT(18)),
+};
+
+static struct ccu_reset a31_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_PHY2]  = RESET(0x0cc, BIT(2)),
+
+   [RST_AHB1_OTG]  = RESET(0x2c0, BIT(24)),
+   [RST_AHB1_EHCI0]= RESET(0x2c0, BIT(26)),
+   [RST_AHB1_EHCI1]= RESET(0x2c0, BIT(27)),
+   [RST_AHB1_OHCI0]= RESET(0x2c0, BIT(29)),
+   [RST_AHB1_OHCI1]= RESET(0x2c0, BIT(30)),
+   [RST_AHB1_OHCI2]= RESET(0x2c0, BIT(31)),
+};
+
+static const struct ccu_desc a31_ccu_desc = {
+   .gates = a31_gates,
+   .resets = a31_resets,
+};
+
+static int a31_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(a31_resets));
+}
+
+static const struct udevice_id a31_clk_ids[] = {
+   { .compatible = "allwinner,sun6i-a31-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun6i_a31) = {
+   .name   = "sun6i_a31_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = a31_clk_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = a31_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 03/20] clk: sunxi: Add Allwinner H3/H5 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner H3/H5.

- Implement USB bus and USB clocks via ccu_clk_gate table for
  H3/H5, so it can accessed in common clk enable and disable
  functions from clk_sunxi.c
- Implement USB bus and USB resets via ccu_reset table for
  H3/H5, so it can accessed in common reset deassert and assert
  functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig  |  7 
 drivers/clk/sunxi/Makefile |  1 +
 drivers/clk/sunxi/clk_h3.c | 79 ++
 3 files changed, 87 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_h3.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index 041d711e58..c3713bbac2 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -9,6 +9,13 @@ config CLK_SUNXI
 
 if CLK_SUNXI
 
+config CLK_SUN8I_H3
+   bool "Clock driver for Allwinner H3/H5"
+   default MACH_SUNXI_H3_H5
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner H3/H5 SoC.
+
 config CLK_SUN50I_A64
bool "Clock driver for Allwinner A64"
default MACH_SUN50I
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index fb20d28333..dec49f27a1 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -6,4 +6,5 @@
 
 obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
 
+obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
new file mode 100644
index 00..9ee5c33b87
--- /dev/null
+++ b/drivers/clk/sunxi/clk_h3.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate h3_gates[] = {
+   [CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
+   [CLK_BUS_EHCI0] = GATE(0x060, BIT(24)),
+   [CLK_BUS_EHCI1] = GATE(0x060, BIT(25)),
+   [CLK_BUS_EHCI2] = GATE(0x060, BIT(26)),
+   [CLK_BUS_EHCI3] = GATE(0x060, BIT(27)),
+   [CLK_BUS_OHCI0] = GATE(0x060, BIT(28)),
+   [CLK_BUS_OHCI1] = GATE(0x060, BIT(29)),
+   [CLK_BUS_OHCI2] = GATE(0x060, BIT(30)),
+   [CLK_BUS_OHCI3] = GATE(0x060, BIT(31)),
+
+   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
+   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
+   [CLK_USB_PHY2]  = GATE(0x0cc, BIT(10)),
+   [CLK_USB_PHY3]  = GATE(0x0cc, BIT(11)),
+   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(16)),
+   [CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
+   [CLK_USB_OHCI2] = GATE(0x0cc, BIT(18)),
+   [CLK_USB_OHCI3] = GATE(0x0cc, BIT(19)),
+};
+
+static struct ccu_reset h3_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_PHY2]  = RESET(0x0cc, BIT(2)),
+   [RST_USB_PHY3]  = RESET(0x0cc, BIT(3)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(23)),
+   [RST_BUS_EHCI0] = RESET(0x2c0, BIT(24)),
+   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(25)),
+   [RST_BUS_EHCI2] = RESET(0x2c0, BIT(26)),
+   [RST_BUS_EHCI3] = RESET(0x2c0, BIT(27)),
+   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
+   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
+   [RST_BUS_OHCI2] = RESET(0x2c0, BIT(30)),
+   [RST_BUS_OHCI3] = RESET(0x2c0, BIT(31)),
+};
+
+static const struct ccu_desc h3_ccu_desc = {
+   .gates = h3_gates,
+   .resets = h3_resets,
+};
+
+static int h3_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(h3_resets));
+}
+
+static const struct udevice_id h3_ccu_ids[] = {
+   { .compatible = "allwinner,sun8i-h3-ccu",
+ .data = (ulong)_ccu_desc },
+   { .compatible = "allwinner,sun50i-h5-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun8i_h3) = {
+   .name   = "sun8i_h3_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = h3_ccu_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = h3_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 04/20] clk: sunxi: Add Allwinner A10/A20 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A10/A20.

- Implement USB ahb and USB clocks via ccu_clk_gate table
  for A10/A20, so it can accessed in common clk enable and
  disable functions from clk_sunxi.c
- Implement USB resets via ccu_reset table for A10/A20,
  so it can accessed in common reset deassert and assert
  functions from reset-sunxi.c

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 drivers/clk/sunxi/Kconfig   |  7 +
 drivers/clk/sunxi/Makefile  |  1 +
 drivers/clk/sunxi/clk_a10.c | 59 +
 3 files changed, 67 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk_a10.c

diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index c3713bbac2..fbbf94ef55 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -9,6 +9,13 @@ config CLK_SUNXI
 
 if CLK_SUNXI
 
+config CLK_SUN4I_A10
+   bool "Clock driver for Allwinner A10/A20"
+   default MACH_SUN4I || MACH_SUN7I
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A10/A20 SoC.
+
 config CLK_SUN8I_H3
bool "Clock driver for Allwinner H3/H5"
default MACH_SUNXI_H3_H5
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index dec49f27a1..bba830922f 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -6,5 +6,6 @@
 
 obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
 
+obj-$(CONFIG_CLK_SUN4I_A10) += clk_a10.o
 obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
 obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
new file mode 100644
index 00..a8a7b7d41e
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct ccu_clk_gate a10_gates[] = {
+   [CLK_AHB_OTG]   = GATE(0x060, BIT(0)),
+   [CLK_AHB_EHCI0] = GATE(0x060, BIT(1)),
+   [CLK_AHB_OHCI0] = GATE(0x060, BIT(2)),
+   [CLK_AHB_EHCI1] = GATE(0x060, BIT(3)),
+   [CLK_AHB_OHCI1] = GATE(0x060, BIT(4)),
+
+   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
+   [CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
+   [CLK_USB_PHY]   = GATE(0x0cc, BIT(8)),
+};
+
+static struct ccu_reset a10_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_PHY2]  = RESET(0x0cc, BIT(2)),
+};
+
+static const struct ccu_desc a10_ccu_desc = {
+   .gates = a10_gates,
+   .resets = a10_resets,
+};
+
+static int a10_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(a10_resets));
+}
+
+static const struct udevice_id a10_ccu_ids[] = {
+   { .compatible = "allwinner,sun4i-a10-ccu",
+ .data = (ulong)_ccu_desc },
+   { .compatible = "allwinner,sun7i-a20-ccu",
+ .data = (ulong)_ccu_desc },
+   { }
+};
+
+U_BOOT_DRIVER(clk_sun4i_a10) = {
+   .name   = "sun4i_a10_ccu",
+   .id = UCLASS_CLK,
+   .of_match   = a10_ccu_ids,
+   .priv_auto_alloc_size   = sizeof(struct ccu_priv),
+   .ops= _clk_ops,
+   .probe  = sunxi_clk_probe,
+   .bind   = a10_clk_bind,
+};
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v6 02/20] reset: Add Allwinner RESET driver

[Jagan Teki]

Add common reset driver for all Allwinner SoC's.

Since CLK and RESET share common DT compatible, it is CLK driver
job is to bind the reset driver. So add CLK bind call on respective
SoC driver by passing ccu map descriptor so-that reset deassert,
deassert operations held based on ccu reset table defined from
CLK driver.

Select DM_RESET via CLK_SUNXI, this make hidden section of RESET
since CLK and RESET share common DT compatible and code.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 arch/arm/include/asm/arch-sunxi/ccu.h |  33 ++-
 drivers/clk/sunxi/Kconfig |   1 +
 drivers/clk/sunxi/clk_a64.c   |  20 +
 drivers/reset/Kconfig |   8 ++
 drivers/reset/Makefile|   1 +
 drivers/reset/reset-sunxi.c   | 124 ++
 6 files changed, 186 insertions(+), 1 deletion(-)
 create mode 100644 drivers/reset/reset-sunxi.c

diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h 
b/arch/arm/include/asm/arch-sunxi/ccu.h
index 24efe0ab0a..5dd97ab227 100644
--- a/arch/arm/include/asm/arch-sunxi/ccu.h
+++ b/arch/arm/include/asm/arch-sunxi/ccu.h
@@ -8,12 +8,14 @@
 #define _ASM_ARCH_CCU_H
 
 /**
- * enum ccu_flags - ccu clock flags
+ * enum ccu_flags - ccu clock/reset flags
  *
  * @CCU_CLK_F_IS_VALID:is given clock gate is valid?
+ * @CCU_RST_F_IS_VALID:is given reset control is valid?
  */
 enum ccu_flags {
CCU_CLK_F_IS_VALID  = BIT(0),
+   CCU_RST_F_IS_VALID  = BIT(1),
 };
 
 /**
@@ -34,13 +36,33 @@ struct ccu_clk_gate {
.flags = CCU_CLK_F_IS_VALID,\
 }
 
+/**
+ * struct ccu_reset - ccu reset
+ * @off:   reset offset
+ * @bit:   reset bit
+ * @flags: ccu reset control flags
+ */
+struct ccu_reset {
+   u16 off;
+   u32 bit;
+   enum ccu_flags flags;
+};
+
+#define RESET(_off, _bit) {\
+   .off = _off,\
+   .bit = _bit,\
+   .flags = CCU_RST_F_IS_VALID,\
+}
+
 /**
  * struct ccu_desc - clock control unit descriptor
  *
  * @gates: clock gates
+ * @resets:reset unit
  */
 struct ccu_desc {
const struct ccu_clk_gate *gates;
+   const struct ccu_reset *resets;
 };
 
 /**
@@ -62,4 +84,13 @@ int sunxi_clk_probe(struct udevice *dev);
 
 extern struct clk_ops sunxi_clk_ops;
 
+/**
+ * sunxi_reset_bind() - reset binding
+ *
+ * @dev:   reset device
+ * @count: reset count
+ * @return 0 success, or error value
+ */
+int sunxi_reset_bind(struct udevice *dev, ulong count);
+
 #endif /* _ASM_ARCH_CCU_H */
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf5ecb3801..041d711e58 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -1,6 +1,7 @@
 config CLK_SUNXI
bool "Clock support for Allwinner SoCs"
depends on CLK && ARCH_SUNXI
+   select DM_RESET
default y
help
  This enables support for common clock driver API on Allwinner
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index 803a2f711d..eb0a45d97f 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static const struct ccu_clk_gate a64_gates[] = {
[CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
@@ -26,10 +27,28 @@ static const struct ccu_clk_gate a64_gates[] = {
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
 };
 
+static const struct ccu_reset a64_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_HSIC]  = RESET(0x0cc, BIT(2)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(23)),
+   [RST_BUS_EHCI0] = RESET(0x2c0, BIT(24)),
+   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(25)),
+   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
+   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
+};
+
 static const struct ccu_desc a64_ccu_desc = {
.gates = a64_gates,
+   .resets = a64_resets,
 };
 
+static int a64_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, ARRAY_SIZE(a64_resets));
+}
+
 static const struct udevice_id a64_ccu_ids[] = {
{ .compatible = "allwinner,sun50i-a64-ccu",
  .data = (ulong)_ccu_desc },
@@ -43,4 +62,5 @@ U_BOOT_DRIVER(clk_sun50i_a64) = {
.priv_auto_alloc_size   = sizeof(struct ccu_priv),
.ops= _clk_ops,
.probe  = sunxi_clk_probe,
+   .bind   = a64_clk_bind,
 };
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 9c5208b7da..b6b40b6ce9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -106,4 +106,12 @@ config RESET_SOCFPGA
help
  Support for reset controller on SoCFPGA platform.
 
+config RESET_SUNXI
+   bool "RESET support for Allwinner SoCs"
+   

[U-Boot] [PATCH v6 01/20] clk: Add Allwinner A64 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A64.

Implement USB clock enable and disable functions for
OHCI, EHCI, OTG and USBPHY gate and clock registers
via ccu clk gate table.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
 arch/arm/include/asm/arch-sunxi/ccu.h | 65 +++
 drivers/clk/Kconfig   |  1 +
 drivers/clk/Makefile  |  1 +
 drivers/clk/sunxi/Kconfig | 18 +++
 drivers/clk/sunxi/Makefile|  9 
 drivers/clk/sunxi/clk_a64.c   | 46 +
 drivers/clk/sunxi/clk_sunxi.c | 74 +++
 7 files changed, 214 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-sunxi/ccu.h
 create mode 100644 drivers/clk/sunxi/Kconfig
 create mode 100644 drivers/clk/sunxi/Makefile
 create mode 100644 drivers/clk/sunxi/clk_a64.c
 create mode 100644 drivers/clk/sunxi/clk_sunxi.c

diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h 
b/arch/arm/include/asm/arch-sunxi/ccu.h
new file mode 100644
index 00..24efe0ab0a
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/ccu.h
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#ifndef _ASM_ARCH_CCU_H
+#define _ASM_ARCH_CCU_H
+
+/**
+ * enum ccu_flags - ccu clock flags
+ *
+ * @CCU_CLK_F_IS_VALID:is given clock gate is valid?
+ */
+enum ccu_flags {
+   CCU_CLK_F_IS_VALID  = BIT(0),
+};
+
+/**
+ * struct ccu_clk_gate - ccu clock gate
+ * @off:   gate offset
+ * @bit:   gate bit
+ * @flags: ccu clock gate flags
+ */
+struct ccu_clk_gate {
+   u16 off;
+   u32 bit;
+   enum ccu_flags flags;
+};
+
+#define GATE(_off, _bit) { \
+   .off = _off,\
+   .bit = _bit,\
+   .flags = CCU_CLK_F_IS_VALID,\
+}
+
+/**
+ * struct ccu_desc - clock control unit descriptor
+ *
+ * @gates: clock gates
+ */
+struct ccu_desc {
+   const struct ccu_clk_gate *gates;
+};
+
+/**
+ * struct ccu_priv - sunxi clock control unit
+ *
+ * @base:  base address
+ * @desc:  ccu descriptor
+ */
+struct ccu_priv {
+   void *base;
+   const struct ccu_desc *desc;
+};
+
+/**
+ * sunxi_clk_probe - common sunxi clock probe
+ * @dev:   clock device
+ */
+int sunxi_clk_probe(struct udevice *dev);
+
+extern struct clk_ops sunxi_clk_ops;
+
+#endif /* _ASM_ARCH_CCU_H */
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index eadf7f8250..51c931b906 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -104,6 +104,7 @@ source "drivers/clk/imx/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/owl/Kconfig"
 source "drivers/clk/renesas/Kconfig"
+source "drivers/clk/sunxi/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 9acbb1a650..6a4ff9143b 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_OWL) += owl/
 obj-$(CONFIG_CLK_RENESAS) += renesas/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
 obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
 obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
new file mode 100644
index 00..bf5ecb3801
--- /dev/null
+++ b/drivers/clk/sunxi/Kconfig
@@ -0,0 +1,18 @@
+config CLK_SUNXI
+   bool "Clock support for Allwinner SoCs"
+   depends on CLK && ARCH_SUNXI
+   default y
+   help
+ This enables support for common clock driver API on Allwinner
+ SoCs.
+
+if CLK_SUNXI
+
+config CLK_SUN50I_A64
+   bool "Clock driver for Allwinner A64"
+   default MACH_SUN50I
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A64 SoC.
+
+endif # CLK_SUNXI
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
new file mode 100644
index 00..fb20d28333
--- /dev/null
+++ b/drivers/clk/sunxi/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2018 Amarula Solutions.
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
+
+obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
new file mode 100644
index 00..803a2f711d
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct ccu_clk_gate a64_gates[] = {
+   [CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
+   [CLK_BUS_EHCI0] = GATE(0x060, BIT(24)),
+   [CLK_BUS_EHCI1] = GATE(0x060, BIT(25)),

[U-Boot] [PATCH v6 00/20] clk: Add Allwinner CLK, RESET support

[Jagan Teki]

This series fixes few comments from previous verision for Allwinner
clock gates, resets and dropped clock tree patches which I have 
mentioned on previous series[1].

Changes for v6:
- use ARRAY_SIZE for reset array instead of number
- remove comment from sunxi_reset_request
- Enable CONFIG_USB_OHCI_HCD on few missing boards
- collect Marek Acked-by

Any inputs,
Jagan.

[1] https://patchwork.ozlabs.org/cover/1019654/

Jagan Teki (20):
  clk: Add Allwinner A64 CLK driver
  reset: Add Allwinner RESET driver
  clk: sunxi: Add Allwinner H3/H5 CLK driver
  clk: sunxi: Add Allwinner A10/A20 CLK driver
  clk: sunxi: Add Allwinner A10s/A13 CLK driver
  clk: sunxi: Add Allwinner A31 CLK driver
  clk: sunxi: Add Allwinner A23/A33 CLK driver
  clk: sunxi: Add Allwinner A83T CLK driver
  clk: sunxi: Add Allwinner R40 CLK driver
  clk: sunxi: Add Allwinner V3S CLK driver
  clk: sunxi: Implement UART clocks
  clk: sunxi: Implement UART resets
  clk: sunxi: Add Allwinner H6 CLK driver
  sunxi: A64: Update sun50i-a64-ccu.h
  sunxi: Enable CLK
  phy: sun4i-usb: Use CLK and RESET support
  reset: Add reset valid
  musb-new: sunxi: Use CLK and RESET support
  sunxi: usb: Switch to Generic host controllers
  usb: host: Drop [e-o]hci-sunxi drivers

 arch/arm/include/asm/arch-sunxi/ccu.h |  96 
 arch/arm/mach-sunxi/Kconfig   |  12 +
 configs/A10-OLinuXino-Lime_defconfig  |   1 +
 configs/A10s-OLinuXino-M_defconfig|   1 +
 configs/A13-OLinuXinoM_defconfig  |   1 +
 configs/A13-OLinuXino_defconfig   |   1 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig|   1 +
 configs/A20-OLinuXino-Lime2_defconfig |   1 +
 configs/A20-OLinuXino-Lime_defconfig  |   1 +
 configs/A20-OLinuXino_MICRO-eMMC_defconfig|   1 +
 configs/A20-OLinuXino_MICRO_defconfig |   1 +
 configs/A20-Olimex-SOM-EVB_defconfig  |   1 +
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig  |   1 +
 configs/A20-Olimex-SOM204-EVB_defconfig   |   1 +
 configs/Auxtek-T003_defconfig |   1 +
 configs/Auxtek-T004_defconfig |   1 +
 configs/Bananapi_defconfig|   1 +
 configs/Bananapi_m2m_defconfig|   1 +
 configs/Bananapro_defconfig   |   1 +
 configs/CHIP_defconfig|   1 +
 configs/CHIP_pro_defconfig|   1 +
 configs/CSQ_CS908_defconfig   |   1 +
 configs/Colombus_defconfig|   1 +
 configs/Cubieboard2_defconfig |   1 +
 configs/Cubieboard_defconfig  |   1 +
 configs/Cubietruck_defconfig  |   1 +
 configs/Cubietruck_plus_defconfig |   1 +
 configs/Hummingbird_A31_defconfig |   1 +
 configs/Itead_Ibox_A20_defconfig  |   1 +
 configs/Lamobo_R1_defconfig   |   1 +
 configs/Linksprite_pcDuino3_Nano_defconfig|   1 +
 configs/Linksprite_pcDuino3_defconfig |   1 +
 configs/Linksprite_pcDuino_defconfig  |   1 +
 configs/MK808C_defconfig  |   1 +
 configs/Marsboard_A10_defconfig   |   1 +
 configs/Mele_A1000G_quad_defconfig|   1 +
 configs/Mele_A1000_defconfig  |   1 +
 configs/Mele_I7_defconfig |   1 +
 configs/Mele_M3_defconfig |   1 +
 configs/Mele_M5_defconfig |   1 +
 configs/Mele_M9_defconfig |   1 +
 configs/Mini-X_defconfig  |   1 +
 configs/Orangepi_defconfig|   1 +
 configs/Orangepi_mini_defconfig   |   1 +
 configs/Sinlinx_SinA31s_defconfig |   1 +
 configs/Sinlinx_SinA33_defconfig  |   1 +
 configs/Sinovoip_BPI_M2_Plus_defconfig|   1 +
 configs/Sinovoip_BPI_M2_defconfig |   1 +
 configs/Sinovoip_BPI_M3_defconfig |   1 +
 configs/Wexler_TAB7200_defconfig  |   1 +
 configs/Wits_Pro_A20_DKT_defconfig|   1 +
 configs/Wobo_i5_defconfig |   1 +
 configs/a64-olinuxino_defconfig   |   1 +
 configs/ba10_tv_box_defconfig |   1 +
 configs/bananapi_m1_plus_defconfig|   1 +
 configs/bananapi_m64_defconfig|   1 +
 configs/ga10h_v1_1_defconfig  |   1 +
 configs/h8_homlet_v2_defconfig|   1 +
 configs/i12-tvbox_defconfig   |   1 +
 configs/icnova-a20-swac_defconfig |   1 +
 configs/inet1_defconfig   |   1 +
 configs/inet_q972_defconfig   |   1 +
 configs/jesurun_q5_defconfig  |   1 +
 configs/libretech_all_h3_cc_h2_plus_defconfig |   1 +
 configs/libretech_all_h3_cc_h3_defconfig  |   1 +
 configs/libretech_all_h3_cc_h5_defconfig  |   1 +
 configs/mixtile_loftq_defconfig   |   1 +
 configs/mk802_a10s_defconfig  |   1 +
 

Re: [U-Boot] [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support

[Jagan Teki]

On Thu, Jan 10, 2019 at 6:21 AM André Przywara  wrote:
>
> On 08/01/2019 19:12, Jagan Teki wrote:
> > On Tue, Jan 8, 2019 at 5:09 PM Andre Przywara  
> > wrote:
> >>
> >> On Tue, 8 Jan 2019 16:27:14 +0530
> >> Jagan Teki  wrote:
> >>
> >> Hi,
> >>
> >>> On Mon, Jan 7, 2019 at 6:35 AM André Przywara
> >>>  wrote:
> 
>  On 31/12/2018 16:59, Jagan Teki wrote:
> > Clock control unit comprises of parent clocks, gates,
> > multiplexers, dividers, multipliers, pre/post dividers and flags
> > etc.
> >
> > So, the U-Boot implementation of ccu has divided into gates and
> > tree. gates are generic clock configuration of enable/disable bit
> > management which can be handle via ccu_clock_gate.
> 
>  So if I understand this correctly, you implement the gate
>  functionality separately from the complex clock code, even if they
>  are the same clock from the DT point of view? So if one wants to
>  enable the MMC0 clock, which is a mux/divider clock, one needs to
>  specify an extra entry in the gate array to describe the enable bit
>  in this special clock register? Sounds a bit surprising, but is
>  probably a neat trick to keep things simple. There should be a
>  comment in the code to this regard then.
> >>>
> >>> Exactly. Idea is to keep the macro's as simple as possible.
> >>>
> >>> Adding gates clocks separately make easy and reasonable way to
> >>> enable/disable clock operations. We even operate with single macro
> >>> with all clock attributes along with gate(either another member or
> >>> common structure like Linux does), but that seems not simple as per as
> >>> my experince since there are many IP's like USB's just need
> >>> enable/disable.
> >>>
> 
> > Tree clocks are parent clock type, fixed clocks, mp, nk, nkm,
> > nkmp, pre/post div, flags etc. which were managed via
> > ccu_clock_tree.
> 
>  For a start, can we use more descriptive names than those very
>  specific MP/NK names? DIV_MUX and PLL sound more descriptive to me.
>  I understand that Linux uses those terms, but it would be great if
>  uninitiated people have a chance to understand this as well.
> 
> > This patch add support for MP, NK, MISC, FIXED clock types as
> > part of ccu clock tree with get_rate functionality this
> > eventually used by uart driver. and rest of the infrastructure
> > will try to add while CLK is being used on respective peripherals.
> >
> > Note that few of the tree type clock would require to enable
> > gates on their specific clock, in that case we need to add the
> > gate details via ccu_clock_gate, example: MP with gate so the
> > gate offset, bit value should add as part of ccu_clock_gate.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> >  arch/arm/include/asm/arch-sunxi/ccu.h | 192
> > +- drivers/clk/sunxi/clk_a64.c
> > |  40 ++ drivers/clk/sunxi/clk_sunxi.c | 182
> >  3 files changed, 413 insertions(+), 1
> > deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h
> > b/arch/arm/include/asm/arch-sunxi/ccu.h index
> > 3fdc26978d..61b8c36b3b 100644 ---
> > a/arch/arm/include/asm/arch-sunxi/ccu.h +++
> > b/arch/arm/include/asm/arch-sunxi/ccu.h @@ -7,15 +7,204 @@
> >  #ifndef _ASM_ARCH_CCU_H
> >  #define _ASM_ARCH_CCU_H
> >
> > +#define OSC_32K_ULL  32000ULL
> 
>  32768
> 
>  And why ULL? The whole Allwinner clock system works with 32-bit
>  values, so just U would be totally sufficient. This avoid blowing
>  this up to 64 bit unnecessarily, which sounds painful for those
>  poor ARMv7 parts.
> > +#define OSC_24M_ULL  2400ULL
> > +
> > +/**
> > + * enum ccu_clk_type - ccu clock types
> > + *
> > + * @CCU_CLK_TYPE_MISC:   misc clock type
> 
>  What is MISC, exactly? Seems like an artefact clock to me, some
>  placeholder you need because gate clocks are handled separately in
>  the gates struct. Should this be called something with SIMPLE
>  instead, or GATE?
> >>>
> >>> Unlike MP type in MMC, UART doesn't need any clock attributes like
> >>> dividers, mux, etc, just have attached parent. I don't think UART
> >>> clock is simple one It has parent, that indeed have another parents
> >>> and so...on, ie reason I named as MISC.
> >>
> >> Not really, as far as I can see the UART clock is a just a gate clock as
> >> many others, with one parent (APB2).
> >> The fact that APB2 in turn can have multiple parents doesn't affect the
> >> UART clock itself, as you model this via the clock tree.
> >>
> >> In fact we could have similar clocks in the tree structure for the
> >> other gate clocks (USB, for instance), it's just that the UART is the
> >> only user so far which actually queries the clock rate.
> >>
> >> So MISC is way 

Re: [U-Boot] [PATCH v4 1/6] pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family

[Daniel Schwierzeck]

Hi Horatio,

Am 10.01.19 um 15:11 schrieb Gregory CLEMENT:
> Hi Horatiu,
>  
>  On jeu., janv. 10 2019, Horatiu Vultur  wrote:
> 
>> The Jaguar2 SOC family has 63 gpio pins therefore I extended mscc-common
>> to support new numbe of pins and remove any platform dependency from
>> mscc-common.
>>
>> Signed-off-by: Horatiu Vultur 
>> ---
>>  MAINTAINERS   |   1 +
>>  drivers/pinctrl/mscc/Kconfig  |   9 +
>>  drivers/pinctrl/mscc/Makefile |   1 +
>>  drivers/pinctrl/mscc/mscc-common.c|  90 +++---
>>  drivers/pinctrl/mscc/mscc-common.h|  17 +-
>>  drivers/pinctrl/mscc/pinctrl-jr2.c| 315 
>> ++
>>  drivers/pinctrl/mscc/pinctrl-luton.c  |  16 +-
>>  drivers/pinctrl/mscc/pinctrl-ocelot.c |  16 +-
>>  8 files changed, 436 insertions(+), 29 deletions(-)
>>  create mode 100644 drivers/pinctrl/mscc/pinctrl-jr2.c
>>

this series looks now good to me but you should address Gregory's
comments. I didn't review the device-trees in detail as I expected that
you use the Linux versions which already had a proper review.

-- 
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [u-boot][PATCH] ls1046aqds: Bypass xfi port fixup for KR mode

[York Sun]

On 12/10/18 1:27 AM, Florinel Iordache wrote:
> u-boot makes a fixup for LS1046AQDS board to setup the properties
>  'fixed-link' and 'phy-connection-type' to 'xgmii' but in case of
>  backplane mode this fixup is not correct because it causes the KR link
>  to fail and so it must be bypassed in order to keep the link in KR mode
>  as it is defined in DTS.
> 
> Signed-off-by: Florinel Iordache 
> ---
>  board/freescale/ls1046aqds/eth.c | 35 +--
>  1 file changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/board/freescale/ls1046aqds/eth.c 
> b/board/freescale/ls1046aqds/eth.c
> index d3e8831..1fd755c 100644
> --- a/board/freescale/ls1046aqds/eth.c
> +++ b/board/freescale/ls1046aqds/eth.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2016 Freescale Semiconductor, Inc.
> + * Copyright 2018 NXP
>   */
>  
>  #include 
> @@ -153,6 +154,9 @@ void board_ft_fman_fixup_port(void *fdt, char *compat, 
> phys_addr_t addr,
> enum fm_port port, int offset)
>  {
>   struct fixed_link f_link;
> + u32 *handle;
> + char *prop = NULL;
> + int off;
>  
>   if (fm_info_get_enet_if(port) == PHY_INTERFACE_MODE_SGMII) {
>   switch (port) {
> @@ -208,16 +212,27 @@ void board_ft_fman_fixup_port(void *fdt, char *compat, 
> phys_addr_t addr,
>  "qsgmii");
>   } else if (fm_info_get_enet_if(port) == PHY_INTERFACE_MODE_XGMII &&
>  (port == FM1_10GEC1 || port == FM1_10GEC2)) {
> - /* XFI interface */
> - f_link.phy_id = cpu_to_fdt32(port);
> - f_link.duplex = cpu_to_fdt32(1);
> - f_link.link_speed = cpu_to_fdt32(1);
> - f_link.pause = 0;
> - f_link.asym_pause = 0;
> - /* no PHY for XFI */
> - fdt_delprop(fdt, offset, "phy-handle");
> - fdt_setprop(fdt, offset, "fixed-link", _link, sizeof(f_link));
> - fdt_setprop_string(fdt, offset, "phy-connection-type", "xgmii");
> + handle = fdt_getprop(fdt, offset, "phy-handle", NULL);

warning: assignment discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]

Pleas fix.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> Am 10.01.2019 um 16:56 schrieb Tom Rini:
> >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic  wrote:
> >>>
> >>>Hi Tom, Soeren,
> >>>
> >>>On 09/01/19 23:39, Tom Rini wrote:
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >Hi Soeren,
> >
> >On 08/01/19 12:03, Soeren Moch wrote:
> >>Hi Stefano,
> >>
> >>On 08.01.19 11:24, Stefano Babic wrote:
> >>>Hi Soeren,
> >>>
> >>>On 08/01/19 11:14, Soeren Moch wrote:
> Stefano,
> 
> can you apply this for v2019.01? This is really a important fix to 
> avoid
>   environment and u-boot binary overwriting each other.
> It is also a small local fix which cannot hurt anybody else.
> >>>I will apply and I send a new PR. This is not the first fix in this
> >>>direction, u-boot becomes pretty large, it is becoming a common 
> >>>problem.
> >>>
> >>Thank you very much.
> >>
> >>Yes, "in the good old days (tm)" there was much effort put into not
> >>increasing the binary size for existing boards when adding new features.
> >
> >Right, fully agree.
> >
> >>Unfortunately this is not true anymore.
> >
> >I get in the same trouble with more as one project. A previous rule of
> >thumb was to reserve 512KB to the bootloader because it was pretty
> >unthinkable that bootloader could be larger. Mhmmhhthis remember me
> >someone else who said that 640Kb is enough for everything.
> >
> >Anyway, as you noted, this is a big problem in field and it makes
> >difficult an upgrade without returning back the device to factory, what
> >nobody wants.
> 
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.
> >>>
> >>>I am not sure if we should point to EFI as responsible for the increased
> >>>footprint or it is due to the sum of several components / factors. I
> >>>just report my experience in last month : I had to port U-Boot for a
> >>>customer from a not very old release (2017.01) to the current. 2017.01
> >>>had already (apart of FIT support) all features the customer needed, but
> >>>there are issues(NAND, UBI) and I kew that they were solved later.
> >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> >>>a lot in board code, but of course I had to reconfigure a lot. At the
> >>>end, everything worked but I was quite astonished about footprint. I had:
> >>>
> >>>2017.01 u-boot.bin 443452
> >>>2018.11 u-boot.bin 654684
> >>>
> >>>  But the new footprint overwrote the space for the env, and I had to
> >>>change the layout.It was not something that I could not manage and in
> >>>this specific case, customer could handle it. I cannot say I did
> >>>something pretty wrong to bloat the bootloader, so my feeling was that
> >>>there is not a specific part responsible for the increased size, but
> >>>each component is slightly bigger and they sizes sum at the end.
> >>>
> >>>
>   Why default?  Well, "everyone"
> agrees that defaulting to EFI application support means the widest
> choice of out of the box software support.
> >>>
> >>>I am unsure about this - just my two cents.
> >>>
> >>>I agree with you if we are talking about evaluation boards and / or
> >>>boards supposed to run different distros (or in any case, more flavour
> >>>of software).
> >>>
> >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> >>>for a specific project and won't run any other kind of software. If a
> >>>device is a navigation system, a network controller, or whatever, it
> >>>will just do this job until its EOL.
> >>>
> >>>Specially for older boards, a new feature should not be activated as
> >>>default. At the beginning, police in U-Boot was to set just what should
> >>>be required in the bootloader, without setting what is not needed as
> >>>default. So default was off instead of on.
> >>
> >>I aslo think that would suit U-Boot better. For example, I have one
> >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> >>currently means I have to re-check the defconfig for every update to
> >>disable new features that are now on by default. I think having those
> >>default to off and enabling them via defconfig if required would be better.
> >
> >Can SoCFPGA not set the option to make a link failure if you grow beyond
> >204KiB?  As part of this thread, the only new default y thing since
> >v2018.01 at least is CRC16-CCITT support in "hash".
> 
> Well, this is a non-mainline config. Plus I keep having problems with the
> size check in that it does not account for the DTB. Wait, that was for 

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

Am 10.01.2019 um 16:56 schrieb Tom Rini:

On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:

On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic  wrote:


Hi Tom, Soeren,

On 09/01/19 23:39, Tom Rini wrote:

On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:

Hi Soeren,

On 08/01/19 12:03, Soeren Moch wrote:

Hi Stefano,

On 08.01.19 11:24, Stefano Babic wrote:

Hi Soeren,

On 08/01/19 11:14, Soeren Moch wrote:

Stefano,

can you apply this for v2019.01? This is really a important fix to avoid
  environment and u-boot binary overwriting each other.
It is also a small local fix which cannot hurt anybody else.

I will apply and I send a new PR. This is not the first fix in this
direction, u-boot becomes pretty large, it is becoming a common problem.


Thank you very much.

Yes, "in the good old days (tm)" there was much effort put into not
increasing the binary size for existing boards when adding new features.


Right, fully agree.


Unfortunately this is not true anymore.


I get in the same trouble with more as one project. A previous rule of
thumb was to reserve 512KB to the bootloader because it was pretty
unthinkable that bootloader could be larger. Mhmmhhthis remember me
someone else who said that 640Kb is enough for everything.

Anyway, as you noted, this is a big problem in field and it makes
difficult an upgrade without returning back the device to factory, what
nobody wants.


So, this is more on me, so I should probably explain a little, and point
at the biggest culprit too.  The biggest at times culprit and sometimes
controversial thing is that we default to the EFI subsystem being on by
default.  This is 50KiB on tbs2910.


I am not sure if we should point to EFI as responsible for the increased
footprint or it is due to the sum of several components / factors. I
just report my experience in last month : I had to port U-Boot for a
customer from a not very old release (2017.01) to the current. 2017.01
had already (apart of FIT support) all features the customer needed, but
there are issues(NAND, UBI) and I kew that they were solved later.
Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
a lot in board code, but of course I had to reconfigure a lot. At the
end, everything worked but I was quite astonished about footprint. I had:

2017.01 u-boot.bin 443452
2018.11 u-boot.bin 654684

  But the new footprint overwrote the space for the env, and I had to
change the layout.It was not something that I could not manage and in
this specific case, customer could handle it. I cannot say I did
something pretty wrong to bloat the bootloader, so my feeling was that
there is not a specific part responsible for the increased size, but
each component is slightly bigger and they sizes sum at the end.



  Why default?  Well, "everyone"
agrees that defaulting to EFI application support means the widest
choice of out of the box software support.


I am unsure about this - just my two cents.

I agree with you if we are talking about evaluation boards and / or
boards supposed to run different distros (or in any case, more flavour
of software).

But there are a lot of "custom" boards (maintained in U-Boot) that runs
for a specific project and won't run any other kind of software. If a
device is a navigation system, a network controller, or whatever, it
will just do this job until its EOL.

Specially for older boards, a new feature should not be activated as
default. At the beginning, police in U-Boot was to set just what should
be required in the bootloader, without setting what is not needed as
default. So default was off instead of on.


I aslo think that would suit U-Boot better. For example, I have one
configuration where I need to squeeze U-Boot into 204 KiB. For me this
currently means I have to re-check the defconfig for every update to
disable new features that are now on by default. I think having those
default to off and enabling them via defconfig if required would be better.


Can SoCFPGA not set the option to make a link failure if you grow beyond
204KiB?  As part of this thread, the only new default y thing since
v2018.01 at least is CRC16-CCITT support in "hash".


Well, this is a non-mainline config. Plus I keep having problems with 
the size check in that it does not account for the DTB. Wait, that was 
for SPL, how do you enable a size check for U-Boot?


Anyway, if new default y things aren't the problem, it's probably an 
increasement here and there, like Stefano said... :-(


Thanks,
Simon

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pylibfdt: Use Python 2 in Makefile

[Tom Rini]

On Thu, Jan 10, 2019 at 05:56:56AM -0700, Simon Glass wrote:
> On Tue, 8 Jan 2019 at 06:19, Josef Lusticky  wrote:
> >
> > pylibfdt needs Python 2 to build.
> > Replace $(PYTHON) with $(PYTHON2) in pylibfdt Makefile
> > to ensure Python 2 is used to build it.
> >
> > This fixes build on systems where Python 3 is the default version
> > of the "python" interpreter.
> > ---
> >  scripts/dtc/pylibfdt/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> Reviewed-by: Simon Glass 
> 
> At some point we should sync this with upstream which I think plans to
> support both.

Given the impending death of Python2, that's good news.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic  wrote:
> >
> > Hi Tom, Soeren,
> >
> > On 09/01/19 23:39, Tom Rini wrote:
> > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > >> Hi Soeren,
> > >>
> > >> On 08/01/19 12:03, Soeren Moch wrote:
> > >>> Hi Stefano,
> > >>>
> > >>> On 08.01.19 11:24, Stefano Babic wrote:
> >  Hi Soeren,
> > 
> >  On 08/01/19 11:14, Soeren Moch wrote:
> > > Stefano,
> > >
> > > can you apply this for v2019.01? This is really a important fix to 
> > > avoid
> > >  environment and u-boot binary overwriting each other.
> > > It is also a small local fix which cannot hurt anybody else.
> >  I will apply and I send a new PR. This is not the first fix in this
> >  direction, u-boot becomes pretty large, it is becoming a common 
> >  problem.
> > 
> > >>> Thank you very much.
> > >>>
> > >>> Yes, "in the good old days (tm)" there was much effort put into not
> > >>> increasing the binary size for existing boards when adding new features.
> > >>
> > >> Right, fully agree.
> > >>
> > >>> Unfortunately this is not true anymore.
> > >>
> > >> I get in the same trouble with more as one project. A previous rule of
> > >> thumb was to reserve 512KB to the bootloader because it was pretty
> > >> unthinkable that bootloader could be larger. Mhmmhhthis remember me
> > >> someone else who said that 640Kb is enough for everything.
> > >>
> > >> Anyway, as you noted, this is a big problem in field and it makes
> > >> difficult an upgrade without returning back the device to factory, what
> > >> nobody wants.
> > >
> > > So, this is more on me, so I should probably explain a little, and point
> > > at the biggest culprit too.  The biggest at times culprit and sometimes
> > > controversial thing is that we default to the EFI subsystem being on by
> > > default.  This is 50KiB on tbs2910.
> >
> > I am not sure if we should point to EFI as responsible for the increased
> > footprint or it is due to the sum of several components / factors. I
> > just report my experience in last month : I had to port U-Boot for a
> > customer from a not very old release (2017.01) to the current. 2017.01
> > had already (apart of FIT support) all features the customer needed, but
> > there are issues(NAND, UBI) and I kew that they were solved later.
> > Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > a lot in board code, but of course I had to reconfigure a lot. At the
> > end, everything worked but I was quite astonished about footprint. I had:
> >
> > 2017.01 u-boot.bin 443452
> > 2018.11 u-boot.bin 654684
> >
> >  But the new footprint overwrote the space for the env, and I had to
> > change the layout.It was not something that I could not manage and in
> > this specific case, customer could handle it. I cannot say I did
> > something pretty wrong to bloat the bootloader, so my feeling was that
> > there is not a specific part responsible for the increased size, but
> > each component is slightly bigger and they sizes sum at the end.
> >
> >
> > >  Why default?  Well, "everyone"
> > > agrees that defaulting to EFI application support means the widest
> > > choice of out of the box software support.
> >
> > I am unsure about this - just my two cents.
> >
> > I agree with you if we are talking about evaluation boards and / or
> > boards supposed to run different distros (or in any case, more flavour
> > of software).
> >
> > But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > for a specific project and won't run any other kind of software. If a
> > device is a navigation system, a network controller, or whatever, it
> > will just do this job until its EOL.
> >
> > Specially for older boards, a new feature should not be activated as
> > default. At the beginning, police in U-Boot was to set just what should
> > be required in the bootloader, without setting what is not needed as
> > default. So default was off instead of on.
> 
> I aslo think that would suit U-Boot better. For example, I have one
> configuration where I need to squeeze U-Boot into 204 KiB. For me this
> currently means I have to re-check the defconfig for every update to
> disable new features that are now on by default. I think having those
> default to off and enabling them via defconfig if required would be better.

Can SoCFPGA not set the option to make a link failure if you grow beyond
204KiB?  As part of this thread, the only new default y thing since
v2018.01 at least is CRC16-CCITT support in "hash".

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> Hi Tom, Soeren,
> 
> On 09/01/19 23:39, Tom Rini wrote:
[snip]
> >  Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
> 
> I am unsure about this - just my two cents.
> 
> I agree with you if we are talking about evaluation boards and / or
> boards supposed to run different distros (or in any case, more flavour
> of software).
> 
> But there are a lot of "custom" boards (maintained in U-Boot) that runs
> for a specific project and won't run any other kind of software. If a
> device is a navigation system, a network controller, or whatever, it
> will just do this job until its EOL.
> 
> Specially for older boards, a new feature should not be activated as
> default. At the beginning, police in U-Boot was to set just what should
> be required in the bootloader, without setting what is not needed as
> default. So default was off instead of on.

So, part of what I'm taking away from all of this is that I really do
need to see how many people I can bcc at once before gmail gets really
mad at me,  Yes, there's a number of end-user devices we have support
for in mainline that are intended to be re-used as the manufacturer
intended.  Part of the Kconfig migration means that they can more easily
remove stuff they don't want/need than before.  But there's also the
repurposed boards, and lots of not really clear cut cases, such as the
tbs2910 where while it's not my call, does fall into the "enable EFI
loader support for your end users maybe?" category.  And in the end, I
should have emailed off everyone with a gentle reminder to inspect and
trim their configs.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote:
> Hi Tom,
> 
> On 10/01/19 15:44, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> >> Hi Tom, Soeren,
> >>
> >> On 09/01/19 23:39, Tom Rini wrote:
> >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>  Hi Soeren,
> 
>  On 08/01/19 12:03, Soeren Moch wrote:
> > Hi Stefano,
> >
> > On 08.01.19 11:24, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 11:14, Soeren Moch wrote:
> >>> Stefano,
> >>>
> >>> can you apply this for v2019.01? This is really a important fix to 
> >>> avoid
> >>>  environment and u-boot binary overwriting each other.
> >>> It is also a small local fix which cannot hurt anybody else.
> >> I will apply and I send a new PR. This is not the first fix in this
> >> direction, u-boot becomes pretty large, it is becoming a common 
> >> problem.
> >>
> > Thank you very much.
> >
> > Yes, "in the good old days (tm)" there was much effort put into not
> > increasing the binary size for existing boards when adding new features.
> 
>  Right, fully agree.
> 
> > Unfortunately this is not true anymore.
> 
>  I get in the same trouble with more as one project. A previous rule of
>  thumb was to reserve 512KB to the bootloader because it was pretty
>  unthinkable that bootloader could be larger. Mhmmhhthis remember me
>  someone else who said that 640Kb is enough for everything.
> 
>  Anyway, as you noted, this is a big problem in field and it makes
>  difficult an upgrade without returning back the device to factory, what
>  nobody wants.
> >>>
> >>> So, this is more on me, so I should probably explain a little, and point
> >>> at the biggest culprit too.  The biggest at times culprit and sometimes
> >>> controversial thing is that we default to the EFI subsystem being on by
> >>> default.  This is 50KiB on tbs2910.
> >>
> >> I am not sure if we should point to EFI as responsible for the increased
> >> footprint or it is due to the sum of several components / factors. I
> >> just report my experience in last month : I had to port U-Boot for a
> >> customer from a not very old release (2017.01) to the current. 2017.01
> >> had already (apart of FIT support) all features the customer needed, but
> >> there are issues(NAND, UBI) and I kew that they were solved later.
> >> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> >> a lot in board code, but of course I had to reconfigure a lot. At the
> >> end, everything worked but I was quite astonished about footprint. I had:
> >>
> >> 2017.01u-boot.bin 443452
> >> 2018.11 u-boot.bin 654684
> >> I'm splitting my reply here into two emails.  This here concerns the
> > heck out of me.  But I don't see it on MPC8308RDB.  There I see:
> >powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text 
> > +6847.0
> > MPC8308RDB : all -124241 bss -131040 data -48 text +6847
> >u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 
> > (-125646)
> 
> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
> it is not MPC8308RDB. But nevertheless, I could not understand the
> difference is sitze.

Right, I understand, that's just the first MPC83xx board I spotted, and
I wanted to see if all platforms had such unreasonable growth.  You're
showing your custom platform went up by _200_ kilobytes.

> > And in terms of .bins:
> > -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 
> > /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
> > -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 
> > /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
> > 
> > I am doing all of mpc83xx now to see if something else trips such a
> > large growth.
> > 
> 
> I will do the same here on this board and try to understand where the
> difference is coming from. I will report to you, then.

Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote:
> 
> 
> On 10.01.19 03:30, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
> >>
> >> On 09.01.19 23:39, Tom Rini wrote:
> >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>  Hi Soeren,
> 
>  On 08/01/19 12:03, Soeren Moch wrote:
> > Hi Stefano,
> >
> > On 08.01.19 11:24, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 11:14, Soeren Moch wrote:
> >>> Stefano,
> >>>
> >>> can you apply this for v2019.01? This is really a important fix to 
> >>> avoid
> >>>  environment and u-boot binary overwriting each other.
> >>> It is also a small local fix which cannot hurt anybody else.
> >> I will apply and I send a new PR. This is not the first fix in this
> >> direction, u-boot becomes pretty large, it is becoming a common 
> >> problem.
> >>
> > Thank you very much.
> >
> > Yes, "in the good old days (tm)" there was much effort put into not
> > increasing the binary size for existing boards when adding new features.
>  Right, fully agree.
> 
> > Unfortunately this is not true anymore.
>  I get in the same trouble with more as one project. A previous rule of
>  thumb was to reserve 512KB to the bootloader because it was pretty
>  unthinkable that bootloader could be larger. Mhmmhhthis remember me
>  someone else who said that 640Kb is enough for everything.
> 
>  Anyway, as you noted, this is a big problem in field and it makes
>  difficult an upgrade without returning back the device to factory, what
>  nobody wants.
> >>> So, this is more on me, so I should probably explain a little, and point
> >>> at the biggest culprit too.  The biggest at times culprit and sometimes
> >>> controversial thing is that we default to the EFI subsystem being on by
> >>> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> >>> agrees that defaulting to EFI application support means the widest
> >>> choice of out of the box software support.
> >>>
> >> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
> >> boards. The usual way for firmware updates was to load a special
> > Yes, there's some amount of chicken-and-egg but it's there and growing.
> >
> >> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
> >> more convenient these days to support EFI, maybe a good idea to
> >> default=y, but why this is not disabled in old board's defconfigs then?
> > While it's default y and means we're even enabling it on pre-v7
> > processors, the general answer is that defaults matter especially when
> > things get forked off for a custom project or for a new reference
> > platform, and it's something that can always be turned off.  i.MX is in
> > fact where a number of platforms have gone for opt-out.
> So default y might be OK if this feature is desired for new platforms.
> But I would prefer that the same patch series that introduces the
> default y also inserts all the "# CONFIG_WHATEVER is not set" in old
> board's defconfigs.

But that's close to the opposite of why you make something default y,
which I really do try and not do so often, but maybe I'm also not doing
a great job there.

But, digging into specifics for just a moment,
https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what
we're talking about here and that you can install $whatever on it as
$whatever expects to be able to have its EFI-application installer just
run (and be passed a device tree for the kernel) is part of why
EFI_LOADER is default enabled.

That's not saying you shouldn't still disable it if you need the space.

[snip]
> >> The bigger challenge are the BLK and DM conversions for the next u-boot
> >> version. I absolutely cannot understand how somebody can insist on these
> >> changes, while letting the board maintainers completely alone with
> >> required driver adaptations. Board maintainers are not familiar with
> >> driver code, a lot of board maintainers would need to work in parallel
> >> on this (when no person is designated for this work, all maintainers are
> >> equally responsible), while the author of the BLK/DM core code is very
> >> familiar with the required changes. The necessary API adaptations in
> >> drivers would be a no-brainer for him, since nothing of the actual
> >> hardware access code needs to be adapted. At least that is my 
> >> understanding.
> >> But someone (who actually?) decided to simply offload the second
> >> conversion step (drivers) to somebody else, with no help offered for
> >> this, but with short deadlines. I never heard that this can work in
> >> community projects.
> >> If the driver adaptations are done for a single board from each family,
> >> then the third step (adapting board configurations) is a job for board
> >> maintainers. But we're not at his point.
> > Keep in mind that for the 

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Tom,

On 10/01/19 15:44, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>> Hi Tom, Soeren,
>>
>> On 09/01/19 23:39, Tom Rini wrote:
>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
 Hi Soeren,

 On 08/01/19 12:03, Soeren Moch wrote:
> Hi Stefano,
>
> On 08.01.19 11:24, Stefano Babic wrote:
>> Hi Soeren,
>>
>> On 08/01/19 11:14, Soeren Moch wrote:
>>> Stefano,
>>>
>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>  environment and u-boot binary overwriting each other.
>>> It is also a small local fix which cannot hurt anybody else.
>> I will apply and I send a new PR. This is not the first fix in this
>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>
> Thank you very much.
>
> Yes, "in the good old days (tm)" there was much effort put into not
> increasing the binary size for existing boards when adding new features.

 Right, fully agree.

> Unfortunately this is not true anymore.

 I get in the same trouble with more as one project. A previous rule of
 thumb was to reserve 512KB to the bootloader because it was pretty
 unthinkable that bootloader could be larger. Mhmmhhthis remember me
 someone else who said that 640Kb is enough for everything.

 Anyway, as you noted, this is a big problem in field and it makes
 difficult an upgrade without returning back the device to factory, what
 nobody wants.
>>>
>>> So, this is more on me, so I should probably explain a little, and point
>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>> controversial thing is that we default to the EFI subsystem being on by
>>> default.  This is 50KiB on tbs2910.
>>
>> I am not sure if we should point to EFI as responsible for the increased
>> footprint or it is due to the sum of several components / factors. I
>> just report my experience in last month : I had to port U-Boot for a
>> customer from a not very old release (2017.01) to the current. 2017.01
>> had already (apart of FIT support) all features the customer needed, but
>> there are issues(NAND, UBI) and I kew that they were solved later.
>> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
>> a lot in board code, but of course I had to reconfigure a lot. At the
>> end, everything worked but I was quite astonished about footprint. I had:
>>
>> 2017.01  u-boot.bin 443452
>> 2018.11 u-boot.bin 654684
>> I'm splitting my reply here into two emails.  This here concerns the
> heck out of me.  But I don't see it on MPC8308RDB.  There I see:
>powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text 
> +6847.0
> MPC8308RDB : all -124241 bss -131040 data -48 text +6847
>u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 
> (-125646)

Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
it is not MPC8308RDB. But nevertheless, I could not understand the
difference is sitze.

> 
> And in terms of .bins:
> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 
> /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
> -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 
> /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
> 
> I am doing all of mpc83xx now to see if something else trips such a
> large growth.
> 

I will do the same here on this board and try to understand where the
difference is coming from. I will report to you, then.


Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [GIT] Pull request: u-boot-dfu (10.01.2019)

[Jean-Jacques Hiblot]

On 10/01/2019 15:12, Marek Vasut wrote:

On 1/10/19 3:02 PM, Jean-Jacques Hiblot wrote:

On 10/01/2019 09:51, Marek Vasut wrote:

On 1/10/19 8:37 AM, Lukasz Majewski wrote:

On Thu, 10 Jan 2019 01:53:23 +0100
Marek Vasut  wrote:


On 1/10/19 12:21 AM, Lukasz Majewski wrote:

Dear Marek,

I've build tested the patch set from Jean-Jacques on sunxi:

./tools/buildman/buildman.py --branch=HEAD sunxi --detail --verbose
--show_errors --force-build --count=5 --output-dir=../BUILD/

It also passes on Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/477104303

The following changes since commit
7436f5e54d35bcad53befec90e2e67288071f74e:

    Merge tag 'for-master-20190103' of
git://git.denx.de/u-boot-rockchip (2019-01-03 08:39:44 -0500)

are available in the git repository at:

    git://git.denx.de/u-boot-dfu.git

for you to fetch changes up to
97f2e698788eba9ee0ea51b3c2f34e989788:

    dm: usb: gadget: Fix boot breakage on sunxi platforms (2019-01-09
    01:04:36 +0100)


Jean-Jacques Hiblot (5):
    dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports
    ARM: dts: define USB aliases for all omap5 platforms
    Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
CONFIG_SPL_USB_GADGET
    usb: Make compiling gadget support optional
    dm: usb: gadget: Fix boot breakage on sunxi platforms

I think that's the wrong patch at the end, it still unconditionally
pulls in udc-uclass.o if CONFIG_$(SPL_)DM is enabled.


This is the order proposed by Jean-Jacques:

Just changing the order should be enough to prevent any breakage.

1) Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
CONFIG_SPL_USB_GADGET
2) usb: Make compiling gadget support optional
3) dm: usb: gadget: Fix boot breakage on sunxi platforms

But it's still unconditionally pulling in UDC code if DM is enabled,
which is what I was complaining in the previous PR too , can you explain
why ?

No it does not because the code in drivers/usb/gadget/udc is not
compiled if CONFIG_$(SPL_)_USB_GADGET is not set (patch #2)

Ah, I see, thanks.

I wanted to apply this PR, but got conflict:

Auto-merging configs/omap4_panda_defconfig
CONFLICT (content): Merge conflict in configs/omap4_panda_defconfig
Auto-merging configs/duovero_defconfig
CONFLICT (content): Merge conflict in configs/duovero_defconfig
Auto-merging Makefile
error: could not apply b5d6e0f7b0... usb: Make compiling gadget support
optional

I guess something minor changed in the config files, can you respin the
PR one more time ? I pushed u-boot-usb/master updated on u-boot/master
just now.


Done.





___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH PATCH v2 2/2] usb: Make compiling gadget support optional

[Jean-Jacques Hiblot]

There is no need to compile and include this code if it is not used.
CONFIG_USB_GADGET can be used for the purpose.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- rebased on top of latest u-boot-usb

 Makefile   | 4 ++--
 configs/cm_t3517_defconfig | 1 +
 configs/cm_t35_defconfig   | 1 +
 configs/duovero_defconfig  | 1 +
 configs/igep0032_defconfig | 1 +
 configs/igep00x0_defconfig | 1 +
 configs/omap3_zoom1_defconfig  | 1 +
 configs/omap4_panda_defconfig  | 1 +
 configs/omap4_sdp4430_defconfig| 1 +
 configs/spear300_usbtty_defconfig  | 2 ++
 configs/spear300_usbtty_nand_defconfig | 2 ++
 configs/spear310_usbtty_defconfig  | 2 ++
 configs/spear310_usbtty_nand_defconfig | 2 ++
 configs/spear310_usbtty_pnor_defconfig | 2 ++
 configs/spear320_usbtty_defconfig  | 2 ++
 configs/spear320_usbtty_nand_defconfig | 2 ++
 configs/spear320_usbtty_pnor_defconfig | 2 ++
 configs/spear600_usbtty_defconfig  | 2 ++
 configs/spear600_usbtty_nand_defconfig | 2 ++
 19 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index c4d0c3002e..ce2ca00730 100644
--- a/Makefile
+++ b/Makefile
@@ -712,8 +712,8 @@ libs-y += drivers/usb/dwc3/
 libs-y += drivers/usb/common/
 libs-y += drivers/usb/emul/
 libs-y += drivers/usb/eth/
-libs-y += drivers/usb/gadget/
-libs-y += drivers/usb/gadget/udc/
+libs-$(CONFIG_USB_GADGET) += drivers/usb/gadget/
+libs-$(CONFIG_USB_GADGET) += drivers/usb/gadget/udc/
 libs-y += drivers/usb/host/
 libs-y += drivers/usb/musb/
 libs-y += drivers/usb/musb-new/
diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig
index 0901fea638..c204a29081 100644
--- a/configs/cm_t3517_defconfig
+++ b/configs/cm_t3517_defconfig
@@ -54,6 +54,7 @@ CONFIG_USB=y
 CONFIG_USB_MUSB_HOST=y
 CONFIG_USB_MUSB_AM35X=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
 CONFIG_VIDEO_OMAP3=y
 CONFIG_LCD=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/cm_t35_defconfig b/configs/cm_t35_defconfig
index f1fe2d058d..a27c502489 100644
--- a/configs/cm_t35_defconfig
+++ b/configs/cm_t35_defconfig
@@ -56,6 +56,7 @@ CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
 CONFIG_TWL4030_USB=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
 CONFIG_VIDEO_OMAP3=y
 CONFIG_LCD=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/duovero_defconfig b/configs/duovero_defconfig
index 8ea626d013..782a9dc291 100644
--- a/configs/duovero_defconfig
+++ b/configs/duovero_defconfig
@@ -36,5 +36,6 @@ CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
+CONFIG_USB_GADGET=y
 CONFIG_FAT_WRITE=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
index 383648789c..20d2cf5820 100644
--- a/configs/igep0032_defconfig
+++ b/configs/igep0032_defconfig
@@ -45,6 +45,7 @@ CONFIG_USB=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
 CONFIG_TWL4030_USB=y
+CONFIG_USB_GADGET=y
 CONFIG_FAT_WRITE=y
 CONFIG_UBIFS_SILENCE_MSG=y
 CONFIG_BCH=y
diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig
index f2989e34e1..330350c32a 100644
--- a/configs/igep00x0_defconfig
+++ b/configs/igep00x0_defconfig
@@ -46,6 +46,7 @@ CONFIG_USB=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
 CONFIG_TWL4030_USB=y
+CONFIG_USB_GADGET=y
 CONFIG_FAT_WRITE=y
 CONFIG_UBIFS_SILENCE_MSG=y
 CONFIG_BCH=y
diff --git a/configs/omap3_zoom1_defconfig b/configs/omap3_zoom1_defconfig
index 325c0020ca..489e6a8ee0 100644
--- a/configs/omap3_zoom1_defconfig
+++ b/configs/omap3_zoom1_defconfig
@@ -35,5 +35,6 @@ CONFIG_USB=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
 CONFIG_TWL4030_USB=y
+CONFIG_USB_GADGET=y
 CONFIG_FAT_WRITE=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/omap4_panda_defconfig b/configs/omap4_panda_defconfig
index b66659f123..7ee9eea06a 100644
--- a/configs/omap4_panda_defconfig
+++ b/configs/omap4_panda_defconfig
@@ -36,6 +36,7 @@ CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
+CONFIG_USB_GADGET=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/omap4_sdp4430_defconfig b/configs/omap4_sdp4430_defconfig
index 6b2ea202e5..0e01c8edcb 100644
--- a/configs/omap4_sdp4430_defconfig
+++ b/configs/omap4_sdp4430_defconfig
@@ -33,6 +33,7 @@ CONFIG_OMAP3_SPI=y
 CONFIG_USB=y
 CONFIG_USB_MUSB_UDC=y
 CONFIG_USB_OMAP3=y
+CONFIG_USB_GADGET=y
 CONFIG_FAT_WRITE=y
 # CONFIG_REGEX is not set
 CONFIG_OF_LIBFDT=y
diff --git a/configs/spear300_usbtty_defconfig 
b/configs/spear300_usbtty_defconfig
index bc0c3ec091..cb115fecb7 100644
--- a/configs/spear300_usbtty_defconfig
+++ b/configs/spear300_usbtty_defconfig
@@ -27,3 +27,5 @@ CONFIG_PHY_GIGE=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_MII=y
 CONFIG_CONS_INDEX=0
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
diff --git a/configs/spear300_usbtty_nand_defconfig 
b/configs/spear300_usbtty_nand_defconfig
index 9b90cd8638..4064ba36e9 100644
--- a/configs/spear300_usbtty_nand_defconfig
+++ 

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> Hi Tom, Soeren,
> 
> On 09/01/19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 12:03, Soeren Moch wrote:
> >>> Hi Stefano,
> >>>
> >>> On 08.01.19 11:24, Stefano Babic wrote:
>  Hi Soeren,
> 
>  On 08/01/19 11:14, Soeren Moch wrote:
> > Stefano,
> >
> > can you apply this for v2019.01? This is really a important fix to avoid
> >  environment and u-boot binary overwriting each other.
> > It is also a small local fix which cannot hurt anybody else.
>  I will apply and I send a new PR. This is not the first fix in this
>  direction, u-boot becomes pretty large, it is becoming a common problem.
> 
> >>> Thank you very much.
> >>>
> >>> Yes, "in the good old days (tm)" there was much effort put into not
> >>> increasing the binary size for existing boards when adding new features.
> >>
> >> Right, fully agree.
> >>
> >>> Unfortunately this is not true anymore.
> >>
> >> I get in the same trouble with more as one project. A previous rule of
> >> thumb was to reserve 512KB to the bootloader because it was pretty
> >> unthinkable that bootloader could be larger. Mhmmhhthis remember me
> >> someone else who said that 640Kb is enough for everything.
> >>
> >> Anyway, as you noted, this is a big problem in field and it makes
> >> difficult an upgrade without returning back the device to factory, what
> >> nobody wants.
> > 
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.
> 
> I am not sure if we should point to EFI as responsible for the increased
> footprint or it is due to the sum of several components / factors. I
> just report my experience in last month : I had to port U-Boot for a
> customer from a not very old release (2017.01) to the current. 2017.01
> had already (apart of FIT support) all features the customer needed, but
> there are issues(NAND, UBI) and I kew that they were solved later.
> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> a lot in board code, but of course I had to reconfigure a lot. At the
> end, everything worked but I was quite astonished about footprint. I had:
> 
> 2017.01   u-boot.bin 443452
> 2018.11 u-boot.bin 654684

I'm splitting my reply here into two emails.  This here concerns the
heck out of me.  But I don't see it on MPC8308RDB.  There I see:
   powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0
MPC8308RDB : all -124241 bss -131040 data -48 text +6847
   u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 
(-125646)

And in terms of .bins:
-rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 
/tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
-rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 
/tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin

I am doing all of mpc83xx now to see if something else trips such a
large growth.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: ti: boot: Fix am57xx evm fdtfile name

[Sam Protsenko]

Hi Lokesh,

On Thu, Jan 10, 2019 at 4:47 AM Lokesh Vutla  wrote:
>
>
>
> On 1/10/2019 1:55 AM, Praneeth Bajjuri wrote:
> > am57xx evm uses am57xx-evm-reva3.dtb.
> > update findfdt to pick the correct default dtb
> >
> > Signed-off-by: Praneeth Bajjuri 
> > ---
> >  include/environment/ti/boot.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
> > index 86ff6d3ea7c6..c9ad3046acaa 100644
> > --- a/include/environment/ti/boot.h
> > +++ b/include/environment/ti/boot.h
> > @@ -125,7 +125,7 @@
> >   "if test $board_name = am57xx_evm; then " \
> >   "setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
> >   "if test $board_name = am57xx_evm_reva3; then " \
> > - "setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
> > + "setenv fdtfile am57xx-evm-reva3.dtb; fi;" \
>
> I do not see this dts in kernel. Either it is not upstream or we are
> suposed to use overlays in this case.
>

Agreed. We should target upstream kernel in upstream U-Boot. So we
should either:
  1. Add corresponding dtb/dtbo files for AM57x EVM in upstream kernel first
  2. Or drop this patch and continue using X15 dtb for EVM.

As I understand, (1) is not going to happen any time soon (though I
would prefer this solution, as EVM already happened and being used).
So we should probably stick to (2).

> Thanks and regards,
> Lokesh
>
> >   "if test $board_name = am571x_idk; then " \
> >   "setenv fdtfile am571x-idk.dtb; fi;" \
> >   "if test $fdtfile = undefined; then " \
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] kbuild: fix parallel build race caused by u-boot.cfg regeneration

[Masahiro Yamada]

Multiple people have reported intermittent build failure in parallel
building.

Kever Yang reported this issue some time ago [1], but I could not
get enough clue at that time.

This time, Richard Purdie provided a full build log [2], which was
very helpful for me to root-cause it.

The cause of the problem is commit 0d982c585330 ("Makefile: add
dependencies to regenerate u-boot.cfg when lost").

That commit added the 'cfg' as the prerequisite of the 'all' target,
so the parallel build tries to run it simultaneously, then regenerates
a symlink while building objects.

When u-boot.cfg is accidentally lost, let's rebuild it before
descending into any subdirectories.

Also, what is annoying is u-boot.cfg is currently regenerated every
time since it depends on FORCE. We can get rid of all the prerequisites
of u-boot.cfg because u-boot.cfg is rebuilt anyway as the byproduct of
auto.conf when a user updates the .config file.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330341.html
[2] 
https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/160/steps/7/logs/step1b

Fixes: 0d982c585330 ("Makefile: add dependencies to regenerate u-boot.cfg when 
lost")
Reported-by: Kever Yang 
Reported-by: Richard Purdie 
Signed-off-by: Masahiro Yamada 
Reviewed-by: Simon Glass 
---

Changes in v2:
 - Move 'cfg' before 'prepare0' to avoid a race between them

 Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index eeb299f..c6eb727 100644
--- a/Makefile
+++ b/Makefile
@@ -534,7 +534,7 @@ include/config/%.conf: $(KCONFIG_CONFIG) 
include/config/auto.conf.cmd
@# Otherwise, 'make silentoldconfig' would be invoked twice.
$(Q)touch include/config/auto.conf
 
-u-boot.cfg spl/u-boot.cfg tpl/u-boot.cfg: include/config.h FORCE
+u-boot.cfg spl/u-boot.cfg tpl/u-boot.cfg:
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.autoconf $(@)
 
 -include include/autoconf.mk
@@ -910,7 +910,7 @@ quiet_cmd_cfgcheck = CFGCHK  $2
 cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
$(srctree)/scripts/config_whitelist.txt $(srctree)
 
-all:   $(ALL-y) cfg
+all:   $(ALL-y)
 ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y)
@echo >&2 "= WARNING =="
@echo >&2 "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
@@ -1530,7 +1530,7 @@ ifneq ($(KBUILD_SRC),)
 endif
 
 # prepare2 creates a makefile if using a separate output directory
-prepare2: prepare3 outputmakefile
+prepare2: prepare3 outputmakefile cfg
 
 prepare1: prepare2 $(version_h) $(timestamp_h) \
include/config/auto.conf
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [GIT] Pull request: u-boot-dfu (10.01.2019)

[Marek Vasut]

On 1/10/19 3:02 PM, Jean-Jacques Hiblot wrote:
> 
> On 10/01/2019 09:51, Marek Vasut wrote:
>> On 1/10/19 8:37 AM, Lukasz Majewski wrote:
>>> On Thu, 10 Jan 2019 01:53:23 +0100
>>> Marek Vasut  wrote:
>>>
 On 1/10/19 12:21 AM, Lukasz Majewski wrote:
> Dear Marek,
>
> I've build tested the patch set from Jean-Jacques on sunxi:
>
> ./tools/buildman/buildman.py --branch=HEAD sunxi --detail --verbose
> --show_errors --force-build --count=5 --output-dir=../BUILD/
>
> It also passes on Travis-CI:
> https://travis-ci.org/lmajewski/u-boot-dfu/builds/477104303
>
> The following changes since commit
> 7436f5e54d35bcad53befec90e2e67288071f74e:
>
>    Merge tag 'for-master-20190103' of
> git://git.denx.de/u-boot-rockchip (2019-01-03 08:39:44 -0500)
>
> are available in the git repository at:
>
>    git://git.denx.de/u-boot-dfu.git
>
> for you to fetch changes up to
> 97f2e698788eba9ee0ea51b3c2f34e989788:
>
>    dm: usb: gadget: Fix boot breakage on sunxi platforms (2019-01-09
>    01:04:36 +0100)
>
> 
> Jean-Jacques Hiblot (5):
>    dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports
>    ARM: dts: define USB aliases for all omap5 platforms
>    Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
> CONFIG_SPL_USB_GADGET
>    usb: Make compiling gadget support optional
>    dm: usb: gadget: Fix boot breakage on sunxi platforms
 I think that's the wrong patch at the end, it still unconditionally
 pulls in udc-uclass.o if CONFIG_$(SPL_)DM is enabled.

>>> This is the order proposed by Jean-Jacques:
>>>
>>> Just changing the order should be enough to prevent any breakage.
>>>
>>> 1) Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
>>> CONFIG_SPL_USB_GADGET
>>> 2) usb: Make compiling gadget support optional
>>> 3) dm: usb: gadget: Fix boot breakage on sunxi platforms
>> But it's still unconditionally pulling in UDC code if DM is enabled,
>> which is what I was complaining in the previous PR too , can you explain
>> why ?
> 
> No it does not because the code in drivers/usb/gadget/udc is not
> compiled if CONFIG_$(SPL_)_USB_GADGET is not set (patch #2)

Ah, I see, thanks.

I wanted to apply this PR, but got conflict:

Auto-merging configs/omap4_panda_defconfig
CONFLICT (content): Merge conflict in configs/omap4_panda_defconfig
Auto-merging configs/duovero_defconfig
CONFLICT (content): Merge conflict in configs/duovero_defconfig
Auto-merging Makefile
error: could not apply b5d6e0f7b0... usb: Make compiling gadget support
optional

I guess something minor changed in the config files, can you respin the
PR one more time ? I pushed u-boot-usb/master updated on u-boot/master
just now.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/6] pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family

[Gregory CLEMENT]

Hi Horatiu,
 
 On jeu., janv. 10 2019, Horatiu Vultur  wrote:

> The Jaguar2 SOC family has 63 gpio pins therefore I extended mscc-common
> to support new numbe of pins and remove any platform dependency from
> mscc-common.
>
> Signed-off-by: Horatiu Vultur 
> ---
>  MAINTAINERS   |   1 +
>  drivers/pinctrl/mscc/Kconfig  |   9 +
>  drivers/pinctrl/mscc/Makefile |   1 +
>  drivers/pinctrl/mscc/mscc-common.c|  90 +++---
>  drivers/pinctrl/mscc/mscc-common.h|  17 +-
>  drivers/pinctrl/mscc/pinctrl-jr2.c| 315 
> ++
>  drivers/pinctrl/mscc/pinctrl-luton.c  |  16 +-
>  drivers/pinctrl/mscc/pinctrl-ocelot.c |  16 +-
>  8 files changed, 436 insertions(+), 29 deletions(-)
>  create mode 100644 drivers/pinctrl/mscc/pinctrl-jr2.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 494962e..495d3e5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -525,6 +525,7 @@ F:board/mscc/
>  F:   configs/mscc*
>  F:   drivers/gpio/mscc_sgpio.c
>  F:   include/configs/vcoreiii.h
> +F:   drivers/pinctrl/mscc/
>  
>  MIPS JZ4780
>  M:   Ezequiel Garcia 
> diff --git a/drivers/pinctrl/mscc/Kconfig b/drivers/pinctrl/mscc/Kconfig
> index cfc6c06..d07ea1b 100644
> --- a/drivers/pinctrl/mscc/Kconfig
> +++ b/drivers/pinctrl/mscc/Kconfig
> @@ -20,3 +20,12 @@ config PINCTRL_MSCC_LUTON
>   help
>  Support pin multiplexing and pin configuration control on
>  Microsemi luton SoCs.
> +
> +config PINCTRL_MSCC_JR2
> + depends on SOC_JR2 && PINCTRL_FULL && OF_CONTROL
> + select PINCTRL_MSCC
> + default y
> + bool "Microsemi jr2 family pin control driver"
> + help
> + Support pin multiplexing and pin configuration control on
> + Microsemi jr2 SoCs.
> diff --git a/drivers/pinctrl/mscc/Makefile b/drivers/pinctrl/mscc/Makefile
> index 6910671..8038d54 100644
> --- a/drivers/pinctrl/mscc/Makefile
> +++ b/drivers/pinctrl/mscc/Makefile
> @@ -3,3 +3,4 @@
>  obj-y += mscc-common.o
>  obj-$(CONFIG_PINCTRL_MSCC_OCELOT) += pinctrl-ocelot.o
>  obj-$(CONFIG_PINCTRL_MSCC_LUTON) += pinctrl-luton.o
> +obj-$(CONFIG_PINCTRL_MSCC_JR2) += pinctrl-jr2.o
> diff --git a/drivers/pinctrl/mscc/mscc-common.c 
> b/drivers/pinctrl/mscc/mscc-common.c
> index d74b8a6..bd3e6ea 100644
> --- a/drivers/pinctrl/mscc/mscc-common.c
> +++ b/drivers/pinctrl/mscc/mscc-common.c
> @@ -22,16 +22,37 @@
>  #include 
>  #include "mscc-common.h"
>  
> -#define MSCC_GPIO_OUT_SET0x0
> -#define MSCC_GPIO_OUT_CLR0x4
> -#define MSCC_GPIO_OUT0x8
> -#define MSCC_GPIO_IN 0xc
> -#define MSCC_GPIO_OE 0x10
> -#define MSCC_GPIO_INTR   0x14
> -#define MSCC_GPIO_INTR_ENA   0x18
> -#define MSCC_GPIO_INTR_IDENT 0x1c
> -#define MSCC_GPIO_ALT0   0x20
> -#define MSCC_GPIO_ALT1   0x24
> +static void mscc_writel(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + writel(BIT(offset), addr);
> + else
> + writel(BIT(offset % 32), addr + 4);
> +}
> +
> +static unsigned int mscc_readl(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + return readl(addr);
> + else
> + return readl(addr + 4);
> +}
> +
> +static void mscc_setbits(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + writel(readl(addr) | BIT(offset), addr);
> + else
> + writel(readl(addr + 4) | BIT(offset % 32), addr + 4);
> +}
> +
> +static void mscc_clrbits(unsigned int offset, void *addr)
> +{
> + if (offset < 32)
> + writel(readl(addr) & ~BIT(offset), addr);
> + else
> + writel(readl(addr + 4) & ~BIT(offset % 32), addr + 4);
> +}
>  
>  static int mscc_get_functions_count(struct udevice *dev)
>  {
> @@ -67,7 +88,7 @@ static int mscc_pinmux_set_mux(struct udevice *dev,
>  {
>   struct mscc_pinctrl *info = dev_get_priv(dev);
>   struct mscc_pin_caps *pin = info->mscc_pins[pin_selector].drv_data;
> - int f;
> + int f, offset, regoff;
>  
>   f = mscc_pin_function_idx(pin_selector, selector, info->mscc_pins);
>   if (f < 0)
> @@ -79,15 +100,22 @@ static int mscc_pinmux_set_mux(struct udevice *dev,
>* This is racy because both registers can't be updated at the same time
>* but it doesn't matter much for now.
>*/
> + offset = pin->pin;
> + regoff = info->mscc_gpios[MSCC_GPIO_ALT0];
> + if (offset >= 32) {
> + offset = offset % 32;
> + regoff = info->mscc_gpios[MSCC_GPIO_ALT1];
> + }
> +
>   if (f & BIT(0))
> - setbits_le32(info->regs + MSCC_GPIO_ALT0, BIT(pin->pin));
> + mscc_setbits(offset, info->regs + regoff);
>   else
> - clrbits_le32(info->regs + MSCC_GPIO_ALT0, BIT(pin->pin));
> + mscc_clrbits(offset, info->regs + regoff);
>  
>   if (f & BIT(1))
> - setbits_le32(info->regs + MSCC_GPIO_ALT1, BIT(pin->pin - 1));
> 

Re: [U-Boot] [PATCH] kbuild: fix parallel build race caused by u-boot.cfg regeneration

[Masahiro Yamada]

On Wed, Jan 9, 2019 at 4:33 PM Masahiro Yamada
 wrote:
>
> Multiple people have reported intermittent build failure in parallel
> building.
>
> Kever Yang reported this issue some time ago [1], but I could not
> get enough clue at that time.
>
> This time, Richard Purdie provided a complete build log [2], which
> was very helpful for me to root-cause it.
>
> The cause of the problem is commit 0d982c585330 ("Makefile: add
> dependencies to regenerate u-boot.cfg when lost").
>
> That commit added the 'cfg' as the prerequisite of the 'all' target,
> so the parallel build tries to run it simultaneously, then regenerates
> a symlink while building objects.
>
> When u-boot.cfg is accidentally lost, lets' rebuild it before
> descending into any subdirectories.
>
> Also, what is annoying is u-boot.cfg is currently regenerated every
> time since it depends on FORCE. We can get rid of all the prerequisites
> of u-boot.cfg because u-boot.cfg is rebuilt anyway as the byproduct of
> auto.conf when a user updates the .config file.
>
> [1] https://lists.denx.de/pipermail/u-boot/2018-June/330341.html
> [2] 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/160/steps/7/logs/step1b
>
> Fixes: 0d982c585330 ("Makefile: add dependencies to regenerate u-boot.cfg 
> when lost")
> Reported-by: Kever Yang 
> Reported-by: Richard Purdie 
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index eeb299f..363ebc8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -534,7 +534,7 @@ include/config/%.conf: $(KCONFIG_CONFIG) 
> include/config/auto.conf.cmd
> @# Otherwise, 'make silentoldconfig' would be invoked twice.
> $(Q)touch include/config/auto.conf
>
> -u-boot.cfg spl/u-boot.cfg tpl/u-boot.cfg: include/config.h FORCE
> +u-boot.cfg spl/u-boot.cfg tpl/u-boot.cfg:
> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.autoconf $(@)
>
>  -include include/autoconf.mk
> @@ -910,7 +910,7 @@ quiet_cmd_cfgcheck = CFGCHK  $2
>  cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
> $(srctree)/scripts/config_whitelist.txt $(srctree)
>
> -all:   $(ALL-y) cfg
> +all:   $(ALL-y)
>  ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y)
> @echo >&2 "= WARNING =="
> @echo >&2 "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
> @@ -1549,7 +1549,7 @@ prepare0: archprepare FORCE
> $(Q)$(MAKE) $(build)=.
>
>  # All the preparing..
> -prepare: prepare0
> +prepare: prepare0 cfg


I noticed this is still unsafe
because prepare0 descends into ./Kbuild
and generates asm-offset things.

I will send v2.


>
>  # Generate some files
>  # ---
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

On 10.01.19 03:30, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
>>
>> On 09.01.19 23:39, Tom Rini wrote:
>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
 Hi Soeren,

 On 08/01/19 12:03, Soeren Moch wrote:
> Hi Stefano,
>
> On 08.01.19 11:24, Stefano Babic wrote:
>> Hi Soeren,
>>
>> On 08/01/19 11:14, Soeren Moch wrote:
>>> Stefano,
>>>
>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>  environment and u-boot binary overwriting each other.
>>> It is also a small local fix which cannot hurt anybody else.
>> I will apply and I send a new PR. This is not the first fix in this
>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>
> Thank you very much.
>
> Yes, "in the good old days (tm)" there was much effort put into not
> increasing the binary size for existing boards when adding new features.
 Right, fully agree.

> Unfortunately this is not true anymore.
 I get in the same trouble with more as one project. A previous rule of
 thumb was to reserve 512KB to the bootloader because it was pretty
 unthinkable that bootloader could be larger. Mhmmhhthis remember me
 someone else who said that 640Kb is enough for everything.

 Anyway, as you noted, this is a big problem in field and it makes
 difficult an upgrade without returning back the device to factory, what
 nobody wants.
>>> So, this is more on me, so I should probably explain a little, and point
>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>> controversial thing is that we default to the EFI subsystem being on by
>>> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
>>> agrees that defaulting to EFI application support means the widest
>>> choice of out of the box software support.
>>>
>> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
>> boards. The usual way for firmware updates was to load a special
> Yes, there's some amount of chicken-and-egg but it's there and growing.
>
>> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
>> more convenient these days to support EFI, maybe a good idea to
>> default=y, but why this is not disabled in old board's defconfigs then?
> While it's default y and means we're even enabling it on pre-v7
> processors, the general answer is that defaults matter especially when
> things get forked off for a custom project or for a new reference
> platform, and it's something that can always be turned off.  i.MX is in
> fact where a number of platforms have gone for opt-out.
So default y might be OK if this feature is desired for new platforms.
But I would prefer that the same patch series that introduces the
default y also inserts all the "# CONFIG_WHATEVER is not set" in old
board's defconfigs.
>> Either "automatically" like in the Kconfig conversions, or via a short
>> notice to the relevant board maintainers?
> I've been bad about communicating stuff to board maintainers, so that's
> on me.  I have been, more of late at least, mentioning them in the
> release emails, and now that we have build-time warnings (which are long
> over-due, sorry!) I hope it will be more visible.  But I haven't come up
> with a good way to not too painfully email the 300 or so people listed
> as a maintainer for something under boards/.  I need to 'tho.
>
>> I also noticed this EFI support as big, but disabling it is more
>> complicated than disabling FIT, and we are at -rc3. Maybe I will send a
>> corresponding patch for the next merge window.
> It shouldn't be more than just disabling CONFIG_EFI_LOADER.
This works, thanks. I must have done something when I tried this 2 weeks
ago.
>
>>> And I do look at size changes, at least per push to master.  So most of
>>> the time it comes in "drips and drabs".  Right now I'm going to grow
>>> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
>>> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
>>> that's not super interesting, so lets look at v2018.09 to now.  That's
>>> 1800 bytes.  That's not too bad and looks like it's maybe half bug
>>> fixes, half working on various frameworks (sure, DM/DT stuff but also
>>> hash algos.  If we jump back to v2018.01, so more or less a year worth
>>> of changes, that's 19KiB.  Without trying to break down _everything_
>>> that's a good bit of EFI and a little bit everywhere else.
>> I fully understand that this is not a easy job for you. And usually a
>> few kiB are not a big deal. But the one kiB that overwrites the
>> environment on eMMC (and therefore often bricks the board) is very very
>> inconvenient for users.
> Right, it's bad, I agree.  Which is part of my further lament about the
> build-time size check.
>
> And all the shiny new driver model / OF features only bring
> 

Re: [U-Boot] [GIT] Pull request: u-boot-dfu (10.01.2019)

[Jean-Jacques Hiblot]

On 10/01/2019 09:51, Marek Vasut wrote:

On 1/10/19 8:37 AM, Lukasz Majewski wrote:

On Thu, 10 Jan 2019 01:53:23 +0100
Marek Vasut  wrote:


On 1/10/19 12:21 AM, Lukasz Majewski wrote:

Dear Marek,

I've build tested the patch set from Jean-Jacques on sunxi:

./tools/buildman/buildman.py --branch=HEAD sunxi --detail --verbose
--show_errors --force-build --count=5 --output-dir=../BUILD/

It also passes on Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/477104303

The following changes since commit
7436f5e54d35bcad53befec90e2e67288071f74e:

   Merge tag 'for-master-20190103' of
git://git.denx.de/u-boot-rockchip (2019-01-03 08:39:44 -0500)

are available in the git repository at:

   git://git.denx.de/u-boot-dfu.git

for you to fetch changes up to
97f2e698788eba9ee0ea51b3c2f34e989788:

   dm: usb: gadget: Fix boot breakage on sunxi platforms (2019-01-09
   01:04:36 +0100)


Jean-Jacques Hiblot (5):
   dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports
   ARM: dts: define USB aliases for all omap5 platforms
   Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
CONFIG_SPL_USB_GADGET
   usb: Make compiling gadget support optional
   dm: usb: gadget: Fix boot breakage on sunxi platforms

I think that's the wrong patch at the end, it still unconditionally
pulls in udc-uclass.o if CONFIG_$(SPL_)DM is enabled.


This is the order proposed by Jean-Jacques:

Just changing the order should be enough to prevent any breakage.

1) Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
CONFIG_SPL_USB_GADGET
2) usb: Make compiling gadget support optional
3) dm: usb: gadget: Fix boot breakage on sunxi platforms

But it's still unconditionally pulling in UDC code if DM is enabled,
which is what I was complaining in the previous PR too , can you explain
why ?


No it does not because the code in drivers/usb/gadget/udc is not 
compiled if CONFIG_$(SPL_)_USB_GADGET is not set (patch #2)






___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Issue with compiling uboot for SoC-eds arria 10

[Michael Nazzareno Trimarchi]

Hi

On Thu, Jan 10, 2019 at 2:16 PM Sujay Suresh  wrote:
>
> Please specify clearly what you're trying to convey!
>

Please keep in the loop mainling list. I ask you:
- what version of uboot do you build?
- please send a reasonable log to rid it (using service like pastebin)
and send a link to it

Michael

>
> 
> From: Michael Nazzareno Trimarchi 
> To: Sujay Suresh 
> Cc: "u-boot@lists.denx.de" 
> Sent: Thursday, January 10, 2019 5:54 PM
> Subject: Re: [U-Boot] Issue with compiling uboot for SoC-eds arria 10
>
> Hi
>
> On Thu, Jan 10, 2019 at 1:17 PM Sujay Suresh  wrote:
> >
> > Hi,
> > I am trying to compile uboot in my linux machine but the 2 bin file needed 
> > are not generating, instead I get these errors as in the picture enclosed.
>
> version of u-boot. Not add picture but pastbin resonable part of the
> build log. If you are running ubuntu in a virtual machine configure
> add on to do copy and paste
>
> Michael
>
> > Please Provide your support.
> > Best.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
> --
> | Michael Nazzareno TrimarchiAmarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172Amsterdam 1018 AM NL |
>
> |  [`as]
> http://www.amarulasolutions.com
>   |
>
>


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"

[Simon Glass]

On Mon, 7 Jan 2019 at 14:14, Simon Goldschmidt
 wrote:
>
> Add a driver for the "snps,dw-apb-uart" used in socfpga and others.
>
> This driver is required to get OF_PLATDATA to work for socfpga.
> It uses the ns16550 driver, converting the platdata from of-platdata
> go the ns16550 format.
>
> Signed-off-by: Simon Goldschmidt 
> ---
>
>  drivers/serial/Kconfig | 10 
>  drivers/serial/Makefile|  1 +
>  drivers/serial/serial_dw_apb.c | 42 ++
>  3 files changed, 53 insertions(+)
>  create mode 100644 drivers/serial/serial_dw_apb.c
>

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: serial: DEBUG_UART_SKIP_INIT depends on DEBUG_UART

[Simon Glass]

On Wed, 9 Jan 2019 at 12:27, Simon Goldschmidt
 wrote:
>
> DEBUG_UART_SKIP_INIT is used only by debug UART and thus should depend
> on DEBUG_UART.
>
> Signed-off-by: Simon Goldschmidt 
> ---
>
>  drivers/serial/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] xyz-modem: Fix timeout loop waiting with WATCHDOG

[Simon Glass]

On Tue, 8 Jan 2019 at 06:58, Lokesh Vutla  wrote:
>
> Commit 2c77c0d6524eb ("xyz-modem: Change getc timeout loop waiting")
> fixes the loop delay when using a hw watchdog, assuming that watchdog
> kicking is taken care of by getc(). But the xyzmodem driver tries to
> do a getc only after confirming that a character is available like below:
> while (!tstc()) {
> till timeout;
> }
> if (tstc())
> *c = getc();
>
> and getc() does a watchdog reset only if it fails to see a character.
> In this case, getc() always sees a character and never does a
> watchdog reset. So to make sure that watchdog doesn't get reset
> while loading the file, do a watchdog reset just before starting the
> image loading.
>
> Signed-off-by: Lokesh Vutla 
> Signed-off-by: Vignesh R 
> ---
> - This fixes uart boot on am335x-evm.
> Changes since v2:
> - Updated commit message.
>
>  common/xyzModem.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] kbuild: fix parallel build race caused by u-boot.cfg regeneration

[Simon Glass]

On Wed, 9 Jan 2019 at 00:32, Masahiro Yamada
 wrote:
>
> Multiple people have reported intermittent build failure in parallel
> building.
>
> Kever Yang reported this issue some time ago [1], but I could not
> get enough clue at that time.
>
> This time, Richard Purdie provided a complete build log [2], which
> was very helpful for me to root-cause it.
>
> The cause of the problem is commit 0d982c585330 ("Makefile: add
> dependencies to regenerate u-boot.cfg when lost").
>
> That commit added the 'cfg' as the prerequisite of the 'all' target,
> so the parallel build tries to run it simultaneously, then regenerates
> a symlink while building objects.
>
> When u-boot.cfg is accidentally lost, lets' rebuild it before
> descending into any subdirectories.
>
> Also, what is annoying is u-boot.cfg is currently regenerated every
> time since it depends on FORCE. We can get rid of all the prerequisites
> of u-boot.cfg because u-boot.cfg is rebuilt anyway as the byproduct of
> auto.conf when a user updates the .config file.
>
> [1] https://lists.denx.de/pipermail/u-boot/2018-June/330341.html
> [2] 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/160/steps/7/logs/step1b
>
> Fixes: 0d982c585330 ("Makefile: add dependencies to regenerate u-boot.cfg 
> when lost")
> Reported-by: Kever Yang 
> Reported-by: Richard Purdie 
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pylibfdt: Use Python 2 in Makefile

[Simon Glass]

On Tue, 8 Jan 2019 at 06:19, Josef Lusticky  wrote:
>
> pylibfdt needs Python 2 to build.
> Replace $(PYTHON) with $(PYTHON2) in pylibfdt Makefile
> to ensure Python 2 is used to build it.
>
> This fixes build on systems where Python 3 is the default version
> of the "python" interpreter.
> ---
>  scripts/dtc/pylibfdt/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

At some point we should sync this with upstream which I think plans to
support both.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: ns16550: fix debug uart putc called before init

[Simon Glass]

On Wed, 9 Jan 2019 at 12:35, Simon Goldschmidt
 wrote:
>
> If _debug_uart_putc() is called before _debug_uart_init(), the
> ns16550 debug uart driver hangs in a tight loop waiting for the
> tx FIFO to get empty.
>
> As this can happen via a printf sneaking in before the port calls
> debug_uart_init(), introduce a config option to ignore characters
> before the debug uart is initialized.
>
> This is done by reading the baudrate divisor and aborting if is zero.
>
> The Kconfig option is required as reading the baudrate divisor does
> not seem to work for all ns16500 compatibles (which is why the last
> attempt on this has been reverted in 1a67969a99).
>
> Tested on socfpga_cyclone5_socrates.
>
> Signed-off-by: Simon Goldschmidt 
> ---
>
>  drivers/serial/Kconfig   | 12 
>  drivers/serial/ns16550.c | 20 ++--
>  2 files changed, 30 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "dm: pinctrl: Prevent (re-)configuring pins when already done before relocation"

[Simon Glass]

On Wed, 9 Jan 2019 at 15:05, Lukasz Majewski  wrote:
>
> This reverts commit a7f4b4b344396590845e6552c82829ef68ef9f89.
>
> As reported by Alex Kiernan the above optimization introduces a
> regression in the below use case where:
>
> 1. Device has defined 'u-boot,dm-spl' property (@ eMMC DTS node)
>
> 2. The device downloads its MLO/SPL via UART (not eMMC - the eMMC pinmux
> pins are NOT probed/configured in MLO/SPL).
>
> 3. The loaded via UART MLO/SPL wants to load Linux from eMMC. In this case
> the DM core and pinctrl uclass checks 'u-boot,dm-spl' and don't
> configure pins (as it thinks that those were initialized in MLO/SPL).
>
> As we are very close to release - please revert this commit.
>
> Reported-by: Alex Kiernan 
> Signed-off-by: Lukasz Majewski 
>
> ---
>
>  drivers/pinctrl/pinctrl-uclass.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/2] x86: edison: Switch to CONFIG_OF_SEPARATE

[Simon Glass]

On Tue, 8 Jan 2019 at 07:17, Andy Shevchenko
 wrote:
>
> There is no need for Intel Edison to have CONFIG_OF_EMBED to be enabled.
> Replace it with CONFIG_OF_SEPARATE.
>
> There is no functional change since u-boot.bin always contains DTB
> either embedded or attached.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  configs/edison_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] power: regulator: Introduce regulator_set_enable_if_allowed api

[Simon Glass]

On Sun, 6 Jan 2019 at 23:13, Lokesh Vutla  wrote:
>
> regulator_set_enable() api throws an error in the following three cases:
> - when requested to disable an always-on regulator
> - when set_enable() ops not provided by regulator driver
> - when enabling is actually failed.(Error returned by the regulator driver)
>
> Sometimes consumer drivers doesn't want to track the first two scenarios
> and just need to worry about the case where enabling is actually failed.
> But it is also a good practice to have an error value returned in the
> first two cases.
>
> So introduce an api regulator_set_enable_if_allowed() which ignores the
> first two error cases and returns an error as given by regulator driver.
> Consumer drivers can use this api need not worry about the first two
> error conditions.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  drivers/power/regulator/regulator-uclass.c | 11 +++
>  include/power/regulator.h  | 11 +++
>  2 files changed, 22 insertions(+)

Thanks for the patch. But please do adjust the tests to call this
function and check that it does the right thing.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot