Re: [U-Boot] [PATCH v2 30/51] x86: Drop all the old pin configuration code

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > We don't need this anymore - we can use device tree and the new pinconfig > driver instead. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: None > >

Re: [U-Boot] [PATCH v2 28/51] x86: Add an ICH6 pin configuration driver

On Mon, Mar 14, 2016 at 1:44 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> Add a driver which sets up the pin configuration on x86 devices with an ICH6 >> (or later) Platform Controller Hub. >> >> The driver is not in the

Re: [U-Boot] [PATCH v2 27/51] x86: link: Add pin configuration to the device tree

On Mon, Mar 14, 2016 at 1:43 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> At present pin configuration on link does not use the standard mechanism, >> but some rather ugly custom code. As a first step to resolving this, add

Re: [U-Boot] [PATCH v2 29/51] x86: gpio: Allow the pinctrl driver to set up the pin config

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > Rather than setting up the pin configuration in the GPIO driver, use the > new pinctrl driver to do it. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2:

Re: [U-Boot] [PATCH v2 26/51] x86: Update microcode for secondary CPUs

On Mon, Mar 14, 2016 at 1:41 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> Each CPU needs to have its microcode loaded. Add support for this so that >> all CPUs will have the same version. >> >> Signed-off-by: Simon Glass

Re: [U-Boot] [PATCH v2 28/51] x86: Add an ICH6 pin configuration driver

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > Add a driver which sets up the pin configuration on x86 devices with an ICH6 > (or later) Platform Controller Hub. > > The driver is not in the pinctrl uclass due to some oddities of the way x86 > devices work: > > - The

Re: [U-Boot] [PATCH v2 27/51] x86: link: Add pin configuration to the device tree

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > At present pin configuration on link does not use the standard mechanism, > but some rather ugly custom code. As a first step to resolving this, add the > pin configuration to the device tree. > > Four of the GPIOs must be

Re: [U-Boot] [PATCH v2 26/51] x86: Update microcode for secondary CPUs

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > Each CPU needs to have its microcode loaded. Add support for this so that > all CPUs will have the same version. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Fix micrcode typo > - Don't try

