Re: [U-Boot] [PATCH v9 04/49] dts: Bring in pinctrl device tree binding

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Add this binding file since we now use it in U-Boot.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  .../pinctrl/pinctrl-bindings.txt   | 236 
> +
>  1 file changed, 236 insertions(+)
>  create mode 100644 doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt

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

Re: [U-Boot] [PATCH v9 03/49] dm: pmic: Add 'reg status' to show all regulators

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> It is convenient to be able to see the status of all regulators in a list.
> Add this feature to the 'reg status' command.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  common/cmd_regulator.c | 66 
> ++
>  1 file changed, 56 insertions(+), 10 deletions(-)

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

Re: [U-Boot] [PATCH v9 02/49] dm: pinctrl: Add a function to parse PIN_CONFIG flags

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Add a function which produces a flags word from a few common PIN_CONFIG
> settings. This is useful for simple pinctrl drivers that don't need to worry
> about drive strength, etc.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/pinctrl/pinctrl-uclass.c | 12 
>  include/dm/pinctrl.h | 13 +
>  2 files changed, 25 insertions(+)

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

Re: [U-Boot] [PATCH v9 01/49] dm: core: Don't set pinctrl for pinctrl devices

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> There is sort-of race condition when a pinctrl device is probed. The pinctrl
> function is called which may end up using the same device as is being
> probed. This results in operations being used before the device is actually
> probed.
>
> For now, disallow pinctrl operations on pinctrl devices while probing. An
> alternative solution would be to move the operation to later in the
> device_probe() function (for pinctrl devices only) but this needs more
> thought.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/core/device.c | 6 --

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

Re: [U-Boot] [PATCH v9 12/49] rockchip: Use pwrseq for MMC start-up on jerry

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This is defined in the device tree in Linux. Copy over the settings so that
> this can be used instead of hard-coding the reset line.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/dts/rk3288-veyron.dtsi| 15 +++
>  configs/chromebook_jerry_defconfig |  1 +
>  include/configs/rk3288_common.h|  1 +
>  3 files changed, 13 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v9 05/49] power: Add base support for the RK808 PMIC

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This Rockchip PMIC provides features suitable for battery-powered
> applications. It is commonly used with Rockchip SoCs.
>
> Add a driver which provides register access. The regulator driver will use
> this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/power/pmic/Kconfig  |  9 +
>  drivers/power/pmic/Makefile |  1 +
>  drivers/power/pmic/rk808.c  | 96 
> +
>  include/power/rk808_pmic.h  | 77 
>  4 files changed, 183 insertions(+)
>  create mode 100644 drivers/power/pmic/rk808.c
>  create mode 100644 include/power/rk808_pmic.h

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

Re: [U-Boot] [PATCH v9 08/49] rockchip: Avoid using MMC code when not booting from MMC

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This saves some code space in SPL which is useful on jerry.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v9 07/49] dm: Add a power sequencing uclass

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Some devices need special sequences to be used when starting up. Add a
> uclass for this. Drivers can be added to provide specific features as
> needed.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/misc/Kconfig | 18 ++
>  drivers/misc/Makefile|  1 +
>  drivers/misc/pwrseq-uclass.c | 24 
>  include/dm/uclass-id.h   |  1 +
>  include/pwrseq.h | 18 ++
>  5 files changed, 62 insertions(+)
>  create mode 100644 drivers/misc/pwrseq-uclass.c
>  create mode 100644 include/pwrseq.h

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

Re: [U-Boot] [PATCH v9 13/49] rockchip: jerry: Disable pmic-int-1 setup to avoid a hang

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This hangs when activated (by probing the PMIC). Disable it for now until we
> understand the root cause.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/dts/rk3288-veyron.dtsi | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 14/49] rockchip: Use a separate clock ID for clocks

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> At present we use the same peripheral ID for clocks and pinctrl. While this
> works it is probably better to use the device tree clock binding ID for
> clocks. We can use the clk_get_by_index() function to find this.
>
> Update the clock drivers and the code that uses them.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2:
> - Update call to clk_get_by_index()
>
>  configs/chromebook_jerry_defconfig |  1 +
>  configs/firefly-rk3288_defconfig   |  1 +
>  drivers/clk/clk_rk3036.c   | 16 +-
>  drivers/clk/clk_rk3288.c   | 63 
> +-
>  drivers/mmc/rockchip_dw_mmc.c  | 13 +++-
>  5 files changed, 50 insertions(+), 44 deletions(-)

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

Re: [U-Boot] [PATCH v9 15/49] rockchip: clock: Rename the general clock variable to gclk_rate

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> The current name is confusing and a bit verbose. Rename it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/clk/clk_rk3288.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

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

Re: [U-Boot] [PATCH v9 16/49] rockchip: clk: Add a function to get a peripheral clock rate

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> It is useful to be able to read the rate of a peripheral clock. Add a
> handler for that.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/clk/clk_rk3288.c | 37 +
>  1 file changed, 37 insertions(+)

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

Re: [U-Boot] [PATCH v9 19/49] rockchip: spi: Update the driver to use the new clock ID

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> We can use the new clk_get_by_index() function to get the correct clock.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2:
> - Update call to clk_get_by_index()
>
>  drivers/spi/rk_spi.c | 32 +---
>  1 file changed, 17 insertions(+), 15 deletions(-)

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

Re: [U-Boot] [PATCH v9 20/49] rockchip: spi: Avoid setting the pinctrl twice

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> If full pinctrl is enabled we don't need to manually set the pinctrl in the
> driver. It will happen automatically. Adjust the code to suit - we will
> still use manual mode in SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/spi/rk_spi.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v9 22/49] rockchip: pinctrl: Add a full pinctrl driver

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> We can make use of the device tree to configure pinctrl settings. Add this
> support for the driver so we can use it in U-Boot proper.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/pinctrl/rockchip/pinctrl_rk3288.c | 230 
> +-
>  1 file changed, 229 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 21/49] rockchip: mmc: Update the driver to use the new clock ID

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> We can use the new clk_get_by_index() function to get the correct clock.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/clk/clk_rk3288.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 18/49] rockchip: i2c: Update the driver to use the new clock ID

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> We can use the new clk_get_by_index() function to get the correct clock.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2:
> - Update call to clk_get_by_index()
>
>  drivers/i2c/rk_i2c.c | 38 ++
>  1 file changed, 22 insertions(+), 16 deletions(-)

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

Re: [U-Boot] [PATCH v9 23/49] rockchip: Move firefly and jerry to use the full pinctrl

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Use the full pinctrl driver in U-Boot proper.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  configs/chromebook_jerry_defconfig | 1 -
>  configs/firefly-rk3288_defconfig   | 1 -
>  2 files changed, 2 deletions(-)

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

Re: [U-Boot] [PATCH v9 25/49] rockchip: Disable simple-bus in SPL for firefly-rk3288, jerry

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This is not needed for booting, so drop it from SPL to save about 300 bytes.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  configs/chromebook_jerry_defconfig | 1 +
>  configs/firefly-rk3288_defconfig   | 1 +
>  2 files changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v9 24/49] rockchip: jerry: Enable the RK808 PMIC and regulator

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Enable this PMIC and regulator, which is used on jerry.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  configs/chromebook_jerry_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v9 27/49] gpio: Allow 's' as an abbreviation for 'status'

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> The 'gpio' command allows abbreviations for most subcommands. Allow them
> for 'status' also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  common/cmd_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 31/49] dm: power: Allow regulators to be omitted from SPL

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> For some boards the pmic interface is useful but the regulator interface
> (which comes with it) is too large. Allow them to be separated such that
> SPL can decide which it needs.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/power/pmic/Kconfig   | 21 +
>  drivers/power/pmic/pmic-uclass.c |  2 ++
>  drivers/power/regulator/Kconfig  |  9 +
>  drivers/power/regulator/Makefile |  4 ++--
>  4 files changed, 34 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v9 30/49] spi: Correct device tree usage in spi_flash_decode_fdt()

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This function currently searches the entire device tree for a node that
> it thinks is relevant. But the node is known and is passed in. Correct the
> code and enable it only with driver model, since only driver-model boards
> will use it.
>
> This avoids bringing in a large number of strings from fdtdec.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/mtd/spi/spi_flash.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v9 09/49] rockchip: Convert the PMU IOMUX registers into an array

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This is easier to deal with when using generic code since it allows us to
> use a register index instead of naming each register.
>
> Adjust it, adding an enum to improve readability.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/include/asm/arch-rockchip/pmu_rk3288.h | 12 
>  drivers/pinctrl/rockchip/pinctrl_rk3288.c   |  4 ++--
>  2 files changed, 10 insertions(+), 6 deletions(-)

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

Re: [U-Boot] [PATCH v9 32/49] dm: pinctrl: Add a way for a GPIO driver to obtain a pin function

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> GPIO drivers want to be able to show if a pin is enabled for input, output,
> or is being used by another function. Some drivers can easily find this
> and the code is included in the driver. For some SoCs this is more complex.
> Conceptually this should be handled by pinctrl rather than GPIO. Most
> pinctrl drivers will have this feature anyway.
>
> Add a method by which a GPIO driver can obtain the pin mux value given a
> GPIO reference. This avoids repeating the code in two places.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/pinctrl/pinctrl-uclass.c | 10 ++
>  include/dm/pinctrl.h | 32 
>  2 files changed, 42 insertions(+)

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

Re: [U-Boot] [PATCH v9 28/49] cros_ec: Disable the Chrome OS EC in SPL

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This is not used in SPL so don't allow it to be built there, even if I2C
> is enabled in SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/misc/Makefile | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v9 10/49] rockchip: mmc: Use a pwrseq device if available

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Use the pwrseq uclass to find a suitable power sequence for the MMC device.
> If this is enabled in the device tree, we will pick it up automatically.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/mmc/rockchip_dw_mmc.c | 47 
> +++
>  1 file changed, 47 insertions(+)

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

Re: [U-Boot] [PATCH v9 06/49] power: Add support for RK808 regulators

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> Add regulator support for the RK808 PMIC. It integrated 4 BUCKs and 8 LDOs
> all of which are supported by this driver.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/power/regulator/Kconfig  |   9 ++
>  drivers/power/regulator/Makefile |   1 +
>  drivers/power/regulator/rk808.c  | 301 
> +++
>  3 files changed, 311 insertions(+)
>  create mode 100644 drivers/power/regulator/rk808.c

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

Re: [U-Boot] [PATCH v9 26/49] rockchip: jerry: Drop unused options

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> To reduce the SPL image size, drop the LED features. Jerry does not have
> an LED and we can leave out GPIO support also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  configs/chromebook_jerry_defconfig | 5 -
>  include/configs/chromebook_jerry.h | 2 ++
>  2 files changed, 2 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH v9 33/49] dm: core: Export uclass_find_device_by_of_offset()

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> It is sometimes useful to be able to find a device before probing it,
> perhaps to set up some platform data for it. Allow finding by of_offset
> also.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/core/uclass.c|  4 ++--
>  include/dm/uclass-internal.h | 16 
>  2 files changed, 18 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v9 29/49] dm: i2c: Allow muxes to be enabled for SPL separately

[Simon Glass]

On 21 January 2016 at 22:32, Heiko Schocher  wrote:
> Hello Simon,
>
> Am 22.01.2016 um 03:43 schrieb Simon Glass:
>>
>> Since I2C muxes are seldom needed in SPL, and the code for this increases
>> the size somewhat, add a separate option to enable I2C muxes for SPL.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v9: None
>> Changes in v2: None
>>
>>   drivers/i2c/Makefile   | 4 ++--
>>   drivers/i2c/muxes/Kconfig  | 9 +
>>   drivers/i2c/muxes/Makefile | 2 +-
>>   3 files changed, 12 insertions(+), 3 deletions(-)
>
>
> Thanks!
>
> Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v9 39/49] rockchip: spi: Remember the last speed to avoid re-setting it

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Rather than changing the clock to the same value on every transaction,
> remember the last value and don't adjust the clock unless it is necessary.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/spi/rk_spi.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 34/49] dm: power: Tidy up debugging output and return values

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> The currect PMIC debugging is a little confusing. Adjust it so that it is
> clear whether the operation succeeded or failed. Also, avoid creating a new
> error return value when a perfectly good one is already available.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/power/pmic/pmic-uclass.c   | 11 ---
>  drivers/power/pmic/rk808.c | 14 ++
>  drivers/power/regulator/regulator-uclass.c |  2 +-
>  3 files changed, 19 insertions(+), 8 deletions(-)

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

