Re: [U-Boot] [PATCH] rockchip: rk3399: update MAINTAINER file

[Simon Glass]

On 9 August 2016 at 09:56, Andreas Färber  wrote:
>
> Am 09.08.2016 um 16:35 schrieb Simon Glass:
> > +Andreas
> >
> > On 9 August 2016 at 01:29, Kever Yang  wrote:
> >> This patch add maintainer information for rk3399 evb.
> >>
> >> Signed-off-by: Kever Yang 
> >> ---
> >>
> >>  board/rockchip/evb_rk3399/MAINTAINERS | 6 ++
> >>  1 file changed, 6 insertions(+)
> >
> > Acked-by: Simon Glass 
>
> Thanks,
>
> Reviewed-by: Andreas Färber 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: usb: xhci-fsl: Change burst beat and outstanding pipelined transfers requests

[Marek Vasut]

On 08/19/2016 07:51 AM, Sriram Dash wrote:
> This is required for better performance, and performs below tuning:
> 1. Enable burst length set, and define it as 4/8/16.
> 2. Set burst request limit to 16 requests.
> 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: Sriram Dash 
> ---
>  drivers/usb/host/xhci-fsl.c  | 13 +
>  include/linux/usb/xhci-fsl.h |  3 +++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
> index bdcd4f1..082924f 100644
> --- a/drivers/usb/host/xhci-fsl.c
> +++ b/drivers/usb/host/xhci-fsl.c
> @@ -58,6 +58,16 @@ static void fsl_apply_xhci_errata(void)
>   }
>  }
>  
> +static void fsl_xhci_set_beat_burst_length(struct dwc3 *dwc3_reg)
> +{
> + int val = readl(_reg->g_sbuscfg0);
> +
> + val &= ~USB3_ENABLE_BEAT_BURST_MASK;
> + writel(val | USB3_ENABLE_BEAT_BURST, _reg->g_sbuscfg0);
> + val = readl(_reg->g_sbuscfg1);
> + writel(val | USB3_SET_BEAT_BURST_LIMIT, _reg->g_sbuscfg1);

setbits_le32() ?

> +}
> +
>  static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci)
>  {
>   int ret = 0;
> @@ -74,6 +84,9 @@ static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci)
>   /* Set GFLADJ_30MHZ as 20h as per XHCI spec default value */
>   dwc3_set_fladj(fsl_xhci->dwc3_reg, GFLADJ_30MHZ_DEFAULT);
>  
> + /* Change beat burst and outstanding pipelined transfers requests */
> + fsl_xhci_set_beat_burst_length(fsl_xhci->dwc3_reg);
> +
>   return ret;
>  }
>  
> diff --git a/include/linux/usb/xhci-fsl.h b/include/linux/usb/xhci-fsl.h
> index 199f366..1032763 100644
> --- a/include/linux/usb/xhci-fsl.h
> +++ b/include/linux/usb/xhci-fsl.h
> @@ -20,6 +20,9 @@
>  #define USB3_PHY_TX_RX_POWERON   (USB3_PHY_RX_POWERON | 
> USB3_PHY_TX_POWERON)
>  #define USB3_PWRCTL_CLK_CMD_SHIFT   14
>  #define USB3_PWRCTL_CLK_FREQ_SHIFT   22
> +#define USB3_ENABLE_BEAT_BURST   0xF
> +#define USB3_ENABLE_BEAT_BURST_MASK  0xFF
> +#define USB3_SET_BEAT_BURST_LIMIT0xF00
>  
>  /* USBOTGSS_WRAPPER definitions */
>  #define USBOTGSS_WRAPRESET   BIT(17)
> 


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

Re: [U-Boot] [UBOOT PATCH 1/4] armv7: psci: make v7_flush_dcache_all public for all psci code

[Tom Rini]

On Fri, Aug 19, 2016 at 05:20:30PM +0800, macro.wav...@gmail.com wrote:

> From: Hongbo Zhang 
> 
> The v7_flush_dcache_all function will be called by ls102xa platform system
> suspend, it is necessary to make it a public call instead of a local one, but
> changing the LENTRY to ENTRY isn't enough, because there is another one using
> the same name, so this one gets a psci_ prefix.
> 
> Signed-off-by: Hongbo Zhang 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ARM: OMAP4+: vcores: Remove duplicated code

[Tom Rini]

On Wed, Aug 17, 2016 at 04:25:36PM +0530, Lokesh Vutla wrote:

> There is no reason to duplicate code for DRA7xx platforms as there
> can be Rail grouping. The maximum voltage detection algorithm can still
> be run on other platforms with no Rail grouping and does not harm as
> it gives the same result.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] tools/env: soften warning about erase block alignment

[Tom Rini]

On Wed, Aug 17, 2016 at 11:41:54PM +0200, Andreas Fenkart wrote:

> addon 183923d3e
> MMC/SATA have no erase blocks, only blocks. Hence the warning
> about erase block alignment might be confusing in such environment.
> 
> Signed-off-by: Andreas Fenkart 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] tools/env: return with error if redundant environments have unequal size

[Tom Rini]

On Wed, Aug 17, 2016 at 11:41:53PM +0200, Andreas Fenkart wrote:

> For double buffering to work, the target buffer must always be big
> enough to hold all data. This can only be ensured if buffers are of
> equal size, otherwise one must be smaller and we risk data loss
> when copying from the bigger to the smaller buffer.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Andreas Fenkart 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ARM: OMAP5+: vcores: Drop unnecessary #ifndefs

[Tom Rini]

On Wed, Aug 17, 2016 at 04:25:35PM +0530, Lokesh Vutla wrote:

> gpio_en field is introduced to detect if pmic is controlled by GPIO.
> Make this field 0 on all TPS659* pmics available on DRA7/OMAP5 based platforms
> and remove the #ifndefs.
> 
> Reviewed-by:  Keerthy 
> Signed-off-by: Lokesh Vutla 

The gpio_en field is part of the BSS and would already be 0, however,
this makes the code clearer when reading when is important, so I'm OK
with the change.

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL__SUPPORT as Kconfig option

[Tom Rini]

On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
> > Hello Andrew,
> > 
> > first thanks for this series!
> > 
> > Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
> >> Create a new Kconfig file to contain SPL boot media loading support
> >> options as we begin moving these to the Kconfig system and out of header
> >> files. Initially add new configs for all the existing boot media types,
> >> giving them the same definition name as before to allow compatibility
> >> with systems not yet using Kconfig.
> >>
> >> Signed-off-by: Andrew F. Davis 
> >> ---
> >>   common/Kconfig |  7 +++
> >>   common/spl/Kconfig | 54
> >> ++
> >>   2 files changed, 61 insertions(+)
> >>   create mode 100644 common/spl/Kconfig
> >>
> >> diff --git a/common/Kconfig b/common/Kconfig
> >> index 46e7173..f594db5 100644
> >> --- a/common/Kconfig
> >> +++ b/common/Kconfig
> >> @@ -156,6 +156,13 @@ config SPI_BOOT
> >> booted via SPI flash. This is not a must, some SoCs need this,
> >> somes not.
> >>
> >> +menu "SPL Media Loading Support"
> >> +depends on SPL
> >> +
> >> +source "common/spl/Kconfig"
> >> +
> >> +endmenu
> >> +
> >>   endmenu
> >>
> >>   config BOOTDELAY
> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >> new file mode 100644
> >> index 000..788ca14
> >> --- /dev/null
> >> +++ b/common/spl/Kconfig
> >> @@ -0,0 +1,54 @@
> >> +config SPL_YMODEM_SUPPORT
> >> +depends on SPL
> >> +bool "SPL Support for loading next stage from UART"
> >> +help
> >> +  This option enables SPL to load the next stage bootloader
> >> +  over a UART line using the x/y/z/modem protocol.
> >> +
> >> +config SPL_MMC_SUPPORT
> >> +bool "SPL Support for loading next stage from SD/MMC/eMMC"
> >> +help
> >> +  This option enables SPL to load the next stage bootloader
> >> +  from an SD/MMC/eMMC device.
> > 
> > Hmm.. why do you not move, for existing board configs, which use
> > this symbols, them into their defconfigs? There is the great
> > script from Masahiro
> > 
> > u-boot:tools/moveconfig.py
> > 
> > which should do the most things for you ... 
> 
> Maybe I'm not understanding this script but after getting it to run it
> doesn't seem to find any uses of the config, I'm not sure this works
> with SPL configs, as the check looks only at the non-SPL build case as
> far as I can tell.

Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ext4: fix possible crash on directory traversal, ignore deleted entries

[Tom Rini]

On Sun, Aug 14, 2016 at 05:11:04AM +0200, Stefan Brüns wrote:

> The following command triggers a segfault in search_dir:
> ./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
> ext4write host 0 0 /./foo 0x10'
> 
> The following command triggers a segfault in check_filename:
> ./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
> ext4write host 0 0 /. 0x10'
> 
> "." is the first entry in the directory, thus previous_dir is NULL. The
> whole previous_dir block in search_dir seems to be a bad copy from
> check_filename(...). As the changed data is not written to disk, the
> statement is mostly harmless, save the possible NULL-ptr reference.
> 
> Typically a file is unlinked by extending the direntlen of the previous
> entry. If the entry is the first entry in the directory block, it is
> invalidated by setting inode=0.
> 
> The inode==0 case is hard to trigger without crafted filesystems. It only
> hits if the first entry in a directory block is deleted and later a lookup
> for the entry (by name) is done.
> 
> Signed-off-by: Stefan Brüns 
> ---
>  fs/ext4/ext4_common.c | 57 
> ++-
>  fs/ext4/ext4_write.c  |  2 +-
>  include/ext4fs.h  |  2 +-
>  3 files changed, 22 insertions(+), 39 deletions(-)

Can you please add the test case to the existing scripts?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL__SUPPORT as Kconfig option

[Andrew F. Davis]

On 08/19/2016 01:27 AM, Heiko Schocher wrote:
> Hello Andrew,
> 
> first thanks for this series!
> 
> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
>> Create a new Kconfig file to contain SPL boot media loading support
>> options as we begin moving these to the Kconfig system and out of header
>> files. Initially add new configs for all the existing boot media types,
>> giving them the same definition name as before to allow compatibility
>> with systems not yet using Kconfig.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>   common/Kconfig |  7 +++
>>   common/spl/Kconfig | 54
>> ++
>>   2 files changed, 61 insertions(+)
>>   create mode 100644 common/spl/Kconfig
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index 46e7173..f594db5 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -156,6 +156,13 @@ config SPI_BOOT
>> booted via SPI flash. This is not a must, some SoCs need this,
>> somes not.
>>
>> +menu "SPL Media Loading Support"
>> +depends on SPL
>> +
>> +source "common/spl/Kconfig"
>> +
>> +endmenu
>> +
>>   endmenu
>>
>>   config BOOTDELAY
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> new file mode 100644
>> index 000..788ca14
>> --- /dev/null
>> +++ b/common/spl/Kconfig
>> @@ -0,0 +1,54 @@
>> +config SPL_YMODEM_SUPPORT
>> +depends on SPL
>> +bool "SPL Support for loading next stage from UART"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  over a UART line using the x/y/z/modem protocol.
>> +
>> +config SPL_MMC_SUPPORT
>> +bool "SPL Support for loading next stage from SD/MMC/eMMC"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from an SD/MMC/eMMC device.
> 
> Hmm.. why do you not move, for existing board configs, which use
> this symbols, them into their defconfigs? There is the great
> script from Masahiro
> 
> u-boot:tools/moveconfig.py
> 
> which should do the most things for you ... 

Maybe I'm not understanding this script but after getting it to run it
doesn't seem to find any uses of the config, I'm not sure this works
with SPL configs, as the check looks only at the non-SPL build case as
far as I can tell.

There is also the more complex cases where _SUPPORT option are only
defined in the config.h files when some other option is defined, this
conditional dependency will need to be translated in each defconfig file.

Thanks,
Andrew

> also there is a tbot
> testcase, with which you can test, that your new patch(es) do not
> break an existing board, see for interests:
> 
> http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
> 
> Same comment applies for your patches:
> [U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL__BOOT as Kconfig option
> [U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig
> option
> 
> May you want to try it? If you have problems, feel free to contact me.
> 
> bye,
> Heiko
> 
>> +
>> +config SPL_SPI_SUPPORT
>> +bool "SPL Support for loading next stage from SPI flash"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from SPI flash.
>> +
>> +config SPL_USB_SUPPORT
>> +bool "SPL Support for loading next stage from USB"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from a USB device.
>> +
>> +config SPL_SATA_SUPPORT
>> +bool "SPL Support for loading next stage from SATA"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from a SATA device.
>> +
>> +config SPL_NOR_SUPPORT
>> +bool "SPL Support for loading next stage from NOR flash"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from NOR flash.
>> +
>> +config SPL_NAND_SUPPORT
>> +bool "SPL Support for loading next stage from NAND flash"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from NAND flash.
>> +
>> +config SPL_ONENAND_SUPPORT
>> +bool "SPL Support for loading next stage from ONENAND"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from ONENAND.
>> +
>> +config SPL_NET_SUPPORT
>> +bool "SPL Support for loading next stage from NET"
>> +help
>> +  This option enables SPL to load the next stage bootloader
>> +  from NET.
>>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] Fix up issues with new NFSv3 implementation

[Joe Hershberger]

On Mon, Aug 15, 2016 at 3:03 PM, Joe Hershberger  wrote:
> This fixes most of the memory bloat that happened with the addition of NFSv3
> Some checkpatch.pl issues are also fixed
> Refactored some code to better share common snippets
>
> These patches depend on the NFSv3 patch by Guillaume GARDET 
> 
> https://patchwork.ozlabs.org/patch/654061/
>
>
> Joe Hershberger (9):
>   net: nfs: Share the file handle buffer for v2 / v3
>   net: nfs: Correct the reply data buffer size
>   net: nfs: Fix lines that are too long
>   net: nfs: Consolidate handling of NFSv3 attributes
>   net: nfs: Correct a comment
>   net: nfs: Use consistent names for the rpc_pkt
>   net: nfs: Move some prints to debug statements
>   net: nfs: Use the tx buffer to construct rpc msgs
>   net: nfs: Simplify rpc_add_credentials()

Barring any comments on this, I'm going to pull these in next week.

Thanks,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Clean up some NFS issues not related to v3 support

[Joe Hershberger]

On Mon, Aug 15, 2016 at 2:42 PM, Joe Hershberger  wrote:
> There were a few issues with related to NFS that existed previously.
> Clean those up before adding v3 support.
>
>
> Joe Hershberger (3):
>   net: Stop including NFS overhead in defragment max
>   net: nfs: Remove separate buffer for default name
>   net: nfs: Remove unused define

Barring any comments on this, I'm going to pull it in next week.

Thanks,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net/fm: Remove unused code of FMan QMI

[Joe Hershberger]

On Thu, Aug 18, 2016 at 10:35 PM, Zhiqiang Hou  wrote:
> From: Hou Zhiqiang 
>
> The QMan is not used in FMan IM mode, so no QMI enqueue or QMI
> dequeue are performed.
>
> Signed-off-by: Hou Zhiqiang 

Seems reasonable.

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/5] Remove calls from net drivers to legacy miiphy_register() entry-point

