* [PATCH] ARM i.MX SPI driver changes for i.MX53 support
From: Grant Likely @ 2011-01-13 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimfcxbPq8G_LjO8tz8=nANFkd=5AJYjkTZQyrYG@mail.gmail.com>
On Thu, Jan 13, 2011 at 11:12:07AM +0800, Yong Shen wrote:
> Thanks Grant. I am not asking somebody to merge it right now. I just
> wonder who will take it, since maintainers change from time to time.
Okay. :-) For spi stuff, I usually apply it to my tree, unless it
has dependencies on stuff in someone else's tree. At the very least
spi patches must have either my or David Gibson's ack.
g.
>
> Yong
>
> On Thu, Jan 13, 2011 at 11:05 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
> > On Thu, Jan 13, 2011 at 11:01:44AM +0800, Yong Shen wrote:
> >> Seems no comments from spi-devel list. This patch is also:
> >> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> >>
> >> Who will take this patch into a tree?
> >
> > Patience Yong. ?You only posted it two days ago. ?It takes time for
> > people to notice and respond some times.
> >
> > Normally, I wouldn't pick up a patch in the middle of the merge
> > window, but this is pretty trivial, so I'll bend the rules this time.
> >
> > g.
> >
> >>
> >> Yong
> >>
> >> On Tue, Jan 11, 2011 at 5:21 PM, ?<yong.shen@freescale.com> wrote:
> >> > From: Yong Shen <yong.shen@freescale.com>
> >> >
> >> > 1. Change the Kconfig to include i.MX53
> >> > 2. add devtype entry for i.MX53
> >> >
> >> > Signed-off-by: Yong Shen <yong.shen@freescale.com>
> >> > Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> >> > ---
> >> > ?drivers/spi/Kconfig ? | ? ?4 ++--
> >> > ?drivers/spi/spi_imx.c | ? ?6 ++++++
> >> > ?2 files changed, 8 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> >> > index 78f9fd0..04965e2 100644
> >> > --- a/drivers/spi/Kconfig
> >> > +++ b/drivers/spi/Kconfig
> >> > @@ -153,10 +153,10 @@ config SPI_IMX_VER_0_4
> >> > ? ? ? ?def_bool y if ARCH_MX31
> >> >
> >> > ?config SPI_IMX_VER_0_7
> >> > - ? ? ? def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51
> >> > + ? ? ? def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
> >> >
> >> > ?config SPI_IMX_VER_2_3
> >> > - ? ? ? def_bool y if ARCH_MX51
> >> > + ? ? ? def_bool y if ARCH_MX51 || ARCH_MX53
> >> >
> >> > ?config SPI_IMX
> >> > ? ? ? ?tristate "Freescale i.MX SPI controllers"
> >> > diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
> >> > index 55a38e2..9b8a733 100644
> >> > --- a/drivers/spi/spi_imx.c
> >> > +++ b/drivers/spi/spi_imx.c
> >> > @@ -747,6 +747,12 @@ static struct platform_device_id spi_imx_devtype[] = {
> >> > ? ? ? ? ? ? ? ?.name = "imx51-ecspi",
> >> > ? ? ? ? ? ? ? ?.driver_data = SPI_IMX_VER_2_3,
> >> > ? ? ? ?}, {
> >> > + ? ? ? ? ? ? ? .name = "imx53-cspi",
> >> > + ? ? ? ? ? ? ? .driver_data = SPI_IMX_VER_0_7,
> >> > + ? ? ? }, {
> >> > + ? ? ? ? ? ? ? .name = "imx53-ecspi",
> >> > + ? ? ? ? ? ? ? .driver_data = SPI_IMX_VER_2_3,
> >> > + ? ? ? }, {
> >> > ? ? ? ? ? ? ? ?/* sentinel */
> >> > ? ? ? ?}
> >> > ?};
> >> > --
> >> > 1.7.1
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
^ permalink raw reply
* [PATCH v2] arm: Defer vetting of atags to setup.c
From: Grant Likely @ 2011-01-13 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112195640.GJ11039@n2100.arm.linux.org.uk>
On Wed, Jan 12, 2011 at 07:56:40PM +0000, Russell King - ARM Linux wrote:
> The patch looks good to me, except for one small concerning point, which
> I should've thought about earlier - sorry.
>
> One of the things that __vet_atags does is to make sure that the data
> pointed to by 'r2' is actually an atag list.
>
> Historically, we haven't required boot loaders to set r2 to anything -
> it used not to be defined to mean anything at all. So with older boot
> loaders, this could be pointing at anything - it all depends what the
> boot loader code last did, and how the compiler optimized that code.
>
> So, the __vet_atags asm tries dereferencing the values there after
> checking that it's word aligned. We hope that we won't hit a read-
> sensitive device in doing so. If we find a valid ATAG_CORE then we
> allow the pointer. If we don't find those magic words, then we zero.
>
> For boot loaders which always pass valid r2 values, moving this code
> after the MMU makes no difference. For older boot loaders, it may be
> that __phys_to_virt(r2) ends up pointing at unmapped memory, which will
> cause a MMU abort - and as the vectors haven't been setup, that could
> hang the kernel.
>
> So I think this has to stay in assembly code to make sure it works as
> required - to detect old boot loaders passing random values in r2 and
> allow the old method (atag address in machine_desc struct) to work.
Hmmm, I wondered about that. I knew that code was to support older
firmware that doesn't pass proper atags, but from looking at the
explicit tests, it looked like the dereference would still be safe.
Oh well, it was worth a try.
g.
>
> On Wed, Jan 12, 2011 at 11:03:07AM -0700, Grant Likely wrote:
> > Since the debug macros no longer depend on atag data, the vetting can
> > be deferred to setup_arch() in setup.c which simplifies the code
> > somewhat.
> >
> > This patch removes __vet_atags() from head.S and moves it setup_arch().
> > I've tried to preserve the existing behaviour in this patch so the
> > extra atags vetting is only using when CONFIG_MMU is selected.
> >
> > v2: Move removal of __machine_type_lookup to a separate patch.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> > arch/arm/kernel/head-common.S | 51 +++++++----------------------------------
> > arch/arm/kernel/head.S | 1 -
> > arch/arm/kernel/setup.c | 16 +++++++++++++
> > 3 files changed, 25 insertions(+), 43 deletions(-)
> >
> > diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> > index c84b57d..8bb1829 100644
> > --- a/arch/arm/kernel/head-common.S
> > +++ b/arch/arm/kernel/head-common.S
> > @@ -11,50 +11,8 @@
> > *
> > */
> >
> > -#define ATAG_CORE 0x54410001
> > -#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2)
> > -#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2)
> > -
> > -/*
> > - * Exception handling. Something went wrong and we can't proceed. We
> > - * ought to tell the user, but since we don't have any guarantee that
> > - * we're even running on the right architecture, we do virtually nothing.
> > - *
> > - * If CONFIG_DEBUG_LL is set we try to print out something about the error
> > - * and hope for the best (useful if bootloader fails to pass a proper
> > - * machine ID for example).
> > - */
> > __HEAD
> >
> > -/* Determine validity of the r2 atags pointer. The heuristic requires
> > - * that the pointer be aligned, in the first 16k of physical RAM and
> > - * that the ATAG_CORE marker is first and present. Future revisions
> > - * of this function may be more lenient with the physical address and
> > - * may also be able to move the ATAGS block if necessary.
> > - *
> > - * Returns:
> > - * r2 either valid atags pointer, or zero
> > - * r5, r6 corrupted
> > - */
> > -__vet_atags:
> > - tst r2, #0x3 @ aligned?
> > - bne 1f
> > -
> > - ldr r5, [r2, #0] @ is first tag ATAG_CORE?
> > - cmp r5, #ATAG_CORE_SIZE
> > - cmpne r5, #ATAG_CORE_SIZE_EMPTY
> > - bne 1f
> > - ldr r5, [r2, #4]
> > - ldr r6, =ATAG_CORE
> > - cmp r5, r6
> > - bne 1f
> > -
> > - mov pc, lr @ atag pointer is ok
> > -
> > -1: mov r2, #0
> > - mov pc, lr
> > -ENDPROC(__vet_atags)
> > -
> > /*
> > * The following fragment of code is executed with the MMU on in MMU mode,
> > * and uses absolute addresses; this is not position independent.
> > @@ -158,6 +116,15 @@ __lookup_processor_type_data:
> > .long __proc_info_end
> > .size __lookup_processor_type_data, . - __lookup_processor_type_data
> >
> > +/*
> > + * Exception handling. Something went wrong and we can't proceed. We
> > + * ought to tell the user, but since we don't have any guarantee that
> > + * we're even running on the right architecture, we do virtually nothing.
> > + *
> > + * If CONFIG_DEBUG_LL is set we try to print out something about the error
> > + * and hope for the best (useful if bootloader fails to pass a proper
> > + * machine ID for example).
> > + */
> > __error_p:
> > #ifdef CONFIG_DEBUG_LL
> > adr r0, str_p1
> > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> > index 19f3909..4b0cf4a 100644
> > --- a/arch/arm/kernel/head.S
> > +++ b/arch/arm/kernel/head.S
> > @@ -92,7 +92,6 @@ ENTRY(stext)
> > * r1 = machine no, r2 = atags,
> > * r9 = cpuid, r10 = procinfo
> > */
> > - bl __vet_atags
> > #ifdef CONFIG_SMP_ON_UP
> > bl __fixup_smp
> > #endif
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 77266a8..47cf110 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -851,6 +851,22 @@ void __init setup_arch(char **cmdline_p)
> > if (mdesc->soft_reboot)
> > reboot_setup("s");
> >
> > +#if defined(CONFIG_MMU)
> > + /*
> > + * Determine validity of the atags pointer. The heuristic requires
> > + * that the pointer be aligned, and that the ATAG_CORE marker is
> > + * first and present.
> > + */
> > + if (__atags_pointer & 0x3)
> > + __atags_pointer = 0;
> > + if (__atags_pointer) {
> > + struct tag *t = phys_to_virt(__atags_pointer);
> > + if ((t->hdr.size != tag_size(tag_core)) &&
> > + (t->hdr.size != sizeof(struct tag_header)) &&
> > + (t->hdr.tag != ATAG_CORE))
> > + __atags_pointer = 0;
> > + }
> > +#endif
> > if (__atags_pointer)
> > tags = phys_to_virt(__atags_pointer);
> > else if (mdesc->boot_params)
> >
^ permalink raw reply
* [PATCH 2/3] ARM: i.MX53 EVK: add ecspi IOMUX setting
From: yong.shen at freescale.com @ 2011-01-13 3:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Yong Shen <yong.shen@freescale.com>
add ecspi IOMUX setting, also fix a bug of chip select pin order
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/board-mx53_evk.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index 8017d68..2cb4415 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -33,8 +33,8 @@
#include <mach/iomux-mx53.h>
#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
-#define EVK_ECSPI1_CS0 IMX_GPIO_NR(3, 19)
-#define EVK_ECSPI1_CS1 IMX_GPIO_NR(2, 30)
+#define EVK_ECSPI1_CS0 IMX_GPIO_NR(2, 30)
+#define EVK_ECSPI1_CS1 IMX_GPIO_NR(3, 19)
#include "crm_regs.h"
#include "devices-imx53.h"
@@ -54,6 +54,14 @@ static iomux_v3_cfg_t mx53_evk_pads[] = {
MX53_PAD_ATA_CS_1__UART3_RXD,
MX53_PAD_ATA_DA_1__UART3_CTS,
MX53_PAD_ATA_DA_2__UART3_RTS,
+
+ MX53_PAD_EIM_D16__CSPI1_SCLK,
+ MX53_PAD_EIM_D17__CSPI1_MISO,
+ MX53_PAD_EIM_D18__CSPI1_MOSI,
+
+ /* ecspi chip select lines */
+ MX53_PAD_EIM_EB2__GPIO_2_30,
+ MX53_PAD_EIM_D19__GPIO_3_19,
};
static const struct imxuart_platform_data mx53_evk_uart_pdata __initconst = {
--
1.7.1
^ permalink raw reply related
* [PATCH v4 1/3] ARM: i.MX53: add IOMUX pad for ecspi
From: yong.shen at freescale.com @ 2011-01-13 3:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Yong Shen <yong.shen@freescale.com>
Add IOMUX pad entry for ecspi
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/plat-mxc/include/mach/iomux-mx53.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx53.h b/arch/arm/plat-mxc/include/mach/iomux-mx53.h
index 2673007..68e11d7 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mx53.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mx53.h
@@ -134,6 +134,9 @@ typedef enum iomux_config {
#define MX53_PAD_EIM_D16__GPIO_3_16 IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
#define MX53_PAD_EIM_D17__GPIO_3_17 IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
#define MX53_PAD_EIM_D18__GPIO_3_18 IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
+#define MX53_PAD_EIM_D16__CSPI1_SCLK IOMUX_PAD(0x460, 0x118,IOMUX_CONFIG_ALT4, 0x79c, 3, NO_PAD_CTRL)
+#define MX53_PAD_EIM_D17__CSPI1_MISO IOMUX_PAD(0x464, 0x11C,IOMUX_CONFIG_ALT4, 0x7a0, 3, NO_PAD_CTRL)
+#define MX53_PAD_EIM_D18__CSPI1_MOSI IOMUX_PAD(0x468, 0x120,IOMUX_CONFIG_ALT4, 0x7a4, 3, NO_PAD_CTRL)
#define MX53_PAD_EIM_D19__GPIO_3_19 IOMUX_PAD(0x46C, 0x124,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
#define MX53_PAD_EIM_D20__GPIO_3_20 IOMUX_PAD(0x470, 0x128,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
#define MX53_PAD_EIM_D21__GPIO_3_21 IOMUX_PAD(0x474, 0x12C,IOMUX_CONFIG_ALT1, 0x0, 0, NO_PAD_CTRL)
--
1.7.1
^ permalink raw reply related
* [PATCH v4 2/3] ARM: i.MX53 EVK: add ecspi IOMUX setting
From: yong.shen at freescale.com @ 2011-01-13 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294889993-16347-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
add ecspi IOMUX setting, also fix a bug of chip select pin order
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/board-mx53_evk.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index 8017d68..2cb4415 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -33,8 +33,8 @@
#include <mach/iomux-mx53.h>
#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
-#define EVK_ECSPI1_CS0 IMX_GPIO_NR(3, 19)
-#define EVK_ECSPI1_CS1 IMX_GPIO_NR(2, 30)
+#define EVK_ECSPI1_CS0 IMX_GPIO_NR(2, 30)
+#define EVK_ECSPI1_CS1 IMX_GPIO_NR(3, 19)
#include "crm_regs.h"
#include "devices-imx53.h"
@@ -54,6 +54,14 @@ static iomux_v3_cfg_t mx53_evk_pads[] = {
MX53_PAD_ATA_CS_1__UART3_RXD,
MX53_PAD_ATA_DA_1__UART3_CTS,
MX53_PAD_ATA_DA_2__UART3_RTS,
+
+ MX53_PAD_EIM_D16__CSPI1_SCLK,
+ MX53_PAD_EIM_D17__CSPI1_MISO,
+ MX53_PAD_EIM_D18__CSPI1_MOSI,
+
+ /* ecspi chip select lines */
+ MX53_PAD_EIM_EB2__GPIO_2_30,
+ MX53_PAD_EIM_D19__GPIO_3_19,
};
static const struct imxuart_platform_data mx53_evk_uart_pdata __initconst = {
--
1.7.1
^ permalink raw reply related
* [PATCH v4 3/3] ARM: i.MX53 EVK: add spi nor device
From: yong.shen at freescale.com @ 2011-01-13 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294889993-16347-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
add spi board information for spi nor device
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/board-mx53_evk.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index 2cb4415..caee04c 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -24,6 +24,8 @@
#include <linux/fec.h>
#include <linux/delay.h>
#include <linux/gpio.h>
+#include <linux/spi/flash.h>
+#include <linux/spi/spi.h>
#include <mach/common.h>
#include <mach/hardware.h>
#include <asm/mach-types.h>
@@ -99,6 +101,17 @@ static struct fec_platform_data mx53_evk_fec_pdata = {
.phy = PHY_INTERFACE_MODE_RMII,
};
+static struct spi_board_info mx53_evk_spi_board_info[] __initdata = {
+ {
+ .modalias = "mtd_dataflash",
+ .max_speed_hz = 25000000,
+ .bus_num = 0,
+ .chip_select = 1,
+ .mode = SPI_MODE_0,
+ .platform_data = NULL,
+ },
+};
+
static int mx53_evk_spi_cs[] = {
EVK_ECSPI1_CS0,
EVK_ECSPI1_CS1,
@@ -123,6 +136,8 @@ static void __init mx53_evk_board_init(void)
imx53_add_sdhci_esdhc_imx(0, NULL);
imx53_add_sdhci_esdhc_imx(1, NULL);
+ spi_register_board_info(mx53_evk_spi_board_info,
+ ARRAY_SIZE(mx53_evk_spi_board_info));
imx53_add_ecspi(0, &mx53_evk_spi_data);
}
--
1.7.1
^ permalink raw reply related
* [PATCH v4 2/3] ARM: i.MX53 EVK: add ecspi IOMUX setting
From: Yong Shen @ 2011-01-13 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294889993-16347-2-git-send-email-yong.shen@freescale.com>
Hi there,
Since some code are already in the tree, this patch set are based on
the latest code and reflect some comments from Uwe.
Yong
On Thu, Jan 13, 2011 at 11:39 AM, <yong.shen@freescale.com> wrote:
> From: Yong Shen <yong.shen@freescale.com>
>
> add ecspi IOMUX setting, also fix a bug of chip select pin order
>
> Signed-off-by: Yong Shen <yong.shen@freescale.com>
> ---
> ?arch/arm/mach-mx5/board-mx53_evk.c | ? 12 ++++++++++--
> ?1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
> index 8017d68..2cb4415 100644
> --- a/arch/arm/mach-mx5/board-mx53_evk.c
> +++ b/arch/arm/mach-mx5/board-mx53_evk.c
> @@ -33,8 +33,8 @@
> ?#include <mach/iomux-mx53.h>
>
> ?#define SMD_FEC_PHY_RST ? ? ? ? ? ? ? ?IMX_GPIO_NR(7, 6)
> -#define EVK_ECSPI1_CS0 ? ? ? ? IMX_GPIO_NR(3, 19)
> -#define EVK_ECSPI1_CS1 ? ? ? ? IMX_GPIO_NR(2, 30)
> +#define EVK_ECSPI1_CS0 ? ? ? ? IMX_GPIO_NR(2, 30)
> +#define EVK_ECSPI1_CS1 ? ? ? ? IMX_GPIO_NR(3, 19)
>
> ?#include "crm_regs.h"
> ?#include "devices-imx53.h"
> @@ -54,6 +54,14 @@ static iomux_v3_cfg_t mx53_evk_pads[] = {
> ? ? ? ?MX53_PAD_ATA_CS_1__UART3_RXD,
> ? ? ? ?MX53_PAD_ATA_DA_1__UART3_CTS,
> ? ? ? ?MX53_PAD_ATA_DA_2__UART3_RTS,
> +
> + ? ? ? MX53_PAD_EIM_D16__CSPI1_SCLK,
> + ? ? ? MX53_PAD_EIM_D17__CSPI1_MISO,
> + ? ? ? MX53_PAD_EIM_D18__CSPI1_MOSI,
> +
> + ? ? ? /* ecspi chip select lines */
> + ? ? ? MX53_PAD_EIM_EB2__GPIO_2_30,
> + ? ? ? MX53_PAD_EIM_D19__GPIO_3_19,
> ?};
>
> ?static const struct imxuart_platform_data mx53_evk_uart_pdata __initconst = {
> --
> 1.7.1
>
>
>
^ permalink raw reply
* [PATCH] drivers: ld9040 amoled driver support
From: Donghwa Lee @ 2011-01-13 4:40 UTC (permalink / raw)
To: linux-arm-kernel
This patch is ld9040 amoled panel driver.
I resend because there was no comment.
It is similar to s6e63m0 panel driver and use spi gpio to send panel
information.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
---
drivers/video/backlight/Kconfig | 8 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/ld9040.c | 927 ++++++++++++++++++++++++++++++++
drivers/video/backlight/ld9040_gamma.h | 203 +++++++
4 files changed, 1139 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/backlight/ld9040.c
create mode 100644 drivers/video/backlight/ld9040_gamma.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index e54a337..db3d123 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -109,6 +109,14 @@ config LCD_S6E63M0
If you have an S6E63M0 LCD Panel, say Y to enable its
LCD control driver.
+config LCD_LD9040
+ tristate "LD9040 AMOLED LCD Driver"
+ depends on SPI && BACKLIGHT_CLASS_DEVICE
+ default n
+ help
+ If you have an LD9040 Panel, say Y to enable its
+ control driver.
+
endif # LCD_CLASS_DEVICE
#
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 44c0f81..457996c 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_LCD_VGG2432A4) += vgg2432a4.o
obj-$(CONFIG_LCD_TDO24M) += tdo24m.o
obj-$(CONFIG_LCD_TOSA) += tosa_lcd.o
obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
+obj-$(CONFIG_LCD_LD9040) += ld9040.o
obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
obj-$(CONFIG_BACKLIGHT_ATMEL_PWM) += atmel-pwm-bl.o
diff --git a/drivers/video/backlight/ld9040.c b/drivers/video/backlight/ld9040.c
new file mode 100644
index 0000000..248f42f
--- /dev/null
+++ b/drivers/video/backlight/ld9040.c
@@ -0,0 +1,927 @@
+/*
+ * ld9040 AMOLED LCD panel driver.
+ *
+ * Author: Donghwa Lee <dh09.lee@samsung.com>
+ *
+ * Derived from drivers/video/backlight/s6e63m0.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <linux/wait.h>
+#include <linux/fb.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/lcd.h>
+#include <linux/backlight.h>
+
+#include "ld9040_gamma.h"
+
+#define SLEEPMSEC 0x1000
+#define ENDDEF 0x2000
+#define DEFMASK 0xFF00
+#define COMMAND_ONLY 0xFE
+#define DATA_ONLY 0xFF
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 24
+#define POWER_IS_ON(pwr) ((pwr) <= FB_BLANK_NORMAL)
+
+struct ld9040 {
+ struct device *dev;
+ struct spi_device *spi;
+ unsigned int power;
+ unsigned int gamma_mode;
+ unsigned int current_brightness;
+ unsigned int gamma_table_count;
+
+ struct lcd_device *ld;
+ struct backlight_device *bd;
+ struct lcd_platform_data *lcd_pd;
+};
+
+static const unsigned short SEQ_SWRESET[] = {
+ 0x01, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_USER_SETTING[] = {
+ 0xF0, 0x5A,
+
+ DATA_ONLY, 0x5A,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_ELVSS_ON[] = {
+ 0xB1, 0x0D,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x16,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GTCON[] = {
+ 0xF7, 0x09,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_PANEL_CONDITION[] = {
+ 0xF8, 0x05,
+
+ DATA_ONLY, 0x65,
+ DATA_ONLY, 0x96,
+ DATA_ONLY, 0x71,
+ DATA_ONLY, 0x7D,
+ DATA_ONLY, 0x19,
+ DATA_ONLY, 0x3B,
+ DATA_ONLY, 0x0D,
+ DATA_ONLY, 0x19,
+ DATA_ONLY, 0x7E,
+ DATA_ONLY, 0x0D,
+ DATA_ONLY, 0xE2,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x7E,
+ DATA_ONLY, 0x7D,
+ DATA_ONLY, 0x07,
+ DATA_ONLY, 0x07,
+ DATA_ONLY, 0x20,
+ DATA_ONLY, 0x20,
+ DATA_ONLY, 0x20,
+ DATA_ONLY, 0x02,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAMMA_SET1[] = {
+ 0xF9, 0x00,
+
+ DATA_ONLY, 0xA7,
+ DATA_ONLY, 0xB4,
+ DATA_ONLY, 0xAE,
+ DATA_ONLY, 0xBF,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x91,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xB2,
+ DATA_ONLY, 0xB4,
+ DATA_ONLY, 0xAA,
+ DATA_ONLY, 0xBB,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xAC,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xB3,
+ DATA_ONLY, 0xB1,
+ DATA_ONLY, 0xAA,
+ DATA_ONLY, 0xBC,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0xB3,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAMMA_CTRL[] = {
+ 0xFB, 0x02,
+
+ DATA_ONLY, 0x5A,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAMMA_START[] = {
+ 0xF9, COMMAND_ONLY,
+
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_APON[] = {
+ 0xF3, 0x00,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x0A,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_DISPCTL[] = {
+ 0xF2, 0x02,
+
+ DATA_ONLY, 0x08,
+ DATA_ONLY, 0x08,
+ DATA_ONLY, 0x10,
+ DATA_ONLY, 0x10,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_MANPWR[] = {
+ 0xB0, 0x04,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_PWR_CTRL[] = {
+ 0xF4, 0x0A,
+
+ DATA_ONLY, 0x87,
+ DATA_ONLY, 0x25,
+ DATA_ONLY, 0x6A,
+ DATA_ONLY, 0x44,
+ DATA_ONLY, 0x02,
+ DATA_ONLY, 0x88,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_SLPOUT[] = {
+ 0x11, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_SLPIN[] = {
+ 0x10, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_DISPON[] = {
+ 0x29, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_DISPOFF[] = {
+ 0x28, COMMAND_ONLY,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VCI1_1ST_EN[] = {
+ 0xF3, 0x10,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VL1_EN[] = {
+ 0xF3, 0x11,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VL2_EN[] = {
+ 0xF3, 0x13,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VCI1_2ND_EN[] = {
+ 0xF3, 0x33,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VL3_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VREG1_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x01,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VGH_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x11,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VGL_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0x31,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x02,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VMOS_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xB1,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VINT_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xF1,
+ /* DATA_ONLY, 0x71, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VBH_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xF9,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_VBL_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFD,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GAM_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_SD_AMP_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x80,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_GLS_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x81,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_ELS_EN[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x83,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static const unsigned short SEQ_EL_ON[] = {
+ 0xF3, 0x37,
+
+ DATA_ONLY, 0xFF,
+ /* DATA_ONLY, 0x73, VMOS/VBL/VBH not used */
+ DATA_ONLY, 0x87,
+ DATA_ONLY, 0x00,
+ DATA_ONLY, 0x03,
+ /* DATA_ONLY, 0x02, VMOS/VBL/VBH not used */
+ ENDDEF, 0x00
+};
+
+static int ld9040_spi_write_byte(struct ld9040 *lcd, int addr, int data)
+{
+ u16 buf[1];
+ struct spi_message msg;
+
+ struct spi_transfer xfer = {
+ .len = 2,
+ .tx_buf = buf,
+ };
+
+ buf[0] = (addr << 8) | data;
+
+ spi_message_init(&msg);
+ spi_message_add_tail(&xfer, &msg);
+
+ return spi_sync(lcd->spi, &msg);
+}
+
+static int ld9040_spi_write(struct ld9040 *lcd, unsigned char address,
+ unsigned char command)
+{
+ int ret = 0;
+
+ if (address != DATA_ONLY)
+ ret = ld9040_spi_write_byte(lcd, 0x0, address);
+ if (command != COMMAND_ONLY)
+ ret = ld9040_spi_write_byte(lcd, 0x1, command);
+
+ return ret;
+}
+
+static int ld9040_panel_send_sequence(struct ld9040 *lcd,
+ const unsigned short *wbuf)
+{
+ int ret = 0, i = 0;
+
+ while ((wbuf[i] & DEFMASK) != ENDDEF) {
+ if ((wbuf[i] & DEFMASK) != SLEEPMSEC) {
+ ret = ld9040_spi_write(lcd, wbuf[i], wbuf[i+1]);
+ if (ret)
+ break;
+ } else
+ udelay(wbuf[i+1]*1000);
+ i += 2;
+ }
+
+ return ret;
+}
+
+static int _ld9040_gamma_ctl(struct ld9040 *lcd, const unsigned int *gamma)
+{
+ unsigned int i = 0;
+ int ret = 0;
+
+ /* start gamma table updating. */
+ ret = ld9040_panel_send_sequence(lcd, SEQ_GAMMA_START);
+ if (ret) {
+ dev_err(lcd->dev, "failed to disable gamma table updating.\n");
+ goto gamma_err;
+ }
+
+ for (i = 0 ; i < GAMMA_TABLE_COUNT; i++) {
+ ret = ld9040_spi_write(lcd, DATA_ONLY, gamma[i]);
+ if (ret) {
+ dev_err(lcd->dev, "failed to set gamma table.\n");
+ goto gamma_err;
+ }
+ }
+
+ /* update gamma table. */
+ ret = ld9040_panel_send_sequence(lcd, SEQ_GAMMA_CTRL);
+ if (ret)
+ dev_err(lcd->dev, "failed to update gamma table.\n");
+
+gamma_err:
+ return ret;
+}
+
+static int ld9040_gamma_ctl(struct ld9040 *lcd, int gamma)
+{
+ int ret = 0;
+
+ ret = _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[gamma]);
+
+ return ret;
+}
+
+
+static int ld9040_ldi_init(struct ld9040 *lcd)
+{
+ int ret, i;
+ const unsigned short *init_seq[] = {
+ SEQ_USER_SETTING,
+ SEQ_PANEL_CONDITION,
+ SEQ_DISPCTL,
+ SEQ_MANPWR,
+ SEQ_PWR_CTRL,
+ SEQ_ELVSS_ON,
+ SEQ_GTCON,
+ SEQ_GAMMA_SET1,
+ SEQ_GAMMA_CTRL,
+ SEQ_SLPOUT,
+ };
+
+ for (i = 0; i < ARRAY_SIZE(init_seq); i++) {
+ ret = ld9040_panel_send_sequence(lcd, init_seq[i]);
+ /* workaround: minimum delay time for transferring CMD */
+ udelay(300);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+static int ld9040_ldi_enable(struct ld9040 *lcd)
+{
+ int ret = 0;
+
+ ret = ld9040_panel_send_sequence(lcd, SEQ_DISPON);
+
+ return ret;
+}
+
+static int ld9040_ldi_disable(struct ld9040 *lcd)
+{
+ int ret;
+
+ ret = ld9040_panel_send_sequence(lcd, SEQ_DISPOFF);
+ ret = ld9040_panel_send_sequence(lcd, SEQ_SLPIN);
+
+ return ret;
+}
+
+static int ld9040_power_on(struct ld9040 *lcd)
+{
+ int ret = 0;
+ struct lcd_platform_data *pd = NULL;
+ pd = lcd->lcd_pd;
+ if (!pd) {
+ dev_err(lcd->dev, "platform data is NULL.\n");
+ return -EFAULT;
+ }
+
+ if (!pd->power_on) {
+ dev_err(lcd->dev, "power_on is NULL.\n");
+ return -EFAULT;
+ } else {
+ pd->power_on(lcd->ld, 1);
+ mdelay(pd->power_on_delay);
+ }
+
+ if (!pd->reset) {
+ dev_err(lcd->dev, "reset is NULL.\n");
+ return -EFAULT;
+ } else {
+ pd->reset(lcd->ld);
+ mdelay(pd->reset_delay);
+ }
+
+ ret = ld9040_ldi_init(lcd);
+ if (ret) {
+ dev_err(lcd->dev, "failed to initialize ldi.\n");
+ return ret;
+ }
+
+ ret = ld9040_ldi_enable(lcd);
+ if (ret) {
+ dev_err(lcd->dev, "failed to enable ldi.\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ld9040_power_off(struct ld9040 *lcd)
+{
+ int ret = 0;
+ struct lcd_platform_data *pd = NULL;
+
+ pd = lcd->lcd_pd;
+ if (!pd) {
+ dev_err(lcd->dev, "platform data is NULL.\n");
+ return -EFAULT;
+ }
+
+ ret = ld9040_ldi_disable(lcd);
+ if (ret) {
+ dev_err(lcd->dev, "lcd setting failed.\n");
+ return -EIO;
+ }
+
+ mdelay(pd->power_off_delay);
+
+ if (!pd->power_on) {
+ dev_err(lcd->dev, "power_on is NULL.\n");
+ return -EFAULT;
+ } else
+ pd->power_on(lcd->ld, 0);
+
+ return 0;
+}
+
+static int ld9040_power(struct ld9040 *lcd, int power)
+{
+ int ret = 0;
+
+ if (POWER_IS_ON(power) && !POWER_IS_ON(lcd->power))
+ ret = ld9040_power_on(lcd);
+ else if (!POWER_IS_ON(power) && POWER_IS_ON(lcd->power))
+ ret = ld9040_power_off(lcd);
+
+ if (!ret)
+ lcd->power = power;
+
+ return ret;
+}
+
+static int ld9040_set_power(struct lcd_device *ld, int power)
+{
+ struct ld9040 *lcd = lcd_get_data(ld);
+
+ if (power != FB_BLANK_UNBLANK && power != FB_BLANK_POWERDOWN &&
+ power != FB_BLANK_NORMAL) {
+ dev_err(lcd->dev, "power value should be 0, 1 or 4.\n");
+ return -EINVAL;
+ }
+
+ return ld9040_power(lcd, power);
+}
+
+static int ld9040_get_power(struct lcd_device *ld)
+{
+ struct ld9040 *lcd = lcd_get_data(ld);
+
+ return lcd->power;
+}
+
+static int ld9040_get_brightness(struct backlight_device *bd)
+{
+ return bd->props.brightness;
+}
+
+static int ld9040_set_brightness(struct backlight_device *bd)
+{
+ int ret = 0, brightness = bd->props.brightness;
+ struct ld9040 *lcd = bl_get_data(bd);
+
+ if (brightness < MIN_BRIGHTNESS ||
+ brightness > bd->props.max_brightness) {
+ dev_err(&bd->dev, "lcd brightness should be %d to %d.\n",
+ MIN_BRIGHTNESS, MAX_BRIGHTNESS);
+ return -EINVAL;
+ }
+
+ ret = ld9040_gamma_ctl(lcd, bd->props.brightness);
+ if (ret) {
+ dev_err(&bd->dev, "lcd brightness setting failed.\n");
+ return -EIO;
+ }
+
+ return ret;
+}
+
+static struct lcd_ops ld9040_lcd_ops = {
+ .set_power = ld9040_set_power,
+ .get_power = ld9040_get_power,
+};
+
+static const struct backlight_ops ld9040_backlight_ops = {
+ .get_brightness = ld9040_get_brightness,
+ .update_status = ld9040_set_brightness,
+};
+
+static ssize_t ld9040_sysfs_show_gamma_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct ld9040 *lcd = dev_get_drvdata(dev);
+ char temp[10];
+
+ switch (lcd->gamma_mode) {
+ case 0:
+ sprintf(temp, "2.2 mode\n");
+ strcat(buf, temp);
+ break;
+ default:
+ dev_info(dev, "gamma mode could be 0:2.2\n");
+ break;
+ }
+
+ return strlen(buf);
+}
+
+static ssize_t ld9040_sysfs_store_gamma_mode(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct ld9040 *lcd = dev_get_drvdata(dev);
+ struct backlight_device *bd = NULL;
+ int brightness, rc;
+
+ rc = strict_strtoul(buf, 0, (unsigned long *)&lcd->gamma_mode);
+ if (rc < 0)
+ return rc;
+
+ bd = lcd->bd;
+
+ brightness = bd->props.brightness;
+
+ switch (lcd->gamma_mode) {
+ case 0:
+ _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[brightness]);
+ break;
+ default:
+ dev_info(dev, "gamma mode could be 0:2.2\n");
+ _ld9040_gamma_ctl(lcd, gamma_table.gamma_22_table[brightness]);
+ break;
+ }
+ return len;
+}
+
+static DEVICE_ATTR(gamma_mode, 0644,
+ ld9040_sysfs_show_gamma_mode, ld9040_sysfs_store_gamma_mode);
+
+static ssize_t ld9040_sysfs_show_gamma_table(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct ld9040 *lcd = dev_get_drvdata(dev);
+ char temp[3];
+
+ sprintf(temp, "%d\n", lcd->gamma_table_count);
+ strcpy(buf, temp);
+
+ return strlen(buf);
+}
+
+static DEVICE_ATTR(gamma_table, 0644,
+ ld9040_sysfs_show_gamma_table, NULL);
+
+static int ld9040_probe(struct spi_device *spi)
+{
+ int ret = 0;
+ struct ld9040 *lcd = NULL;
+ struct lcd_device *ld = NULL;
+ struct backlight_device *bd = NULL;
+
+ lcd = kzalloc(sizeof(struct ld9040), GFP_KERNEL);
+ if (!lcd)
+ return -ENOMEM;
+
+ /* ld9040 lcd panel uses 3-wire 9bits SPI Mode. */
+ spi->bits_per_word = 9;
+
+ ret = spi_setup(spi);
+ if (ret < 0) {
+ dev_err(&spi->dev, "spi setup failed.\n");
+ goto out_free_lcd;
+ }
+
+ lcd->spi = spi;
+ lcd->dev = &spi->dev;
+
+ lcd->lcd_pd = (struct lcd_platform_data *)spi->dev.platform_data;
+ if (!lcd->lcd_pd) {
+ dev_err(&spi->dev, "platform data is NULL.\n");
+ goto out_free_lcd;
+ }
+
+ ld = lcd_device_register("ld9040", &spi->dev, lcd, &ld9040_lcd_ops);
+ if (IS_ERR(ld)) {
+ ret = PTR_ERR(ld);
+ goto out_free_lcd;
+ }
+
+ lcd->ld = ld;
+
+ bd = backlight_device_register("ld9040-bl", &spi->dev,
+ lcd, &ld9040_backlight_ops, NULL);
+ if (IS_ERR(ld)) {
+ ret = PTR_ERR(ld);
+ goto out_free_lcd;
+ }
+
+ bd->props.max_brightness = MAX_BRIGHTNESS;
+ bd->props.brightness = MAX_BRIGHTNESS;
+ lcd->bd = bd;
+
+ /*
+ * it gets gamma table count available so it gets user
+ * know that.
+ */
+ lcd->gamma_table_count =
+ sizeof(gamma_table) / (MAX_GAMMA_LEVEL * sizeof(int));
+
+ ret = device_create_file(&(spi->dev), &dev_attr_gamma_mode);
+ if (ret < 0)
+ dev_err(&(spi->dev), "failed to add sysfs entries\n");
+
+ ret = device_create_file(&(spi->dev), &dev_attr_gamma_table);
+ if (ret < 0)
+ dev_err(&(spi->dev), "failed to add sysfs entries\n");
+
+ /*
+ * if lcd panel was on from bootloader like u-boot then
+ * do not lcd on.
+ */
+ if (!lcd->lcd_pd->lcd_enabled) {
+ /*
+ * if lcd panel was off from bootloader then
+ * current lcd status is powerdown and then
+ * it enables lcd panel.
+ */
+ lcd->power = FB_BLANK_POWERDOWN;
+
+ ld9040_power(lcd, FB_BLANK_UNBLANK);
+ } else
+ lcd->power = FB_BLANK_UNBLANK;
+
+ dev_set_drvdata(&spi->dev, lcd);
+
+ dev_info(&spi->dev, "ld9040 panel driver has been probed.\n");
+ return 0;
+
+out_free_lcd:
+ kfree(lcd);
+ return ret;
+}
+
+static int __devexit ld9040_remove(struct spi_device *spi)
+{
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ ld9040_power(lcd, FB_BLANK_POWERDOWN);
+ lcd_device_unregister(lcd->ld);
+ kfree(lcd);
+
+ return 0;
+}
+
+#if defined(CONFIG_PM)
+unsigned int beforepower;
+
+static int ld9040_suspend(struct spi_device *spi, pm_message_t mesg)
+{
+ int ret = 0;
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ dev_dbg(&spi->dev, "lcd->power = %d\n", lcd->power);
+
+ beforepower = lcd->power;
+
+ /*
+ * when lcd panel is suspend, lcd panel becomes off
+ * regardless of status.
+ */
+ ret = ld9040_power(lcd, FB_BLANK_POWERDOWN);
+
+ return ret;
+}
+
+static int ld9040_resume(struct spi_device *spi)
+{
+ int ret = 0;
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ /*
+ * after suspended, if lcd panel status is FB_BLANK_UNBLANK
+ * (at that time, power is FB_BLANK_UNBLANK) then
+ * it changes that status to FB_BLANK_POWERDOWN to get lcd on.
+ */
+ if (beforepower == FB_BLANK_UNBLANK)
+ lcd->power = FB_BLANK_POWERDOWN;
+
+ dev_dbg(&spi->dev, "power = %d\n", beforepower);
+
+ ret = ld9040_power(lcd, beforepower);
+
+ return ret;
+}
+#else
+#define ld9040_suspend NULL
+#define ld9040_resume NULL
+#endif
+
+/* Power down all displays on reboot, poweroff or halt. */
+static void ld9040_shutdown(struct spi_device *spi)
+{
+ struct ld9040 *lcd = dev_get_drvdata(&spi->dev);
+
+ ld9040_power(lcd, FB_BLANK_POWERDOWN);
+}
+
+static struct spi_driver ld9040_driver = {
+ .driver = {
+ .name = "ld9040",
+ .bus = &spi_bus_type,
+ .owner = THIS_MODULE,
+ },
+ .probe = ld9040_probe,
+ .remove = __devexit_p(ld9040_remove),
+ .shutdown = ld9040_shutdown,
+ .suspend = ld9040_suspend,
+ .resume = ld9040_resume,
+};
+
+static int __init ld9040_init(void)
+{
+ return spi_register_driver(&ld9040_driver);
+}
+
+static void __exit ld9040_exit(void)
+{
+ spi_unregister_driver(&ld9040_driver);
+}
+
+module_init(ld9040_init);
+module_exit(ld9040_exit);
+
+MODULE_AUTHOR("Donghwa Lee <dh09.lee@samsung.com>");
+MODULE_DESCRIPTION("ld9040 LCD Driver");
+MODULE_LICENSE("GPL");
+
diff --git a/drivers/video/backlight/ld9040_gamma.h b/drivers/video/backlight/ld9040_gamma.h
new file mode 100644
index 0000000..f199133
--- /dev/null
+++ b/drivers/video/backlight/ld9040_gamma.h
@@ -0,0 +1,203 @@
+/* linux/drivers/video/samsung/ld9040_brightness.h
+ *
+ * Gamma level definitions.
+ *
+ * Copyright (c) 2009 Samsung Electronics
+ * InKi Dae <inki.dae@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#ifndef _ld9040_BRIGHTNESS_H
+#define _ld9040_BRIGHTNESS_H
+
+#define MAX_GAMMA_LEVEL 25
+#define GAMMA_TABLE_COUNT 21
+
+/* gamma value: 2.2 */
+static const unsigned int ld9040_22_300[] = {
+ 0x00, 0xa7, 0xb4, 0xae, 0xbf, 0x00, 0x91,
+ 0x00, 0xb2, 0xb4, 0xaa, 0xbb, 0x00, 0xac,
+ 0x00, 0xb3, 0xb1, 0xaa, 0xbc, 0x00, 0xb3
+};
+
+static const unsigned int ld9040_22_290[] = {
+ 0x00, 0xa9, 0xb7, 0xae, 0xbd, 0x00, 0x89,
+ 0x00, 0xb7, 0xb6, 0xa8, 0xba, 0x00, 0xa4,
+ 0x00, 0xb1, 0xb4, 0xaa, 0xbb, 0x00, 0xaa
+};
+
+static const unsigned int ld9040_22_280[] = {
+ 0x00, 0xa9, 0xb6, 0xad, 0xbf, 0x00, 0x86,
+ 0x00, 0xb8, 0xb5, 0xa8, 0xbc, 0x00, 0xa0,
+ 0x00, 0xb3, 0xb3, 0xa9, 0xbc, 0x00, 0xa7
+};
+
+static const unsigned int ld9040_22_270[] = {
+ 0x00, 0xa8, 0xb8, 0xae, 0xbe, 0x00, 0x84,
+ 0x00, 0xb9, 0xb7, 0xa8, 0xbc, 0x00, 0x9d,
+ 0x00, 0xb2, 0xb5, 0xaa, 0xbc, 0x00, 0xa4
+
+};
+static const unsigned int ld9040_22_260[] = {
+ 0x00, 0xa4, 0xb8, 0xb0, 0xbf, 0x00, 0x80,
+ 0x00, 0xb8, 0xb6, 0xaa, 0xbc, 0x00, 0x9a,
+ 0x00, 0xb0, 0xb5, 0xab, 0xbd, 0x00, 0xa0
+};
+
+static const unsigned int ld9040_22_250[] = {
+ 0x00, 0xa4, 0xb9, 0xaf, 0xc1, 0x00, 0x7d,
+ 0x00, 0xb9, 0xb6, 0xaa, 0xbb, 0x00, 0x97,
+ 0x00, 0xb1, 0xb5, 0xaa, 0xbf, 0x00, 0x9d
+};
+
+static const unsigned int ld9040_22_240[] = {
+ 0x00, 0xa2, 0xb9, 0xaf, 0xc2, 0x00, 0x7a,
+ 0x00, 0xb9, 0xb7, 0xaa, 0xbd, 0x00, 0x94,
+ 0x00, 0xb0, 0xb5, 0xab, 0xbf, 0x00, 0x9a
+};
+
+static const unsigned int ld9040_22_230[] = {
+ 0x00, 0xa0, 0xb9, 0xaf, 0xc3, 0x00, 0x77,
+ 0x00, 0xb9, 0xb7, 0xab, 0xbe, 0x00, 0x90,
+ 0x00, 0xb0, 0xb6, 0xab, 0xbf, 0x00, 0x97
+};
+
+static const unsigned int ld9040_22_220[] = {
+ 0x00, 0x9e, 0xba, 0xb0, 0xc2, 0x00, 0x75,
+ 0x00, 0xb9, 0xb8, 0xab, 0xbe, 0x00, 0x8e,
+ 0x00, 0xb0, 0xb6, 0xac, 0xbf, 0x00, 0x94
+};
+
+static const unsigned int ld9040_22_210[] = {
+ 0x00, 0x9c, 0xb9, 0xb0, 0xc4, 0x00, 0x72,
+ 0x00, 0xb8, 0xb8, 0xac, 0xbf, 0x00, 0x8a,
+ 0x00, 0xb0, 0xb6, 0xac, 0xc0, 0x00, 0x91
+};
+
+static const unsigned int ld9040_22_200[] = {
+ 0x00, 0x9a, 0xba, 0xb1, 0xc4, 0x00, 0x6f,
+ 0x00, 0xb8, 0xb8, 0xad, 0xc0, 0x00, 0x86,
+ 0x00, 0xb0, 0xb7, 0xad, 0xc0, 0x00, 0x8d
+};
+
+static const unsigned int ld9040_22_190[] = {
+ 0x00, 0x97, 0xba, 0xb2, 0xc5, 0x00, 0x6c,
+ 0x00, 0xb8, 0xb8, 0xae, 0xc1, 0x00, 0x82,
+ 0x00, 0xb0, 0xb6, 0xae, 0xc2, 0x00, 0x89
+};
+
+static const unsigned int ld9040_22_180[] = {
+ 0x00, 0x93, 0xba, 0xb3, 0xc5, 0x00, 0x69,
+ 0x00, 0xb8, 0xb9, 0xae, 0xc1, 0x00, 0x7f,
+ 0x00, 0xb0, 0xb6, 0xae, 0xc3, 0x00, 0x85
+};
+
+static const unsigned int ld9040_22_170[] = {
+ 0x00, 0x8b, 0xb9, 0xb3, 0xc7, 0x00, 0x65,
+ 0x00, 0xb7, 0xb8, 0xaf, 0xc3, 0x00, 0x7a,
+ 0x00, 0x80, 0xb6, 0xae, 0xc4, 0x00, 0x81
+};
+
+static const unsigned int ld9040_22_160[] = {
+ 0x00, 0x89, 0xba, 0xb3, 0xc8, 0x00, 0x62,
+ 0x00, 0xb6, 0xba, 0xaf, 0xc3, 0x00, 0x76,
+ 0x00, 0xaf, 0xb7, 0xae, 0xc4, 0x00, 0x7e
+};
+
+static const unsigned int ld9040_22_150[] = {
+ 0x00, 0x82, 0xba, 0xb4, 0xc7, 0x00, 0x5f,
+ 0x00, 0xb5, 0xba, 0xb0, 0xc3, 0x00, 0x72,
+ 0x00, 0xae, 0xb8, 0xb0, 0xc3, 0x00, 0x7a
+};
+
+static const unsigned int ld9040_22_140[] = {
+ 0x00, 0x7b, 0xbb, 0xb4, 0xc8, 0x00, 0x5b,
+ 0x00, 0xb5, 0xba, 0xb1, 0xc4, 0x00, 0x6e,
+ 0x00, 0xae, 0xb9, 0xb0, 0xc5, 0x00, 0x75
+};
+
+static const unsigned int ld9040_22_130[] = {
+ 0x00, 0x71, 0xbb, 0xb5, 0xc8, 0x00, 0x57,
+ 0x00, 0xb5, 0xbb, 0xb0, 0xc5, 0x00, 0x6a,
+ 0x00, 0xae, 0xb9, 0xb1, 0xc6, 0x00, 0x70
+};
+
+static const unsigned int ld9040_22_120[] = {
+ 0x00, 0x47, 0xba, 0xb6, 0xca, 0x00, 0x53,
+ 0x00, 0xb5, 0xbb, 0xb3, 0xc6, 0x00, 0x65,
+ 0x00, 0xae, 0xb8, 0xb3, 0xc7, 0x00, 0x6c
+};
+
+static const unsigned int ld9040_22_110[] = {
+ 0x00, 0x13, 0xbb, 0xb7, 0xca, 0x00, 0x4f,
+ 0x00, 0xb4, 0xbb, 0xb3, 0xc7, 0x00, 0x60,
+ 0x00, 0xad, 0xb8, 0xb4, 0xc7, 0x00, 0x67
+};
+
+static const unsigned int ld9040_22_100[] = {
+ 0x00, 0x13, 0xba, 0xb8, 0xcb, 0x00, 0x4b,
+ 0x00, 0xb3, 0xbc, 0xb4, 0xc7, 0x00, 0x5c,
+ 0x00, 0xac, 0xb8, 0xb4, 0xc8, 0x00, 0x62
+};
+
+static const unsigned int ld9040_22_90[] = {
+ 0x00, 0x13, 0xb9, 0xb8, 0xcd, 0x00, 0x46,
+ 0x00, 0xb1, 0xbc, 0xb5, 0xc8, 0x00, 0x56,
+ 0x00, 0xaa, 0xb8, 0xb4, 0xc9, 0x00, 0x5d
+};
+
+static const unsigned int ld9040_22_80[] = {
+ 0x00, 0x13, 0xba, 0xb9, 0xcd, 0x00, 0x41,
+ 0x00, 0xb0, 0xbe, 0xb5, 0xc9, 0x00, 0x51,
+ 0x00, 0xa9, 0xb9, 0xb5, 0xca, 0x00, 0x57
+};
+
+static const unsigned int ld9040_22_70[] = {
+ 0x00, 0x13, 0xb9, 0xb9, 0xd0, 0x00, 0x3c,
+ 0x00, 0xaf, 0xbf, 0xb6, 0xcb, 0x00, 0x4b,
+ 0x00, 0xa8, 0xb9, 0xb5, 0xcc, 0x00, 0x52
+};
+
+static const unsigned int ld9040_22_50[] = {
+ 0x00, 0x13, 0xb2, 0xba, 0xd2, 0x00, 0x30,
+ 0x00, 0xaf, 0xc0, 0xb8, 0xcd, 0x00, 0x3d,
+ 0x00, 0xa8, 0xb8, 0xb7, 0xcd, 0x00, 0x44
+};
+
+struct ld9040_gamma {
+ unsigned int *gamma_22_table[MAX_GAMMA_LEVEL];
+};
+
+static struct ld9040_gamma gamma_table = {
+ .gamma_22_table[0] = (unsigned int *)&ld9040_22_50,
+ .gamma_22_table[1] = (unsigned int *)&ld9040_22_70,
+ .gamma_22_table[2] = (unsigned int *)&ld9040_22_80,
+ .gamma_22_table[3] = (unsigned int *)&ld9040_22_90,
+ .gamma_22_table[4] = (unsigned int *)&ld9040_22_100,
+ .gamma_22_table[5] = (unsigned int *)&ld9040_22_110,
+ .gamma_22_table[6] = (unsigned int *)&ld9040_22_120,
+ .gamma_22_table[7] = (unsigned int *)&ld9040_22_130,
+ .gamma_22_table[8] = (unsigned int *)&ld9040_22_140,
+ .gamma_22_table[9] = (unsigned int *)&ld9040_22_150,
+ .gamma_22_table[10] = (unsigned int *)&ld9040_22_160,
+ .gamma_22_table[11] = (unsigned int *)&ld9040_22_170,
+ .gamma_22_table[12] = (unsigned int *)&ld9040_22_180,
+ .gamma_22_table[13] = (unsigned int *)&ld9040_22_190,
+ .gamma_22_table[14] = (unsigned int *)&ld9040_22_200,
+ .gamma_22_table[15] = (unsigned int *)&ld9040_22_210,
+ .gamma_22_table[16] = (unsigned int *)&ld9040_22_220,
+ .gamma_22_table[17] = (unsigned int *)&ld9040_22_230,
+ .gamma_22_table[18] = (unsigned int *)&ld9040_22_240,
+ .gamma_22_table[19] = (unsigned int *)&ld9040_22_250,
+ .gamma_22_table[20] = (unsigned int *)&ld9040_22_260,
+ .gamma_22_table[21] = (unsigned int *)&ld9040_22_270,
+ .gamma_22_table[22] = (unsigned int *)&ld9040_22_280,
+ .gamma_22_table[23] = (unsigned int *)&ld9040_22_290,
+ .gamma_22_table[24] = (unsigned int *)&ld9040_22_300,
+};
+
+#endif
+
--
1.6.0.4
^ permalink raw reply related
* [GIT PULL] Samsung S5P for 2.6.38 merge window
From: Kukjin Kim @ 2011-01-13 5:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
Please pull Samsung S5P updates from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
for-rmk
These things are for 2.6.38.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit 387c31c7e5c9805b0aef8833d1731a5fe7bdea14
Linux 2.6.37-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
for-rmk
Abhilash Kesavan (3):
ARM: S5P64X0: Change GPIOlib initialization to core_initcall
ARM: S5P6440: Change the name for MMC Special Clock
ARM: S3C24XX: Add support UART3 for S3C2443 and S3C2416
Amit Daniel Kachhap (1):
ARM: SAMSUNG: Add support for clock debugging through debug-fs
interface
Atul Dahiya (1):
ARM: S5P64X0: Add clock support for RTC
Changhwan Youn (6):
ARM: S5PV310: Add Interrupt of MCT
ARM: S5PV310: Limit the irqs which support cascade interrupt
ARM: S5PV310: Add irq_mask to handle combiner irqs properly
ARM: SAMSUNG: Add support for Power Domain control
ARM: S5PV310: Set bit 22 in the PL310 (cache controller) AuxCtlr
register
ARM: S5PV310: Add support Power Domain
Darius Augulis (1):
serial: samsung: fix device name
Donguk Ryu (2):
ARM: S5P: Add Support System MMU
ARM: S5PV310: Add Support System MMU
Jaecheol Lee (1):
ARM: S5PV310: Add FOUT APLL get rate function
Jassi Brar (25):
ARM: S5PV310: Add platform devices for PL330 DMACs
ARM: SAMSUNG: Rename s3c64xx I2S platform device
ARM: SAMSUNG: Prepare audio header for new I2S driver
ARM: S3C64XX: Upgrade platform device for I2S
ARM: S5P64X0: Upgrade platform device for I2S
ARM: S5P6442: Upgrade platform device for I2S
ARM: S5PC100: Upgrade platform device for I2S
ARM: S5PV210: Upgrade platform device for I2S
ARM: S5PV310: Add audio platform devices
ARM: S5P6442: Implement i2c-gpio config
ARM: S5P6442: Enable I2C0 device on SMDK6442
ARM: S5P6450: Define clocks for I2S
ARM: S5P6450: Define base addresses for I2S
ARM: S5P6440: Enable I2S device to work on SMDK6440
ARM: S5P6450: Enable I2S device to work on SMDK6450
ARM: S5PV210: Enable I2S device to work on SMDKC110
ARM: S5PV210: Enable I2S device to work on SMDKV210
ARM: S5PV310: Enable I2C1 device
ARM: S5PV310: Add PDMA clocks
ARM: S5PV310: Add AC97 clock
ARM: S5PV310: Define I2S clocks
ARM: S5PV310: Add AC97 support for SMDK
ARM: S5PV310: Enable I2S device on SMDKV310
ARM: S5PV310: Enable I2S device on SMDKC210
ARM: S3C64XX: Clear DMA_HALT upon start
Kukjin Kim (26):
Merge branch 'next-samsung-asoc' into next-samsung-asoc2
ARM: S5P64X0: Add GPIOlib support for S5P6450
ARM: SAMSUNG: Cleanup GPIOlib adding 2bit chips
ARM: S5P64X0: Cleanup S5P64X0 GPIOlib adding 2bit chips
ARM: S5P64X0: Rename GPIOlib file to gpiolib.c
ARM: S5P: Move the SROM register definitions to plat-s5p
Merge branch 'next-samsung-asoc2' into for-next-new
Merge branch 'next-samsung' into for-next-new
Merge branch 'next-s5p' into for-next-new
Merge branch 'next-s5p64x0' into for-next-new
Merge branch 'next-s5pv210' into for-next-new
Merge branch 'dev/s5pv310-irq' into next-s5pv310
Merge branch 'next-s5pv310' into for-next
Merge branch 'dev/s5pv310-cpufreq' into next-s5pv310
Merge branch 'next-s5pv310' into for-next
Merge branch 'next-samsung-irq_data' into for-next
Merge branch 'next-s3c64xx' into for-next
ARM: S3C64XX: Tidy register and disable clock usage
ARM: S5P6440: Tidy register and disable clock usage
ARM: S5P6442: Tidy register and disable clock usage
ARM: S5P6450: Tidy register and disable clock usage
ARM: S5PC100: Tidy register and disable clock usage
ARM: S5PV210: Tidy init+disable clock usage and
s3c24xx_register_clocks cleanup
ARM: S5PV310: Tidy init+disable clock usage and
s3c24xx_register_clocks cleanup
Merge branch 'dev/cleanup-clocks' into for-next
Merge branch 'next-s3c24xx' into for-next
Kyungmin Park (1):
ARM: S5PV310: Universal SDHCI devices support
Lennert Buytenhek (3):
ARM: S3C24XX: irq_data conversion
ARM: S5P: irq_data conversion
ARM: SAMSUNG: some GENERIC_HARDIRQS_NO_DEPRECATED build fixes
Mark Brown (5):
ARM: SAMSUNG: Convert s3c_irqext_wake() to new irq_ interrupt methods
ARM: S3C64XX: Convert S3C64xx irq-eint to use new irq_ methods
ARM: S3C64XX: Use chip_data to store the shift for EINTs
ARM: SAMSUNG: Convert irq-uart to use new irq_ functions
ARM: SAMSUNG: Convert irq-vic-timer to irq_ functions
Rajeshwari Shinde (1):
ARM: S5P64X0: Segregate audio devices
Sangwook Ju (2):
ARM: S5PV310: Define missing CMU register for CPUFREQ
ARM: S5PV310: Update CPUFREQ
Sunyoung Kang (4):
ARM: S5PV310: Update CMU registers for CPUFREQ
ARM: S5PV310: Add DMC registers and map_desc
ARM: S5PV310: Add support CPUFREQ
ARM: S5PV310: Update Kconfig and Makefile for supporting CPUFREQ
Sylwester Nawrocki (3):
ARM: S5PV210: Add resource definitions for MIPI CSIS
ARM: S5PV310: Add resource definitions for MIPI CSIS
ARM: S5P: Add platform support for MIPI CSIS devices
Thomas Abraham (6):
ARM: S5PV210: Add frame buffer display support for SMDKV210
ARM: S5P: Add SROM control register shift macros for other banks.
ARM: S5P: Add SROM bank 4 and 5 register offsets
ARM: S5P: Move SROM controller IO mapping to plat-s5p for S5P SoCs
ARM: S5PV210: Add SROM controller clock
ARM: S5PV210: Add DM9000 support on SMDKV210
Yauhen Kharuzhy (5):
ARM: S3C24XX: Add address map and clock definitions for HSMMC0
ARM: S3C2416: Add platform helpers for setup SDHCI
ARM: S3C2416: Add support of SD/MMC card detect on SMDK2416
ARM: S3C2443: Implement GPIO pull-up/down configuration methods
ARM: SAMSUNG: Don't export __init functions to modules
arch/arm/Kconfig | 1 +
arch/arm/mach-s3c2410/bast-irq.c | 22 +-
arch/arm/mach-s3c2410/include/mach/irqs.h | 4 +-
arch/arm/mach-s3c2410/include/mach/map.h | 4 +-
.../mach-s3c2410/include/mach/regs-s3c2443-clock.h | 1 +
arch/arm/mach-s3c2412/irq.c | 50 +-
arch/arm/mach-s3c2416/Kconfig | 12 +
arch/arm/mach-s3c2416/Makefile | 4 +
arch/arm/mach-s3c2416/clock.c | 18 +-
arch/arm/mach-s3c2416/irq.c | 76 ++--
arch/arm/mach-s3c2416/mach-smdk2416.c | 23 +
arch/arm/mach-s3c2416/s3c2416.c | 5 +
arch/arm/mach-s3c2416/setup-sdhci-gpio.c | 34 ++
arch/arm/mach-s3c2416/setup-sdhci.c | 61 ++
arch/arm/mach-s3c2440/irq.c | 18 +-
arch/arm/mach-s3c2440/s3c244x-irq.c | 18 +-
arch/arm/mach-s3c2443/Kconfig | 3 +-
arch/arm/mach-s3c2443/clock.c | 4 +-
arch/arm/mach-s3c2443/irq.c | 95 ++--
arch/arm/mach-s3c2443/mach-smdk2443.c | 9 +-
arch/arm/mach-s3c2443/s3c2443.c | 7 +
arch/arm/mach-s3c64xx/clock.c | 21 +-
arch/arm/mach-s3c64xx/dev-audio.c | 60 ++-
arch/arm/mach-s3c64xx/dma.c | 1 +
arch/arm/mach-s3c64xx/irq-eint.c | 37 +-
arch/arm/mach-s5p6442/clock.c | 16 +-
arch/arm/mach-s5p6442/dev-audio.c | 44 ++-
arch/arm/mach-s5p6442/include/mach/map.h | 3 +
arch/arm/mach-s5p6442/mach-smdk6442.c | 10 +
arch/arm/mach-s5p6442/setup-i2c0.c | 5 +-
arch/arm/mach-s5p64x0/Makefile | 4 +-
arch/arm/mach-s5p64x0/clock-s5p6440.c | 24 +-
arch/arm/mach-s5p64x0/clock-s5p6450.c | 36 +-
arch/arm/mach-s5p64x0/dev-audio.c | 144 ++++-
arch/arm/mach-s5p64x0/{gpio.c => gpiolib.c} | 221 +++++++-
arch/arm/mach-s5p64x0/include/mach/map.h | 5 +
arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 57 +--
arch/arm/mach-s5p64x0/mach-smdk6440.c | 1 +
arch/arm/mach-s5p64x0/mach-smdk6450.c | 1 +
arch/arm/mach-s5pc100/clock.c | 16 +-
arch/arm/mach-s5pc100/dev-audio.c | 54 ++-
arch/arm/mach-s5pc100/include/mach/map.h | 2 +
arch/arm/mach-s5pv210/Kconfig | 2 +
arch/arm/mach-s5pv210/clock.c | 35 +-
arch/arm/mach-s5pv210/cpu.c | 5 -
arch/arm/mach-s5pv210/dev-audio.c | 56 ++-
arch/arm/mach-s5pv210/include/mach/irqs.h | 3 +-
arch/arm/mach-s5pv210/include/mach/map.h | 6 +
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 5 +-
arch/arm/mach-s5pv210/mach-smdkc110.c | 1 +
arch/arm/mach-s5pv210/mach-smdkv210.c | 139 +++++-
arch/arm/mach-s5pv310/Kconfig | 22 +
arch/arm/mach-s5pv310/Makefile | 7 +-
arch/arm/mach-s5pv310/clock.c | 77 ++-
arch/arm/mach-s5pv310/cpu.c | 21 +-
arch/arm/mach-s5pv310/cpufreq.c | 580
++++++++++++++++++++
arch/arm/mach-s5pv310/dev-audio.c | 364 ++++++++++++
arch/arm/mach-s5pv310/dev-pd.c | 139 +++++
arch/arm/mach-s5pv310/dev-sysmmu.c | 187 +++++++
arch/arm/mach-s5pv310/dma.c | 168 ++++++
arch/arm/mach-s5pv310/include/mach/dma.h | 26 +
arch/arm/mach-s5pv310/include/mach/irqs.h | 37 ++-
arch/arm/mach-s5pv310/include/mach/map.h | 50 ++
arch/arm/mach-s5pv310/include/mach/regs-clock.h | 80 +++-
arch/arm/mach-s5pv310/include/mach/regs-mem.h | 23 +
arch/arm/mach-s5pv310/include/mach/regs-pmu.h | 30 +
arch/arm/mach-s5pv310/include/mach/regs-srom.h | 50 --
arch/arm/mach-s5pv310/include/mach/regs-sysmmu.h | 24 +
arch/arm/mach-s5pv310/include/mach/sysmmu.h | 119 ++++
arch/arm/mach-s5pv310/irq-combiner.c | 32 +-
arch/arm/mach-s5pv310/irq-eint.c | 55 +-
arch/arm/mach-s5pv310/mach-smdkc210.c | 52 ++-
arch/arm/mach-s5pv310/mach-smdkv310.c | 52 ++-
arch/arm/mach-s5pv310/mach-universal_c210.c | 80 +++
arch/arm/plat-s3c24xx/devs.c | 1 -
arch/arm/plat-s3c24xx/include/plat/irq.h | 4 +-
arch/arm/plat-s3c24xx/irq-pm.c | 9 +-
arch/arm/plat-s3c24xx/irq.c | 182 +++----
arch/arm/plat-s3c24xx/s3c2443-clock.c | 2 +-
arch/arm/plat-s5p/Kconfig | 26 +
arch/arm/plat-s5p/Makefile | 3 +
arch/arm/plat-s5p/cpu.c | 5 +
arch/arm/plat-s5p/dev-csis0.c | 34 ++
arch/arm/plat-s5p/dev-csis1.c | 34 ++
arch/arm/plat-s5p/include/plat/csis.h | 28 +
arch/arm/plat-s5p/include/plat/map-s5p.h | 1 +
arch/arm/plat-s5p/include/plat/regs-srom.h | 54 ++
arch/arm/plat-s5p/include/plat/sysmmu.h | 23 +
arch/arm/plat-s5p/irq-eint.c | 86 ++--
arch/arm/plat-s5p/irq-gpioint.c | 50 +-
arch/arm/plat-s5p/irq-pm.c | 6 +-
arch/arm/plat-s5p/sysmmu.c | 328 +++++++++++
arch/arm/plat-samsung/Kconfig | 14 +
arch/arm/plat-samsung/Makefile | 4 +
arch/arm/plat-samsung/clock.c | 92 +++
arch/arm/plat-samsung/dev-nand.c | 2 -
arch/arm/plat-samsung/gpio-config.c | 42 ++
arch/arm/plat-samsung/gpiolib.c | 7 +
arch/arm/plat-samsung/include/plat/audio.h | 24 +
arch/arm/plat-samsung/include/plat/clock.h | 3 +
arch/arm/plat-samsung/include/plat/devs.h | 17 +
.../plat-samsung/include/plat/gpio-cfg-helpers.h | 2 +-
arch/arm/plat-samsung/include/plat/gpio-core.h | 2 +
arch/arm/plat-samsung/include/plat/pd.h | 30 +
arch/arm/plat-samsung/include/plat/pm.h | 4 +-
arch/arm/plat-samsung/include/plat/sdhci.h | 35 ++
arch/arm/plat-samsung/irq-uart.c | 40 +-
arch/arm/plat-samsung/irq-vic-timer.c | 26 +-
arch/arm/plat-samsung/pd.c | 95 ++++
arch/arm/plat-samsung/pm.c | 6 +-
drivers/serial/samsung.c | 4 +-
111 files changed, 4277 insertions(+), 806 deletions(-)
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Alexander Holler @ 2011-01-13 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112184258.GH11039@n2100.arm.linux.org.uk>
Hello,
Am 12.01.2011 19:42, schrieb Russell King - ARM Linux:
> As the overall feeling at the time was "don't use large initrds" it's
> something I've never really cared about - and I'm still of the opinion
> that 16MB of compressed initrd/initramfs is rather silly.
Hmm, sorry, I have to disagree. ;)
E.g. 12MB out of the 16MB in the initramfs I've used are modules.
I've also created some larger initramfs wich included X11 and such, and
I find it very convenient to use the initramfs to include a rootfs in
the the kernel and so only have to handle one file for all. E.g. just
load the kernel with the included rootfs via tftp and you are done.
Sure this can all be done using an external initrd, but that is much
less comfortable to use.
At least I like that feature since it is available and won't miss it now. ;)
Regards,
Alexander
^ permalink raw reply
* Warning from might_sleep() in SWI handler
From: TAO HU @ 2011-01-13 6:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi, All
We're getting kernel run on OMAP4430 chip (ARMv7, dual core), and got an
unexpected warning by might_sleep() function. While that happened,
we're performing system test which almost consumed all system memory.
Based on log below, might_sleep() threw out an unexpected warning
in page fault exception triggered by short of memory while calling
system call (by SWI exception). This should be a normal scenario, but,
kernel doesn't seem to handle it fine. ?Any thoughts ?
log:
<6>[35377.073242] request_suspend_state: wakeup (0->0) at
32812699437166 (2010-12-29 19:08:41.273678467 UTC)
<6>[35379.468200] input: sensors as /devices/virtual/input/input9
<6>[35380.344421] usb_ether_get_stats
<6>[35380.362335] usb_ether_get_stats
<6>[35380.399444] usb_ether_get_stats
<6>[35380.417022] usb_ether_get_stats
<6>[35380.618469] usb_ether_get_stats
<3>[35391.279327] init: untracked pid 25171 exited
<4>[35393.306610] events/0: page allocation failure. order:1, mode:0x20
<4>[35393.313140] [<c004b7a0>] (unwind_backtrace+0x0/0xf0) from
[<c00f2df8>] (__alloc_pages_nodemask+0x568/0x6e8)
<4>[35393.323455] [<c00f2df8>] (__alloc_pages_nodemask+0x568/0x6e8)
from [<c0117a64>] (cache_grow.clone.0+0xac/0x3e8)
<4>[35393.334167] [<c0117a64>] (cache_grow.clone.0+0xac/0x3e8) from
[<c011a0a0>] (__kmalloc_track_caller+0x3f4/0x6cc)
<4>[35393.344848] [<c011a0a0>] (__kmalloc_track_caller+0x3f4/0x6cc)
from [<c0373264>] (__alloc_skb+0x50/0xe0)
<4>[35393.354827] [<c0373264>] (__alloc_skb+0x50/0xe0) from
[<bf030020>] (st_int_recv+0x370/0x48c [st_drv])
<4>[35393.364593] [<bf030020>] (st_int_recv+0x370/0x48c [st_drv]) from
[<bf02f018>] (st_tty_receive+0x18/0x20 [st_drv])
<4>[35393.375488] [<bf02f018>] (st_tty_receive+0x18/0x20 [st_drv])
from [<c0240ae0>] (flush_to_ldisc+0xe0/0x180)
<4>[35393.385711] [<c0240ae0>] (flush_to_ldisc+0xe0/0x180) from
[<c00a4cac>] (worker_thread+0x1e4/0x278)
<4>[35393.395202] [<c00a4cac>] (worker_thread+0x1e4/0x278) from
[<c00a8ab0>] (kthread+0x78/0x80)
<4>[35393.403961] [<c00a8ab0>] (kthread+0x78/0x80) from [<c00462cc>]
(kernel_thread_exit+0x0/0x8)
<4>[35393.412811] Mem-info:
<4>[35393.415222] Normal per-cpu:
<4>[35393.418182] CPU??? 0: hi:? 186, btch:? 31 usd:?? 5
<4>[35393.423248] CPU??? 1: hi:? 186, btch:? 31 usd:? 91
<4>[35393.428314] active_anon:15917 inactive_anon:15771 isolated_anon:1
<4>[35393.428314]? active_file:5235 inactive_file:7587 isolated_file:0
<4>[35393.428344]? unevictable:50762 dirty:56 writeback:0 unstable:0
<4>[35393.428344]? free:1037 slab_reclaimable:1224 slab_unreclaimable:3021
<4>[35393.428344]? mapped:12461 shmem:93 pagetables:3545 bounce:0
<4>[35393.459930] Normal free:4148kB min:2848kB low:3560kB high:4272kB
active_anon:63668kB inactive_anon:63084kB active_file:20940kB
inactive_file:30348kB unevictable:203048kB isolated(anon):4kB
isolated(file):0kB present:508000kB mlocked:0kB dirty:224kB
writeback:0kB mapped:49844kB shmem:372kB slab_reclaimable:4896kB
slab_unreclaimable:12084kB kernel_stack:3664kB pagetables:14180kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
all_unreclaimable? no
<4>[35393.502685] lowmem_reserve[]: 0 0 0
<4>[35393.506378] Normal: 1037*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4148kB
<4>[35393.517517] 63672 total pagecache pages
<4>[35393.521545] 0 pages in swap cache
<4>[35393.525054] Swap cache stats: add 0, delete 0, find 0/0
<4>[35393.530578] Free swap? = 0kB
<4>[35393.533630] Total swap = 0kB
<4>[35393.555419] 128000 pages of RAM
<4>[35393.558746] 1790 free pages
<4>[35393.561676] 17305 reserved pages
<4>[35393.565093] 4254 slab pages
<4>[35393.568054] 127057 pages shared
<4>[35393.571350] 0 pages swap cached
<3>[35393.596527] (stc): Can't allocate mem for new packet
<3>[35398.317199] hci_cmd_task: hci0 command tx timeout
<3>[35403.916595] BUG: sleeping function called from invalid context
at /Volumes/data/hudson/workspace/integrated_device-cdma-solana-eng_main-dev_linux_continuous/platform/kernel/omap4/arch/arm/mm/fault.c:295
<3>[35403.935455] in_atomic(): 0, irqs_disabled(): 128, pid: 25390,
name: Thread-9
<4>[35403.942901] [<c004b7a0>] (unwind_backtrace+0x0/0xf0) from
[<c007eb24>] (__might_sleep+0x11c/0x148)
<4>[35403.952301] [<c007eb24>] (__might_sleep+0x11c/0x148) from
[<c004eccc>] (do_page_fault+0xa8/0x2e8)
<4>[35403.961608] [<c004eccc>] (do_page_fault+0xa8/0x2e8) from
[<c0044488>] (do_DataAbort+0x34/0xa8)
<4>[35403.970642] [<c0044488>] (do_DataAbort+0x34/0xa8) from
[<c0044bec>] (__dabt_svc+0x4c/0x60)
<4>[35403.979309] Exception stack(0xd1b79f68 to 0xd1b79fb0)
<4>[35403.984588] 9f60:?????????????????? 4624d868 00020241 00000180
4847ba4c 00000241 00228e58
<4>[35403.993164] 9f80: 00000180 00000005 20000010 43c66d8c 43c66d74
46251a60 ad12e228 d1b79fb0
<4>[35404.001739] 9fa0: afd0da0c c0045228 60000093 ffffffff
<4>[35404.007019] [<c0044bec>] (__dabt_svc+0x4c/0x60) from
[<c0045228>] (vector_swi+0x28/0x88)
--
Best Regards
Hu Tao
^ permalink raw reply
* [PATCHv8 00/12] Contiguous Memory Allocator
From: Marek Szyprowski @ 2011-01-13 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101121357580.25498@xanadu.home>
Hello,
On Wednesday, January 12, 2011 8:04 PM Nicolas Pitre wrote:
> On Wed, 12 Jan 2011, Marek Szyprowski wrote:
>
> > I understand that modifying L1 page tables is definitely not a proper way of
> > handling this. It simply costs too much. But what if we consider that the DMA
> > memory can be only allocated from a specific range of the system memory?
> > Assuming that this range of memory is known during the boot time, it CAN be
> > mapped with two-level of tables in MMU. First level mapping will stay the
> > same all the time for all processes, but it would be possible to unmap the
> > pages required for DMA from the second level mapping what will be visible
> > from all the processes at once.
>
> How much memory are we talking about? What is the typical figure?
One typical scenario we would like to support is full-hd decoding. One frame is
about 4MB (1920x1080x2 ~= 4MB). Depending on the codec, it may require up to 15
buffers what gives about 60MB. This simple calculation does not include memory
for the framebuffer, temporary buffers for the hardware codec and buffers for
the stream.
> > Is there any reason why such solution won't work?
>
> It could work indeed.
>
> One similar solution that is already in place is to use highmem for that
> reclaimable DMA memory. It is easy to ensure affected highmem pages are
> not mapped in kernel space. And you can decide at boot time how many
> highmem pages you want even if the system has less that 1GB of RAM.
Hmmm, right, this might also help solving the problem.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Uwe Kleine-König @ 2011-01-13 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101122344500.2678@localhost6.localdomain6>
Hi Nick,
On Wed, Jan 12, 2011 at 11:52:01PM +0100, Thomas Gleixner wrote:
> On Wed, 12 Jan 2011, Uwe Kleine-K?nig wrote:
> > > Reverting: fs: rcu-walk aware d_revalidate method
> > > commit: 34286d6662308d82aed891852d04c7c3a2649b16
> > I found that one, too, in the meantime. Currently debugging that with
> > tglx on irc.
>
> The last finding is that parent and dentry in
> nameidata_dentry_drop_rcu() are the same, which explains the lock
> recursion nicely.
>
> @nick: Anything you want us to add to the debugging ?
If that helps, the chdir is to / (probably while being already in /).
Maybe the problem is that "/." == "/.."?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* i.MX & IRQF_ONESHOT
From: Eric Bénard @ 2011-01-13 8:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
while testing 2.6.37 on our i.MX27 based board - code in
arch/arm/mach-imx/eukrea_mbimx27-baseboard.c - I noticed the touchscreen
controller (ADS7846) doesn't work anymore.
A few IRQ are generated when probing for the chipset and starting calibration
(usually first point works), then nothing more (even if the IRQ signals is
generated as seen on the scope, the irq count doesn't increase anymore and
stays <= 4 and no data is reported to the input layer).
drivers/input/touchscreen/ads7846.c was switched to threaded IRQ in commit
2991a1ca6e9b13b639a82c0eec0cbc191bf1f42f where was added :
irq_flags |= IRQF_ONESHOT;
Commenting out this line in the ads7846 driver makes it work again.
Am I missing something obvious or is there a reason for IRQF_ONESHOT creating
trouble with gpio irq or SPI on i.MX ?
Thanks
Eric
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with system mmu.
From: Jonghun Han @ 2011-01-13 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111173509.GB14017@dumpdata.com>
Sorry for late reply.
Samsung SoC C210 has many multimedia IPs.
Each IP has its own MMU named SYSTEM MMU like CPU's MMU.
So it can handle discontiguous memory using device own virtual address.
What Inki Dae wants to discuss is how to allocate the memory and how to
share it with other multimedia IPs.
Thank you for interesting.
Best regards,
> -----Original Message-----
> From: linux-fbdev-owner at vger.kernel.org [mailto:linux-fbdev-
> owner at vger.kernel.org] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Wednesday, January 12, 2011 2:35 AM
> To: Jonghun Han
> Cc: 'InKi Dae'; linux-media at vger.kernel.org;
linux-arm-kernel at lists.infradead.org;
> 'linux-fbdev'; kyungmin.park at samsung.com
> Subject: Re: Memory sharing issue by application on V4L2 based device
driver
> with system mmu.
>
>
> .. snip..
> > But 64KB or 1MB physically contiguous memory is better than 4KB page
> > in the point of performance.
>
> Could you explain that in more details please? I presume you are talking
about a
> CPU that has a MMU unit, right?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Anand Gadiyar @ 2011-01-13 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111231611.GX4957@atomide.com>
Tony Lindgren wrote:
> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren <tony@atomide.com>
> Date: Tue Jan 11 15:03:03 2011 -0800
>
> omap4: Fix ULPI PHY init for ES1.0 SDP
>
> Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
> enable the ehci port on 4430SDP) added code to enable EHCI
> support on 4430sdp board.
>
> Looks like the ULPI pin does not seem to be muxed properly on ES1.0
> SDP and this causes the system to reboot when the ULPI PHY is
> enabled.
>
> Fix this by muxing the pin, this is the same setting for
> both ES1.0 and ES2.0. Also add checking for gpio_request.
>
> Cc: Keshava Munegowda <keshava_mgowda@ti.com
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
>
> #ifdef CONFIG_OMAP_MUX
> static struct omap_board_mux board_mux[] __initdata = {
> + OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
> #else
> @@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
> omap4_twl6030_hsmmc_init(mmc);
>
> /* Power on the ULPI PHY */
> - if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> - /* FIXME: Assumes pad is already muxed for GPIO mode */
> - gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
VMDM_3V3");
> + status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
VMDM_3V3");
> + if (status)
> + pr_err("%s: Could not get USBB1 PHY GPIO\n");
Tony,
This throws up a build warning as there's no parameter corresponding to
the %s. Showed up in linux-next as of today.
- Anand
^ permalink raw reply
* [PATCH] unbreak ehci-mxc on otg port of i.MX27
From: Eric Bénard @ 2011-01-13 9:06 UTC (permalink / raw)
To: linux-arm-kernel
commit 711669e5b80b6f2d88f61ed8a9681f83d8cbd201 fixed port 0 support
for i.MX51 but broke it for (at least) i.MX27 which doesn't have
a usb_phy1 clock but has a pdev->id 0.
Signed-off-by: Eric B?nard <eric@eukrea.com>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/usb/host/ehci-mxc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index fa59b26..18eb597 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -178,7 +178,7 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
}
/* "dr" device has its own clock */
- if (pdev->id == 0) {
+ if ((cpu_is_mx51()) & (pdev->id == 0)) {
priv->phy1clk = clk_get(dev, "usb_phy1");
if (IS_ERR(priv->phy1clk)) {
ret = PTR_ERR(priv->phy1clk);
--
1.7.3.4
^ permalink raw reply related
* Warning from might_sleep() in SWI handler
From: Russell King - ARM Linux @ 2011-01-13 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=gakqH9i5m6CjKd__LHSZwFoaEOLAim0Wsehk2@mail.gmail.com>
On Thu, Jan 13, 2011 at 02:34:39PM +0800, TAO HU wrote:
> <3>[35403.916595] BUG: sleeping function called from invalid context
> at /Volumes/data/hudson/workspace/integrated_device-cdma-solana-eng_main-dev_linux_continuous/platform/kernel/omap4/arch/arm/mm/fault.c:295
> <3>[35403.935455] in_atomic(): 0, irqs_disabled(): 128, pid: 25390,
> name: Thread-9
> <4>[35403.942901] [<c004b7a0>] (unwind_backtrace+0x0/0xf0) from
> [<c007eb24>] (__might_sleep+0x11c/0x148)
> <4>[35403.952301] [<c007eb24>] (__might_sleep+0x11c/0x148) from
> [<c004eccc>] (do_page_fault+0xa8/0x2e8)
> <4>[35403.961608] [<c004eccc>] (do_page_fault+0xa8/0x2e8) from
> [<c0044488>] (do_DataAbort+0x34/0xa8)
> <4>[35403.970642] [<c0044488>] (do_DataAbort+0x34/0xa8) from
> [<c0044bec>] (__dabt_svc+0x4c/0x60)
> <4>[35403.979309] Exception stack(0xd1b79f68 to 0xd1b79fb0)
> <4>[35403.984588] 9f60:?????????????????? 4624d868 00020241 00000180
> 4847ba4c 00000241 00228e58
> <4>[35403.993164] 9f80: 00000180 00000005 20000010 43c66d8c 43c66d74
> 46251a60 ad12e228 d1b79fb0
> <4>[35404.001739] 9fa0: afd0da0c c0045228 60000093 ffffffff
> <4>[35404.007019] [<c0044bec>] (__dabt_svc+0x4c/0x60) from
> [<c0045228>] (vector_swi+0x28/0x88)
It would be nice if the trace continued beyond this point.
It looks like userspace tried to execute an instruction at 0xafd0da0c,
and it was available to the instruction stream (which knew it as a SWI
instruction) but not the data stream.
I guess we have a race in the swap-out code on SMP:
CPU0 CPU1
clears pte
executes instruction from page,
already has I-TLB but no D-TLB entry,
takes SWI exception
tries to load instruction, data abort
tlb flush
This isn't trivial to resolve... In the meantime, the workaround is to
disable OABI compatibility.
^ permalink raw reply
* [PATCH] unbreak ehci-mxc on otg port of i.MX27
From: Sascha Hauer @ 2011-01-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294909575-32709-1-git-send-email-eric@eukrea.com>
On Thu, Jan 13, 2011 at 10:06:15AM +0100, Eric B?nard wrote:
> commit 711669e5b80b6f2d88f61ed8a9681f83d8cbd201 fixed port 0 support
> for i.MX51 but broke it for (at least) i.MX27 which doesn't have
> a usb_phy1 clock but has a pdev->id 0.
Shame on me for not reviewing the patch properly :(
>
> Signed-off-by: Eric B?nard <eric@eukrea.com>
> Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/usb/host/ehci-mxc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
> index fa59b26..18eb597 100644
> --- a/drivers/usb/host/ehci-mxc.c
> +++ b/drivers/usb/host/ehci-mxc.c
> @@ -178,7 +178,7 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
> }
>
> /* "dr" device has its own clock */
> - if (pdev->id == 0) {
> + if ((cpu_is_mx51()) & (pdev->id == 0)) {
should be && and please remove the unnecessary braces around
cpu_is_mx51(). Otherwise ok.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* No subject
From: Uwe Kleine-König @ 2011-01-13 9:13 UTC (permalink / raw)
To: linux-arm-kernel
<jason77.wang@gmail.com>
Bcc:
Subject: Re: i.MX & IRQF_ONESHOT
Reply-To:
In-Reply-To: <4D2EB6EF.7030608@eukrea.com>
Hello,
[adding tglx who AFAIK invented threaded irqs and the people involved
in 2991a1ca6e9b to Cc]
On Thu, Jan 13, 2011 at 09:25:19AM +0100, Eric B?nard wrote:
> while testing 2.6.37 on our i.MX27 based board - code in
> arch/arm/mach-imx/eukrea_mbimx27-baseboard.c - I noticed the
> touchscreen controller (ADS7846) doesn't work anymore.
>
> A few IRQ are generated when probing for the chipset and starting
> calibration (usually first point works), then nothing more (even if
> the IRQ signals is generated as seen on the scope, the irq count
> doesn't increase anymore and stays <= 4 and no data is reported to
> the input layer).
>
> drivers/input/touchscreen/ads7846.c was switched to threaded IRQ in
> commit 2991a1ca6e9b13b639a82c0eec0cbc191bf1f42f where was added :
> irq_flags |= IRQF_ONESHOT;
AFAIK this is how threaded irq usually work. The irq should get
reenabled by irq_thread -> irq_finalize_oneshot then.
> Commenting out this line in the ads7846 driver makes it work again.
> Am I missing something obvious or is there a reason for IRQF_ONESHOT
> creating trouble with gpio irq or SPI on i.MX ?
I don't know. Is the irq masked? pending?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Russell King - ARM Linux @ 2011-01-13 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f1a86cfda277de8d190e5eb9b9ccd77@mail.gmail.com>
On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> Tony Lindgren wrote:
> > /* Power on the ULPI PHY */
> > - if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> > - /* FIXME: Assumes pad is already muxed for GPIO mode */
> > - gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> VMDM_3V3");
> > + status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> VMDM_3V3");
> > + if (status)
> > + pr_err("%s: Could not get USBB1 PHY GPIO\n");
>
> Tony,
>
> This throws up a build warning as there's no parameter corresponding to
> the %s. Showed up in linux-next as of today.
It's pretty obvious that the above is wrong, and the compiler would
have caught it with a warning when building it. Was the above patch
not build-tested before it was committed?
Given the very sorry state of OMAP in mainline at present, I'm surprised
that this kind of stuff is still going on...
^ permalink raw reply
* [PATCH] unbreak ehci-mxc on otg port of i.MX27
From: Eric Bénard @ 2011-01-13 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113091229.GE12078@pengutronix.de>
Hi Sascha,
On 13/01/2011 10:12, Sascha Hauer wrote:
>>
>> /* "dr" device has its own clock */
>> - if (pdev->id == 0) {
>> + if ((cpu_is_mx51())& (pdev->id == 0)) {
>
> should be&& and please remove the unnecessary braces around
> cpu_is_mx51(). Otherwise ok.
>
shame on me for the &, a wrong copy and paste from my working tree removed the
second one, While I'm here does MX53 or MX50 need this ?
Eric
^ permalink raw reply
* mmaping a fixed address fails on ARM
From: Mikael Pettersson @ 2011-01-13 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim1MOB+r1shuJDvqJexerFo3wQ_o1wQpiaALW=0@mail.gmail.com>
Bryan Wu writes:
> Let me add Andre here
>
> Thanks,
> -Bryan
>
> On Thu, Jan 13, 2011 at 5:58 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
> > Hi Russell,
> >
> > Andre posted a mmap testcase [1] and a bug report [2] for Ubuntu
> > kernel on OMAP4 system, since he is porting some applications from x86
> > to ARM. He testcase works fine on x86, but always fail on ARM. I've
> > tested it on OMAP3/OMAP4/i.MX51.
> >
> > Basically what he want to do is get a mapping on a specific virtual
> > address. But AFAIK, mmap doesn't make sure we can get the mapping
> > address as we want. On x86, it works fine. So if this fails, the
> > application can't run on ARM.
> >
> > The implementation of arch_get_unmapped_area() is different from ARM
> > and x86, that might makes mmap behavior different between ARM and x86.
> > Andre said 2.6.28-versatile. I'm not sure whether it is a regression.
> >
> > [1]: http://launchpadlibrarian.net/61588086/main.c
> > [2]: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/697004
mmap() with a non-NULL hint referring to a currently unmapped area,
but without MAP_FIXED, isn't even remotely portable or reliable
(I've tried it myself in the context of JITs). It may work on
Linux/x86, but that doesn't allow you to assume it should work
on other OS/CPU combinations (and I know of several where it
emphatically doesn't work).
If you want a fixed address then use MAP_FIXED. If you don't want
MAP_FIXED to clobber an existing mapping then you have to keep track
of existing mappings yourself and avoid them.
What is that "some application"?
/Mikael
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Russell King - ARM Linux @ 2011-01-13 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2E928D.9030208@ahsoftware.de>
On Thu, Jan 13, 2011 at 06:50:05AM +0100, Alexander Holler wrote:
> Hello,
>
> Am 12.01.2011 19:42, schrieb Russell King - ARM Linux:
>
>> As the overall feeling at the time was "don't use large initrds" it's
>> something I've never really cared about - and I'm still of the opinion
>> that 16MB of compressed initrd/initramfs is rather silly.
>
> Hmm, sorry, I have to disagree. ;)
> E.g. 12MB out of the 16MB in the initramfs I've used are modules.
> I've also created some larger initramfs wich included X11 and such, and
> I find it very convenient to use the initramfs to include a rootfs in
> the the kernel and so only have to handle one file for all. E.g. just
> load the kernel with the included rootfs via tftp and you are done.
Oddly, that's why I wrote the bootp wrapper, which predates the
currently broken initrd-in-kernel idea.
> Sure this can all be done using an external initrd, but that is much
> less comfortable to use.
>
> At least I like that feature since it is available and won't miss it now. ;)
The feature isn't available if it doesn't work. It's not going to get
fixed for 2.6.38 - it'll be 2.6.39 due to the timing and complexity of
the problem.
^ permalink raw reply
* [RFC] Make SMP secondary CPU up more resilient to failure.
From: Andrei Warkentin @ 2011-01-13 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101224173824.GI20587@n2100.arm.linux.org.uk>
On Fri, Dec 24, 2010 at 11:38 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> On Tue, Dec 21, 2010 at 03:53:46PM -0600, Andrei Warkentin wrote:
> > Russel,
>
> Grr.
>
> > Thank you! The culprit looks as it seems to be the writel without
> > __iowmb, as you pointed out. At the very least I've yet to hit the
> > problem again this way.
>
> Good news.
>
> > I still want to add code inside the platform SMP support as a safety
> > net. Maybe I am being too pedantic, but ?In the near future (with
> > those 40 patches), secondaries are going to boot directly via
> > secondary_startup as well, so the first time platform-specific code
> > gets invoked is platform_secondary_init. I want to ensure that when
> > boot_secondary returns, the CPU is either guaranteed to be running or
> > for-sure dead. The problem is that platform_secondary_init is already
> > too late - if the CPU gets killed due to timeout anytime between the
> > entry to secondary_start_kernel and ?platform_secondary_init, it could
> > have already increased the refcount on init_mm or disabled preemption.
>
> Here's a problem for you to ponder on over Christmas.
>
> Let's say the secondary CPU is running slowly due to system load. ?It
> makes it through to secondary_start_kernel(), and calls through to
> your preinit function. ?It checks that it should be booting, and
> passes that test.
>
> At this point, the requesting CPU times out, but gets preempted to
> other tasks (which could very well happen on a heavily loaded system
> with preempt enabled).
>
> The booting CPU signals that via writing the reset vector, and continues
> on to increment the mm_count and switch its page tables.
My goal was for the preinit to run explicitely before the mm_count is
incremented. The cpu
sits (spins) inside the preinit until it is either told to continue
with the init (thus the synchronized CPU knows it succeeded), or it
sits there spinning inside the preinit until it gets killed due to a
timeout. Since I think the "side effects" only start after the
mm_count is incremented, I thought right before would be a good place.
>
> The requesting CPU finally switches back to the thread requesting
> that the CPU be brought up. ?It decides as it timed out to kill the
> booting CPU, and does so.
I should have made this clearer in my email when I said 'synchronize',
but if the timeout ever occurs it means two things -
1) CPU is dead or someplace before secondary_start_kernel
2) CPU is about to enter/entering preinit
3) CPU is already spinning inside preinit waiting to be allowed to
continue. It hasn't incremented mm_count, switched pts, or done
anything else that affects global kernel state.
In either case, it can be torn down (by say, fiddling with the power/reset).
If the timeout doesn't occur, then the requesting cpu will allow the
secondary to quit spinning inside the preinit.
>
> What this means that we now have exactly the same scenario you've
> referred to above, and adding the pre-init function hasn't really
> solved anything.
>
> I _really_ don't want platforms to start playing these games, because
> we'll end up with lots of different attempts to solve the problem,
> each of them probably racy like the above. ?The safest solution is to
> use a longer timeout - maybe an excessively long timeout - to guarantee
> that we never miss a starting CPU.
>
> If we do end up needing something like this in the kernel, then it needs
> to be done carefully and in generic code where it can be done properly
> once. ?(If any bugs are found in it, we've also only one version to fix,
> not five or six different versions.)
I fully agree. Would you be interested in me bringing back the actual
synchronization code from platform-dependent code into the preinit
function and posting that as a patch for review?
?However, I'd argue that it's better
> to wait longer for the CPU to come up if there's a possibility that it
> will rather than trying to sort out the mess from a partially booted
> secondary CPU.
Fair enough, I suppose that does make any platform bugs in smp path
more immediately obvious :)
^ 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