Re: [U-Boot] [PATCH v9 38/49] rockchip: reset: Use the rk_clr/setreg() interface

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Use this function in preference to the macro.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/mach-rockchip/rk3288/reset_rk3288.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v9 36/49] dm: clk: Add a simple version of clk_get_by_index()

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> This function adds quite a bit of code to SPL and we probably don't need
> all the features in SPL. Add a simple version (for SPL only) to save space.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2:
> - Add an assert for clk_devp
>
>  drivers/clk/clk-uclass.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 37/49] rockchip: sdram: Use the rk_clr/setreg() interface

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Use this function in preference to the macro.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v9 42/49] rockchip: pinctrl: Reduce the size for SPL

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> This file has many features that are not needed by SPL. Use #ifdef to
> remove the unused features and reduce the code size.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/pinctrl/rockchip/pinctrl_rk3288.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH v9 41/49] rockchip: clk: Make rkclk_get_clk() SoC-specific

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> The current method assumes that clocks are numbered from 0 and we can
> determine a clock by its number. It is safer to use an ID in the clock's
> platform data to avoid the situation where another clock is bound before
> the one we expect.
>
> Move the existing code into rk3036 since it still works there. Add a new
> implementation for rk3288.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/mach-rockchip/Makefile |  1 -
>  arch/arm/mach-rockchip/common.c | 28 
>  drivers/clk/clk_rk3036.c| 17 +
>  drivers/clk/clk_rk3288.c| 13 +
>  4 files changed, 30 insertions(+), 29 deletions(-)
>  delete mode 100644 arch/arm/mach-rockchip/common.c

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

Re: [U-Boot] [PATCH v9 40/49] rockchip: spi: Correct the bus init code

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Two of the init values are created locally so cannot be out of range.
> The masking is unnecessary and in one case is incorrect. Fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/spi/rk_spi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v9 17/49] rockchip: clock: Add a function to find a clock by ID

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> The current approach of using uclass_get_device() is error-prone. Another
> clock (for example a fixed-clock) may cause it to break. Add a function that
> does a proper search.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  arch/arm/include/asm/arch-rockchip/clock.h | 12 
>  drivers/clk/clk_rk3288.c   | 24 ++--
>  2 files changed, 34 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH v9 43/49] rockchip: pinctrl: Implement the get_gpio_mux() method

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Implement this so that the GPIO command will be able to report whether a
> GPIO is used for input or output.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/pinctrl/rockchip/pinctrl_rk3288.c | 68 
> +++
>  1 file changed, 52 insertions(+), 16 deletions(-)

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

Re: [U-Boot] [PATCH v9 44/49] rockchip: gpio: Read the GPIO value correctly

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> This function should return 0 or 1, not a mask. Fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/gpio/rk_gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 46/49] rockchip: spi: Implement the delays

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Some devices need delays before and after activiation. Implement these
> features in the SPI driver so that we will be able to enable the Chrome
> OS EC.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/spi/rk_spi.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v9 47/49] rockchip: spi: Correct chip-enable code

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> At present there is an incorrect call to rkspi_enable_chip(). It should
> be disabling the chip, not enabling it. Correct this and ensure that the
> chip is disabled when releasing the bus.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  drivers/spi/rk_spi.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v9 11/49] rockchip: Correct the defconfig order

[Simon Glass]

On 21 January 2016 at 19:43, Simon Glass  wrote:
> This has got out of sequence somehow. Fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9: None
> Changes in v2: None
>
>  configs/chromebook_jerry_defconfig | 6 +++---
>  configs/firefly-rk3288_defconfig   | 4 ++--
>  2 files changed, 5 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH v9 49/49] rockchip: jerry: Enable the Chrome OS EC

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Turn on the EC and enable the keyboard.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v9:
> - Rebase to upstream/master
>
> Changes in v2: None
>
>  arch/arm/dts/rk3288-veyron-chromebook.dtsi | 4 
>  configs/chromebook_jerry_defconfig | 8 
>  include/configs/chromebook_jerry.h | 7 +++
>  include/configs/firefly-rk3288.h   | 2 ++
>  include/configs/rk3288_common.h| 7 +++
>  5 files changed, 28 insertions(+)

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

Re: [U-Boot] [RFC PATCH v1] kirkwood_nand: claim MPP pins on the fly

[Scott Wood]

