The board select menu in arch/arm/Kconfig is still big.
To slim down it, this commit moves AT91 boards to
arch/arm/mach-at91/Kconfig.
Also, consolidate config SYS_SOC in each board Kconfig.
The Kconfig files under board/ directory were modified with the
following command:
find board -name
This commit moves source files as follows:
arch/arm/cpu/arm920t/at91/* - arch/arm/mach-at91/arm920t/*
arch/arm/cpu/arm926ejs/at91/* - arch/arm/mach-at91/arm926ejs/*
arch/arm/cpu/armv7/at91/* - arch/arm/mach-at91/armv7/*
arch/arm/cpu/at91-common/*- arch/arm/mach-at91/*
Move arch/arm/include/asm/arch-uniphier/*
- arch/arm/mach-uniphier/include/mach/*
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
MAINTAINERS | 1 -
.../asm/arch-uniphier = mach-uniphier/include/mach}/arm-mpcore.h
Move
arch/arm/cpu/armv7/uniphier/* - arch/arm/mach-uniphier/*
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
MAINTAINERS | 2 +-
arch/arm/Kconfig| 2 +-
This commit moves files as follows:
arch/arm/cpu/arm720t/tegra20/* - arch/arm/mach-tegra/tegra20/*
arch/arm/cpu/arm720t/tegra30/* - arch/arm/mach-tegra/tegra30/*
arch/arm/cpu/arm720t/tegra114/* - arch/arm/mach-tegra/tegra114/*
arch/arm/cpu/arm720t/tegra124* -
This series can be applied on the current u-boot/master
(commit 37b608a52dcb133)
Buildman test passed.
$ tools/buildman/buildman -s -b mach arm
boards.cfg is up to date. Nothing to do.
Summary of 22 commits for 474 boards (8 threads, 1 job per thread)
01: powerpc: remove icecube_5200, Lite5200,
Move
arch/arm/cpu/arm926ejs/kirkwood/* - arch/arm/mach-kirkwood/*
Note:
Perhaps, can we merge arch/arm/mach-kirkwood and
arch/arm/mvebu-common into arch/arm/mach-mvebu, like Linux?
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Luka
Move arch/arm/include/asm/arch-kirkwood/*
- arch/arm/mach-kirkwood/include/mach/*
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Luka Perkov luka.per...@sartura.hr
Cc: Stefan Roese s...@denx.de
---
MAINTAINERS
Some buses need to set up their devices before they can be used. This setup
may well be common to all buses in a particular uclass. Support a common
pre-probe method for the uclass, called before any bus devices are probed.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Masahiro Yamada
This has moved to driver model so we don't need the fdtdec support.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
include/fdtdec.h | 1 -
lib/fdtdec.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index
I2C is now deprecated on ARM platforms and there are no devices that use it
with the v3 protocol. We can't require v3 support if we want to support I2C.
Adjust the error handling to suit.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Add patches to tidy up
At present we go through various contortions to store the I2C's chip
address in its private data. This only exists when the chip is active so
must be set up when it is probed. Until the device is probed we don't
actually record what address it will appear on.
However, now that we can support
Now that we have new bus features, update README.txt and the SPI docs to
explain these.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Drop RFC prefix since this series has been properly tested now
- Update commit message to describe immuatable platform data
This is no-longer needed since all platforms use SPI for cros_ec.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Add patches to tidy up cros_ec using new I2C/SPI features
drivers/misc/cros_ec_spi.c | 51 ++
1
For buses it is common for parents to need to know the address of the child
on the bus, the bus speed to use for that child, and other information. This
can be provided in platform data attached to each child.
Add driver model support for this, including auto-allocation which can be
requested
These have moved to driver model so we don't need the fdtdec support.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
include/fdtdec.h | 6 --
lib/fdtdec.c | 6 --
2 files changed, 12 deletions(-)
diff --git a/include/fdtdec.h
At present we try to use the 'reg' property and device tree aliases to give
devices a sequence number. The 'reg' property is often actually a memory
address, so the sequence numbers thus-obtained are not useful. It would be
better if the devices were just sequentially numbered in that case. In
At present we go through various contortions to store the SPI slave's chip
select in its private data. This only exists when the slave is active so
must be set up when it is probed. Until the device is probed we don't
actually know what chip select it will appear on.
However, now that we can
In many cases the per-child private data for a device's children is defined
by the uclass rather than the individual driver. For example, a SPI bus
needs to store information about each of its children, but all SPI drivers
store the same information. It makes sense to allow the uclass to define
Use a single exit point when we have an error and add debugging there.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
drivers/mtd/spi/sandbox.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/sandbox.c
Allow parent drivers to be called when a new child is bound to them. This
allows a bus to set up information it needs for that child.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v3: None
Changes in v2: None
In many cases the child platform data for a device's children is defined by
the uclass rather than the individual devices. For example, a SPI bus needs
to know the chip select and speed for each of its children. It makes sense
to allow this information to be defined the SPI uclass rather than each
Make the error handling more standard to make it easier to build on top of
it. Also correct a bug in the error path where there is no parent.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v3: None
Changes in v2: None
Update the driver model support, and remove the old code. Change snow to
use this new support.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Add patches to tidy up cros_ec using new I2C/SPI features
drivers/misc/cros_ec_i2c.c | 107
At present we use struct spi_slave as our device pointer in a lot of places
to avoid changing the old SPI API. At some point this will go away.
But for now, it is better if the SPI uclass sets up this pointer, rather
than relying on passing it into the device when it is probed. We can use the
new
For buses, after a child is bound, allow the uclass to perform some
processing. This can be used to figure out the address of the child (e.g.
the chip select for SPI slaves) so that it is ready to be probed.
This avoids bus drivers having to repeat the same process, which really
should be done by
This is common to all SPI drivers and specifies a structure used by the
uclass. It makes more sense to define it in the uclass.
Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
This is useful to check which uclass a device is in.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
drivers/core/device.c | 5 +
include/dm/device.h | 8
test/dm/core.c| 11 +++
3 files changed, 24 insertions(+)
diff
We don't want to bind devices which should never be used.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes in v3: None
Changes in v2:
- Add patches to tidy up cros_ec using new I2C/SPI features
drivers/core/root.c | 5 +
1 file
CONFIG_TARGET_FOO was only used in board/sunxi/Makefile to select the
dram config for sun5i and sun7i boards and in board/sunxi/gmac.c for some
special handling of the bananapi/bananapro (both sun7i), all sun5i and sun7i
boards have been moved over to using a single dram_sun5i_autoconfig file,
and
On both my A13-OLinuxIno and my A13-OLinuxIno-Micro, the vga output gives an
unstable image when active low v or hsync is used, so when an external vga dac
is used force v and hsync active high independent of what the modeline says.
This fixes the unstable image.
Signed-off-by: Hans de Goede
Currently we've separate detailed dram settings for all sun5i boards, this
moves them over to using auto dram configuration so that we can get rid of
all the per board dram_foo.c files.
This has been tested on a A10s-Olinuxino, A13-Olinuxino, A13-OlinuxinoM,
mk802-a10s and r7-tv-dongle board.
And use this to set the GMAC Transmit Clock Delay Chain value on Banana
boards, rather then keying of CONFIG_TARGET_FOO.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 2 ++
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 2 ++
There are missing parameters in help which fpga dump command
requires.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
common/cmd_fpga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c
index 484a6c6ce036..7f99aabf8a5c 100644
---
Hi Nikita Kiryanov,
+ Andreas, Tom
On 01/23/2015 09:20 AM, Bo Shen wrote:
Hi Nikita Kiryanov,
On 01/22/2015 09:10 PM, Nikita Kiryanov wrote:
Hi Bo,
On 01/21/2015 06:37 AM, Bo Shen wrote:
This commit 904672e (lcd: refactor lcd console stuff into its
own file), which cause lcd console
Hi,
On 26-01-15 04:30, Simon Glass wrote:
Hi Adam,
On 25 January 2015 at 08:24, Adam Sampson a...@offog.org wrote:
This is a low-cost Allwinner A20 board with Arduino-style GPIO headers;
it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro
USB socket for OTG and another for
This is a low-cost Allwinner A20 board with Arduino-style GPIO headers;
it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro
USB socket for OTG and another for power in, HDMI, SATA, 5V power for
SATA devices, gigabit Ethernet, an IR receiver, 3.5mm audio out and a
MIPI camera
Hi!
I have tried to find solution to get am335x based Silica/Pengwyn board
booting from usb flash. U-boot on that board is based on u-boot 2013.10. I
flashed it with similar configuration as mmc flash, but I did not find
combination of configuration variables to get proper spl code generated. I
Hi Adam,
On 25 January 2015 at 08:24, Adam Sampson a...@offog.org wrote:
This is a low-cost Allwinner A20 board with Arduino-style GPIO headers;
it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro
USB socket for OTG and another for power in, HDMI, SATA, 5V power for
SATA
This patch adds U-Boot support for the Reachtech G2C1 board. G2C1 U-Boot
images created with this patch will perform the following:
- Initialise the MX28 for 'No Battery' mode
- Configure all IOMUXs
- Configure GPIO directions for all IOMUXs designed for GPIO use
- Inilialise the MMC
From: Shaohui Xie shaohui@freescale.com
When compiling under 64 bit mode, there are warnings as below:
In file included from drivers/block/ahci.c:16:0:
drivers/block/ahci.c: In function 'ahci_reset':
./arch/arm/include/asm/io.h:72:28: warning: cast to pointer from integer
of different size
On 26/01/15 00:27, Simon Glass wrote:
This has moved to driver model so we don't need the fdtdec support.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
include/fdtdec.h | 1 -
lib/fdtdec.c | 1 -
2 files changed, 2 deletions(-)
diff
The root device corresponds to the root device tree node, so set this up.
Also add a few notes to the documentation.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
doc/driver-model/README.txt | 4
drivers/core/root.c | 3 +++
2 files
When using allocated platform data, allocate it when we bind the device.
This makes it possible to fill in this information before the device is
probed.
This fits with the platform data model (when not using device tree),
since platform data exists at bind-time.
Signed-off-by: Simon Glass
Rather than assuming that the chip offset length is 1, allow it to be
provided. This allows chips that don't use the default offset length to
be used (at present they are only supported by the command line 'i2c'
command which sets the offset length explicitly).
Signed-off-by: Simon Glass
The current bus implementation is simple but leaves some things to drivers
which are better handled in the uclass.
At present uclasses cannot provide a common way of dealing with children
(i.e. devices on the bus), so we have duplication in the drivers. The same
code is repeated in each driver
Mention that the devices are probed ready for use.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
include/dm/uclass.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index f6ec6d7..2577ae6 100644
---
There is no point in running the tests if U-Boot cannot be built. Abort in
this case.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2: None
test/dm/test-dm.sh | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/test/dm/test-dm.sh
Hi Albert,
this series contains pending kirkwood patches that have been posted on
the mailing list for some time now.
The following changes since commit 37b608a52dcb13312a4f7ccea199cd6bac76d298:
powerpc: remove icecube_5200, Lite5200, cpci5200, mecp5200, pf5200
(2015-01-23 16:56:09 -0500)
Hi Simon,
On Sun, 25 Jan 2015 08:26:54 -0700
Simon Glass s...@chromium.org wrote:
The current bus implementation is simple but leaves some things to drivers
which are better handled in the uclass.
At present uclasses cannot provide a common way of dealing with children
(i.e. devices on
On Sun, 25 Jan 2015 08:27:00 -0700
Simon Glass s...@chromium.org wrote:
When using allocated platform data, allocate it when we bind the device.
This makes it possible to fill in this information before the device is
probed.
This fits with the platform data model (when not using device
On Sun, 25 Jan 2015 08:27:01 -0700
Simon Glass s...@chromium.org wrote:
For buses it is common for parents to need to know the address of the child
on the bus, the bus speed to use for that child, and other information. This
can be provided in platform data attached to each child.
Add
On Sun, 25 Jan 2015 08:27:04 -0700
Simon Glass s...@chromium.org wrote:
This is useful to check which uclass a device is in.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com
___
U-Boot mailing
On Sun, 25 Jan 2015 08:27:06 -0700
Simon Glass s...@chromium.org wrote:
In many cases the per-child private data for a device's children is defined
by the uclass rather than the individual driver. For example, a SPI bus
needs to store information about each of its children, but all SPI
On Sun, 25 Jan 2015 08:27:13 -0700
Simon Glass s...@chromium.org wrote:
At present we go through various contortions to store the I2C's chip
address in its private data. This only exists when the chip is active so
must be set up when it is probed. Until the device is probed we don't
actually
55 matches
Mail list logo
