When PLL5P is used as a parent clock for some of the peripherals,
the current code just selects some hardcoded divisors. This happens
to work, but only under assumption that the PLL5P clock speed is
somewhere between 360MHz and 480MHz (the typical DRAM clock speeds).
However with some tweaks for t
The dcdc3 voltage is expected to be set by the bootloader and the right
voltage depends on the DRAM settings (higher clock speed needs more
voltage). Allowing to use the 'dcdc3_vol' parameter from the FEX file
only introduces an unnecessary fragile dependency between the settings
in u-boot and the
On Fri, Oct 3, 2014 at 4:08 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 10/03/2014 05:57 PM, Rob Herring wrote:
>>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
A simple-framebuffer node represents a framebuffer setup by the firmwar
On Fri, Oct 3, 2014 at 5:26 PM, Geert Uytterhoeven wrote:
> On Fri, Oct 3, 2014 at 10:55 PM, jonsm...@gmail.com
> wrote:
>> On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven
>> wrote:
>>> On Thu, Oct 2, 2014 at 3:34 PM, jonsm...@gmail.com
>>> wrote:
Does the clock and regulator cleanup
On Fri, Oct 3, 2014 at 10:55 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven
> wrote:
>> On Thu, Oct 2, 2014 at 3:34 PM, jonsm...@gmail.com
>> wrote:
>>> Does the clock and regulator cleanup happen before drivers can load
>>> off from initrd? I didn't think i
On Fri, Oct 3, 2014 at 4:08 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 10/03/2014 05:57 PM, Rob Herring wrote:
>>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
A simple-framebuffer node represents a framebuffer setup by the firmwar
On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede wrote:
> Hi,
>
> On 10/03/2014 05:57 PM, Rob Herring wrote:
>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
>>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>>> bootloader. Such a framebuffer may have a number of
On Fri, 2014-10-03 at 21:06 +0800, Chen-Yu Tsai wrote:
> On Fri, Oct 3, 2014 at 8:47 PM, Ian Campbell wrote:
> > On Fri, 2014-10-03 at 14:37 +0200, Maxime Ripard wrote:
> >> On Fri, Oct 03, 2014 at 08:16:30PM +0800, Chen-Yu Tsai wrote:
> >> > The Colombus board is an A31 evaluation board from WITS
Hi,
Am 03.10.2014 um 09:56 schrieb Vladimir Komendantskiy:
The Allwinner SoCs that have an HDMI pin, also have a memory-mapped
HDMI-CEC register located at HDMI base 0xf1c16000 plus the offset
0x214. This register provides the following bits
#define CEC_RX 0x0100 /* phys. line value, eith
Hi,
On 10/03/2014 06:19 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 11:04 AM, Geert Uytterhoeven
> wrote:
>> Hi Rob,
>>
>> On Fri, Oct 3, 2014 at 5:57 PM, Rob Herring wrote:
>>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
A simple-framebuffer node represents a framebuffer setu
Hi,
On 10/03/2014 05:57 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>> property to communicate this to the OS
On Fri, Oct 3, 2014 at 11:04 AM, Geert Uytterhoeven
wrote:
> Hi Rob,
>
> On Fri, Oct 3, 2014 at 5:57 PM, Rob Herring wrote:
>> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
>>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>>> bootloader. Such a framebuffer ma
Hi Rob,
On Fri, Oct 3, 2014 at 5:57 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>> property to communicate t
On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede wrote:
> A simple-framebuffer node represents a framebuffer setup by the firmware /
> bootloader. Such a framebuffer may have a number of clocks in use, add a
> property to communicate this to the OS.
>
> Signed-off-by: Hans de Goede
> Reviewed-by: Mi
Hi Ian, et al,
Here is a patch-set adding support for the second sdcard slot found on some
sunxi devices. This includes support for eMMC-s connected to sdc2 (so that
they are bootable), as found on e.g. the Mele-M3.
For the eMMC case this set also adds support to detect what device we're
actually
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/pinmux.c | 13 +
arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/arch/arm/cpu/armv7/sunxi/pinmux.c
b/arch/arm/cpu/armv7/sunxi/pinmux.c
index 1f2843f..a3e5bfc 100644
--- a/arc
Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL
check is not necessary with Kconfig, because only options explicitly marked
as also being for the SPL get set during SPL builds.
Signed-off-by: Hans de Goede
---
board/sunxi/Kconfig | 8
board/sunxi/board.c | 2 +
sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
booting, and make that one "mmc dev 0" so that a single u-boot binary can
be used for both the onboard eMMC and for external sdcards.
Signed-off-by: Hans de Goede
---
arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
board/sun
None of the known sunxi devices actually use mmc1 routed through PH, where
as some devices do actually use mmc1 routed through PG, so change the routing
of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
PH, we will need to change things to be a bit more flexible.
Signed
Signed-off-by: Hans de Goede
---
board/sunxi/Kconfig | 27 +++
drivers/mmc/sunxi_mmc.c | 20
2 files changed, 47 insertions(+)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 622f7b4..72d6dfa 100644
--- a/board/sunxi/Kconfig
+++ b/boa
Enable the second sdcard slot found on some boards. Note that we do not
set CONFIG_MMC_SUNXI_SLOT_EXTRA for the SPL, as having it there is not useful,
Except for on the Mele-M3 where the second sdcard is an eMMC, from which the
device can also boot, and there we want to have both in the SPL, so th
A simple-framebuffer node represents a framebuffer setup by the firmware /
bootloader. Such a framebuffer may have a number of clocks in use, add a
property to communicate this to the OS.
Signed-off-by: Hans de Goede
Reviewed-by: Mike Turquette
--
Changes in v2:
-Added Reviewed-by: Mike Turquet
Hi,
On 10/03/2014 03:20 PM, Rob Herring wrote:
> On Fri, Oct 3, 2014 at 6:52 AM, Hans de Goede wrote:
>> A simple-framebuffer node represents a framebuffer setup by the firmware /
>> bootloader. Such a framebuffer may have a number of clocks in use, add a
>> property to communicate this to the OS
Hello,
On Fri, 3 Oct 2014 04:55:22 -0700 (PDT) Markus Rathgeb wrote:
> Thank you for your work!
>
> Is there a git repository the changes could be found (to simplify merging /
> cherry-picking)?
> Is there some progress to get that mainline?
I've been waiting for some feed-back from sunxi commu
On Fri, Oct 3, 2014 at 6:52 AM, Hans de Goede wrote:
> A simple-framebuffer node represents a framebuffer setup by the firmware /
> bootloader. Such a framebuffer may have a number of clocks in use, add a
> property to communicate this to the OS.
>
> Signed-off-by: Hans de Goede
> Reviewed-by: Mi
On Fri, Oct 3, 2014 at 8:47 PM, Ian Campbell wrote:
> On Fri, 2014-10-03 at 14:37 +0200, Maxime Ripard wrote:
>> On Fri, Oct 03, 2014 at 08:16:30PM +0800, Chen-Yu Tsai wrote:
>> > The Colombus board is an A31 evaluation board from WITS Technology.
>> >
>> > Maxime has kindly agreed to maintain thi
On 03/10/14 14:16, Hans de Goede wrote:
>>> You indicate that you don't have the time for this discussion, and I note
>>> that
>>> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how
>>> about
>>> the following, I pick up drivers/video/fbdev/simplefb.c maintainership,
>>>
On Fri, 2014-10-03 at 14:37 +0200, Maxime Ripard wrote:
> On Fri, Oct 03, 2014 at 08:16:30PM +0800, Chen-Yu Tsai wrote:
> > The Colombus board is an A31 evaluation board from WITS Technology.
> >
> > Maxime has kindly agreed to maintain this board.
> >
> > [1] http://lists.denx.de/pipermail/u-boo
On Fri, Oct 03, 2014 at 08:16:30PM +0800, Chen-Yu Tsai wrote:
> The Colombus board is an A31 evaluation board from WITS Technology.
>
> Maxime has kindly agreed to maintain this board.
>
> [1] http://lists.denx.de/pipermail/u-boot/2014-September/190043.html
>
> Signed-off-by: Chen-Yu Tsai
> Cc:
Hi everyone,
This is v3 of the A31 support series. This series add basic (UART and MMC)
support for Allwinner's A31 SoC. The patches, excluding the first one,
were cherry-picked from u-boot-sunxi. Due to the difference between u-boot
mainline and u-boot-sunxi, some patches were rearranged or squas
We have already defined macros for pull-up/down values in the
GPIO header. Use them instead of magic numbers when configuring
the UART pins.
Signed-off-by: Chen-Yu Tsai
Acked-by: Ian Campbell
---
arch/arm/cpu/armv7/sunxi/board.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
From: Hans de Goede
The mmc hardware on sun6i has an extra reset control that needs to
be de-asserted prior to usage. Also the FIFO address is different.
Signed-off-by: Hans de Goede
[w...@csie.org: use setbits_le32 for reset control, drop obsolete changes,
rewrite different FIF
BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when
CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally
include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI.
Signed-off-by: Chen-Yu Tsai
Acked-by: Ian Campbell
---
include/configs/sunxi-common.h | 8 ++
From: Maxime Ripard
Signed-off-by: Maxime Ripard
Signed-off-by: Hans de Goede
[w...@csie.org: commit message was "ARM: sunxi: Setup the A31 UART0 muxing"]
[w...@csie.org: reorder #ifs by SUN?I]
[w...@csie.org: replace magic numbers with GPIO definitions]
Signed-off-by: Chen-Yu Tsai
Acked-by: I
From: Maxime Ripard
Add a new sun6i machine that supports UART and MMC.
Signed-off-by: Maxime Ripard
Signed-off-by: Hans de Goede
[w...@csie.org: use SPDX labels, adapt to Kconfig system, drop ifdef
around mmc and smp code, drop MACH_TYPE]
Signed-off-by: Chen-Yu Tsai
Acked-by:
This patch adds the basic clocks support for the Allwinner A31 (sun6i)
processor. This code will not been compiled until the build is hooked
up in a later patch. It has been split out to keep the patches manageable.
This includes changes from the following commits from u-boot-sunxi:
a92051b ARM:
From: Oliver Schinagl
A31 has several new and changed memory address. This patch adds them.
Signed-off-by: Oliver Schinagl
Signed-off-by: Hans de Goede
Signed-off-by: Chen-Yu Tsai
Acked-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/cpu.h | 9 +
1 file changed, 9 insertions(+)
From: Oliver Schinagl
The A31 has a new module called PRCM, or Power, Reset Control Module.
This module controls clocks and resets for RTC block modules, and also
PLL biasing in the main clock module.
This patch adds the register definitions, and also enables the clocks
and resets for the RTC bl
UART0 is the default debug/console UART on the A31.
Signed-off-by: Chen-Yu Tsai
Acked-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/gpio.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f7f3d8c
The Colombus board is an A31 evaluation board from WITS Technology.
Maxime has kindly agreed to maintain this board.
[1] http://lists.denx.de/pipermail/u-boot/2014-September/190043.html
Signed-off-by: Chen-Yu Tsai
Cc: Maxime Ripard
---
board/sunxi/MAINTAINERS| 5 +
configs/Colombus_de
Hello!
Thank you for your work!
Is there a git repository the changes could be found (to simplify merging /
cherry-picking)?
Is there some progress to get that mainline?
Is there some way to enable RTC battery charging for the mainline 3.17?
Using the 3.4 kernel we could use i2cset, is there so
Hi Tomi,
On 10/03/2014 01:45 PM, Tomi Valkeinen wrote:
> On 03/10/14 14:16, Hans de Goede wrote:
>
You indicate that you don't have the time for this discussion, and I note
that
there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how
about
the followin
From: Luc Verhaegen
This claims and enables clocks listed in the simple framebuffer dt node.
This is needed so that the display engine, in case the required clocks
are known by the kernel code and are described in the dt, will remain
properly enabled.
Signed-off-by: Luc Verhaegen
[hdego...@redh
During the discussion about adding clock handling code to simplefb, it became
clear that simplefb currently does not have an active maintainer.
I've discussed this with Stephen Warren , the original
author of simplefb, and with his permisson I'm picking up maintainership of
simplefb.
Cc: Stephen
From: Luc Verhaegen
Signed-off-by: Luc Verhaegen
Acked-by: Stephen Warren
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/simplefb.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/driv
From: Luc Verhaegen
Signed-off-by: Luc Verhaegen
Acked-by: Stephen Warren
[hdego...@redhat.com: drop unnecessary void * cast]
Reviewed-by: Hans de Goede
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/simplefb.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
dif
Hi Tomi,
Here is v2 of the patch-set to add clocks support to simplefb.
Changes in v2:
-Added "simplefb: Add simplefb MAINTAINERS entry" patch
If you've followed the discussion sofar, then you know that not everyone
agrees 100% with this. The primary concern being that this will turn simplefb
in
A simple-framebuffer node represents a framebuffer setup by the firmware /
bootloader. Such a framebuffer may have a number of clocks in use, add a
property to communicate this to the OS.
Signed-off-by: Hans de Goede
Reviewed-by: Mike Turquette
---
Documentation/devicetree/bindings/video/simple
Hi,
On 10/02/2014 05:49 PM, Stephen Warren wrote:
> On 10/02/2014 12:42 AM, Hans de Goede wrote:
> ...
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problem
Hi,
On 10/03/2014 10:49 AM, Siarhei Siamashka wrote:
> On Fri, 03 Oct 2014 10:04:29 +0200
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 10/01/2014 07:43 PM, Hendrik wrote:
>>> I have always been using the sunxi u-boot from
>>> 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but no
On Fri, 03 Oct 2014 10:04:29 +0200
Hans de Goede wrote:
> Hi,
>
> On 10/01/2014 07:43 PM, Hendrik wrote:
> > I have always been using the sunxi u-boot from
> > 'https://github.com/linux-sunxi/u-boot-sunxi' and that works fine, but now
> > I want to boot the kernel from USB. That is not possibl
Hi,
On 10/02/2014 09:23 AM, Ian Campbell wrote:
> On Wed, 2014-10-01 at 16:23 +0200, Hans de Goede wrote:
>> The Mele M3 is yet another Allwinnner based Android top set box from Mele.
>>
>> It uses a housing similar to the A2000, but without the USM sata storage slot
>> at the top.
>>
>> It featur
The Allwinner SoCs that have an HDMI pin, also have a memory-mapped
HDMI-CEC register located at HDMI base 0xf1c16000 plus the offset 0x214.
This register provides the following bits
#define CEC_RX 0x0100 /* phys. line value, either high or low */
#define CEC_TX 0x0200
#define CEC_ENABLE
Hi,
On 10/03/2014 01:31 AM, Julian Calaby wrote:
> Hi,
>
> On Fri, Oct 3, 2014 at 1:14 AM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede wr
54 matches
Mail list logo
