Re: [U-Boot] [PATCH v2 0/17] dm: Add I2C support and convert sandbox, tegra

2014-11-16 Thread Heiko Schocher

Hello Simon,

Am 11.11.2014 18:46, schrieb Simon Glass:

This series adds I2C support to driver model. It has become apparent that
this is a high priority as it is widely used. It follows along to some
extent from the SPI conversion.

Several changes are made from the original I2C implementations.

Firstly it is not necessary to specify the chip address with every call,
since each chip knows its own address - it is stored in struct dm_i2c_chip
which is attached to each chip on the I2C bus. However, this information
*is* passed to the driver since I presume most drivers need it and it would
be cumbersome to look up in every call.

Secondly there is no concept of a 'current' I2C bus so all associated logic
is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are
not available. Since the chip device specifies both the bus and the chip
address, there is no need for this concept. It also causes problems when
one driver changes the current bus and forgets to change it back.

Thirdly initialisation is handled by driver model's normal probe() method
on each device so there should be no need for i2c_init_all(), i2c_init(),
i2c_init_board(), i2c_board_late_init() and board_i2c_init().

I2C muxes are not yet supported. To support these we will need to maintain
state of the current mux settings to avoid resetting every mux every time.
Probably we need to add a sandbox I2C mux driver to permit testing of this.
This can probably be done later.

Platform data is not yet supported either, only device tree. The
U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not
used. Also struct i2c_adapter is not defined anymore. This will need to be
addressed, perhaps as part of converting over a board that does not use
device tree, assuming that we want to support this.

The following I2C CONFIGs are no-longer needed when driver model is used:

   CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method
   CONFIG_I2C_MULTI_BUS  - we always support multi-bus with driver model
   CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses
   CONFIG_SYS_I2C_SPEED  - the device tree specifies the speed for each bus
   CONFIG_SYS_I2C- this is the 'new old' API, now deprecated

There are a few SPI patches included here due to a dependency on a new
device binding function.

This series is available at u-boot-dm/i2c-working.

Changes in v2:
- Add a suitable commit message
- Add new patch to correct handling of aliases with embedded digits
- Add new patch to add a function to bind a device by driver name
- Add new patches to adjust SPI to use device_bind_driver()
- Fix cihp typo
- Implement generic I2C devices to allow 'i2c probe' on unknown devices
- Return the probed device from i2c_probe()
- Set the bus speed after the bus is probed
- Add some debugging for generic I2C device binding
- Add a 'deblock' method to recover an I2C bus stuck in mid-transaction
- Add a helper function to find a chip on a particular bus number
- Change alen to int so that it can be -1 (this was a bug)
- Call the deblock() method for 'i2c reset'
- Update commit message for EEPROM driver
- Add a test for automatic binding of generic I2C devices
- Add a new asm/test.h header for tests in sandbox
- Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices
- Correct the compatible strings for I2C buses
- Don't init if the speed is 0, since this breaks the controller
- Expand coverage to all Tegra boards

Simon Glass (17):
   dm: i2c: Move error reporting into a common function
   dm: core: Allow access to the device's driver_id data
   dm: core: Add functions to find parent and OF data
   dm: fdt: Correct handling of aliases with embedded digits
   dm: Add a function to bind a device by driver name
   dm: spi: Correct handling of SPI chip selects in sandbox
   dm: spi: Use device_bind_driver() instead of our own function
   dm: i2c: Add a uclass for I2C
   dm: i2c: Implement driver model support in the i2c command
   dm: i2c: Add I2C emulation driver for sandbox
   dm: i2c: Add a sandbox I2C driver
   dm: i2c: Add an I2C EEPROM simulator
   dm: i2c: config: Enable I2C for sandbox using driver model
   dm: i2c: dts: Add an I2C bus for sandbox
   dm: Add a simple EEPROM driver
   dm: i2c: Add tests for I2C
   dm: i2c: tegra: Convert to driver model

  arch/arm/cpu/tegra20-common/pmu.c   |  21 +-
  arch/arm/dts/tegra124-jetson-tk1.dts|   1 -
  arch/arm/dts/tegra124-norrin.dts|   1 -
  arch/arm/dts/tegra30-tec-ng.dts |   4 +
  arch/arm/include/asm/arch-tegra/tegra_i2c.h |   2 +-
  arch/sandbox/dts/sandbox.dts|  17 ++
  arch/sandbox/include/asm/test.h |  15 ++
  board/avionic-design/common/tamonten-ng.c   |  12 +-
  board/nvidia/cardhu/cardhu.c|  13 +-
  board/nvidia/common/board.c |   4 -
  board/nvidia/dalmore/dalmore.c  |  21 +-
  board/nvidia/whistler/whistler.c

