Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 9月, 2019 4 次提交
  3. 25 8月, 2019 5 次提交
    • J
      ARM: aspeed: Enable SMP boot · 87dfe496
      由 Joel Stanley 提交于 
      This brings the secondary CPU into Linux. It depends on the setup
performed by ASPEED's u-boot.
Signed-off-by: NJoel Stanley <joel@jms.id.au>
      87dfe496
    • J
      ARM: aspeed: Add ASPEED AST2600 architecture · 9afe2c0a
      由 Joel Stanley 提交于 
      The AST2600 is a Cortex A7 dual core CPU that uses the ARM GIC for
interrupts and ARM timer as a clocksource.
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
      9afe2c0a
    • J
      ARM: aspeed: Select timer in each SoC · e35d7db9
      由 Joel Stanley 提交于 
      In preparation for adding the ast2600 which does not use this timer.
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
      e35d7db9
    • J
      dt-bindings: arm: cpus: Add ASPEED SMP · 5177cabf
      由 Joel Stanley 提交于 
      The AST2600 SoC contains two CPUs and requires the operating system to
bring the second one out of firmware.
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
      5177cabf
    • A
      ARM: imx: stop adjusting ar8031 phy tx delay · acf993a0
      由 André Draszik 提交于 
      Recent changes to the Atheros at803x driver cause
the approach taken here to stop working because
commit 6d4cd041
("net: phy: at803x: disable delay only for RGMII mode")
and commit cd28d1d6
("net: phy: at803x: Disable phy delay for RGMII mode")
fix the AR8031 driver to configure the phy's (RX/TX)
delays as per the 'phy-mode' in the device tree.

In particular, the phy tx (and rx) delays are updated
again as per the 'phy-mode' *after* the code in here
runs.

Things worked before above commits, because the AR8031
comes out of reset with RX delay enabled, and the
at803x driver didn't touch the delay configuration at
all when "rgmii" mode was selected.

It appears the code in here tries to make device
trees work that incorrectly specify "rgmii", but
that can't work any more and it is imperative since
above commits to have the phy-mode configured
correctly in the device tree.

I suspect there are a few imx7d based boards using
the ar8031 phy and phy-mode = "rgmii", but given I
don't know which ones exactly, I am not in a
position to update the respective device trees.

Hence this patch is simply removing the superfluous
code from the imx7d initialisation. An alternative
could be to add a warning instead, but that would
penalize all boards that have been updated already.
Signed-off-by: NAndré Draszik <git@andred.net>
CC: Russell King <linux@armlinux.org.uk>
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Pengutronix Kernel Team <kernel@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: NXP Linux Team <linux-imx@nxp.com>
CC: Kate Stewart <kstewart@linuxfoundation.org>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Leonard Crestez <leonard.crestez@nxp.com>
CC: linux-arm-kernel@lists.infradead.org
Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      acf993a0
  5. 24 8月, 2019 4 次提交
  7. 16 8月, 2019 14 次提交
  9. 15 8月, 2019 2 次提交
    • A
      ARM: orion/mvebu: unify debug-ll virtual addresses · 3584be9e
      由 Arnd Bergmann 提交于 
      In a multiplatform configuration, enabling DEBUG_LL breaks booting
on all platforms with incompatible settings. In case of the Marvell
platforms of the Orion/MVEBU family, the physical addresses are
all the same, we just map them at different virtual addresses,
which makes it impossible to run a kernel with DEBUG_LL enabled on
a combination of the merged mvebu and the legacy boardfile based
platforms.

This is easily solved by using the same virtual address everywhere.
I picked the address that is already used by mach-mvebu for UART0:
0xfec12000. All these platforms have a 1MB region with their internal
registers, almost always at physical address 0xf1000000, so I'm
updating the iotable for that entry.

In case of mach-dove, this is slightly trickier, as the existing
mapping is 8MB and a second 8MB mapping is already at the 0xfec00000
address. I have verified from the datasheet that the last 7MB of the
physical mapping are "reserved" and nothing in Linux tries to use
it either. I'm putting this 1MB mapping at the same address as the
others, and the second 8MB register area immediately before that.

Link: https://lore.kernel.org/r/20190731195713.3150463-14-arnd@arndb.de
Link: https://lore.kernel.org/linux-arm-kernel/87si3eb1z8.fsf@free-electrons.com/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      3584be9e
    • A
      ARM: dove: clean up mach/*.h headers · ce78179e
      由 Arnd Bergmann 提交于 
      This is a simple move of all header files that are no longer
included by anything else from the include/mach directory
to the platform directory itself as preparation for
multiplatform support.

The mach/uncompress.h headers are left in place for now,
and are mildly modified to be independent of the other
headers. They will be removed entirely when ARCH_MULTIPLATFORM
gets enabled and they become obsolete.

Rather than updating the path names inside of the comments
of each header, I delete those comments to avoid having to
update them again, should they get moved or copied another
time.

Link: https://lore.kernel.org/r/20190731195713.3150463-13-arnd@arndb.deSigned-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      ce78179e
  11. 14 8月, 2019 10 次提交
  13. 13 8月, 2019 1 次提交