[Joe Hershberger]

Hi Karl,

On Fri, Aug 19, 2016 at 3:14 AM, Karl Beldan  wrote:
> On Mon, Aug 08, 2016 at 11:28:36AM -0500, Joe Hershberger wrote:
>>
>> This is an effort to migrate closer to the phylib approach so that a
>> new DM approach can be developed from a single starting point. The more
>> of this legacy code that can be removed, the easier it will be to move
>> forward.
>>
>
> Hi Joe,
>
> It was nice to see spatch put to work. However davinci_emac crashes
> U-Boot now. It is an invasive patch so it might take time to check
> everything is in order, so unless you already have a follow-up series I
> can send in a trivial patch just now to fix that for davinci_emac.

That's a bummer. Is it a systemic problem that you expect to affect
more drivers or is it something that is likely to only affect davinci?

Yes, please sent a patch to fix it up.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: disk: Fix CONFIG_BLK breakage

[Tom Rini]

On Fri, Aug 12, 2016 at 08:19:42PM +0200, Alexander Graf wrote:
> 
> 
> On 12.08.16 19:20, Simon Glass wrote:
> > Hi Alex,
> > 
> > On 10 August 2016 at 13:01, Alexander Graf  wrote:
> >>
> >>> On 10 Aug 2016, at 18:25, Tom Rini  wrote:
> >>>
> >>> On Wed, Aug 10, 2016 at 03:25:16PM +0200, Alexander Graf wrote:
> 
> 
> > Am 10.08.2016 um 15:16 schrieb Simon Glass :
> >
> > Hi Alex,
> >
> >> On 10 August 2016 at 07:02, Alexander Graf  wrote:
> >>> On 08/10/2016 02:56 PM, Simon Glass wrote:
> >>>
> >>> +Tom
> >>>
> >>> Hi Alex,
> >>>
> >>> On 10 August 2016 at 01:47, Alexander Graf  wrote:
> >
> > On 08 Aug 2016, at 23:44, Simon Glass  wrote:
> >
> > Hi Alexander,
> >
> >> On 5 August 2016 at 06:49, Alexander Graf  wrote:
> >>
> >> When using CONFIG_BLK, there were 2 issues:
> >>
> >> 1) The name we generate the device with has to match the
> >>name we set in efi_set_bootdev()
> >>
> >> 2) The device we pass into our block functions was wrong,
> >>we should not rediscover it but just use the already known
> >>pointer.
> >>
> >> This patch fixes both issues.
> >>
> >> Signed-off-by: Alexander Graf 
> >> ---
> >> cmd/bootefi.c | 23 ++-
> >> lib/efi_loader/efi_disk.c | 18 +++---
> >> 2 files changed, 29 insertions(+), 12 deletions(-)
> >>> [...]
> >>>
> >> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> >> index c434c92..e00a747 100644
> >> --- a/lib/efi_loader/efi_disk.c
> >> +++ b/lib/efi_loader/efi_disk.c
> >> @@ -31,6 +31,8 @@ struct efi_disk_obj {
> >>   struct efi_device_path_file_path *dp;
> >>   /* Offset into disk for simple partitions */
> >>   lbaint_t offset;
> >> +   /* Internal block device */
> >> +   const struct blk_desc *desc;
> >
> > Rather than storing this, can you store the udevice?
> 
>  I could, but then I would diverge between the CONFIG_BLK and
>  non-CONFIG_BLK path again, which would turn the code into an #ifdef 
>  mess
>  (read: hard to maintain), because the whole device creation path 
>  relies on
>  struct blk_desc * today and doesn’t pass the udevice anywhere.
> 
>  Do you feel strongly about this? To give you an idea how messy it 
>  gets,
>  the diff is below.
> >>>
> >>> Actually I'd like to make this feature depend on CONFIG_BLK. If we add
> >>> new features that don't use driver model, and then use the legacy data
> >>> structures such that converting to driver model becomes harder, we'll
> >>> never be done.
> >>>
> >>> I did mention this at the beginning and it seems to have come to pass.
> >>>
> >>> In order of preference from my side:
> >>>
> >>> 1. Make EFI_LOADER depend on BLK
> >>
> >>
> >> If we make EFI_LOADER depend on BLK, doesn't that break all systems 
> >> that
> >> need storage that isn't converted to device model today? Like the SATA
> >> breakage on Xilinx systems, just at a much bigger scale?
> >
> > No it just means that these platforms need to move to BLK before they
> > can use the EFI loader. Given the embryonic nature of this feature,
> > that seems reasonable, and the impact would be small. It will also
> > encourage conversion and keep the code cleaner.
> 
>  No, it will simply make my life harder because I would have to sit
>  down and vonvert every single board to BLK that I need EFI enabled.
> >>>
> >>> Seems like as good a place as any to jump in, of the boards that you
> >>> need EFI enabled on, what isn't converted today?
> >>
> >> I want to make EFI the default boot path in openSUSE, which means any 
> >> board that anyone out there wants to run openSUSE on would be on the list. 
> >> Anything that keeps them from running EFI on a random board is a road 
> >> block that I’d rather not have if I can avoid it.
> > 
> > Of course, I fully understand that. However as mentioned in this
> > patch, you are creating future problems.
> 
> I don't see how I am creating future problems, really. Passing a
> udevice* instead of the struct blk_desc* internally doesn't improve the
> code really at the end of the day.
> 
> > Can you address Tom's question? I take it that it boots on Raspberry
> > Pi (which I'd like to try actually - are there instructions
> > somewhere?). We can easily convert that over. Anything else?
> 
> For a list of currently available "upstream" openSUSE images, see
> 

Re: [U-Boot] [PATCH] spi: tegra: fix hand in set_mode()

[Stephen Warren]

On 08/19/2016 10:56 AM, Jagan Teki wrote:

On 18 August 2016 at 22:23, Stephen Warren  wrote:

From: Stephen Warren 

In tegra20_slink.c, the set_mode() function may be executed before the
SPI bus is claimed the first time, and hence the clocks to the SPI
controller may not be running. If so, any register read/write at this
time will hang the CPU. Fix this by ensuring the clock is running as soon
as the driver is probed. This is observed on the Tegra30 Beaver board.

Apply the same clock initialization fix to all other Tegra SPI drivers so
that if set_mode() is ever implemented there, the same bug will not appear.
Note that tegra114_spi.c already operates in this fashion.

The clock manipulation code is copied from claim_bus() to probe() rather
than moved. This ensures that any calls to set_speed() take effect; the
clock can't be set once during probe and left unchanged.


Do we need to set the clock for claim_bus() as well? I think it's
better to move this on to set_speed so-that any call to set_speed()
will update the same. I don't think claim_bus would require this
again.


I explained this in the commit message: The clock rate needs to be set 
in claim_bus() so that the frequency requested by set_speed() is in force.

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

Re: [U-Boot] [PATCH] spi: tegra: fix hand in set_mode()

[Jagan Teki]

On 18 August 2016 at 22:23, Stephen Warren  wrote:
> From: Stephen Warren 
>
> In tegra20_slink.c, the set_mode() function may be executed before the
> SPI bus is claimed the first time, and hence the clocks to the SPI
> controller may not be running. If so, any register read/write at this
> time will hang the CPU. Fix this by ensuring the clock is running as soon
> as the driver is probed. This is observed on the Tegra30 Beaver board.
>
> Apply the same clock initialization fix to all other Tegra SPI drivers so
> that if set_mode() is ever implemented there, the same bug will not appear.
> Note that tegra114_spi.c already operates in this fashion.
>
> The clock manipulation code is copied from claim_bus() to probe() rather
> than moved. This ensures that any calls to set_speed() take effect; the
> clock can't be set once during probe and left unchanged.

Do we need to set the clock for claim_bus() as well? I think it's
better to move this on to set_speed so-that any call to set_speed()
will update the same. I don't think claim_bus would require this
again.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] mx7: ums command does not mount SD card partitions

[Fabio Estevam]

Hi Peng/Ye Li,

We are trying the 'ums' command on a mx7d sabresd board running the
latest U-Boot code from u-boot-imx tree:

=> ums 0 mmc 0

This should make the content of the SD card to be mounted on the host
PC and the two SD card partition should pop up in the screen.

We do see the two partitions icons to appear on the host, but the two
SD card partitions are not mounted automatically.

We see this behavior on a mx7d sabresd and also mx7s warp boards.

In other mx6 boards the partitions are correctly mounted.

We also tested the following command in the kernel on a mx7d sabresd:

modprobe g_mass_storage file=/dev/mmcblk0

and the SD card partitions are always automatically mounted.

Any ideas as to why U-boot ums do not mount the SD card partitions
automatically?

Thanks,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL__BOOT as Kconfig option

[Andrew F. Davis]

On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
> 
> 
> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>> Currently U-Boot proper has Kconfig options that enable the generation
>> of U-Boot binaries that are capable of being booted from the selected
>> boot media type. The same set of generation targets for SPL are assumed
>> with various methods and config header hackery. On some platforms the
>> options for SPL, such as load address, are dependent on boot type
>> and cannot depend on boot image type selected for U-Boot proper.
>> Add a Kconfig menu to select SPL boot image types, and populate it
>> with the same media types as are already available for U-Boot proper.
>> Uses of this option are added later.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>  common/Kconfig | 69 
>> ++
>>  1 file changed, 69 insertions(+)
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index f594db5..90ba5b2 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -156,6 +156,75 @@ config SPI_BOOT
>>booted via SPI flash. This is not a must, some SoCs need this,
>>somes not.
>>  
>> +menu "SPL Boot media"
>> +depends on SPL
>> +
>> +config SPL_NOR_BOOT
>> +bool "Support for booting SPL from NOR flash"
>> +default n
> 
> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
> 

Nope, these simply enable the SPL to be built for being itself loaded
from this media, for instance the SPL does not need to know how to load
images over UART just because it itself was.

> May be a dump question. Do you see any issue with using
> SPL__SUPPORT config for the same purpose as SPL__BOOT
> instead of creating a new defconfig?
> 

Kind of the same answer as above, the idea is that _SUPPORT is for
adding the ability to load images from a media type to the SPL, and
_BOOT is to inform the make system to generate an SPL image that can be
loaded from this media. This mirrors, for SPL, the same options that
already exist for U-Boot proper.

Now something that I had considered was using the U-Boot proper _BOOT
options to determine what kinds of media the SPL should know how to load
images from, but this becomes very complex and would led to
misunderstandings of the options, like the one I correct in patch 8, so
I have kept them independent of each other.

Thanks,
Andrew

> Thanks and regards,
> Lokesh
> 
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via NOR flash. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_NAND_BOOT
>> +bool "Support for booting SPL from NAND flash"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via NAND flash. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_ONENAND_BOOT
>> +bool "Support for booting SPL from ONENAND"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via ONENAND. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_QSPI_BOOT
>> +bool "Support for booting SPL from QSPI flash"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via QSPI flash. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_SATA_BOOT
>> +bool "Support for booting SPL from SATA"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via SATA. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_SD_BOOT
>> +bool "Support for booting SPL from SD/MMC/eMMC"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via SD/MMC/eMMC. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_SPI_BOOT
>> +bool "Support for booting SPL from SPI flash"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via SPI flash. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +config SPL_UART_BOOT
>> +bool "Support for booting SPL from UART"
>> +default n
>> +help
>> +  Enabling this will make an SPL binary that is capable of being
>> +  booted via UART. This is not a must, some SoCs need this,
>> +  some do not.
>> +
>> +endmenu
>> +
>>  menu "SPL Media Loading Support"
>>  depends on SPL
>>  
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] ext4: more fixes for possible file system corruption

[Lukasz Majewski]

Hi Stefan,

> The two patches fix two more possible corruptions of ext filesystems
> during write operations.
> 
> This goes ontop the previous pending patches.
> 
> Stefan Brüns (2):
>   ext4: Avoid corruption of directories with hash tree indexes
>   ext4: scan all directory blocks when looking up an entry
> 

Would you consider adding proper tests to our test framework (@./test
directory), so we would avoid ext4 regressions in the future?

Thanks for your effort and preparing patches.  

>  fs/ext4/ext4_common.c | 74
> +++
> fs/ext4/ext4_write.c  |  5  include/ext4fs.h  |  1 +
>  3 files changed, 39 insertions(+), 41 deletions(-)
> 



-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ext4: scan all directory blocks when looking up an entry

[Lukasz Majewski]

Hi Stefan,