On Fri, 2016-01-15 at 17:22 +1300, Chris Packham wrote:
> Claim the MPP pins for the NAND flash controller only when it's actually
> being used. This allows the pins to be shared with the SPI interface
> which already supports an equivalent on-access MPP reconfiguration.
> 
> Reviewed-by: Mark Tomlinson 
> Signed-off-by: Chris Packham 
> ---
> I haven't wrapped this with a configuration option because I think it
> should be safe to enable by default. It will either re-apply the same
> MPP configuration that has already been done in the board init or put
> the MPP pins into the correct mode to access NAND.
> 
> I've only got access to one kirkwood based board with NAND flash so I'd
> appreciate some feedback from someone with access to a few different
> boards.
> 
> From the datasheets I have access to it looks like there is only one
> possible MPP configuration for NF_IO[0-7] so that is what I've
> implemented. I'm not aware of anything using this driver that needs a
> different MPP config.
> 
>  drivers/mtd/nand/kirkwood_nand.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/mtd/nand/kirkwood_nand.c
> b/drivers/mtd/nand/kirkwood_nand.c
> index 4fc34d6..ff81212 100644
> --- a/drivers/mtd/nand/kirkwood_nand.c
> +++ b/drivers/mtd/nand/kirkwood_nand.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /* NAND Flash Soc registers */
> @@ -22,6 +23,8 @@ struct kwnandf_registers {
>  static struct kwnandf_registers *nf_reg =
>   (struct kwnandf_registers *)KW_NANDF_BASE;
>  
> +static u32 nand_mpp_backup[9] = { 0 };

There's a non-static nand_mpp_backup[] in drivers/spi/kirkwood_spi.c, with a
different length.  And the length assumed by kirkwood_mpp_conf seems to be
different still (and larger than the spi array).

> +
>  /*
>   * hardware specific access to control-lines/bits
>   */
> @@ -49,6 +52,22 @@ static void kw_nand_hwcontrol(struct mtd_info *mtd, int
> cmd,
>  void kw_nand_select_chip(struct mtd_info *mtd, int chip)
>  {
>   u32 data;
> + u32 nand_config[] = {
> + MPP0_NF_IO2,
> + MPP1_NF_IO3,
> + MPP2_NF_IO4,
> + MPP3_NF_IO5,
> + MPP4_NF_IO6,
> + MPP5_NF_IO7,
> + MPP18_NF_IO0,
> + MPP19_NF_IO1,
> + 0
> + };

If you make this static const the compiler won't need to create the table at
runtime.

-Scott

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

Re: [U-Boot] [PATCH v2 3/8] drivers: net: keystone_net: convert driver to adopt device driver model

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> Adopt keystone_net driver to adopt device driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  drivers/net/keystone_net.c | 418 
> -
>  1 file changed, 376 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/net/keystone_net.c b/drivers/net/keystone_net.c
> index 209fae9..21ebaeb 100644
> --- a/drivers/net/keystone_net.c
> +++ b/drivers/net/keystone_net.c
> @@ -10,6 +10,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -18,10 +20,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
> +#ifndef CONFIG_DM_ETH
>  unsigned int emac_open;
>  static struct mii_dev *mdio_bus;
>  static unsigned int sys_has_mdio = 1;
> +#endif
>
>  #ifdef KEYSTONE2_EMAC_GIG_ENABLE
>  #define emac_gigabit_enable(x) keystone2_eth_gigabit_enable(x)
> @@ -36,40 +43,44 @@ static unsigned int sys_has_mdio = 1;
>
>  static u8 rx_buffs[RX_BUFF_NUMS * RX_BUFF_LEN] __aligned(16);
>
> +#ifndef CONFIG_DM_ETH
>  struct rx_buff_desc net_rx_buffs = {
> .buff_ptr   = rx_buffs,
> .num_buffs  = RX_BUFF_NUMS,
> .buff_len   = RX_BUFF_LEN,
> .rx_flow= 22,
>  };
> -
> -#ifndef CONFIG_SOC_K2G
> -static void keystone2_net_serdes_setup(void);
>  #endif
>
> -int keystone2_eth_read_mac_addr(struct eth_device *dev)
> -{
> -   struct eth_priv_t *eth_priv;
> -   u32 maca = 0;
> -   u32 macb = 0;
> -
> -   eth_priv = (struct eth_priv_t *)dev->priv;
> +#ifdef CONFIG_DM_ETH
>
> -   /* Read the e-fuse mac address */
> -   if (eth_priv->slave_port == 1) {
> -   maca = __raw_readl(MAC_ID_BASE_ADDR);
> -   macb = __raw_readl(MAC_ID_BASE_ADDR + 4);
> -   }
> -
> -   dev->enetaddr[0] = (macb >>  8) & 0xff;
> -   dev->enetaddr[1] = (macb >>  0) & 0xff;
> -   dev->enetaddr[2] = (maca >> 24) & 0xff;
> -   dev->enetaddr[3] = (maca >> 16) & 0xff;
> -   dev->enetaddr[4] = (maca >>  8) & 0xff;
> -   dev->enetaddr[5] = (maca >>  0) & 0xff;
> +enum link_type {
> +   LINK_TYPE_MAC_TO_MAC_AUTO = 0,
> +   LINK_TYPE_MAC_TO_PHY_MODE = 1,
> +   LINK_TYPE_MAC_TO_MAC_FORCED_MODE = 2,
> +   LINK_TYPE_MAC_TO_FIBRE_MODE = 3,
> +   LINK_TYPE_MAC_TO_PHY_NO_MDIO_MODE = 4,
> +   LINK_TYPE_10G_MAC_TO_PHY_MODE = 10,
> +   LINK_TYPE_10G_MAC_TO_MAC_FORCED_MODE = 11,
> +};
>
> -   return 0;
> -}
> +struct ks2_eth_priv {
> +   struct udevice  *dev;
> +   struct phy_device   *phydev;
> +   struct mii_dev  *mdio_bus;
> +   int phy_addr;
> +   phy_interface_t phy_if;
> +   int sgmii_link_type;
> +   void*mdio_base;
> +   struct rx_buff_desc net_rx_buffs;
> +   struct pktdma_cfg   *netcp_pktdma;
> +   void*hd;
> +   int slave_port;
> +   enum link_type  link_type;
> +   boolemac_open;
> +   boolhas_mdio;
> +};
> +#endif
>
>  /* MDIO */
>
> @@ -140,6 +151,7 @@ static int keystone2_mdio_write(struct mii_dev *bus,
> return 0;
>  }
>
> +#ifndef CONFIG_DM_ETH
>  static void  __attribute__((unused))
> keystone2_eth_gigabit_enable(struct eth_device *dev)
>  {
> @@ -163,6 +175,31 @@ static void  __attribute__((unused))
>EMAC_MACCONTROL_GIGFORCE | EMAC_MACCONTROL_GIGABIT_ENABLE,
>DEVICE_EMACSL_BASE(eth_priv->slave_port - 1) + 
> CPGMACSL_REG_CTL);
>  }
> +#else
> +static void  __attribute__((unused))
> +   keystone2_eth_gigabit_enable(struct udevice *dev)
> +{
> +   struct ks2_eth_priv *priv = dev_get_priv(dev);
> +   u_int16_t data;
> +
> +   if (priv->has_mdio) {
> +   data = keystone2_mdio_read(priv->mdio_bus, priv->phy_addr,
> +  MDIO_DEVAD_NONE, 0);
> +   /* speed selection MSB */
> +   if (!(data & (1 << 6)))
> +   return;
> +   }
> +
> +   /*
> +* Check if link detected is giga-bit
> +* If Gigabit mode detected, enable gigbit in MAC
> +*/
> +   writel(readl(DEVICE_EMACSL_BASE(priv->slave_port - 1) +
> +CPGMACSL_REG_CTL) |
> +  EMAC_MACCONTROL_GIGFORCE | EMAC_MACCONTROL_GIGABIT_ENABLE,
> +  DEVICE_EMACSL_BASE(priv->slave_port - 1) + CPGMACSL_REG_CTL);
> +}
> +#endif
>
>  #ifdef CONFIG_SOC_K2G
>  int keystone_rgmii_config(struct phy_device *phy_dev)
> @@ -401,6 +438,58 @@ int ethss_stop(void)
> return 0;
>  }
>
> +struct ks2_serdes ks2_serdes_sgmii_156p25mhz = {
> +   .clk = 

Re: [U-Boot] [PATCH v2 4/8] defconfig: k2hk_evm_defconfig: enable net driver model

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> enable net driver model for k2hk evm as keystone_net supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 

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 5/8] defconfig: k2l_evm_defconfig: enable net driver model

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> enable net driver model for k2l evm as keystone_net supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[Scott Wood]

On Fri, 2016-01-22 at 20:18 +, york sun wrote:
> On 01/22/2016 12:14 PM, Bhupesh Sharma wrote:
> > 
> > 
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Saturday, January 23, 2016 1:39 AM
> > > To: york sun; Zhiqiang Hou; u-boot@lists.denx.de;
> > > albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
> > > le...@freescale.com; prabha...@freescale.com;
> > > bhupesh.sha...@freescale.com; Zhiqiang Hou
> > > Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
> > > 
> > > On Fri, 2016-01-22 at 20:05 +, york sun wrote:
> > > > On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
> > > > > From: Hou Zhiqiang 
> > > > > 
> > > > > The FSL Primary Protected Application (PPA) is a software component
> > > > > loaded during boot which runs in TrustZone and remains resident
> > > > > after boot.
> > > > > 
> > > > > Signed-off-by: Hou Zhiqiang 
> > > > > ---
> > > > > Tested on LS1043A RDB board
> > > > > 
> > > > 
> > > > I presume PSCI is implemented in PPA. How does the SMP boot flow
> > > > change with PPA? U-boot has to remain functional in the absence of
> > > > PPA,
> > > right?
> > > > 
> > > > Would it be possible to write a readme for PPA?
> > > 
> > > Also, how does the devicetree get updated to indicate the presence of
> > > PSCI?
> > > 
> > 
> > One needs to add PSCI node in the DTS for the same, claiming support for
> > PSCI specification.
> > The cpu.enable_method needs to be changed from spin-table to psci as well.
> > 
> > See http://lxr.free-electrons.com/source/Documentation/devicetree/bindings
> > /arm/psci.txt for details.
> > 
> 
> Bhupesh,
> 
> Before PPA is fully adopted, u-boot has to detect the existence of PPA and
> decide to use PSCI or spin table, right? So the device tree node should also
> be
> fixed accordingly.

How would U-Boot know what version of PSCI the loaded PPA supports?  Is or
could there be any metadata on the PPA image to convey such information?

-Scott

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[york sun]

On 01/22/2016 12:27 PM, Bhupesh Sharma wrote:
> 
> 
>> -Original Message-
>> From: Scott Wood [mailto:o...@buserror.net]
>> Sent: Saturday, January 23, 2016 1:52 AM
>> To: york sun; Bhupesh Sharma; Zhiqiang Hou; u-boot@lists.denx.de;
>> albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
>> le...@freescale.com; prabha...@freescale.com;
>> bhupesh.sha...@freescale.com; Zhiqiang Hou
>> Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
>>
>> On Fri, 2016-01-22 at 20:18 +, york sun wrote:
>>> On 01/22/2016 12:14 PM, Bhupesh Sharma wrote:


> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Saturday, January 23, 2016 1:39 AM
> To: york sun; Zhiqiang Hou; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
> le...@freescale.com; prabha...@freescale.com;
> bhupesh.sha...@freescale.com; Zhiqiang Hou
> Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
>
> On Fri, 2016-01-22 at 20:05 +, york sun wrote:
>> On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
>>> From: Hou Zhiqiang 
>>>
>>> The FSL Primary Protected Application (PPA) is a software
>>> component loaded during boot which runs in TrustZone and
>>> remains resident after boot.
>>>
>>> Signed-off-by: Hou Zhiqiang 
>>> ---
>>> Tested on LS1043A RDB board
>>>
>>
>> I presume PSCI is implemented in PPA. How does the SMP boot flow
>> change with PPA? U-boot has to remain functional in the absence
>> of PPA,
> right?
>>
>> Would it be possible to write a readme for PPA?
>
> Also, how does the devicetree get updated to indicate the presence
> of PSCI?
>

 One needs to add PSCI node in the DTS for the same, claiming support
 for PSCI specification.
 The cpu.enable_method needs to be changed from spin-table to psci as
>> well.

 See
 http://lxr.free-electrons.com/source/Documentation/devicetree/bindin
 gs
 /arm/psci.txt for details.

>>>
>>> Bhupesh,
>>>
>>> Before PPA is fully adopted, u-boot has to detect the existence of PPA
>>> and decide to use PSCI or spin table, right? So the device tree node
>>> should also be fixed accordingly.
> 
> A static CONFIG_ flag is used for enabling the PPA support currently in 
> QorIQ-LS u-boot code.

Not enough. The driver parse PPA image and gives up if it is not a valid image.
Before we have a way to deploy PPA image to all our customers, we need to keep
both options open.

York

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

Re: [U-Boot] [PATCH 1/2] net: Add bootfile in DHCP Request

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:08 PM, MESSIER, ALEXANDRE
 wrote:
>> -Original Message-
>> From: Joe Hershberger [mailto:joe.hershber...@gmail.com]
>> Sent: January-22-16 2:35 PM
>> To: amessier.t...@gmail.com
>> Cc: u-boot; Joe Hershberger; MESSIER, ALEXANDRE
>> Subject: Re: [U-Boot] [PATCH 1/2] net: Add bootfile in DHCP Request
>>
>> On Fri, Jan 22, 2016 at 1:22 PM,   wrote:
>> > From: Alexandre Messier 
>> >
>> > Add the bootfile name in the DHCP Request packet, in addition
>> > to it already being sent in the DHCP Discover.
>> >
>> > This is needed by some DHCP servers so that the bootfile name is
>> > properly returned by the server to the client in the DHCP Ack, as
>> > expected by U-Boot.
>> >
>> > Signed-off-by: Alexandre Messier 
>> > ---
>> >  README  | 5 +
>> >  net/bootp.c | 3 +++
>> >  2 files changed, 8 insertions(+)
>> >
>> > diff --git a/README b/README
>> > index 0dc657d..05966ab 100644
>> > --- a/README
>> > +++ b/README
>> > @@ -2191,6 +2191,7 @@ CBFS (Coreboot Filesystem) support
>> > CONFIG_BOOTP_TIMEOFFSET
>> > CONFIG_BOOTP_VENDOREX
>> > CONFIG_BOOTP_MAY_FAIL
>> > +   CONFIG_BOOTP_DHCPREQ_BOOTFILE
>> >
>> > CONFIG_BOOTP_SERVERIP - TFTP server will be the serverip
>> > environment variable, not the BOOTP server.
>> > @@ -2231,6 +2232,10 @@ CBFS (Coreboot Filesystem) support
>> > the DHCP timeout and retry process takes a longer than
>> > this delay.
>> >
>> > +   CONFIG_BOOTP_DHCPREQ_BOOTFILE - Set the bootfile name in
>> > +   DHCPREQUEST packet, in addition to DHCPDISCOVER. This may 
>> > be
>> > +   needed by some DHCP servers in specific cases.
>> > +
>> >   - Link-local IP address negotiation:
>> > Negotiate with other link-local clients on the local 
>> > network
>> > for an address that doesn't require explicit configuration.
>> > diff --git a/net/bootp.c b/net/bootp.c
>> > index b2f8ad4..8da94cf 100644
>> > --- a/net/bootp.c
>> > +++ b/net/bootp.c
>> > @@ -918,6 +918,9 @@ static void dhcp_send_request_packet(struct
>> bootp_hdr *bp_offer)
>> > net_write_ip(>bp_giaddr, zero_ip);
>> >
>> > memcpy(bp->bp_chaddr, net_ethaddr, 6);
>> > +#if defined(CONFIG_BOOTP_DHCPREQ_BOOTFILE)
>>
>> Does it hurt anything to send this in all cases? Does it really need a
>> config option to hide it?
>
> It is done this way to be sure not to impact anyone, in case someone has
> a DHCP server that does not handle the bootfile in the request properly.
>
> It works for us, but we don't have any way to test it more exhaustively.
> If anyone can test and/or confirm it does not impact anything, the config
> option can be removed.

I think if we just add it always and wait for someone to complain that
it can't work for them. If that happens, then we can add a config.

> In the other case, if we keep the option, I'll have to send an update to
> add it to kconfig.
>
>>
>> > +   copy_filename(bp->bp_file, net_boot_file_name, sizeof(bp-
>> >bp_file));
>> > +#endif
>> >
>> > /*
>> >  * ID is the id of the OFFER packet
>> > --
>> > 1.8.3.1
>> >
>> > ___
>> > U-Boot mailing list
>> > U-Boot@lists.denx.de
>> > https://urldefense.proofpoint.com/v2/url?u=http-
>> 3A__lists.denx.de_mailman_listinfo_u-2Dboot=CwIBaQ=0YGvTs3tT-
>> VMy8_v51yLDw=adEdfGeVvAp5D3jUKeOClnVoZZOSb93LtGg4Qgmpmjw&
>> m=CpBoSRS4ye1cP9RQb3QmksXKDd30VxXxno2acTLjzAA=i14g-1S2h7qY-
>> RuR6rb8Jot80682EPbPqx-NRB3pUaE=
>
> 
>
> This e-mail contains privileged and confidential information intended for the 
> use of the addressees named above. If you are not the intended recipient of 
> this e-mail, you are hereby notified that you must not disseminate, copy or 
> take any action in respect of any information contained in it. If you have 
> received this e-mail in error, please notify the sender immediately by e-mail 
> and immediately destroy this e-mail and its attachments.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V2 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[Scott Wood]

On Fri, 2016-01-22 at 20:07 +0800, Gong Qianyu wrote:
> Both Freescale Layerscape and powerpc/mpc85xx platforms are using
> fdt_fixup_fman_firmware() to insert Fman ucode blob into the device
> tree. So move it to driver code.
> 
> Signed-off-by: Gong Qianyu 
> ---
> V2:
>  - New patch.
>  
>  arch/powerpc/cpu/mpc85xx/cpu_init.c |   2 +-
>  arch/powerpc/cpu/mpc85xx/fdt.c  | 125 ++---
> --
>  board/freescale/common/arm_sleep.c  |   2 +-
>  board/freescale/common/mpc85xx_sleep.c  |   2 +-
>  board/freescale/ls1021aqds/ls1021aqds.c |   2 +-
>  board/freescale/ls1021atwr/ls1021atwr.c |   2 +-
>  drivers/net/fm/Makefile |   1 +
>  drivers/net/fm/fdt.c| 129
> 
>  include/fsl_fman.h  |   1 +
>  9 files changed, 141 insertions(+), 125 deletions(-)

Use -M -C with git format-patch so we can see what (if anything) changed
during the move.

-Scott

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

Re: [U-Boot] [PATCH V2 3/8] test/py: drain console log at the end of any failed test

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Tests may fail for a number of reasons, and in particular for reasons
> other than a timeout waiting for U-Boot to print expected data. If the
> last operation that a failed test performs is not waiting for U-Boot to
> print something, then any trailing output from U-Boot during that test's
> operation will not be logged as part of that test, but rather either
> along with the next test, or even thrown away, potentiall hiding clues
> re: the test failure reason.
>
> Solve this by explicitly draining (and hence logging) the U-Boot output
> in the case of failed tests.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
>  test/py/conftest.py|  1 +
>  test/py/u_boot_console_base.py | 38 ++
>  2 files changed, 39 insertions(+)

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

Re: [U-Boot] [PATCH V2 1/8] test/py: fix timeout to be absolute

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Currently, Spawn.expect() imposes its timeout solely upon receipt of new
> data, not on its overall operation. In theory, this could cause the
> timeout not to fire if U-Boot continually generated output that did not
> match the expected patterns.
>
> Fix the code to additionally impose a timeout on overall operation, which
> is the intended mode of operation.
>
> Signed-off-by: Stephen Warren 
> Reviewed-by: Lukasz Majewski 
> Acked-by: Simon Glass 
> ---
>  test/py/u_boot_spawn.py | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH V2 7/8] test/py: ums: add filesystem-based testing

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Enhance the UMS test to optionally mount a partition and read/write a file
> to it, validating that the content written and read back are identical.
>
> This enhancement is backwards-compatible; old boardenv contents that don't
> define the new configuration data will cause the test code to perform as
> before.
>
> test/ums/ is deleted since the Python test now performs the same testing
> that it did.
>
> The code is also re-written to make use of the recently added utility
> module, and split it up into nested functions so the overall logic of
> the test process can be followed more easily without the details
> cluttering the code.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Lukasz Majewski 
> Acked-by: Simon Glass 
> ---
> v2: Fix file-level and function-level comment to describe the enhanced
> test more fully.
> ---
>  test/py/tests/test_ums.py   | 236 
> +++-
>  test/ums/README |  30 --
>  test/ums/ums_gadget_test.sh | 183 --
>  3 files changed, 188 insertions(+), 261 deletions(-)
>  delete mode 100644 test/ums/README
>  delete mode 100755 test/ums/ums_gadget_test.sh

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

[U-Boot] Please pull u-boot-rockchip

[Simon Glass]

Hi Tom,

This includes some kylin improvements for Android booting, support for
a new Rockchip board (Rock 2), Rockchip display support using eDP and
HDMI with the new driver-model video uclass, and Chrome OS EC support
for Jerry.


The following changes since commit 6905f4d3c7be46fed4859f51f0a8f9a1107c22e7:

  Merge git://git.denx.de/u-boot-dm (2016-01-21 11:49:49 -0500)

are available in the git repository at:

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

for you to fetch changes up to f138713073b5587b195cb73e12394e57c15cbb01:

  rockchip: Update the README (2016-01-21 20:42:37 -0700)


Jeffy Chen (5):
  ARM: bootm: Try to use relocated ramdisk
  rockchip: rk3036: Bind GPIO banks
  rockchip: kylin: Add default gpt partition table
  rockchip: kylin: Check fastboot request
  rockchip: kylin: Store env in emmc

Masahiro Yamada (1):
  clk: add fixed rate clock driver

Simon Glass (87):
  dm: clk: Add support for decoding clocks from the device tree
  dm: core: Don't set pinctrl for pinctrl devices
  dm: pinctrl: Add a function to parse PIN_CONFIG flags
  dm: pmic: Add 'reg status' to show all regulators
  dts: Bring in pinctrl device tree binding
  power: Add base support for the RK808 PMIC
  power: Add support for RK808 regulators
  dm: Add a power sequencing uclass
  rockchip: Avoid using MMC code when not booting from MMC
  rockchip: Convert the PMU IOMUX registers into an array
  rockchip: mmc: Use a pwrseq device if available
  rockchip: Correct the defconfig order
  rockchip: Use pwrseq for MMC start-up on jerry
  rockchip: jerry: Disable pmic-int-1 setup to avoid a hang
  rockchip: Use a separate clock ID for clocks
  rockchip: clock: Rename the general clock variable to gclk_rate
  rockchip: clk: Add a function to get a peripheral clock rate
  rockchip: clock: Add a function to find a clock by ID
  rockchip: i2c: Update the driver to use the new clock ID
  rockchip: spi: Update the driver to use the new clock ID
  rockchip: spi: Avoid setting the pinctrl twice
  rockchip: mmc: Update the driver to use the new clock ID
  rockchip: pinctrl: Add a full pinctrl driver
  rockchip: Move firefly and jerry to use the full pinctrl
  rockchip: jerry: Enable the RK808 PMIC and regulator
  rockchip: Disable simple-bus in SPL for firefly-rk3288, jerry
  rockchip: jerry: Drop unused options
  gpio: Allow 's' as an abbreviation for 'status'
  cros_ec: Disable the Chrome OS EC in SPL
  dm: i2c: Allow muxes to be enabled for SPL separately
  spi: Correct device tree usage in spi_flash_decode_fdt()
  dm: power: Allow regulators to be omitted from SPL
  dm: pinctrl: Add a way for a GPIO driver to obtain a pin function
  dm: core: Export uclass_find_device_by_of_offset()
  dm: power: Tidy up debugging output and return values
  dm: power: Allow regulators to not implement all operations
  dm: clk: Add a simple version of clk_get_by_index()
  rockchip: sdram: Use the rk_clr/setreg() interface
  rockchip: reset: Use the rk_clr/setreg() interface
  rockchip: spi: Remember the last speed to avoid re-setting it
  rockchip: spi: Correct the bus init code
  rockchip: clk: Make rkclk_get_clk() SoC-specific
  rockchip: pinctrl: Reduce the size for SPL
  rockchip: pinctrl: Implement the get_gpio_mux() method
  rockchip: gpio: Read the GPIO value correctly
  rockchip: gpio: Implement the get_function() method
  rockchip: spi: Implement the delays
  rockchip: spi: Correct chip-enable code
  rockchip: spi: Remove the explicit pinctrl setting
  rockchip: jerry: Enable the Chrome OS EC
  stdio: Correct a build error with driver model
  gpio: Warn about invalid GPIOs used with the 'gpio' command
  video: Name consoles by their number
  video: Add a function to control cache flushing
  video: bridge: Allow GPIOs to be optional
  dm: pwm: Add a PWM uclass
  pwm: rockchip: Add a PWM driver for Rockchip SoCs
  dm: backlight: Add a backlight uclass
  dm: backlight: Add a driver for a PWM backlight
  dm: panel: Add a panel uclass
  video: panel: Add a simple panel driver
  dm: video: Repurpose the 'displayport' uclass to 'display'
  rockchip: Rename the CRU_MODE_CON fields
  rockchip: clk: Add support for clocks needed by the displays
  rockchip: video: Add a display driver for rockchip HDMI
  rockchip: video: Add a display driver for rockchip eDP
  rockchip: video: Add a video-output driver
  rockchip: Don't skip low-level init
  rockchip: Add a simple 'clock' command
  rockchip: Add a script to parse datasheets
  rockchip: config: Enable the 'gpio' command
  rockchip: sdram: Tidy up a few comments
  rockchip: sdram: Use syscon_get_first_range() where possible
  

Re: [U-Boot] [PATCH V2 2/8] test/py: move U-Boot respawn trigger to the test core

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Prior to this change, U-Boot was lazilly (re-)spawned if/when a test
> attempted to interact with it, and no active connection existed. This
> approach was simple, yet had the disadvantage that U-Boot might be
> spawned in the middle of a test function, e.g. after the test had already
> performed actions such as creating data files, etc. In that case, this
> could cause the log to contain the sequence (1) some test logs, (2)
> U-Boot's boot process, (3) the rest of that test's logs. This isn't
> optimally readable. This issue will affect the upcoming DFU and enhanced
> UMS tests.
>
> This change converts u_boot_console to be a function-scoped fixture, so
> that pytest attempts to re-create the object for each test invocation.
> This allows the fixture factory function to ensure that U-Boot is spawned
> prior to every test. In practice, the same object is returned each time
> so there is essentially no additional overhead due to this change.
>
> This allows us to remove:
>
> - The explicit ensure_spawned() call from test_sleep, since the core now
> ensures that the spawn happens before the test code is executed.
>
> - The laxy calls to ensure_spawned() in the u_boot_console_*
> implementations.
>
> The one downside is that test_env's "state_ttest_env" fixture must be
> converted to a function-scoped fixture too, since a module-scoped fixture
> cannot use a function-scoped fixture. To avoid overhead, we use the same
> trick of returning the same object each time.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
>  test/py/conftest.py| 3 ++-
>  test/py/tests/test_env.py  | 8 ++--
>  test/py/tests/test_sandbox_exit.py | 2 --
>  test/py/tests/test_sleep.py| 4 
>  test/py/u_boot_console_base.py | 2 --
>  test/py/u_boot_console_sandbox.py  | 1 -
>  6 files changed, 8 insertions(+), 12 deletions(-)

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

Re: [U-Boot] [PATCH V2 6/8] test/py: add various utility code

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Add various common utility functions. These will be used by a forthcoming
> re-written UMS test, and a brand-new DFU test.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
>  test/py/u_boot_console_base.py |  19 +
>  test/py/u_boot_utils.py| 171 
> +
>  2 files changed, 190 insertions(+)
>  create mode 100644 test/py/u_boot_utils.py

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

Re: [U-Boot] [PATCH V2 8/8] test/py: add DFU test

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Add a test of DFU functionality to the Python test suite. The test
> starts DFU in U-Boot, waits for USB device enumeration on the host,
> executes dfu-util multiple times to test various transfer sizes, many
> of which trigger USB driver edge cases, and finally aborts the DFU
> command in U-Boot.
>
> This test mirrors the functionality previously available via the shell
> scripts in test/dfu, and hence those are removed too.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Lukasz Majewski 
> Acked-by: Simon Glass 
> ---
> v2: Fix file comment to refer to "dfu" not "ums", and be generally more
> descriptive.
> ---
>  test/dfu/README  |  44 ---
>  test/dfu/dfu_gadget_test.sh  | 108 
>  test/dfu/dfu_gadget_test_init.sh |  45 ---
>  test/py/tests/test_dfu.py| 262 
> +++
>  4 files changed, 262 insertions(+), 197 deletions(-)
>  delete mode 100644 test/dfu/README
>  delete mode 100755 test/dfu/dfu_gadget_test.sh
>  delete mode 100755 test/dfu/dfu_gadget_test_init.sh
>  create mode 100644 test/py/tests/test_dfu.py

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

Re: [U-Boot] [PATCH V2 5/8] test/py: optionally ignore errors from shell commands

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Sometimes it's useful to run shell commands and ignore any errors. One
> example might be cleanup logic; if a test-case experiences an error, the
> cleanup logic might experience an error too, and we don't want that error
> to mask the original error, so we want to ignore the subsequent error.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
>  test/py/multiplexed_log.py | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH V2 4/8] test/py: log when tests send CTRL-C

[Simon Glass]

On 22 January 2016 at 12:30, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Write a note to the log file when a test sends CTRL-C to U-Boot. This
> makes it easier to follow what's happening in the logs, especially since
> U-Boot doesn't echo the character back to its output, so there's no other
> signal of what's going on.
>
> Signed-off-by: Stephen Warren 
> Acked-by: Simon Glass 
> ---
>  test/py/u_boot_console_base.py | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[Scott Wood]

On Fri, 2016-01-22 at 20:27 +, Bhupesh Sharma wrote:
> 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Saturday, January 23, 2016 1:52 AM
> > To: york sun; Bhupesh Sharma; Zhiqiang Hou; u-boot@lists.denx.de;
> > albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
> > le...@freescale.com; prabha...@freescale.com;
> > bhupesh.sha...@freescale.com; Zhiqiang Hou
> > Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
> > 
> > On Fri, 2016-01-22 at 20:18 +, york sun wrote:
> > > On 01/22/2016 12:14 PM, Bhupesh Sharma wrote:
> > > > 
> > > > 
> > > > > -Original Message-
> > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > Sent: Saturday, January 23, 2016 1:39 AM
> > > > > To: york sun; Zhiqiang Hou; u-boot@lists.denx.de;
> > > > > albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
> > > > > le...@freescale.com; prabha...@freescale.com;
> > > > > bhupesh.sha...@freescale.com; Zhiqiang Hou
> > > > > Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
> > > > > 
> > > > > On Fri, 2016-01-22 at 20:05 +, york sun wrote:
> > > > > > On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
> > > > > > > From: Hou Zhiqiang 
> > > > > > > 
> > > > > > > The FSL Primary Protected Application (PPA) is a software
> > > > > > > component loaded during boot which runs in TrustZone and
> > > > > > > remains resident after boot.
> > > > > > > 
> > > > > > > Signed-off-by: Hou Zhiqiang 
> > > > > > > ---
> > > > > > > Tested on LS1043A RDB board
> > > > > > > 
> > > > > > 
> > > > > > I presume PSCI is implemented in PPA. How does the SMP boot flow
> > > > > > change with PPA? U-boot has to remain functional in the absence
> > > > > > of PPA,
> > > > > right?
> > > > > > 
> > > > > > Would it be possible to write a readme for PPA?
> > > > > 
> > > > > Also, how does the devicetree get updated to indicate the presence
> > > > > of PSCI?
> > > > > 
> > > > 
> > > > One needs to add PSCI node in the DTS for the same, claiming support
> > > > for PSCI specification.
> > > > The cpu.enable_method needs to be changed from spin-table to psci as
> > well.
> > > > 
> > > > See
> > > > http://lxr.free-electrons.com/source/Documentation/devicetree/bindin
> > > > gs
> > > > /arm/psci.txt for details.
> > > > 
> > > 
> > > Bhupesh,
> > > 
> > > Before PPA is fully adopted, u-boot has to detect the existence of PPA
> > > and decide to use PSCI or spin table, right? So the device tree node
> > > should also be fixed accordingly.
> 
> A static CONFIG_ flag is used for enabling the PPA support currently in
> QorIQ-LS u-boot code.
> 
> > 
> > How would U-Boot know what version of PSCI the loaded PPA supports?  Is
> > or could there be any metadata on the PPA image to convey such
> > information?
> 
> PSCI specifications support the PSCI_VERSION API which is implemented by PPA
> and it returns the PSCI_VERSION
> supported by PPA.

That does not answer the question unless we can assume that PPA always
implements PSCI >= 0.2.  And maybe there are other services worth advertising
in the device tree?  Some sort of metadata would be nice.

-Scott

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

Re: [U-Boot] [PATCH v5 2/2] usb: eth: add Realtek RTL8152B/RTL8153 DRIVER

[Marek Vasut]

On Friday, January 22, 2016 at 08:50:04 PM, Joe Hershberger wrote:
> On Wed, Jan 20, 2016 at 12:24 AM, Ted Chen  wrote:
> > This patch adds driver support for the Realtek RTL8152B/RTL8153 USB
> > network adapters.
> > 
> > Signed-off-by: Ted Chen 
> > [swarren, fixed a few compiler warnings]
> > [swarren, with permission, converted license header to SPDX]
> > [swarren, removed printf() spew during probe()]
> > Signed-off-by: Stephen Warren 
> > ---
> > 
> >  drivers/usb/eth/Makefile|1 +
> >  drivers/usb/eth/r8152.c | 1456
> >  +++ drivers/usb/eth/r8152.h
> >  |  631 +++
> >  drivers/usb/eth/r8152_fw.c  |  980 +
> >  drivers/usb/eth/usb_ether.c |7 +
> >  include/usb_ether.h |6 +
> >  6 files changed, 3081 insertions(+)
> >  create mode 100644 drivers/usb/eth/r8152.c
> >  create mode 100644 drivers/usb/eth/r8152.h
> >  create mode 100644 drivers/usb/eth/r8152_fw.c
> > 
> > Changes for v2: Modified by Marek's comments.
> > - Remove pattern informations.
> > - Don't allocate & free when read/write register.
> > - relpace udelay to mdelay.
> > - pull firmware into global variable.
> > - code review.
> > 
> > Changes for v3: Modified by Marek's and Joe's comments.
> > - Remove driver version informations.
> > - separate firmware code to individual file.
> > - split extensive defines to r8152.h.
> > - code review.
> > 
> > Changes for v4: Modified by Marek's comments.
> > - remove the redundant code in generic_ocp_read and generic_ocp_write.
> > - remove redundant typecasting.
> > - collect the codes of busy waiting to rtl8152_reinit_ll and
> > rtl8152_nic_reset. - use ARRAY_SIZE() to avoid having 0x00 as a
> > terminating entry of r8152_dongles. - using if (!ep_in_found && (ep_addr
> > & USB_DIR_IN)) ... to replace old version. - code review.
> > 
> > Changes for v5: Modified by Marek's comments.
> > - add r8152_wait_for_bit to replace busy wait.
> > - change the name of patch4 to r8152b_set_dq_desc.
> > - add r8152_versions to store the hw's version.
> 
> Acked-by: Joe Hershberger 

Do you want to pick this or shall I ?

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[york sun]

On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> The FSL Primary Protected Application (PPA) is a software component
> loaded during boot which runs in TrustZone and remains resident
> after boot.
> 
> Signed-off-by: Hou Zhiqiang 
> ---
> Tested on LS1043A RDB board
> 

I presume PSCI is implemented in PPA. How does the SMP boot flow change with
PPA? U-boot has to remain functional in the absence of PPA, right?

Would it be possible to write a readme for PPA?

York

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[Scott Wood]

On Fri, 2016-01-22 at 20:05 +, york sun wrote:
> On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> > 
> > The FSL Primary Protected Application (PPA) is a software component
> > loaded during boot which runs in TrustZone and remains resident
> > after boot.
> > 
> > Signed-off-by: Hou Zhiqiang 
> > ---
> > Tested on LS1043A RDB board
> > 
> 
> I presume PSCI is implemented in PPA. How does the SMP boot flow change with
> PPA? U-boot has to remain functional in the absence of PPA, right?
> 
> Would it be possible to write a readme for PPA?

Also, how does the devicetree get updated to indicate the presence of PSCI?

-Scott

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[york sun]

On 01/22/2016 12:14 PM, Bhupesh Sharma wrote:
> 
> 
>> -Original Message-
>> From: Scott Wood [mailto:o...@buserror.net]
>> Sent: Saturday, January 23, 2016 1:39 AM
>> To: york sun; Zhiqiang Hou; u-boot@lists.denx.de;
>> albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
>> le...@freescale.com; prabha...@freescale.com;
>> bhupesh.sha...@freescale.com; Zhiqiang Hou
>> Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
>>
>> On Fri, 2016-01-22 at 20:05 +, york sun wrote:
>>> On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
 From: Hou Zhiqiang 

 The FSL Primary Protected Application (PPA) is a software component
 loaded during boot which runs in TrustZone and remains resident
 after boot.

 Signed-off-by: Hou Zhiqiang 
 ---
 Tested on LS1043A RDB board

>>>
>>> I presume PSCI is implemented in PPA. How does the SMP boot flow
>>> change with PPA? U-boot has to remain functional in the absence of PPA,
>> right?
>>>
>>> Would it be possible to write a readme for PPA?
>>
>> Also, how does the devicetree get updated to indicate the presence of
>> PSCI?
>>
> 
> One needs to add PSCI node in the DTS for the same, claiming support for PSCI 
> specification.
> The cpu.enable_method needs to be changed from spin-table to psci as well.
> 
> See 
> http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/arm/psci.txt
>  for details.
> 

Bhupesh,

Before PPA is fully adopted, u-boot has to detect the existence of PPA and
decide to use PSCI or spin table, right? So the device tree node should also be
fixed accordingly.

York


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

Re: [U-Boot] [PATCH] pci: restore initialization for DM_PCI

[Simon Glass]

Hi Stephen,

On 22 January 2016 at 12:38, Stephen Warren  wrote:
>
> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>
>> Hi Bin,
>>
>> On 21 January 2016 at 20:53, Bin Meng  wrote:
>>>
>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass  wrote:

 Hi,

 On 21 January 2016 at 18:39, Bin Meng  wrote:
>
> Hi Stephen,
>
> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren  
> wrote:
>>
>> From: Stephen Warren 
>>
>> PCI controllers should be enumerated at startup so that PCI devices
>> such as Ethernet controllers are available at startup. Fix board_init_r()
>> not to skip calling pci_init() when CONFIG_DM_PCI is defined, and provide
>> an implementation of pci_init() for the DM case.
>>
>
> What exact issue are you trying to fix? I posted the same question on
> Simon's patch [1] before. Does your patch and Simon's fix the same
> issue?
>
> Note I submitted a similar patch [2] last year for x86 only, to
> explicitly trigger the PCI enueration. But it was not accepted.
>
>> Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver 
>> model
>> for Ethernet")
>> Signed-off-by: Stephen Warren 
>> ---
>> I'm not sure if relying on the side-effects of calling
>> uclass_{first,ext}_device is the correct approach; is there a more 
>> explicit
>> way to probe all PCI controllers?
>>
>> Arguably, perhaps we should introduce a "pci start" command instead of
>> this change to be consistent with e.g. USB. However, that would be a
>> regression relative to earlier versions of U-Boot.
>> ---
>
>
> [1] http://patchwork.ozlabs.org/patch/569323/
> [2] http://patchwork.ozlabs.org/patch/500246/
>
> Regards,
> Bin


 This does go against the driver-model philosophy of lazy init. I
 wonder if we should add this patch with a Kconfig option to enable it?
 Then it can be enabled only for boards that need it.

>>>
>>> I suspect the issue is somewhere else. On Intel Galileo with a PCI
>>> ethernet, it works fine without such explicit pci init. Which PCI
>>> ethernet driver does not work on Tegra?
>>
>>
>> It could be because that board probes PCI to get its serial to work.
>>
>> This could be fixed on Tegra by adding an Ethernet node to the device
>> tree to cause it to be probed. But I don't think that should be a
>> requirement.
>
>
> Since PCI devices are automatically probed via standard bus protocols, I 
> believe we shouldn't have to add them to the DT.
>
> However, I could accept that we should add the PCI controller to DT in order 
> for the controller to be probed, and when that happens, the bus should be 
> enumerated thus causing all the Ethernet devices to be probed. However, the 
> PCI controller is already in DT, and this process isn't being kicked off, so 
> if that's the way it's supposed to work, there's a bug there.

So what do you think about a Kconfig option that tells U-Boot that PCI
must be probed after relocation?

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

Re: [U-Boot] [PATCH 1/2] driver: net: ldpaa_eth: Add support of PHY framework

[Joe Hershberger]

On Wed, Jan 20, 2016 at 12:34 AM, Prabhakar Kushwaha
 wrote:
> This patch integrate DPAA2 ethernet driver existing PHY framework.
>
> Call phy_connect and phy_config as per available DPMAC id defined
> in SerDes Protcol.
>
> Signed-off-by: Pratiyush Mohan Srivastava 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 116 
> --
>  1 file changed, 85 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 3857122..0a82bc6 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -14,15 +14,34 @@
>  #include 
>  #include 
>
> +#include 
>  #include "ldpaa_eth.h"
>
> -#undef CONFIG_PHYLIB
> +#ifdef CONFIG_PHYLIB
>  static int init_phy(struct eth_device *dev)
>  {
> -   /*TODO for external PHY */
> +   struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)dev->priv;
> +   struct phy_device *phydev = NULL;
> +   struct mii_dev *bus;
> +
> +   bus = wriop_get_mdio(priv->dpmac_id);
> +   if (bus == NULL)
> +   return 0;
> +
> +   phydev = phy_connect(bus, wriop_get_phy_address(priv->dpmac_id),
> +dev, wriop_get_enet_if(priv->dpmac_id));
> +   if (!phydev) {
> +   printf("Failed to connect\n");
> +   return -1;
> +   }
> +
> +   priv->phydev = phydev;
> +
> +   phy_config(phydev);