Re: [U-Boot] [PATCH 1/3 v2] blackfin: rename bfin-twi_i2c driver to adi_i2c

2014-11-16 Thread Heiko Schocher

Hello Sonic Zhang,

Am 13.11.2014 08:30, schrieb Scott Jiang:

Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
  drivers/i2c/Makefile  |2 +-
  drivers/i2c/{bfin-twi_i2c.c = adi_i2c.c} |7 +++
  include/configs/bct-brettl2.h |2 +-
  include/configs/bf518f-ezbrd.h|2 +-
  include/configs/bf526-ezbrd.h |2 +-
  include/configs/bf527-ad7160-eval.h   |2 +-
  include/configs/bf527-ezkit.h |2 +-
  include/configs/bf527-sdp.h   |2 +-
  include/configs/bf537-minotaur.h  |2 +-
  include/configs/bf537-pnav.h  |2 +-
  include/configs/bf537-srv1.h  |2 +-
  include/configs/bf537-stamp.h |2 +-
  include/configs/bf538f-ezkit.h|2 +-
  include/configs/bf548-ezkit.h |2 +-
  include/configs/bf609-ezkit.h |2 +-
  include/configs/br4.h |2 +-
  include/configs/cm-bf527.h|2 +-
  include/configs/cm-bf537e.h   |2 +-
  include/configs/cm-bf537u.h   |2 +-
  include/configs/cm-bf548.h|2 +-
  include/configs/pr1.h |2 +-
  include/configs/tcm-bf518.h   |2 +-
  include/configs/tcm-bf537.h   |2 +-
  23 files changed, 25 insertions(+), 26 deletions(-)
  rename drivers/i2c/{bfin-twi_i2c.c = adi_i2c.c} (98%)


This patch looks fine from my side ... is it okay for you
if I pick up this patch
(and the patches belonging into this series

Patchwork [U-Boot,2/3,v2] adi_i2c: convert to use general io accessors.
http://patchwork.ozlabs.org/patch/409887/

Patchwork [U-Boot,3/3,v2] blackfin: convert to use CONFIG_SYS_I2C framework
http://patchwork.ozlabs.org/patch/409888/

)?

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
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 v2 0/17] dm: Add I2C support and convert sandbox, tegra

2014-11-16 Thread Simon Glass
Hi Heiko,

On 17 November 2014 06:42, Heiko Schocher h...@denx.de wrote:

 Hello Simon,

 Am 11.11.2014 18:46, schrieb Simon Glass:

 This series adds I2C support to driver model. It has become apparent that
 this is a high priority as it is widely used. It follows along to some
 extent from the SPI conversion.

 Several changes are made from the original I2C implementations.

 Firstly it is not necessary to specify the chip address with every call,
 since each chip knows its own address - it is stored in struct dm_i2c_chip
 which is attached to each chip on the I2C bus. However, this information
 *is* passed to the driver since I presume most drivers need it and it would
 be cumbersome to look up in every call.

 Secondly there is no concept of a 'current' I2C bus so all associated logic
 is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are
 not available. Since the chip device specifies both the bus and the chip
 address, there is no need for this concept. It also causes problems when
 one driver changes the current bus and forgets to change it back.

 Thirdly initialisation is handled by driver model's normal probe() method
 on each device so there should be no need for i2c_init_all(), i2c_init(),
 i2c_init_board(), i2c_board_late_init() and board_i2c_init().

 I2C muxes are not yet supported. To support these we will need to maintain
 state of the current mux settings to avoid resetting every mux every time.
 Probably we need to add a sandbox I2C mux driver to permit testing of this.
 This can probably be done later.

 Platform data is not yet supported either, only device tree. The
 U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not
 used. Also struct i2c_adapter is not defined anymore. This will need to be
 addressed, perhaps as part of converting over a board that does not use
 device tree, assuming that we want to support this.

 The following I2C CONFIGs are no-longer needed when driver model is used:

CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method
CONFIG_I2C_MULTI_BUS  - we always support multi-bus with driver model
CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses
CONFIG_SYS_I2C_SPEED  - the device tree specifies the speed for each 
 bus
