* [PATCH] ARM: EXYNOS: exynos4-dt: Set .smp field of machine descriptor
From: Kukjin Kim @ 2012-10-22 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2W-Tg5ZwzwuXg3-56KhiLwQS3rGktweRG8XwdVMda=HBg@mail.gmail.com>
Kyungmin Park wrote:
>
> + Arnd, Olof,
>
> Tomasz,
> I think it's better to add arm-soc maintainers at CC when send the
patches.
> Samsung patches doesn't handled or merged with proper time.
>
I did just now. Sorry for late.
[...]
> > Ping. I think this should be considered a fix.
> >
Tomasz, yes I applied this in my -fix. Note this will be sent to upstream
with other Samsung fixes during 3.7-rc, probably in a couple of days.
Thanks for your reminder.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: EXYNOS: exynos4-dt: Set .smp field of machine descriptor
From: Kukjin Kim @ 2012-10-21 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350035378-31989-1-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> This patch adds missing initializer of .smp field of machine descriptor
> of Exynos 4 DT machine.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> ---
> arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-
> exynos/mach-exynos4-dt.c
> index 7222e3c..d6bdcfb 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -119,6 +119,7 @@ static char const *exynos4_dt_compat[] __initdata = {
>
> DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device
Tree)")
> /* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
> + .smp = smp_ops(exynos_smp_ops),
> .init_irq = exynos4_init_irq,
> .map_io = exynos4_dt_map_io,
> .handle_irq = gic_handle_irq,
> --
> 1.7.12
Yes, right. Applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: EXYNOS: exynos4-dt: Set .smp field of machine descriptor
From: Kyungmin Park @ 2012-10-21 23:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2064474.beoN9hr7Vi@flatron>
+ Arnd, Olof,
Tomasz,
I think it's better to add arm-soc maintainers at CC when send the patches.
Samsung patches doesn't handled or merged with proper time.
Thank you,
Kyungmin Park
On 10/22/12, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On Friday 12 of October 2012 11:49:38 Tomasz Figa wrote:
>> This patch adds missing initializer of .smp field of machine descriptor
>> of Exynos 4 DT machine.
>>
>> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>> ---
>> arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
>> b/arch/arm/mach-exynos/mach-exynos4-dt.c index 7222e3c..d6bdcfb 100644
>> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
>> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
>> @@ -119,6 +119,7 @@ static char const *exynos4_dt_compat[] __initdata =
>> {
>>
>> DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device
>> Tree)") /* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
>> + .smp = smp_ops(exynos_smp_ops),
>> .init_irq = exynos4_init_irq,
>> .map_io = exynos4_dt_map_io,
>> .handle_irq = gic_handle_irq,
>
> Ping. I think this should be considered a fix.
>
> Best regards,
> Tomasz Figa
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v4 4/5] ARM: annotate VMALLOC_END definition with _AC
From: Josh Cartwright @ 2012-10-21 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351466765.git.josh.cartwright@ni.com>
This makes the definition of VMALLOC_END suitable for use within
assembly code. This is necessary to allow the use of VMALLOC_END in
defining where the early uart is mapped for use with DEBUG_LL.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/include/asm/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 08c1231..72904a2 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -40,7 +40,7 @@
*/
#define VMALLOC_OFFSET (8*1024*1024)
#define VMALLOC_START (((unsigned long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1))
-#define VMALLOC_END 0xff000000UL
+#define VMALLOC_END _AC(0xff000000,UL)
#define LIBRARY_TEXT_START 0x0c000000
--
1.8.0
^ permalink raw reply related
* [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: David Miller @ 2012-10-21 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-2-git-send-email-manabian@gmail.com>
You do know that this is going to generate warnings on 64-bit
platforms?
I was hoping you would have noticed and corrected this before
enabling the driver everywhere, I guess my expectations were
way too high :-/
^ permalink raw reply
* [PATCH v4 1/7] uio: uio_pruss: replace private SRAM API with genalloc
From: Hans J. Koch @ 2012-10-21 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018145338.GA25164@beef>
On Thu, Oct 18, 2012 at 10:53:38AM -0400, Matt Porter wrote:
> On Fri, Oct 05, 2012 at 01:04:40PM -0400, Matt Porter wrote:
> > Remove the use of the private DaVinci SRAM API in favor
> > of genalloc. The pool to be used is provided by platform
> > data.
> >
> > Signed-off-by: Matt Porter <mporter@ti.com>
>
> Hans,
>
> Any additional concerns on this patch?
Not from my side. I was waiting for your discussion to calm down.
> Sekhar is holding off on applying
> parts 4,5,7 for davinci until this is accepted.
You can add my
Signed-off-by: "Hans J. Koch" <hjk@hansjkoch.de>
Thanks,
Hans
>
> Thanks,
> Matt
>
> > ---
> > drivers/uio/Kconfig | 1 +
> > drivers/uio/uio_pruss.c | 24 +++++++++++++++++-------
> > include/linux/platform_data/uio_pruss.h | 3 ++-
> > 3 files changed, 20 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> > index 6f3ea9b..c48b938 100644
> > --- a/drivers/uio/Kconfig
> > +++ b/drivers/uio/Kconfig
> > @@ -97,6 +97,7 @@ config UIO_NETX
> > config UIO_PRUSS
> > tristate "Texas Instruments PRUSS driver"
> > depends on ARCH_DAVINCI_DA850
> > + select GENERIC_ALLOCATOR
> > help
> > PRUSS driver for OMAPL138/DA850/AM18XX devices
> > PRUSS driver requires user space components, examples and user space
> > diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
> > index 33a7a27..f8738de 100644
> > --- a/drivers/uio/uio_pruss.c
> > +++ b/drivers/uio/uio_pruss.c
> > @@ -25,7 +25,7 @@
> > #include <linux/clk.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/slab.h>
> > -#include <mach/sram.h>
> > +#include <linux/genalloc.h>
> >
> > #define DRV_NAME "pruss_uio"
> > #define DRV_VERSION "1.0"
> > @@ -65,10 +65,11 @@ struct uio_pruss_dev {
> > dma_addr_t sram_paddr;
> > dma_addr_t ddr_paddr;
> > void __iomem *prussio_vaddr;
> > - void *sram_vaddr;
> > + unsigned long sram_vaddr;
> > void *ddr_vaddr;
> > unsigned int hostirq_start;
> > unsigned int pintc_base;
> > + struct gen_pool *sram_pool;
> > };
> >
> > static irqreturn_t pruss_handler(int irq, struct uio_info *info)
> > @@ -106,7 +107,9 @@ static void pruss_cleanup(struct platform_device *dev,
> > gdev->ddr_paddr);
> > }
> > if (gdev->sram_vaddr)
> > - sram_free(gdev->sram_vaddr, sram_pool_sz);
> > + gen_pool_free(gdev->sram_pool,
> > + gdev->sram_vaddr,
> > + sram_pool_sz);
> > kfree(gdev->info);
> > clk_put(gdev->pruss_clk);
> > kfree(gdev);
> > @@ -152,10 +155,17 @@ static int __devinit pruss_probe(struct platform_device *dev)
> > goto out_free;
> > }
> >
> > - gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
> > - if (!gdev->sram_vaddr) {
> > - dev_err(&dev->dev, "Could not allocate SRAM pool\n");
> > - goto out_free;
> > + if (pdata->sram_pool) {
> > + gdev->sram_pool = pdata->sram_pool;
> > + gdev->sram_vaddr =
> > + gen_pool_alloc(gdev->sram_pool, sram_pool_sz);
> > + if (!gdev->sram_vaddr) {
> > + dev_err(&dev->dev, "Could not allocate SRAM pool\n");
> > + goto out_free;
> > + }
> > + gdev->sram_paddr =
> > + gen_pool_virt_to_phys(gdev->sram_pool,
> > + gdev->sram_vaddr);
> > }
> >
> > gdev->ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz,
> > diff --git a/include/linux/platform_data/uio_pruss.h b/include/linux/platform_data/uio_pruss.h
> > index f39140a..3d47d21 100644
> > --- a/include/linux/platform_data/uio_pruss.h
> > +++ b/include/linux/platform_data/uio_pruss.h
> > @@ -20,6 +20,7 @@
> >
> > /* To configure the PRUSS INTC base offset for UIO driver */
> > struct uio_pruss_pdata {
> > - u32 pintc_base;
> > + u32 pintc_base;
> > + struct gen_pool *sram_pool;
> > };
> > #endif /* _UIO_PRUSS_H_ */
> > --
> > 1.7.9.5
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH v2 3/3] net/at91_ether: add pdata flag for reverse Eth addr
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350856623-9819-1-git-send-email-manabian@gmail.com>
This will allow us to remove the last mach include from at91_ether
and also make it easier to share address setup with macb.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/board-csb337.c | 2 ++
drivers/net/ethernet/cadence/Kconfig | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 5 ++---
include/linux/platform_data/macb.h | 1 +
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
index 3e37437..aa9b320 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -53,6 +53,8 @@ static void __init csb337_init_early(void)
static struct macb_platform_data __initdata csb337_eth_data = {
.phy_irq_pin = AT91_PIN_PC2,
.is_rmii = 0,
+ /* The CSB337 bootloader stores the MAC the wrong-way around */
+ .rev_eth_addr = 1,
};
static struct at91_usbh_data __initdata csb337_usbh_data = {
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f6d0956..40172d1 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -21,7 +21,6 @@ if NET_CADENCE
config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
- depends on ARM && ARCH_AT91RM9200
select NET_CORE
select MACB
---help---
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 375d272..b92815a 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -32,8 +32,6 @@
#include <linux/phy.h>
#include <linux/io.h>
-#include <asm/mach-types.h>
-
#include "macb.h"
#define DRV_NAME "at91_ether"
@@ -61,9 +59,10 @@
static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
{
+ struct macb *lp = netdev_priv(dev);
char addr[6];
- if (machine_is_csb337()) {
+ if (lp->board_data.rev_eth_addr) {
addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
addr[4] = (lo & 0xff00) >> 8;
addr[3] = (lo & 0xff0000) >> 16;
diff --git a/include/linux/platform_data/macb.h b/include/linux/platform_data/macb.h
index b081c72..044a124 100644
--- a/include/linux/platform_data/macb.h
+++ b/include/linux/platform_data/macb.h
@@ -12,6 +12,7 @@ struct macb_platform_data {
u32 phy_mask;
int phy_irq_pin; /* PHY IRQ */
u8 is_rmii; /* using RMII interface? */
+ u8 rev_eth_addr; /* reverse Ethernet address byte order */
};
#endif /* __MACB_PDATA_H__ */
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 2/3] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350856623-9819-1-git-send-email-manabian@gmail.com>
Now that HAVE_NET_MACB is gone let's just select MACB to
satisfy the dependecies in at91_ether.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 5d1ea30..f6d0956 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -23,7 +23,7 @@ config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
depends on ARM && ARCH_AT91RM9200
select NET_CORE
- select PHYLIB
+ select MACB
---help---
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 798b1e0..9068b83 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,5 +2,5 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
+obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_MACB) += macb.o
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 1/3] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350856623-9819-1-git-send-email-manabian@gmail.com>
macb is a platform driver and there is nothing that prevents
this driver from being built on non-ARM/AVR32 platforms.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/Kconfig | 4 ----
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 5 -----
3 files changed, 10 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index d846b6e..72020fb 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -45,7 +45,6 @@ config SOC_AT91RM9200
config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
@@ -63,7 +62,6 @@ config SOC_AT91SAM9263
bool "AT91SAM9263"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
config SOC_AT91SAM9RL
@@ -76,7 +74,6 @@ config SOC_AT91SAM9G45
bool "AT91SAM9G45 or AT91SAM9M10 families"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
@@ -86,7 +83,6 @@ config SOC_AT91SAM9X5
bool "AT91SAM9x5 family"
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 06e73bf..09f9fa8 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -80,7 +80,6 @@ config PLATFORM_AT32AP
select ARCH_REQUIRE_GPIOLIB
select GENERIC_ALLOCATOR
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
#
# CPU types
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 57f78abe..5d1ea30 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -2,13 +2,9 @@
# Atmel device configuration
#
-config HAVE_NET_MACB
- bool
-
config NET_CADENCE
bool "Cadence devices"
default y
- depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
Make sure you know the name of your card. Read the Ethernet-HOWTO,
@@ -34,7 +30,6 @@ config ARM_AT91_ETHER
config MACB
tristate "Cadence MACB/GEM support"
- depends on HAVE_NET_MACB
select PHYLIB
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
--
1.7.12.4
^ permalink raw reply related
* [PATCH v2 0/3] make cadence ethernet drivers build on any architecture
From: Joachim Eastwood @ 2012-10-21 21:57 UTC (permalink / raw)
To: linux-arm-kernel
This series makes the at91_ether and macb driver build-able on any architecture.
Patch 1 removes the HAVE_NET_MACB from the cadence Kconfig and this allow macb to be built on any architecture. The macb driver requires no other modifications.
Patch 3 moves a bootloader quirk for CSB337 from at91_ether into platform data as a flag. This allow us to remove the last mach include and build this driver on any architecture. It also make it easier to share the address setup between at91_ether and macb.
The next series will make the at91_ether driver use address setting and statistics from macb. There is also a clean up of print outs plus some comment/style fixes.
Joachim Eastwood (3):
net/cadence: get rid of HAVE_NET_MACB
net/at91_ether: select MACB in Kconfig
net/at91_ether: add pdata flag for reverse Eth addr
arch/arm/mach-at91/Kconfig | 4 ----
arch/arm/mach-at91/board-csb337.c | 2 ++
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 8 +-------
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/at91_ether.c | 5 ++---
include/linux/platform_data/macb.h | 1 +
7 files changed, 7 insertions(+), 16 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [RFC 00/11] Convert Kirkwood to pinctrl
From: Sebastian Hesselbarth @ 2012-10-21 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021191634.GL21046@lunn.ch>
On 10/21/2012 09:16 PM, Andrew Lunn wrote:
>>> Do we want to enable the use of mvebu GPIO driver
>>> outside of mach-mvebu?
>>
>> Yes.
>>
>>> Do we want to enable the use of mvebu pinctrl driver
>>> outside of mach-mvebu?
>>
>> Yes.
>>
>> Generally speaking, I think it is a good idea for
>> mach-{mvebu,kirkwood,dove,mv78xx0,orion5x} to share as much
>> infrastructure code as possible.
>
> Definitely.
>
> However, i _think_ Sebastian had a different opinion to your two
> yes's. Maybe its just for Dove?
>
> I hope Sebastian will comment soon.
Andrew, Thomas,
we had long discussions about this some time ago. I agree to both
of Thomas' "yes" above as you convinced me that this is the best
way of merging plat-orion and mach-mvebu.
Do you want to add dove pinctrl to your patch set? If yes, when
do you want to post v1 of this RFC?
Sebastian
^ permalink raw reply
* [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Joachim Eastwood @ 2012-10-21 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021182551.GH12801@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:25 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> Move Ethernet address byte order fix for csb337 into it's board
>> setup.
>>
>> This will allow us to remove the last mach include from at91_ether
>> and also to share the address setup with the macb driver.
> no the at91rm9200 move to DT this is not compatible with it
>
> you need to pass ths in info via platform_data
>
> and do not touch driver code related stuff in boards
I know the board code is a bit nasty.
If it's unacceptable I'll cook up a flag and pass it by platform_data,
something like "reverse_eth_addr". Still it will only ever be used on
the csb337 board.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Joachim Eastwood @ 2012-10-21 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021183418.GC18964@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:34 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> Move Ethernet address byte order fix for csb337 into it's board
>> setup.
>>
>> This will allow us to remove the last mach include from at91_ether
>> and also to share the address setup with the macb driver.
> no the current drivers expect mach/board.h, mach/at91rm9200_emac.h, asm/gpio.h
>
> waht you did will not even compile on non at91 platform
>
> Did you even compile it on non at91?
This is the last mach include in the at91_ether driver in net-next.
And, yes, after this patch it complies fine for at least x86_64.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-21 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021183122.GB18964@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:31 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> Now that HAVE_NET_MACB is gone let's just select MACB to
>> satisfy the dependecies in at91_ether.
>>
>> PHYLIB will then by selected by MACB.
>>
>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>> ---
>> drivers/net/ethernet/cadence/Kconfig | 2 +-
>> drivers/net/ethernet/cadence/Makefile | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
>> index 5d1ea30..f6d0956 100644
>> --- a/drivers/net/ethernet/cadence/Kconfig
>> +++ b/drivers/net/ethernet/cadence/Kconfig
>> @@ -23,7 +23,7 @@ config ARM_AT91_ETHER
>> tristate "AT91RM9200 Ethernet support"
>> depends on ARM && ARCH_AT91RM9200
>> select NET_CORE
>> - select PHYLIB
>> + select MACB
> no the ether and macb are two diferrent drivers for 2 IPs from cadence
>
> the ehter does not need the macb
The at91_ether in net-next does.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021183005.GA18964@game.jcrosoft.org>
On Sun, Oct 21, 2012 at 8:30 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
>> macb is a platform driver and there is nothing that prevents
>> this driver from being built on non-ARM/AVR32 platforms.
> if you want to drop the HAVE_NET_MACB you need to drop it everywher in one
> patch
Breaking it up in several patches doesn't seem to cause any build
failures and I did this in case the patches were going into different
git trees.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 2/3] RTC: omap-rtc: enable pm_runtime
From: Daniel Mack @ 2012-10-21 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA00B18@DBDE01.ent.ti.com>
On 19.10.2012 12:58, Mohammed, Afzal wrote:
> Hi Daniel,
>
> On Thu, Oct 18, 2012 at 22:03:13, Hiremath, Vaibhav wrote:
>> On Thu, Oct 18, 2012 at 21:49:44, Daniel Mack wrote:
>>> On 18.10.2012 18:12, Vaibhav Hiremath wrote:
>
>>>> It would be really helpful if you could test these patches and ack them.
>
>>> Ok, will do tomorrow. What's missing there is support for writing to the
>>> OMAP_RTC_OSC_REG (path 3/3 in my series). Would like me to rebase the
>>> functionality? I need thatkind of setup for my board ...
>
>> This is bit tricky and required more discussion before merging it,
>> let me reopen the old discussion which I had started some time back -
>>
>>
>> RTC OSC clock is required to configure clocksource systemtimer for the
>> kernel, and it is important when you get into PM related features.
>>
>> Please refer the below commit for more reference,
>>
>> http://marc.info/?l=u-boot&m=135057734713796&w=2
>
> Newer version (v4) of omap rtc patches for am335x has been
> posted, "rtc: omap dt support (for am33xx)".
> In case you can test, please do it over the new series.
>
> You would need also need DT patch that adds DT node to
> test (it has been separated from the series as it is
> felt that it should not be part of same series),
> "arm/dts: am33xx rtc node"
Agreed. I tested your patches and they do basically the same thing than
mine. You can take my
Tested-by: Daniel Mack <zonque@gmail.com>
on all patches in this series except for 2/5 which I didn't test as I
don't have any Davinci platform.
> If you are using mainline uboot, you would need the fix as
> mentioned by Vaibhav H (as in the link he provided above),
> expecting it to reach uboot mainline soon.
>
> If the above is being attempted to achieve in Kernel it
> would cause 2-3 seconds delay in boot time (else it had
> to be made a module), please refer link provided by
> Vaibhav H for more details.
>
> else you can do in current mainline uboot,
>
> mw.l 0x44e3e06c 0x83e70b13
> mw.l 0x44e3e070 0x95a4f1e0
> mw.b 0x44e3e054 0x48
>
> and then boot kernel.
I'm surprised that survives the kernel boot, but I'll give it a try. In
case you want to add that logic to the kernel as well, please copy me in
the discussion :)
Thanks,
Daniel
^ permalink raw reply
* [PATCH v4 3/5] rtc: omap: dt support
From: Daniel Mack @ 2012-10-21 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <061c670b0a05570d7b83d8a8f105ee5b35583f7f.1350633036.git.afzal@ti.com>
On 19.10.2012 11:59, Afzal Mohammed wrote:
> enhance rtc-omap driver with DT capability
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> Acked-by: Sekhar Nori <nsekhar@ti.com>
> ---
>
> v4:
> Proper devicetree documentation
>
> v2:
> Use compatible as ti,da830-rtc instead of ti,am1808-rtc
>
> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 17 +++++++++++++++++
> drivers/rtc/rtc-omap.c | 18 ++++++++++++++++++
> 2 files changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-omap.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> new file mode 100644
> index 0000000..b47aa41
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> @@ -0,0 +1,17 @@
> +TI Real Time Clock
> +
> +Required properties:
> +- compatible: "ti,da830-rtc"
> +- reg: Address range of rtc register set
> +- interrupts: rtc timer, alarm interrupts in order
> +- interrupt-parent: phandle for the interrupt controller
> +
> +Example:
> +
> +rtc at 1c23000 {
> + compatible = "ti,da830-rtc";
> + reg = <0x23000 0x1000>;
> + interrupts = <19
> + 19>;
> + interrupt-parent = <&intc>;
> +};
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index d948426..dff9ff4 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -20,6 +20,8 @@
> #include <linux/rtc.h>
> #include <linux/bcd.h>
> #include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>
> #include <asm/io.h>
>
> @@ -298,6 +300,8 @@ static struct rtc_class_ops omap_rtc_ops = {
> static int omap_rtc_alarm;
> static int omap_rtc_timer;
>
> +#define OMAP_RTC_DATA_DA830_IDX 1
> +
> static struct platform_device_id omap_rtc_devtype[] = {
> {
> .name = DRIVER_NAME,
> @@ -309,12 +313,25 @@ static struct platform_device_id omap_rtc_devtype[] = {
> };
> MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
>
> +static const struct of_device_id omap_rtc_of_match[] = {
> + { .compatible = "ti,da830-rtc",
> + .data = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
Wouldn't it make sense to list all the compatible models here? The
advantage of a compatible list is that we can name the models
explicitly, or maybe at least "davinci-rtc". Is there any reason for
this particular name?
Daniel
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
> +
> static int __init omap_rtc_probe(struct platform_device *pdev)
> {
> struct resource *res, *mem;
> struct rtc_device *rtc;
> u8 reg, new_ctrl;
> const struct platform_device_id *id_entry;
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(omap_rtc_of_match, &pdev->dev);
> + if (of_id)
> + pdev->id_entry = of_id->data;
>
> omap_rtc_timer = platform_get_irq(pdev, 0);
> if (omap_rtc_timer <= 0) {
> @@ -510,6 +527,7 @@ static struct platform_driver omap_rtc_driver = {
> .driver = {
> .name = DRIVER_NAME,
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(omap_rtc_of_match),
> },
> .id_table = omap_rtc_devtype,
> };
>
^ permalink raw reply
* [PATCH 3/9] uprobes: allow ignoring of probe hits
From: Oleg Nesterov @ 2012-10-21 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021181504.GA4840@ubuntu>
On 10/21, Rabin Vincent wrote:
>
> On Wed, Oct 17, 2012 at 07:35:10PM +0200, Oleg Nesterov wrote:
> >
> > And, to clarify, I am not arguing. Just curious.
> >
> > So, is this like cmov on x86? And this patch allows to not report if
> > the condition is not true? Or there are other issues on arm?
>
> Yes, I guess this is like CMOV on x86. In the ARM instruction set most
> instructions can be conditionally executed.
>
> In order to set the probe on a conditional instruction, we use an
> undefined instruction with the same condition as the instruction we
> replace. However, it is implementation defined whether an undefined
> instruction with a failing condition code will trigger an undefined
> instruction exception or just be executed as a NOP. So for those
> processor implementations where we do get the undefined instruction
> exception even for a failing condition code, we have to ignore it in
> order to provide consistent behaviour.
OK, I see, thanks for your explanation.
Oleg.
^ permalink raw reply
* [RFC 00/11] Convert Kirkwood to pinctrl
From: Andrew Lunn @ 2012-10-21 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021210902.4dbd3e09@skate>
On Sun, Oct 21, 2012 at 09:09:02PM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Sat, 20 Oct 2012 17:07:32 +0200, Andrew Lunn wrote:
>
> > This patchset converts all kirkwood DT boards to pinctrl.
> > It is an RFC for a number of reasons:
>
> Thanks for doing this work!
>
> > Do we want to enable the use of mvebu GPIO driver
> > outside of mach-mvebu?
>
> Yes.
>
> > Do we want to enable the use of mvebu pinctrl driver
> > outside of mach-mvebu?
>
> Yes.
>
> Generally speaking, I think it is a good idea for
> mach-{mvebu,kirkwood,dove,mv78xx0,orion5x} to share as much
> infrastructure code as possible.
Definitely.
However, i _think_ Sebastian had a different opinion to your two
yes's. Maybe its just for Dove?
I hope Sebastian will comment soon.
Andrew
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: first set of PRM/CM cleanups for 3.8
From: Paul Walmsley @ 2012-10-21 19:13 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.8
for you to fetch changes up to 2bb2a5d30abb0dc99d074877bfad2056142c730b:
ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver (2012-10-21 01:01:13 -0600)
- ----------------------------------------------------------------
The first set of OMAP PRM/CM-related cleanup patches for 3.8.
Prepares for the future move of the PRM/CM code to drivers/. Also
includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
series that don't need external acks.
Basic test logs for this branch on top of v3.7-rc2 are here:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/
But due to the number of unrelated regressions present in v3.7-rc[12],
it's not particularly usable as a testing base. With reverts, fixes,
and workarounds applied as documented in:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt
the following test logs were obtained:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/
which indicate that the series tests cleanly.
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)):
text data bss total kernel
+112 0 0 +112 am33xx_only
-1740 -104 0 -1844 n800_multi_omap2xxx
-1648 -80 0 -1728 n800_only_a
+80 0 0 +80 omap1_defconfig
+32 0 0 +32 omap1_defconfig_1510innovator_only
+80 0 0 +80 omap1_defconfig_5912osk_only
+912 +64 0 +976 omap2plus_defconfig
-1836 -112 0 -1948 omap2plus_defconfig_2430sdp_only
+912 +136 0 +1048 omap2plus_defconfig_cpupm
+896 +64 0 +960 omap2plus_defconfig_no_pm
-6004 -80 +64 -6020 omap2plus_defconfig_omap2_4_only
-428 -56 0 -484 omap2plus_defconfig_omap3_4_only
-888 -136 0 -1024 rmk_omap3430_ldp_oldconfig
+200 +56 0 +256 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556))
avail rsrvd high freed board kconfig
8k -8k . . 2420n800 omap2plus_defconfig
-8k 8k . . am335xbone omap2plus_defconfig
Paul Walmsley (9):
ARM: OMAP2+: PRM: remove PRM weak functions
ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files
ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM
ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files
ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions into PRM/CM
ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers
ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers
ARM: OMAP1: create read_reset_sources() function (for initial use by watchdog)
ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver
arch/arm/mach-omap1/common.h | 2 +
arch/arm/mach-omap1/reset.c | 38 +++
arch/arm/mach-omap2/Makefile | 110 ++++---
arch/arm/mach-omap2/clkt2xxx_apll.c | 2 +-
arch/arm/mach-omap2/clkt2xxx_dpll.c | 2 +-
arch/arm/mach-omap2/clock.c | 3 +-
arch/arm/mach-omap2/clock2420_data.c | 2 +-
arch/arm/mach-omap2/clock2430.c | 2 +-
arch/arm/mach-omap2/clock2430_data.c | 2 +-
arch/arm/mach-omap2/clock34xx.c | 2 +-
arch/arm/mach-omap2/clock3517.c | 2 +-
arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 339 -------------------
arch/arm/mach-omap2/clockdomain33xx.c | 74 -----
arch/arm/mach-omap2/clockdomain44xx.c | 151 ---------
arch/arm/mach-omap2/cm.h | 12 +
arch/arm/mach-omap2/cm2xxx.c | 255 ++++++++++++++
arch/arm/mach-omap2/cm2xxx.h | 66 ++++
arch/arm/mach-omap2/cm2xxx_3xxx.h | 119 +++----
arch/arm/mach-omap2/cm33xx.c | 56 ++++
arch/arm/mach-omap2/{cm2xxx_3xxx.c => cm3xxx.c} | 307 +++++++++--------
arch/arm/mach-omap2/cm3xxx.h | 86 +++++
arch/arm/mach-omap2/cm_common.c | 71 ++++
arch/arm/mach-omap2/cminst44xx.c | 142 +++++++-
arch/arm/mach-omap2/control.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.c | 51 ++-
arch/arm/mach-omap2/pm24xx.c | 4 +-
arch/arm/mach-omap2/pm34xx.c | 5 +-
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 242 --------------
arch/arm/mach-omap2/powerdomain33xx.c | 229 -------------
arch/arm/mach-omap2/powerdomain44xx.c | 285 ----------------
arch/arm/mach-omap2/prm-regbits-24xx.h | 6 +-
arch/arm/mach-omap2/prm-regbits-34xx.h | 12 +-
arch/arm/mach-omap2/prm.h | 53 +++
arch/arm/mach-omap2/prm2xxx.c | 126 +++++++
arch/arm/mach-omap2/prm2xxx.h | 132 ++++++++
arch/arm/mach-omap2/prm2xxx_3xxx.c | 332 +++++++------------
arch/arm/mach-omap2/prm2xxx_3xxx.h | 277 ++++------------
arch/arm/mach-omap2/prm33xx.c | 202 ++++++++++++
arch/arm/mach-omap2/prm3xxx.c | 403 +++++++++++++++++++++++
arch/arm/mach-omap2/prm3xxx.h | 160 +++++++++
arch/arm/mach-omap2/prm44xx.c | 355 +++++++++++++++++++-
arch/arm/mach-omap2/prm44xx.h | 2 +
arch/arm/mach-omap2/prm_common.c | 104 +++---
arch/arm/mach-omap2/sdrc2xxx.c | 2 +-
arch/arm/mach-omap2/sleep34xx.S | 4 +-
arch/arm/mach-omap2/sram242x.S | 4 +-
arch/arm/mach-omap2/sram243x.S | 4 +-
arch/arm/mach-omap2/sram34xx.S | 2 +-
49 files changed, 2750 insertions(+), 2097 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
delete mode 100644 arch/arm/mach-omap2/clockdomain33xx.c
delete mode 100644 arch/arm/mach-omap2/clockdomain44xx.c
create mode 100644 arch/arm/mach-omap2/cm2xxx.c
create mode 100644 arch/arm/mach-omap2/cm2xxx.h
rename arch/arm/mach-omap2/{cm2xxx_3xxx.c => cm3xxx.c} (72%)
create mode 100644 arch/arm/mach-omap2/cm3xxx.h
create mode 100644 arch/arm/mach-omap2/cm_common.c
delete mode 100644 arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
delete mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
delete mode 100644 arch/arm/mach-omap2/powerdomain44xx.c
create mode 100644 arch/arm/mach-omap2/prm2xxx.c
create mode 100644 arch/arm/mach-omap2/prm2xxx.h
create mode 100644 arch/arm/mach-omap2/prm3xxx.c
create mode 100644 arch/arm/mach-omap2/prm3xxx.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQhEkXAAoJEMePsQ0LvSpL5MQQAIep02VYn26LnKRaU34Oy6wW
zMpr8G1kPr+u6suoIylHceSQ8EKN72Icj1BpOCBENOtMkzy8YRsUBLy4+Olz6QEd
jttGKqfpK9OEBD1vTrU4OFAN5u481SlyM4EH4GnybfEf6PZBNiTMvW5cYYORxavF
GP91XJ7h0whUWLd241Elf7lkylOThrE1i7TRbQ/aSsR2TjQu0+j0Z85+hClb7tfj
Jgzzk8c6gYZ3xxye0Wa6+nZmnDrpzLtgqgQk/gwDUB1wXr4QRvnhwgVYMfcdrdDC
hySU/xlMEJPHKLCeiuh8C55XIOq6D+osIq75V9GiAWahIxjIuOgsFyfQnH7dbUp0
kFiC8gchOYTyXJzekqAnT37bD/a5UdVM7b9LoApayUKaOj+J931ArmgF65Phie0t
A8Drm27i973i65I5NYMaiHzEpV/flS6uGbvQGhzT1Lj962rst38wr+Tu+6byuqlJ
oo1at5ArBD32sXjaS0XDWJvbuk8htwGGF64VaL9gJKV/eovqPJjZ4/Qcaa+BNJHj
JlRigV2WWwXH8JZ4mDy6uMj6VWCDp24LHlQoyoErRVYNnLqZsQNYJVaN3LmEsYeR
Ccf6ortZ8Q5Hhbpxm6XJKAYHn8IWLvzZ9fIBB7wLAez3beNzYGpAJ8g0xq1updIU
mU00eXz6MpjI05wLMzkv
=Rcv0
-----END PGP SIGNATURE-----
^ permalink raw reply
* [RFC 00/11] Convert Kirkwood to pinctrl
From: Thomas Petazzoni @ 2012-10-21 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350745663-5277-1-git-send-email-andrew@lunn.ch>
Dear Andrew Lunn,
On Sat, 20 Oct 2012 17:07:32 +0200, Andrew Lunn wrote:
> This patchset converts all kirkwood DT boards to pinctrl.
> It is an RFC for a number of reasons:
Thanks for doing this work!
> Do we want to enable the use of mvebu GPIO driver
> outside of mach-mvebu?
Yes.
> Do we want to enable the use of mvebu pinctrl driver
> outside of mach-mvebu?
Yes.
Generally speaking, I think it is a good idea for
mach-{mvebu,kirkwood,dove,mv78xx0,orion5x} to share as much
infrastructure code as possible. A first step is obviously to migrate
everybody to use the drivers/gpio mvebu driver and the drivers/pinctrl
mvebu driver, and get rid of plat-orion/{gpio,mpp}.c once this work is
done.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 9/9] ARM: add uprobes support
From: Rabin Vincent @ 2012-10-21 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015174450.GB18614@linaro.org>
On Mon, Oct 15, 2012 at 06:44:50PM +0100, Dave Martin wrote:
> On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote:
> > Why? It currently works for ARM userspace even if the kernel is
> > Thumb-2.
>
> My bad, I misread what was happening in the Makefile changes.
>
> My concern is about whether we can build the ARM and Thumb-2 kprobes
> code into the same kernel. If so, no problem, but I believe this is
> not a tested configuration for kprobes itself.
>
> If you've not already done so, it should be possible to test this
> by adding CONFIG_THUMB2_KERNEL=y to your config, providing your
> hardware is Thumb-2 capable.
I've tested this before. With a Thumb-2 kernel, both the kprobes test
(Thumb) and the uprobes test (ARM) run fine.
> General question which I'm not sure I understand yet: is is possible
> to combine uprobes/kprobes decode more completely? It's not obvious
> to me whether the uprobes-specific decoding only relates to features
> which architecturally execute differently in user mode versus
> privileged mode. Some explanation somewhere could be helpful.
What we change is not the decoding itself but the handling of the
instructions:
(1) Load and stores are executed from the xol area by user space so
the instructions need to be rewritten when they touch the PC. Kprobes
code rewrites the instructions directly and executes them or in some
cases simulates them.
(2) All other non-simulated instructions are also executed from the
XOL area in userspace. Because of this, the ALU instructions which
use the PC also need to be rewritten to not use the PC. Perhaps we
can actually get rid of this and just execute these instruction from
kernel space like it is done for uprobes.
So the uprobes code is uses the decoding tables just to know if the
instruction is using the PC or not, but if we make the ALU
instructions execute from kernel space we could actually use the
emulate_*() functions like kprobes does.
^ permalink raw reply
* [PATCH 9/9] ARM: add uprobes support
From: Rabin Vincent @ 2012-10-21 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350485448.3206.146.camel@linaro1.home>
On Wed, Oct 17, 2012 at 03:50:48PM +0100, Jon Medhurst (Tixy) wrote:
> I just been looking at the decoding changes in patch 8 and had similar
> thoughts. The patch as it stands looks rather bolted on the side and
> makes the resulting code rather messy.
I agree.
> a) uprobes is similar enough to kprobes that the existing code can be
> morphed into something that cleanly supports both, or
>
> b) the similarities aren't close enough and that we should factor out
> the similarities into a more generalised decoding base, which the
> {u,k}probe code can then build on.
>
> c) some mix of a) and b)
>
> I can't help but think of the various calls over the past year or so for
> a general ARM/Thumb instruction decoding framework (the last one only a
> few weeks ago on the linux-arm-kernel list). Perhaps b) would be a small
> step towards that.
>
> I hope to find some time to understand the uprobe patches in more
> detail, so I can try and come up with some sensible suggestions on a
> cleaner solution; because I feel that as they stand they aren't really
> suitable for inclusion in the kernel.
I contemplated sending the decoding patch with [RFC] but finally went
with [PATCH] since they mostly mean the same thing :-).
Suggestions welcome. For one thing, the creation of a fake struct
kprobe from within the uprobes and the dependency on kprobes because of
that is not very nice, we probably need a "struct probe" of some sort
perhaps.
> Rabin, what tree/commit are your patches based on? (They don't seem to
> apply cleanly to 3.6 or 3.7-rc1.) I want to apply them locally so I can
> use my favourite visualisation tool and to play with them.
The patches are based on next-20121012. The uprobes core is seeing
quite a few changes in linux-next so the series will probably not apply
on later linux-next trees.
^ permalink raw reply
* [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-4-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Move Ethernet address byte order fix for csb337 into it's board
> setup.
>
> This will allow us to remove the last mach include from at91_ether
> and also to share the address setup with the macb driver.
no the current drivers expect mach/board.h, mach/at91rm9200_emac.h, asm/gpio.h
waht you did will not even compile on non at91 platform
Did you even compile it on non at91?
Best Regards,
J.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
> drivers/net/ethernet/cadence/Kconfig | 1 -
> drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
> 3 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
> index 3e37437..5522132 100644
> --- a/arch/arm/mach-at91/board-csb337.c
> +++ b/arch/arm/mach-at91/board-csb337.c
> @@ -217,6 +217,40 @@ static struct gpio_led csb_leds[] = {
> }
> };
>
> +/*
> + * MicroMonitor (uMon) on the CSB337 store the ethernet address in the
> + * wrong byte order (and continues to do so, for bug-compatibility).
> + */
> +#define MACB_SA1B 0x0098
> +#define MACB_SA1T 0x009c
> +static void __init csb337_fix_eth_addr(void)
> +{
> + void __iomem *emac;
> + u32 lo, hi, tmp;
> + int i;
> +
> + emac = ioremap(AT91RM9200_BASE_EMAC, SZ_16K);
> + if (!emac) {
> + printk(KERN_ERR "csb337: unable to fixup Ethernet address\n");
> + return;
> + }
> +
> + /* Fix byte order on all 4 address registers */
> + for (i = 0; i < 4; i++) {
> + lo = readl(emac + MACB_SA1B + i * 8);
> + hi = readl(emac + MACB_SA1T + i * 8);
> +
> + tmp = (lo & 0xff) << 8 | (lo & 0xff00) >> 8;
> + writel(tmp, emac + MACB_SA1T + i * 8);
> +
> + tmp = (hi & 0xff) << 8 | (hi & 0xff00) >> 8
> + | (lo & 0xff0000) << 8
> + | (lo & 0xff000000) >> 8;
> + writel(tmp, emac + MACB_SA1B + i * 8);
> + }
> +
> + iounmap(emac);
> +}
>
> static void __init csb337_board_init(void)
> {
> @@ -225,6 +259,7 @@ static void __init csb337_board_init(void)
> at91_register_uart(0, 0, 0);
> at91_add_device_serial();
> /* Ethernet */
> + csb337_fix_eth_addr();
> at91_add_device_eth(&csb337_eth_data);
> /* USB Host */
> at91_add_device_usbh(&csb337_usbh_data);
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index f6d0956..40172d1 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -21,7 +21,6 @@ if NET_CADENCE
>
> config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> - depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> select MACB
> ---help---
> diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> index 375d272..5ed1a63 100644
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@ -32,8 +32,6 @@
> #include <linux/phy.h>
> #include <linux/io.h>
>
> -#include <asm/mach-types.h>
> -
> #include "macb.h"
>
> #define DRV_NAME "at91_ether"
> @@ -55,30 +53,18 @@
> * U-Boot on the AT91RM9200-DK do not do this.
> *
> * - Likewise it must store the addresses in the correct byte order.
> - * MicroMonitor (uMon) on the CSB337 does this incorrectly (and
> - * continues to do so, for bug-compatibility).
> */
>
> static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
> {
> char addr[6];
>
> - if (machine_is_csb337()) {
> - addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
> - addr[4] = (lo & 0xff00) >> 8;
> - addr[3] = (lo & 0xff0000) >> 16;
> - addr[2] = (lo & 0xff000000) >> 24;
> - addr[1] = (hi & 0xff);
> - addr[0] = (hi & 0xff00) >> 8;
> - }
> - else {
> - addr[0] = (lo & 0xff);
> - addr[1] = (lo & 0xff00) >> 8;
> - addr[2] = (lo & 0xff0000) >> 16;
> - addr[3] = (lo & 0xff000000) >> 24;
> - addr[4] = (hi & 0xff);
> - addr[5] = (hi & 0xff00) >> 8;
> - }
> + addr[0] = (lo & 0xff);
> + addr[1] = (lo & 0xff00) >> 8;
> + addr[2] = (lo & 0xff0000) >> 16;
> + addr[3] = (lo & 0xff000000) >> 24;
> + addr[4] = (hi & 0xff);
> + addr[5] = (hi & 0xff00) >> 8;
>
> if (is_valid_ether_addr(addr)) {
> memcpy(dev->dev_addr, &addr, 6);
> --
> 1.7.12.4
>
^ permalink raw reply
* [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-3-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Now that HAVE_NET_MACB is gone let's just select MACB to
> satisfy the dependecies in at91_ether.
>
> PHYLIB will then by selected by MACB.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 2 +-
> drivers/net/ethernet/cadence/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index 5d1ea30..f6d0956 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -23,7 +23,7 @@ config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> - select PHYLIB
> + select MACB
no the ether and macb are two diferrent drivers for 2 IPs from cadence
the ehter does not need the macb
Best Regards,
J.
> ---help---
> If you wish to compile a kernel for the AT91RM9200 and enable
> ethernet support, then you should always answer Y to this.
> diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
> index 798b1e0..9068b83 100644
> --- a/drivers/net/ethernet/cadence/Makefile
> +++ b/drivers/net/ethernet/cadence/Makefile
> @@ -2,5 +2,5 @@
> # Makefile for the Atmel network device drivers.
> #
>
> -obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
> +obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> obj-$(CONFIG_MACB) += macb.o
> --
> 1.7.12.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox