Browsing the DTS for all the R-Car SoCs with similar part numbers
makes my head hurt, so to improve the user friendliness of the
DTS code base include R-Car product name in each DTSI file.
Product names are derived from
Documentation/devicetree/bindings/arm/shmobile.txt
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Browsing the DTS for all the R-Car SoCs with similar part numbers
still makes my head hurt, so to improve the user friendliness of
the 32-bit ARM DTS code base include R-Car Gen1 product names for
each DTSI file.
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Update the SATA device nodes on R-Car H1, H2, and M2-W to use a 2 MiB
I/O space, as specified in Rev.1.0 of the R-Car H1 and R-Car Gen2
hardware user manuals.
See also commit e9f0089b2d ("arm64: dts: r8a7795: Correct SATA
device size to 2MiB").
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
As the soc_camera framework is going to be deprecated soon, remove the
associated configuration options from shmobile defconfig.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Christoph Hellwig suggested a slightly different path for handling
backwards compatibility with the 32-bit time_t based system calls:
Rather than simply reusing the compat_sys_* entry points on 32-bit
architectures unchanged, we get rid of those entry points and the
compat_time types by renaming them to something that makes more sense
on 32-bit architectures (which don't have a compat mode otherwise),
and then share the entry points under the new name with the 64-bit
architectures that use them for implementing the compatibility.
The following types and interfaces are renamed here, and moved
from linux/compat_time.h to linux/time32.h:
old new
--- ---
compat_time_t old_time32_t
struct compat_timeval struct old_timeval32
struct compat_timespec struct old_timespec32
struct compat_itimerspec struct old_itimerspec32
ns_to_compat_timeval() ns_to_old_timeval32()
get_compat_itimerspec64() get_old_itimerspec32()
put_compat_itimerspec64() put_old_itimerspec32()
compat_get_timespec64() get_old_timespec32()
compat_put_timespec64() put_old_timespec32()
As we already have aliases in place, this patch addresses only the
instances that are relevant to the system call interface in particular,
not those that occur in device drivers and other modules. Those
will get handled separately, while providing the 64-bit version
of the respective interfaces.
I'm not renaming the timex, rusage and itimerval structures, as we are
still debating what the new interface will look like, and whether we
will need a replacement at all.
This also doesn't change the names of the syscall entry points, which can
be done more easily when we actually switch over the 32-bit architectures
to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Configure sdmmc4 parent clock to pllc4 and sdmmc1 to pllp_out0 by
setting the assigned-clocks device tree properties. pllc4 offer
better jitter performance and should be used with higher speed
modes like HS200 and HS400.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use assigned-clock properties to configure pllc4 as the parent clock
for sdmmc4 on Tegra210. pllc4 offers better jitter perfomance than
the default pllp and is required by HS200 and HS400 modes.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the calibration offset properties used for automatic pad drive
strength calibration.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the calibration offset properties used for automatic pad drive
strength calibration.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Allow sdmmc1 to set the signaling voltage to 1.8 V in order to support
faster signaling modes.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Set regulator-min-microvolt property of ldo2 to 1.8 V in
tegra210-p2180.dtsi. ldo2 is used by the sdmmc1 SDHCI controller and its
voltage needs to be adjusted down to 1.8 V to support faster signaling
modes. It appears that the comment about the SDHCI driver requesting
invalid voltages no longer applies.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add pad voltage configuration nodes for sdmmc pads with configurable
voltages on Tegra186.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add pad voltage configuration nodes for sdmmc pads with configurable
voltages on Tegra210.
Signed-off-by: Aapo Vienamo <avienamo@nvidia.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
On Nehalem and newer core CPUs the CPU cache internally uses 44 bits
physical address space. The L1TF workaround is limited by this internal
cache address width, and needs to have one bit free there for the
mitigation to work.
Older client systems report only 36bit physical address space so the range
check decides that L1TF is not mitigated for a 36bit phys/32GB system with
some memory holes.
But since these actually have the larger internal cache width this warning
is bogus because it would only really be needed if the system had more than
43bits of memory.
Add a new internal x86_cache_bits field. Normally it is the same as the
physical bits field reported by CPUID, but for Nehalem and newerforce it to
be at least 44bits.
Change the L1TF memory size warning to use the new cache_bits field to
avoid bogus warnings and remove the bogus comment about memory size.
Fixes: 17dbca1193 ("x86/speculation/l1tf: Add sysfs reporting for l1tf")
Reported-by: George Anchev <studio@anchev.net>
Reported-by: Christopher Snowhill <kode54@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Michael Hocko <mhocko@suse.com>
Cc: vbabka@suse.cz
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180824170351.34874-1-andi@firstfloor.org
Beside the non-controllable green power LED, the NanoPi-A64 features a
blue "status" LED, connected to PD24.
Add the device tree node to make it usable.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The NanoPi-A64 has an on-board WiFi chip, connected to the usual MMC1 SDIO
interface. The AXP power line is the always-on VDD_SYS_3.3V, but it uses
pin L2 to enable the regulator.
As the actual WiFi driver is not in mainline Linux, it doesn't have a
compatible string, so we omit this from the node.
Add the respective nodes to the DT to make it usable.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
[wens@csie.org: Add RTL8189ETV LPO clock to pwrseq node]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The NanoPi-A64 has the usual Realtek Gbit PHY connected to the EMAC,
so add the respective nodes to the DT. The PHY is powered by the
VDD_SYS_3.3V line, which is always on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
According to the NanoPi-A64 schematics, DCDC1 is connected to a voltage
rail named "VDD_SYS_3.3V". All users seem to expect 3.3V here: the
Ethernet PHY, the uSD card slot, the camera interface and the GPIO pins
on the headers.
Fix up the voltage on the regulator to lift it up to 3.3V.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Olinuxino has two USB sockets:
USB0 is connected to a micro B socket. As it has the ID pin wired and
the VBUS line connected to the PMIC, we describe it as a proper OTG socket,
which switches between host and device automatically.
USB1 is connected to a normal USB A socket. PG9 enables the power line,
so add the required regulator as well.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Add the DT nodes required to enable the Gigabit Ethernet on the board.
The PHY is powered by the always-on power rail VDD_SYS_3.3V (DCDC1).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Olinuxino board uses DDR3L chips which are supposed to be driven
with 1.35V. The reset default of the AXP is properly set to 1.36V.
While technically the chips can also run at 1.5 volts, changing the
voltage on the fly while booting Linux is asking for trouble. Also
running at a lower voltage saves power.
So fix the DCDC5 value to match the actual board design.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Martin Lucina <martin@lucina.net>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win board uses the AXP's ALDO1 power rail to drive the
VCC-CSI line, which, according to the schematic, needs to be set to 2.8V.
Also the ELDO3 power rail is connected to the CSI, with somewhat unclear
voltage requirements. Add this regulator and allow the voltage to be set
between 1.5V and 1.8V, which are the voltages mentioned in the
schematic.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win features a soldered WiFi chip on the board, connected
via the SDIO interface. Add the required DT nodes.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win exposes several UARTs on header pins, and connects one
to the on-board WiFi/Bluetooth chip.
Add the pinmux definitions to the UART nodes, but keep them disabled.
Enable the UART1, which is wired to the Bluetooth chip, and add a serdev
node. There is no binding for the BT8723 yet, so leave this mostly empty
for now.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Orange Pi Win has a micro USB-B socket, connected to the SoC's
USB-OTG port. Its power is supplied by the AXP PMIC, and the ID pin is
connected to GPIO PH9. It can serve both as a host or a client port.
Add the respective DT nodes to enable it.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
[wens@csie.org: enable paired EHCI/OHCI device nodes and regulator supply]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