Re: [U-Boot] [PATCH v2 22/51] x86: Allow I/O functions to use pointers

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > It is common with memory-mapped I/O to use the address of a structure member > to access memory, as in: > >struct some_regs { > u32 ctrl; > u32 data; >} > >struct some_regs *regs = (struct some_regs

Re: [U-Boot] [PATCH v2 24/51] x86: Record the CPU details when starting each core

On Mon, Mar 14, 2016 at 1:15 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> As each core starts up, record its microcode version and CPU ID so these can >> be presented with the 'cpu detail' command. >> >> Signed-off-by: Simon

Re: [U-Boot] [PATCH v2 25/51] x86: ivybridge: Show microcode version for each core

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > Enable the microcode feature so that the microcode version is shown with the > 'cpu detail' command. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: >

Re: [U-Boot] [PATCH v2 23/51] x86: Move common MRC Kconfig options to the common file

On Mon, Mar 14, 2016 at 1:13 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> At present the MRC options are private to ivybridge. Other Intel CPUs also >> use these settings. Move them to a common place. >> >> Signed-off-by:

Re: [U-Boot] [PATCH v2 21/51] x86: Add macros to clear and set I/O bits

On Mon, Mar 14, 2016 at 1:10 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> The clrsetbits_...() macros are useful for working with memory mapped I/O. >> But they do not work with I/O space, as used on x86 machines. >> >> Add

Re: [U-Boot] [PATCH v2 20/51] x86: dts: Drop memory SPD compatible string

On Mon, Mar 14, 2016 at 1:07 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> This is not needed now that the memory controller driver has the SPD data >> in its own node. >> >> Signed-off-by: Simon Glass >>

[U-Boot] [PATCH v3 6/6] doc: dt-bindings: Describe rockchip LVDS interface

I didn't have a common board to enable LVDS. So add this dcocument to help others who want to enable LVDS in their board. Signed-off-by: Jacob Chen Acked-by: Simon Glass --- Changes in v3: - None Changes in v2: - Correct file - Change description

[U-Boot] [PATCH v3 2/6] rockchip: Add a binding file for rk3288 video

Signed-off-by: Jacob Chen Acked-by: Simon Glass --- Changes in v3: - Move dts change to another patch Changes in v2: - New include/dt-bindings/video/rk3288.h | 11 +++ 1 file changed, 11 insertions(+) create mode 100644

[U-Boot] [PATCH v3 5/6] rockchip: video: Add LVDS support in vop driver

LVDS have a different display out mode, add code to get right flag. The vop_ip decied display device and the remote_vop_id decied which vop was being used. So we should use the remote_vop_id to set DCLK_VOP. Signed-off-by: Jacob Chen Acked-by: Simon Glass

[U-Boot] [PATCH v3 1/6] dm: video: Add a operation to display uclass

The current display class only allow to get timing from edid. So add a operation to get timing directly from driver. In driver, I will use fdtdec_decode_display_timing to get timing. Signed-off-by: Jacob Chen Acked-by: Simon Glass --- Changes in v3: -

[U-Boot] [PATCH v3 4/6] rockchip: dts: Add LVDS support

Add these node to be used in rockchip LVDS and VOP driver. Signed-off-by: Jacob Chen Acked-by: Simon Glass --- Changes in v3: - Include bingding file in dts Changes in v2: - None arch/arm/dts/rk3288.dtsi | 47

[U-Boot] [PATCH v2 1/3] Add a binding file for rockchip video

and include it in rk3288 device tree Signed-off-by: Jacob Chen --- arch/arm/dts/rk3288.dtsi | 1 + include/dt-bindings/video/rk3288.h | 11 +++ 2 files changed, 12 insertions(+) create mode 100644 include/dt-bindings/video/rk3288.h diff --git

[U-Boot] [PATCH v2] serial: pl01x: Add support for devices with the rate pre-configured.

For Raspberry Pi, we had the input clock rate to the pl011 fixed in the rpi.c file, but it may be changed by firmware due to user changes to config.txt. Since the firmware always sets up the uart (default 115200 output unless the user changes it), we can just skip our own uart init to simplify

Re: [U-Boot] [PATCH v2 1/3] Add a bingding file for rockchip video

O Oh..wrong title... 2016-03-14 1:45 GMT+08:00 Jacob Chen : > and include it in rk3288 device tree > > Signed-off-by: Jacob Chen > --- > > arch/arm/dts/rk3288.dtsi | 1 + > include/dt-bindings/video/rk3288.h | 11 +++ > 2 files

[U-Boot] [PATCH v2 2/3] rockchip: video: Add a display driver for rockchip LVDS

Some Rockchip SoCs support LVDS output. Add a display driver for this so that these displays can be used on supported boards. Signed-off-by: Jacob Chen --- arch/arm/include/asm/arch-rockchip/lvds_rk3288.h | 97 + drivers/video/rockchip/Makefile

[U-Boot] [PATCH v2 0/3] Add LVDS support for rk3288

This series patches add LVDS support for rk3288. Jacob Chen (3): Add a bingding file for rockchip video rockchip: video: Add a display driver for rockchip LVDS doc: dt-bindings: Describe rockchip LVDS interface arch/arm/dts/rk3288.dtsi | 1 +

Re: [U-Boot] [PATCH v2 17/18] board: Add Qualcomm Dragonboard 410C support

On Sat, Mar 12, 2016 at 10:13:43PM +0100, Mateusz Kulikowski wrote: > On 12.03.2016 00:58, Daniel Glöckner wrote: > > It is also confusing to have the "add" instruction in there without an > > explanation, especially because having it at offset 4 instead of 0 defeats > > its original purpose (MZ

Re: [U-Boot] [PATCH v2 24/51] x86: Record the CPU details when starting each core

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > As each core starts up, record its microcode version and CPU ID so these can > be presented with the 'cpu detail' command. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Don't try to read

Re: [U-Boot] [PATCH v2 23/51] x86: Move common MRC Kconfig options to the common file

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > At present the MRC options are private to ivybridge. Other Intel CPUs also > use these settings. Move them to a common place. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add Kconfig help

Re: [U-Boot] [PATCH v2 16/51] x86: ivybridge: Drop sandybridge_early_init()

On Mon, Mar 14, 2016 at 12:58 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: >> This function was removed in the previous clean-up. Drop it from the header >> file also. >> >> Signed-off-by: Simon Glass >> ---

Re: [U-Boot] [PATCH v2 18/51] x86: Add common SDRAM-init code

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > The code to call the memory reference code is common to several Intel CPUs. > Add common code for performing this init. Intel calls this 'Pre-EFI-Init' > (PEI), where EFI stands for Extensible Firmware Interface. > >

Re: [U-Boot] [PATCH v2] ti_armv7_common: env: Add NFS loading support to default enviroment

On Sunday 13 March 2016 10:48 PM, Andrew F. Davis wrote: > On 03/12/2016 03:58 AM, Lokesh Vutla wrote: >> >> >> On Saturday 12 March 2016 02:34 AM, Andrew F. Davis wrote: >>> NFS loading is similar to net loading except initial files are loaded >>> over NFS instead of TFTP, this removes the need

Re: [U-Boot] [PATCH v2 17/51] x86: Move common PCH code into a common place

Hi Simon, On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > The SATA indexed register write functions are common to several Intel PCHs. > Move this into a common location. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > >

Re: [U-Boot] [PATCH v2 16/51] x86: ivybridge: Drop sandybridge_early_init()

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > This function was removed in the previous clean-up. Drop it from the header > file also. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/include/asm/arch-ivybridge/sandybridge.h

Re: [U-Boot] [PATCH v2 14/51] x86: Rename PORT_RESET to IO_PORT_RESET

On Mon, Mar 14, 2016 at 12:37 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> This same name is used in USB. Add a prefix to distinguish it. >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v2: None

Re: [U-Boot] [PATCH v2 15/51] x86: Move Intel Management Engine code to a common place

On Sat, Mar 12, 2016 at 1:07 PM, Simon Glass wrote: > Some of the Intel ME code is common to several Intel CPUs. Move it into a > common location. Add a header file for report_platform.c also. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng

Re: [U-Boot] [PATCH v2 13/51] x86: Move common CPU code to its own place

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > Some of the Intel CPU code is common to several Intel CPUs. Move it into a > common location along with required declarations. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng >

Re: [U-Boot] [PATCH v2 12/51] x86: Move common LPC code to its own place

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > Some of the LPC code is common to several Intel LPC devices. Move it into a > common location. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: > - Use

Re: [U-Boot] [PATCH v2 14/51] x86: Rename PORT_RESET to IO_PORT_RESET

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > This same name is used in USB. Add a prefix to distinguish it. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/cpu/cpu.c | 4 ++-- >

Re: [U-Boot] [PATCH v2 09/51] x86: Move microcode code to a common location

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > This code is used on several Intel CPUs. Move it into a common location. > > Signed-off-by: Simon Glass > Reviewed-by: Bin Meng > --- > > Changes in v2: > - Rename microcode_intel.c

Re: [U-Boot] [PATCH v2 11/51] x86: Add the root-complex block to common intel registers

On Mon, Mar 14, 2016 at 12:29 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> This is similar to MCH in that it is used in various drivers. Add it to >> the common header. >> >> Signed-off-by: Simon Glass >>

Re: [U-Boot] [PATCH v2 08/51] x86: Move cache-as-RAM code into a common location

On Mon, Mar 14, 2016 at 12:27 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> This cache-as-RAM (CAR) code is common to several Intel chips. Create a new >> intel_common directory and move it in there. >> >> Signed-off-by: Simon

Re: [U-Boot] [PATCH v2 10/51] x86: Create a common header for Intel register access

On Mon, Mar 14, 2016 at 12:28 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> There are several blocks of registers that are accessed from all over the >> code on Intel CPUs. These don't currently have their own driver and it is

Re: [U-Boot] [PATCH v2 11/51] x86: Add the root-complex block to common intel registers

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > This is similar to MCH in that it is used in various drivers. Add it to > the common header. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/cpu/ivybridge/bd82x6x.c | 1

Re: [U-Boot] [PATCH v2 10/51] x86: Create a common header for Intel register access

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > There are several blocks of registers that are accessed from all over the > code on Intel CPUs. These don't currently have their own driver and it is > not clear whether having a driver makes sense. > > An example is the

Re: [U-Boot] [PATCH v2 08/51] x86: Move cache-as-RAM code into a common location

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > This cache-as-RAM (CAR) code is common to several Intel chips. Create a new > intel_common directory and move it in there. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > >

Re: [U-Boot] [PATCH v2 07/51] x86: cpu: Add functions to return the family and stepping

On Mon, Mar 14, 2016 at 12:20 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> These two identifiers can be useful for drivers which need to adjust their >> behaviour depending on the CPU family or stepping (revision). >> >>

Re: [U-Boot] [PATCH v2 01/51] dm: timer: Correct timer init ordering after relocation

On Mon, Mar 14, 2016 at 12:08 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> Commit 1057e6c broke use of the timer with driver model. If the timer is used >> before relocation, then it becomes broken after relocation. This

Re: [U-Boot] [PATCH v2 04/51] syscon: Avoid returning a device on failure

On Mon, Mar 14, 2016 at 12:10 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> If the device cannot be probed, syscon_get_by_driver_data() will still >> return a useful value in its devp parameter. Ensure that it returns NULL >>

Re: [U-Boot] [PATCH v2 05/51] input: i8042: Make sure the keyboard is enabled

On Mon, Mar 14, 2016 at 12:17 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> Add one more step into the init sequence. This fixes the keyboard on samus, >> which otherwise does not work. >> >> Signed-off-by: Simon Glass

Re: [U-Boot] [PATCH v2 06/51] x86: Allow use of serial soon after relocation

On Mon, Mar 14, 2016 at 12:18 PM, Bin Meng wrote: > On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: >> At present on x86 machines with use cache-as-RAM, the memory goes away just >> before board_init_r() is called. This means that serial drivers are >>

Re: [U-Boot] [PATCH 15/69] x86: cpu: Add functions to return the family and stepping

Hi Simon, On Sat, Mar 12, 2016 at 1:04 PM, Simon Glass wrote: > Hi Bin, > > On 10 March 2016 at 21:52, Bin Meng wrote: >> Hi Simon, >> >> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >>> These two identifiers can be useful for

Re: [U-Boot] [PATCH v2 07/51] x86: cpu: Add functions to return the family and stepping

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > These two identifiers can be useful for drivers which need to adjust their > behaviour depending on the CPU family or stepping (revision). > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Use

Re: [U-Boot] [PATCH v2 06/51] x86: Allow use of serial soon after relocation

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > At present on x86 machines with use cache-as-RAM, the memory goes away just > before board_init_r() is called. This means that serial drivers are > no-longer unavailable, until initr_dm() it called, etc. > > Any attempt to

Re: [U-Boot] [PATCH v2 05/51] input: i8042: Make sure the keyboard is enabled

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > Add one more step into the init sequence. This fixes the keyboard on samus, > which otherwise does not work. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Use a #define for the output flush

Re: [U-Boot] [PATCH v2 04/51] syscon: Avoid returning a device on failure

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > If the device cannot be probed, syscon_get_by_driver_data() will still > return a useful value in its devp parameter. Ensure that it returns NULL > instead. > > Signed-off-by: Simon Glass > --- > >

Re: [U-Boot] [PATCH v2 01/51] dm: timer: Correct timer init ordering after relocation

On Sat, Mar 12, 2016 at 1:06 PM, Simon Glass wrote: > Commit 1057e6c broke use of the timer with driver model. If the timer is used > before relocation, then it becomes broken after relocation. This prevents > some x86 boards from booting. Fix it. > > Fixes: 1057e6c (timer: Set

Re: [U-Boot] [PATCH v3 3/6] rockchip: video: Add a display driver for rockchip LVDS

On 13 March 2016 at 21:20, Jacob Chen wrote: > Some Rockchip SoCs support LVDS output. Add a display driver for this so > that these displays can be used on supported boards. > > Signed-off-by: Jacob Chen > --- > > Changes in v3: > - Use

Re: [U-Boot] [PATCH] ls102xa: dm: serial: Disable CONFIG_DM_STDIO for LCD/HDMI display

Hi, Simon, > On 1 March 2016 at 02:06, Alison Wang wrote: > > When LCD/HDMI is connected to LS1021ATWR or LS1021AQDS, the console > > output should be shown on the monitor. > > > > If CONFIG_DM_SERIAL and CONFIG_DM_STDIO are both enabled, serial > > device is registered and

[U-Boot] [PATCH v2 8/9] Allow command-line files to be dropped

These files do not need to be compiled when CONFIG_CMDLINE is disabled. Update the Makefile to reflect this. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- Changes in v2: None common/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2

[U-Boot] [PATCH v2 9/9] Drop various features when the command line is not available

Some features are only useful or meaningful when the command line is present. Ensure that these features are not compiled in when CONFIG_CMDLINE is not enabled. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- Changes in v2: None

[U-Boot] [PATCH v2 6/9] Panic when no command line processing can be performed

Normally board_run_command() will handle command processed. But if for some reason it returns then we should panic to avoid further processing. Signed-off-by: Simon Glass --- Changes in v2: - Use panic() instead of hang() common/main.c | 1 + 1 file changed, 1 insertion(+)

[U-Boot] [PATCH v2 7/9] Allow command code to compile to nothing

When CONFIG_CMDLINE is disabled we need to remove all the command-line code. Most can be removed by dropping the appropriate linker lists from the images, but sub-commands must be dealt with specially. A simple mechanism is used to avoid 'unused static function' errors. Signed-off-by: Simon

[U-Boot] [PATCH v2 5/9] Drop command-processing code when CONFIG_CMDLINE is disabled

Command parsing and processing code is not needed when the command line is disabled. Remove this code in that case. Signed-off-by: Simon Glass --- Changes in v2: - Move the board_run_command() prototype into this patch cmd/help.c| 4 common/cli.c | 17

[U-Boot] [PATCH v2 3/9] arm: x86: Drop command-line code when CONFIG_CMDLINE is disabled

Update the link script to drop this code when not needed. This is only done for two architectures at present. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- Changes in v2: None arch/arm/cpu/u-boot.lds | 3 +++ arch/x86/cpu/u-boot.lds | 4 2

[U-Boot] [PATCH v2 4/9] sandbox: Avoid calling commands when not available

Don't try to run commands when not supported. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- Changes in v2: None arch/sandbox/cpu/start.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/sandbox/cpu/start.c

[U-Boot] [PATCH v2 2/9] Add an option to enable the command line

Add a new Kconfig option for the command line. This is enabled by default, but when disabled it will remove the command line. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- Changes in v2: None README | 8 cmd/Kconfig | 12

[U-Boot] [PATCH v2 0/9] Add CONFIG_CMDLINE to allow removal of all commands

A large chunk of the U-Boot code is its wide variety of commands. For some applications this is not needed, since the boot can be controlled by a board-specific hard-coded boot procedure. Any attempt to use commands, such as running script, will result in an error. U-Boot acts as if it supports

[U-Boot] [PATCH v3 20/21] board: Add Qualcomm Dragonboard 410C support

This commit add support for 96Boards Dragonboard410C. It is board based on APQ8016 Qualcomm SoC, complying with 96boards specification. Features (present out of the box): - 4x Cortex A53 (ARMv8) - 2x USB Host port - 1x USB Device port - 4x LEDs - 1x HDMI connector - 1x uSD connector - 3x buttons

[U-Boot] [PATCH v3 21/21] Add myself as Snapdragon and SPMI maintainer

- Update MAINTAINERS - Update git-mailrc Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: - New patch Changes in v1: None MAINTAINERS| 11 +++ doc/git-mailrc | 3 +++ 2 files

[U-Boot] [PATCH v3 19/21] arm: Add support for Qualcomm Snapdragon family

First supported chip is APQ8016 (that is compatible with MSM8916). Drivers in SoC code: - Reset controller (PSHOLD) - Clock controller (very simple clock configuration for MMC and UART) Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass

[U-Boot] [PATCH v3 18/21] gpio: Add support for Qualcomm PM8916 gpios

This driver supports GPIOs present on PM8916 PMIC. There are 2 device drivers inside: - GPIO driver (4 "generic" GPIOs) - Keypad driver that presents itself as GPIO with 2 inputs (power and reset) Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass

[U-Boot] [PATCH v3 16/21] drivers: spmi: Add support for Qualcomm SPMI bus driver

Support SPMI arbiter on Qualcomm Snapdragon devices. Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass Tested-by: Simon Glass --- Changes in v3: None Changes in v2: - Rename DM_SPMI -> SPMI - Rename p -> priv (in

[U-Boot] [PATCH v3 15/21] spmi: Add sandbox test driver

This patch adds emulated spmi bus controller with part of pm8916 pmic on it to sandbox and tests validating SPMI uclass. Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass --- Changes in v3: - Updated test.dts to include SPMI like

[U-Boot] [PATCH v3 17/21] pmic: Add support for Qualcomm PM8916 PMIC

This PMIC is connected on SPMI bus so needs SPMI support enabled. Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass Tested-by: Simon Glass --- Changes in v3: None Changes in v2: - Add reviewed-by - Reordered Kconfig

[U-Boot] [PATCH v3 13/21] ehci: Add support for Qualcomm EHCI

This driver is able to reconfigure OTG controller into HOST mode. Board can add board-specific initialization as board_prepare_usb(). It requires USB_ULPI_VIEWPORT enabled in board configuration. Signed-off-by: Mateusz Kulikowski Acked-by: Marek Vasut

[U-Boot] [PATCH v3 14/21] drivers: Add SPMI bus uclass

Qualcom processors use proprietary bus to talk with PMIC devices - SPMI (System Power Management Interface). On wiring level it is similar to I2C, but on protocol level, it's multi-master and has simple autodetection capabilities. This commit adds simple uclass that provides bus read/write

[U-Boot] [PATCH v3 11/21] usb: ehci-ci: Add missing registers.

Some registers of usb_ehci were marked as reserved. This may be true for some variants of Chipidea USB core, but they have meaning on other devices. The following registers were added: sbusstatus/sbusmode: AHB-related registers genconfig*: Auxiluary IP core configuration registers.

[U-Boot] [PATCH v3 12/21] ehci-ci.h: drop generic USBCMD fields

Use definitions from ehci.h instead. Signed-off-by: Mateusz Kulikowski Acked-by: Marek Vasut Tested-by: Simon Glass --- Changes in v3: None Changes in v2: - Add Acked-by Changes in v1: None drivers/usb/host/ehci-mpc512x.c | 4

[U-Boot] [PATCH v3 09/21] eth: asix88179: Print packet length properly

Debug printf used '%u' to print size_t variable. This caused warnings on 64-bit machines. Signed-off-by: Mateusz Kulikowski --- Changes in v3: - New patch Changes in v2: None Changes in v1: None drivers/usb/eth/asix88179.c | 2 +- 1 file changed, 1 insertion(+),

[U-Boot] [PATCH v3 07/21] usb: ulpi: Fix viewport_addr type

viewport_addr is address of memory mapped ULPI viewport. It is used only as argument to readl/writel later causing compile warnings on 64-bit devices. This fix changes its type to match pointer size. Signed-off-by: Mateusz Kulikowski --- Changes in v3: - New patch

[U-Boot] [PATCH v3 08/21] usb: ulpi: Fix compile warning in read/write on 64-bit machines.

ulpi_read and ulpi_write are used to read/write registers via ULPI bus. Code generates compilation warnings on 64-bit machines where pointer is cast to u32. This patch drops all but last 8 bits of register address. It is possible, because addresses on ULPI bus are 6- or 8-bit. It is not possible

[U-Boot] [PATCH v3 04/21] ehci-hcd: Add init_after_reset

Some host controllers need addidional initialization after ehci_reset() In non-dm implementation it is possible to use CONFIG_EHCI_HCD_INIT_AFTER_RESET. This patch adds similar option to ehci drivers using dm. Signed-off-by: Mateusz Kulikowski Acked-by: Marek Vasut

[U-Boot] [PATCH v3 06/21] Migrate CONFIG_ULPI* to Kconfig

Move CONFIG_USB_ULPI* from headers to defconfigs for boards that use it. Also - add CONFIG_USB where necesarry - all boards use it, but some are not defining it explicitly. Affected boards: colibri_t20, harmony, mcx, mt_ventoux, twister, zynq_(picozed, zc702, zc706, zed, zybo) Signed-off-by:

[U-Boot] [PATCH v3 05/21] usb: ulpi: Add Kconfig options for ULPI

The following options can be now enabled via defconfig: - CONFIG_USB_ULPI - CONFIG_USB_ULPI_VIEWPORT - CONFIG_USB_ULPI_VIEWPORT_OMAP Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: - Add better

[U-Boot] [PATCH v3 03/21] mmc: Add support for Qualcomm SDHCI controller

Add support for SD/eMMC controller present on some Qualcomm Snapdragon devices. This controller implements SDHCI 2.0 interface but requires vendor-specific initialization. Driver works in PIO mode as ADMA is not supported by U-Boot (yet). Signed-off-by: Mateusz Kulikowski

[U-Boot] [PATCH v3 01/21] serial: Add support for Qualcomm serial port

This driver works in "new" Data Mover UART mode, so will be compatible with modern Qualcomm chips only. Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass Tested-by: Simon Glass --- Changes in v3: - Add

[U-Boot] [PATCH v3 02/21] gpio: Add support for Qualcomm gpio controller

Add support for gpio controllers on Qualcomm Snapdragon devices. This devices are usually called Top Level Mode Multiplexing in Qualcomm documentation. Signed-off-by: Mateusz Kulikowski Reviewed-by: Simon Glass Tested-by: Simon Glass

[U-Boot] [PATCH v3 00/21] Add support for 96boards Dragonboard410C board

Hi All, This is (hopefully) last version of Dragonboard410c series. Sorry for longer delay, but I had too many things to do recently. As always - for "simplicity" this series is available on my github: https://github.com/hallor/u-boot/tree/dragonboard-for-mainline-v3 There are almost no changes

Re: [U-Boot] [PATCH] usb: Add new command to regress USB devices

Dear Simon, In message

Re: [U-Boot] [PATCH v2 1/3] Add a binding file for rockchip video

On 13 March 2016 at 11:52, Jacob Chen wrote: > and include it in rk3288 device tree > > Signed-off-by: Jacob Chen > --- > > arch/arm/dts/rk3288.dtsi | 1 + > include/dt-bindings/video/rk3288.h | 11 +++ > 2 files changed, 12

Re: [U-Boot] [PATCH v2 2/3] rockchip: video: Add a display driver for rockchip LVDS

Hi Jacob, On 13 March 2016 at 11:45, Jacob Chen wrote: > Some Rockchip SoCs support LVDS output. Add a display driver for this so > that these displays can be used on supported boards. Please can you include a change log for v2? If you can using patman you can add

Re: [U-Boot] [PATCH v2 0/3] Add LVDS support for rk3288

Hi Jacob, On 13 March 2016 at 11:45, Jacob Chen wrote: > This series patches add LVDS support for rk3288. > > > Jacob Chen (3): > Add a bingding file for rockchip video > rockchip: video: Add a display driver for rockchip LVDS > doc: dt-bindings: Describe rockchip

Re: [U-Boot] [PATCH v2] ti_armv7_common: env: Add NFS loading support to default enviroment

On 03/12/2016 03:58 AM, Lokesh Vutla wrote: > > > On Saturday 12 March 2016 02:34 AM, Andrew F. Davis wrote: >> NFS loading is similar to net loading except initial files are loaded >> over NFS instead of TFTP, this removes the need for multiple different >> protocol servers running on the host

[U-Boot] [PATCH 4/5] rockchip: video: Add LVDS support in vop driver

LVDS have a different display out mode, add code to get right flag. The vop_ip decied display device and the remote_vop_id decied which vop was being used. So we should use the remote_vop_id to set DCLK_VOP. Signed-off-by: Jacob Chen Signed-off-by: jacob

[U-Boot] [PATCH 5/5] doc: dt-bindings: Describe rockchip LVDS interface

I didn't have a common board to enable LVDS. So add this dcocument to help others who want to enable LVDS in their board. Signed-off-by: Jacob Chen Signed-off-by: jacob --- doc/device-tree-bindings/video/rockchip-lvds.txt | 77

[U-Boot] [PATCH 3/5] rockchip: dts: Add LVDS support

Add these node to be used in rockchip LVDS and VOP driver. Signed-off-by: Jacob Chen Signed-off-by: jacob --- arch/arm/dts/rk3288.dtsi | 46 +- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git

Re: [U-Boot] [U-BOOT.V2] usb: xhci: Fix vendor command error if the request

Hi Marek Sorry for late replay. On 6 March 2016 at 13:14, Marek Vasut wrote: > On 03/05/2016 06:53 PM, Anand Moon wrote: >> Hi Marek, > > Hi! > >> On 5 March 2016 at 18:00, Marek Vasut wrote: >>> On 03/05/2016 09:43 AM, Anand Moon wrote: From: Ted Chen

[U-Boot] [PATCH 1/5] dm: video: Add a operation to display uclass

The current display class only allow to get timing from edid. So add a operation to get timing directly from driver. In driver, I will use fdtdec_decode_display_timing to get timing. Signed-off-by: Jacob Chen Signed-off-by: jacob ---

[U-Boot] [PATCH 0/5] Add LVDS support for rk3288.

From: jacob This series patches add LVDS support for rk3288. I'm a newbie in submiting patches. If there are something wrong, hope to get help. Jacob Chen (5): dm: video: Add a operation to display uclass rockchip: video: Add a display driver for rockchip LVDS

[U-Boot] [PATCH 2/5] rockchip: video: Add a display driver for rockchip LVDS

Some Rockchip SoCs support LVDS output. Add a display driver for this so that these displays can be used on supported boards. Signed-off-by: Jacob Chen Signed-off-by: jacob --- arch/arm/include/asm/arch-rockchip/lvds_rk3288.h | 99 +

[U-Boot] [PATCH v3 1/4] dm: usb: Unbind old block devices when shutting down USB

When 'usb start' is used, block devices are created for any USB flash sticks and disks, etc. When 'usb stop' is used, these block devices are currently not removed. We don't want old block devices hanging around since they can still be visible to U-Boot. Therefore, when USB is shut down, remove

  1   2   >