copied target/linux/x86/config-3.14 and target/linux/x86/patches-3.14 to
3.18 equivalents and then tweaked until it built.
Tested on alix2, soekris net4826 and soekris net4521.
Still having trouble with net4826 booting from Grub, alix2 and net4521
are fine.
Signed-off-by: Russell Senior <russell@personaltelco.net>
SVN-Revision: 44758
Move first 3 patches to 0xx numbers range to denote that this is
backported code and they should be removed when we update
kernel to version >= 3.19
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44732
To finally sync code with upsream cleanup registers headers, and update
several comments and kernel config symbols descriptions. No functional
changes.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44731
Cleanup board patch by moving code to specific patches, and factor out
leds to separate patch. No functional changes.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44729
Move GPIO patches behind PCI patch, since they are not yet merged
upstream.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44728
Make register names more consistent, mostly add appropriate prefix
(AR5312_ or AR2315_) or _BASE suffix. Also add macro to simplify mask
and shift operation.
No functional changes.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44726
There are no external users (last one was PCI driver) for these headers,
so move them to arch directory. Few macroses from ar231x.h header moved
to devices.h and file was removed.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44724
Honestly remap main SoC MMR mem and use accessor functions to
interact with registers. Now registers defined relatively to base
address (e.g. SDRAM controller base address).
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44723
AFAIK, no one AR2315+ chip (AR2315, AR2316, AR2317, AR2318) does not
contain IR block, so remove IR registers definitions. Also remove few
unused macroses.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44722
Pass PCI IRQ and I/O memory ranges via platform device resources, this
change makes PCI controller driver independed from arch headers, so
also remove few includes.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44721
Honestly remap PCI controller MMR and use accessor functions to interact
with registers.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44720
Add container and place all context specific variables and structure to
it.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44719
Put AR2315_PCI_HOST_SDRAM_BASEADDR macro to DMA header, since this is
arbitrary value and not some hw specific constant. Also this relocation
decouples dma from HW specific header.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44716
Do not use prom_init() callback, do memory initialization in
plat_mem_setup() callback and move serial port configuration to
arch_initcall stage.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44715
Check SoC family (AR5312+ or AR2315+) before call instead of checking it
inside the called function. Also convert ar{5312,2315}_init_device()
function to void, since they both return zero and nobody care about
return value.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44713
Sync functions, variables and enums names with upstream. Mostly replace
'ar231x_' prefix by 'ath25_'.
No functional changes, except few 'int' -> 'unsigned' changes.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44712
Ethernet controller driver don't use boarddata directly, so remove
corresponding field from its platform device structure.
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
SVN-Revision: 44710
This problem has existed at least since Attitude Adjustment and
is also present in trunk. Basically on the Hornet-UB board the
functionality of RESET and WPS have "switched places".
There are two tickets about the issue at dev.openwrt.org,
The solution suggested on them both is incomplete though
and introduces the following proglem:
Patching as suggested on #14136/#15282 will result in a situation
where simply pressing the RESET button on the bottom will cause
FACTORY RESET to be run. This is due to GPIO high/low state being
incorrect as a result of the above change and virtually the RESET
button is in the pressed-down state the entire time. When it is
then physically pressed, that causes the opposite, release, to be
triggered and since to the board it seemed that the button was
pressed long before it was released, the FACTORY RESET results.
The attached patch works as expected. I have verified both the
incorrect functionality as well as after fixing the issue as
described in the patch and flashing the resulting firmware to a
Hornet-UB board.
Signed-off-by: Janne Cederberg <janne.cederberg@gmail.com>
SVN-Revision: 44692