CONFIG_SYS_I2C- this is the 'new old' API, now deprecated

 There are a few SPI patches included here due to a dependency on a new
 device binding function.

 This series is available at u-boot-dm/i2c-working.

 Changes in v2:
 - Add a suitable commit message
 - Add new patch to correct handling of aliases with embedded digits
 - Add new patch to add a function to bind a device by driver name
 - Add new patches to adjust SPI to use device_bind_driver()
 - Fix cihp typo
 - Implement generic I2C devices to allow 'i2c probe' on unknown devices
 - Return the probed device from i2c_probe()
 - Set the bus speed after the bus is probed
 - Add some debugging for generic I2C device binding
 - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction
 - Add a helper function to find a chip on a particular bus number
 - Change alen to int so that it can be -1 (this was a bug)
 - Call the deblock() method for 'i2c reset'
 - Update commit message for EEPROM driver
 - Add a test for automatic binding of generic I2C devices
 - Add a new asm/test.h header for tests in sandbox
 - Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices
 - Correct the compatible strings for I2C buses
 - Don't init if the speed is 0, since this breaks the controller
 - Expand coverage to all Tegra boards

 Simon Glass (17):
dm: i2c: Move error reporting into a common function
dm: core: Allow access to the device's driver_id data
dm: core: Add functions to find parent and OF data
dm: fdt: Correct handling of aliases with embedded digits
dm: Add a function to bind a device by driver name
dm: spi: Correct handling of SPI chip selects in sandbox
dm: spi: Use device_bind_driver() instead of our own function
dm: i2c: Add a uclass for I2C
dm: i2c: Implement driver model support in the i2c command
dm: i2c: Add I2C emulation driver for sandbox
dm: i2c: Add a sandbox I2C driver
dm: i2c: Add an I2C EEPROM simulator
dm: i2c: config: Enable I2C for sandbox using driver model
dm: i2c: dts: Add an I2C bus for sandbox
dm: Add a simple EEPROM driver
dm: i2c: Add tests for I2C
dm: i2c: tegra: Convert to driver model

   arch/arm/cpu/tegra20-common/pmu.c   |  21 +-
   arch/arm/dts/tegra124-jetson-tk1.dts|   1 -
   arch/arm/dts/tegra124-norrin.dts|   1 -
   arch/arm/dts/tegra30-tec-ng.dts |   4 +
   arch/arm/include/asm/arch-tegra/tegra_i2c.h |   2 +-
   arch/sandbox/dts/sandbox.dts|  17 ++
   arch/sandbox/include/asm/test.h |  15 ++
   board/avionic-design/common/tamonten-ng.c   |  12 +-
   board/nvidia/cardhu/cardhu.c

Re: [U-Boot] [RFC] dm: tegra: boot time regression

2014-11-16 Thread Simon Glass
Hi,

On 21 October 2014 17:19, Simon Glass s...@chromium.org wrote:
 Hi Marcel,

 On 21 October 2014 08:37, Marcel Ziswiler mar...@ziswiler.com wrote:
 Migrating our BSPs towards mainline U-Boot I noticed it suddenly booting
 slower. With mainline Linux I noticed about a 1 to 2 second increase
 while booting downstream L4T takes 10 to 15 seconds longer! Git
 bisecting it revealed the following commit to be at odds:

 858530a8c0a7ce7e573e513934804a00d6676813
 dm: tegra: Enable driver model for serial

 Switching back to not using the DM driver for serial brings it back to
 booting much faster. However looking closely at the serial stuff and its
 accompanying settings I could not quite pinpoint why exactly any of this
 would make the Linux kernel suddenly boot slower.

 Has anybody noticed similar issues?


 No I haven't but I have not really tested it. I wonder how U-Boot is
 affecting Linux boot time? Do you have a trace of the kernel boot?

Did this get resolved? Do you have an update please?

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


Re: [U-Boot] [PATCH 1/3 v2] blackfin: rename bfin-twi_i2c driver to adi_i2c

2014-11-16 Thread Sonic Zhang
Hi Keiko,

On Mon, Nov 17, 2014 at 2:50 PM, Heiko Schocher h...@denx.de wrote:
 Hello Sonic Zhang,

 Am 13.11.2014 08:30, schrieb Scott Jiang:

 Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
 ---
   drivers/i2c/Makefile  |2 +-
   drivers/i2c/{bfin-twi_i2c.c = adi_i2c.c} |7 +++
   include/configs/bct-brettl2.h |2 +-
   include/configs/bf518f-ezbrd.h|2 +-
   include/configs/bf526-ezbrd.h |2 +-
   include/configs/bf527-ad7160-eval.h   |2 +-
   include/configs/bf527-ezkit.h |2 +-
   include/configs/bf527-sdp.h   |2 +-
   include/configs/bf537-minotaur.h  |2 +-
   include/configs/bf537-pnav.h  |2 +-
   include/configs/bf537-srv1.h  |2 +-
   include/configs/bf537-stamp.h |2 +-
   include/configs/bf538f-ezkit.h|2 +-
   include/configs/bf548-ezkit.h |2 +-
   include/configs/bf609-ezkit.h |2 +-
   include/configs/br4.h |2 +-
   include/configs/cm-bf527.h|2 +-
   include/configs/cm-bf537e.h   |2 +-
   include/configs/cm-bf537u.h   |2 +-
   include/configs/cm-bf548.h|2 +-
   include/configs/pr1.h |2 +-
   include/configs/tcm-bf518.h   |2 +-
   include/configs/tcm-bf537.h   |2 +-
   23 files changed, 25 insertions(+), 26 deletions(-)
   rename drivers/i2c/{bfin-twi_i2c.c = adi_i2c.c} (98%)


 This patch looks fine from my side ... is it okay for you
 if I pick up this patch
 (and the patches belonging into this series

 Patchwork [U-Boot,2/3,v2] adi_i2c: convert to use general io accessors.
 http://patchwork.ozlabs.org/patch/409887/

 Patchwork [U-Boot,3/3,v2] blackfin: convert to use CONFIG_SYS_I2C framework
 http://patchwork.ozlabs.org/patch/409888/

 )?


