| Age | Commit message (Collapse) | Author |
|---|
|
This patch drops support for AVR32 architecture from the Linux kernel.
The AVR32 architecture is not keeping up with the development of the
kernel, and since it shares so much of the drivers with Atmel ARM SoC,
it is starting to hinder these drivers to develop swiftly.
Also, all AVR32 AP7 SoC processors are end of lifed from Atmel (now
Microchip).
Finally, the GCC toolchain is stuck at version 4.2.x, and has not
received any patches since the last release from Atmel;
4.2.4-atmel.1.1.3.avr32linux.1. When building kernel v4.10, this
toolchain is no longer able to properly link the network stack.
Haavard and I have came to the conclusion that we feel keeping AVR32 on
life support offers more obstacles for Atmel ARMs, than it gives joy to
AVR32 users. I also suspect there are very few AVR32 users left today,
if anybody at all.
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Håvard Skinnemoen <hskinnemoen@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
|
|
Most arches have an asm/gpio.h that merely includes linux/gpio.h. The
others select ARCH_HAVE_CUSTOM_GPIO_H, and when that's selected,
linux/gpio.h includes asm/gpio.h.
Therefore, code should include linux/gpio.h instead of including asm/gpio.h
directly.
Remove includes of asm/gpio.h, adding an include of linux/gpio.h when
necessary.
This is a follow-on to 7563bbf89d06 ("gpiolib/arches: Centralise
bolierplate asm/gpio.h").
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Switch to the generic leds_pwm driver instead of leds-atmel-pwm.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
Both at91 and avr32 defines its own platform data structure for
the macb driver and both share common structures though at91
includes a currently unused phy_irq_pin. Create a common
macb_platform_data for macb that both at91 and avr32 can use. In
future we can use this to support other architectures that use the
same IP block with the macb driver.
v2: rename eth_platform_data to macb_platform_data and allow at91_ether
to share the platform data with macb.
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
|
clk_get() returns ERR_PTR() on error, not NULL.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
|
|
Same patch as before, modified to use bool.
This patch solves the problem with the inverted mci detect pin on Merisc
boards.
Signed-off-by: Jonas Larsson <jonas.larsson@martinsson.se>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
|
|
Adds extra parameter to AT32 at32_map_usart(), so as to reserve
RTS/CTS/CLK pins.
All boards under arch/avr32/boards have been updated (trivial change), but
not all have been tested.
Signed-off-by: Peter Ma <pma@mediamatech.com>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
|
|
This patch adds RTC support for the Merisc boards.
Signed-off-by: Jonas Larsson <jonas.larsson@martinsson.se>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
|
|
Merisc is the family name for a range of AVR32-based boards.
The boards are designed to be used in a man-machine interfacing
environment, utilizing a touch-based graphical user interface. They host
a vast range of I/O peripherals as well as a large SDRAM & Flash memory
bank.
For more information see: http://www.martinsson.se/merisc
Signed-off-by: Jonas Larsson <jonas.larsson@martinsson.se>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
|