Seems you should be returning the value from this call.

>
> return 0;

Instead of 0.

>  }
> +#endif
>
>  #ifdef DEBUG
>  static void ldpaa_eth_get_dpni_counter(void)
> @@ -303,7 +322,9 @@ static int ldpaa_eth_open(struct eth_device *net_dev, 
> bd_t *bd)
>  #ifdef DEBUG
> struct dpni_link_state link_state;
>  #endif
> -   int err;
> +   int err = 0;
> +   struct mii_dev *bus;
> +   phy_interface_t enet_if;
>
> if (net_dev->state == ETH_STATE_ACTIVE)
> return 0;
> @@ -317,11 +338,48 @@ static int ldpaa_eth_open(struct eth_device *net_dev, 
> bd_t *bd)
> printf("ERROR (DPL is deployed. No device available)\n");
> return -ENODEV;
> }
> +
> /* DPMAC initialization */
> err = ldpaa_dpmac_setup(priv);
> if (err < 0)
> goto err_dpmac_setup;
>
> +#ifdef CONFIG_PHYLIB
> +   if (priv->phydev)
> +   err = phy_startup(priv->phydev);
> +   if (err) {
> +   printf("%s: Could not initialize\n",
> +  priv->phydev->dev->name);
> +   goto err_dpamc_bind;
> +   }
> +#else