This is OK to me.

Regards,

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


[U-Boot] sunxi: CPU disabling (was: Re: ARM: flush_dcache_all for PSCI)

2014-11-16 Thread Jan Kiszka
On 2014-11-10 14:10, Marc Zyngier wrote:
 On 10/11/14 12:57, Jan Kiszka wrote:
 Hi all,

 I'm trying to get Marc's CPU hotplug-anabling patch [1] for sunxi
 working on a B-Pi. After the first discussion it became clear that we
 need something like flush_dcache_all in the PSCI monitor (I don't think
 we need an icache flush, do we?). Does anyone have a clever suggestion
 
 No, I-cache can be left alone.
 
 how to reuse the existing code for that? Or do we really need to
 re-implement everything, in the worst case in assembly?
 
 Why don't you turn the u-boot code into a set of macros, included by
 both the core u-boot code and the PSCI code?

I've now ported over v7_flush_dcache_all from the Linux kernel.

However, that didn't magically solve the remaining issues with your
patch: I'm getting crashes on CPU 0 after handling the shoot-down FIQ.
That is even then the case if I only acknowledge the FIQ on the receiver
side, don't do any fiddling with CPU1's power states. Only if I
disabling sending the FIQ from CPU 1, the system remains stable in a CPU
off/on loop.

Below the patch I'm using. Any ideas if something is wrong with the FIQ
handler or the setup of this mechanism or whatever?

Jan

---

diff --git a/arch/arm/cpu/armv7/sunxi/psci.S b/arch/arm/cpu/armv7/sunxi/psci.S
index b9ea78b..0e4bca4 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.S
+++ b/arch/arm/cpu/armv7/sunxi/psci.S
@@ -18,6 +18,7 @@
  */
 
 #include config.h
+#include asm/gic.h
 #include asm/psci.h
 #include asm/arch/cpu.h
 
@@ -38,6 +39,8 @@
 
 #defineONE_MS  (CONFIG_SYS_CLK_FREQ / 1000)
 #defineTEN_MS  (10 * ONE_MS)
+#defineGICD_BASE   0x1c81000
+#defineGICC_BASE   0x1c82000
 
 .macro timer_wait  reg, ticks
@ Program CNTP_TVAL
@@ -61,7 +64,27 @@
 
 .globl psci_arch_init
 psci_arch_init:
