Add a SATA driver for broadwell. This supports connecting an SSD and the
usual U-Boot commands to read and write data.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2: None
arch/x86/cpu/broadwell/Makefile | 1 +
arch/x86/cpu/broadwell/sata.c | 269 +
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 for the moved options
- Fix tab indentation
arch/x86/Kconfig | 61 +
There is an extra line in the comment in the header. Remove it.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
include/configs/x86-chromebook.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/configs/x86-chromebook.h b/include/configs/x86-chromebook.h
inde
This adds the broadwell architecture, with the CPU driver and some useful
header files.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2: None
arch/x86/Kconfig| 1 +
arch/x86/cpu/Makefile | 1 +
arch/x86/cpu/broadwell/Kconfi
Before set value for a gpio, need to set its direction to
output first.
Signed-off-by: Peng Fan
Cc: Przemyslaw Marczak
Cc: Simon Glass
---
drivers/power/regulator/fixed.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
We may have pinmux settings for pinctrl device, like the following
example:
"
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog_1>;
imx6ul-evk {
pinctrl_hog_1: hoggrp-1 {
fsl,pins = <
MX6UL_
Broadwell uses a binary blob called the memory reference code (MRC) to start
up its SDRAM. This is similar to ivybridge so we can mostly use common code
for running this blob.
Signed-off-by: Simon Glass
---
Changes in v2:
- Rename sdram to mrc
arch/x86/cpu/broadwell/Makefile|
Add a driver for the broadwell low-power platform controller hub.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2:
- Use setio_32() instead of setio_le32(), etc.
- Use capitals for header guard
arch/x86/cpu/broadwell/Makefile | 2 +
arch/x86/cpu/broadwell/iobp.c
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 GPIO controller is not present in I/O space until it is set up
- This is done by writing
Broadwell requires quite a bit of power-management setup. Add code to set
this up correctly.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2:
- Use capitals for header guard
arch/x86/cpu/broadwell/Makefile | 1 +
arch/x86/cpu/broadwell/power_state.c | 89 ++
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 some macros to provide similar features for I/O.
Signed-off-by: Simon Glass
---
Changes in v2:
- Use setio_32() instead of setio_le32(), etc.
arch/x86/i
Make a few minor updates to make the meaning clearer.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/doc/device-tree-bindin
Provide a way to determine the HSIO (high-speed I/O) version supported by
the Intel Management Engine (ME) implementation on the platform.
Signed-off-by: Simon Glass
---
Changes in v2: None
arch/x86/cpu/broadwell/Makefile | 1 +
arch/x86/cpu/broadwell/me.c | 57 +++
Add an address which can be used for loading and running the reference code
when needed.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
include/configs/x86-chromebook.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/x86-chromebook.h b/include/c
Add a driver for the broadwell northbridge. This sets up the location of
several blocks of registers.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2: None
arch/x86/cpu/broadwell/Makefile | 1 +
arch/x86/cpu/broadwell/northbridge.c | 59 ++
Broadwell needs a special binary blob to set up the PCH. Add code to run
this on start-up.
Signed-off-by: Simon Glass
---
Changes in v2:
- Fix comment style
arch/x86/cpu/broadwell/Makefile | 1 +
arch/x86/cpu/broadwell/refcode.c | 113 +++
2 files changed
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
arch/x86/include/asm/gpio.h | 141 --
board/coreboot/coreboot/coreboot.c| 5 --
GPIO pins need to be set up on start-up. Add a driver to provide this,
configured from the device tree.
The binding is slightly different from the existing ICH6 binding, since that
is quite verbose. The new binding should be just as extensible.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
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 microcode version on quark
- Use gd->arch.x86_device instead of reading the device ID again
arch/x86/cpu/in
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:
- Rename subject to 'core' instead of 'code'
arch/x86/cpu/ivybridge/model_206ax.c | 3 ++-
1 file changed, 2 insertions(+), 1
Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.
In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong
Add a driver for the broadwell LPC (low-pin-count peripheral). This mostly
uses common code.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2:
- Use capitals for header guard
arch/x86/cpu/broadwell/Makefile | 1 +
arch/x86/cpu/broadwell/lpc.c | 77 ++
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 available before relocation (for SDRAM pin
strapping).
Signed-off-by: Simon Glass
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 to update microcode on FSP platforms
arch/x86/cpu/cpu.c | 1 +
arch/x86/cpu/intel_common/ca
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.
Signed-off-by: Simon Glass
---
Changes in v2:
- Rename sdram_common.c to mrc.c
arch/x
Add a GPIO driver for the GPIO peripheral found on broadwell devices.
Signed-off-by: Simon Glass
Acked-by: Bin Meng
---
Changes in v2:
- Use setio_32() instead of setio_le32(), etc.
- Fix 'configure' typo
drivers/gpio/Kconfig| 9 ++
drivers/gpio/Makefile | 1
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: None
configs/bayleybay_defconfig | 2 +
configs/cougarcanyon2_defconfig | 2 +
configs/crownbay_defconfig |
Add a video driver for Intel's broadwell integrated graphics controller.
This uses a binary blob for most init, with the driver just performing a few
basic tasks.
This driver supports VESA as the mode-setting mechanism. Since most boards
don't support driver model yet with VESA, a special case is
Intel has invented yet another binary blob which firmware is required to
run. This is run after SDRAM is ready. It is linked to load at a particular
address, typically 0, but is a relocatable ELF so can be moved if required.
Add support for this in the build system. The file should be placed in th
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
arch/x86/cpu/intel_common/Makefile| 1 +
arch/x86/cpu/intel_common/pch_common.c| 25 ++
arch/x86/cpu/ivybrid
This is not needed now that the memory controller driver has the SPD data
in its own node.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
arch/x86/dts/chromebook_link.dts | 1 -
include/fdtdec.h | 1 -
lib/fdtdec.c | 1 -
3 files c
This is a little easier on the eyes, particularly when the backlight is set
to maximum.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
include/configs/x86-chromebook.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/x86-chromebook.h b/include/co
Update a few points which have become out-of-date.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2:
- Correct naming of Intel platforms
doc/README.x86 | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86
index
This adds basic support for chromebook_samus. This is the 2015 Pixel and
is based on an Intel broadwell platform.
Supported so far are:
- Serial
- SPI flash
- SDRAM init (with MRC cache)
- SATA
- Video (on the internal LCD panel)
- Keyboard
Various less-visible drivers are provided to make the ab
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 | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/arch-ivybridge/sandybridge.h
b/
Adjust the existing implementation to use the new common SDRAM init code.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2:
- Rename sdram to mrc
arch/x86/cpu/ivybridge/sdram.c | 394 +
1 file changed, 83 insertions(+), 311 deletions(-
Add a function to set the ID in the IOAPIC.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
---
Changes in v2: None
arch/x86/cpu/ioapic.c | 16
arch/x86/include/asm/ioapic.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/arch/x86/cpu/ioapic.c b/arch/x86/cpu
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
---
Changes in v2:
- Use capitals for header guard
arch/x86/cpu/intel_common/Makefile | 2
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 ++--
arch/x86/cpu/intel_common/cpu.c | 4 ++--
arch/x86/include/asm/processor.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
dif
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
arch/x86/cpu/Makefile | 1 +
arch/x86/cpu/intel_common/Makefile | 7 +++
arch/x86
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
---
Changes in v2:
- Use capitals for header guard
arch/x86/cpu/intel_common/Makefile| 1 +
arch/x86/cpu/inte
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 Memory Controller Hub (MCH). We map it to a known location
on some Intel chips (mostl
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 +
arch/x86/cpu/ivybridge/lpc.c | 6 --
arch/x86/include/asm/arch-ivybridge/pch.h | 5 ---
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 use printf() within this period will cause a hang.
To fix this, mark the serial de
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 *)BASE_ADDRESS;
writel(1, ®->ctrl);
writel(2, ®->data);
This does not currently wo
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 gd->arch.x86_mask to get the stepping value
arch/x86/cpu/cpu.c | 10 ++
arch/x86/include/
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 command
- Adjust the code order slightly
drivers/input/i8042.c | 4
include/i8042.h | 1 +
2
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 capitals for header guard
- Move cougarcanyon lpc_common.h include to this patch
arch/x86/cpu/intel_common/Makefile|
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 to microcode.c
arch/x86/cpu/intel_common/Makefile| 3 +++
arch/x86/cpu/intel_common/car.S
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
---
Changes in v2: None
drivers/core/syscon-uclass.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/c
At present samus reports about 5600 DMIPS. With the default iteration count
this is OK, but if 10 million runs are performed it overflows. Fix it.
Signed-off-by: Simon Glass
---
Changes in v2: None
lib/dhry/cmd_dhry.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/
This is missing, with causes lldiv() to fail on boards with use the private
libgcc. Add the missing routine.
Code is available for using the CLZ instruction but it is not enabled at
present.
Signed-off-by: Simon Glass
---
Changes in v2: None
arch/arm/lib/Makefile| 3 +-
arch/arm/lib/_ul
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 up the real timer after driver model is available)
Signed-off-by: Simon Glass
-
Hi Bin,
On 11 March 2016 at 01:54, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Add a video driver for Intel's broadwell integrated graphics controller.
>> This uses a binary blob for most init, with the driver just performing a few
>> basic tasks.
>
> W
Hi Bin,
On 11 March 2016 at 01:34, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Provide a way to determine the HSIO (high-speed I/O) version supported by
>> the Intel Management Engine (ME) implementation on the platform.
>>
>> Signed-off-by: Simon Glass
Hi Bin,
On 11 March 2016 at 01:46, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
>> without any 16-bit init. This can help during development by allowing U-Boot
>> to avoid doing al
This series adds support for samus, the Chromebook Pixel 2015. Since it is
only the second board added that does not use an FSP, there is quite a bit
of refactoring involved to avoid code duplication.
Samus uses roughly the same binary blobs as link, except now there is one
more called the referen
Hi Bin,
On 11 March 2016 at 01:30, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Broadwell uses a binary blob called the memory reference code (MRC) to start
>> up its SDRAM. This is similar to ivybridge so we can mostly use common code
>> for running thi
Hi Bin,
On 11 March 2016 at 00:29, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Intel has invented yet another binary blob which firmware is required to
>> run. This is run after SDRAM is ready. It is linked to load at a particular
>> address, typically
Hi Bin,
On 10 March 2016 at 22:27, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, 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
Hi Bin,
On 10 March 2016 at 21:31, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:27 AM, 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, u
Hi Bin,
On 10 March 2016 at 20:25, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:27 AM, 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
Hi Bin,
On 10 March 2016 at 20:28, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:27 AM, 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.
>
> Shouldn't t
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 drivers which need to adjust their
>> behaviour depending on the CPU family or stepping (revision).
>>
>> Signed-off-by: Simon Glass
Hi Simon,
On Fri, Mar 11, 2016 at 05:33:05PM -0700, Simon Glass wrote:
>Hi Peng,
>
>On 10 March 2016 at 01:57, Peng Fan wrote:
>> Support Driver Model for fsl esdhc driver.
>>
>> In order to minimize the change, reuse the fsl_esdhc_initialize function.
>> This new way is to fill an fsl_esdhc_cfg
Hi Bin,
On 11 March 2016 at 00:48, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> > This series adds support for samus, the Chromebook Pixel 2015. Since it is
> > only the second board added that does not use an FSP, there is quite a bit
> > of refactorin
Hello Marek Vasut
I am working on u-boot 2016.01.
Using a platform with DWC3 USB 3.0 controller.
My objective is to configure the USB in device mode and it gets exposed to an
X86 as a USB mass storage.
The memory exposed would be a SATA disk.
Is it possible to do it via ums command?
I gave it
On Sun, Feb 07, 2016 at 09:57:37PM +0100, Mateusz Kulikowski wrote:
> U-Boot boots chained with fastboot in 64-bit mode.
> --- /dev/null
> +++ b/board/qualcomm/dragonboard410c/head.S
> @@ -0,0 +1,28 @@
> +/*
> + * Little-Kernel/Fastboot header for proper chain-loading
> + *
> + * (C) Copyright 201
Configure the NAND device, define partition sizes, and create
the environment space for Cygnus and NSP boards.
Signed-off-by: Steve Rae
---
Changes in v2: None
arch/arm/include/asm/arch-bcmcygnus/configs.h | 33 +++
arch/arm/include/asm/arch-bcmnsp/configs.h| 33 +++
- add missing declaration
- update debug output format specifiers
Signed-off-by: Steve Rae
---
the checkpatch warning:
warning: cmd/mtdparts.c,1494: quoted string split across lines
is for the existing code; it is not introduced with this change...
Changes in v2: None
cmd/mtdparts.c
From: Jiandong Zheng
Add support for the iproc NAND, and enable on Cygnus and NSP boards.
Signed-off-by: Jiandong Zheng
Signed-off-by: Steve Rae
---
There was a previous attempt to implement this "iproc NAND"
(see: http://patchwork.ozlabs.org/patch/505399), however, due to the
amount of change
Enable MTD support on Cygnus and NSP boards.
Signed-off-by: Steve Rae
---
Changes in v2: None
arch/arm/include/asm/arch-bcmcygnus/configs.h | 6 ++
arch/arm/include/asm/arch-bcmnsp/configs.h| 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/include/asm/arch-bcmcygnus/
Hi Peng,
On 10 March 2016 at 01:57, Peng Fan wrote:
> Support Driver Model for fsl esdhc driver.
>
> In order to minimize the change, reuse the fsl_esdhc_initialize function.
> This new way is to fill an fsl_esdhc_cfg struture and pass it
> to fsl_esdhc_initialize, just like the code in different
+Stephen
Hi Jagan,
On 11 March 2016 at 01:00, Jagan Teki wrote:
>
> Hi,
>
> Did anyone encounter this issue? please let me know for any inputs.
>
>arm: + venice2
> +drivers/mtd/spi-nor/built-in.o: In function `spi_nor_write':
> +build/../drivers/mtd/spi-nor/spi-nor.c:585: undefined re
Hi Stefan,
On 11 March 2016 at 09:28, Stefan Roese wrote:
> Hi Simon,
>
>
> On 09.03.2016 18:11, Simon Glass wrote:
>>
>> On 9 March 2016 at 09:15, Stefan Roese wrote:
>>>
>>>
>>> Hi Simon,
>>>
>>> On 09.03.2016 00:33, Simon Glass wrote:
>>>
>>>
>>>
>>> I'm currently struggling with the USB
On Mon, 2016-02-29 at 19:03 -0700, Simon Glass wrote:
> Hi Sjoerd,
>
> On 28 February 2016 at 14:25, Sjoerd Simons
> wrote:
> >
> >
> > diff --git a/drivers/net/gmac_rk3288.c b/drivers/net/gmac_rk3288.c
> > new file mode 100644
> > index 000..5400b2c
> > --- /dev/null
> > +++ b/drivers/net/
NFS loading works on DRA7 variants, remove the undefinition.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
---
Changes from v1:
- Remove undefinition from dra74 and am57xx while we are here
configs/am57xx_evm_defconfig | 1 -
configs/dra72_evm_defconfig | 1 -
config
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 and allows the use of a single
network file system containing boot related files in their usual
in-filesystem directory.
On 03/11/2016 02:29 PM, Andrew F. Davis wrote:
> On 03/11/2016 09:38 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 and allows the u
On 03/11/2016 07:26 AM, Sriram Dash wrote:
> Move usb device-tree fixup framework from ehci-fsl.c to common place so
> that it can be used by other drivers as well (xhci-fsl.c).
>
> Signed-off-by: Ramneek Mehresh
> Signed-off-by: Sriram Dash
> ---
> Changes in v4:
> - Retain copywrite info
>
On 03/11/2016 07:26 AM, Sriram Dash wrote:
> fdt_usb_get_node_type() to return error code instead of pointer.
This sentence makes no sense.
> Signed-off-by: Sriram Dash
> Signed-off-by: Rajesh Bhagat
> ---
> drivers/usb/common/fsl-dt-fixup.c | 25 ++---
> 1 file changed, 14
On 03/11/2016 07:26 AM, Sriram Dash wrote:
> Call fdt_usb_get_node_type() from fdt_fixup_usb_mode_phy_type() to
> avoid code duplication.
>
> Signed-off-by: Sriram Dash
> Signed-off-by: Rajesh Bhagat
> ---
> Changes in v4:
> - Make minimal modification to code
> Changes in v3:
> - Move the d
On 03/11/2016 07:26 AM, Sriram Dash wrote:
> Enables usb device-tree fixup code to incorporate xhci controller
>
> Signed-off-by: Ramneek Mehresh
> Signed-off-by: Sriram Dash
> ---
> Changes in v4:
> - Use a terminating entry in the array for getting node type for controller
> Changes in v3:
>
On 03/11/2016 09:38 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 and allows the use of a single
> network file system containing boot
On Fri, Mar 11, 2016 at 12:18 PM, Scott Wood wrote:
> On Fri, 2016-03-11 at 12:13 -0800, Steve Rae wrote:
>> On Fri, Mar 11, 2016 at 11:55 AM, Scott Wood wrote:
>> > On Fri, 2016-03-11 at 11:47 -0800, Steve Rae wrote:
>> > > On Fri, Mar 11, 2016 at 11:29 AM, Scott Wood wrote:
>> > > > On Thu, 20
On Fri, 2016-03-11 at 12:13 -0800, Steve Rae wrote:
> On Fri, Mar 11, 2016 at 11:55 AM, Scott Wood wrote:
> > On Fri, 2016-03-11 at 11:47 -0800, Steve Rae wrote:
> > > On Fri, Mar 11, 2016 at 11:29 AM, Scott Wood wrote:
> > > > On Thu, 2016-03-10 at 14:26 -0800, Steve Rae wrote:
> > > > > From: J
On Fri, Mar 11, 2016 at 11:55 AM, Scott Wood wrote:
> On Fri, 2016-03-11 at 11:47 -0800, Steve Rae wrote:
>> On Fri, Mar 11, 2016 at 11:29 AM, Scott Wood wrote:
>> > On Thu, 2016-03-10 at 14:26 -0800, Steve Rae wrote:
>> > > From: Jiandong Zheng
>> > >
>> > > Add support for the iproc NAND, and
Hello Jagan,
On Sat, 12 Mar 2016 00:41:25 +0530, Jagan Teki
wrote:
> Hi Albert,
>
> On 12 March 2016 at 00:17, Albert ARIBAUD wrote:
> > Hello Jagan,
> >
> > On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki
> > wrote:
> >> On 11 March 2016 at 07:50, Marek Vasut wrote:
> >> > The stm_is_locked_s
On Thu, 2016-03-10 at 14:26 -0800, Steve Rae wrote:
> From: Jiandong Zheng
>
> Add support for the iproc NAND, and enable on Cygnus and NSP boards.
>
> Signed-off-by: Jiandong Zheng
> Signed-off-by: Steve Rae
> ---
> There was a previous attempt to implement this "iproc NAND"
> (see: http://pa
Hi Albert,
On 12 March 2016 at 00:17, Albert ARIBAUD wrote:
> Hello Jagan,
>
> On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki
> wrote:
>> On 11 March 2016 at 07:50, Marek Vasut wrote:
>> > The stm_is_locked_sr() function is picked from Linux kernel. For reason
>> > unknown, the 64bit data types
Hello Jagan,
On Fri, 11 Mar 2016 12:09:37 +0530, Jagan Teki
wrote:
> On 11 March 2016 at 07:50, Marek Vasut wrote:
> > The stm_is_locked_sr() function is picked from Linux kernel. For reason
> > unknown, the 64bit data types used by the function and present in Linux
> > were replaced with 32bit
Hi,
On 11-03-16 18:53, Stephen Warren wrote:
On 03/11/2016 07:55 AM, Stefan Roese wrote:
My current x86 platform (Bay Trail, not in mainline yet) has a quite
complex USB infrastructure with many USB hubs. Here the USB scan takes
an incredible huge amount of time:
starting USB...
USB0: USB E
On 03/11/2016 07:44 PM, Jagan Teki wrote:
> On 12 March 2016 at 00:03, Marek Vasut wrote:
>> On 03/11/2016 07:07 PM, Jagan Teki wrote:
>>> On 11 March 2016 at 23:32, Marek Vasut wrote:
On 03/11/2016 06:34 PM, Jagan Teki wrote:
> On 11 March 2016 at 17:59, Marek Vasut wrote:
>> On 03
On 12 March 2016 at 00:03, Marek Vasut wrote:
> On 03/11/2016 07:07 PM, Jagan Teki wrote:
>> On 11 March 2016 at 23:32, Marek Vasut wrote:
>>> On 03/11/2016 06:34 PM, Jagan Teki wrote:
On 11 March 2016 at 17:59, Marek Vasut wrote:
> On 03/11/2016 07:39 AM, Jagan Teki wrote:
>> On 11
On 03/11/2016 07:07 PM, Jagan Teki wrote:
> On 11 March 2016 at 23:32, Marek Vasut wrote:
>> On 03/11/2016 06:34 PM, Jagan Teki wrote:
>>> On 11 March 2016 at 17:59, Marek Vasut wrote:
On 03/11/2016 07:39 AM, Jagan Teki wrote:
> On 11 March 2016 at 07:50, Marek Vasut wrote:
>> The s
Thanks for this clarification...
On Fri, Mar 11, 2016 at 10:18 AM, Tom Rini wrote:
> On Fri, Mar 11, 2016 at 10:07:46AM -0800, Steve Rae wrote:
>
>> Is it expected the _every_ CONFIG_* and CONFIG_SYS_* will be moved to
>> Kconfig?
>> What about #defines that will absolutely never used by anyone
On Fri, Mar 11, 2016 at 10:07:46AM -0800, Steve Rae wrote:
> Is it expected the _every_ CONFIG_* and CONFIG_SYS_* will be moved to Kconfig?
> What about #defines that will absolutely never used by anyone else?
> for example, I (may) have a code fragment that distinguishes between
> "CONFIG_CYGNUS"
On 11 March 2016 at 23:32, Marek Vasut wrote:
> On 03/11/2016 06:34 PM, Jagan Teki wrote:
>> On 11 March 2016 at 17:59, Marek Vasut wrote:
>>> On 03/11/2016 07:39 AM, Jagan Teki wrote:
On 11 March 2016 at 07:50, Marek Vasut wrote:
> The stm_is_locked_sr() function is picked from Linux k
Is it expected the _every_ CONFIG_* and CONFIG_SYS_* will be moved to Kconfig?
What about #defines that will absolutely never used by anyone else?
for example, I (may) have a code fragment that distinguishes between
"CONFIG_CYGNUS" and "CONFIG_NSPLUS"...
Would these need to be Kconfig? or would tha
On 03/11/2016 06:34 PM, Jagan Teki wrote:
> On 11 March 2016 at 17:59, Marek Vasut wrote:
>> On 03/11/2016 07:39 AM, Jagan Teki wrote:
>>> On 11 March 2016 at 07:50, Marek Vasut wrote:
The stm_is_locked_sr() function is picked from Linux kernel. For reason
unknown, the 64bit data types
1 - 100 of 168 matches
Mail list logo