Is there actually a reason to support !CONFIG_PHYLIB?

> +   priv->phydev = (struct phy_device *)malloc(sizeof(struct phy_device));
> +   memset(priv->phydev, 0, sizeof(struct phy_device));
> +
> +   priv->phydev->speed = SPEED_1000;
> +   priv->phydev->link = 1;
> +   priv->phydev->duplex = DUPLEX_FULL;
> +#endif
> +
> +   bus = wriop_get_mdio(priv->dpmac_id);
> +   enet_if = wriop_get_enet_if(priv->dpmac_id);
> +   if ((bus == NULL) &&
> +   (enet_if == PHY_INTERFACE_MODE_XGMII)) {
> +   priv->phydev = (struct phy_device *)
> +   malloc(sizeof(struct phy_device));
> +   memset(priv->phydev, 0, sizeof(struct phy_device));
> +
> +   priv->phydev->speed = SPEED_1;
> +   priv->phydev->link = 1;
> +   priv->phydev->duplex = DUPLEX_FULL;
> +   }
> +
> +   if (!priv->phydev->link) {
> +   printf("%s: No link.\n", priv->phydev->dev->name);
> +   err = -1;
> +   goto err_dpamc_bind;
> +   }
> +
> /* DPMAC binding DPNI */
> err = ldpaa_dpmac_bind(priv);
> if (err)
> @@ -348,28 +406,24 @@ static int ldpaa_eth_open(struct eth_device *net_dev, 
> bd_t *bd)
> return err;
> }
>
> -#ifdef CONFIG_PHYLIB
> -   /* TODO Check this path */
> -   err = phy_startup(priv->phydev);
> -   if (err) {
> -   printf("%s: Could not initialize\n", priv->phydev->dev->name);
> -   return err;
> -   }
> -#else
> -   priv->phydev->speed = SPEED_1000;
> -   priv->phydev->link = 1;
> -   priv->phydev->duplex = DUPLEX_FULL;
> -#endif
> -
> err = dpni_enable(dflt_mc_io, MC_CMD_NO_FLAGS, 
> dflt_dpni->dpni_handle);
> if (err < 0) {
> printf("dpni_enable() failed\n");
> return err;
> }
>
> -   dpmac_link_state.rate = SPEED_1000;
> -   dpmac_link_state.options = DPMAC_LINK_OPT_AUTONEG;
> -   dpmac_link_state.up = 1;
> +   dpmac_link_state.rate = priv->phydev->speed;
> +
> +   if (priv->phydev->autoneg == AUTONEG_DISABLE)
> +   dpmac_link_state.options &= 

Re: [U-Boot] [PATCH v5 2/2] usb: eth: add Realtek RTL8152B/RTL8153 DRIVER

[Joe Hershberger]

Hi Marek,