+   movwr4, #(GICD_BASE  0x)
+   movtr4, #(GICD_BASE  16)
+
+   ldr r5, [r4, #GICD_IGROUPRn]
+   bic r5, r5, #(1  15)  @ SGI15 as Group-0
+   str r5, [r4, #GICD_IGROUPRn]
+
+   mov r5, #0  @ Set SGI15 priority to 0
+   strbr5, [r4, #(GICD_IPRIORITYRn + 15)]
+
+   add r4, r4, #0x1000 @ GICC address
+
+   mov r5, #0xff
+   str r5, [r4, #GICC_PMR] @ Be cool with non-secure
+
+   ldr r5, [r4, #GICC_CTLR]
+   orr r5, r5, #(1  3)   @ Switch FIQEn on
+   str r5, [r4, #GICC_CTLR]
+
mrc p15, 0, r5, c1, c1, 0   @ Read SCR
+   orr r5, r5, #4  @ Enable FIQ in monitor mode
bic r5, r5, #1  @ Secure mode
mcr p15, 0, r5, c1, c1, 0   @ Write SCR
isb
@@ -79,6 +102,77 @@ psci_arch_init:
 
bx  lr
 
+.globl psci_fiq_enter
+psci_fiq_enter:
+   push{r0-r12}
+
+   @ Switch to secure
+   mrc p15, 0, r7, c1, c1, 0
+   bic r8, r7, #1
+   mcr p15, 0, r8, c1, c1, 0
+   isb
+
+   movwr8, #(GICC_BASE  0x)
+   movtr8, #(GICC_BASE  16)
+   ldr r9, [r8, #GICC_IAR]
+   movwr10, #0x3ff
+   movtr10, #0
+   cmp r9, r10
+   beq out
+   movwr10, #0x3fe
+   cmp r9, r10
+   beq out
+   str r9, [r8, #GICC_EOIR]
+   dsb
+
+   @ Compute CPU number
+   lsr r9, r9, #10
+   and r9, r9, #0xf
+
+   movwr8, #(SUN7I_CPUCFG_BASE  0x)
+   movtr8, #(SUN7I_CPUCFG_BASE  16)
+
+   @ Wait for the core to enter WFI
+   lsl r11, r9, #6 @ x64
+   add r11, r11, r8
+
+1: ldr r10, [r11, #0x48]
+   tst r10, #(1  2)
+   bne 2f
+   timer_wait r10, ONE_MS
+   b   1b
+
+   @ Reset CPU
+2: mov r10, #0
+   str r10, [r11, #0x40]
+
+   @ Lock CPU
+   mov r10, #1
+   lsl r9, r10, r9 @ r9 is now CPU mask
+   ldr r10, [r8, #0x1e4]
+   bic r10, r10, r9
+   str r10, [r8, #0x1e4]
+
+   @ Set power gating
+   ldr r10, [r8, #0x1b4]
+   orr r10, r10, #1
+   str r10, [r8, #0x1b4]
+   timer_wait r10, ONE_MS
+
+   @ Activate power clamp
+   mov r10, #1
+1: str r10, [r8, #0x1b0]
+   lsl r10, r10, #1
+   orr r10, r10, #1
+   tst r10, #0x100
+   beq 1b
+
+   @ Restore security level
+out:   mcr p15, 0, r7, c1, c1, 0
+
+   pop {r0-r12}
+   movspc, lr
+
@ r1 = target CPU
@ r2 = target PC
 .globl psci_cpu_on
@@ -144,6 +238,57 @@ psci_cpu_on:
 _target_pc:
.word   0
 
+# Imported from Linux kernel
+v7_flush_dcache_all:
+   dmb @ ensure ordering with previous 
memory accesses
+   mrc p15, 1, r0, c0, c0, 1   @ read clidr
+   andsr3, r0, #0x700  @ extract loc from clidr
+   mov r3, r3, lsr #23 

Re: [U-Boot] Booting non devicetree enabled kernels using u-boot build with CONFIG_OF_LIBFDT ?

2014-11-16 Thread Simon Glass
Hi Hans,

On 16 November 2014 19:41, Hans de Goede hdego...@redhat.com wrote:
 Hi,

 On 11/13/2014 07:38 PM, Hans de Goede wrote:
 Hi,

 On 11/13/2014 07:34 PM, Tom Rini wrote:
 On Thu, Nov 13, 2014 at 07:08:59PM +0100, Hans de Goede wrote:
 Hi all,

 So as you know I've been working on getting mainline u-boot to boot the
 older android derived linux-sunxi kernels, as some people need features
 not yet in mainline, and I would like there to be only one u-boot for both.

 I had this working a while ago, but recently it broke, this is caused by
 config_distro_defaults.h setting CONFIG_OF_LIBFDT, if I undef that
 after including config_distro_defaults.h things work again.

 I do not know if CONFIG_OF_LIBFDT is a recent addition to 
 config_distro_defaults.h,
 or if something else broke things. But if I do not undef it, boot fails 
 with:

 sun7i# bootm start 0x4800
 ## Booting kernel from Legacy Image at 4800 ...
Image Name:   Linux-3.4.75.sun7i+
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:3966672 Bytes = 3.8 MiB
Load Address: 40008000
Entry Point:  40008000
Verifying Checksum ... OK
 Could not find a valid device tree

 My hunch is that we've got more fall-out from Simon's re-org of the
 bootm code ages ago.  It should be valid to try and boot a kernel
 without a device tree and other parts of the code base (for example
 arch/arm/lib/bootm.c) still do a FDT-or-ATAGS dance for example.

I'm not so sure. If I go back to v2011.03 I see that bootm_start()
calls boot_get_fdt() and prints that message if it fails. This call is
protected by CONFIG_OF_LIBFDT. So in this respect I don't see the new
code (bootm refactor of mid-2013) being different from the old.

It looks like this was created in this commit from 2008:

06a09918f bootm: refactor fdt locating and relocation code

It moved the PPC behaviour over to be common for all archs.

Of course I could be missing something, but I can't see it.


 That is good news, because ideally upstream u-boot build with
 OLD_SUNXI_KERNEL_COMPAT should be able to boot old disk images without
 needing them to modify their boot.scr, which requiring bootm 0xfoo - -
 would do.

 So maybe check if there is a third argument to bootm, and if there
 is not still try the dance for finding one appended in various ways,
 and if that fails continue normally (where as with the third
 argument present this of course needs to stay an error) ?

 Ping ? The above was intended as a question, I'm willing to spend some
 time on getting the behavior suggested above, but first I would like to
 heat that such behavior is desirable (and thus my patch has a chance of
 getting applied).

You can go through the steps using the bootm sub-commands, but it is a
bit painful. I'm not sure about the intended behaviour.

If you look at the README, it says:

 CONFIG_OF_LIBFDT
 New kernel versions are expecting firmware settings to be
 passed using flattened device trees (based on open firmware
 concepts).
 CONFIG_OF_LIBFDT
 * New libfdt-based support
 * Adds the fdt command
 * The bootm command automatically updates the fdt

My feeling is that CONFIG_OF_LIBFDT probably means that an FDT should
be provided to the kernel. If that is true then I don't like this
either - it should add the capability, not require it to be used. But
it appears to be long-standing behaviour going back 6 years.

What could we do? We presumably do want to report an error if there is
no FDT when the kernel needs it, but I'm not sure how we know. The
'dance' described above seems reasonable to me.

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


Re: [U-Boot] [PATCH] get_maintainer.pl: fix source tree detection

2014-11-16 Thread Simon Glass
On 16 November 2014 19:30, Daniel Schwierzeck
daniel.schwierz...@gmail.com wrote:
 get_maintainer.pl always fails with following message:
 ./scripts/get_maintainer.pl: The current directory does not appear to be a 
 linux kernel source tree.

 This was caused by commit:

 commit 548b310c68ac99a0330d8b56c797c09ff0742d1e
 Author: Masahiro Yamada yamad...@jp.panasonic.com
 Date:   Thu Oct 30 15:50:15 2014 +0900

 Remove the CREDITS file

 This file is not maintained these days.

 We use MAINTAINERS for the maintainership of the supported boards.
 For dead boards, we have some clues in doc/README.scrapyard and
 also imperishable history in git-log.

 Remove CREDITS from source tree detection to fix this.

 Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ot1200: fix card detect for usdhc4

2014-11-16 Thread Christian Gmeiner
Hi Stefano


2014-11-13 16:34 GMT+01:00 Stefano Babic sba...@denx.de:
 On 11/11/2014 12:57, Christian Gmeiner wrote:
 Today I got the final board and found out that a different
 connector is used as the one on my development board. The
 new connector has swaped pins for cd and wp.

 This change is tested on a production ready baord.


 I fixed it myself.


Thanks a lot!

 Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
 ---
  board/bachmann/ot1200/ot1200.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/board/bachmann/ot1200/ot1200.c b/board/bachmann/ot1200/ot1200.c
 index 2ed8cf7..007c1ef 100644
 --- a/board/bachmann/ot1200/ot1200.c
 +++ b/board/bachmann/ot1200/ot1200.c
 @@ -159,8 +159,8 @@ int board_mmc_getcd(struct mmc *mmc)
   gpio_direction_input(IMX_GPIO_NR(4, 5));
   ret = gpio_get_value(IMX_GPIO_NR(4, 5));
   } else {
 - gpio_direction_input(IMX_GPIO_NR(1, 4));
 - ret = !gpio_get_value(IMX_GPIO_NR(1, 4));
 + gpio_direction_input(IMX_GPIO_NR(1, 5));
 + ret = !gpio_get_value(IMX_GPIO_NR(1, 5));
   }

   return ret;


 Applied to u-boot-imx, thanks !


greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v8 1/3] exynos5: fix GPIO information of exynos5420

2014-11-16 Thread Simon Glass
Hi Hyungwon,

On 14 November 2014 06:25, Hyungwon Hwang human.hw...@samsung.com wrote:
 This patch fixes wrong GPIO information such as GPIO bank, table which
 is used to convert GPIO name to index, bank base address, and etc.

 Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
 Tested-by: Lukasz Majewski l.majew...@samsung.com
 Acked-by: Lukasz Majewski l.majew...@samsung.com
 Cc: Minkyu Kang mk7.k...@samsung.com
 Cc: Lukasz Majewski l.majew...@samsung.com
 ---
 Changes for v4:
 - None

 Changes for v5:
 - None

 Changes for v6:
 - None

 Changes for v7:
 - None

 Changes for v8:
 - None

  arch/arm/include/asm/arch-exynos/cpu.h  |  11 +-
  arch/arm/include/asm/arch-exynos/gpio.h | 232 
 +++-
  2 files changed, 117 insertions(+), 126 deletions(-)

 diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
 b/arch/arm/include/asm/arch-exynos/cpu.h
 index 29674ad..48936de 100644
 --- a/arch/arm/include/asm/arch-exynos/cpu.h
 +++ b/arch/arm/include/asm/arch-exynos/cpu.h
 @@ -148,7 +148,7 @@

  /* EXYNOS5420 */
  #define EXYNOS5420_AUDIOSS_BASE0x0381
 -#define EXYNOS5420_GPIO_PART6_BASE 0x0386
 +#define EXYNOS5420_GPIO_PART5_BASE 0x0386
  #define EXYNOS5420_PRO_ID  0x1000
  #define EXYNOS5420_CLOCK_BASE  0x1001
  #define EXYNOS5420_POWER_BASE  0x1004
 @@ -170,11 +170,10 @@
  #define EXYNOS5420_I2S_BASE0x12D6
  #define EXYNOS5420_PWMTIMER_BASE   0x12DD
  #define EXYNOS5420_SPI_ISP_BASE0x131A
 -#define EXYNOS5420_GPIO_PART2_BASE 0x1340
 -#define EXYNOS5420_GPIO_PART3_BASE 0x13400C00
 -#define EXYNOS5420_GPIO_PART4_BASE 0x1341
 -#define EXYNOS5420_GPIO_PART5_BASE 0x1400
 -#define EXYNOS5420_GPIO_PART1_BASE 0x1401
 +#define EXYNOS5420_GPIO_PART1_BASE 0x1340
 +#define EXYNOS5420_GPIO_PART2_BASE 0x1341
 +#define EXYNOS5420_GPIO_PART3_BASE 0x1400
 +#define EXYNOS5420_GPIO_PART4_BASE 0x1401
  #define EXYNOS5420_MIPI_DSIM_BASE  0x1450
  #define EXYNOS5420_DP_BASE 0x145B

 diff --git a/arch/arm/include/asm/arch-exynos/gpio.h 
 b/arch/arm/include/asm/arch-exynos/gpio.h
 index 9699954..aef897d 100644
 --- a/arch/arm/include/asm/arch-exynos/gpio.h
 +++ b/arch/arm/include/asm/arch-exynos/gpio.h
 @@ -1042,83 +1042,7 @@ enum exynos5_gpio_pin {
  };

  enum exynos5420_gpio_pin {
 -   /* GPIO_PART1_STARTS */
 -   EXYNOS5420_GPIO_A00,/* 0 */

Why does this order need to change? I think you might be trying to
remove the device tree work-around that we currently have. See
arch/arm/dts/exynos54xx-pinctrl-uboot.dtsi:

/*
 * Replicate the ordering of arch/arm/include/asm/arch-exynos/gpio.h
 * TODO(s...@chromium.org): This ordering ceases to matter once GPIO
 * numbers are not needed in U-Boot for exynos.
 */
pinctrl@1401 {
#address-cells = 1;
#size-cells = 0;
};
pinctrl@1340 {
#address-cells = 1;
#size-cells = 0;
gpy7 {
};

gpx0 {
reg = 0xc00;
};
};

Since you are changing things such that gpy7 comes first, I think you
need to update this file. But then don't you also need to update all
the numbering that we have in the various device tree files? For
example in exynos5420-peach-pit.dts:

ec-interrupt = gpio 93 1; /* GPX1_5 */

The 93 will be wrong now I think - should it become 21?

I do have a vague plan to implement proper device tree support for
GPIOs using driver model, so you could do:

ec-interrupt = gpx1 5 GPIO_ACTIVE_LOW;

The gpx1 bit is already there. We need to bring over the dt-binding
header from Linux, and adjust the driver model uclass to understand
GPIO nodes better.

But if you are not up for any of this, I wonder if you should just
change the ordering back?

See also my comments below.

 -   EXYNOS5420_GPIO_A01,
 -   EXYNOS5420_GPIO_A02,
 -   EXYNOS5420_GPIO_A03,
 -   EXYNOS5420_GPIO_A04,
 -   EXYNOS5420_GPIO_A05,
 -   EXYNOS5420_GPIO_A06,
 -   EXYNOS5420_GPIO_A07,
 -   EXYNOS5420_GPIO_A10,/* 8 */
 -   EXYNOS5420_GPIO_A11,
 -   EXYNOS5420_GPIO_A12,
 -   EXYNOS5420_GPIO_A13,
 -   EXYNOS5420_GPIO_A14,
 -   EXYNOS5420_GPIO_A15,
 -   EXYNOS5420_GPIO_A16,
 -   EXYNOS5420_GPIO_A17,
 -   EXYNOS5420_GPIO_A20,/* 16 0x10 */
 -   EXYNOS5420_GPIO_A21,
 -   EXYNOS5420_GPIO_A22,
 -   EXYNOS5420_GPIO_A23,
 -   EXYNOS5420_GPIO_A24,
 -   EXYNOS5420_GPIO_A25,
 -   EXYNOS5420_GPIO_A26,
 -   EXYNOS5420_GPIO_A27,
 -   EXYNOS5420_GPIO_B00,/* 24 0x18 */
 -   EXYNOS5420_GPIO_B01,
 -   EXYNOS5420_GPIO_B02,
 -   EXYNOS5420_GPIO_B03,
 -   EXYNOS5420_GPIO_B04,
 -   EXYNOS5420_GPIO_B05,
 -   

Re: [U-Boot] [PATCH 2/5] arm: socfpga: Use only one clrbits_le32 call to deassert SPI reset bits

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 12:46:59, Stefan Roese wrote:
 As suggested by Pavel, lets combine the two calls into one.
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Vince Bridgers vbrid...@altera.com
 Cc: Marek Vasut ma...@denx.de

Acked-by: Pavel Machek pa...@denx.de

 ---
  arch/arm/cpu/armv7/socfpga/reset_manager.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/cpu/armv7/socfpga/reset_manager.c 
 b/arch/arm/cpu/armv7/socfpga/reset_manager.c
 index af9db85..25921e7 100644
 --- a/arch/arm/cpu/armv7/socfpga/reset_manager.c
 +++ b/arch/arm/cpu/armv7/socfpga/reset_manager.c
 @@ -110,6 +110,6 @@ void socfpga_spim_enable(void)
  {
   const void *reset = reset_manager_base-per_mod_reset;
  
 - clrbits_le32(reset, 1  RSTMGR_PERMODRST_SPIM0_LSB);
 - clrbits_le32(reset, 1  RSTMGR_PERMODRST_SPIM1_LSB);
 + clrbits_le32(reset, (1  RSTMGR_PERMODRST_SPIM0_LSB) |
 +  (1  RSTMGR_PERMODRST_SPIM1_LSB));
  }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/5] arm: socfpga: Add missing DW master SPI clock prototyp to clock_manager.h

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 12:47:00, Stefan Roese wrote:
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Vince Bridgers vbrid...@altera.com
 Cc: Marek Vasut ma...@denx.de

Acked-by: Pavel Machek pa...@denx.de

 ---
  arch/arm/include/asm/arch-socfpga/clock_manager.h | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/include/asm/arch-socfpga/clock_manager.h 
 b/arch/arm/include/asm/arch-socfpga/clock_manager.h
 index fa49f6a..5449726 100644
 --- a/arch/arm/include/asm/arch-socfpga/clock_manager.h
 +++ b/arch/arm/include/asm/arch-socfpga/clock_manager.h
 @@ -14,6 +14,7 @@ unsigned long cm_get_sdram_clk_hz(void);
  unsigned int cm_get_l4_sp_clk_hz(void);
  unsigned int cm_get_mmc_controller_clk_hz(void);
  unsigned int cm_get_qspi_controller_clk_hz(void);
 +unsigned int cm_get_spi_controller_clk_hz(void);
  #endif
  
  typedef struct {

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] arm: socfpga: dts: altr, rst-mgr.h: Move to SPDX license identifiers

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 12:46:58, Stefan Roese wrote:
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Vince Bridgers vbrid...@altera.com
 Cc: Marek Vasut ma...@denx.de

Acked-by: Pavel Machek pa...@denx.de

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/5] spi: designware_spi: Some fixes / changes

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 12:47:01, Stefan Roese wrote:
 As suggested by Pavel, here some fixes to the designware SPI driver:
 
 - Spelling fixes
 - Comment for timeout added
 - Removed n_bytes completely (bits_per_word is enough for this)
 - Unput clock now not defined via macro. The function to
   get the clock value is now called directly from within the driver
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Vince Bridgers vbrid...@altera.com
 Cc: Marek Vasut ma...@denx.de

Acked-by: Pavel Machek pa...@denx.de

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/5] arm: socfpga: DW_SPI: Remove clock info from config header

2014-11-16 Thread Pavel Machek
On Sun 2014-11-16 12:47:02, Stefan Roese wrote:
 Remove the now unnecessary clocking info from the SoCFPGA
 config header. As this info in now used directly in the SPI driver
 itself.
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Vince Bridgers vbrid...@altera.com
 Cc: Marek Vasut ma...@denx.de

Acked-by: Pavel Machek pa...@denx.de

Thanks!
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


<    1   2