* [PATCH 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers
From: Kukjin Kim @ 2011-09-20 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920234502.GU7781@ponder.secretlab.ca>
Grant Likely wrote:
>
> On Tue, Aug 30, 2011 at 09:27:26PM +0900, Kukjin Kim wrote:
> > Since gpio-samsung.c can replace old Samsung GPIO drivers,
> > this patch removes them.
> >
> > Cc: Ben Dooks <ben-linux@fluff.org>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>
> Removing this code before adding the new code means it is not
> bisectable. I'll squash the two patches together when I pick them
> up..
>
OK, no problem and would be better to me if you could create some topic
branch for this series. I'd like to merge it to avoid conflicts with Samsung
stuff.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> > ---
> > arch/arm/plat-samsung/Makefile | 2 -
> > arch/arm/plat-samsung/gpio-config.c | 431
-----------------------------
> > arch/arm/plat-samsung/gpio.c | 167 ------------
> > drivers/gpio/Kconfig | 28 --
> > drivers/gpio/Makefile | 9 -
> > drivers/gpio/gpio-exynos4.c | 385 --------------------------
> > drivers/gpio/gpio-plat-samsung.c | 205 --------------
> > drivers/gpio/gpio-s3c24xx.c | 283 -------------------
> > drivers/gpio/gpio-s3c64xx.c | 289 --------------------
> > drivers/gpio/gpio-s5p64x0.c | 510
-----------------------------------
> > drivers/gpio/gpio-s5pc100.c | 354 ------------------------
> > drivers/gpio/gpio-s5pv210.c | 287 --------------------
> > 12 files changed, 0 insertions(+), 2950 deletions(-)
> > delete mode 100644 arch/arm/plat-samsung/gpio-config.c
> > delete mode 100644 arch/arm/plat-samsung/gpio.c
> > delete mode 100644 drivers/gpio/gpio-exynos4.c
> > delete mode 100644 drivers/gpio/gpio-plat-samsung.c
> > delete mode 100644 drivers/gpio/gpio-s3c24xx.c
> > delete mode 100644 drivers/gpio/gpio-s3c64xx.c
> > delete mode 100644 drivers/gpio/gpio-s5p64x0.c
> > delete mode 100644 drivers/gpio/gpio-s5pc100.c
> > delete mode 100644 drivers/gpio/gpio-s5pv210.c
> >
^ permalink raw reply
* [PATCH 5/5] omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers
From: Tony Lindgren @ 2011-09-20 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109210113.49151.laurent.pinchart@ideasonboard.com>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [110920 15:40]:
> > CONFIG_REGULATOR_TPS65023=y
> > CONFIG_REGULATOR_TPS6507X=y
> > +CONFIG_MEDIA_SUPPORT=y
> > +CONFIG_MEDIA_CONTROLLER=y
> > +CONFIG_VIDEO_DEV=y
> > +CONFIG_VIDEO_V4L2_COMMON=y
> > +CONFIG_VIDEO_ALLOW_V4L1=y
> > +CONFIG_VIDEO_V4L1_COMPAT=y
> > +CONFIG_VIDEO_V4L2_SUBDEV_API=y
> > +CONFIG_VIDEO_MEDIA=y
> > +CONFIG_VIDEO_MT9T111=y
> > +CONFIG_VIDEO_OMAP3=y
>
> Shouldn't they be compiled as modules instead ?
Yes, let's not apply this.
Tony
^ permalink raw reply
* [PATCH 1/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/
From: Grant Likely @ 2011-09-20 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001f01cc76bd$1ebad900$5c308b00$%kim@samsung.com>
On Mon, Sep 19, 2011 at 08:13:12PM +0900, Kukjin Kim wrote:
> Kukjin Kim wrote:
> >
>
> (snip)...
>
> Hi Grant,
>
> I didn't get any comments on this series, gpio-samsung patches for
> consolidation of Samsung gpiolib. Please let me know whether this is ok to
> you or not. And I think, if you're ok, this should be sent to upstream via
> both gpio tree and arm(samsung) tree to avoid conflicts...
>
> As a note, following is its status...
>
> Kukjin Kim (9):
> ARM: SAMSUNG: Move map header file into plat-samsung
> gpio/s3c24xx: move gpio driver into drivers/gpio/
> gpio/s3c64xx: move gpio driver into drivers/gpio/
> gpio/s5p64x0: move gpio driver into drivers/gpio/
> gpio/samsung: Remove useless old Samsung related GPIO drivers
> gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
> ARM: SAMSUNG: Update the name of regarding Samsung GPIO
> ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIGs
> Merge branch 'next/topic-plat-samsung-1' into next/topic-gpio-samsung
Actually, even though I said I would pick it up, you've already got it
in a tree, so you can go ahead and merge it with my ack. I don't see
any major risk of conflicts for the next merge window, so there is no
need to merge it in the gpio tree also.
g.
>
> arch/arm/Kconfig | 3 -
> arch/arm/mach-exynos4/include/mach/pm-core.h | 2 +-
> arch/arm/mach-s3c2410/Kconfig | 7 -
> arch/arm/mach-s3c2410/Makefile | 1 -
> arch/arm/mach-s3c2410/include/mach/gpio-fns.h | 99 +-
> arch/arm/mach-s3c2410/include/mach/gpio-track.h | 6 +-
> arch/arm/mach-s3c2410/include/mach/map.h | 52 +-
> arch/arm/mach-s3c2410/include/mach/pm-core.h | 2 +-
> arch/arm/mach-s3c2410/s3c2410.c | 4 +-
> arch/arm/mach-s3c2412/Kconfig | 1 -
> arch/arm/mach-s3c2412/Makefile | 1 -
> arch/arm/mach-s3c2412/gpio.c | 2 +-
> arch/arm/mach-s3c2416/Kconfig | 1 -
> arch/arm/mach-s3c2416/s3c2416.c | 4 +-
> arch/arm/mach-s3c2440/Kconfig | 4 -
> arch/arm/mach-s3c2440/s3c2440.c | 4 +-
> arch/arm/mach-s3c2440/s3c2442.c | 4 +-
> arch/arm/mach-s3c2443/Kconfig | 1 -
> arch/arm/mach-s3c2443/s3c2443.c | 4 +-
> arch/arm/mach-s3c64xx/Makefile | 1 -
> arch/arm/mach-s3c64xx/gpiolib.c | 290 ---
> arch/arm/mach-s3c64xx/include/mach/map.h | 9 +-
> arch/arm/mach-s3c64xx/include/mach/pm-core.h | 2 +-
> arch/arm/mach-s5p64x0/Makefile | 2 +-
> arch/arm/mach-s5p64x0/gpiolib.c | 511 ----
> arch/arm/mach-s5pv210/include/mach/pm-core.h | 2 +-
> arch/arm/plat-s3c24xx/Kconfig | 1 -
> arch/arm/plat-s3c24xx/Makefile | 2 -
> arch/arm/plat-s3c24xx/gpio.c | 96 -
> arch/arm/plat-s3c24xx/gpiolib.c | 229 --
> arch/arm/plat-s3c24xx/include/plat/map.h | 100 -
> arch/arm/plat-s5p/Kconfig | 3 -
> arch/arm/plat-s5p/irq-gpioint.c | 10 +-
> arch/arm/plat-samsung/Kconfig | 27 -
> arch/arm/plat-samsung/Makefile | 2 -
> arch/arm/plat-samsung/gpio-config.c | 431 ----
> arch/arm/plat-samsung/gpio.c | 167 --
> .../plat-samsung/include/plat/gpio-cfg-helpers.h | 172 +-
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 34 +-
> arch/arm/plat-samsung/include/plat/gpio-core.h | 97 +-
> arch/arm/plat-samsung/include/plat/gpio-fns.h | 98 +
> arch/arm/plat-samsung/include/plat/map-s3c.h | 84 +
> .../include/plat/map-s5p.h | 6 +-
> arch/arm/plat-samsung/include/plat/pm.h | 10 +-
> arch/arm/plat-samsung/pm-gpio.c | 72 +-
> arch/arm/plat-samsung/pm.c | 6 +-
> drivers/gpio/Kconfig | 16 -
> drivers/gpio/Makefile | 7 +-
> drivers/gpio/gpio-exynos4.c | 385 ---
> drivers/gpio/gpio-plat-samsung.c | 205 --
> drivers/gpio/gpio-s5pc100.c | 354 ---
> drivers/gpio/gpio-s5pv210.c | 287 ---
> drivers/gpio/gpio-samsung.c | 2686
> ++++++++++++++++++++
> 53 files changed, 3072 insertions(+), 3534 deletions(-)
> delete mode 100644 arch/arm/mach-s3c64xx/gpiolib.c
> delete mode 100644 arch/arm/mach-s5p64x0/gpiolib.c
> delete mode 100644 arch/arm/plat-s3c24xx/gpio.c
> delete mode 100644 arch/arm/plat-s3c24xx/gpiolib.c
> delete mode 100644 arch/arm/plat-s3c24xx/include/plat/map.h
> delete mode 100644 arch/arm/plat-samsung/gpio-config.c
> delete mode 100644 arch/arm/plat-samsung/gpio.c
> create mode 100644 arch/arm/plat-samsung/include/plat/gpio-fns.h
> create mode 100644 arch/arm/plat-samsung/include/plat/map-s3c.h
> rename arch/arm/{plat-s5p => plat-samsung}/include/plat/map-s5p.h (94%)
> delete mode 100644 drivers/gpio/gpio-exynos4.c
> delete mode 100644 drivers/gpio/gpio-plat-samsung.c
> delete mode 100644 drivers/gpio/gpio-s5pc100.c
> delete mode 100644 drivers/gpio/gpio-s5pv210.c
> create mode 100644 drivers/gpio/gpio-samsung.c
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
^ permalink raw reply
* [PATCH 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
From: Grant Likely @ 2011-09-20 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314707249-12241-6-git-send-email-kgene.kim@samsung.com>
On Tue, Aug 30, 2011 at 09:27:27PM +0900, Kukjin Kim wrote:
> This patch adds support for Samsung GPIOs with one gpio driver.
> Actually there are drivers/gpio-s3c24xx.c, gpio-s3c64xx.c,
> gpio-s5p64x0.c, gpio-s5pc100.c, gpio-s5pv210.c, gpio-exynos4.c,
> gpio-plat-samsung.c, plat-samsung/gpio-config.c and gpio.c to
> support each Samsung SoCs before.
> Basically, the gpio-samsung.c has been made by their merging
> and removing duplicated definitions.
>
> Note: gpio-samsung.c includes some SoC dependent codes and it
> will be replaced next time.
>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-samsung.c | 2686 +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 2687 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpio/gpio-samsung.c
It's a big driver file, but I'll go ahead and pick this up without too
much review because at least it is all in the same place now. I'll
expect further cleanup in future patches.
g.
^ permalink raw reply
* [PATCH 00/10] hwspinlock-next
From: Greg KH @ 2011-09-20 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920231340.GT18894@atomide.com>
On Tue, Sep 20, 2011 at 04:13:40PM -0700, Tony Lindgren wrote:
> * Ohad Ben-Cohen <ohad@wizery.com> [110920 01:34]:
> > On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> >
> > I'm wondering how hwspinlock updates like this should go upstream.
> >
> > The first hwspinlock batch was picked by Tony, because it involved a
> > bulk of OMAP changes.
> >
> > Hwspinlock isn't OMAP-specific anymore though (we gained support for
> > STE's u8500) and the vast majority of changes are in drivers/. We're
> > still very much ARM-related, though this may change too at some point
> > (c6x has a similar "hardware semaphore" peripheral like the u8500
> > does).
> >
> > Tony, if you're still willing to pick up these updates I'd be happy to
> > send you pull requests of course.
>
> I'd prefer for Greg to take these as these are drivers.
What, am I the catch-all for drivers these days?
Oh, right, it looks like I am :)
> If he's not taking it at this point based on it being ARM only,
> I can take it then.
Please do, I don't even have the ability to build them here, as I don't
have an arm cross-compiler on this travel laptop.
greg k-h
^ permalink raw reply
* [PATCH 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers
From: Grant Likely @ 2011-09-20 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314707249-12241-5-git-send-email-kgene.kim@samsung.com>
On Tue, Aug 30, 2011 at 09:27:26PM +0900, Kukjin Kim wrote:
> Since gpio-samsung.c can replace old Samsung GPIO drivers,
> this patch removes them.
>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Removing this code before adding the new code means it is not
bisectable. I'll squash the two patches together when I pick them
up..
g.
> ---
> arch/arm/plat-samsung/Makefile | 2 -
> arch/arm/plat-samsung/gpio-config.c | 431 -----------------------------
> arch/arm/plat-samsung/gpio.c | 167 ------------
> drivers/gpio/Kconfig | 28 --
> drivers/gpio/Makefile | 9 -
> drivers/gpio/gpio-exynos4.c | 385 --------------------------
> drivers/gpio/gpio-plat-samsung.c | 205 --------------
> drivers/gpio/gpio-s3c24xx.c | 283 -------------------
> drivers/gpio/gpio-s3c64xx.c | 289 --------------------
> drivers/gpio/gpio-s5p64x0.c | 510 -----------------------------------
> drivers/gpio/gpio-s5pc100.c | 354 ------------------------
> drivers/gpio/gpio-s5pv210.c | 287 --------------------
> 12 files changed, 0 insertions(+), 2950 deletions(-)
> delete mode 100644 arch/arm/plat-samsung/gpio-config.c
> delete mode 100644 arch/arm/plat-samsung/gpio.c
> delete mode 100644 drivers/gpio/gpio-exynos4.c
> delete mode 100644 drivers/gpio/gpio-plat-samsung.c
> delete mode 100644 drivers/gpio/gpio-s3c24xx.c
> delete mode 100644 drivers/gpio/gpio-s3c64xx.c
> delete mode 100644 drivers/gpio/gpio-s5p64x0.c
> delete mode 100644 drivers/gpio/gpio-s5pc100.c
> delete mode 100644 drivers/gpio/gpio-s5pv210.c
>
^ permalink raw reply
* [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
From: Laurent Pinchart @ 2011-09-20 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-5-git-send-email-deepthy.ravi@ti.com>
Hi Deepthy,
Thanks for the patch.
On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
> Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
> register for UYVY8_2X8 and YUYV8_2X8 formats.
>
> Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
> ---
> drivers/media/video/omap3isp/ispccdc.c | 11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/video/omap3isp/ispccdc.c
> b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644
> --- a/drivers/media/video/omap3isp/ispccdc.c
> +++ b/drivers/media/video/omap3isp/ispccdc.c
> @@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
> *ccdc,
>
> syn_mode &= ~ISPCCDC_SYN_MODE_INPMOD_MASK;
> if (format->code == V4L2_MBUS_FMT_YUYV8_2X8 ||
> - format->code == V4L2_MBUS_FMT_UYVY8_2X8)
> - syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
> + format->code == V4L2_MBUS_FMT_UYVY8_2X8){
> + if (pdata && pdata->bt656)
> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
> + else
> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
> + }
> else if (format->code == V4L2_MBUS_FMT_YUYV8_1X16 ||
> format->code == V4L2_MBUS_FMT_UYVY8_1X16)
> syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
> @@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device
> *ccdc) syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ;
>
> /* Use PACK8 mode for 1byte per pixel formats. */
> - if (omap3isp_video_format_info(format->code)->width <= 8)
> + if ((omap3isp_video_format_info(format->code)->width <= 8) &&
> + (omap3isp_video_format_info(format->code)->bpp <= 8))
I'm not sure to follow you. This will clear the PACK8 bit for the YUYV8_2X8
formats. Those formats are 8 bits wide, shouldn't PACK8 be set to store
samples on 8 bits instead of 16 bits ?
Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode with
the bridge enabled ? In that case, what would you think about setting the CCDC
input format to YUYV8_1X16 instead ? This would better reflect the reality, as
the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC is then fed with
YUYV8_1X16.
> syn_mode |= ISPCCDC_SYN_MODE_PACK8;
> else
> syn_mode &= ~ISPCCDC_SYN_MODE_PACK8;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Fix missing inline functions for Makefile cleanup (Re: [GIT PULL] omap cleanup part1 for v3.2 merge window)
From: Tony Lindgren @ 2011-09-20 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202334.43213.arnd@arndb.de>
Commit f41caddbe73f52a42f529d668ce47b4d693fd2c0 (omap2+: Use
Kconfig symbol in Makefile instead of obj-y) cleaned up the
omap2+ Makefile. However this did not account for the inline
functions that are now needed for board_flash_init and
board_nand_init.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
Will have this in the next pull request for cleanup
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -148,11 +148,6 @@ __init board_nand_init(struct mtd_partition *nand_parts,
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(&board_nand_data);
}
-#else
-void
-__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs, int nand_type)
-{
-}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
/**
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -24,7 +24,26 @@ struct flash_partitions {
int nr_parts;
};
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
extern void board_flash_init(struct flash_partitions [],
char chip_sel[][GPMC_CS_NUM], int nand_type);
+#else
+static inline void board_flash_init(struct flash_partitions part[],
+ char chip_sel[][GPMC_CS_NUM], int nand_type)
+{
+}
+#endif
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
extern void board_nand_init(struct mtd_partition *nand_parts,
u8 nr_parts, u8 cs, int nand_type);
+#else
+static inline void board_nand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs, int nand_type)
+{
+}
+#endif
^ permalink raw reply
* [PATCH 5/5] omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers
From: Laurent Pinchart @ 2011-09-20 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316530612-23075-6-git-send-email-deepthy.ravi@ti.com>
Hi Deepthy,
Thanks for the patch.
On Tuesday 20 September 2011 16:56:52 Deepthy Ravi wrote:
> Enables multimedia driver, media controller api,
> v4l2-subdev-api, omap3isp and mt9t111 sensor
> drivers in omap2plus_defconfig.
>
> Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com>
> ---
> arch/arm/configs/omap2plus_defconfig | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig index d5f00d7..548823d 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -133,6 +133,16 @@ CONFIG_TWL4030_WATCHDOG=y
> CONFIG_REGULATOR_TWL4030=y
> CONFIG_REGULATOR_TPS65023=y
> CONFIG_REGULATOR_TPS6507X=y
> +CONFIG_MEDIA_SUPPORT=y
> +CONFIG_MEDIA_CONTROLLER=y
> +CONFIG_VIDEO_DEV=y
> +CONFIG_VIDEO_V4L2_COMMON=y
> +CONFIG_VIDEO_ALLOW_V4L1=y
> +CONFIG_VIDEO_V4L1_COMPAT=y
> +CONFIG_VIDEO_V4L2_SUBDEV_API=y
> +CONFIG_VIDEO_MEDIA=y
> +CONFIG_VIDEO_MT9T111=y
> +CONFIG_VIDEO_OMAP3=y
Shouldn't they be compiled as modules instead ?
> CONFIG_FB=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_MODE_HELPERS=y
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 00/10] hwspinlock-next
From: Tony Lindgren @ 2011-09-20 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=Wgbam6u1bq8fG+oMUhxfWH1g3dU7q+VhPWFEZOLgFMV_3vQ@mail.gmail.com>
* Ohad Ben-Cohen <ohad@wizery.com> [110920 01:34]:
> On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>
> I'm wondering how hwspinlock updates like this should go upstream.
>
> The first hwspinlock batch was picked by Tony, because it involved a
> bulk of OMAP changes.
>
> Hwspinlock isn't OMAP-specific anymore though (we gained support for
> STE's u8500) and the vast majority of changes are in drivers/. We're
> still very much ARM-related, though this may change too at some point
> (c6x has a similar "hardware semaphore" peripheral like the u8500
> does).
>
> Tony, if you're still willing to pick up these updates I'd be happy to
> send you pull requests of course.
I'd prefer for Greg to take these as these are drivers.
If he's not taking it at this point based on it being ARM only,
I can take it then.
Regards,
Tony
^ permalink raw reply
* [PATCH 3/3] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-09-20 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-4-git-send-email-robherring2@gmail.com>
On Tue, Sep 20, 2011 at 03:24:04PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This adds ARM gic interrupt controller initialization using device tree
> data.
>
> The initialization function is intended to be called by of_irq_init
> function like this:
>
> const static struct of_device_id irq_match[] = {
> { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> {}
> };
>
> static void __init init_irqs(void)
> {
> of_irq_init(irq_match);
> }
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 55 +++++++++++++++
> arch/arm/common/gic.c | 89 +++++++++++++++++++++++-
> arch/arm/include/asm/hardware/gic.h | 12 ++++
> 3 files changed, 152 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..52916b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,55 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> + "arm,cortex-a9-gic"
> + "arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The type shall be a <u32> and the value shall be 3.
> +
> + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> + interrupts.
> +
> + The 2nd cell contains the interrupt number for the interrupt type.
> + SPI interrupts are in the range [0-987]. PPI interrupts are in the
> + range [0-15].
> +
> + The 3rd cell is the flags, encoded as follows:
> + bits[3:0] trigger type and level flags.
> + 1 = low-to-high edge triggered
> + 2 = high-to-low edge triggered
> + 4 = active high level-sensitive
> + 8 = active low level-sensitive
> + bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
> + the 8 possible cpus attached to the GIC. A bit set to '1' indicated
> + the interrupt is wired to that CPU. Only valid for PPI interrupts.
> +
> +- reg : Specifies base physical address(s) and size of the GIC registers. The
> + first region is the GIC distributor register base and size. The 2nd region is
> + the GIC cpu interface register base and size.
> +
> +Optional
> +- interrupts : Interrupt source of the parent interrupt controller. Only
> + present on secondary GICs.
> +
> +Example:
> +
> + intc: interrupt-controller at fff11000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <1>;
> + interrupt-controller;
> + reg = <0xfff11000 0x1000>,
> + <0xfff10100 0x100>;
> + };
> +
Ack on the binding.
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 666b278..84e69a4 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -28,6 +28,10 @@
> #include <linux/smp.h>
> #include <linux/cpumask.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/irqdomain.h>
>
> #include <asm/irq.h>
> #include <asm/mach/irq.h>
> @@ -255,6 +259,15 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
> irq_set_chained_handler(irq, gic_handle_cascade_irq);
> }
>
> +static int gic_irq_count(void __iomem *dist_base)
> +{
> + int gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
> + gic_irqs = (gic_irqs + 1) * 32;
> + if (gic_irqs > 1020)
> + gic_irqs = 1020;
> + return gic_irqs;
> +}
> +
> static void __init gic_dist_init(struct gic_chip_data *gic,
> unsigned int irq_start)
> {
> @@ -277,10 +290,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
> * Find out how many interrupts are supported.
> * The GIC only supports up to 1020 interrupt sources.
> */
> - gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
> - gic_irqs = (gic_irqs + 1) * 32;
> - if (gic_irqs > 1020)
> - gic_irqs = 1020;
> + gic_irqs = gic_irq_count(base);
>
> /*
> * Set all global interrupts to be level triggered, active low.
> @@ -405,3 +415,74 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
> }
> #endif
> +
> +#ifdef CONFIG_OF
> +static int gic_cnt __initdata = 0;
> +
> +int gic_irq_domain_dt_translate(struct irq_domain *d,
> + struct device_node *controller,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq, unsigned int *out_type)
> +{
> + struct gic_chip_data *gic_data = d->priv;
> +
> + if (d->of_node != controller)
> + return -EINVAL;
> + if (intsize < 3)
> + return -EINVAL;
> +
> + *out_hwirq = intspec[1];
> + /*
> + * We've already skipped over SGIs, so PPIs need no translation.
> + * For SPIs, we need to skip over 16 PPIs on primary GICs.
> + */
> + if (!intspec[0] && !gic_data->irq_offset)
> + *out_hwirq += 16;
I though that the offset was 32 to get from SPI number to Interrrupt
ID? And that PPI interrupts start at Interrupt ID 16? Or am I
mistaken about the hwirq number that this driver uses internally?
Otherwise, the change looks about right to me.
g.
^ permalink raw reply
* [PATCH 2/3] of/irq: introduce of_irq_init
From: Grant Likely @ 2011-09-20 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-3-git-send-email-robherring2@gmail.com>
On Tue, Sep 20, 2011 at 03:24:03PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
>
> Based on initial pseudo code from Grant Likely.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Thanks Rob. Looks pretty good.
Comments below.
> ---
> drivers/of/irq.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of_irq.h | 1 +
> 2 files changed, 115 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 6a5b5e7..1d51bc7 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -19,10 +19,12 @@
> */
>
> #include <linux/errno.h>
> +#include <linux/list.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_irq.h>
> #include <linux/string.h>
> +#include <linux/slab.h>
>
> /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
> #ifndef NO_IRQ
> @@ -386,3 +388,115 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>
> return i;
> }
> +
> +struct intc_desc {
> + struct list_head list;
> + struct device_node *dev;
> + struct device_node *interrupt_parent;
> +};
> +
> +typedef int (*irq_init_cb_t)(struct device_node *, struct device_node *);
This typedef should be in a header file. I'd like to try and find a
way to typecheck the .data parameter in the matches table (maybe with
a macro), but I've not dug into the problem.
> +
> +/**
> + * of_irq_init - Scan the device tree for matching interrupt controllers and
kerneldoc format is:
* of_irq_init() - ...
And the short description should fit on the one line. Further
description can appear after the argument list documentation.
> + * call their initialization functions in order with parents first.
> + * @matches: 0 terminated array of nodes to match and initialization function
> + * to call on match
> + */
> +void __init of_irq_init(const struct of_device_id *matches)
> +{
> + struct device_node *np;
> + struct intc_desc *desc;
> + struct intc_desc *temp_desc;
> + struct intc_desc *parent_desc = NULL;
> + struct list_head intc_desc_list;
> + struct list_head intc_parent_list;
Nit: these lines can be collapsed a bit.
struct intc_desc *desc, *temp_desc, *parent_desc = NULL;
struct list_head intc_desc_list, intc_parent_list;
> + INIT_LIST_HEAD(&intc_desc_list);
> + INIT_LIST_HEAD(&intc_parent_list);
> +
> + for_each_matching_node(np, matches) {
> + if (!of_find_property(np, "interrupt-controller", NULL))
> + continue;
> + /* Here, we allocate and populate an intc_desc with the node
> + * pointer, interrupt-parent device_node etc. */
> + desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> + if (!desc) {
> + WARN_ON(1);
> + goto err;
> + }
> + desc->dev = np;
> + desc->interrupt_parent = of_irq_find_parent(np);
> + list_add(&desc->list, &intc_desc_list);
list_add_tail() would keep things ordered.
> + }
> + if (list_empty(&intc_desc_list))
> + return;
This test can be dropped because the while loop performs the exact
same test.
> +
> + /*
> + * The root irq controller is the one without an interrupt-parent.
> + * That one goes first, followed by the controllers that reference it,
> + * followed by the ones that reference the 2nd level controllers, etc
> + */
> + while (!list_empty(&intc_desc_list)) {
> + /*
> + * Process all controllers with the current 'parent'.
> + * First pass will be looking for NULL as the parent.
> + * The assumption is that NULL parent means a root controller.
> + */
> + list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> + const struct of_device_id *match;
> + int ret;
> + irq_init_cb_t irq_init_cb;
> +
> + if (parent_desc &&
> + (desc->interrupt_parent != parent_desc->dev))
> + continue;
If you changed
struct intc_desc *parent_desc = NULL;
to
struct device_node *parent_np = NULL;
Then this test could be simplified to:
if (desc->interupt_parent != parent_np)
continue;
And the kfree could be done immediately after the next parent is
pulled off the intc_desc_list since the only thing actually needed
from the parent_desc is the parent node pointer.
> +
> + list_del(&desc->list);
> + match = of_match_node(matches, desc->dev);
> + if (!match || !match->data)
> + continue;
> +
> + pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> + match->compatible,
> + desc->dev, desc->interrupt_parent);
> + irq_init_cb = match->data;
> + ret = irq_init_cb(desc->dev, desc->interrupt_parent);
> + if (ret)
> + continue;
> +
> + /*
> + * This one is now set up; add it to the parent list so
> + * its children can get processed in a subsequent pass.
> + */
> + list_add_tail(&desc->list, &intc_parent_list);
> + }
> + /*
> + * All the direct children for the current parent are
> + * processed, so free the parent now.
> + */
> + if (parent_desc)
> + kfree(parent_desc);
> +
> + /* Get the next pending parent that might have children */
> + parent_desc = list_first_entry(&intc_parent_list,
> + typeof(*parent_desc), list);
> + if (list_empty(&intc_parent_list) || !parent_desc) {
> + pr_debug("of_irq_init: children remain, but no parents\n");
> + goto err;
> + }
> +
> + list_del(&parent_desc->list);
> + }
Need a loop here to clear and free any remaining entries in the
intc_parent_list. Actually, everything would work fine by simply
removing the below 'return' statement and letting the code fall
through to the free loops unconditionally. And the "goto err" above
can be simplified to "break".
> + return;
> +
> +err:
> + list_for_each_entry_safe(desc, temp_desc, &intc_parent_list, list) {
> + list_del(&desc->list);
> + kfree(desc);
> + }
> + list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> + list_del(&desc->list);
> + kfree(desc);
> + }
> +}
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index cd2e61c..032d76c 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
> struct resource *res, int nr_irqs);
> extern struct device_node *of_irq_find_parent(struct device_node *child);
>
> +extern void of_irq_init(const struct of_device_id *matches);
>
> #endif /* CONFIG_OF_IRQ */
> #endif /* CONFIG_OF */
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH V2] ARM: kdump: copy kernel relocation code at the kexec prepare stage
From: Russell King - ARM Linux @ 2011-09-20 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316520043-14619-1-git-send-email-leiwen@marvell.com>
On Tue, Sep 20, 2011 at 08:00:43PM +0800, Lei Wen wrote:
> This copy really don't need to do at the very second before the kernel
> would crash.
>
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> Acked-by: Simon Horman <horms@verge.net.au>
> ---
> Changelog:
> V2: move the flush_icache_range after the memcpy operation to ensure I/D cache
> coherency for the relocation code
Much better, thanks.
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Tony Lindgren @ 2011-09-20 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202346.11393.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [110920 14:12]:
> On Tuesday 20 September 2011, Arnd Bergmann wrote:
> >
> > One more thing: my randconfig tests are running now and
> > have spit out a new error after merging lost of stuff
> > today:
Good to hear you got "arndconfig" running :)
Do you think we could also add support for something
like this:
$ echo CONFIG_ARCH_OMAP=y > .config
$ make randconfig
or
$ make --force=CONFIG_ARCH_OMAP randconfig
Where randconfig would keep the forced CONFIG_ARCH_OMAP
static while randomly selecting the others?
This would allow targeted randconfig for each patch more
or less..
> > arch/arm/mach-omap2/built-in.o: In function `omap_zoom_init':
> > /home/arnd/linux-arm/arch/arm/mach-omap2/board-zoom.c:117: undefined reference to `board_nand_init'
> > make[1]: *** [.tmp_vmlinux1] Error 1
> > make[1]: Target `_all' not remade because of errors.
> > make: *** [sub-make] Error 2
> > make: Target `_all' not remade because of errors.
>
> Found it: the offending patch is:
>
> omap2+: Use Kconfig symbol in Makefile instead of obj-y
>
>
> It seems that you replace the #ifdef in the board-flash.c file
> with a similar #ifdef in the header that replaces this with an
> empty inline function when the object is not built.
Oops. I'll do a fix for that. Those should be now inline
functions in the header.
As various other omap branches are based on the cleanup I'd
rather not go mess with the original patch unless you insist.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux
From: Stephen Warren @ 2011-09-20 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316175249-10780-1-git-send-email-linus.walleij@stericsson.com>
Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.
...
> diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
...
> +/* Pinmux settings */
> +static struct pinmux_map u300_pinmux_map[] = {
> + /* anonymous maps for chip power and EMIFs */
> + PINMUX_MAP_PRIMARY_SYS_HOG("POWER", "power"),
> + PINMUX_MAP_PRIMARY_SYS_HOG("EMIF0", "emif0"),
> + PINMUX_MAP_PRIMARY_SYS_HOG("EMIF1", "emif1"),
> + /* per-device maps for MMC/SD, SPI and UART */
> + PINMUX_MAP_PRIMARY("MMCSD", "mmc0", "mmci"),
> + PINMUX_MAP_PRIMARY("SPI", "spi0", "pl022"),
> + PINMUX_MAP_PRIMARY("UART0", "uart0", "uart0"),
> +};
> +
> +struct u300_mux_hog {
> + const char *name;
> + struct device *dev;
> + struct pinmux *pmx;
> +};
> +
> +static struct u300_mux_hog u300_mux_hogs[] = {
> + {
> + .name = "uart0",
> + .dev = &uart0_device.dev,
> + },
> + {
> + .name = "spi0",
> + .dev = &pl022_device.dev,
> + },
> + {
> + .name = "mmc0",
> + .dev = &mmcsd_device.dev,
> + },
> +};
> +
> +static int __init u300_pinmux_fetch(void)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(u300_mux_hogs); i++) {
> + struct pinmux *pmx;
> + int ret;
> +
> + pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
> + if (IS_ERR(pmx)) {
> + pr_err("u300: could not get pinmux hog %s\n",
> + u300_mux_hogs[i].name);
> + continue;
> + }
> + ret = pinmux_enable(pmx);
> + if (ret) {
> + pr_err("u300: could enable pinmux hog %s\n",
> + u300_mux_hogs[i].name);
> + continue;
> + }
> + u300_mux_hogs[i].pmx = pmx;
> + }
> + return 0;
> +}
> +subsys_initcall(u300_pinmux_fetch);
Why not just have the pinmux core support hogging on non-"system" mapping
entries; then everything I quoted above except u300_pinmux_map[] could
be deleted, and the "hog" flag set on the last 3 u300_pinmux_map[] entries.
--
nvpublic
^ permalink raw reply
* [PATCH 1/2] drivers: create a pin control subsystem v7
From: Stephen Warren @ 2011-09-20 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316175203-10736-1-git-send-email-linus.walleij@stericsson.com>
Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
I've read through the documentation and header files, but not the .c files,
and this looks almost perfect as far as I can tell right now. I'll try to
review the .c files sometime too.
I just have one comment:
> diff --git a/include/linux/pinctrl/pinmux.h b/include/linux/pinctrl/pinmux.h
...
> +/* External interface to pinmux */
> +extern int pinmux_request_gpio(unsigned gpio);
> +extern void pinmux_free_gpio(unsigned gpio);
> +extern struct pinmux * __must_check pinmux_get(struct device *dev, const char *name);
> +extern void pinmux_put(struct pinmux *pmx);
> +extern int pinmux_enable(struct pinmux *pmx);
> +extern void pinmux_disable(struct pinmux *pmx);
> +extern int pinmux_config(struct pinmux *pmx, u16 param, unsigned long *data);
That definition of pinmux_config doesn't seem as useful as it could be;
I'd like the ability to execute pinmux_config on a /named/ group, and I
can certainly see a use-case for applying it to /named/ pins too.
The issues with applying pinmux_config to a mapping table entry are:
* When there are multiple mapping table entries referenced by one
pinmux_get, you don't necessarily want to apply the same configuration
to all of the groups; think of a bus with a combination of low-speed
output control signals and high-speed input data signals or something
like that.
* When muxing works in groups, you may want to apply the configuration
to individual pins rather than the whole groups using in the mapping
table.
--
nvpublic
^ permalink raw reply
* [PATCH] spi: Fix builderror in spi-pl022.c
From: Grant Likely @ 2011-09-20 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbsUMCvBofKjExiB2wCbK9CwpcXr5xmShJ4SHEGAAH4Bw@mail.gmail.com>
On Tue, Sep 20, 2011 at 10:45:41PM +0200, Linus Walleij wrote:
> On Mon, Sep 5, 2011 at 2:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Sun, Aug 28, 2011 at 9:26 PM, Peter Huewe <peterhuewe@gmx.de> wrote:
> >
> >> This patch fixes a build error, introduced by commit (67fc8b9f, "PM: add
> >> runtime PM support to core Primecell driver") which unfortunately was a little
> >> bit incomplete and did contain a typo (11 instead of 22).
> >> I'm not sure how this patch could have been tested back then, if it
> >> doesn't even compile ;)
> >
> > Grant can you please apply this patch? Right now linux-next is
> > breaking because of this missing patch...
>
> Ping on this... ignore if it's been picked already.
It's not a patch that went through my tree, so I cannot pick it up.
g.
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-20 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202334.43213.arnd@arndb.de>
On Tuesday 20 September 2011, Arnd Bergmann wrote:
> On Saturday 17 September 2011, Tony Lindgren wrote:
> > Hi Arnd,
> >
> > Please pull the first part of omap cleanup from:
> >
> > git://github.com/tmlind/linux.git cleanup
> >
> > This series cleans up early_init functions and removes
> > CHIP_IS macro usage. This makes it easier to have SoC
> > specific init functions so adding support for new omap
> > variants does not require patching all over the place.
>
> One more thing: my randconfig tests are running now and
> have spit out a new error after merging lost of stuff
> today:
>
> arch/arm/mach-omap2/built-in.o: In function `omap_zoom_init':
> /home/arnd/linux-arm/arch/arm/mach-omap2/board-zoom.c:117: undefined reference to `board_nand_init'
> make[1]: *** [.tmp_vmlinux1] Error 1
> make[1]: Target `_all' not remade because of errors.
> make: *** [sub-make] Error 2
> make: Target `_all' not remade because of errors.
Found it: the offending patch is:
omap2+: Use Kconfig symbol in Makefile instead of obj-y
It seems that you replace the #ifdef in the board-flash.c file
with a similar #ifdef in the header that replaces this with an
empty inline function when the object is not built.
Arnd
^ permalink raw reply
* [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
From: Olof Johansson @ 2011-09-20 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202301.56983.arnd@arndb.de>
On Tue, Sep 20, 2011 at 2:01 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 20 September 2011, Arnd Bergmann wrote:
>> On Tuesday 20 September 2011, Grant Likely wrote:
>> > On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote:
>> > > On Tuesday 20 September 2011, Stephen Warren wrote:
>> > > > The bindings were recently updated to have separate properties for each
>> > > > type of GPIO. Update the Device Tree source to match that.
>> > > >
>> > > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> > > > Acked-by: Olof Johansson <olof@lixom.net>
>> > > > ---
>> > > > I'd previously sent these to Grant assuming they'd go in his dt/next branch,
>> > > > but perhaps these should go in through Arnd's arm-soc next/dt branch?
>> > > >
>> > >
>> > > Which tree has the update that changed the bindings? I think it should
>> > > go into the same one.
>> > >
>> > > If it's already upstream, I can take it into the fixes branch.
>> >
>> > Already upstream
>>
>> Ok, I see. I've applied both patches to the fixes branch and will send
>> it out with the next pull request for 3.1 to Linus then.
>
> Sorry, I just noticed that the second patch is not a bug fix, so I took it out
> again and kept only patch 1/2 in the fixes branch for 3.1.
>
> Should I take the other one as well? It's probably better to let that
> go the proper way through the tegra tree for 3.2, right?
Given that you have a public tree right now, and I don't (since
kernel.org is down), please feel free to start a tegra/for-3.2 branch
for me and apply it there. I'll base further work on top of that if
needed.
(There also aren't a whole lot of other patches queued for 3.2 right now).
-Olof
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Arnd Bergmann @ 2011-09-20 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917014623.GC2937@atomide.com>
On Saturday 17 September 2011, Tony Lindgren wrote:
> Hi Arnd,
>
> Please pull the first part of omap cleanup from:
>
> git://github.com/tmlind/linux.git cleanup
>
> This series cleans up early_init functions and removes
> CHIP_IS macro usage. This makes it easier to have SoC
> specific init functions so adding support for new omap
> variants does not require patching all over the place.
One more thing: my randconfig tests are running now and
have spit out a new error after merging lost of stuff
today:
arch/arm/mach-omap2/built-in.o: In function `omap_zoom_init':
/home/arnd/linux-arm/arch/arm/mach-omap2/board-zoom.c:117: undefined reference to `board_nand_init'
make[1]: *** [.tmp_vmlinux1] Error 1
make[1]: Target `_all' not remade because of errors.
make: *** [sub-make] Error 2
make: Target `_all' not remade because of errors.
It's not clear to me if this is actually caused by one of your
changes, or just a mismerge of some sort. I've attached
the defconfig that was used for your reference.
Also, I've got a branch with lots of omap specific randconfig
patches at
git://git.linaro.org/people/arnd/linux.git randconfig/omap
Probably not all of them are correct, but it would be nice
if you could take a look and cherry-pick the ones you like.
Arnd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defconfig.gz
Type: application/x-gzip
Size: 2750 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110920/28f35e27/attachment.gz>
^ permalink raw reply
* [GIT PULL] arm-soc fixes for v3.1-rc7
From: Arnd Bergmann @ 2011-09-20 21:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Here are the latest bug fixes for integration into 3.1. It's mostly
samsung stuff, which was missing in the last round, plus three
small regression fixes in other platforms.
Please pull for the next -rc.
Thanks,
Arnd
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://git.linaro.org/people/arnd/arm-soc.git fixes
Arnd Bergmann (1):
Merge branch 'samsung-fixes-2' of git://github.com/kgene/linux-samsung into HEAD
Banajit Goswami (1):
ARM: S3C64XX: Remove un-used code backlight code on SMDK6410
Changhwan Youn (1):
ARM: EXYNOS4: restart clocksource while system resumes
Jonghwan Choi (1):
ARM: EXYNOS4: Fix wrong pll type for vpll
Kukjin Kim (3):
ARM: EXYNOS4: Fix return type of local_timer_setup()
ARM: EXYNOS4: Fix routing timer interrupt to offline CPU
ARM: SAMSUNG: fix to prevent declaring duplicated
Linus Walleij (1):
mach-integrator: fix VGA base regression
Marek Szyprowski (1):
ARM: SAMSUNG: fix watchdog reset issue with clk_get()
Nicolas Pitre (1):
ARM: Dove: fix second SPI initialization call
Stephen Warren (1):
arm/dt: Tegra: Update SDHCI nodes to match bindings
Thomas Abraham (1):
ARM: EXYNOS4: fix incorrect pad configuration for keypad row lines
arch/arm/boot/dts/tegra-harmony.dts | 12 +++---
arch/arm/boot/dts/tegra-seaboard.dts | 6 ++--
arch/arm/mach-dove/common.c | 2 +-
arch/arm/mach-exynos4/clock.c | 2 +-
arch/arm/mach-exynos4/mct.c | 10 +++++-
arch/arm/mach-exynos4/platsmp.c | 2 +
arch/arm/mach-exynos4/setup-keypad.c | 11 +++---
arch/arm/mach-integrator/integrator_ap.c | 2 +
arch/arm/mach-integrator/pci_v3.c | 2 -
arch/arm/mach-s3c64xx/mach-smdk6410.c | 39 --------------------
arch/arm/plat-samsung/clock.c | 11 ++++++
arch/arm/plat-samsung/include/plat/clock.h | 8 ++++
.../arm/plat-samsung/include/plat/watchdog-reset.h | 10 ++----
13 files changed, 52 insertions(+), 65 deletions(-)
^ permalink raw reply
* [GIT PULL] omap voltage cleanup for v3.2 merge window
From: Tony Lindgren @ 2011-09-20 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202206.24931.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [110920 12:32]:
> On Saturday 17 September 2011, Tony Lindgren wrote:
> > Please pull omap voltage cleanup series:
> >
> > git://github.com/tmlind/linux.git voltage
> >
> > This has a dependency to the cleanup part 1 series. As
> > this contains some voltage fixes too, it's a separate
> > series. You can either pull it into cleanup or keep it
> > separate.
>
> Hi Tony,
>
> I've pulled it into the for-next branch, but haven't
> made up my mind how it I will send it upstream.
> I definitely think it's good that you sent it to me
> as a separate series, given the number of patches in it.
OK thanks. FYI, most of the voltage stuff can eventually
become just a regular device driver. But that depends on
some other changes, like PRCM interrupt driver.
Regards,
Tony
^ permalink raw reply
* [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
From: Arnd Bergmann @ 2011-09-20 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202134.50242.arnd@arndb.de>
On Tuesday 20 September 2011, Arnd Bergmann wrote:
> On Tuesday 20 September 2011, Grant Likely wrote:
> > On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 20 September 2011, Stephen Warren wrote:
> > > > The bindings were recently updated to have separate properties for each
> > > > type of GPIO. Update the Device Tree source to match that.
> > > >
> > > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > > Acked-by: Olof Johansson <olof@lixom.net>
> > > > ---
> > > > I'd previously sent these to Grant assuming they'd go in his dt/next branch,
> > > > but perhaps these should go in through Arnd's arm-soc next/dt branch?
> > > >
> > >
> > > Which tree has the update that changed the bindings? I think it should
> > > go into the same one.
> > >
> > > If it's already upstream, I can take it into the fixes branch.
> >
> > Already upstream
>
> Ok, I see. I've applied both patches to the fixes branch and will send
> it out with the next pull request for 3.1 to Linus then.
Sorry, I just noticed that the second patch is not a bug fix, so I took it out
again and kept only patch 1/2 in the fixes branch for 3.1.
Should I take the other one as well? It's probably better to let that
go the proper way through the tegra tree for 3.2, right?
Arnd
^ permalink raw reply
* [PATCH 1/3] of/irq: of_irq_find_parent: check for parent equal to child
From: Grant Likely @ 2011-09-20 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316550244-3655-2-git-send-email-robherring2@gmail.com>
On Tue, Sep 20, 2011 at 03:24:02PM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> An interrupt controller may often implicitly inherit itself from a parent
> node when in fact the controller is the interrupt root controller. Guard
> against the case of child == parent and return NULL in this case.
>
> This can also be fixed by adding an explicit "interrupt-parent;" to a root
> interrupt controller node.
>
> Based on code from Grant Likely.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Looks great.
Ben, can you look at this please? Make sure I've not missed something
about how powerpc expects of_irq_find_parent() to behave.
g.
> ---
> drivers/of/irq.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 9f689f1..6a5b5e7 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -58,27 +58,27 @@ EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
> */
> struct device_node *of_irq_find_parent(struct device_node *child)
> {
> - struct device_node *p;
> + struct device_node *p, *c = child;
> const __be32 *parp;
>
> - if (!of_node_get(child))
> + if (!of_node_get(c))
> return NULL;
>
> do {
> - parp = of_get_property(child, "interrupt-parent", NULL);
> + parp = of_get_property(c, "interrupt-parent", NULL);
> if (parp == NULL)
> - p = of_get_parent(child);
> + p = of_get_parent(c);
> else {
> if (of_irq_workarounds & OF_IMAP_NO_PHANDLE)
> p = of_node_get(of_irq_dflt_pic);
> else
> p = of_find_node_by_phandle(be32_to_cpup(parp));
> }
> - of_node_put(child);
> - child = p;
> + of_node_put(c);
> + c = p;
> } while (p && of_get_property(p, "#interrupt-cells", NULL) == NULL);
>
> - return p;
> + return (p == child) ? NULL : p;
> }
>
> /**
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH] mach-integrator: fix VGA base regression
From: Arnd Bergmann @ 2011-09-20 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb5jdgR+_aZxVzaedr1FJdUWSi9b7utcB6NsiXhX3GvLA@mail.gmail.com>
On Tuesday 20 September 2011, Linus Walleij wrote:
> On Mon, Sep 5, 2011 at 4:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 05 September 2011, Linus Walleij wrote:
> >> On Sun, Sep 4, 2011 at 11:40 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>
> >> > The changes introduced in commit
> >> > cc22b4c18540e5e8bf55c7d124044f9317527d3c
> >> > "ARM: set vga memory base at run-time"
> >>
> >> Arnd can you choose whether to apply this patch or revert
> >> the commit making it necessary?
> >
> > I'm still stuck with master.kernel.org being down, so I can't really push
> > any updates right now. I'll do it once it's up again.
>
> Ping on this. Rob agreed to merge the patch, this is a regression
> making Integrator non-bootable in 3.1 so I'd really like to see it
> merged ASAP.
>
Applied, thanks for the reminder!
Arnd
^ 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