On Fri, Jan 22, 2016 at 2:00 PM, Marek Vasut  wrote:
> On Friday, January 22, 2016 at 08:50:04 PM, Joe Hershberger wrote:
>> On Wed, Jan 20, 2016 at 12:24 AM, Ted Chen  wrote:
>> > This patch adds driver support for the Realtek RTL8152B/RTL8153 USB
>> > network adapters.
>> >
>> > Signed-off-by: Ted Chen 
>> > [swarren, fixed a few compiler warnings]
>> > [swarren, with permission, converted license header to SPDX]
>> > [swarren, removed printf() spew during probe()]
>> > Signed-off-by: Stephen Warren 
>> > ---
>> >
>> >  drivers/usb/eth/Makefile|1 +
>> >  drivers/usb/eth/r8152.c | 1456
>> >  +++ drivers/usb/eth/r8152.h
>> >  |  631 +++
>> >  drivers/usb/eth/r8152_fw.c  |  980 +
>> >  drivers/usb/eth/usb_ether.c |7 +
>> >  include/usb_ether.h |6 +
>> >  6 files changed, 3081 insertions(+)
>> >  create mode 100644 drivers/usb/eth/r8152.c
>> >  create mode 100644 drivers/usb/eth/r8152.h
>> >  create mode 100644 drivers/usb/eth/r8152_fw.c
>> >
>> > Changes for v2: Modified by Marek's comments.
>> > - Remove pattern informations.
>> > - Don't allocate & free when read/write register.
>> > - relpace udelay to mdelay.
>> > - pull firmware into global variable.
>> > - code review.
>> >
>> > Changes for v3: Modified by Marek's and Joe's comments.
>> > - Remove driver version informations.
>> > - separate firmware code to individual file.
>> > - split extensive defines to r8152.h.
>> > - code review.
>> >
>> > Changes for v4: Modified by Marek's comments.
>> > - remove the redundant code in generic_ocp_read and generic_ocp_write.
>> > - remove redundant typecasting.
>> > - collect the codes of busy waiting to rtl8152_reinit_ll and
>> > rtl8152_nic_reset. - use ARRAY_SIZE() to avoid having 0x00 as a
>> > terminating entry of r8152_dongles. - using if (!ep_in_found && (ep_addr
>> > & USB_DIR_IN)) ... to replace old version. - code review.
>> >
>> > Changes for v5: Modified by Marek's comments.
>> > - add r8152_wait_for_bit to replace busy wait.
>> > - change the name of patch4 to r8152b_set_dq_desc.
>> > - add r8152_versions to store the hw's version.
>>
>> Acked-by: Joe Hershberger 
>
> Do you want to pick this or shall I ?

If there is some dependency (patch 1) that you will take first, you
can just take this as well.

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

[U-Boot] Please pull u-boot-fdt

[Simon Glass]

Hi Tom,

I've been sitting on this but I don't see much else so we may as well it get in.


The following changes since commit 6905f4d3c7be46fed4859f51f0a8f9a1107c22e7:

  Merge git://git.denx.de/u-boot-dm (2016-01-21 11:49:49 -0500)

are available in the git repository at:

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

for you to fetch changes up to 67871a595873930a0a536b1685e5caac53766701:

  devicetree: use wildcard to clean arch subdir (2016-01-22 14:41:14 -0700)


Thomas Chou (1):
  devicetree: use wildcard to clean arch subdir

 dts/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] pci: restore initialization for DM_PCI

[Stephen Warren]

On 01/22/2016 01:32 PM, Simon Glass wrote:

Hi Stephen,

On 22 January 2016 at 12:38, Stephen Warren  wrote:


On 01/21/2016 09:03 PM, Simon Glass wrote:


Hi Bin,

On 21 January 2016 at 20:53, Bin Meng  wrote:


On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass  wrote:


Hi,

On 21 January 2016 at 18:39, Bin Meng  wrote:


Hi Stephen,

On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren  wrote:


From: Stephen Warren 

PCI controllers should be enumerated at startup so that PCI devices
such as Ethernet controllers are available at startup. Fix board_init_r()
not to skip calling pci_init() when CONFIG_DM_PCI is defined, and provide
an implementation of pci_init() for the DM case.



What exact issue are you trying to fix? I posted the same question on
Simon's patch [1] before. Does your patch and Simon's fix the same
issue?

Note I submitted a similar patch [2] last year for x86 only, to
explicitly trigger the PCI enueration. But it was not accepted.


Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver model
for Ethernet")
Signed-off-by: Stephen Warren 
---
I'm not sure if relying on the side-effects of calling
uclass_{first,ext}_device is the correct approach; is there a more explicit
way to probe all PCI controllers?

Arguably, perhaps we should introduce a "pci start" command instead of
this change to be consistent with e.g. USB. However, that would be a
regression relative to earlier versions of U-Boot.
---



[1] http://patchwork.ozlabs.org/patch/569323/
[2] http://patchwork.ozlabs.org/patch/500246/

Regards,
Bin



This does go against the driver-model philosophy of lazy init. I
wonder if we should add this patch with a Kconfig option to enable it?
Then it can be enabled only for boards that need it.



I suspect the issue is somewhere else. On Intel Galileo with a PCI
ethernet, it works fine without such explicit pci init. Which PCI
ethernet driver does not work on Tegra?



It could be because that board probes PCI to get its serial to work.

This could be fixed on Tegra by adding an Ethernet node to the device
tree to cause it to be probed. But I don't think that should be a
requirement.



Since PCI devices are automatically probed via standard bus protocols, I 
believe we shouldn't have to add them to the DT.

However, I could accept that we should add the PCI controller to DT in order 
for the controller to be probed, and when that happens, the bus should be 
enumerated thus causing all the Ethernet devices to be probed. However, the PCI 
controller is already in DT, and this process isn't being kicked off, so if 
that's the way it's supposed to work, there's a bug there.


So what do you think about a Kconfig option that tells U-Boot that PCI
must be probed after relocation?


I'm puzzled why anyone would turn off that option.

If PCI is to be used at all, it needs to be probed. The only way I'm 
aware of that it can be probed today is by accidental side-effect of 
some board forcibly probing some device that happens to be on a PCI bus 
(i.e. Bin's case). In other case, PCI doesn't get automatically probed 
at boot, and I don't see any command that allows it to be probed 
manually. Don't we need this patch (or your patch linked above) in order 
to make PCI usable at all? If so, why would anyone turn this off?

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

Re: [U-Boot] [PATCH] pci: restore initialization for DM_PCI

[Simon Glass]

Hi Stephen,

On 22 January 2016 at 14:48, Stephen Warren  wrote:
> On 01/22/2016 01:32 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 22 January 2016 at 12:38, Stephen Warren  wrote:
>>>
>>>
>>> On 01/21/2016 09:03 PM, Simon Glass wrote:


 Hi Bin,

 On 21 January 2016 at 20:53, Bin Meng  wrote:
>
>
> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass  wrote:
>>
>>
>> Hi,
>>
>> On 21 January 2016 at 18:39, Bin Meng  wrote:
>>>
>>>
>>> Hi Stephen,
>>>
>>> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>>>  wrote:


 From: Stephen Warren 

 PCI controllers should be enumerated at startup so that PCI devices
 such as Ethernet controllers are available at startup. Fix
 board_init_r()
 not to skip calling pci_init() when CONFIG_DM_PCI is defined, and
 provide
 an implementation of pci_init() for the DM case.

>>>
>>> What exact issue are you trying to fix? I posted the same question on
>>> Simon's patch [1] before. Does your patch and Simon's fix the same
>>> issue?
>>>
>>> Note I submitted a similar patch [2] last year for x86 only, to
>>> explicitly trigger the PCI enueration. But it was not accepted.
>>>
 Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver
 model
 for Ethernet")
 Signed-off-by: Stephen Warren 
 ---
 I'm not sure if relying on the side-effects of calling
 uclass_{first,ext}_device is the correct approach; is there a more
 explicit
 way to probe all PCI controllers?

 Arguably, perhaps we should introduce a "pci start" command instead
 of
 this change to be consistent with e.g. USB. However, that would be a
 regression relative to earlier versions of U-Boot.
 ---
>>>
>>>
>>>
>>> [1] http://patchwork.ozlabs.org/patch/569323/
>>> [2] http://patchwork.ozlabs.org/patch/500246/
>>>
>>> Regards,
>>> Bin
>>
>>
>>
>> This does go against the driver-model philosophy of lazy init. I
>> wonder if we should add this patch with a Kconfig option to enable it?
>> Then it can be enabled only for boards that need it.
>>
>
> I suspect the issue is somewhere else. On Intel Galileo with a PCI
> ethernet, it works fine without such explicit pci init. Which PCI
> ethernet driver does not work on Tegra?



 It could be because that board probes PCI to get its serial to work.

 This could be fixed on Tegra by adding an Ethernet node to the device
 tree to cause it to be probed. But I don't think that should be a
 requirement.
>>>
>>>
>>>
>>> Since PCI devices are automatically probed via standard bus protocols, I
>>> believe we shouldn't have to add them to the DT.
>>>
>>> However, I could accept that we should add the PCI controller to DT in
>>> order for the controller to be probed, and when that happens, the bus should
>>> be enumerated thus causing all the Ethernet devices to be probed. However,
>>> the PCI controller is already in DT, and this process isn't being kicked
>>> off, so if that's the way it's supposed to work, there's a bug there.
>>
>>
>> So what do you think about a Kconfig option that tells U-Boot that PCI
>> must be probed after relocation?
>
>
> I'm puzzled why anyone would turn off that option.
>
> If PCI is to be used at all, it needs to be probed. The only way I'm aware
> of that it can be probed today is by accidental side-effect of some board
> forcibly probing some device that happens to be on a PCI bus (i.e. Bin's
> case). In other case, PCI doesn't get automatically probed at boot, and I
> don't see any command that allows it to be probed manually. Don't we need
> this patch (or your patch linked above) in order to make PCI usable at all?
> If so, why would anyone turn this off?

We try to probe devices only when used. E.g. on beaver, if you are not
net-booting, you actually don't need PCI.

I think a command is a good idea. I also think a Kconfig option to
auto-probe PCI is worth adding. But I'm not keen on manually probing
it by default for all PCI boards.

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

Re: [U-Boot] [PATCH] pci: restore initialization for DM_PCI

[Stephen Warren]

On 01/22/2016 02:50 PM, Simon Glass wrote:

Hi Stephen,

On 22 January 2016 at 14:48, Stephen Warren  wrote:

On 01/22/2016 01:32 PM, Simon Glass wrote:


Hi Stephen,

On 22 January 2016 at 12:38, Stephen Warren  wrote:



On 01/21/2016 09:03 PM, Simon Glass wrote:



Hi Bin,

On 21 January 2016 at 20:53, Bin Meng  wrote:



On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass  wrote:



Hi,

On 21 January 2016 at 18:39, Bin Meng  wrote:



Hi Stephen,

On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
 wrote:



From: Stephen Warren 

PCI controllers should be enumerated at startup so that PCI devices
such as Ethernet controllers are available at startup. Fix
board_init_r()
not to skip calling pci_init() when CONFIG_DM_PCI is defined, and
provide
an implementation of pci_init() for the DM case.



What exact issue are you trying to fix? I posted the same question on
Simon's patch [1] before. Does your patch and Simon's fix the same
issue?

Note I submitted a similar patch [2] last year for x86 only, to
explicitly trigger the PCI enueration. But it was not accepted.


Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to driver
model
for Ethernet")
Signed-off-by: Stephen Warren 
---
I'm not sure if relying on the side-effects of calling
uclass_{first,ext}_device is the correct approach; is there a more
explicit
way to probe all PCI controllers?

Arguably, perhaps we should introduce a "pci start" command instead
of
this change to be consistent with e.g. USB. However, that would be a
regression relative to earlier versions of U-Boot.
---




[1] http://patchwork.ozlabs.org/patch/569323/
[2] http://patchwork.ozlabs.org/patch/500246/

Regards,
Bin




This does go against the driver-model philosophy of lazy init. I
wonder if we should add this patch with a Kconfig option to enable it?
Then it can be enabled only for boards that need it.



I suspect the issue is somewhere else. On Intel Galileo with a PCI
ethernet, it works fine without such explicit pci init. Which PCI
ethernet driver does not work on Tegra?




It could be because that board probes PCI to get its serial to work.

This could be fixed on Tegra by adding an Ethernet node to the device
tree to cause it to be probed. But I don't think that should be a
requirement.




Since PCI devices are automatically probed via standard bus protocols, I
believe we shouldn't have to add them to the DT.

However, I could accept that we should add the PCI controller to DT in
order for the controller to be probed, and when that happens, the bus should
be enumerated thus causing all the Ethernet devices to be probed. However,
the PCI controller is already in DT, and this process isn't being kicked
off, so if that's the way it's supposed to work, there's a bug there.



So what do you think about a Kconfig option that tells U-Boot that PCI
must be probed after relocation?



I'm puzzled why anyone would turn off that option.

If PCI is to be used at all, it needs to be probed. The only way I'm aware
of that it can be probed today is by accidental side-effect of some board
forcibly probing some device that happens to be on a PCI bus (i.e. Bin's
case). In other case, PCI doesn't get automatically probed at boot, and I
don't see any command that allows it to be probed manually. Don't we need
this patch (or your patch linked above) in order to make PCI usable at all?
If so, why would anyone turn this off?


We try to probe devices only when used. E.g. on beaver, if you are not
net-booting, you actually don't need PCI.


Are you saying that the first network command I execute in U-Boot should 
probe Ethernet device and hence PCI devices right now in the current 
U-Boot code?


That doesn't work right now. If it did work, that would probably be OK.

If not, I don't see how mentioning the lazy probing is relevant.


I think a command is a good idea. I also think a Kconfig option to
auto-probe PCI is worth adding. But I'm not keen on manually probing
it by default for all PCI boards.

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

Re: [U-Boot] [Patch V2 3/3] armv8/fsl-layerscape: fdt: add fixup for fman

[Scott Wood]

On Fri, 2016-01-22 at 20:07 +0800, Gong Qianyu wrote:
> Add fdt fixup for Fman clock and inserting Fman ucode blob
> into the device tree.
> 
> Signed-off-by: Gong Qianyu 
> ---
> V2:
>  - Removed the duplicated function.
> 
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index eafdd71..8a6b694 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -8,12 +8,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #ifdef CONFIG_FSL_LSCH3
>  #include 
>  #endif
>  #ifdef CONFIG_FSL_ESDHC
>  #include 
>  #endif
> +#ifdef CONFIG_SYS_DPAA_FMAN
> +#include 
> +#endif
>  #ifdef CONFIG_MP
>  #include 
>  #endif
> @@ -181,6 +185,10 @@ static void fdt_fixup_smmu(void *blob)
>  
>  void ft_cpu_setup(void *blob, bd_t *bd)
>  {
> + struct sys_info sysinfo;
> +
> + get_sys_info();
> +
>  #ifdef CONFIG_MP
>   ft_fixup_cpu(blob);
>  #endif
> @@ -201,4 +209,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_FSL_LSCH3
>   fdt_fixup_smmu(blob);
>  #endif
> +
> +#ifdef CONFIG_SYS_DPAA_FMAN
> + do_fixup_by_compat_u32(blob, "fsl,fman",
> +"clock-frequency", sysinfo.freq_fman[0], 1);
> + fdt_fixup_fman_firmware(blob);
> +#endif
>  }


There is no clock-frequency in the fman binding.  A clocks property is used
instead (which does not require a fixup).

-Scott

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

Re: [U-Boot] [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support

[Scott Wood]

On Fri, 2016-01-22 at 20:14 +, Bhupesh Sharma wrote:
> 
> > -Original Message-
> > From: Scott Wood [mailto:o...@buserror.net]
> > Sent: Saturday, January 23, 2016 1:39 AM
> > To: york sun; Zhiqiang Hou; u-boot@lists.denx.de;
> > albert.u.b...@aribaud.net; mingkai...@freescale.com; Stuart Yoder;
> > le...@freescale.com; prabha...@freescale.com;
> > bhupesh.sha...@freescale.com; Zhiqiang Hou
> > Subject: Re: [PATCHv2 2/3] ARMv8/layerscape: Add FSL PPA support
> > 
> > On Fri, 2016-01-22 at 20:05 +, york sun wrote:
> > > On 01/21/2016 01:53 AM, Zhiqiang Hou wrote:
> > > > From: Hou Zhiqiang 
> > > > 
> > > > The FSL Primary Protected Application (PPA) is a software component
> > > > loaded during boot which runs in TrustZone and remains resident
> > > > after boot.
> > > > 
> > > > Signed-off-by: Hou Zhiqiang 
> > > > ---
> > > > Tested on LS1043A RDB board
> > > > 
> > > 
> > > I presume PSCI is implemented in PPA. How does the SMP boot flow
> > > change with PPA? U-boot has to remain functional in the absence of PPA,
> > right?
> > > 
> > > Would it be possible to write a readme for PPA?
> > 
> > Also, how does the devicetree get updated to indicate the presence of
> > PSCI?
> > 
> 
> One needs to add PSCI node in the DTS for the same, claiming support for
> PSCI specification.

So then we need a different dts based on whether PPA is loaded?  No thanks.

> The cpu.enable_method needs to be changed from spin-table to psci as well.

Right, that's part of updating the devicetree to indicate the presence of
PSCI.

> See http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/a
> rm/psci.txt for details.

I'm familiar with the binding.

-Scott

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

Re: [U-Boot] [PATCH v2 7/8] ARM: dts: k2g: Add keystone net dts files

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> Add keystone net DT support for k2g evm.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 

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 6/8] defconfig: k2e_evm_defconfig: enable net driver model

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> enable net driver model for k2e evm as keystone_net supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 

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 8/8] defconfig: k2g_evm_defconfig: enable net driver model

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> enable net driver model for k2g evm as keystone_net supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 

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 V5 2/4] spi: fsl_qspi: Fix qspi_op_rdid memcpy issue

