The following parameters are no longer needed by the edma driver since the
information can be obtained from the IP's CCCFG register:
n_channel, n_region, n_slot and n_tc.
Remove the initialization of n_cc as well since in this context it has no
meaning. We have separate edma_soc_info struct/eDMA3_CC instance so this
member does not make any sense (and the driver no longer uses it).
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE

In case when booted with DT or the queue_priority_mapping is not provided
set up a default priority map.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

To be consistent in the code that we take parameters from edma_cc[j] struct
and not randomly from info[j] as well.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

The struct edma is allocated per CC bases so the member num_cc does not make
any sense. One CC is one CC, it does not have sub CCs.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

It is ignored by the edma driver since we are just setting back the default
mapping of TC -> Queue.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

There is no need to change the default TC -> Queue mapping. By default the
mapping is: TC0 -> Q0, TC1 -> Q1, etc.
Changing this has no benefits at all and all the board files are just setting
the same mapping back to the HW.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Instead of saving the for loop length, take the num_tc value from the pdata.
In case of DT boot set the n_tc to 3 as it is hardwired in edma_of_parse_dt()
This is a temporary state since upcoming patch(es) will change how we are
dealing with these parameters.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

The pdata has been just allocated with devm_kzalloc() in
edma_setup_info_from_dt() and passed to this function.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Get the two interrupt line number at the same time by merging the two
instance of if(node){}else{} places.
replace the &pdev->dev with the already existing dev which makes it possible
to collapse lines with devm_request_irq()
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

As Joel pointed out, edma_read_position() uses memcpy_fromio() to read
the parameter ram. That's not synchronized with the internal update as
it does a byte by byte copy. We need to do a 32bit read to get a
consistent value.

Further reading destination and source is pointless. In DEV_TO_MEM
transfers we are only interested in the destination, in MEM_TO_DEV we
care about the source. In MEM_TO_MEM it really does not matter which
one you read.

Simple solution: Remove the pointers, select dest/source via a bool
and return the read value.

Remove the export of this function while at it. The only potential
user is the dmaengine and that's always builtin.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This is another great example of trainwreck engineering:

commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
added support for using EDMA on peripherals which have no direct EDMA
event mapping.

The code compiles and does not explode in your face, but that's it.

1) Reading an u16 array from an u32 device tree array simply does not
   work. Even if the function is named "edma_of_read_u32_to_s16_array".

   It merily calls of_property_read_u16_array. So the resulting 16bit
   array will have every other entry = 0.

2) The DT entry for the xbar registers related to xbar has length 0x10
   instead of the real length: 0xfd0 - 0xf90 = 0x40.

   Not a real problem as it does not cross a page boundary, but
   wrong nevertheless.

3) But none of this matters as the mapping never happens:

   After reading nonsense edma_of_read_u32_to_s16_array() invalidates
   the first array entry pair, so nobody can ever notice the
   braindamage by immediate explosion.

Seems the QA criteria for this code was solely not to explode when
someone adds edma-xbar-event-map entries to the DT. Goal achieved,
congratulations!

Not really helpful if someone wants to use edma on a device which
requires a xbar mapping.

Fix the issues by:

- annotating the device tree entry with "/bits/ 16" as documented in
  the of_property_read_u16_array kernel doc

- make the size of the xbar register mapping correct

- invalidating the end of the array and not the start

This convoluted mess wants to be completely rewritten as there is no
point to keep the xbar_chan array memory and the iomapping of the xbar
regs around forever. Marking the xbar mapped channels as used should
be done right there.

But that's a different issue and this patch is small enough to make it
work and allows a simple backport for stable.

Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

The kvm/mmu code shared by arm and arm64 uses kalloc() to allocate
a bounce page (if hypervisor init code crosses page boundary) and
hypervisor PGDs. The problem is that kalloc() does not guarantee
the proper alignment. In the case of the bounce page, the page sized
buffer allocated may also cross a page boundary negating the purpose
and leading to a hang during kvm initialization. Likewise the PGDs
allocated may not meet the minimum alignment requirements of the
underlying MMU. This patch uses __get_free_page() to guarantee the
worst case alignment needs of the bounce page and PGDs on both arm
and arm64.

Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: NMark Salter <msalter@redhat.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

KVM currently crashes and burns on big-endian hosts, so don't allow it
to be selected until we've got that fixed.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

The mmu-gather operation 'tlb_flush_mmu()' has done two things: the
actual tlb flush operation, and the batched freeing of the pages that
the TLB entries pointed at.

This splits the operation into separate phases, so that the forced
batched flushing done by zap_pte_range() can now do the actual TLB flush
while still holding the page table lock, but delay the batched freeing
of all the pages to after the lock has been dropped.

