| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Platform data support has been removed from the DU driver, drop DU
support from the legacy Marzen board file. The multiplatform DT-based
Marzen support should be used instead.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Simon Horman <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Platform data support has been removed from the DU driver, drop DU
support from the legacy Lager board file. The multiplatform DT-based
Lager support should be used instead.
Signed-off-by: Laurent Pinchart <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Simon Horman <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The function graph helper function prepare_ftrace_return() which does the work
to hijack the parent pointer has that parent pointer as its first parameter.
Instead, if we make it the second parameter and have ip as the first parameter
(self_addr), then it can use the %rdi from save_mcount_regs that loads it
already.
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
Move all the work from ftrace_caller_setup into save_mcount_regs. This
simplifies the code and makes it easier to understand.
Link: http://lkml.kernel.org/r/CA+55aFxUTUbdxpjVMW8X9c=o8sui7OB_MYPfcbJuDyfUWtNrNg@mail.gmail.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
The save_mcount_regs macro saves and restores the required mcount regs that
need to be saved before calling C code. It is done for all the function hook
utilities (static tracing, dynamic tracing, regs, function graph).
When frame pointers are enabled, the ftrace trampolines need to set up
frames and pointers such that a back trace (dump stack) can continue passed
them. Currently, a separate macro is used (create_frame) to do this, but
it's only done for the ftrace_caller and ftrace_reg_caller functions. It
is not done for the static tracer or function graph tracing.
Instead of having a separate macro doing the recording of the frames,
have the save_mcount_regs perform this task. This also has all tracers
saving the frame pointers when needed.
Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
mcount regs
The macro save_mcount_regs saves regs onto the stack. But to uncouple the
amount of stack used in that macro from the users of the macro, we need
to have a define that tells all the users how much stack is used by that
macro. This way we can change the amount of stack the macro uses without
breaking its users.
Also remove some dead code that was left over from commit fdc841b58cf5
"ftrace: x86: Remove check of obsolete variable function_trace_stop".
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
Currently save_mcount_regs is passed a "skip" parameter to know how much
stack updated the pt_regs, as it tries to keep the saved pt_regs in the
same location for all users. This is rather stupid, especially since the
part stored on the pt_regs has nothing to do with what is suppose to be
in that location.
Instead of doing that, just pass in an "added" parameter that lets that
macro know how much stack was added before it was called so that it
can get to the RIP. But the difference is that it will now offset the
pt_regs by that "added" count. The caller now needs to take care of
the offset of the pt_regs.
This will make it easier to simplify the code later.
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
Instead of having save_mcount_regs store the RIP in %rdx as a temp register
to place it in the proper location of the pt_regs on the stack. Use the
%rdi register as the temp register. This lets us remove the extra store
in the ftrace_caller_setup macro.
Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
The name MCOUNT_SAVE_FRAME is rather confusing as it really isn't a
function frame that is saved, but just the required mcount registers
that are needed to be saved before C code may be called. The word
"frame" confuses it as being a function frame which it is not.
Rename MCOUNT_SAVE_FRAME and MCOUNT_RESTORE_FRAME to save_mcount_regs
and restore_mcount_regs respectively. Noticed the lower case, which
keeps it from screaming at the reviewers.
Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
Linus pointed out that MCOUNT_SAVE_FRAME is used in only a single file
and that there's no reason that it should be in a header file.
Move the macro to the code that uses it.
Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
Linus pointed out that there were locations that did the hard coded
update of the parent and rip parameters. One of them was the static tracer
which could also use the ftrace_caller_setup to do that work. In fact,
because it did not use it, it is prone to bugs, and since the static
tracer is hardly ever used (who wants function tracing code always being
called?) it doesn't get tested very often. I only run a few "does it still
work" tests on it. But I do not run stress tests on that code. Although,
since it is never turned off, just having it on should be stressful enough.
(especially for the performance folks)
There's no reason that the static tracer can't also use ftrace_caller_setup.
Have it do so.
Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
|
|
This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
actually called outside of a few drivers) into arch_setup_dma_ops, so
that we can use IOMMUs for DMA transfers in a more generic fashion.
Since this significantly complicates the arch_setup_dma_ops function,
it is moved out of line into dma-mapping.c. If CONFIG_ARM_DMA_USE_IOMMU
is not set, the iommu parameter is ignored and the normal ops are used
instead.
Acked-by: Russell King <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
We need to ensure that the IOMMUs in the system have a chance to perform
some basic initialisation before we start adding masters to them.
This patch adds a call to of_iommu_init before of_platform_populate.
Acked-by: Russell King <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
This patch extends of_dma_configure so that it sets up the IOMMU for a
device, as well as the coherent/non-coherent DMA mapping ops.
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Tested-by: Robin Murphy <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
set_arch_dma_coherent_ops is called from of_dma_configure in order to
swizzle the architectural dma-mapping functions over to a cache-coherent
implementation. This is currently implemented only for ARM.
In anticipation of re-using this mechanism for IOMMU-backed dma-mapping
ops too, this patch replaces the function with a broader
arch_setup_dma_ops callback which will be extended in future.
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Marek Szyprowski <[email protected]>
Tested-by: Robin Murphy <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
|
|
Update handling of cacheflush syscall with changes made in arch/arm
counterpart:
- return error to userspace when flushing syscall fails
- split user cache-flushing into interruptible chunks
- don't bother rounding to nearest vma
Signed-off-by: Vladimir Murzin <[email protected]>
[will: changed internal return value from -EINTR to 0 to match arch/arm/]
Signed-off-by: Will Deacon <[email protected]>
|
|
Hand down the cpu number instead, otherwise lockdep screams when doing
echo 1 > /sys/devices/system/cpu/microcode/reload.
BUG: using smp_processor_id() in preemptible [00000000] code: amd64-microcode/2470
caller is debug_smp_processor_id+0x12/0x20
CPU: 1 PID: 2470 Comm: amd64-microcode Not tainted 3.18.0-rc6+ #26
...
Signed-off-by: Borislav Petkov <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
When we generate the instruction for out of line execution the length
of the to be copied instruction was evaluated from a not initialized
memory location.
Therefore we ended up with a random (2, 4 or 6) number of bytes being
copied instead of taking the real instruction length into account.
This works surprisingly well most of the time, but still not always.
Reported-by: Ursula Braun <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
Commit eb7e7d76 "s390: Replace __get_cpu_var uses" broke machine check
handling.
We copy machine check information from per-cpu to a stack variable for
local processing. Next we should zap the per-cpu variable, not the
stack variable.
Signed-off-by: Sebastian Ott <[email protected]>
Reviewed-by: Heiko Carstens <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001
The problem there was that microcode patches are not being reapplied
after suspend-to-ram. It was important to reapply them, though, because
of for example Haswell's TSX erratum which disabled TSX instructions
with a microcode patch.
A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode
on resume") but, as it is often the case, simple fixes are too
simple. This one causes 32-bit resume to fail:
https://bugzilla.kernel.org/show_bug.cgi?id=88391
Properly fixing this would require more involved changes for which it
is too late now, right before the merge window. Thus, limit this to
64-bit only temporarily.
Signed-off-by: Borislav Petkov <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
secondary_startup() in the header is not needed at all.
Signed-off-by: Michal Simek <[email protected]>
|
|
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Acked-by: Soren Brinkmann <[email protected]>
Signed-off-by: Peter Crosthwaite <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
|
|
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Acked-by: Soren Brinkmann <[email protected]>
Signed-off-by: Peter Crosthwaite <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
|
|
The current driver probe() function assumes the sensor device to be
always present and gets executed every time if the driver is loaded,
but the appropriate hardware could not be present.
So, move the platform device creation as part of platform init code
and use the 'id_table' to check if the device is present or not.
Signed-off-by: Neelesh Gupta <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
|
|
We need the xhci fixes here and this resolves a merge issue with
drivers/usb/dwc3/ep0.c
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
|
|
The SDMMC, SDIO and EMMC controllers use an external FIFO whose size is 256x32bit.
This patch set the corresponding fifo-depth properties for both RK3066 and RK3188.
Signed-off-by: Julien CHAUVEAU <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
|
|
The leds-gpio driver recently switched to the device property API. The device_node
name is no longer retrieved if the "label" devicetree property is not found.
In this case the driver tries to create entries with (null) name in
/sys/class/leds, which is wrong and generates backtrace as several gpio_leds have
the same name. Also renamed subnode "yellow" to "blue" to match the last
schematics updates.
Signed-off-by: Romain Perier <[email protected]>
Signed-off-by: Heiko Stuebner <[email protected]>
|
|
The suspend/resume sequence on Armada XP needs to modify a number of
registers in the SDRAM controller. Therefore, this commit updates the
Armada XP Device Tree description to include the SDRAM controller
Device Tree node.
Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-17-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
In order to support suspend/resume on Armada XP, an additional set of
registers need to be described at the MBus controller level. This
commit therefore adjusts the Device Tree of the Armada 370/XP SoC to
include those registers in the MBus controller description;
Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-16-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
This commit improves the Armada XP GP Device Tree description to
describe the 3 GPIOs that are used to connect the SoC to the PIC
micro-controller that we talk to shutdown the SoC when entering
suspend to RAM.
Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-15-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
The Armada XP has multiple cores clocked by independent clocks. The
SMP startup code contains a function called set_secondary_cpus_clock()
called in armada_xp_smp_prepare_cpus() to ensure the clocks of the
secondary CPUs match the clock of the boot CPU.
With the introduction of suspend/resume, this operation is no longer
needed when booting the system, but also when existing the suspend to
RAM state. Therefore this commit reworks a bit the logic: instead of
configuring the clock of all secondary CPUs in
armada_xp_smp_prepare_cpus(), we do it on a per-secondary CPU basis in
armada_xp_boot_secondary(), as this function gets called when existing
suspend to RAM for each secondary CPU.
Since the function now only takes care of one CPU, we rename it from
set_secondary_cpus_clock() to set_secondary_cpu_clock(), and it looses
its __init marker, as it is now used beyond the system initialization.
Note that we can't use smp_processor_id() directly, because when
exiting from suspend to RAM, the code is apparently executed with
preemption enabled, so smp_processor_id() is not happy (prints a
warning). We therefore switch to using get_cpu()/put_cpu(), even
though we pretty much have the guarantee that the code starting the
secondary CPUs is going to run on the boot CPU and will not be
migrated.
Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-14-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
The armada_370_xp_cpu_resume() until now was used only as the function
called by the SoC when returning from a deep idle state (as used in
cpuidle, or when the CPU is brought offline using CPU hotplug).
However, it is now also used when exiting the suspend to RAM state. In
this case, it is the bootloader that calls back into this function,
with the MMU left enabled by the BootROM. Having the MMU enabled when
entering this function confuses the kerrnel because we are not using
the kernel page tables at this point, but in other mvebu functions we
use the information on whether the MMU is enabled or not to find out
whether we should talk to the coherency fabric using a physical
address or a virtual address. To fix that, we simply disable the MMU
when entering this function, so that the kernel is in an expected
situation.
Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-13-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
On the Armada XP GP platform, entering suspend to RAM state is
triggering by talking to an external PIC micro-controller connected to
the SoC using 3 GPIOs. There is then a small magic sequence of GPIO
toggling that needs to be used to tell the PIC to turn off the SoC.
The code uses the Device Tree to find out which GPIOs are used to
connect to the PIC micro-controller, and then registers its
mvebu_armada_xp_gp_pm_enter() callback to the SoC-level PM code. The
SoC PM code will call back into this registered function at the very
end of the suspend procedure.
Signed-off-by: Thomas Petazzoni <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-12-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
When going out of suspend to RAM, the Marvell EBU platforms go through
the bootloader, which re-configures the DRAM controller. To achieve
this, the bootloader executes a piece of code called the "DDR3
training code". It does some reads/writes to the memory to find out
the optimal timings for the memory chip being used.
This has the nasty side effect that the first 10 KB of each DRAM
chip-select are overwritten by the bootloader when exiting the suspend
to RAM state.
Therefore, this commit implements the ->reserve() hook for the 'struct
machine_desc' used on Armada XP, to reserve the 10 KB of each DRAM
chip-select using the memblock API.
Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-11-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
This commit implements the core of the platform code to enable
suspend/resume on Armada XP. It registers the platform_suspend_ops
structure, and implements the ->enter() hook of this structure.
It is worth mentioning that this commit only provides the SoC-level
part of suspend/resume, which calls into some board-specific code
provided in a follow-up commit.
The most important thing that this SoC-level code has to do is to
build an in-memory structure that contains a magic number, the return
address in the kernel after resume, and a set of address/value
pairs. This structure is used by the bootloader to restore a certain
number of registers (according to the set of address/value pairs) and
then jump back into the kernel at the provided location.
The code also puts the SDRAM into self-refresh mode, before calling
into board-specific code to actually enter the suspend to RAM state.
[ jac - add email exchange between Andrew Lunn and Thomas Petazzoni to better
describe who consumes the address/value pairs ]
> > Is this a well defined mechanism supported by mainline uboot, barebox
> > etc. Or is it some Marvell extension to their uboot?
>
> As far as I know, it is a Marvell extension to their "binary header",
> so it's done even before U-Boot starts. Since the hardware needs
> assistance from the bootloader to do suspend/resume, there is
> necessarily a certain amount of cooperation/agreement needed by what
> the kernel does and what the bootloader expects. I'm not sure there's
> any "standard" mechanism here. Do you know of any?
>
> I know the suspend/resume on the Blackfin architecture works the same
> way (at least it used to work that way years ago when I did a bit of
> Blackfin stuff). And here as well, there was some cooperation between
> the kernel and the bootloader. See
> arch/blackfin/mach-common/dpmc_modes.S, function do_hibernate() at the
> end.
>
Signed-off-by: Thomas Petazzoni <[email protected]>
Link: https://lkml.kernel.org/r/1416585613-2113-10-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <[email protected]>
|
|
In commit 9c62a68d13119a1ca9718381d97b0cb415ff4e9d ("netpoll:
Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") this
Kconfig option was removed. So remove references to it from
all defconfigs as well.
Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/omap-gpmc
Pull "move omap gpmc to drivers finally" from Tony Lindgren:
We can finally move the GPMC code to live in drivers/memory for
further clean up work.
Note that we still have dependencies to the legacy booting for
omap3 board-*.c files for setting up the board specific memory
timings. For that we need the timing related things still exposed
in include/linux/omap-gpmc.h. This will all become private data
to the GPMC driver once the legacy booting support can be dropped.
* tag 'omap-for-v3.19/gpmc-move-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
memory: gpmc: Move omap gpmc code to live under drivers
ARM: OMAP2+: Move GPMC initcall to devices.c
ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/fixes-non-critical
Pull "ARM: tegra: Core code changes for v3.19" from Thierry Reding:
This contains a single fix for a bug that was introduced back in v3.13.
* tag 'tegra-for-3.19-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: Re-add removed SoC id macro to tegra_resume()
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/defconfig
Pull "ARM: tegra: Default configuration changes for v3.19" from Thierry Reding:
This is merely a regeneration of the default configuration to get rid of
two symbols that are now enabled by default or removed.
* tag 'tegra-for-3.19-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
ARM: tegra: Regenerate default configuration
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
next/dt
Pull "ARM: BCM5301X: Add some more devices to device tree" from Hauke Mehrtens:
The most important part is adding the axi bus to the SoC dtsi file,
this is the main bus on the SoC.
These patches were all send to the arm list and I haven't got any
negative responses.
Signed-off-by: Hauke Mehrtens <[email protected]>
* tag 'bcm5301x-dt-2014-11-27' of https://github.com/hauke/linux:
ARM: BCM5301X: Add LEDs for Netgear R6250 V1
ARM: BCM5301X: Add Broadcom's bus-axi to the DTS file
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
The Cortex-A5x TRM states in paragraph "9.2 Generic Timer functional
description" that generic timers provide an active-LOW interrupt
output. Fix the device trees to correctly describe this.
While doing this update the CPU mask to match the number of described
CPUs as well.
Signed-off-by: Liviu Dudau <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
into next/dt2
Pull "mvebu DT changes for v3.19 (round 3)" from Jason Cooper:
- Armada 375
- Add PHY and USB cluster controller support
* tag 'mvebu-dt-usb-phy-3.19-3' of git://git.infradead.org/linux-mvebu:
ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375
ARM: mvebu: add Device Tree description of USB cluster controller on Armada 375
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"Not much interesting going on fixes-wise for us this week, as it
should be for an -rc7. I'm not expecting Olof to work much over
Thanksgiving weekend, so I decided to take over again and push these
out to you.
Just four simple fixes this week:
- one missing of_node_put() on armv7 based mvebu
- forcing the USB host into the right mode on Chromebook
(exynos5-snow)
- enabling two important drivers for exynos_defconfig
- fixing a noncritical bug for tegra that would cause a regression
with common code patches queued for 3.19"
* tag 'armsoc-for-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: tegra: irq: fix buggy usage of irq_data irq field
ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
ARM: dts: Explicitly set dr_mode on exynos5250-snow
ARM: mvebu: add missing of_node_put() call in coherency.c
|
|
Pull ARM fixes from Russell King:
"Another round of relatively small ARM fixes.
Thomas spotted that the strex backoff delay bit was a disable bit, so
it needed to be clear for this to work. Vladimir spotted that using a
restart block for the cache flush operation would return -EINTR, which
userspace was not expecting. Dmitry spotted that the auxiliary
control register accesses for Xscale were not correct"
* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 8226/1: cacheflush: get rid of restarting block
ARM: 8222/1: mvebu: enable strex backoff delay
ARM: 8216/1: xscale: correct auxiliary register in suspend/resume
|
|
Linux 3.18-rc4 is a dependency for the phy-dt-header branch that
is needed for the final mvebu DT changes.
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Pull "mvebu DT changes for v3.19 (round 2)" from Jason Cooper:
- mvebu
- Use simple-card audio on Armada 370 DB
- Add DSA node for Armada 370 DB
- Add SDHCI to Armada 38x
- Armada 370/XP rework to support new Synology boards
- Add Synology DS213j and DS414
- Various pinctrl and uart and alias fixes to help bootloaders
* tag 'mvebu-dt-3.19-2' of git://git.infradead.org/linux-mvebu:
arm: mvebu: normalize pinctrl entries for Armada SoCs
arm: mvebu: fix wrongly named DS414 pinctrl entries
arm: mvebu: add .dts file for Synology DS414
arm: mvebu: add .dts file for Synology DS213j
arm: mvebu: define and use common Armada XP SPI pinctrl setting
arm: mvebu: define and use common Armada XP UART2/3 pinctrl settings
arm: mvebu: define and use common Armada 370 UART pinctrl settings
arm: mvebu: define and use common Armada 370 SPI pinctrl settings
arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi
arm: mvebu: use recently introduced uart label for stdout-path
arm: mvebu: add uartX labels for Armada SoC serial nodes
arm: mvebu: fix vendor prefix typo in kirkwood-synology.dtsi
ARM: mvebu: fix ordering in Armada 370 .dtsi
ARM: mvebu: adjust ethernet aliases according to U-Boot requirements for A38x
ARM: mvebu: remove clock-frequency from Armada 38x SDHCI Device Tree node
ARM: mvebu: enable no-1-8-v flag for Armada 385 DB SDHCI interface
mvebu: 370 RD: Add support for the switch
ARM: mvebu: use simple-card DT binding for audio on Armada 370 DB
ARM: mvebu: remove conflicting muxing on Armada 370 DB
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
into next/defconfig
Pull "mvebu defconfig changes for v3.19 (round 2)" from Jason Cooper:
- mvebu
- Add SDHCI, i2c, and MTD_BLOCK
* tag 'mvebu-defconfig-3.19-2' of git://git.infradead.org/linux-mvebu:
ARM: mvebu: add MTD_BLOCK to mvebu_v7_defconfig
ARM: mvebu: enable i2c device in mvebu_v7_defconfig
ARM: mvebu: re-enable SDHCI driver for Armada 38x SoC in v7 defconfig
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Pull "mvebu SoC changes for v3.19" from Jason Cooper:
- Armada 38x
- Implement CPU hotplug support
- Armada 375
- Remove Z1 stepping support (limited dist. of SoC)
* tag 'mvebu-soc-3.19' of git://git.infradead.org/linux-mvebu:
ARM: mvebu: Implement the CPU hotplug support for the Armada 38x SoCs
ARM: mvebu: Fix the secondary startup for Cortex A9 SoC
ARM: mvebu: Move SCU power up in a function
ARM: mvebu: Clean-up the Armada XP support
ARM: mvebu: update comments in coherency.c
ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherency
ARM: mvebu: remove unused register offset definition
ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP
ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric
ARM: mvebu: Remove thermal quirk for A375 Z1 revision
ARM: mvebu: add missing of_node_put() call in coherency.c
ARM: orion: Fix for certain sequence of request_irq can cause irq storm
ARM: mvebu: armada xp: Generalize use of i2c quirk
Signed-off-by: Arnd Bergmann <[email protected]>
|