[york sun]

On 01/22/2016 07:43 AM, Scott Wood wrote:
> On 01/21/2016 09:35 PM, Qianyu Gong wrote:
>>
>>> -Original Message-
>>> From: Scott Wood
>>> Sent: Friday, January 22, 2016 3:30 AM
>>> To: Qianyu Gong ; u-boot@lists.denx.de;
>>> r58...@freescale.com
>>> Cc: mingkai...@freescale.com; jt...@openedev.com; b48...@freescale.com;
>>> shaohui@freescale.com; wenbin.s...@freescale.com; Scott Wood
>>> ; Gong Qianyu 
>>> Subject: Re: [Patch V5 2/4] spi: fsl_qspi: Fix qspi_op_rdid memcpy issue
>>>
>>> On 01/20/2016 09:43 PM, Gong Qianyu wrote:
 From: Gong Qianyu 

 In current driver everytime we memcpy 4 bytes to the dest memory
 regardless of the remaining length.
 This patch adds checking the remaining length before memcpy.
 If the length is shorter than 4 bytes, memcpy the actual length of
 data to the dest memory.

 Signed-off-by: Gong Qianyu 
 ---
 V2-V5:
  - No change.

  drivers/spi/fsl_qspi.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
 38e5900..f178857 100644
 --- a/drivers/spi/fsl_qspi.c
 +++ b/drivers/spi/fsl_qspi.c
 @@ -500,7 +500,10 @@ static void qspi_op_rdid(struct fsl_qspi_priv *priv, 
 u32
>>> *rxbuf, u32 len)
if (rbsr_reg & QSPI_RBSR_RDBFL_MASK) {
data = qspi_read32(priv->flags, >rbdr[i]);
data = qspi_endian_xchg(data);
 -  memcpy(rxbuf, , 4);
 +  if (size < 4)
 +  memcpy(rxbuf, , size);
 +  else
 +  memcpy(rxbuf, , 4);
>>>
>>> memcpy(rxbuf, , min(size, 4));
>>>
rxbuf++;
size -= 4;
i++;
>>>
>>> size -= 4 even if size was < 4?
>>>
>>> -Scott
>>
>> Yes.. The following is complete code:
>>
>> i = 0;
>> size = len;
>> while ((RX_BUFFER_SIZE >= size) && (size > 0)) {
>> rbsr_reg = qspi_read32(priv->flags, >rbsr);
>> if (rbsr_reg & QSPI_RBSR_RDBFL_MASK) {
>> data = qspi_read32(priv->flags, >rbdr[i]);
>> data = qspi_endian_xchg(data);
>> memcpy(rxbuf, , min(size, 4));
>> rxbuf++;
>> size -= 4;
>> i++;
>> }
>> }
> 
> I'm not saying it doesn't work (assuming i is signed, which the
> "complete code" above doesn't show).  I'm saying it looks weird, and it
> would be better to have a variable that holds min(size, 4) and pass that
> to both memcpy and the subtraction.
> 

Qianyu,

Previously I said it looked weird for doing this. Please fix.

"size" is declared as "int".
"len" is declared as u32. That's not "int". If you trace back the functions, you
may see it came from DIV_ROUND_UP(bitlen, 8) where bitlen is "unsigned int". So
technically the code is safe. But it is _confusing_. We don't want to confuse
ourselves when reading the code later. And the fix is easy, isn't it?

York

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

Re: [U-Boot] [PATCH] pci: restore initialization for DM_PCI

[Simon Glass]

Hi Stephen,

On 22 January 2016 at 14:58, Stephen Warren  wrote:
> On 01/22/2016 02:50 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 22 January 2016 at 14:48, Stephen Warren  wrote:
>>>
>>> On 01/22/2016 01:32 PM, Simon Glass wrote:


 Hi Stephen,

 On 22 January 2016 at 12:38, Stephen Warren 
 wrote:
>
>
>
> On 01/21/2016 09:03 PM, Simon Glass wrote:
>>
>>
>>
>> Hi Bin,
>>
>> On 21 January 2016 at 20:53, Bin Meng  wrote:
>>>
>>>
>>>
>>> On Fri, Jan 22, 2016 at 11:36 AM, Simon Glass 
>>> wrote:



 Hi,

 On 21 January 2016 at 18:39, Bin Meng  wrote:
>
>
>
> Hi Stephen,
>
> On Fri, Jan 22, 2016 at 7:35 AM, Stephen Warren
>  wrote:
>>
>>
>>
>> From: Stephen Warren 
>>
>> PCI controllers should be enumerated at startup so that PCI
>> devices
>> such as Ethernet controllers are available at startup. Fix
>> board_init_r()
>> not to skip calling pci_init() when CONFIG_DM_PCI is defined, and
>> provide
>> an implementation of pci_init() for the DM case.
>>
>
> What exact issue are you trying to fix? I posted the same question
> on
> Simon's patch [1] before. Does your patch and Simon's fix the same
> issue?
>
> Note I submitted a similar patch [2] last year for x86 only, to
> explicitly trigger the PCI enueration. But it was not accepted.
>
>> Fixes: 96350f729c42 ("dm: tegra: net: Convert tegra boards to
>> driver
>> model
>> for Ethernet")
>> Signed-off-by: Stephen Warren 
>> ---
>> I'm not sure if relying on the side-effects of calling
>> uclass_{first,ext}_device is the correct approach; is there a more
>> explicit
>> way to probe all PCI controllers?
>>
>> Arguably, perhaps we should introduce a "pci start" command
>> instead
>> of
>> this change to be consistent with e.g. USB. However, that would be
>> a
>> regression relative to earlier versions of U-Boot.
>> ---
>
>
>
>
> [1] http://patchwork.ozlabs.org/patch/569323/
> [2] http://patchwork.ozlabs.org/patch/500246/
>
> Regards,
> Bin




 This does go against the driver-model philosophy of lazy init. I
 wonder if we should add this patch with a Kconfig option to enable
 it?
 Then it can be enabled only for boards that need it.

>>>
>>> I suspect the issue is somewhere else. On Intel Galileo with a PCI
>>> ethernet, it works fine without such explicit pci init. Which PCI
>>> ethernet driver does not work on Tegra?
>>
>>
>>
>>
>> It could be because that board probes PCI to get its serial to work.
>>
>> This could be fixed on Tegra by adding an Ethernet node to the device
>> tree to cause it to be probed. But I don't think that should be a
>> requirement.
>
>
>
>
> Since PCI devices are automatically probed via standard bus protocols,
> I
> believe we shouldn't have to add them to the DT.
>
> However, I could accept that we should add the PCI controller to DT in
> order for the controller to be probed, and when that happens, the bus
> should
> be enumerated thus causing all the Ethernet devices to be probed.
> However,
> the PCI controller is already in DT, and this process isn't being
> kicked
> off, so if that's the way it's supposed to work, there's a bug there.



 So what do you think about a Kconfig option that tells U-Boot that PCI
 must be probed after relocation?
>>>
>>>
>>>
>>> I'm puzzled why anyone would turn off that option.
>>>
>>> If PCI is to be used at all, it needs to be probed. The only way I'm
>>> aware
>>> of that it can be probed today is by accidental side-effect of some board
>>> forcibly probing some device that happens to be on a PCI bus (i.e. Bin's
>>> case). In other case, PCI doesn't get automatically probed at boot, and I
>>> don't see any command that allows it to be probed manually. Don't we need
>>> this patch (or your patch linked above) in order to make PCI usable at
>>> all?
>>> If so, why would anyone turn this off?
>>
>>
>> We try to probe devices only when used. E.g. on beaver, if you are not
>> net-booting, you actually don't need PCI.
>
>
> Are you saying that the first network command I execute in U-Boot should
> probe Ethernet device and hence PCI 

Re: [U-Boot] [PATCH v2 05/37] video: bridge: Allow GPIOs to be optional

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Some video bridges will not have GPIOs to control reset, etc. Allow these
> to be optional.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/video/bridge/video-bridge-uclass.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v2 09/37] dm: backlight: Add a driver for a PWM backlight

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Many backlights need to use a PWM to control the brightness. Add a driver
> for this. It understands the standard device tree binding.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/video/Makefile|   3 +
>  drivers/video/pwm_backlight.c | 134 
> ++
>  2 files changed, 137 insertions(+)
>  create mode 100644 drivers/video/pwm_backlight.c

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

Re: [U-Boot] [PATCH v2 10/37] dm: panel: Add a panel uclass

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> LCD panels can usefully be modelled as their own uclass. They can be probed
> (which powers them up ready for use). If they have a backlight, this can be
> enabled.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/video/Makefile   |  1 +
>  drivers/video/panel-uclass.c | 25 +
>  include/dm/uclass-id.h   |  1 +
>  include/panel.h  | 31 +++
>  4 files changed, 58 insertions(+)
>  create mode 100644 drivers/video/panel-uclass.c
>  create mode 100644 include/panel.h

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

Re: [U-Boot] [PATCH v2 08/37] dm: backlight: Add a backlight uclass

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> LCD panels normally have a backlight which can be controlled to illuminate
> the LCD contents. Add a uclass to support this. Initially it only has a
> method to enable the backlight.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/video/Makefile   |  1 +
>  drivers/video/backlight-uclass.c | 25 +
>  include/backlight.h  | 31 +++
>  include/dm/uclass-id.h   |  1 +
>  4 files changed, 58 insertions(+)
>  create mode 100644 drivers/video/backlight-uclass.c
>  create mode 100644 include/backlight.h

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

Re: [U-Boot] [PATCH v2 18/37] rockchip: Don't skip low-level init

[Simon Glass]

On 21 January 2016 at 19:45, Simon Glass  wrote:
> At present the low-level init is skipped on rockchip. Among other things
> this means that the instruction cache is left disabled. Fix this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/mach-rockchip/board.c| 4 
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 4 
>  include/configs/rk3288_common.h   | 1 -
>  3 files changed, 8 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 16/37] rockchip: video: Add a display driver for rockchip eDP

[Simon Glass]

On 21 January 2016 at 19:45, Simon Glass  wrote:
> Some Rockchip SoCs support embedded DisplayPort output. Add a display driver
> for this so that these displays can be used on supported boards.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Update for new clk_get_by_index() API
>
>  arch/arm/include/asm/arch-rockchip/edp_rk3288.h |  636 +
>  drivers/video/rockchip/Makefile |2 +-
>  drivers/video/rockchip/rk_edp.c | 1085 
> +++
>  3 files changed, 1722 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/edp_rk3288.h
>  create mode 100644 drivers/video/rockchip/rk_edp.c

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

Re: [U-Boot] [PATCH v2 19/37] rockchip: Add a simple 'clock' command

[Simon Glass]

On 21 January 2016 at 19:45, Simon Glass  wrote:
> Add a command that displays the PLLs and their current rate.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/mach-rockchip/board.c | 24 
>  1 file changed, 24 insertions(+)

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

Re: [U-Boot] [PATCH v2 17/37] rockchip: video: Add a video-output driver

[Simon Glass]

On 21 January 2016 at 19:45, Simon Glass  wrote:
> Some rockchip SoCs include video output (VOP). Add a driver to support this.
> It can output via a display driver (UCLASS_DISPLAY) and currently HDMI and
> eDP are supported.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 349 
> 
>  drivers/video/rockchip/Makefile |   2 +-
>  drivers/video/rockchip/rk_vop.c | 346 +++
>  3 files changed, 696 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/vop_rk3288.h
>  create mode 100644 drivers/video/rockchip/rk_vop.c

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

Re: [U-Boot] [PATCH v2 20/37] rockchip: Add a script to parse datasheets

[Simon Glass]

On 21 January 2016 at 19:45, Simon Glass  wrote:
> This script has proved useful for parsing datasheets and creating register
> shift/mask values for use in header files. Include it in case it is useful
> for others.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  doc/README.rockchip |   6 ++
>  tools/rkmux.py  | 218 
> 
>  2 files changed, 224 insertions(+)
>  create mode 100755 tools/rkmux.py

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

[U-Boot] [PATCH V2 1/8] test/py: fix timeout to be absolute

[Stephen Warren]

From: Stephen Warren 

Currently, Spawn.expect() imposes its timeout solely upon receipt of new
data, not on its overall operation. In theory, this could cause the
timeout not to fire if U-Boot continually generated output that did not
match the expected patterns.

Fix the code to additionally impose a timeout on overall operation, which
is the intended mode of operation.

Signed-off-by: Stephen Warren 
Reviewed-by: Lukasz Majewski 
Acked-by: Simon Glass 
---
 test/py/u_boot_spawn.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/test/py/u_boot_spawn.py b/test/py/u_boot_spawn.py
index 1baee63df25c..df4c67597cab 100644
--- a/test/py/u_boot_spawn.py
+++ b/test/py/u_boot_spawn.py
@@ -122,6 +122,7 @@ class Spawn(object):
 if type(patterns[pi]) == type(''):
 patterns[pi] = re.compile(patterns[pi])
 
+tstart_s = time.time()
 try:
 while True:
 earliest_m = None
@@ -142,7 +143,11 @@ class Spawn(object):
 self.after = self.buf[pos:posafter]
 self.buf = self.buf[posafter:]
 return earliest_pi
-events = self.poll.poll(self.timeout)
+tnow_s = time.time()
+tdelta_ms = (tnow_s - tstart_s) * 1000
+if tdelta_ms > self.timeout:
+raise Timeout()
+events = self.poll.poll(self.timeout - tdelta_ms)
 if not events:
 raise Timeout()
 c = os.read(self.fd, 1024)
-- 
2.7.0

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

[U-Boot] [PATCH V2 4/8] test/py: log when tests send CTRL-C

[Stephen Warren]

From: Stephen Warren 

Write a note to the log file when a test sends CTRL-C to U-Boot. This
makes it easier to follow what's happening in the logs, especially since
U-Boot doesn't echo the character back to its output, so there's no other
signal of what's going on.

Signed-off-by: Stephen Warren 
Acked-by: Simon Glass 
---
 test/py/u_boot_console_base.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index 418a26bb8e40..433bec6e9fdd 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -212,6 +212,7 @@ class ConsoleBase(object):
 Nothing.
 '''
 
+self.log.action('Sending Ctrl-C')
 self.run_command(chr(3), wait_for_echo=False, send_nl=False)
 
 def drain_console(self):
-- 
2.7.0

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

[U-Boot] [PATCH V2 5/8] test/py: optionally ignore errors from shell commands

[Stephen Warren]

From: Stephen Warren 

Sometimes it's useful to run shell commands and ignore any errors. One
example might be cleanup logic; if a test-case experiences an error, the
cleanup logic might experience an error too, and we don't want that error
to mask the original error, so we want to ignore the subsequent error.

Signed-off-by: Stephen Warren 
Acked-by: Simon Glass 
---
 test/py/multiplexed_log.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/test/py/multiplexed_log.py b/test/py/multiplexed_log.py
index 48f2b51de15f..5059bbfb99c3 100644
--- a/test/py/multiplexed_log.py
+++ b/test/py/multiplexed_log.py
@@ -106,13 +106,17 @@ class RunAndLog(object):
 '''Clean up any resources managed by this object.'''
 pass
 
-def run(self, cmd, cwd=None):
+def run(self, cmd, cwd=None, ignore_errors=False):
 '''Run a command as a sub-process, and log the results.
 
 Args:
 cmd: The command to execute.
 cwd: The directory to run the command in. Can be None to use the
 current directory.
+ignore_errors: Indicate whether to ignore errors. If True, the
+function will simply return if the command cannot be executed
+or exits with an error code, otherwise an exception will be
+raised if such problems occur.
 
 Returns:
 Nothing.
@@ -148,7 +152,7 @@ class RunAndLog(object):
 exception = e
 if output and not output.endswith('\n'):
 output += '\n'
-if exit_status and not exception:
+if exit_status and not exception and not ignore_errors:
 exception = Exception('Exit code: ' + str(exit_status))
 if exception:
 output += str(exception) + '\n'
-- 
2.7.0

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

Re: [U-Boot] [PATCH v2 2/8] drivers: net: phy: micrel: fix build errors with CONFIG_DM_ETH

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:23 AM, Mugunthan V N  wrote:
> When Micrel phy is selected without CONFIG_PHY_MICREL_KSZ9031 or
> CONFIG_PHY_MICREL_KSZ9021 there  is a build error. Fixing this
> by adding proper ifdefs
>
> drivers/net/phy/micrel.c:370:39: error: array type has incomplete element type
>  static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
>^
> drivers/net/phy/micrel.c:372:39: error: array type has incomplete element type
>  static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
>^
> drivers/net/phy/micrel.c: In function ‘ksz9031_of_config’:
> drivers/net/phy/micrel.c:377:23: error: array type has incomplete element type
>   struct ksz90x1_ofcfg ofcfg[] = {
>^
> drivers/net/phy/micrel.c:379:13: error: ‘ksz90x1_rxd_grp’ undeclared (first 
> use in this function)
>{ MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW, 2, ksz90x1_rxd_grp, 4 },
>  ^
> drivers/net/phy/micrel.c:379:13: note: each undeclared identifier is reported 
> only once for each function it appears in
> drivers/net/phy/micrel.c:380:13: error: ‘ksz90x1_txd_grp’ undeclared (first 
> use in this function)
>{ MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW, 2, ksz90x1_txd_grp, 4 },
>  ^
> drivers/net/phy/micrel.c:386:3: warning: implicit declaration of function 
> ‘ksz90x1_of_config_group’ [-Wimplicit-function-declaration]
>ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
>^
> drivers/net/phy/micrel.c:377:23: warning: unused variable ‘ofcfg’ 
> [-Wunused-variable]
>   struct ksz90x1_ofcfg ofcfg[] = {
>^
> drivers/net/phy/micrel.c: At top level:
> drivers/net/phy/micrel.c:370:39: warning: ‘ksz9031_ctl_grp’ defined but not 
> used [-Wunused-variable]
>  static const struct ksz90x1_reg_field ksz9031_ctl_grp[] =
>^
> drivers/net/phy/micrel.c:372:39: warning: ‘ksz9031_clk_grp’ defined but not 
> used [-Wunused-variable]
>  static const struct ksz90x1_reg_field ksz9031_clk_grp[] =
>^
> scripts/Makefile.build:277: recipe for target 'drivers/net/phy/micrel.o' 
> failed
> make[1]: *** [drivers/net/phy/micrel.o] Error 1
> Makefile:1201: recipe for target 'drivers/net/phy' failed
> make: *** [drivers/net/phy] Error 2
> make: *** Waiting for unfinished jobs
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 

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 04/37] video: Add a function to control cache flushing

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Allow the cache-flushing function of a video device to be controlled.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/video/video-uclass.c | 7 +++
>  include/video.h  | 8 
>  2 files changed, 15 insertions(+)

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

Re: [U-Boot] [PATCH v2 03/37] video: Name consoles by their number

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> We must use the console name in the 'stdout' variable to select the one
> we want. At present the name is formed from the driver name with a suffix
> indicating the rotation value.
>
> It seems better to name them sequentially since this can be controlled by
> driver order. So adjust the code to use 'vidconsole' for the first,
> 'vidconsole1' for the second, etc.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/video/vidconsole-uclass.c | 7 ++-
>  include/configs/sandbox.h | 8 
>  2 files changed, 10 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH v2 02/37] gpio: Warn about invalid GPIOs used with the 'gpio' command

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> At present there is no indication that an invalid GPIO is used except that
> the GPIO status is not displayed. Make the error more explicit to avoid
> confusion.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  common/cmd_gpio.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH v2 07/37] pwm: rockchip: Add a PWM driver for Rockchip SoCs

[Simon Glass]

On 21 January 2016 at 19:44, Simon Glass  wrote:
> Add a simple driver which implements the standard PWM uclass interface.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/include/asm/arch-rockchip/pwm.h |  41 
>  drivers/pwm/Kconfig  |   9 +++
>  drivers/pwm/Makefile |   1 +
>  drivers/pwm/rk_pwm.c | 103 
> +++
>  4 files changed, 154 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/pwm.h
>  create mode 100644 drivers/pwm/rk_pwm.c

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

Re: [U-Boot] [PATCH v2 34/37] rockchip: rock2: Bring in device tree files from Linux

[Simon Glass]

On 21 January 2016 at 19:45, Simon Glass  wrote:
> Bring in the current device tree files for rock2 from linux/next commit
> 719d6c1. Hopefully this is the latest one.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/arm/dts/rk3288-rock2-som.dtsi   | 278 
> +++
>  arch/arm/dts/rk3288-rock2-square.dts | 180 +++
>  2 files changed, 458 insertions(+)
>  create mode 100644 arch/arm/dts/rk3288-rock2-som.dtsi
>  create mode 100644 arch/arm/dts/rk3288-rock2-square.dts

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