This in turn allows us to avoid a race condition between
set_page_dirty() (as called by zap_pte_range() when it finds a dirty
shared memory pte) and page_mkclean(): because we now flush all the
dirty page data from the TLB's while holding the pte lock,
page_mkclean() will be held up walking the (recently cleaned) page
tables until after the TLB entries have been flushed from all CPU's.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: NDave Hansen <dave.hansen@intel.com>
Acked-by: NHugh Dickins <hughd@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some Marvell PJ4B CPUs also implement iWMMXt extensions. With a
proper check for iWMMXt coprocessors now in place, enable it by
default on PJ4B. While at it, also allow to manually select
the corresponding Kconfig option.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit fdb487f5
  ("ARM: 8015/1: Add cpu_is_pj4 to distinguish PJ4 because it
    has some differences with V7")
introduced a cpuid check for Marvell PJ4 processors to fix a
regression caused by adding PJ4 based Marvell Dove into
multi_v7.

Unfortunately, this check is too narrow to catch PJ4 used on
Dove itself and breaks iWMMXt support.

This patch therefore relaxes the cpuid mask to match both PJ4
and PJ4B. Also, rework the given comment about PJ4/PJ4B
modifications to be a little bit more specific about the
differences.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

commit fdb487f5
  ("ARM: 8015/1: Add cpu_is_pj4 to distinguish PJ4 because it
    has some differences with V7")
introduced a fix for checking PJ4 cpuid to not use PJ4 specific
coprocessor access on non-PJ4 platforms.

Unfortunately, this in turn broke Marvell Armada 370/XP, both
comprising Marvell PJ4B CPUs without iWMMXt extension. Instead
of only checking for cpuid, which may not be sufficient to
determine iWMMXt support, the presence of iWMMXt coprocessors
can be checked by enabling and reading the Coprocessor ID
register (wCID, register 0 of CP1).

Therefore this adds an explicit check for the presence and correct
wCID value, before enabling iWMMXt capabilities. As a bonus, also
print the iWMMXt version of a detected coprocessor.

This has been tested to properly detect iWMMXt presence/absence on:
- PJ4,  CPUID 0x560f5815, wCID 0x56052001: Marvell Dove, iWMMXt v2
- PJ4B, CPUID 0x561f5811: Marvell Armada 370, no iWMMXt
- PJ4B, CPUID 0x562f5841, wCID 0x56052001: Marvell Armada 1500, iWMMXt v2
- PJ4B, CPUID 0x562f5842: Marvell Armada XP, no iWMMXt
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This fixes PJ4 coprocessor init to only expose iWMMXt capabilities,
if the corresponding kernel support for iWMMXt is enabled.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

iwmmxt.S requires special treatment of coprocessor access registers
for PJ4 and XScale-based CPUs. It only checks for CPU_PJ4 and drops
down to XScale-based treatment on all other architectures.

As some PJ4B also come with iWMMXt and also need PJ4 treatment,
rework the corresponding preprocessor directives to explicitly
check for supported architectures and fail on unsupported ones.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The SPC stores voltage in mV while the code assumes it was returning
uV. Convert the returned voltage to uV before storing. Also fix the
comment depicting voltage to uV.
Signed-off-by: NPunit Agrawal <punit.agrawal@arm.com>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>

Tegra124 only has 4 UARTs. Parts of the documentation hint at a fifth
UART, but this appears to be left-over from earlier SoC documentation.
Remove the non-existent DT node for UART5.

Cc: <stable@vger.kernel.org>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Commit a7cbe92c ("ARM: tegra: remove tegra EMC scaling driver")
removed the only user of TEGRA_EMC_SCALING_ENABLE. Remove its Kconfig
entry too.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Few things were out of order:

- removed ARCH_BCM2835 duplicate
- shuffled ARCH_BCM_5301X, ARCH_U8500 and ARCH_U300 around so to keep the
  list sorted

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Signed-by: NDomenico Andreoli <domenico.andreoli@linux.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

In commit ddb902cc (ARM: centralize common multi-platform kconfig
options), CLKSRC_OF was removed from some platforms, but not added to
ARCH_MULTIPLATFORM. Fix this.
Reported-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

I get a build warning because spear_clocksource_init() calls
clocksource_mmio_init(), but it doesn't have an __init annotation.
Fix that.
Signed-off-by: NAlex Elder <elder@linaro.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

hx4700 needs the same fix as in
9705e746
"ARM: pxa: fix various compilation problems"

Fix build errors. Initial one is:
/linux/arch/arm/mach-pxa/include/mach/hx4700.h:18:32: error:
 'PXA_NR_BUILTIN_GPIO' undeclared here (not in a function)
|  #define HX4700_ASIC3_GPIO_BASE PXA_NR_BUILTIN_GPIO

Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: NAndrea Adami <andrea.adami@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

dcscb_allcpus_mask is an array of size 2.

The index variable cluster has to be checked against this limit
before accessing the array.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NPawel Moll <pawel.moll@arm.com>

At least the smc91x driver expects the device to be at 0x300
offset from bus base address. This does not work currently
for GPMC when booted in device tree mode as it attempts to
remap the the allocated GPMC partition to the address
configured by the device tree plus the device offset.

Note that this works just fine when booted with legacy mode.

Let's fix the issue by just ignoring any device specific
offset while remapping. And let's make sure the remap
address confirms to the GPMC 16MB minimum granularity
as listed in the TRM for GPMC_CONFIG7 BASEADDRESS bits.

Otherwise we can get something like this:

omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300

Cc: Pekon Gupta <pekon@ti.com>
Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

68efd7d2("arm: dma-mapping: remove order parameter from
arm_iommu_create_mapping()") is causing kernel panic
because it wrongly sets the value of mapping->size:

Unable to handle kernel NULL pointer dereference at virtual
address 000000a0
pgd = e7a84000
[000000a0] *pgd=00000000
...
PC is at bitmap_clear+0x48/0xd0
LR is at __iommu_remove_mapping+0x130/0x164

Fix it by correcting mapping->size value.
Signed-off-by: NRitesh Harjani <ritesh.harjani@gmail.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>

s/interrupts-names/interrupt-names/g
s/clocks-names/clock-names/g

Some of the binding files and device tree files get this wrong and the
kernel won't be able to pick it up. Fix them up now so that they don't
get widely used.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by : Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
[dropped arch/arm/include/asm/unistd.h changes --rmk]
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix e26a9e00 'ARM: Better
virt_to_page() handling' replaced __pv_phys_offset with
__pv_phys_pfn_offset. Also note that size of __pv_phys_offset
was quad but size of __pv_phys_pfn_offset is word. Instruction
that used to update __pv_phys_offset which address is in r6
had to update low word of __pv_phys_offset so it used #LOW_OFFSET
macro for store offset. Now when size of __pv_phys_pfn_offset is
word, no difference between little endian and big endian should
exist - i.e no offset should be used when __pv_phys_pfn_offset
is stored.

Note that for little endian image proposed change is noop,
since in little endian case #LOW_OFFSET is defined 0 anyway.
Reported-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The switcher should not depend on MAX_CLUSTER to determine ifit should
be activated or not. In a multiplatform kernel binary it is possible to
have dual-cluster and quad-cluster platforms configured in. In that case
MAX_CLUSTER which is a build time limit should be 4 and that shouldn't
prevent the switcher from working if the kernel is booted on a b.L
dual-cluster system.

In bL_switcher_halve_cpus() we already have a runtime validation check
to make sure we're dealing with only two clusters, so booting on a quad
cluster system will be caught and switcher activation aborted.

However, the b.L switcher must ensure the MCPM layer is initialized on
the booted hardware before doing anything.  The mcpm_is_available()
function is added to that effect.
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Tested-by: NAbhilash Kesavan <kesavan.abhilash@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

For vmcore generated by LPAE enabled kernel, user space
utility such as crash needs additional infomation to
parse.

So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
i386 linux does.

Cc: <stable@vger.kernel.org>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NLiu Hua <sdu.liu@huawei.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result.

When viewing ftrace record in big-endian ARM systems, we found that
the timestamp errors:

swapper-0   [001] 1325.970000:   0:120:R ==> [001]    16:120:R events/1
events/1-16 [001] 1325.970000:   16:120:S ==> [001]    0:120:R swapper
swapper-0   [000] 1325.1000000:  0:120:R   + [000]    15:120:R events/0
swapper-0   [000] 1325.1000000:  0:120:R ==> [000]    15:120:R events/0
swapper-0   [000] 1326.030000:   0:120:R   + [000]  1150:120:R sshd
swapper-0   [000] 1326.030000:   0:120:R ==> [000]  1150:120:R sshd

When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2".
Reviewed-by: NDave Martin <Dave.Martin@arm.com>
Reviewed-by: NNicolas Pitre <nico@linaro.org>
Cc: <stable@vger.kernel.org> # 2.6.20+
Signed-off-by: NAlex Wu <wuquanming@huawei.com>
Signed-off-by: NXiangyu Lu <luxiangyu@huawei.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Indicate that the edma dmaengine driver has support for cyclic mode.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJoel Fernandes <joelf@ti.com>
Reviewed-and-Tested-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

For later use save the number of queues available for the CC.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJoel Fernandes <joelf@ti.com>
Reviewed-and-Tested-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>