> Scanning only the direct blocks of the directory file may falsely
> report an existing file as nonexisting, and worse can also lead to
> creation of a duplicate entry on file creation.
> 
> Signed-off-by: Stefan Brüns 
> ---
>  fs/ext4/ext4_common.c | 74
> +++ 1 file changed,
> 33 insertions(+), 41 deletions(-)
> 
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index 8d0013e..aa72b0d 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -500,64 +500,53 @@ static int search_dir(struct ext2_inode
> *parent_inode, char *dirname) {
>   int status;
>   int inodeno = 0;
> - int totalbytes;
> - int templength;
> - int direct_blk_idx;
> + int offset;
> + int blk_idx;
>   long int blknr;
> - char *ptr = NULL;
>   unsigned char *block_buffer = NULL;
>   struct ext2_dirent *dir = NULL;
>   struct ext_filesystem *fs = get_fs();
> + uint32_t directory_blocks;
>  
> - /* read the block no allocated to a file */
> - for (direct_blk_idx = 0; direct_blk_idx < INDIRECT_BLOCKS;
> - direct_blk_idx++) {
> - blknr = read_allocated_block(parent_inode,
> direct_blk_idx);
> - if (blknr == 0)
> - goto fail;
> + directory_blocks = le32_to_cpu(g_parent_inode->size) >>
> + LOG2_BLOCK_SIZE(ext4fs_root);
>  
> - /* read the blocks of parent inode */
> - block_buffer = zalloc(fs->blksz);
> - if (!block_buffer)
> + block_buffer = zalloc(fs->blksz);
> + if (!block_buffer)
> + goto fail;
> +
> + /* get the block no allocated to a file */
> + for (blk_idx = 0; blk_idx < directory_blocks; blk_idx++) {
> + blknr = read_allocated_block(parent_inode, blk_idx);
> + if (blknr == 0)
>   goto fail;
>  
> + /* read the directory block */
>   status = ext4fs_devread((lbaint_t)blknr *
> fs->sect_perblk, 0, fs->blksz, (char *)block_buffer);
>   if (status == 0)
>   goto fail;
>  
> + offset = 0;
>   dir = (struct ext2_dirent *)block_buffer;
> - ptr = (char *)dir;
> - totalbytes = 0;
> - while (le16_to_cpu(dir->direntlen) >= 0) {
> - /*
> -  * blocksize-totalbytes because last
> directory
> -  * length i.e.,*dir->direntlen is free
> availble
> -  * space in the block that means
> -  * it is a last entry of directory entry
> -  */
> - if (dir->inode && (strlen(dirname) ==
> dir->namelen)) {
> - if (strncmp(dirname, ptr +
> sizeof(struct ext2_dirent), dir->namelen) == 0) {
> - inodeno =
> le32_to_cpu(dir->inode);
> - break;
> - }
> + while (le16_to_cpu(dir->direntlen) >= 8) {
> + if (dir->inode && (strlen(dirname) ==
> dir->namelen) &&
> + (strncmp(dirname, [1], dir->namelen)
> == 0)) {
> + inodeno = le32_to_cpu(dir->inode);
> + break;
>   }
>  
> - if (fs->blksz - totalbytes ==
> le16_to_cpu(dir->direntlen))
> + offset += le16_to_cpu(dir->direntlen);
> + if (offset >= fs->blksz)
>   break;
>  
> - /* traversing the each directory entry */
> - templength = le16_to_cpu(dir->direntlen);
> - totalbytes = totalbytes + templength;
> - dir = (struct ext2_dirent *)((char *)dir +
> templength);
> - ptr = (char *)dir;
> + dir = (struct ext2_dirent *)(block_buffer +
> offset); }
>  
> - free(block_buffer);
> - block_buffer = NULL;
> -
> - if (inodeno > 0)
> + if (inodeno > 0) {
> + free(block_buffer);
>   return inodeno;
> + }
>   }
>  
>  fail:
> @@ -809,14 +798,17 @@ fail:
>  
>  int ext4fs_filename_unlink(char *filename)
>  {
> - short direct_blk_idx = 0;
> + int blk_idx;
>   long int blknr = -1;
>   int inodeno = -1;
> + uint32_t directory_blocks;
> +
> + directory_blocks = le32_to_cpu(g_parent_inode->size) >>
> + LOG2_BLOCK_SIZE(ext4fs_root);
>  
>   /* read the block no allocated to a file */
> - for (direct_blk_idx = 0; direct_blk_idx < INDIRECT_BLOCKS;
> - direct_blk_idx++) {
> - blknr = read_allocated_block(g_parent_inode,
> direct_blk_idx);
> + for (blk_idx = 0; blk_idx < directory_blocks; blk_idx++) {
> +  

Re: [U-Boot] [PATCH 1/2] ext4: Avoid corruption of directories with hash tree indexes

[Lukasz Majewski]

Hi Stefan,

> While directories can be read using the old linear scan method,
> adding a new file would require updating the index tree
> (alternatively, the whole tree could be removed).
> 
> Signed-off-by: Stefan Brüns 
> ---
>  fs/ext4/ext4_write.c | 5 +
>  include/ext4fs.h | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
> index 4235b95..ccc8a9c 100644
> --- a/fs/ext4/ext4_write.c
> +++ b/fs/ext4/ext4_write.c
> @@ -864,6 +864,11 @@ int ext4fs_write(const char *fname, unsigned
> char *buffer, goto fail;
>   if (ext4fs_iget(parent_inodeno, g_parent_inode))
>   goto fail;
> + /* do not mess up a directory using hash trees */
> + if (le32_to_cpu(g_parent_inode->flags) & EXT4_INDEX_FL) {
> + printf("hash tree directory\n");
> + goto fail;
> + }
>   /* check if the filename is already present in root */
>   existing_file_inodeno = ext4fs_filename_unlink(filename);
>   if (existing_file_inodeno != -1) {
> diff --git a/include/ext4fs.h b/include/ext4fs.h
> index e3f6216..6e31c73 100644
> --- a/include/ext4fs.h
> +++ b/include/ext4fs.h
> @@ -28,6 +28,7 @@
>  #define __EXT4__
>  #include 
>  
> +#define EXT4_INDEX_FL0x1000 /* Inode uses hash
> tree index */ #define EXT4_EXTENTS_FL 0x0008 /*
> Inode uses extents */ #define EXT4_EXT_MAGIC
> 0xf30a #define EXT4_FEATURE_RO_COMPAT_GDT_CSUM0x0010

Reviewed-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

[Wenyou.Yang]

Hi Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: 2016年8月19日 19:36
> To: Wenyou Yang - A41535 
> Cc: Wenyou Yang - A41535 ; u-
> b...@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the 
> spi
> driver
> 
> On 8 August 2016 at 06:14,   wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: 2016年8月6日 21:00
> >> To: Wenyou Yang 
> >> Cc: U-Boot Mailing List 
> >> Subject: Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support
> >> for the spi driver
> >>
> >> On 31 July 2016 at 17:05, Jagan Teki  wrote:
> >> > On 29 July 2016 at 06:08, Wenyou Yang  wrote:
> >> >> Add driver model support while retaining the existing legacy code.
> >> >> This allows the driver to support boards that have converted to
> >> >> driver model as well as those that have not.
> >>
> >> Need some info - how many boards still pending to use this driver to use 
> >> it in
> dm?
> >
> > For now, only sama5d2_xplained has used this drive in dm, other boards
> > with AT91 SoC has not used dm driver, such as at91sam9g20ek, at91sam9x5ek,
> at91sam9m10g45ek, sama5d3xek. sama5d4ek, 
> 
> Please convert these boards to dm as well, because driver still have non-dm 
> code
> never know when it gets removed.

Okay, we will convert them.

Thank you for your reminder.

> 
> thanks!
> --
> Jagan.


Best Regards,
Wenyou Yang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] warp7: Add PMIC support

[Fabio Estevam]

On Fri, Aug 19, 2016 at 10:21 AM, Vanessa Maegima
 wrote:
> Add PMIC support. Tested by command "pmic PFUZE3000 dump".
>
> Signed-off-by: Vanessa Maegima 

Reviewed-by: Fabio Estevam 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] warp7: Add PMIC support

[Vanessa Maegima]

Add PMIC support. Tested by command "pmic PFUZE3000 dump".

Signed-off-by: Vanessa Maegima 
---
 board/warp7/warp7.c | 57 +
 include/configs/warp7.h | 12 +++
 2 files changed, 69 insertions(+)

diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index 27e31f3..cffee4a 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -11,12 +11,17 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include "../freescale/common/pfuze.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -25,6 +30,26 @@ DECLARE_GLOBAL_DATA_PTR;
 #define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW |\
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
 
+#define I2C_PAD_CTRL   (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
+   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
+
+#ifdef CONFIG_SYS_I2C_MXC
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+/* I2C1 for PMIC */
+static struct i2c_pads_info i2c_pad_info1 = {
+   .scl = {
+   .i2c_mode = MX7D_PAD_I2C1_SCL__I2C1_SCL | PC,
+   .gpio_mode = MX7D_PAD_I2C1_SCL__GPIO4_IO8 | PC,
+   .gp = IMX_GPIO_NR(4, 8),
+   },
+   .sda = {
+   .i2c_mode = MX7D_PAD_I2C1_SDA__I2C1_SDA | PC,
+   .gpio_mode = MX7D_PAD_I2C1_SDA__GPIO4_IO9 | PC,
+   .gp = IMX_GPIO_NR(4, 9),
+   },
+};
+#endif
+
 int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -85,11 +110,43 @@ int board_early_init_f(void)
return 0;
 }
 
+#ifdef CONFIG_POWER
+#define I2C_PMIC   0
+static struct pmic *pfuze;
+int power_init_board(void)
+{
+   int ret;
+   unsigned int reg, rev_id;
+
+   ret = power_pfuze3000_init(I2C_PMIC);
+   if (ret)
+   return ret;
+
+   pfuze = pmic_get("PFUZE3000");
+   ret = pmic_probe(pfuze);
+   if (ret)
+   return ret;
+
+   pmic_reg_read(pfuze, PFUZE3000_DEVICEID, );
+   pmic_reg_read(pfuze, PFUZE3000_REVID, _id);
+   printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", reg, rev_id);
+
+   /* disable Low Power Mode during standby mode */
+   pmic_reg_write(pfuze, PFUZE3000_LDOGCTL, 0x1);
+
+   return 0;
+}
+#endif
+
 int board_init(void)
 {
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
 
+   #ifdef CONFIG_SYS_I2C_MXC
+   setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
+   #endif
+
return 0;
 }
 
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index e59b16c..57a8123 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -103,6 +103,18 @@
 #define CONFIG_SYS_INIT_SP_ADDR \
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
 
+/* I2C configs */
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_MXC_I2C1
+#define CONFIG_SYS_I2C_SPEED   10
+
+/* PMIC */
+#define CONFIG_POWER
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_PFUZE3000
+#define CONFIG_POWER_PFUZE3000_I2C_ADDR0x08
+
 /* FLASH and environment organization */
 #define CONFIG_SYS_NO_FLASH
 #define CONFIG_ENV_SIZESZ_8K
-- 
2.7.4

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

[U-Boot] [PATCH] sunxi: display: Use PWM to drive backlight where applicable

[Hans de Goede]

When the backlight's pwm input is connected to a pwm output of the SoC,
actually use pwm to drive the backlight.

The mean reason for doing this is to fix the backlight turning off
for aprox. 1 second while the kernel is booting. This is caused by
the kernel actually using pwm to drive the backlight, so that it
can dim the backlight. First the pwm driver loads and switches the
pinmux for the pin driving the backlight's pwm input to the pwm
controller. Then about 1s later the actual backlight driver loads
and tells the pwm driver to actually update the pwm settings, which
have a power-on-reset value of "off".

An additional advantage is that this allows us to initatiate the
backlight at 80%, which is the kernel default, avoiding a brightness
change while the kernel loads.

Signed-off-by: Hans de Goede 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |  1 +
 arch/arm/include/asm/arch-sunxi/gpio.h  |  1 +
 arch/arm/include/asm/arch-sunxi/pwm.h   | 27 +++
 drivers/video/sunxi_display.c   | 12 +++-
 4 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/pwm.h

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index cd009d7..a5f396e 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -76,6 +76,7 @@
 #define SUNXI_INTC_BASE0x01c20400
 #define SUNXI_PIO_BASE 0x01c20800
 #define SUNXI_TIMER_BASE   0x01c20c00
+#define SUNXI_PWM_BASE 0x01c20e00
 #define SUNXI_SPDIF_BASE   0x01c21000
 #define SUNXI_AC97_BASE0x01c21400
 #define SUNXI_IR0_BASE 0x01c21800
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index bff7d14..ef426ae 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -150,6 +150,7 @@ enum sunxi_gpio_number {
 #define SUN6I_GPA_SDC3 4
 #define SUN8I_H3_GPA_UART0 2
 
+#define SUN4I_GPB_PWM  2
 #define SUN4I_GPB_TWI0 2
 #define SUN4I_GPB_TWI1 2
 #define SUN5I_GPB_TWI1 2
diff --git a/arch/arm/include/asm/arch-sunxi/pwm.h 
b/arch/arm/include/asm/arch-sunxi/pwm.h
new file mode 100644
index 000..ec997a6
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/pwm.h
@@ -0,0 +1,27 @@
+/*
+ * (C) Copyright 2016 Hans de Goede 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_PWM_H
+#define _SUNXI_PWM_H
+
+#define SUNXI_PWM_CTRL_REG (SUNXI_PWM_BASE + 0)
+#define SUNXI_PWM_CH0_PERIOD   (SUNXI_PWM_BASE + 4)
+
+#define SUNXI_PWM_CTRL_PRESCALE0(x)((x) & 0xf)
+#define SUNXI_PWM_CTRL_ENABLE0 (0x5 << 4)
+#define SUNXI_PWM_CTRL_POLARITY0(x)((x) << 5)
+
+#define SUNXI_PWM_PERIOD_80PCT 0x04af03c0
+
+#if defined CONFIG_MACH_SUN4I || defined CONFIG_MACH_SUN5I
+#define SUNXI_PWM_PIN0 SUNXI_GPB(2)
+#endif
+
+#if defined CONFIG_MACH_SUN8I_A23 || defined CONFIG_MACH_SUN8I_A33
+#define SUNXI_PWM_PIN0 SUNXI_GPH(0)
+#endif
+
+#endif
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 56f6c8e..a152cf2 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,6 @@
 #define PWM_ON 1
 #define PWM_OFF 0
 #endif
-
 DECLARE_GLOBAL_DATA_PTR;
 
 enum sunxi_monitor {
@@ -743,6 +743,16 @@ static void sunxi_lcdc_backlight_enable(void)
gpio_direction_output(pin, 1);
 
pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_BL_PWM);
+#ifdef SUNXI_PWM_PIN0
+   if (pin == SUNXI_PWM_PIN0) {
+   writel(SUNXI_PWM_CTRL_POLARITY0(PWM_ON) |
+  SUNXI_PWM_CTRL_ENABLE0 |
+  SUNXI_PWM_CTRL_PRESCALE0(0xf), SUNXI_PWM_CTRL_REG);
+   writel(SUNXI_PWM_PERIOD_80PCT, SUNXI_PWM_CH0_PERIOD);
+   sunxi_gpio_set_cfgpin(pin, SUN4I_GPB_PWM);
+   return;
+   }
+#endif
if (pin >= 0)
gpio_direction_output(pin, PWM_ON);
 }
-- 
2.7.4

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

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

[Jagan Teki]

On 19 August 2016 at 18:26, Andreas Bießmann  wrote:
> On 2016-08-19 14:48, Jagan Teki wrote:
>>



>
> It would be hard to verify it, if you would have taken that task ... So I'll
> do it, with a lower priority sometime next months.

OK.

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

[Andreas Bießmann]

On 2016-08-19 14:48, Jagan Teki wrote:
On 19 August 2016 at 18:16, Andreas Bießmann  
wrote:




non-dm code has to live for some time since this is a shared driver 
for
avr32 and arm architecture of atmel SoC. Unfortunately avr32 still 
lacks

dm
support in u-boot. I have some prepared patches but AFAIR there was 
a
problem with early malloc ... after that I had no time to get it 
done.


Beside that I also insist on converting the remaining at91 boards to 
dm.
Since there are some boards I would suggest a time frame until end 
of

this
year.



OK, look like avr32 should be a blocker here since at91 boards can do
at-least. What is the plan on avr32, shall I look in to it?



I hope I can look for it in next couple of month. So v2016.11 should 
be

doable, maybe v2017.01. Do you have some avr32 hardware to verify it?


Don't have.


It would be hard to verify it, if you would have taken that task ... So 
I'll do it, with a lower priority sometime next months.


Andreas



thanks!

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

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

[Jagan Teki]

On 19 August 2016 at 18:16, Andreas Bießmann  wrote:
> Hi Jagan,
>
>
> On 2016-08-19 14:10, Jagan Teki wrote:
>>
>> Hi Andreas,
>>
>> On 19 August 2016 at 17:20, Andreas Bießmann  wrote:
>>>
>>> Hi Jagan,
>>>
>>> On 2016-08-19 13:35, Jagan Teki wrote:


 On 8 August 2016 at 06:14,   wrote:
>
>
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: 2016年8月6日 21:00
>> To: Wenyou Yang 
>> Cc: U-Boot Mailing List 
>> Subject: Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support
>> for
>> the spi
>> driver
>>
>> On 31 July 2016 at 17:05, Jagan Teki  wrote:
>> > On 29 July 2016 at 06:08, Wenyou Yang  wrote:
>> >> Add driver model support while retaining the existing legacy code.
>> >> This allows the driver to support boards that have converted to
>> >> driver model as well as those that have not.
>>
>> Need some info - how many boards still pending to use this driver to
>> use
>> it in dm?
>
>
>
> For now, only sama5d2_xplained has used this drive in dm, other boards
> with AT91 SoC has not used dm driver,
> such as at91sam9g20ek, at91sam9x5ek, at91sam9m10g45ek, sama5d3xek.
> sama5d4ek, 



 Please convert these boards to dm as well, because driver still have
 non-dm code never know when it gets removed.
>>>
>>>
>>>
>>> non-dm code has to live for some time since this is a shared driver for
>>> avr32 and arm architecture of atmel SoC. Unfortunately avr32 still lacks
>>> dm
>>> support in u-boot. I have some prepared patches but AFAIR there was a
>>> problem with early malloc ... after that I had no time to get it done.
>>>
>>> Beside that I also insist on converting the remaining at91 boards to dm.
>>> Since there are some boards I would suggest a time frame until end of
>>> this
>>> year.
>>
>>
>> OK, look like avr32 should be a blocker here since at91 boards can do
>> at-least. What is the plan on avr32, shall I look in to it?
>
>
> I hope I can look for it in next couple of month. So v2016.11 should be
> doable, maybe v2017.01. Do you have some avr32 hardware to verify it?

Don't have.

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

[Andreas Bießmann]

Hi Jagan,

On 2016-08-19 14:10, Jagan Teki wrote:

Hi Andreas,

On 19 August 2016 at 17:20, Andreas Bießmann  
wrote:

Hi Jagan,

On 2016-08-19 13:35, Jagan Teki wrote:


On 8 August 2016 at 06:14,   wrote:


Hi Jagan,


-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: 2016年8月6日 21:00
To: Wenyou Yang 
Cc: U-Boot Mailing List 
Subject: Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support 
for

the spi
driver

On 31 July 2016 at 17:05, Jagan Teki  
wrote:

> On 29 July 2016 at 06:08, Wenyou Yang  wrote:
>> Add driver model support while retaining the existing legacy code.
>> This allows the driver to support boards that have converted to
>> driver model as well as those that have not.

Need some info - how many boards still pending to use this driver 
to use

it in dm?



For now, only sama5d2_xplained has used this drive in dm, other 
boards

with AT91 SoC has not used dm driver,
such as at91sam9g20ek, at91sam9x5ek, at91sam9m10g45ek, sama5d3xek.
sama5d4ek, 



Please convert these boards to dm as well, because driver still have
non-dm code never know when it gets removed.



non-dm code has to live for some time since this is a shared driver 
for
avr32 and arm architecture of atmel SoC. Unfortunately avr32 still 
lacks dm

support in u-boot. I have some prepared patches but AFAIR there was a
problem with early malloc ... after that I had no time to get it done.

Beside that I also insist on converting the remaining at91 boards to 
dm.
Since there are some boards I would suggest a time frame until end of 
this

year.


OK, look like avr32 should be a blocker here since at91 boards can do
at-least. What is the plan on avr32, shall I look in to it?


I hope I can look for it in next couple of month. So v2016.11 should be 
doable, maybe v2017.01. Do you have some avr32 hardware to verify it?


Andreas



thanks!

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

Re: [U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option

[Simon Glass]

+Masahiro

Hi Andrew,

On 18 August 2016 at 22:12, Lokesh Vutla  wrote:
>
>
> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>> Add a new Kconfig CONFIG_SPL_TEXT_BASE. Add its use to
>> am335x_evm_defconfig, then only conditionally define it in
>> ti_am335x_common.h when it is not already defined, this allows for
>> systems that have not fully converted to the Kconfig based config
>> system to still include this header without redefining this symbol
>> on platforms that have.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>  Kconfig| 8 
>>  configs/am335x_evm_defconfig   | 1 +
>>  include/configs/ti_am335x_common.h | 2 ++
>>  3 files changed, 11 insertions(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index cb5af5b..f67e7c8 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -319,6 +319,14 @@ config SYS_TEXT_BASE
>>   help
>> TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
>>
>> +config SPL_TEXT_BASE
>> + hex "Text Base"
>> + depends on SPL
>> + help
>> +   When SPL is enabled the image is linked with this as the
>> +   starting address in memeory for which the SPL will be loaded.
>> +   TODO: Move CONFIG_SPL_TEXT_BASE for all the architecture
>
> Nice to see this in a common place. There are some boards which has
> already defined this as Kconfig option. You need to remove the current
> definition or else build might break.

Yes it is great to see this!

You can use the moveconfig.py tool to help with finishing the migration.

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

[U-Boot] Remove atmel_dataflash_spi.c

[Jagan Teki]

Hi Stelian/Alison,

Need some inputs here, since atmel dataflash driver is already
up-streamed on flash side at drivers/mtd/spi/sf_dataflash.c then what
is the point of using drivers/spi/atmel_dataflash_spi.c at spi side.

Are they identically same? can't we use sf_dataflash for common
dataflash operations like what we does in atmel_dataflash_spi?

Thanks!

Jagan.
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sunxi: Tune H3 DRAM PLL to improve lock time

[Jens Kuske]

The H3 PLL5 used for DRAM barely manages to lock to the required
frequency before DRAM controller starts, sometimes leading to wrong
delay-line calibration results.
This patch changes the PLL tuning parameters to the same values as
boot0 used, which speeds up the locking and fixes the problem.

Signed-off-by: Jens Kuske 

---

Hi all,

this might fix some of the DRAM reliability problems seen on H3 boards,
but I could only test it on one board myself, where it only improves
results for dram clocks above 648 MHz. But my board didn't suffer
from reliability problems at 672 MHz, so maybe it helps on boards
where 672 isn't stable.
Even if there are no visible effects on reliability, this is what
boot0 does, and it definitely fixes something, see table below:

DRAM clock  delay steps
without patch   with patch

552 MHz:36  36
576 MHz:35  35
600 MHz:34  34
624 MHz:32  32
648 MHz:31  31
672 MHz:31  30
696 MHz:31  29
720 MHz:31  28
744 MHz:31  27
768 MHz:31  26

Looks like the clock only reached ~648 MHz when calibration is run,
leading to increasing error for higher clocks.
If someone wants to reproduce this test, the delays are from the
DXnLCDL1 registers (0x01c63308 + 0..3 * 0x80) and are responsible
for phase-shifting DQS signals by 90deg relative to DQ.

Best Regards,
Jens

---
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 9 -
 arch/arm/mach-sunxi/clock_sun6i.c | 6 ++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index d4dff1e..be9fcfd 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -116,7 +116,9 @@ struct sunxi_ccm_reg {
u32 mipi_bias_cfg;  /* 0x240 MIPI Bias config */
u32 pll9_bias_cfg;  /* 0x244 PLL9 Bias config */
u32 pll10_bias_cfg; /* 0x248 PLL10 Bias config */
-   u32 reserved21[13];
+   u32 reserved21[5];
+   u32 pll5_tuning_cfg;/* 0x260 PLL5 Tuning config */
+   u32 reserved21_5[7];
u32 pll1_pattern_cfg;   /* 0x280 PLL1 Pattern config */
u32 pll2_pattern_cfg;   /* 0x284 PLL2 Pattern config */
u32 pll3_pattern_cfg;   /* 0x288 PLL3 Pattern config */
@@ -223,6 +225,11 @@ struct sunxi_ccm_reg {
 #define CCM_PLL11_CTRL_UPD (0x1 << 30)
 #define CCM_PLL11_CTRL_EN  (0x1 << 31)
 
+#define CCM_PLL5_TUN_LOCK_TIME(x)  (((x) & 0x7) << 24)
+#define CCM_PLL5_TUN_LOCK_TIME_MASKCCM_PLL5_TUN_LOCK_TIME(0x7)
+#define CCM_PLL5_TUN_INIT_FREQ(x)  (((x) & 0x7f) << 16)
+#define CCM_PLL5_TUN_INIT_FREQ_MASKCCM_PLL5_TUN_INIT_FREQ(0x7f)
+
 #if defined(CONFIG_MACH_SUN50I)
 /* AHB1=100MHz failsafe setup from the FEL mode, usable with PMIC defaults */
 #define AHB1_ABP1_DIV_DEFAULT  0x3190 /* AHB1=PLL6/6,APB1=AHB1/2 */
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 15272c9..ed8cd9b 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -148,6 +148,12 @@ void clock_set_pll5(unsigned int clk, bool 
sigma_delta_enable)
const int max_n = 32;
int k = 1, m = 2;
 
+#ifdef CONFIG_MACH_SUN8I_H3
+   clrsetbits_le32(>pll5_tuning_cfg, CCM_PLL5_TUN_LOCK_TIME_MASK |
+   CCM_PLL5_TUN_INIT_FREQ_MASK,
+   CCM_PLL5_TUN_LOCK_TIME(2) | CCM_PLL5_TUN_INIT_FREQ(16));
+#endif
+
if (sigma_delta_enable)
writel(CCM_PLL5_PATTERN, >pll5_pattern_cfg);
 
-- 
2.9.3

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

Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the spi driver

[Jagan Teki]

On 8 August 2016 at 06:14,   wrote:
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: 2016年8月6日 21:00
>> To: Wenyou Yang 
>> Cc: U-Boot Mailing List 
>> Subject: Re: [U-Boot] [PATCH v7] dm: at91: Add driver model support for the 
>> spi
>> driver
>>
>> On 31 July 2016 at 17:05, Jagan Teki  wrote:
>> > On 29 July 2016 at 06:08, Wenyou Yang  wrote:
>> >> Add driver model support while retaining the existing legacy code.
>> >> This allows the driver to support boards that have converted to
>> >> driver model as well as those that have not.
>>
>> Need some info - how many boards still pending to use this driver to use it 
>> in dm?
>
> For now, only sama5d2_xplained has used this drive in dm, other boards with 
> AT91 SoC has not used dm driver,
> such as at91sam9g20ek, at91sam9x5ek, at91sam9m10g45ek, sama5d3xek. sama5d4ek, 
> 

Please convert these boards to dm as well, because driver still have
non-dm code never know when it gets removed.

thanks!
-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/7] usb: xhci-rockchip: add rockchip dwc3 controller driver

[Marek Vasut]

On 08/19/2016 09:19 AM, Kever Yang wrote:
> From: MengDongyang 
> 
> This patch add support for rockchip dwc3 controller, which corresponding
> to the two type-C port on rk3399 evb.
> Only support usb2.0 currently for we have not enable the usb3.0 phy
> driver and PD(fusb302) driver.
> 
> Signed-off-by: MengDongyang 
> Signed-off-by: Kever Yang 

Hi,

[...]

> +static void rockchip_dwc3_phy_setup(struct dwc3 *dwc3_reg,
> + struct rockchip_xhci *rockchip)
> +{
> + u32 reg;
> + const void *blob = gd->fdt_blob;
> + struct udevice *dev = rockchip->dev;
> + const struct fdt_property *prop;
> + const u32 *data;
> +
> + reg = readl(_reg->g_usb3pipectl[0]);
> +
> + /* To do set dwc3 usb3 pipe control */
> +
> + writel(reg, _reg->g_usb3pipectl[0]);

This read - do nothing - write looks suspicious. Is this needed ?

Also, drop the newline after the comment, it's useless, both above and
below here.

> + /* Set dwc3 usb2 phy config */
> +
> + reg = readl(_reg->g_usb2phycfg[0]);
> +
> + prop = fdt_get_property(blob, dev->of_offset,
> + "snps,dis-enblslpm-quirk", NULL);
> + if (prop)
> + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
> +
> + prop = fdt_get_property(blob, dev->of_offset,
> + "snps,phyif-utmi-bits", NULL);
> + data = (u32 *)prop->data;
> + if (fdt32_to_cpu(*data) == 16) {
> + reg |= DWC3_GUSB2PHYCFG_PHYIF;
> + reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
> + reg |= 5 << DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET;
> + } else if (fdt32_to_cpu(*data) == 8) {
> + reg &= ~DWC3_GUSB2PHYCFG_PHYIF;
> + reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
> + reg |= 9 << DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET;
> + }
> +
> + prop = fdt_get_property(blob, dev->of_offset,
> + "snps,dis-u2-freeclk-exists-quirk", NULL);
> + if (prop)
> + reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
> +
> + prop = fdt_get_property(blob, dev->of_offset,
> + "snps,dis-u2-susphy-quirk", NULL);
> + if (prop)
> + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
> +
> + writel(reg, _reg->g_usb2phycfg[0]);
> +}

[...]

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

[U-Boot] [PATCH] drivers: usb: xhci-fsl: Implement Erratum A-010151 for FSL USB3 controller

[Sriram Dash]

Currently the controller by default enables the Receive Detect feature in P3
mode in USB 3.0 PHY. However, USB 3.0 PHY does not reliably support receive
detection in P3 mode.
Enabling the USB3 controller to configure USB in P2 mode whenever the Receive
Detect feature is required.

Signed-off-by: Sriram Dash 
Signed-off-by: Rajesh Bhagat 
---
 drivers/usb/host/xhci-dwc3.c | 5 +
 drivers/usb/host/xhci-fsl.c  | 7 +++
 include/linux/usb/dwc3.h | 2 ++
 3 files changed, 14 insertions(+)

diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 33961cd..adbd9b5 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -97,3 +97,8 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
setbits_le32(_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
GFLADJ_30MHZ(val));
 }
+
+void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val)
+{
+   setbits_le32(_reg->g_usb3pipectl[0], val);
+}
diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
index bdcd4f1..d9dbf1f 100644
--- a/drivers/usb/host/xhci-fsl.c
+++ b/drivers/usb/host/xhci-fsl.c
@@ -74,6 +74,13 @@ static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci)
/* Set GFLADJ_30MHZ as 20h as per XHCI spec default value */
dwc3_set_fladj(fsl_xhci->dwc3_reg, GFLADJ_30MHZ_DEFAULT);
 
+   /*
+* A-010151: USB controller to configure USB in P2 mode
+* whenever the Receive Detect feature is required
+*/
+   dwc3_set_rxdetect_power_mode(fsl_xhci->dwc3_reg,
+DWC3_GUSB3PIPECTL_DISRXDETP3);
+
return ret;
 }
 
diff --git a/include/linux/usb/dwc3.h b/include/linux/usb/dwc3.h
index 6d1e365..f68cdd2 100644
--- a/include/linux/usb/dwc3.h
+++ b/include/linux/usb/dwc3.h
@@ -184,6 +184,7 @@ struct dwc3 {   /* 
offset: 0xC100 */
 
 /* Global USB3 PIPE Control Register */
 #define DWC3_GUSB3PIPECTL_PHYSOFTRST   (1 << 31)
+#define DWC3_GUSB3PIPECTL_DISRXDETP3   (1 << 28)
 #define DWC3_GUSB3PIPECTL_SUSPHY   (1 << 17)
 
 /* Global TX Fifo Size Register */
@@ -205,5 +206,6 @@ void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode);
 void dwc3_core_soft_reset(struct dwc3 *dwc3_reg);
 int dwc3_core_init(struct dwc3 *dwc3_reg);
 void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val);
+void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val);
 #endif
 #endif /* __DWC3_H_ */
-- 
2.1.0

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

[U-Boot] [PATCH] pinctrl: fix typos in comment blocks of pinconfig_post_bind()

[Masahiro Yamada]

'-' is never used in function names.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/pinctrl-uclass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index fd04b26..7397de2 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -113,7 +113,7 @@ static int pinctrl_select_state_full(struct udevice *dev, 
const char *statename)
 }
 
 /**
- * pinconfig_post-bind() - post binding for PINCONFIG uclass
+ * pinconfig_post_bind() - post binding for PINCONFIG uclass
  * Recursively bind its children as pinconfig devices.
  *
  * @dev: pinconfig device
@@ -257,7 +257,7 @@ int pinctrl_get_gpio_mux(struct udevice *dev, int banknum, 
int index)
 }
 
 /**
- * pinconfig_post-bind() - post binding for PINCTRL uclass
+ * pinconfig_post_bind() - post binding for PINCTRL uclass
  * Recursively bind child nodes as pinconfig devices in case of full pinctrl.
  *
  * @dev: pinctrl device
-- 
1.9.1

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

[U-Boot] [UBOOT PATCH 3/4] nxp: ls102xa: add EPU Finite State Machine

[macro . wave . z]

From: Hongbo Zhang 

The EPU Finite State Machie (FSM) is used in both the last stage of system
suspend and the earliest stage of system resume.

Signed-off-by: Hongbo Zhang 
---
 arch/arm/cpu/armv7/ls102xa/fsl_epu.c | 157 +++
 arch/arm/cpu/armv7/ls102xa/fsl_epu.h |   8 ++
 2 files changed, 165 insertions(+)

diff --git a/arch/arm/cpu/armv7/ls102xa/fsl_epu.c 
b/arch/arm/cpu/armv7/ls102xa/fsl_epu.c
index 6212640..b4de523 100644
--- a/arch/arm/cpu/armv7/ls102xa/fsl_epu.c
+++ b/arch/arm/cpu/armv7/ls102xa/fsl_epu.c
@@ -9,6 +9,163 @@
 
 #include "fsl_epu.h"
 
+struct fsm_reg_vals epu_default_val[] = {
+   /* EPGCR (Event Processor Global Control Register) */
+   {EPGCR, 0},
+   /* EPECR (Event Processor Event Control Registers) */
+   {EPECR0 + EPECR_STRIDE * 0, 0},
+   {EPECR0 + EPECR_STRIDE * 1, 0},
+   {EPECR0 + EPECR_STRIDE * 2, 0xF0004004},
+   {EPECR0 + EPECR_STRIDE * 3, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 4, 0x2084},
+   {EPECR0 + EPECR_STRIDE * 5, 0x0804},
+   {EPECR0 + EPECR_STRIDE * 6, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 7, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 8, 0x6084},
+   {EPECR0 + EPECR_STRIDE * 9, 0x0884},
+   {EPECR0 + EPECR_STRIDE * 10, 0x4284},
+   {EPECR0 + EPECR_STRIDE * 11, 0x9084},
+   {EPECR0 + EPECR_STRIDE * 12, 0x8084},
+   {EPECR0 + EPECR_STRIDE * 13, 0x0884},
+   {EPECR0 + EPECR_STRIDE * 14, 0x0284},
+   {EPECR0 + EPECR_STRIDE * 15, 0x0004},
+   /*
+* EPEVTCR (Event Processor EVT Pin Control Registers)
+* SCU8 triger EVT2, and SCU11 triger EVT9
+*/
+   {EPEVTCR0 + EPEVTCR_STRIDE * 0, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 1, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 2, 0x8001},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 3, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 4, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 5, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 6, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 7, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 8, 0},
+   {EPEVTCR0 + EPEVTCR_STRIDE * 9, 0xB001},
+   /* EPCMPR (Event Processor Counter Compare Registers) */
+   {EPCMPR0 + EPCMPR_STRIDE * 0, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 1, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 2, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 3, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 4, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 5, 0x0020},
+   {EPCMPR0 + EPCMPR_STRIDE * 6, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 7, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 8, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 9, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 10, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 11, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 12, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 13, 0},
+   {EPCMPR0 + EPCMPR_STRIDE * 14, 0x00FF},
+   {EPCMPR0 + EPCMPR_STRIDE * 15, 0x00FF},
+   /* EPCCR (Event Processor Counter Control Registers) */
+   {EPCCR0 + EPCCR_STRIDE * 0, 0},
+   {EPCCR0 + EPCCR_STRIDE * 1, 0},
+   {EPCCR0 + EPCCR_STRIDE * 2, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 3, 0},
+   {EPCCR0 + EPCCR_STRIDE * 4, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 5, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 6, 0},
+   {EPCCR0 + EPCCR_STRIDE * 7, 0},
+   {EPCCR0 + EPCCR_STRIDE * 8, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 9, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 10, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 11, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 12, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 13, 0},
+   {EPCCR0 + EPCCR_STRIDE * 14, 0x9284},
+   {EPCCR0 + EPCCR_STRIDE * 15, 0x9284},
+   /* EPSMCR (Event Processor SCU Mux Control Registers) */
+   {EPSMCR0 + EPSMCR_STRIDE * 0, 0},
+   {EPSMCR0 + EPSMCR_STRIDE * 1, 0},
+   {EPSMCR0 + EPSMCR_STRIDE * 2, 0x6C70},
+   {EPSMCR0 + EPSMCR_STRIDE * 3, 0x2F00},
+   {EPSMCR0 + EPSMCR_STRIDE * 4, 0x002F},
+   {EPSMCR0 + EPSMCR_STRIDE * 5, 0x2E00},
+   {EPSMCR0 + EPSMCR_STRIDE * 6, 0x7C00},
+   {EPSMCR0 + EPSMCR_STRIDE * 7, 0x3000},
+   {EPSMCR0 + EPSMCR_STRIDE * 8, 0x6430},
+   {EPSMCR0 + EPSMCR_STRIDE * 9, 0x3000},
+   {EPSMCR0 + EPSMCR_STRIDE * 10, 0x6530},
+   {EPSMCR0 + EPSMCR_STRIDE * 11, 0x3174},
+   {EPSMCR0 + EPSMCR_STRIDE * 12, 0x7F00},
+   {EPSMCR0 + EPSMCR_STRIDE * 13, 0x3100},
+   {EPSMCR0 + EPSMCR_STRIDE * 14, 0x0031},
+   {EPSMCR0 + EPSMCR_STRIDE * 15, 0x7600},
+   /* EPACR (Event Processor Action Control Registers) */
+   {EPACR0 + EPACR_STRIDE * 0, 0},
+   {EPACR0 + EPACR_STRIDE * 1, 0},
+   {EPACR0 + EPACR_STRIDE * 2, 0},
+   {EPACR0 + EPACR_STRIDE * 3, 0x0080},
+   {EPACR0 + EPACR_STRIDE * 4, 0},
+   {EPACR0 + EPACR_STRIDE * 

[U-Boot] [UBOOT PATCH 4/4] nxp: ls102xa: add LS1 PSCI system suspend

[macro . wave . z]

From: Hongbo Zhang 

The deep sleep function of LS1 platform, is mapped into PSCI system suspend
function, this patch adds implementation of it.

Signed-off-by: Hongbo Zhang 
---
 arch/arm/cpu/armv7/ls102xa/Makefile   |   2 +-
 arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c | 236 ++
 arch/arm/cpu/armv7/ls102xa/psci.S |  11 ++
 board/freescale/common/arm_sleep.c|  35 -
 include/configs/ls1021aqds.h  |   1 +
 include/configs/ls1021atwr.h  |   1 +
 6 files changed, 284 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c

diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile 
b/arch/arm/cpu/armv7/ls102xa/Makefile
index 0228300..f8300c7 100644
--- a/arch/arm/cpu/armv7/ls102xa/Makefile
+++ b/arch/arm/cpu/armv7/ls102xa/Makefile
@@ -16,5 +16,5 @@ obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o 
ls102xa_serdes.o
 obj-$(CONFIG_SPL) += spl.o
 
 ifdef CONFIG_ARMV7_PSCI
-obj-y  += psci.o
+obj-y  += psci.o ls102xa_psci.o
 endif
diff --git a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c 
b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
new file mode 100644
index 000..2ac2e6c
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Author: Hongbo Zhang 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ * This file implements LS102X platform PSCI SYSTEM-SUSPEND function
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "fsl_epu.h"
+
+#define __secure __attribute__((section("._secure.text")))
+
+#define CCSR_GICD_CTLR 0x1000
+#define CCSR_GICC_CTLR 0x2000
+#define DCSR_RCPM_CG1CR0   0x31c
+#define DCSR_RCPM_CSTTACR0 0xb00
+#define DCFG_CRSTSR_WDRFR  0x8
+#define DDR_RESV_LEN   128
+
+#ifdef CONFIG_LS1_DEEP_SLEEP
+/*
+ * DDR controller initialization training breaks the first 128 bytes of DDR,
+ * save them so that the bootloader can restore them while resuming.
+ */
+static void __secure ls1_save_ddr_head(void)
+{
+   const char *src = (const char *)CONFIG_SYS_SDRAM_BASE;
+   char *dest = (char *)(OCRAM_BASE_S_ADDR + OCRAM_S_SIZE - DDR_RESV_LEN);
+   struct ccsr_scfg __iomem *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+   int i;
+
+   out_le32(>sparecr[2], dest);
+
+   for (i = 0; i < DDR_RESV_LEN; i++)
+   *dest++ = *src++;
+}
+
+static void __secure ls1_fsm_setup(void)
+{
+   void *dcsr_epu_base = (void *)(CONFIG_SYS_DCSRBAR + EPU_BLOCK_OFFSET);
+   void *dcsr_rcpm_base = (void *)CONFIG_SYS_DCSR_RCPM_ADDR;
+
+   out_be32(dcsr_rcpm_base + DCSR_RCPM_CSTTACR0, 0x1001);
+   out_be32(dcsr_rcpm_base + DCSR_RCPM_CG1CR0, 0x0001);
+
+   fsl_epu_setup((void *)dcsr_epu_base);
+
+   /* Pull MCKE signal low before enabling deep sleep signal in FPGA */
+   out_be32(dcsr_epu_base + EPECR0, 0x5);
+   out_be32(dcsr_epu_base + EPSMCR15, 0x7630);
+}
+
+static void __secure ls1_deepsleep_irq_cfg(void)
+{
+   struct ccsr_scfg __iomem *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+   struct ccsr_rcpm __iomem *rcpm = (void *)CONFIG_SYS_FSL_RCPM_ADDR;
+   u32 ippdexpcr0, ippdexpcr1, pmcintecr = 0;
+
+   /* Mask interrupts from GIC */
+   out_be32(>nfiqoutr, 0x0);
+   out_be32(>nirqoutr, 0x0);
+   /* Mask deep sleep wake-up interrupts while entering deep sleep */
+   out_be32(>dsimskr, 0x0);
+
+   ippdexpcr0 = in_be32(>ippdexpcr0);
+   /*
+* Workaround: There is bug of register ippdexpcr1, when read it always
+* returns zero, so its value is saved to a scrachpad register to be
+* read, that is why we don't read it from register ippdexpcr1 itself.
+*/
+   ippdexpcr1 = in_le32(>sparecr[7]);
+
+   if (ippdexpcr0 & RCPM_IPPDEXPCR0_ETSEC)
+   pmcintecr |= SCFG_PMCINTECR_ETSECRXG0 |
+SCFG_PMCINTECR_ETSECRXG1 |
+SCFG_PMCINTECR_ETSECERRG0 |
+SCFG_PMCINTECR_ETSECERRG1;
+
+   if (ippdexpcr0 & RCPM_IPPDEXPCR0_GPIO)
+   pmcintecr |= SCFG_PMCINTECR_GPIO;
+
+   if (ippdexpcr1 & RCPM_IPPDEXPCR1_LPUART)
+   pmcintecr |= SCFG_PMCINTECR_LPUART;
+
+   if (ippdexpcr1 & RCPM_IPPDEXPCR1_FLEXTIMER)
+   pmcintecr |= SCFG_PMCINTECR_FTM;
+
+   /* Always set external IRQ pins as wakeup source */
+   pmcintecr |= SCFG_PMCINTECR_IRQ0 | SCFG_PMCINTECR_IRQ1;
+
+   out_be32(>pmcintlecr, 0);
+   /* Clear PMC interrupt status */
+   out_be32(>pmcintsr, 0x);
+   /* Enable wakeup interrupt during deep sleep */
+   out_be32(>pmcintecr, pmcintecr);
+}
+
+static void __secure ls1_delay(unsigned int loop)
+{
+   while (loop--) {
+   int i = 1000;
+   while (i--)

[U-Boot] [UBOOT PATCH 2/4] nxp: ls102xa: add registers definition for system sleep

[macro . wave . z]

From: Hongbo Zhang 

This patch adds definitions of all the regesters necessary for system sleep.

Signed-off-by: Hongbo Zhang 
---
 arch/arm/include/asm/arch-ls102xa/config.h|  2 +
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 52 ++-
 include/configs/ls1021aqds.h  |  7 +++
 3 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index d408fe4..b995a00 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -18,7 +18,9 @@
 #define CONFIG_SYS_DCSRBAR 0x2000
 
 #define CONFIG_SYS_DCSR_DCFG_ADDR  (CONFIG_SYS_DCSRBAR + 0x0022)
+#define CONFIG_SYS_DCSR_RCPM_ADDR  (CONFIG_SYS_DCSRBAR + 0x00222000)
 
+#define CONFIG_SYS_GIC_ADDR(CONFIG_SYS_IMMR + 0x0040)
 #define CONFIG_SYS_FSL_DDR_ADDR(CONFIG_SYS_IMMR + 
0x0008)
 #define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR + 0x0018)
 #define CONFIG_SYS_FSL_CSU_ADDR (CONFIG_SYS_IMMR + 0x0051)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 0a80772..c34fd63 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -161,6 +161,17 @@ struct ccsr_gur {
 #define SCFG_SNPCNFGCR_DBG_RD_WR   0x000c
 #define SCFG_SNPCNFGCR_EDMA_SNP0x0002
 #define SCFG_ENDIANCR_LE   0x8000
+#define SCFG_DPSLPCR_WDRR_EN   0x0001
+#define SCFG_PMCINTECR_LPUART  0x4000
+#define SCFG_PMCINTECR_FTM 0x2000
+#define SCFG_PMCINTECR_GPIO0x1000
+#define SCFG_PMCINTECR_IRQ00x0800
+#define SCFG_PMCINTECR_IRQ10x0400
+#define SCFG_PMCINTECR_ETSECRXG0   0x0080
+#define SCFG_PMCINTECR_ETSECRXG1   0x0040
+#define SCFG_PMCINTECR_ETSECERRG0  0x0008
+#define SCFG_PMCINTECR_ETSECERRG1  0x0004
+#define SCFG_CLUSTERPMCR_WFIL2EN   0x8000
 
 /* Supplemental Configuration Unit */
 struct ccsr_scfg {
@@ -226,7 +237,7 @@ struct ccsr_scfg {
u32 debug_streamid;
u32 resv10[5];
u32 snpcnfgcr;
-   u32 resv11[1];
+   u32 hrstcr;
u32 intpcr;
u32 resv12[20];
u32 scfgrevcr;
@@ -243,6 +254,9 @@ struct ccsr_scfg {
u32 sdhciovserlcr;
u32 resv14[61];
u32 sparecr[8];
+   u32 resv15[248];
+   u32 core0sftrstsr;
+   u32 clusterpmcr;
 };
 
 /* Clocking */
@@ -433,6 +447,42 @@ struct ccsr_ahci {
u32 cmds;   /* port 0/1 CMD status error */
 };
 
+#define RCPM_POWMGTCSR 0x130
+#define RCPM_POWMGTCSR_SERDES_PW   0x8000
+#define RCPM_POWMGTCSR_LPM20_REQ   0x0010
+#define RCPM_POWMGTCSR_LPM20_ST0x0200
+#define RCPM_POWMGTCSR_P_LPM20_ST  0x0100
+#define RCPM_IPPDEXPCR00x140
+#define RCPM_IPPDEXPCR0_ETSEC  0x8000
+#define RCPM_IPPDEXPCR0_GPIO   0x0040
+#define RCPM_IPPDEXPCR10x144
+#define RCPM_IPPDEXPCR1_LPUART 0x4000
+#define RCPM_IPPDEXPCR1_FLEXTIMER  0x2000
+#define RCPM_IPPDEXPCR1_OCRAM1 0x1000
+#define RCPM_NFIQOUTR  0x15c
+#define RCPM_NIRQOUTR  0x16c
+#define RCPM_DSIMSKR   0x18c
+#define RCPM_CLPCL10SETR   0x1c4
+#define RCPM_CLPCL10SETR_C00x0001
+
+struct ccsr_rcpm {
+   u8 rev1[0x4c];
+   u32 twaitsr;
+   u8 rev2[0xe0];
+   u32 powmgtcsr;
+   u8 rev3[0xc];
+   u32 ippdexpcr0;
+   u32 ippdexpcr1;
+   u8 rev4[0x14];
+   u32 nfiqoutr;
+   u8 rev5[0xc];
+   u32 nirqoutr;
+   u8 rev6[0x1c];
+   u32 dsimskr;
+   u8 rev7[0x34];
+   u32 clpcl10setr;
+};
+
 uint get_svr(void);
 
 #endif /* __ASM_ARCH_LS102XA_IMMAP_H_ */
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 47180f9..7c12fc9 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -289,6 +289,13 @@ unsigned long get_board_ddr_clk(void);
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE   0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START  0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE  0x08
+#define QIXIS_CTL_SYS  0x5
+#define QIXIS_CTL_SYS_EVTSW_MASK   0x0c
+#define QIXIS_CTL_SYS_EVTSW_IRQ0x04
+#define QIXIS_RST_FORCE_3  0x45
+#define QIXIS_RST_FORCE_3_PCIESLOT10x80
+#define QIXIS_PWR_CTL2 0x21
+#define QIXIS_PWR_CTL2_PCTL0x2
 
 #define CONFIG_SYS_FPGA_CSPR_EXT   (0x0)
 #define CONFIG_SYS_FPGA_CSPR   (CSPR_PHYS_ADDR(QIXIS_BASE_PHYS) | \
-- 
2.1.4

___
U-Boot 

[U-Boot] [UBOOT PATCH 0/4] Add LS1 PSCI system suspend

[macro . wave . z]

From: Hongbo Zhang 

This patch set is based against latest community uboot tree in which my
PSCIv1.0 support was merged.
Currently doesn't apply our internal SDK uboot, when these get merged in
community we can pull them back into SDK.

We need community kernel to test this PSCI system suspend too, our internal
SDK kernel is too old for PSCI.
And more codes are needed to be added into kernel to do this test, such as
a Flex timer as wake up device, and one peice of code to write IPPDEXPCR
registers before SMC call.

All patches have been tested on both LA1021ATWR and LS1021AQDS.

Hongbo Zhang (4):
  armv7: psci: make v7_flush_dcache_all public for all psci code
  nxp: ls102xa: add registers definition for system sleep
  nxp: ls102xa: add EPU Finite State Machine
  nxp: ls102xa: add LS1 PSCI system suspend

 arch/arm/cpu/armv7/ls102xa/Makefile   |   2 +-
 arch/arm/cpu/armv7/ls102xa/fsl_epu.c  | 157 ++
 arch/arm/cpu/armv7/ls102xa/fsl_epu.h  |   8 +
 arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c | 236 ++
 arch/arm/cpu/armv7/ls102xa/psci.S |  11 +
 arch/arm/cpu/armv7/psci.S |   6 +-
 arch/arm/include/asm/arch-ls102xa/config.h|   2 +
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h |  52 -
 arch/arm/include/asm/psci.h   |   2 +
 board/freescale/common/arm_sleep.c|  35 +++-
 include/configs/ls1021aqds.h  |   8 +
 include/configs/ls1021atwr.h  |   1 +
 12 files changed, 514 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c

-- 
2.1.4

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

[U-Boot] [UBOOT PATCH 1/4] armv7: psci: make v7_flush_dcache_all public for all psci code

[macro . wave . z]

From: Hongbo Zhang 

The v7_flush_dcache_all function will be called by ls102xa platform system
suspend, it is necessary to make it a public call instead of a local one, but
changing the LENTRY to ENTRY isn't enough, because there is another one using
the same name, so this one gets a psci_ prefix.

Signed-off-by: Hongbo Zhang 
---
 arch/arm/cpu/armv7/psci.S   | 6 +++---
 arch/arm/include/asm/psci.h | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index f80f6e2..6a36208 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -187,7 +187,7 @@ ENDPROC(psci_get_cpu_id)
 .weak psci_get_cpu_id
 
 /* Imported from Linux kernel */
-LENTRY(v7_flush_dcache_all)
+ENTRY(psci_v7_flush_dcache_all)
stmfd   sp!, {r4-r5, r7, r9-r11, lr}
dmb @ ensure ordering with previous 
memory accesses
mrc p15, 1, r0, c0, c0, 1   @ read clidr
@@ -234,7 +234,7 @@ finished:
isb
ldmfd   sp!, {r4-r5, r7, r9-r11, lr}
bx  lr
-ENDPROC(v7_flush_dcache_all)
+ENDPROC(psci_v7_flush_dcache_all)
 
 ENTRY(psci_disable_smp)
mrc p15, 0, r0, c1, c0, 1   @ ACTLR
@@ -264,7 +264,7 @@ ENTRY(psci_cpu_off_common)
isb
dsb
 
-   bl  v7_flush_dcache_all
+   bl  psci_v7_flush_dcache_all
 
clrex   @ Why???
 
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index 8aefaa7..9b068f0 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -86,6 +86,8 @@ void psci_cpu_off_common(void);
 int psci_update_dt(void *fdt);
 void psci_board_init(void);
 int fdt_psci(void *fdt);
+
+void psci_v7_flush_dcache_all(void);
 #endif /* ! __ASSEMBLY__ */
 
 #endif /* __ARM_PSCI_H__ */
-- 
2.1.4

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

Re: [U-Boot] [PATCH 1/4] pinctrl: generic: scan for "pins" and "groups" properties in sub-nodes

[Masahiro Yamada]

2016-08-16 18:49 GMT+09:00 Beniamino Galvani :
> In cases where the pins and groups definitions are in a sub-node, as:
>
> uart_a {
> mux {
> groups = "uart_tx_a", "uart_rx_a";
> function = "uart_a";
> };
> };
>
> pinctrl_generic_set_state_subnode() returns an error for the top-level
> node and pinctrl_generic_set_state() fails. Instead, return success so
> that the child nodes are tried.
>
> Signed-off-by: Beniamino Galvani 
> ---


Looks good to me.  Thanks!

Reviewed-by: Masahiro Yamada 


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

Re: [U-Boot] [PATCH 0/5] armv8: Add generic PSCI client support

[Michal Simek]

On 16.8.2016 21:08, Alexander Graf wrote:
> On aarch64 systems, Linux only has managed to push almost everyone to using
> PSCI as standardized interface for CPU start/stop operations. Fortunately
> PSCI also gives us a nicely abstracted interface to reset and power off
> the system.
> 
> This patch set adds support for generic PSCI reset/shutdown support and ties
> it up to EFI Run Time Services, so that an OS like Linux will magically have
> reset and shutdown work.
> 
> Alexander Graf (5):
>   efi_loader: Allow boards to implement get_time and reset_system
>   arm: Disable HVC PSCI calls by default
>   arm: Add PSCI shutdown function
>   arm: Provide common PSCI based reset handler
>   efi_loader: Add generic PSCI RTS
> 
>  arch/arm/cpu/armv8/Kconfig|  18 
>  arch/arm/cpu/armv8/fwcall.c   |  59 ++--
>  arch/arm/include/asm/system.h |  12 +
>  arch/arm/mach-meson/board.c   |   5 ---
>  board/xilinx/zynqmp/zynqmp.c  |   5 ---
>  cmd/bootefi.c |   4 ++
>  include/efi_loader.h  |  18 
>  lib/efi_loader/efi_runtime.c  | 101 
> +-
>  8 files changed, 187 insertions(+), 35 deletions(-)
> 

btw: I think that efi should be out of this series as separate patch.

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/5] Remove calls from net drivers to legacy miiphy_register() entry-point

[Karl Beldan]

On Mon, Aug 08, 2016 at 11:28:36AM -0500, Joe Hershberger wrote:
> 
> This is an effort to migrate closer to the phylib approach so that a
> new DM approach can be developed from a single starting point. The more
> of this legacy code that can be removed, the easier it will be to move
> forward.
> 

Hi Joe,

It was nice to see spatch put to work. However davinci_emac crashes
U-Boot now. It is an invasive patch so it might take time to check
everything is in order, so unless you already have a follow-up series I
can send in a trivial patch just now to fix that for davinci_emac.
 
Karl


> Changes in v2:
> - Added a blank line
> - Run against the current master which adds one more driver to convert 
> (drivers/net/macb.c)
> - Use an updated spatch that does not put closing paren on the next line
> 
> Joe Hershberger (5):
>   scripts: Add a cocci patch for miiphy_register
>   net: mii: Use spatch to update miiphy_register
>   net: mii: Changes not made by spatch
>   net: mii: Fix changes made by spatch
>   net: mii: Clean up legacy glue that is not used
> 
>  arch/m68k/include/asm/fec.h|   9 +-
>  arch/mips/mach-au1x00/au1x00_eth.c |  25 +++--
>  arch/powerpc/cpu/mpc8260/ether_fcc.c   |  13 ++-
>  arch/powerpc/cpu/mpc85xx/ether_fcc.c   |  13 ++-
>  arch/powerpc/cpu/mpc8xx/fec.c  |  40 +---
>  arch/powerpc/cpu/ppc4xx/miiphy.c   |  11 +--
>  board/gdsys/405ep/io.c |  13 ++-
>  board/gdsys/405ep/iocon.c  |  27 +-
>  board/gdsys/405ex/io64.c   |  25 -
>  board/gdsys/mpc8308/hrcon.c|  27 +-
>  board/gdsys/mpc8308/strider.c  |  27 +-
>  common/miiphyutil.c|  73 ---
>  drivers/net/4xx_enet.c |  20 ++--
>  drivers/net/armada100_fec.c|  33 ---
>  drivers/net/at91_emac.c|  28 --
>  drivers/net/bcm-sf2-eth-gmac.c |  18 ++--
>  drivers/net/bcm-sf2-eth.c  |  13 ++-
>  drivers/net/bcm-sf2-eth.h  |   8 +-
>  drivers/net/bfin_mac.c |  43 ++---
>  drivers/net/davinci_emac.c |  34 +--
>  drivers/net/eepro100.c |  34 ---
>  drivers/net/enc28j60.c |  26 --
>  drivers/net/ep93xx_eth.c   |  40 +---
>  drivers/net/fsl_mcdmafec.c |  13 ++-
>  drivers/net/ftmac110.c |  35 ---
>  drivers/net/lpc32xx_eth.c  |  52 +--
>  drivers/net/macb.c |  46 +++---
>  drivers/net/mcffec.c   |  13 ++-
>  drivers/net/mcfmii.c   |  19 ++--
>  drivers/net/mpc512x_fec.c  |  30 --
>  drivers/net/mpc5xxx_fec.c  |  30 --
>  drivers/net/mvgbe.c|  33 +--
>  drivers/net/phy/miiphybb.c |  25 ++---
>  drivers/net/sh_eth.c   |  12 ++-
>  drivers/net/smc911x.c  |  35 +--
>  drivers/qe/uec.c   |  32 ---
>  include/miiphy.h   |  20 +---
>  scripts/coccinelle/net/mdio_register.cocci | 142 
> +
>  38 files changed, 762 insertions(+), 375 deletions(-)
>  create mode 100644 scripts/coccinelle/net/mdio_register.cocci
> 
> -- 
> 1.7.11.5
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Sync dts files with upstream kernel

[Hans de Goede]

Hi,

On 19-08-16 09:11, Ian Campbell wrote:

On Fri, 2016-08-19 at 08:52 +0200, Hans de Goede wrote:

Sync dts files with the current (Aug 18th 2016) state of Maxime's
linux/sunxi/for-next repo.


Is that a rebasing tree, or is the sha of the specific commit stable
and therefore worth including here?


It is stable for a kernel-devel cycle and then gets rebased, so it is
not useful to include the hash IMHO.


Note this commit also updates configs/MSI_Primo81_defconfig,
adding: "# CONFIG_REQUIRE_SERIAL_CONSOLE is not set", this is necessary
because the tablet does not have a reachable uart so the dts sync
drops its serial0 alias.

Signed-off-by: Hans de Goede 


Acked-by: Ian Campbell 


Thanks for the reviews.

Regards,

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

Re: [U-Boot] [PATCH 4/5] arm: Provide common PSCI based reset handler

[Michal Simek]

Hi Alex,

On 16.8.2016 21:08, Alexander Graf wrote:
> Most armv8 systems have PSCI support enabled in EL3, either through
> ARM Trusted Firmware or other firmware.
> 
> On these systems, we do not need to implement system reset manually,
> but can instead rely on higher level firmware to deal with it.
> 
> The exclude list seems excessive right now, but NXP is working on
> providing an in-tree PSCI implementation, so that all NXP systems
> can eventually use PSCI as well.
> 
> Signed-off-by: Alexander Graf 
> ---
>  arch/arm/cpu/armv8/Kconfig   | 18 ++
>  arch/arm/cpu/armv8/fwcall.c  |  7 +++
>  arch/arm/mach-meson/board.c  |  5 -
>  board/xilinx/zynqmp/zynqmp.c |  5 -
>  4 files changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
> index 7e1fc4c..cd2d9bb 100644
> --- a/arch/arm/cpu/armv8/Kconfig
> +++ b/arch/arm/cpu/armv8/Kconfig
> @@ -21,4 +21,22 @@ config ARMV8_SPIN_TABLE
>   - Reserve the code for the spin-table and the release address
> via a /memreserve/ region in the Device Tree.
>  
> +config PSCI_RESET
> + bool "Use PSCI for reset and shutdown"
> + default y
> + depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
> +!TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
> +!TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
> +!TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
> +!TARGET_LS1043ARDB && !ARCH_UNIPHIER && !ARCH_SNAPDRAGON && \
> +!TARGET_S32V234EVB
> + help
> +   Most armv8 systems have PSCI support enabled in EL3, either through
> +   ARM Trusted Firmware or other firmware.
> +
> +   On these systems, we do not need to implement system reset manually,
> +   but can instead rely on higher level firmware to deal with it.
> +
> +   Select Y here to make use of PSCI calls for system reset
> +
>  endif
> diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
> index b3ef7c0..c57b15f 100644
> --- a/arch/arm/cpu/armv8/fwcall.c
> +++ b/arch/arm/cpu/armv8/fwcall.c
> @@ -112,3 +112,10 @@ void __noreturn psci_system_off(void)
>   while (1)
>   ;
>  }
> +
> +#ifdef CONFIG_PSCI_RESET
> +void reset_misc(void)
> +{
> + psci_system_reset();


maybe we should also consider to check which level we are running at.

if (current_el() != 3) {
...
}

But maybe this should be in checked in smc_call and hvc_call.

Thanks,
Michal



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

[U-Boot] [PATCH v2 7/7] config: evb-rk3399: enable fixed regulator

[Kever Yang]

This patch enable fixed regulator driver for rk3399 evb.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2:
- add Acked-by Tag from Simon

 configs/evb-rk3399_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 378111f..9a6d422 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -43,3 +43,5 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
-- 
1.9.1

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

[U-Boot] [PATCH v2 6/7] board: evb-rk3399: enable usb 2.0 host vbus power on board_init

[Kever Yang]

rk3399 using one gpio control signal for two usb 2.0 host port,
it's better to enable the power in board file instead of in usb driver.

Signed-off-by: Kever Yang 
---

Changes in v2:
- use regulator_get_by_platname instead of uclass_get_device_by_name

 board/rockchip/evb_rk3399/evb-rk3399.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c 
b/board/rockchip/evb_rk3399/evb-rk3399.c
index cd61f59..d1f1e89 100644
--- a/board/rockchip/evb_rk3399/evb-rk3399.c
+++ b/board/rockchip/evb_rk3399/evb-rk3399.c
@@ -9,12 +9,13 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
-   struct udevice *pinctrl;
+   struct udevice *pinctrl, *regulator;
int ret;
 
/*
@@ -40,6 +41,18 @@ int board_init(void)
goto out;
}
 
+   ret = regulator_get_by_platname("vcc5v0_host", );
+   if (ret) {
+   debug("%s vcc5v0_host init fail! ret %d\n", __func__, ret);
+   goto out;
+   }
+
+   ret = regulator_set_enable(regulator, true);
+   if (ret) {
+   debug("%s vcc5v0-host-en set fail!\n", __func__);
+   goto out;
+   }
+
 out:
return 0;
 }
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/7] config: rk3399: add usb related configs

[Kever Yang]

From: MengDongyang 

This patch to enable configs for usb module
- xhci
- ehci
- usb storage
- usb net

Signed-off-by: MengDongyang 
Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 configs/evb-rk3399_defconfig|  7 +++
 include/configs/rk3399_common.h | 13 +
 2 files changed, 20 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 2951678..378111f 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -15,6 +15,7 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_USB=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_CLK=y
@@ -36,3 +37,9 @@ CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
+CONFIG_USB=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index bc85e2f..4938165 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -106,4 +106,17 @@
 
 #endif
 
+/* enable usb config for usb ether */
+#define CONFIG_USB_HOST_ETHER
+
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_ASIX88179
+#define CONFIG_USB_ETHER_MCS7830
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_USB_ETHER_RTL8152
+
+/* rockchip xhci host driver */
+#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
+#define CONFIG_USB_XHCI_ROCKCHIP
+
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH v2 5/7] dts: rk3399-evb: add regulator-fixed for usb host vbus

[Kever Yang]

rk3399 evb using one gpio to enable 5V output for both USB 2.0
host port, let's use fixed regulator for them.

Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 arch/arm/dts/rk3399-evb.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index 7b49f6f..bd7801b 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -43,6 +43,12 @@
regulator-always-on;
regulator-boot-on;
};
+
+   vcc5v0_host: vcc5v0-host-en {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_host";
+   gpio = < 25 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 _phy {
-- 
1.9.1

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

[U-Boot] [PATCH v2 4/7] dts: rk3399: add dwc3_typec node for rk3399

[Kever Yang]

From: MengDongyang 

rk3399 has two dwc3 controller for type-C port, add the dts node
and enable them.

Signed-off-by: MengDongyang 
Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 arch/arm/dts/rk3399-evb.dts |  8 
 arch/arm/dts/rk3399.dtsi| 45 +
 2 files changed, 53 insertions(+)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index e92a492..7b49f6f 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -85,6 +85,10 @@
status = "okay";
 };
 
+_typec0 {
+   status = "okay";
+};
+
 _host1_ehci {
status = "okay";
 };
@@ -93,6 +97,10 @@
status = "okay";
 };
 
+_typec1 {
+   status = "okay";
+};
+
  {
pmic {
pmic_int_l: pmic-int-l {
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 6d82078..179860c 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#define USB_CLASS_HUB  9
 
 / {
compatible = "rockchip,rk3399";
@@ -230,6 +231,50 @@
status = "disabled";
};
 
+   dwc3_typec0: usb@fe80 {
+   compatible = "rockchip,rk3399-xhci";
+   reg = <0x0 0xfe80 0x0 0x10>;
+   status = "disabled";
+   rockchip,vbus-gpio = < 3 GPIO_ACTIVE_HIGH>;
+   snps,dis-enblslpm-quirk;
+   snps,phyif-utmi-bits = <16>;
+   snps,dis-u2-freeclk-exists-quirk;
+   snps,dis-u2-susphy-quirk;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+   hub {
+   compatible = "usb-hub";
+   usb,device-class = ;
+   };
+   typec_phy0 {
+   compatible = "rockchip,rk3399-usb3-phy";
+   reg = <0x0 0xff7c 0x0 0x4>;
+   };
+   };
+
+   dwc3_typec1: usb@fe90 {
+   compatible = "rockchip,rk3399-xhci";
+   reg = <0x0 0xfe90 0x0 0x10>;
+   status = "disabled";
+   rockchip,vbus-gpio = < 4 GPIO_ACTIVE_HIGH>;
+   snps,dis-enblslpm-quirk;
+   snps,phyif-utmi-bits = <16>;
+   snps,dis-u2-freeclk-exists-quirk;
+   snps,dis-u2-susphy-quirk;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+   hub {
+   compatible = "usb-hub";
+   usb,device-class = ;
+   };
+   typec_phy1 {
+   compatible = "rockchip,rk3399-usb3-phy";
+   reg = <0x0 0xff80 0x0 0x4>;
+   };
+   };
+
gic: interrupt-controller@fee0 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
-- 
1.9.1

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

[U-Boot] [PATCH v2 2/7] rockchip: select DM_USB for rockchip SoC

[Kever Yang]

From: MengDongyang 

Select DM_USB to compatible with USB DM driver model.

Signed-off-by: MengDongyang 
Signed-off-by: Kever Yang 
Acked-by: Simon Glass 
---

Changes in v2: None

 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ac9401..4dfd4b2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -861,6 +861,7 @@ config ARCH_ROCKCHIP
select DM_SERIAL
select DM_SPI
select DM_SPI_FLASH
+   select DM_USB if USB
 
 config TARGET_THUNDERX_88XX
bool "Support ThunderX 88xx"
-- 
1.9.1

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

[U-Boot] [PATCH v2 1/7] usb: xhci-rockchip: add rockchip dwc3 controller driver

[Kever Yang]

From: MengDongyang 

This patch add support for rockchip dwc3 controller, which corresponding
to the two type-C port on rk3399 evb.
Only support usb2.0 currently for we have not enable the usb3.0 phy
driver and PD(fusb302) driver.

Signed-off-by: MengDongyang 
Signed-off-by: Kever Yang 
---

Changes in v2:
- update for comments from Marek

 drivers/usb/host/Makefile|   1 +
 drivers/usb/host/xhci-rockchip.c | 227 +++
 include/linux/usb/dwc3.h |   9 ++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/usb/host/xhci-rockchip.c

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 620d114..fdefcf6 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_EHCI_ZYNQ) += ehci-zynq.o
 # xhci
 obj-$(CONFIG_USB_XHCI_HCD) += xhci.o xhci-mem.o xhci-ring.o
 obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o
+obj-$(CONFIG_USB_XHCI_ROCKCHIP) += xhci-rockchip.o
 obj-$(CONFIG_USB_XHCI_ZYNQMP) += xhci-zynqmp.o
 obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
 obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
diff --git a/drivers/usb/host/xhci-rockchip.c b/drivers/usb/host/xhci-rockchip.c
new file mode 100644
index 000..baf6b6e
--- /dev/null
+++ b/drivers/usb/host/xhci-rockchip.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (c) 2016 Rockchip, Inc.
+ * Authors: Daniel Meng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct rockchip_xhci_platdata {
+   fdt_addr_t hcd_base;
+   fdt_addr_t phy_base;
+   struct gpio_desc vbus_gpio;
+};
+
+/*
+ * Contains pointers to register base addresses
+ * for the usb controller.
+ */
+struct rockchip_xhci {
+   struct usb_platdata usb_plat;
+   struct xhci_ctrl ctrl;
+   struct xhci_hccr *hcd;
+   struct dwc3 *dwc3_reg;
+   struct udevice *dev;
+};
+
+static int xhci_usb_ofdata_to_platdata(struct udevice *dev)
+{
+   struct rockchip_xhci_platdata *plat = dev_get_platdata(dev);
+   struct udevice *child;
+   int ret = 0;
+
+   /*
+* Get the base address for XHCI controller from the device node
+*/
+   plat->hcd_base = dev_get_addr(dev);
+   if (plat->hcd_base == FDT_ADDR_T_NONE) {
+   debug("Can't get the XHCI register base address\n");
+   return -ENXIO;
+   }
+
+   /*
+* Get the base address for usbphy from the device node
+*/
+   for (device_find_first_child(dev, ); child;
+device_find_next_child()) {
+   if (!of_device_is_compatible(child, "rockchip,rk3399-usb3-phy"))
+   continue;
+   plat->phy_base = dev_get_addr(child);
+   break;
+   }
+
+   if (plat->phy_base == FDT_ADDR_T_NONE) {
+   debug("Can't get the usbphy register address\n");
+   return -ENXIO;
+   }
+
+   /* Vbus gpio */
+   ret = gpio_request_by_name(dev, "rockchip,vbus-gpio", 0,
+  >vbus_gpio, GPIOD_IS_OUT);
+   if (ret)
+   debug("rockchip,vbus-gpio node missing!");
+
+   return 0;
+}
+
+/*
+ * rockchip_dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
+ * @dwc: Pointer to our controller context structure
+ * @rockchip_xhci: Pointer to dev private data
+ */
+static void rockchip_dwc3_phy_setup(struct dwc3 *dwc3_reg,
+   struct rockchip_xhci *rockchip)
+{
+   u32 reg;
+   const void *blob = gd->fdt_blob;
+   struct udevice *dev = rockchip->dev;
+   const struct fdt_property *prop;
+   const u32 *data;
+
+   reg = readl(_reg->g_usb3pipectl[0]);
+
+   /* To do set dwc3 usb3 pipe control */
+
+   writel(reg, _reg->g_usb3pipectl[0]);
+
+   /* Set dwc3 usb2 phy config */
+
+   reg = readl(_reg->g_usb2phycfg[0]);
+
+   prop = fdt_get_property(blob, dev->of_offset,
+   "snps,dis-enblslpm-quirk", NULL);
+   if (prop)
+   reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
+   prop = fdt_get_property(blob, dev->of_offset,
+   "snps,phyif-utmi-bits", NULL);
+   data = (u32 *)prop->data;
+   if (fdt32_to_cpu(*data) == 16) {
+   reg |= DWC3_GUSB2PHYCFG_PHYIF;
+   reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
+   reg |= 5 << DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET;
+   } else if (fdt32_to_cpu(*data) == 8) {
+   reg &= ~DWC3_GUSB2PHYCFG_PHYIF;
+   reg &= ~DWC3_GUSB2PHYCFG_USBTRDTIM_MASK;
+   reg |= 9 << DWC3_GUSB2PHYCFG_USBTRDTIM_OFFSET;
+   }
+
+   prop = fdt_get_property(blob, dev->of_offset,
+   

[U-Boot] [PATCH v2 0/7] rk3399: enable host controllers

[Kever Yang]

rk3399 evb has two typec port(dwc3 controller) which support dual role
device with separate GPIO for vbus control and two USB 2.0 host port
(generic EHCI controller) with one GPIO for vbus control.

This patch set enable all these host controllers and have test with usb
disk and usb ethernet devices on rk3399 evb.

Note: type-C port only support usb 2.0 currently because the PD driver
and USB 3.0 phy driver not enabled.


Changes in v2:
- update for comments from Marek
- use regulator_get_by_platname instead of uclass_get_device_by_name
- add Acked-by Tag from Simon

Kever Yang (3):
  dts: rk3399-evb: add regulator-fixed for usb host vbus
  board: evb-rk3399: enable usb 2.0 host vbus power on board_init
  config: evb-rk3399: enable fixed regulator

MengDongyang (4):
  usb: xhci-rockchip: add rockchip dwc3 controller driver
  rockchip: select DM_USB for rockchip SoC
  config: rk3399: add usb related configs
  dts: rk3399: add dwc3_typec node for rk3399

 arch/arm/Kconfig   |   1 +
 arch/arm/dts/rk3399-evb.dts|  14 ++
 arch/arm/dts/rk3399.dtsi   |  45 +++
 board/rockchip/evb_rk3399/evb-rk3399.c |  15 ++-
 configs/evb-rk3399_defconfig   |   9 ++
 drivers/usb/host/Makefile  |   1 +
 drivers/usb/host/xhci-rockchip.c   | 227 +
 include/configs/rk3399_common.h|  13 ++
 include/linux/usb/dwc3.h   |   9 ++
 9 files changed, 333 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/host/xhci-rockchip.c

-- 
1.9.1

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

Re: [U-Boot] [PATCH] sunxi: Sync dts files with upstream kernel

[Ian Campbell]

On Fri, 2016-08-19 at 08:52 +0200, Hans de Goede wrote:
> Sync dts files with the current (Aug 18th 2016) state of Maxime's
> linux/sunxi/for-next repo.

Is that a rebasing tree, or is the sha of the specific commit stable
and therefore worth including here?

> Note this commit also updates configs/MSI_Primo81_defconfig,
> adding: "# CONFIG_REQUIRE_SERIAL_CONSOLE is not set", this is necessary
> because the tablet does not have a reachable uart so the dts sync
> drops its serial0 alias.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

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

Re: [U-Boot] [PATCH] ARM: dts: sun6i: Add defconfig and dts file for tablets using the inet-q972 PCB

[Ian Campbell]

On Thu, 2016-08-18 at 19:52 +0200, Hans de Goede wrote:
> Add a defconfig and dts file for tablets using the generic inet-q972 PCB.
> 
> Tablets with this PCB feature a mini-hdmi output, micro-usb usb-host,
> micro-usb usb-otg, 3.5mm headphone jack, a micro sd slot,
> (mini) power-barrel and an usb wifi module.
> 
> This has been tested on a 9.7" 1024x768 qware qw tb9718-qhd tablet.
> 
> The dts files are identical to the ones submitted to the upstream kernel.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

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

Re: [U-Boot] ZynqMP breakage

[Michal Simek]

On 16.8.2016 20:39, Alexander Graf wrote:
> Hi Michal,
> 
> I just tried to run the latest u-boot master + a few patches to implement 
> generic PSCI RTS support on zynqmp and got this:
> 
> e
> U-Boot 2016.09-rc1-00453-ga0592f1 (Aug 16 2016 - 20:27:40 +0200) Xilinx 
> ZynqMP ZCU102
> 
> I2C:   ready
> DRAM:  4 GiB
> EL Level:   EL2
> MMC:   sdhci@ff17: 0
> Using default environment
> 
> In:serial@ff00
> Out:   serial@ff00
> Err:   serial@ff00
> Bootmode: SD_MODE1
> SCSI:  SATA link 0 timeout.
> Target spinup took 0 ms.
> AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst
> scanning bus for devices...
> "Synchronous Abort" handler, esr 0x9604
> ELR: 7ff42d20
> LR:  7ff3ff10
> x0 :  x1 : 
> x2 : 0001 x3 : 7df1aa80
> x4 :  x5 : 0001
> x6 : 0200 x7 : 0004
> x8 : 7ff9f800 x9 : 0008
> x10: 7ff9f8f0 x11: 
> x12:  x13: 
> x14: 7ff8242f x15: 7ff82435
> x16: 7ff84388 x17: 7ff84388
> x18: 7df1ade8 x19: 7df1aa80
> x20: 7ff92cb8 x21: 7ff9f800
> x22: 7ff9f000 x23: 0078
> x24: 7ff9f8f0 x25: 
> x26: 7ff9f800 x27: 7ff9f000
> x28: 7ff9fb00 x29: 7df1aca0
> 
> Resetting CPU ...
> 
> resetting …
> 
> Is this a known problem?

Is this issue with usb?
I have usb off on zcu102 that's why if this usb issue
I am not aware about it.


Thanks,
Michal


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

Re: [U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL__SUPPORT as Kconfig option

[Heiko Schocher]

Hello Andrew,

first thanks for this series!

Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:

Create a new Kconfig file to contain SPL boot media loading support
options as we begin moving these to the Kconfig system and out of header
files. Initially add new configs for all the existing boot media types,
giving them the same definition name as before to allow compatibility
with systems not yet using Kconfig.

Signed-off-by: Andrew F. Davis 
---
  common/Kconfig |  7 +++
  common/spl/Kconfig | 54 ++
  2 files changed, 61 insertions(+)
  create mode 100644 common/spl/Kconfig

diff --git a/common/Kconfig b/common/Kconfig
index 46e7173..f594db5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -156,6 +156,13 @@ config SPI_BOOT
  booted via SPI flash. This is not a must, some SoCs need this,
  somes not.

+menu "SPL Media Loading Support"
+   depends on SPL
+
+source "common/spl/Kconfig"
+
+endmenu
+
  endmenu

  config BOOTDELAY
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
new file mode 100644
index 000..788ca14
--- /dev/null
+++ b/common/spl/Kconfig
@@ -0,0 +1,54 @@
+config SPL_YMODEM_SUPPORT
+   depends on SPL
+   bool "SPL Support for loading next stage from UART"
+   help
+ This option enables SPL to load the next stage bootloader
+ over a UART line using the x/y/z/modem protocol.
+
+config SPL_MMC_SUPPORT
+   bool "SPL Support for loading next stage from SD/MMC/eMMC"
+   help
+ This option enables SPL to load the next stage bootloader
+ from an SD/MMC/eMMC device.


Hmm.. why do you not move, for existing board configs, which use
this symbols, them into their defconfigs? There is the great
script from Masahiro

u-boot:tools/moveconfig.py

which should do the most things for you ... also there is a tbot
testcase, with which you can test, that your new patch(es) do not
break an existing board, see for interests:

http://lists.denx.de/pipermail/u-boot/2016-June/258119.html

Same comment applies for your patches:
[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL__BOOT as Kconfig option
[U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option

May you want to try it? If you have problems, feel free to contact me.

bye,
Heiko


+
+config SPL_SPI_SUPPORT
+   bool "SPL Support for loading next stage from SPI flash"
+   help
+ This option enables SPL to load the next stage bootloader
+ from SPI flash.
+
+config SPL_USB_SUPPORT
+   bool "SPL Support for loading next stage from USB"
+   help
+ This option enables SPL to load the next stage bootloader
+ from a USB device.
+
+config SPL_SATA_SUPPORT
+   bool "SPL Support for loading next stage from SATA"
+   help
+ This option enables SPL to load the next stage bootloader
+ from a SATA device.
+
+config SPL_NOR_SUPPORT
+   bool "SPL Support for loading next stage from NOR flash"
+   help
+ This option enables SPL to load the next stage bootloader
+ from NOR flash.
+
+config SPL_NAND_SUPPORT
+   bool "SPL Support for loading next stage from NAND flash"
+   help
+ This option enables SPL to load the next stage bootloader
+ from NAND flash.
+
+config SPL_ONENAND_SUPPORT
+   bool "SPL Support for loading next stage from ONENAND"
+   help
+ This option enables SPL to load the next stage bootloader
+ from ONENAND.
+
+config SPL_NET_SUPPORT
+   bool "SPL Support for loading next stage from NET"
+   help
+ This option enables SPL to load the next stage bootloader
+ from NET.



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/13] Cleanups to allow secure boot on AM33xx devices

[Lokesh Vutla]

On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
> Hello all,
> 
> I've recently been tasked with enabling authenticated boot for AM33xx based
> devices. This work is similar to what has already been done for the AM43xx
> and AM57xx SoCs and leverages much of the infrastructure from them.
> 
> The big difference here is the size of SRAM available on AM33xx being much
> less than on the other SoCs, when performing a secure boot this limits
> the maximum size of the SPL to just ~41k, the SPL currently generated for
> AM33xx SoCs is ~70k. To trim down the SPL we move various options from
> the config headers to the Kconfig system so we can selectively disable
> them in HS specific defconfigs.
> 
> To do this we start in patch 1 and 2 by creating Kconfig options for
> specifying what for what media the SPL should be able to load U-Boot
> from and for what media the SPL should itself be loaded from, respectively.
> We do this as the secure signature contains the name of the SPL boot
> media, and to reduce size. Also this works to reduce confusion
> in build types vs load types, we fix such an issue in patch 8.
> 
> In patch 3 and 4 we use the newly added _SUPPORT Kconfigs on a couple
> boards.
> 
> The rest are hopefully explained well enough in the commit message.

Have you tried doing build tests using buildman?. It is throwing lot of
errors.

Thanks and regards,
Lokesh


> 
> Thanks,
> Andrew
> 
> Andrew F. Davis (13):
>   spl: Kconfig: Add SPL__SUPPORT as Kconfig option
>   spl: Kconfig: Add SPL__BOOT as Kconfig option
>   spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
>   config: am335x_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig
>   config: am43xx_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig
>   Kconfig: Separate AM33XX SOC config from target board config
>   am33xx: config.mk: Add support for additional secure boot image types
>   am33xx: config.mk: Fix option used to enable SPI SPL image type
>   doc: Update info on using AM33xx secure devices from TI
>   ti: omap-common: Allow AM33xx devices to be built securely
>   omap: Use SD_BOOT in place of EMMC_BOOT
>   config: Remove usage of CONFIG_STORAGE_EMMC
>   board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx
> 
>  Kconfig   |  8 
>  arch/arm/Kconfig  | 20 
>  arch/arm/cpu/armv7/am33xx/Kconfig | 18 
>  arch/arm/cpu/armv7/am33xx/config.mk   | 29 ++--
>  arch/arm/cpu/armv7/omap-common/Kconfig|  2 +-
>  board/ti/am335x/board.c   |  8 
>  board/ti/am335x/mux.c |  4 +-
>  common/Kconfig| 76 
> +++
>  common/spl/Kconfig| 54 ++
>  configs/am335x_boneblack_defconfig|  4 +-
>  configs/am335x_boneblack_vboot_defconfig  |  5 +-
>  configs/am335x_evm_defconfig  |  3 ++
>  configs/am335x_evm_nor_defconfig  |  2 +
>  configs/am335x_evm_norboot_defconfig  |  1 +
>  configs/am335x_evm_spiboot_defconfig  |  2 +
>  configs/am335x_evm_usbspl_defconfig   |  1 +
>  configs/am335x_sl50_defconfig |  2 +-
>  configs/am43xx_evm_defconfig  |  1 +
>  configs/am43xx_evm_ethboot_defconfig  |  1 +
>  configs/am43xx_evm_qspiboot_defconfig |  1 +
>  configs/am43xx_evm_usbhost_boot_defconfig |  1 +
>  configs/am43xx_hs_evm_defconfig   |  1 +
>  configs/brppt1_mmc_defconfig  |  3 +-
>  configs/brppt1_spi_defconfig  |  3 +-
>  doc/README.ti-secure  | 32 +
>  include/configs/am335x_evm.h  |  6 +--
>  include/configs/am335x_shc.h  |  2 -
>  include/configs/am335x_sl50.h |  4 +-
>  include/configs/am43xx_evm.h  |  1 -
>  include/configs/bav335x.h |  4 +-
>  include/configs/brppt1.h  |  6 +--
>  include/configs/ti_am335x_common.h|  4 ++
>  32 files changed, 272 insertions(+), 37 deletions(-)
>  create mode 100644 common/spl/Kconfig
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot