this patch adds UART0 and UART1 as LLUART port, as the new Atlas7
registers layout are different, it also refines some names of old
hard-coded MARCOs and uses CONFIG_DEBUG_UART_PHYS/DEBUG_UART_VIRT
to define different base addresses for multiple ports.
Signed-off-by: Guo Zeng <Guo.Zeng@csr.com>
Signed-off-by: Zhiwu Song <Zhiwu.Song@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
imx6q_opp_check_speed_grading() remaps memory to the base variable and
never unmaps it. I can't see how this can be of any use later so here I
unmap it.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The mvebu-mbus driver reads the SDRAM window registers, and make the
information about the DRAM CS configuration available to device
drivers using the mv_mbus_dram_info() API. This information is used by
the DMA-capable device drivers to program their address decoding
windows.
Until now, we were basically providing the SDRAM window register
details as is. However, it turns out that the DMA capability of the
CESA cryptographic engine consists in doing DMA being the DRAM and the
crypto SRAM mapped as a MBus window. For this case, it is very
important that the SDRAM CS information does not overlap with the MBus
bridge window.
Therefore, this commit improves the mvebu-mbus driver to make sure we
adjust the SDRAM CS information so that it doesn't overlap with the
MBus bridge window. This problem was reported by Boris Brezillon,
while working on the mv_cesa driver for Armada 37x/38x/XP. We use the
memblock memory information to know where the usable RAM is located,
as this information is guaranteed to be correct on all SoC variants.
We could have used the MBus bridge window registers on Armada 370/XP,
but they are not really used on Armada 375/38x (Cortex-A9 based),
since the PL310 L2 filtering is used instead to discriminate between
RAM accesses and I/O accesses. Therefore, using the memblock
information is more generic and works accross the different platforms.
Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Fixed merge conflict]
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.
To make things even more fun, the hardware designers have chosen to
put the window 13 remap registers in a completely custom location,
using a logic that differs from the one used for all other remappable
windows.
To solve this problem, this commit:
* Adds a SoC specific function to calculate offset of remap registers
to the mvebu_mbus_soc_data structure. This function,
->win_remap_offset(), returns the offset of the remap registers, or
MVEBU_MBUS_NO_REMAP if the window does not have the remap
capability. This new function replaces the previous integer field
num_remappable_wins, which was insufficient to encode the special
case of window 13.
* Adds an implementation of the ->win_remap_offset() function for the
various SoC families. Some have 2 first windows that are remapable,
some the 4 first, some the 8 first, and then the Armada XP/375/38x
case where the 8 first are remapable plus the special window
13. This is implemented in functions
generic_mbus_win_remap_2_offset(),
generic_mbus_win_remap_4_offset(),
generic_mbus_win_remap_8_offset() and
armada_xp_mbus_win_remap_offset() respectively.
* Change the code to use the ->win_remap_offset() function when
accessing the remap registers, and also to use a newly introduced
mvebu_mbus_window_is_remappable() helper function that tells
whether a given window is remapable or not.
* Separate Armada 370 from XP/375/38X because the window 13 of Armada
370 does not support the remap capability.
[Thomas: adapted for the mainline kernel, minor clarifications in the
code, reword the commit log.]
Signed-off-by: Michal Mazur <arg@semihalf.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Undo the simple fix for stable]
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Now that we have enabled automatic I/O synchronization barriers, we no
longer need any explicit barriers. We can therefore simplify
arch/arm/mach-mvebu/coherency.c by using the existing
arm_coherent_dma_ops instead of our custom mvebu_hwcc_dma_ops, and
re-enable hardware I/O coherency support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Remove forgotten comment]
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Instead of using explicit I/O synchronization barriers shoehorned
inside the streaming DMA mappings API (in
arch/arm/mach-mvebu/coherency.c), we are switching to use automatic
I/O synchronization barrier.
The primary motivation for this change is that explicit I/O
synchronization barriers are not only needed for streaming DMA
mappings (which can easily be done by overriding the dma_map_ops), but
also for coherent DMA mappings (which is a lot less easy to do, since
the kernel assumes such mappings are coherent and don't require any
sort of cache maintenance operation to ensure the consistency of the
buffers).
Switching to automatic I/O synchronization barriers will also allow us
to use the existing arm_coherent_dma_ops instead of our custom
arm_dma_ops.
In order to use automatic I/O synchronization barriers, this commit
changes mvebu-mbus in two ways:
- It enables automatic I/O synchronization barriers in the 0x84
register of the MBus bridge, by enabling such barriers for all MBus
units. This enables automatic barriers for the on-SoC peripherals
that are doing DMA.
- It enables the SyncEnable bit in the MBus windows, so that PCIe
devices also use automatic I/O synchronization barrier.
This automatic synchronization barrier relies on the assumption that
at least one register of a given hardware unit is read before the
driver accesses the DMA mappings modified by this unit. This
assumption is guaranteed for PCI devices by vertue of the PCI
standard, and we can reasonably verify that this assumption is also
true for the limited number of platform drivers doing DMA used on
Marvell EBU platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.
As a minimal fix for stable, don't use window 13. A full fix will
follow later.
Fixes: fddddb52a6 ("bus: introduce an Marvell EBU MBus driver")
Cc: <stable@vger.kernel.org> # v3.10+
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
When an error occurs during an scm call the error returned is remapped so
we lose the original error code. This means that when an error occurs we
have no idea what actually failed within the secure environment.
Add a logging statement that will log the actual error code from scm call
allowing us to easily determine what caused the error to occur.
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
scm_call flushes the entire cache before calling into the secure world.
This is both a performance penalty as well as insufficient on SMP systems
where the CPUs possess a write-back L1 cache. Flush only the command and
response buffers instead, moving the responsibility of flushing any other
cached buffer (being passed to the secure world) to callers.
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Instead of hardcoding the cacheline size as 32, get the cacheline size from
the CTR register.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
The cache invalidation in scm_call() correctly rounds down the start
address to invalidate the beginning of the cacheline but doesn't properly
round up the 'end' address to make it aligned. The last chunk of the
buffer won't be invalidated when 'end' is not cacheline size aligned so
make sure to invalidate the last few bytes in such situations. It also
doesn't do anything about outer caches so make sure to invalidate and flush
those as well.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
We can run qcom platforms in big-endian mode. Select the option.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
If the CPU is in big-endian mode these macros will access the
hardware incorrectly. Reverse thins as necessary to fix this.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Add another SoC address for apq8064 and use DEBUG_UART_VIRT
instead of DEBUG_UART_BASE because the former actually exists.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
The current hardware I/O coherency is known to cause problems with DMA
coherent buffers, as it still requires explicit I/O synchronization
barriers, which is not compatible with the semantics expected by the
Linux DMA coherent buffers API.
So, in order to have enough time to validate a new solution based on
automatic I/O synchronization barriers, this commit disables hardware
I/O coherency entirely. Future patches will re-enable it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Move at91rm9200_idle() along with at91sam9_idle() in clk/at91/pmc.c.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
SRAM initialization is now done through the mmio-sram driver and
at91_init_sram() is not called anymore, remove it.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Now that the SRAM is initialized by the mmio-sram driver, .map_io is useless.
remove it.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Split at91_pm_init() in three variants that are called by the respective SoCs
.init_machine. This allows to remove the of_machine_is_compatible() calls and
move at91_pm_init() out of arch_initcall() which is required for multiplatform.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Check UDP and UHP on sam9x5, sam9n12 and the sama5 series.
Check UHP on the sam9g45.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Now that the SRAM is part of a genpool, use it to allocate memory to use for the
slowclock implementation.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Store SoC differences in a struct to remove cpu_is_* usage.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
- little typo and a LED declared
- addition of the Special Function Registers (SFR) + its binding
- RTC & SRAM nodes
- the at91sam9xe has its own .dtsi now. Not combined with at91sam9260 anymore
- addition of the Image Sensor Interface (ISI) DT part and supported sensors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJUt+9WAAoJEAf03oE53VmQrlQH/2gLux3w9NMBm6GKDAJe3ZbY
JSiT9JIpcDmvVPXheeXQc0gZFGbfg8kcbx6mopPR/n6gAeP0npRApmQxS04M9M6b
HyAyj26s1h79WZOki7hhsIw6bhMCNDb7ODoDOw4F6U1/WWLh+uZY3fg+HO2CFBS8
wyDWKQQWAe0LvbaB44iw5cGsZ2+8/1rb5R7w7AqITjLTOGLvJZn50TYlY6hRrb+7
qfD0gqaRzX6axdtsGVNzkuYUuLQ3rE9IhgauhHlge9QT1Lkl4wfONnGiOFeIc+n0
tcHLb3BYBqOKDbOop+3ED3bqxcmobUIQIlEutvg5lnFkWeVYnXgkIFxHPpEK4K0=
=RH2X
-----END PGP SIGNATURE-----
Merge tag 'at91-dt' into at91-3.20-cleanup
Add a special case for PM domains containing a memory-controller.
Such a PM domain must not be turned off if memory is in use.
On sh73a0 PM domains A4BC0 and A4BC1 each contain an SDRAM Bus State
Controller (SBSC). On r8a73a4 PM domain A3BC contains two DDR Bus
Controllers (DBSC). In both cases, there are no other devices in these
PM domains, so they were eligible for power down, crashing the system.
On r8a7740 the DDR3 Bus State Controller (DBSC3) is located in A4S,
whose child domain A3SM contains the CPU core. Hence A4S is never turned
off, and no crash happened.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Make adding special PM domains to an array, and looking them up
later, more generic, so it can be used for all special hardware blocks.
The type of PM domain is also stored, so rmobile_setup_pm_domain() can
use a switch() statement instead of a chain of if/else statements.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Consolidate the identical rmobile_pd_suspend_*() routines that just
return -EBUSY to prevent a PM domain from being powered down into a
single rmobile_pd_suspend_busy().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
According to v4l2 dt document, we add:
a camera host: ISI port.
a i2c camera sensor: ov2640 port.
to sama5d3xmb.dtsi.
The ov2640 node defines the pinctrls, clocks and refer to isi port.
The ISI node also has a reference to the ov2640 port.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
For sama5d3xmb board, the pins: pinctrl_isi_pck_as_mck is pck1, and
used to provide MCK for camera sensor.
We change its name to: pinctrl_pck1_as_isi_mck.
As we want camera sensor instead of ISI to configure the pck1 (ISI_MCK) pin.
So we remove this pinctrl from ISI DT node. It will be added in sensor's
DT node.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
For sama5d3xmb board, the pins: pinctrl_isi_{power,reset} is used to
power-down or reset camera sensor.
So we should let camera sensor instead of ISI to configure the pins.
This patch will change pinctrl name from pinctrl_isi_{power,reset} to
pinctrl_sensor_{power,reset}. And remove these two pinctrl from ISI's
DT node. We will add these two pinctrl to sensor's DT node.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
The mck is decided by the board design, move it to mb related
dtsi file.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
The ISI has 12 data lines, add the missing two data lines.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
As the ISI has 12 data lines, however we only use 8 data lines with
sensor module. So, split the data line into two groups which make
it can be choosed depends on the hardware design.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
The ethernut5 is actually based on an at91sam9xe, use the correct dts include.
Cc: Martin Reimann <martin.reimann@egnite.de>
Cc: Tim Schendekehl <tim.schendekehl@egnite.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
at91sam9xe is slightly different from at91sam9260, in particular it has a
different SRAM size and location.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Add nodes for the SRAM available on atmel SoCs
For the at91sam9260 and the at91sam9g20, address mirroring is used to create a
single contiguous SRAM range instead of declaring two separate banks.
Also remove leftover TODOs in the sam9g45 file
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[nicolas.ferre@atmel.com: correct at91sam9rl sram size => 0x10000]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Enable the RTC on the at91rm9200ek.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Add a node for the RTC available on at91rm9200.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Add node for the RTC available on the at91sam9n12.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Since all rm9200 board files have been removed, there is no user of
at91rm9200_set_type() left. Remove it
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
at91rm9200_dt_initialize() is doing the same as at91_dt_initialize(), use that
one instead.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Move debug-macro.S from include/mach/ to include/debug where all other common
debug macros are.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
The irq fixup from at91_sysirq_mask_rtc and at91_sysirq_mask_rtt is now handled
by aic_common_rtc_irq_fixup and aic_common_rtt_irq_fixup. Remove those useless
functions.
Also remove the now unused mach/at91_rtt.h header.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Now that at91sam9 SoCs are only supported through DT, remove
CONFIG_MACH_AT91SAM9_DT and use CONFIG_SOC_AT91SAM9 instead.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Now that rm9200 is only supported through DT, remove CONFIG_MACH_AT91RM9200_DT
and use CONFIG_SOC_AT91RM9200 instead.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
CONFIG_NEED_MACH_MEMORY_H is not set by any at91 platform, remove mach/memory.h
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
