Re: [PATCH 3/4] omap: move detection of NAND CS to common-board-devices
* Mike Rapoport [110504 09:35]: > On 05/04/11 07:10, Oleg Drokin wrote: > > Ok, so here's a simple patch to save everyone trouble, I guess. > > > > Though on the other hand I can imagine that perhaps including this generic > > common-board-devices.c > > might not be desirable for people that don't use anything from that file. > > Since the common-board-devices.c has TWL initialization I doubt there would a > board that does not use it at all... > > > Would it be a better idea to split it to a file-per-feature? > > Splitting the common-board-devices into a file-per-feature will diminish its > added value, IMO. > We can either continue to use #ifdef CONFIG_SOMETHING in both > common-board-devices.[ch] as your fix proposes or just drop #ifdefs and > inlines > from the header. > Tony, what is your preference? We should consider the code size too.. Maybe see if you can make them weak instead of the ifdefs? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] omap: move detection of NAND CS to common-board-devices
On 05/04/11 07:10, Oleg Drokin wrote: > Ok, so here's a simple patch to save everyone trouble, I guess. > > Though on the other hand I can imagine that perhaps including this generic > common-board-devices.c > might not be desirable for people that don't use anything from that file. Since the common-board-devices.c has TWL initialization I doubt there would a board that does not use it at all... > Would it be a better idea to split it to a file-per-feature? Splitting the common-board-devices into a file-per-feature will diminish its added value, IMO. We can either continue to use #ifdef CONFIG_SOMETHING in both common-board-devices.[ch] as your fix proposes or just drop #ifdefs and inlines from the header. Tony, what is your preference? -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Linus Walleij [110504 00:37]: > 2011/5/3 Kevin Hilman : > > > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) > > into drivers/gpio first, followed by the cleanup/restructure patches? > > In my case I actually did some cleanup after moving the driver for > U300, but I think this is a question to the GPIO maintainer who > I want to ACK this stuff in the end. > > Grant? > > You can always squash it later ... Personally I would prefer absolutely minimal clean-up of current code before moving to drivers/gpio to cut down the "crazy churn" in arch/arm/. Also then further changes are easier for the GPIO maintainers to review. Of course I understand that this might cause extra load for the GPIO maintainers, so it's up to the GPIO maintainers to set the required standards before accepting the code into drivers/gpio. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v5] twl4030-madc driver
On Wed, May 4, 2011 at 9:41 AM, Steve Sakoman wrote: > On Tue, May 3, 2011 at 12:49 PM, J, KEERTHY wrote: >> Hello Steve, >> >> Can you try adding this patch? > > Thanks! > > I tried the patch and it did indeed fix the issue. We should try to > get this in mainline since the hwmon driver won't work without it. > Yes Steve. I am posting a patch today. > Steve > -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v5] twl4030-madc driver
On Tue, May 3, 2011 at 12:49 PM, J, KEERTHY wrote: > Hello Steve, > > Can you try adding this patch? Thanks! I tried the patch and it did indeed fix the issue. We should try to get this in mainline since the hwmon driver won't work without it. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] omap: move detection of NAND CS to common-board-devices
Ok, so here's a simple patch to save everyone trouble, I guess. Though on the other hand I can imagine that perhaps including this generic common-board-devices.c might not be desirable for people that don't use anything from that file. Would it be a better idea to split it to a file-per-feature? compile-fix.diff Description: Binary data
Re: [PATCH 3/4] omap: move detection of NAND CS to common-board-devices
Hello!
This patch breaks compile for me:
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
> --- a/arch/arm/mach-omap2/common-board-devices.c
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -29,6 +29,7 @@
...
> +void __init omap_nand_flash_init(int options, struct mtd_partition *parts,
> + int nr_parts)
> +{
...
> +}
> diff --git a/arch/arm/mach-omap2/common-board-devices.h
> b/arch/arm/mach-omap2/common-board-devices.h
> index 0ec3e07..ca03abf 100644
> --- a/arch/arm/mach-omap2/common-board-devices.h
> +++ b/arch/arm/mach-omap2/common-board-devices.h
> @@ -39,4 +40,13 @@ static inline void omap_ads7846_init(int bus_num,
> }
> #endif
>
> +#if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
> +void omap_nand_flash_init(int opts, struct mtd_partition *parts, int
> n_parts);
> +#else
> +static inline void omap_nand_flash_init(int opts, struct mtd_partition
> *parts,
> + int nr_parts)
> +{
> +}
arch/arm/mach-omap2/common-board-devices.c:113: error: redefinition of
'omap_nand_flash_init'
arch/arm/mach-omap2/common-board-devices.h:46: note: previous definition of
'omap_nand_flash_init' was here
I don't have CONFIG_MTD_NAND_OMAP2 defined of course as there is no NAND flash
on my board.
Bye,
Oleg
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] omap: consolidate touch screen initialization among different boards
Hello!
This patch breaks compile for me.
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
> --- /dev/null
> +++ b/arch/arm/mach-omap2/common-board-devices.c
> @@ -0,0 +1,85 @@
>
> +void __init omap_ads7846_init(int bus_num, int gpio_pendown, int
> gpio_debounce,
> + struct ads7846_platform_data *board_pdata)
> +{
> ...
> +}
> diff --git a/arch/arm/mach-omap2/common-board-devices.h
> b/arch/arm/mach-omap2/common-board-devices.h
> new file mode 100644
> index 000..75f9248d
> --- /dev/null
> +++ b/arch/arm/mach-omap2/common-board-devices.h
> @@ -0,0 +1,18 @@
> +#ifndef __OMAP_COMMON_BOARD_DEVICES__
> +#define __OMAP_COMMON_BOARD_DEVICES__
> +
> +#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
> + defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
> +struct ads7846_platform_data;
> +
> +void omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
> +struct ads7846_platform_data *board_pdata);
> +#else
arch/arm/mach-omap2/common-board-devices.c:80: error: redefinition of
'omap_ads7846_init'
arch/arm/mach-omap2/common-board-devices.h:36: note: previous definition of
'omap_ads7846_init' was here
Of course I don't have the CONFIG_TOUCHSCREEN_ADS7846 defined.
Bye,
Oleg--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] OMAP: GPIO: cleanup, consolidation, etc. (v2)
Hi Charu, "Varadarajan, Charulatha" writes: > I tested the patch series in wip/gpio-cleanup branch. Thanks so much for testing. It's a great help. I've updated the branch based on some of your comments, and in particular it should now boot on OMAP1. Kevin > Here are the results: > > Compile tested for: > - omap1_defconfig > - omap2plus_defconfig > > Boot test (Failed on the following board): > - OMAP1710-H3 > > Boot test (Success on the following boards): > - OMAP2420-H4 > - OMAP3430-SDP > - OMAP3430-Zoom2 > - OMAP3630-Zoom3 > - OMAP4430-SDP > - OMAP4430-Blaze > > GPIO module functionality testing (success on the following boards): > - OMAP2420-H4 > - OMAP3430-SDP > - OMAP3430-Zoom2 > - OMAP3630-Zoom3 > - OMAP4430-SDP > - OMAP4430-Blaze > > PM Testing (success as given below): > OMAP3430-SDP: retention, off_mode, system_wide suspend, gpio wakeup > OMAP3630-Zoom3: retention, system_wide suspend > using the following: > echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout > echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout > echo '5' > /debug/pm_debug/wakeup_timer_seconds > echo 1 > /debug/pm_debug/sleep_while_idle > echo 1 > /debug/pm_debug/enable_off_mode > > -V Charulatha -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] OMAP: GPIO: cleanup show revision, remove cpu_is checks, display only once
Kevin Hilman writes:
> "Varadarajan, Charulatha" writes:
>
>> Kevin,
>>
>> On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
>>> Remove cpu_is_* checks from gpio_show_revision() by passing in the
>>> revision address offset from platform data. SoCs with no revision
>>> register (15xx, 7xx, and all MPUIOs) use -1 to signify no register.
>>>
>>> While here, all GPIO banks are assumed to be the same revision, so fix
>>> show_revision() to only show the revision for the first bank it finds.
>>> This removes duplicate GPIO revision prints during boot.
>>>
>>> Signed-off-by: Kevin Hilman
>>> ---
>>> arch/arm/mach-omap1/gpio15xx.c | 2 ++
>>> arch/arm/mach-omap1/gpio16xx.c | 2 ++
>>> arch/arm/mach-omap1/gpio7xx.c | 2 ++
>>> arch/arm/mach-omap2/gpio.c | 2 ++
>>> arch/arm/plat-omap/gpio.c | 14 ++
>>> arch/arm/plat-omap/include/plat/gpio.h | 1 +
>>> 6 files changed, 15 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
>>> index 9175624..6f77c36 100644
>>> --- a/arch/arm/mach-omap1/gpio15xx.c
>>> +++ b/arch/arm/mach-omap1/gpio15xx.c
>>> @@ -35,6 +35,7 @@ static struct __initdata resource
>>> omap15xx_mpu_gpio_resources[] = {
>>> };
>>>
>>> static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
>>> + .revision = -1,
>>
>> Assigning -1 to u16 type. Instead you may want to use 0x?
>>
>
> The compiler will do the right thing, so personally, I prefer using -1.
> It's safer if/when the type is changed, but the mask not updated.
Actually, you're right here.
While the compiler does the "right thing" for the assignment, it was not
doing the right thing for the comparision in the driver for the revision
check, and thus trying to read from offset 0x on OMAP1 for MPUIO
banks (that's probably the reason for a boot hang for you on 17xx.)
At least for me, with this change it's booting on OMAP1 (omap5912/OSK
for me.)
I'll change the usage of -1 here to USHRT_MAX.
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
2011/5/3 Kevin Hilman : > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) > into drivers/gpio first, followed by the cleanup/restructure patches? In my case I actually did some cleanup after moving the driver for U300, but I think this is a question to the GPIO maintainer who I want to ACK this stuff in the end. Grant? You can always squash it later ... Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v5] twl4030-madc driver
Hello Steve,
Can you try adding this patch?
Regards,
Keerthy
On Tue, May 3, 2011 at 8:44 PM, Steve Sakoman wrote:
> On Wed, Mar 2, 2011 at 2:15 AM, Samuel Ortiz wrote:
>> Hi Keerthy,
>>
>> On Tue, Mar 01, 2011 at 07:12:06PM +0530, Keerthy wrote:
>>> MADC(Monitoring ADC) driver enables monitoring analog signals using
>>> analog-to-digital conversion (ADC) on the input source.
>>> The previous discussion concluded in keeping the generic ADC
>>> functionality and the hwmon separate. The discussion can be found here:
>>>
>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html
>> Thanks a lot, I applied those 2 patches.
>
> I'm attempting to use this drive on the Overo platform with 2.6.39-rc5.
>
> Other than enabling the module with CONFIG_SENSORS_TWL4030_MADC=m are
> there any board file modifications required other than the below?
>
> I have setup the platform data for the twl4030 madc driver:
>
> diff --git a/arch/arm/mach-omap2/board-overo.c
> b/arch/arm/mach-omap2/board-overo.c
> index 112dfc9..05dd3eb 100644
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -637,10 +637,15 @@ static struct twl4030_codec_data overo_codec_data = {
> .audio = &overo_audio_data,
> };
>
> +static struct twl4030_madc_platform_data overo_madc_data = {
> + .irq_line = 1,
> +};
> +
> static struct twl4030_platform_data overo_twldata = {
> .irq_base = TWL4030_IRQ_BASE,
> .irq_end = TWL4030_IRQ_END,
> .gpio = &overo_gpio_data,
> + .madc = &overo_madc_data,
> .usb = &overo_usb_data,
> .codec = &overo_codec_data,
> .vmmc1 = &overo_vmmc1,
>
> However, I am not seeing the sysfs entry created:
>
> # modprobe twl4030-madc-hwmon
> twl4030_madc_hwmon_init entry
>
> # lsmod
> Module Size Used by
> twl4030_madc_hwmon 2594 0
> ipv6 224256 16
> libertas_sdio 14867 0
> libertas 92429 1 libertas_sdio
> cfg80211 144256 1 libertas
> lib80211 5027 1 libertas
> firmware_class 5859 2 libertas_sdio,libertas
>
> # ls /sys/class/hwmon/
> #
>
> I added a couple of printk's to the driver at the entry points of init
> and probe, and as you can see above the init message is printed, but
> not the probe.
>
> Am I missing something really obvious here?
>
> Steve
>
From a05c6cbb4494173e03ea5957666216caedb22d84 Mon Sep 17 00:00:00 2001
From: Keerthy
Date: Wed, 4 May 2011 01:14:50 +0530
Subject: [PATCH] Enabling Hwmon driver for twl4030-madc
Signed-off-by: Keerthy
---
drivers/mfd/twl-core.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 960b5be..e6e99db 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -83,6 +83,13 @@
#define twl_has_madc() false
#endif
+#if defined(CONFIG_SENSORS_TWL4030_MADC) ||\
+ defined(CONFIG_SENSORS_TWL4030_MADC_MODULE)
+#define twl_has_madc_hwmon() true
+#else
+#define twl_has_madc_hwmon() false
+#endif
+
#ifdef CONFIG_TWL4030_POWER
#define twl_has_power()true
#else
@@ -609,6 +616,14 @@ add_children(struct twl4030_platform_data *pdata, unsigned long features)
return PTR_ERR(child);
}
+if (twl_has_madc_hwmon()) {
+ child = add_child(2, "twl4030_madc_hwmon",
+NULL, 0,
+true, pdata->irq_base + MADC_INTR_OFFSET, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
if (twl_has_rtc()) {
/*
* REVISIT platform_data here currently might expose the
--
1.7.0.4
Re: [PATCH v2 0/7] picodlp projector driver
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote: > picodlp projector is supported by OMAP. > OMAP4430 SDP and EVM boards have an on board projector called as picodlp > projector. > picodlp would be connected to display sub system as a display panel. > It has a dlp processor dpp2600. > > The panel would be connected using 24 bit parallel interface. > It is a WVGA panel with 864 X 480 resolution. > > To know more about picodlp please visit: > http://omappedia.org/wiki/PicoDLP_projector_guide I think patches 3, 4, 5, 7 can be squashed into one. panel-picodlp.c is not that big of a file, and the division is quite artificial to my eyes. In theory the dss part and the i2c part could be in separate patches, but that doesn't make much sense here as the dss part won't function without the i2c part. It's much easier to review one whole patch, than pieces of the whole. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] OMAP: DSS: Adding initialization routine to picodlp panel
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> From: Mythri P K
>
> picodlp_i2c_client needs to send commands over i2c as a part of
> initialiazation.
> system controller dlp pico processor dpp2600 is used.
> It configures the splash screen of picodlp using a sequence of commands.
> A programmer's guide is available at:
> http://focus.ti.com/lit/ug/dlpu002a/dlpu002a.pdf
>
> API is defined for sending command over i2c as an i2c_write operation.
>
> Signed-off-by: Mythri P K
> Signed-off-by: Mayuresh Janorkar
> ---
> Changes since v1:
> 1. Removed initial splash screen
> 2. i2c_commands regrouped
> 3. Removed long msleep
> 4. Added try-after-sleep in i2c_write
>
> drivers/video/omap2/displays/panel-picodlp.c | 212
> ++
> 1 files changed, 212 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-picodlp.c
> b/drivers/video/omap2/displays/panel-picodlp.c
> index fdbfdcf..493a411 100644
> --- a/drivers/video/omap2/displays/panel-picodlp.c
> +++ b/drivers/video/omap2/displays/panel-picodlp.c
> @@ -32,7 +32,15 @@
> #include
> #include
>
> +#include "panel-picodlp.h"
> +
> #define DRIVER_NAME "picodlp_i2c_driver"
> +
> +/* This defines the minit of data which is allowed into single write block */
> +#define MAX_I2C_WRITE_BLOCK_SIZE 32
> +#define PICO_MAJOR 1 /* 2 bits */
> +#define PICO_MINOR 1 /* 2 bits */
> +
> struct picodlp_data {
> struct mutex lock;
> struct i2c_client *picodlp_i2c_client;
> @@ -50,6 +58,11 @@ struct i2c_device_id picodlp_i2c_id[] = {
> { "picodlp_i2c_driver", 0 },
> };
>
> +struct picodlp_i2c_command {
> + u8 reg;
> + u32 value;
> +};
> +
> static struct omap_video_timings pico_ls_timings = {
> .x_res = 864,
> .y_res = 480,
> @@ -70,6 +83,197 @@ static inline struct picodlp_panel_data
> return (struct picodlp_panel_data *) dssdev->data;
> }
>
> +static int picodlp_i2c_write_block(struct i2c_client *client,
> + u8 *data, int len)
> +{
> + struct i2c_msg msg;
> + int i, r, msg_count = 1, trial = 4;
> +
> + struct picodlp_i2c_data *picodlp_i2c_data = i2c_get_clientdata(client);
> +
> + if (len < 1 || len > MAX_I2C_WRITE_BLOCK_SIZE) {
> + dev_err(&client->dev,
> + "too long syn_write_block len %d\n", len);
> + return -EIO;
> + }
> +retry:
> + mutex_lock(&picodlp_i2c_data->xfer_lock);
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.len = len;
> + msg.buf = data;
> + r = i2c_transfer(client->adapter, &msg, msg_count);
> + mutex_unlock(&picodlp_i2c_data->xfer_lock);
> +
> + /*
> + * i2c_transfer returns:
> + * number of messages sent in case of success
> + * a negative error number in case of failure
> + * i2c controller might timeout, in such a case sleep for sometime
> + * and then retry
> + */
> + if (r != msg_count) {
> + msleep(2);
> + if (trial--)
> + goto retry;
This is not good. Hacks like these should only be used as a last option.
I'm still saying that you should find the document mentioned in the
documents you have. I refuse to believe that we (TI) do not know what
our hardware does, especially in a basic issue like this.
I'm 99% sure there is documentation telling the required power-up
sequence. And if that 1% happens, we should find the HW designers and
yell at them until they make the documents.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] OMAP: DSS: Add i2c client driver for picodlp
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote: > The configurations and data transfer with picodlp panel happens through i2c. > An i2c client with name "picodlp_i2c_driver" is registered inside panel. > > dpp2600 requires 4 gpio lines for interfacing it with any processor, > phy_reset, ready_reset, park, display_select Hmm, so what is dpp2600? It's mentioned here for the first time, the documentation doesn't mention it. If it means the picodlp, just use the same name all the time. If not, you could tell what it is first. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] OMAP: DSS: Adding a header file for picodlp panel data
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> picodlp is a TI projector panel supported by OMAP
> picodlp makes use of i2c interface for transferring commands to the panel
> panel data is required for identifying i2c_adapter id and dlp GPIOs
>
> A new header file has been added for panel data and
> picodlp_panel_data struct has been introduced
>
> Signed-off-by: Mayuresh Janorkar
> ---
> Changes since v1: Nil
>
> arch/arm/plat-omap/include/plat/panel-picodlp.h | 25
> +++
> 1 files changed, 25 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-omap/include/plat/panel-picodlp.h
>
> diff --git a/arch/arm/plat-omap/include/plat/panel-picodlp.h
> b/arch/arm/plat-omap/include/plat/panel-picodlp.h
> new file mode 100644
> index 000..89ac4b9
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/panel-picodlp.h
> @@ -0,0 +1,25 @@
> +/*
> + * panel data for picodlp panel
> + *
> + * Copyright (C) 2011 Texas Instruments
> + *
> + * Author: Mayuresh Janorkar
> + *
> + * 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 __ARCH_ARM_PLAT_PANEL_PICODLP_H
> +#define __ARCH_ARM_PLAT_PANEL_PICODLP_H
> +/**
> + * struct : picodlp panel data
> + * picodlp_adapter_id: i2c_adapter number for picodlp
> + */
> +struct picodlp_panel_data {
> + int picodlp_adapter_id;
> + int phy_reset_gpio;
> + int ready_reset_gpio;
> + int park_gpio;
> + int display_sel_gpio;
> +};
I think I've asked this before: where do the names of the GPIOs come
from? I can't find them from the documentation.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] OMAP: DSS: Adding a picodlp panel driver
On Mon, 2011-05-02 at 20:22 +0530, Mayuresh Janorkar wrote:
> From: Mythri P K
>
> A projector panel named picodlp is supported by OMAP.
> panel driver is required to be added with the name picodlp_panel.
>
> It is a WVGA panel with resolution 864 X 480 and panel timing data
> is defined in the panel driver.
>
> picodlp makes use of parallel (DPI) interface multiplexed with secondary lcd
> in case of OMAP4.
>
> Signed-off-by: Mythri P K
> Signed-off-by: Mayuresh Janorkar
> ---
> Changes since v1:
> 1. Removed msleep
>
> drivers/video/omap2/displays/panel-picodlp.c | 226
> ++
> 1 files changed, 226 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
> +static void picodlp_panel_disable(struct omap_dss_device *dssdev)
> +{
> + struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
> +
> + mutex_lock(&picod->lock);
> + /* Turn off DLP Power */
> + if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
> + picodlp_panel_power_off(dssdev);
> +
> + dev_dbg(&dssdev->dev, " disabling picodlp panel\n");
> + dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
> +
> + mutex_unlock(&picod->lock);
Many of the debug prints in this file have an extra space in the
beginning of the string, like above.
You should try to keep the code inside lock and unlock as minimal as
possible. Here the dev_dbg() could as well be outside the lock (granted,
dev_dbg() is a null op if DEBUG is not defined, but still).
Additionally, usually it's good to print the debug print before doing
the action, so here (and similar cases elsewhere in this file) it would
make sense to move the dev_dbg() before the lock.
> +}
> +
> +static int picodlp_panel_suspend(struct omap_dss_device *dssdev)
> +{
> + struct picodlp_data *picod = dev_get_drvdata(&dssdev->dev);
> +
> + mutex_lock(&picod->lock);
> + /* Turn off DLP Power */
> + if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) {
> + dev_dbg(&dssdev->dev, " unable to suspend picodlp panel,"\
> + " panel is not ACTIVE\n");
This is not a debug print, but an error. Similar problem in the function
below.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Staging: Westbridge: replace custom debug macros with pr_...() macros
On Thu, Apr 28, 2011 at 12:47:25PM -0700, Greg KH wrote: > On Thu, Apr 28, 2011 at 11:48:41AM -0700, Sutharsan wrote: > > >From Sutharsan Ramamoorthy > > > > This patch replaces custom debug macros with Linux kernel's pr_...() macros. > > Why not use the dev_dbg() and other macros instead of these? You do > have access to a struct device for all of these places in the code, > right? As I never got a response from you, I'm dropping this from my patch-queue. Please resend when you have addressed this issue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] About ARM expansion boards and others things
Hi guys, I'm thinking probably in a crazy idea, I hope someone can help me or kill definitely this idea from my mind. I'll explain a little more, the real problem is I don't know how to add support for an expansion board for IGEP v2 board. I see most of boards adds the support inside the board-x.c file, for example if the expansion board has a Touchscreen interface using ADS7846/TSC2046 they register ads7846 platform data in board-.c file. This is ok beacause the ads7846 can be detected and if expansion board is not present the detection fails, but maybe other devices in expansion board can't be detected (for example an I/O expansion). So which is the best form to do this ? I'm thinking in create a kernel module for the expansion board that add all the new features, the expansion board should come with a I2C E2PROM for board ID storage, so the idea is create an i2c driver that reads the E2PROM and if found the Board ID inits all the expansion board devices. I have done a few experiments, I've created a kernel module (driver) for a custom expansion board for IGEP v2, the expansion board has : - I2C E2PROM - ADS7846 touch controller (spi) - Seiko 7.0inch LCD - General purpose I/O The driver is capable to register correctly i2c and spi devices and seems is working but I have problems with the Seiko 7.0inch LCD and configuring the MUX from driver. Basically I wonder if it's possible add another omap_dss_device from kernel module to the omap DSS driver (something like omap_dss_register_new_device). Is a good or bad idea ? Why ? Is any reason to not export the MUX functionality to be used for other drivers ? All of this is a crazy idea ? What's the best form to solve the problem ? I hope I have explained well, thanks and cheers, Enric -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] OMAP: GPIO: cleanup show revision, remove cpu_is checks, display only once
"Varadarajan, Charulatha" writes:
> Kevin,
>
> On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
>> Remove cpu_is_* checks from gpio_show_revision() by passing in the
>> revision address offset from platform data. SoCs with no revision
>> register (15xx, 7xx, and all MPUIOs) use -1 to signify no register.
>>
>> While here, all GPIO banks are assumed to be the same revision, so fix
>> show_revision() to only show the revision for the first bank it finds.
>> This removes duplicate GPIO revision prints during boot.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> arch/arm/mach-omap1/gpio15xx.c | 2 ++
>> arch/arm/mach-omap1/gpio16xx.c | 2 ++
>> arch/arm/mach-omap1/gpio7xx.c | 2 ++
>> arch/arm/mach-omap2/gpio.c | 2 ++
>> arch/arm/plat-omap/gpio.c | 14 ++
>> arch/arm/plat-omap/include/plat/gpio.h | 1 +
>> 6 files changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
>> index 9175624..6f77c36 100644
>> --- a/arch/arm/mach-omap1/gpio15xx.c
>> +++ b/arch/arm/mach-omap1/gpio15xx.c
>> @@ -35,6 +35,7 @@ static struct __initdata resource
>> omap15xx_mpu_gpio_resources[] = {
>> };
>>
>> static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
>> + .revision = -1,
>
> Assigning -1 to u16 type. Instead you may want to use 0x?
>
The compiler will do the right thing, so personally, I prefer using -1.
It's safer if/when the type is changed, but the mask not updated.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] OMAP: GPIO: cleanup _set_gpio_wakeup(), remove ifdefs
"Varadarajan, Charulatha" writes:
> On Sat, Apr 23, 2011 at 04:32, Kevin Hilman wrote:
>> Make _set_gpio_wakeup() generic by removing ifdefs. Code for the
>> various SoCs/bank-methods was already the same, except for the
>> non-wakeup GPIO checking. But that flag is set on a per-SoC basis, so
>> can be used for all SoCs.
>>
>> While here, use pr_err() and remove GPIO bank calculation assumption
>> based on subtracting bank pointers.
>>
>> Signed-off-by: Kevin Hilman
[...]
>> -#endif
>> - default:
>> - printk(KERN_ERR "Can't enable GPIO wakeup for method %i\n",
>> - bank->method);
>> + if (bank->non_wakeup_gpios & gpio_bit) {
>> + pr_err("Unable to modify wakeup on non-wakeup GPIO%d\n",
>> gpio);
>
> use dev_err instead.
Agreed, thanks.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP: GPIO: remove MPUIO handling from _clear_gpio_irqbank()
"Varadarajan, Charulatha" writes:
> Kevin,
>
> On Sat, Apr 23, 2011 at 04:31, Kevin Hilman wrote:
>> Remove the OMAP1 #ifdef and MPUIO special case for _clear_gpio_irqbank()
>>
>> The MPUIOs do not need a register access to ack/clear the IRQ status,
>> since reading the IRQ status clears it. In addition, the MPUIO
>> irq_chip has an empty ack method, so _clear_gpio_irqbank() is never
>> used for MPUIOs.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> arch/arm/plat-omap/gpio.c | 6 --
>> 1 files changed, 0 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
>> index fe6971a..8b5ca6e 100644
>> --- a/arch/arm/plat-omap/gpio.c
>> +++ b/arch/arm/plat-omap/gpio.c
>> @@ -770,12 +770,6 @@ static void _clear_gpio_irqbank(struct gpio_bank *bank,
>> int gpio_mask)
>> void __iomem *reg = bank->base;
>>
>> switch (bank->method) {
>> -#ifdef CONFIG_ARCH_OMAP1
>> - case METHOD_MPUIO:
>> - /* MPUIO irqstatus is reset by reading the status register,
>> - * so do nothing here */
>> - return;
>> -#endif
>
> The default case has a "WARN_ON(1)". I guess WARN_ON()
> is not required for METHOD_MPUIO.
As stated in the changelog, this function is never called for MPUIO
banks, so the warning should not be hit.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] OMAP: GPIO: cleanup, consolidation, etc. (v2)
"DebBarma, Tarun Kanti" writes: > Kevin, > [...] >> > >> > Here's an updated version of my work-in-progress GPIO cleanups. >> > >> > I now understand that others have some similar work in progress, so >> > these are posted (to linux-omap only, for now) so that we can begin >> > collaboration on the GPIO cleanups. >> > >> > This series applies on top of v2.6.39-rc4 plus the generic irq_chip >> > series from Thomas Gleixner since in addition to the cleanups, I >> > started moving the GPIO IRQ handling over to use generic irq_chip >> > (last patch in series.) >> > >> > This work in progress is available in my wip/gpio-cleanup branch. >> There are two observations in this series: >> (1) omap1_defconfig build generates following compilation errors: > I realized that I missed the patch series from Thomas Gleixner. > BTW, there are multiple series related to irq_chip cleanup. > Do we need to apply all the series? My wip/gpio-cleanup branch also includes Thomas' series, please use that for testing. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Linus Walleij writes: > 2011/4/26 Tony Lindgren : >> * Linus Walleij [110423 01:32]: >>> Since you'll probably be dependent on stuff happening in my patches >>> to move stuff into drivers/gpio I'll be happy to carry the patches in my >>> gpio-consolidation branch with Tony's ACKs if need be. >> >> Sounds good to me. > > I've just posted a patch series that moves "our" two GPIO drivers to > drivers/gpio, they should serve as good inspiration... Tell me if I can > help out, stack patches on top of this series and I'll carry them. Great, thanks. Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into drivers/gpio first, followed by the cleanup/restructure patches? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/12] ARM: omap4: use remapped PPI interrupts for local timer
On Fri, 2011-04-29 at 12:54 +0530, Santosh Shilimkar wrote: Hi Santosh, > On 4/21/2011 12:38 AM, Marc Zyngier wrote: > > Use the normal interrupt scheme for the local timers by using > > a remapped PPI interrupt. > > > > Tested on a Pandaboard. > > > > Cc: Tony Lindgren > > Cc: Santosh Shilimkar > > Signed-off-by: Marc Zyngier > > --- > > Have reviewed and tested your series along with > OMAP changes. It boots fine on OMAP4430 SDP. > > # cat /proc/interrupts > CPU0 CPU1 > . > 410: 3678 0 GIC-PPI local_timer > 413: 0 1042 GIC-PPI local_timer > . > LOC: 0 0 Local timer interrupts > . > > Though above output would be bit miss leading, this > series removes the duplicate code from platforms and > consolidate it at one place. The LOC line is gone in the next iteration of the patch serie. > FWIW, you can add my > > Reviewedd-by: Santosh Shilimkar > Tested-by: Santosh Shilimkar Thanks for testing. M. -- Reality is an implementation detail. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: cm-t3517: fix section mismatch warning
ping!
Just to make sure you haven't missed this one liner ;)
On 04/26/11 23:41, Igor Grinberg wrote:
> WARNING: arch/arm/mach-omap2/built-in.o(.text+0x11014): Section mismatch
> in reference from the function cm_t3517_init_usbh() to the (unknown
> reference) .init.data:(unknown)
> The function cm_t3517_init_usbh() references
> the (unknown reference) __initdata (unknown).
> This is often because cm_t3517_init_usbh lacks a __initdata
> annotation or the annotation of (unknown) is wrong.
>
> Signed-off-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/board-cm-t3517.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
> b/arch/arm/mach-omap2/board-cm-t3517.c
> index a27e3ee..802cb60 100644
> --- a/arch/arm/mach-omap2/board-cm-t3517.c
> +++ b/arch/arm/mach-omap2/board-cm-t3517.c
> @@ -178,7 +178,7 @@ static struct usbhs_omap_board_data cm_t3517_ehci_pdata
> __initdata = {
> .reset_gpio_port[2] = -EINVAL,
> };
>
> -static int cm_t3517_init_usbh(void)
> +static int __init cm_t3517_init_usbh(void)
> {
> int err;
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi Kalle,
On Tuesday 03 May 2011 12:51:56 kalle.jokini...@nokia.com wrote:
> On 3. toukokuuta 2011 13:49 Laurent Pinchart wrote:
> > On Tuesday 03 May 2011 12:41:23 Kalle Jokiniemi wrote:
> > > The RX-51 uses the CSIb IO complex for camera operation. The
> > > board file is missing definition for the regulator supplying
> > > the CSIb complex, so this is added for better power
> > > management.
> > >
> > > Signed-off-by: Kalle Jokiniemi
> > > ---
> > >
> > > arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++
> > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> > > b/arch/arm/mach-omap2/board-rx51-peripherals.c index bbcb677..2f12425
> > > 100644
> > > --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> > > +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> > > @@ -337,6 +337,10 @@ static struct omap2_hsmmc_info mmc[] __initdata =
> >
> > {
> >
> > > static struct regulator_consumer_supply rx51_vmmc1_supply =
> > >
> > > REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0");
> > >
> > > +static struct regulator_consumer_supply rx51_vaux2_supply[] = {
> > > + REGULATOR_SUPPLY("vdds_csib", "omap3isp"),
> > > +};
> > > +
> >
> > What about
> >
> > static struct regulator_consumer_supply rx51_vaux2_supply =
> >
> > REGULATOR_SUPPLY("vdds_csib", "omap3isp");
> >
> > instead ? :-) It would be in line with the other vaux supply
> > definitions.
> >
> > > static struct regulator_consumer_supply rx51_vaux3_supply =
> > >
> > > REGULATOR_SUPPLY("vmmc", "omap_hsmmc.1");
> > >
> > > @@ -400,6 +404,8 @@ static struct regulator_init_data rx51_vaux2 = {
> > >
> > > .valid_ops_mask = REGULATOR_CHANGE_MODE
> > >
> > > | REGULATOR_CHANGE_STATUS,
> > >
> > > },
> > >
> > > + .num_consumer_supplies = 1,
> > > + .consumer_supplies = rx51_vaux2_supply,
> >
> > and
> >
> > .consumer_supplies = &rx51_vaux2_supply,
> >
> > here.
> >
> > If you're fine with that, there's no need to resubmit, I'll modify this
> > patch and push the set through my tree (let me know if I can keep your
> > SoB line with that change).
>
> Perfectly fine with me, you can keep the SoB line.
I've picked the patches up. I'll submit them for 2.6.40.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v5] twl4030-madc driver
On Wed, Mar 2, 2011 at 2:15 AM, Samuel Ortiz wrote:
> Hi Keerthy,
>
> On Tue, Mar 01, 2011 at 07:12:06PM +0530, Keerthy wrote:
>> MADC(Monitoring ADC) driver enables monitoring analog signals using
>> analog-to-digital conversion (ADC) on the input source.
>> The previous discussion concluded in keeping the generic ADC
>> functionality and the hwmon separate. The discussion can be found here:
>>
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41805.html
> Thanks a lot, I applied those 2 patches.
I'm attempting to use this drive on the Overo platform with 2.6.39-rc5.
Other than enabling the module with CONFIG_SENSORS_TWL4030_MADC=m are
there any board file modifications required other than the below?
I have setup the platform data for the twl4030 madc driver:
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 112dfc9..05dd3eb 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -637,10 +637,15 @@ static struct twl4030_codec_data overo_codec_data = {
.audio = &overo_audio_data,
};
+static struct twl4030_madc_platform_data overo_madc_data = {
+ .irq_line = 1,
+};
+
static struct twl4030_platform_data overo_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
.gpio = &overo_gpio_data,
+ .madc = &overo_madc_data,
.usb= &overo_usb_data,
.codec = &overo_codec_data,
.vmmc1 = &overo_vmmc1,
However, I am not seeing the sysfs entry created:
# modprobe twl4030-madc-hwmon
twl4030_madc_hwmon_init entry
# lsmod
Module Size Used by
twl4030_madc_hwmon 2594 0
ipv6 224256 16
libertas_sdio 14867 0
libertas 92429 1 libertas_sdio
cfg80211 144256 1 libertas
lib802115027 1 libertas
firmware_class 5859 2 libertas_sdio,libertas
# ls /sys/class/hwmon/
#
I added a couple of printk's to the driver at the entry points of init
and probe, and as you can see above the init message is printed, but
not the probe.
Am I missing something really obvious here?
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/9] OMAP3: PM: TWL4030 power scripts and workaround for TWL erratum 27
On Thu, Apr 14, 2011 at 2:27 PM, Lesly A M wrote: > Patch series for TWL4030 power scripts and workaround for TWL erratum 27. > > Changes for implementing TWL4030 power scripts recommended by hardware team. > Introduced a new TWL4030 power script file, which can be used by different > OMAP3 board with the power companion chip TWL4030. > > Updated the changes for TWL4030 errata 27 & 28, and modified > the TWL4030 power script. > Workaround for TWL4030 erratum 27 is required for Si version less than or > equal to TWL5030 ES1.1. > ... > This changes are tested on OMAP3430 & OMAP3630 SDP with off mode enabled in > suspend path. With the patches series applied and a board file change for Beagleboard (similar to patch 7/9 for SDP), the Beagleboard is not consistently booting. Most of the time it is hanging at boot, cf. dump below. In the case it boots OK no voltage drop is observed when going to OFF mode. Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.39-rc5-09490-gf4c2b2b (def@defasus) (gcc version 4.4.1 (Sourcery G++ L ite 2010q1-202) ) #694 SMP Tue May 3 14:11:31 CEST 2011 [0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP3 Beagle Board [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) ... [0.350830] OMAP3 Beagle Rev: Ax/Bx [0.365203] omap_device: omap_uart.0: new worst case activate latency 0: 30517 [0.365570] omap_device: omap_uart.0: new worst case deactivate latency 0: 30517 [0.385253] Found NAND on CS0 [0.388427] Registering NAND on CS0 [0.393585] Unable to get DVI reset GPIO [0.398284] hw-breakpoint: debug architecture 0x4 unsupported. [0.425659] OMAP DMA hardware revision 4.0 [0.509674] bio: create slab at 0 [0.526092] SCSI subsystem initialized [0.531158] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517 [0.541351] omap_device: omap2_mcspi.1: new worst case deactivate latency 0: 30517 [0.557586] usbcore: registered new interface driver usbfs [0.564971] usbcore: registered new interface driver hub [0.572082] usbcore: registered new device driver usb [0.579925] omap_device: omap_i2c.1: new worst case activate latency 0: 30517 [0.587768] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2600 kHz AFAICT the main difference in the wiring is that the PMIC CLKREQ is not connected to the OMAP and is tied to VIO_1V8. Any thought on how to support the T2 scripts on Beagle? Regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Initial B&N Nook Color (encore) support.
Oleg Drokin wrote: Hello! Is there any special support needed for 3621, though? My understanding is that's just 3630 without a "phone" part? 3621 is more or less a 3630 in a different package, less pins, 0.5mm ball pitch and no PoP option. The .29 kernel they had only added is_omap3621 stuff that's not called anywhere, but smartreflex code (I guess that's might be useful to add too of course). I know about the new code drop is coming, but I don't expect there to be any basic stuff changes (and this board file is coming pretty barebones right now), besides I am not so optimistic to actually expect this patch to be merged right away, but I am already gathering valuable feedback. ;) BTW I saw in the archives that you are also working a port, do you have your tree hosted anywhere? Bye, Oleg On Apr 28, 2011, at 7:34 PM, Abimanyu Gottumukkala wrote: Hi, Nook color has Ti OMAP 3621. 3621 CPU Support is not available in current kernel, adding CPU support will be nice before board. BN is set to release new source code in few days, taking new code as porting base is also recommended. Regards, Abimanyu G On Thu, Apr 28, 2011 at 9:27 PM, wrote: From: Oleg Drokin Bare-bones board file, comes with serial console, gpio keys, MMC/SDCard and USB support. --- arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-omap3encore.c | 380 ++ arch/arm/plat-omap/include/plat/uncompress.h |1 + arch/arm/tools/mach-types|2 +- 5 files changed, 389 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3encore.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b997a35..5370561 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO for full description please see the products webpage at http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit +config MACH_ENCORE +bool "Barnes& Noble Encore (Nook Color)" +depends on ARCH_OMAP3 +select OMAP_PACKAGE_CBP + config MACH_OVERO bool "Gumstix Overo board" depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 512b152..b894777 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -189,6 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \ hsmmc.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o \ + hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ diff --git a/arch/arm/mach-omap2/board-omap3encore.c b/arch/arm/mach-omap2/board-omap3encore.c new file mode 100644 index 000..c7bf8de --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3encore.c @@ -0,0 +1,380 @@ +/* + * + * Copyright (C) 2008 Texas Instruments Inc. + * Vikram Pandita + * + * Modified from mach-omap2/board-ldp.c + * + * 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. + * + * April 2011 Oleg Drokin - Port to 2.6.39 + * + */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "mux.h" +#include "hsmmc.h" +#include "sdram-hynix-h8mbx00u0mer-0em.h" + +/* Encore-specific device-info and i2c addresses. */ +/* Battery, bus 1 */ +#define MAX17042_I2C_SLAVE_ADDRESS 0x36 +#define MAX17042_GPIO_FOR_IRQ 100 + +/*addition of MAXIM8903/TI GPIO mapping WRT schematics */ +#define MAX8903_UOK_GPIO_FOR_IRQ 115 +#define MAX8903_DOK_GPIO_FOR_IRQ 114 +#define MAX8903_GPIO_CHG_EN110 +#define MAX8903_GPIO_CHG_STATUS111 +#define MAX8903_GPIO_CHG_FLT 101 +#define MAX8903_GPIO_CHG_IUSB 102 +#define MAX8903_GPIO_CHG_USUS 104 +#define MAX8903_GPIO_CHG_ILM 61 + +/* TI WLAN */ +#define ENCORE_WIFI_PMENA_GPIO 22 +#define ENCORE_WIFI_IRQ_GPIO 15 +#define ENCORE_WIFI_EN_POW 16 + +/* Accelerometer i2c bus 1*/ +#define KXTF9_I2C_SLAVE_ADDRESS0x0F +#define KXTF9_GPIO_FOR_PWR 34 +#define KXTF9_GPIO_FOR_IRQ 113 + +/* Touch screen i2c bus 2*/ +#define CYTTSP_I2C_SLAV
[PATCH] omap : nand : fix subpage ecc issue with prefetch
For prefetch engine, read and write got broken in commit '2c01946c'.
We never hit a scenario of not getting 'gpmc_prefetch_enable'
call success.
When reading/writing a subpage with a non divisible by 4 ecc number
of bytes, the mis-aligned bytes gets handled first before enabling
the Prefetch engine, then it reads/writes rest of the bytes.
Signed-off-by: Kishore Kadiyala
Signed-off-by: Vimal Singh
Reported-by: Bryan DE FARIA
---
drivers/mtd/nand/omap2.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..2c8040f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -263,11 +263,10 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info->nand.options & NAND_BUSWIDTH_16)
- omap_read_buf16(mtd, buf, len);
+ omap_read_buf16(mtd, (u_char *)p, len);
else
- omap_read_buf8(mtd, buf, len);
+ omap_read_buf8(mtd, (u_char *)p, len);
} else {
- p = (u32 *) buf;
do {
r_count = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
r_count = r_count >> 2;
@@ -293,7 +292,7 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
struct omap_nand_info, mtd);
uint32_t w_count = 0;
int i = 0, ret = 0;
- u16 *p;
+ u16 *p = (u16 *)buf;
unsigned long tim, limit;
/* take care of subpage writes */
@@ -309,11 +308,10 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info->nand.options & NAND_BUSWIDTH_16)
- omap_write_buf16(mtd, buf, len);
+ omap_write_buf16(mtd, (u_char *)p, len);
else
- omap_write_buf8(mtd, buf, len);
+ omap_write_buf8(mtd, (u_char *)p, len);
} else {
- p = (u16 *) buf;
while (len) {
w_count = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
w_count = w_count >> 1;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
* Russell King - ARM Linux [110428 07:06]: > > This looks much better. > > Acked-by: Russell King > > It looks like Tony hasn't taken it... Tony, are you going to handle > this patch? I can add it into my devel-cleanup branch for next merge window assuming it won't conflict with your sram changes. If there's a conflict, then you can take it. I'd rather not merge it in the -rc cycle this late as it's not in the oopses or major regressions category. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi,
> -Original Message-
> From: ext Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: 3. toukokuuta 2011 13:49
> To: Jokiniemi Kalle (Nokia-SD/Tampere)
> Cc: mauroche...@gmail.com; t...@atomide.com; linux-
> o...@vger.kernel.org; linux-me...@vger.kernel.org
> Subject: Re: [PATCH v3 2/2] OMAP3: RX-51: define vdds_csib regulator supply
>
> Hi Kalle,
>
> Thanks for the patch.
>
> On Tuesday 03 May 2011 12:41:23 Kalle Jokiniemi wrote:
> > The RX-51 uses the CSIb IO complex for camera operation. The
> > board file is missing definition for the regulator supplying
> > the CSIb complex, so this is added for better power
> > management.
> >
> > Signed-off-by: Kalle Jokiniemi
> > ---
> > arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> > b/arch/arm/mach-omap2/board-rx51-peripherals.c index bbcb677..2f12425
> > 100644
> > --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> > +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> > @@ -337,6 +337,10 @@ static struct omap2_hsmmc_info mmc[] __initdata =
> {
> > static struct regulator_consumer_supply rx51_vmmc1_supply =
> >REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0");
> >
> > +static struct regulator_consumer_supply rx51_vaux2_supply[] = {
> > + REGULATOR_SUPPLY("vdds_csib", "omap3isp"),
> > +};
> > +
>
> What about
>
> static struct regulator_consumer_supply rx51_vaux2_supply =
> REGULATOR_SUPPLY("vdds_csib", "omap3isp");
>
> instead ? :-) It would be in line with the other vaux supply definitions.
>
> > static struct regulator_consumer_supply rx51_vaux3_supply =
> >REGULATOR_SUPPLY("vmmc", "omap_hsmmc.1");
> >
> > @@ -400,6 +404,8 @@ static struct regulator_init_data rx51_vaux2 = {
> >.valid_ops_mask = REGULATOR_CHANGE_MODE
> >
> >| REGULATOR_CHANGE_STATUS,
> >
> >},
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = rx51_vaux2_supply,
>
> and
>
> .consumer_supplies = &rx51_vaux2_supply,
>
> here.
>
> If you're fine with that, there's no need to resubmit, I'll modify this patch
> and push the set through my tree (let me know if I can keep your SoB line
> with
> that change).
Perfectly fine with me, you can keep the SoB line.
Thanks,
Kalle
>
> > };
> >
> > /* VAUX3 - adds more power to VIO_18 rail */
>
> --
> Regards,
>
> Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] OMAP3: RX-51: define vdds_csib regulator supply
Hi Kalle,
Thanks for the patch.
On Tuesday 03 May 2011 12:41:23 Kalle Jokiniemi wrote:
> The RX-51 uses the CSIb IO complex for camera operation. The
> board file is missing definition for the regulator supplying
> the CSIb complex, so this is added for better power
> management.
>
> Signed-off-by: Kalle Jokiniemi
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c index bbcb677..2f12425
> 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -337,6 +337,10 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
> static struct regulator_consumer_supply rx51_vmmc1_supply =
> REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0");
>
> +static struct regulator_consumer_supply rx51_vaux2_supply[] = {
> + REGULATOR_SUPPLY("vdds_csib", "omap3isp"),
> +};
> +
What about
static struct regulator_consumer_supply rx51_vaux2_supply =
REGULATOR_SUPPLY("vdds_csib", "omap3isp");
instead ? :-) It would be in line with the other vaux supply definitions.
> static struct regulator_consumer_supply rx51_vaux3_supply =
> REGULATOR_SUPPLY("vmmc", "omap_hsmmc.1");
>
> @@ -400,6 +404,8 @@ static struct regulator_init_data rx51_vaux2 = {
> .valid_ops_mask = REGULATOR_CHANGE_MODE
>
> | REGULATOR_CHANGE_STATUS,
>
> },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = rx51_vaux2_supply,
and
.consumer_supplies = &rx51_vaux2_supply,
here.
If you're fine with that, there's no need to resubmit, I'll modify this patch
and push the set through my tree (let me know if I can keep your SoB line with
that change).
> };
>
> /* VAUX3 - adds more power to VIO_18 rail */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] OMAP3: ISP: Add regulator control for omap34xx
The current omap3isp driver is missing regulator handling
for CSIb complex in omap34xx based devices. This patch
adds a mechanism for this to the omap3isp driver.
Signed-off-by: Kalle Jokiniemi
Acked-by: Laurent Pinchart
---
drivers/media/video/omap3isp/ispccp2.c | 27 +--
drivers/media/video/omap3isp/ispccp2.h |1 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c
index 0e16cab..ec9e395 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "isp.h"
#include "ispreg.h"
@@ -163,6 +164,9 @@ static void ccp2_if_enable(struct isp_ccp2_device *ccp2, u8
enable)
struct isp_pipeline *pipe = to_isp_pipeline(&ccp2->subdev.entity);
int i;
+ if (enable && ccp2->vdds_csib)
+ regulator_enable(ccp2->vdds_csib);
+
/* Enable/Disable all the LCx channels */
for (i = 0; i < CCP2_LCx_CHANS_NUM; i++)
isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_CCP2, ISPCCP2_LCx_CTRL(i),
@@ -186,6 +190,9 @@ static void ccp2_if_enable(struct isp_ccp2_device *ccp2, u8
enable)
ISPCCP2_LC01_IRQENABLE,
ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ);
}
+
+ if (!enable && ccp2->vdds_csib)
+ regulator_disable(ccp2->vdds_csib);
}
/*
@@ -1137,6 +1144,9 @@ error:
*/
void omap3isp_ccp2_cleanup(struct isp_device *isp)
{
+ struct isp_ccp2_device *ccp2 = &isp->isp_ccp2;
+
+ regulator_put(ccp2->vdds_csib);
}
/*
@@ -1151,14 +1161,27 @@ int omap3isp_ccp2_init(struct isp_device *isp)
init_waitqueue_head(&ccp2->wait);
- /* On the OMAP36xx, the CCP2 uses the CSI PHY1 or PHY2, shared with
+ /*
+* On the OMAP34xx the CSI1 receiver is operated in the CSIb IO
+* complex, which is powered by vdds_csib power rail. Hence the
+* request for the regulator.
+*
+* On the OMAP36xx, the CCP2 uses the CSI PHY1 or PHY2, shared with
* the CSI2c or CSI2a receivers. The PHY then needs to be explicitly
* configured.
*
* TODO: Don't hardcode the usage of PHY1 (shared with CSI2c).
*/
- if (isp->revision == ISP_REVISION_15_0)
+ if (isp->revision == ISP_REVISION_2_0) {
+ ccp2->vdds_csib = regulator_get(isp->dev, "vdds_csib");
+ if (IS_ERR(ccp2->vdds_csib)) {
+ dev_dbg(isp->dev,
+ "Could not get regulator vdds_csib\n");
+ ccp2->vdds_csib = NULL;
+ }
+ } else if (isp->revision == ISP_REVISION_15_0) {
ccp2->phy = &isp->isp_csiphy1;
+ }
ret = ccp2_init_entities(ccp2);
if (ret < 0)
diff --git a/drivers/media/video/omap3isp/ispccp2.h
b/drivers/media/video/omap3isp/ispccp2.h
index 5505a86..6674e9d 100644
--- a/drivers/media/video/omap3isp/ispccp2.h
+++ b/drivers/media/video/omap3isp/ispccp2.h
@@ -81,6 +81,7 @@ struct isp_ccp2_device {
struct isp_interface_mem_config mem_cfg;
struct isp_video video_in;
struct isp_csiphy *phy;
+ struct regulator *vdds_csib;
unsigned int error;
enum isp_pipeline_stream_state state;
wait_queue_head_t wait;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] OMAP3: RX-51: define vdds_csib regulator supply
The RX-51 uses the CSIb IO complex for camera operation. The
board file is missing definition for the regulator supplying
the CSIb complex, so this is added for better power
management.
Signed-off-by: Kalle Jokiniemi
---
arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..2f12425 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -337,6 +337,10 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
static struct regulator_consumer_supply rx51_vmmc1_supply =
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0");
+static struct regulator_consumer_supply rx51_vaux2_supply[] = {
+ REGULATOR_SUPPLY("vdds_csib", "omap3isp"),
+};
+
static struct regulator_consumer_supply rx51_vaux3_supply =
REGULATOR_SUPPLY("vmmc", "omap_hsmmc.1");
@@ -400,6 +404,8 @@ static struct regulator_init_data rx51_vaux2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = rx51_vaux2_supply,
};
/* VAUX3 - adds more power to VIO_18 rail */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] omap3isp/rx-51: Add vdds_csib regulator handling
The CSIb block is used in rx-51 to handle camera ccp2 IO. Adding support to omap3isp driver for managing the power supply for the CSIb IO complex via regulator framework. Also create the apropriate regulator definitions in the rx-51 board file. I propose to push this set through the linux-media, since most of the changes are on the omap3isp driver side. Tested on Nokia N900 and the MeeGo testing daily images (.37 based kernel). Patches on top of Mauro's linux-next tree, build tested and boot tested with that. v2: updated patch 1/2 with comment from Laurent Pinchart v3: removed unnecessary "vaux2" consumer regulator supply Kalle Jokiniemi (2): OMAP3: ISP: Add regulator control for omap34xx OMAP3: RX-51: define vdds_csib regulator supply arch/arm/mach-omap2/board-rx51-peripherals.c |6 + drivers/media/video/omap3isp/ispccp2.c | 27 - drivers/media/video/omap3isp/ispccp2.h |1 + 3 files changed, 32 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2plus: GPIO cleanup mach-omap2/*
* Igor Grinberg [110428 00:13]: > On 04/27/11 18:58, Grazvydas Ignotas wrote: > > > On Wed, Apr 27, 2011 at 5:01 PM, Tony Lindgren wrote: > >> * Igor Grinberg [110427 02:02]: > >>> use gpio_request_() instead of multiple gpiolib calls, > >>> remove unneeded variables, etc. > >> Great :) > > I think this does conflict with Mike's "omap: cleanup board files" > > series though. > > Yep, as I've stated in the description ;) > > I've started working on this before Mike submitted his series and now > I want to get some responses before any rebase work is done. Mike's series is now applied into devel-cleanup, can you please rebase on top of commit ff08a05b6ca3a22107d621b1417e703af25b1298? Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] omap: cleanup board files
* Tony Lindgren [110502 07:18]: > * Mike Rapoport [110502 06:54]: > > ping? > > Looks OK to me, let's wait on Felipe's comments on the > musb related stuff. Applying this series into devel-cleanup for next merge window. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: GIC: Convert GIC library to use the IO relaxed operations
On 5/3/2011 3:41 PM, Catalin Marinas wrote: [...] diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c index e9c2ff8..80b3d3c 100644 --- a/arch/arm/common/gic.c +++ b/arch/arm/common/gic.c @@ -89,7 +89,8 @@ static void gic_mask_irq(struct irq_data *d) u32 mask = 1<< (d->irq % 32); spin_lock(&irq_controller_lock); - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); As I commented on the version 2 of this patch, I don't think we should even bother with the additional readl_relaxed() here. It's not enough to prevent spurious interrupts anyway. I forgot to drop this one. @@ -392,6 +393,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq) unsigned long map = *cpus_addr(*mask); /* this always happens on GIC0 */ - writel(map<< 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT); + dsb(); + writel_relaxed(map<< 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT); I would add a comment before the dsb() on why it is needed. Maybe something like: /* * Ensure that stores to Normal memory are visible to the other CPUs before * issuing the IPI. */ Otherwise the patch looks fine (I'll add my ack after you fix the above). Thanks. Will add above comment, drop the readl and repost with your ack. Same will push it the patch system Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: GIC: Convert GIC library to use the IO relaxed operations
On Fri, 2011-04-29 at 07:22 +0100, Santosh Shilimkar wrote: > The GIC register accesses today make use of readl()/writel() > which prove to be very expensive when used along with mandatory > barriers. This mandatory barriers also introduces an un-necessary > and expensive l2x0_sync() operation. On Cortex-A9 MP cores, GIC > IO accesses from CPU are direct and doesn't go through L2X0 write > buffer. > > A DSB before writel_relaxed() in gic_raise_softirq() is added to be > compliant with the Barrier Litmus document - the mailbox scenario. > > Signed-off-by: Santosh Shilimkar > Cc: Catalin Marinas > Cc: Will Deacon > --- > Rebased on top of Will Deacon's "ARM: gic: use handle_fasteoi_irq for SPIs" > patch and boot tested on OMAP4430. > > arch/arm/common/gic.c | 50 +--- > 1 files changed, 26 insertions(+), 24 deletions(-) > > diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c > index e9c2ff8..80b3d3c 100644 > --- a/arch/arm/common/gic.c > +++ b/arch/arm/common/gic.c > @@ -89,7 +89,8 @@ static void gic_mask_irq(struct irq_data *d) > u32 mask = 1 << (d->irq % 32); > > spin_lock(&irq_controller_lock); > - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / > 32) * 4); > + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + > (gic_irq(d) / 32) * 4); > + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) > / 32) * 4); As I commented on the version 2 of this patch, I don't think we should even bother with the additional readl_relaxed() here. It's not enough to prevent spurious interrupts anyway. > @@ -392,6 +393,7 @@ void gic_raise_softirq(const struct cpumask *mask, > unsigned int irq) > unsigned long map = *cpus_addr(*mask); > > /* this always happens on GIC0 */ > - writel(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT); > + dsb(); > + writel_relaxed(map << 16 | irq, gic_data[0].dist_base + > GIC_DIST_SOFTINT); I would add a comment before the dsb() on why it is needed. Maybe something like: /* * Ensure that stores to Normal memory are visible to the other CPUs before * issuing the IPI. */ Otherwise the patch looks fine (I'll add my ack after you fix the above). Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Initial B&N Nook Color (encore) support.
* gr...@linuxhacker.ru [110428 08:55]:
> From: Oleg Drokin
>
> Bare-bones board file, comes with serial console, gpio keys,
> MMC/SDCard and USB support.
Good to see that. Unfortunately you probably have to do few
more rebases on the devel-cleanup branch because of the code
consolidation effort. We'll have to wait a bit and see what
new platform code we can merge after that is all the
consolidation is sorted out.
Please also post your series with linux-arm-kernel mailing
list Cc'd. Few comments below too.
> +#include
This should be linux/gpio.h nowadays.
> + if(is_encore_board_evt2()) {
You should have if ( here with space.
Maybe run scripts/checkpatch.pl --strict on the patch?
> --- a/arch/arm/tools/mach-types
> +++ b/arch/arm/tools/mach-types
> @@ -962,7 +962,7 @@ omapl138_case_a3 MACH_OMAPL138_CASE_A3
> OMAPL138_CASE_A33280
> uemd MACH_UEMD UEMD3281
> ccwmx51mut MACH_CCWMX51MUT CCWMX51MUT 3282
> rockhopper MACH_ROCKHOPPER ROCKHOPPER 3283
> -nookcolorMACH_NOOKCOLOR NOOKCOLOR 3284
> +encore MACH_ENCORE ENCORE
> 3284
> hkdkc100 MACH_HKDKC100 HKDKC1003285
> ts42xx MACH_TS42XX TS42XX
> 3286
> aebl MACH_AEBL AEBL3287
For this you need to follow the instructions at www.arm.linux.org.uk.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] omap: musb: introduce default board config
Hi, > Most boards use exactly the same configuration for musb initialization. > Create a default that can be shared amount different boards. > > Signed-off-by: Mike Rapoport Acked-by: Felipe Balbi -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/2] OMAP: DSS: Support new dpi panels
On Tue, 2011-05-03 at 09:07 +0200, Enric Balletbo i Serra wrote: > Hi all, > > These patches add support for two new panels to the generic-dpi-panel. > > The first patch adds support for the Seiko 70WVW1TZ3 LCD panel, and the second > adds support for the Powertip PH480272T LCD panel. > > Tested with an IGEP v2 board. > > Changes since v1: > - Change the names of both panels in the panel_config struct to > include the name of the manufacturer. > - Mention the board which uses those panels. > > Please consider to add in next merge window, thanks, > > Enric Balletbo i Serra (2): > OMAP: DSS2: Support for Seiko 70WVW1TZ3 > OMAP: DSS2: Support for Powertip PH480272T > > drivers/video/omap2/displays/panel-generic-dpi.c | 50 > ++ > 1 files changed, 50 insertions(+), 0 deletions(-) Thanks, applied to DSS tree. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
* Felipe Balbi [110502 07:22]: > On Mon, May 02, 2011 at 07:20:52AM -0700, Tony Lindgren wrote: > > * Oleg Drokin [110428 09:33]: > > > > > > So to me it looks like something totally in realm of musb driver itself. > > > Nothing bad happens if you configure your MUSB as say OTG while in fact > > > only > > > peripheral mode was implemented, it continues to work as it did. > > > Of course enabling HOST mode may not magically make things work, but > > > I suspect this could be addressed from Kconfig itself instead. So based on the discussion it sounds like we still the board specific configuration for the mode in some cases. > > I think Felipe already has some patches to remove the various Kconfig > > options for musb? In any case, the musb configuration should be a > > runtime configuration passed in the platform data or cmdline. > > Yeah, I'm planning to get rid of all the ifdeferry and always compile it > with HOST and Peripheral support. It's only few extra tens of bytes > anyway. Still, I doubt I can get that done for this merge window, I > already have pending the debugging rework. So care to ack the original patch then? It still allows overriding the default mode from board-*.c file as needed. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: omap: gpmc-smsc911x: minor style fixes
* Menon, Nishanth [110426 14:05]:
> On Tue, Apr 26, 2011 at 11:25, Igor Grinberg wrote:
> >
> > replace "printk(KERN_ERR" by "pr_err("
> > and fix needlessly multi-lined #ifdef
> >
> > Signed-off-by: Igor Grinberg
>
> Acked-by: Nishanth Menon
Thanks, will queue this too. One line negative diffstat, whee!
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: smsc911x: regression on overo platform
* Mike Rapoport [110502 22:21]: > Yeah, sorry about that. > There's a fix at (1), I hope Tony will merge it soon. > > [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/56499/focus=56542 Will get merged soonish. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] arm: omap: fix bug with multiple smsc911x devices
* Igor Grinberg [110502 23:23]:
>
> > kobject (c06a4250): tried to init an initialized object, something is
> > seriously wrong.
> >
> > introduced by commit 66293989:
> > (omap: convert boards that use SMSC911x to use gpmc-smsc911x)
> >
> > fixed by allocating struct platform_device dynamically.
Thanks, I'll merge this into Mike's original patch in
devel-cleanup branch for the next merge window.
Updated patch below.
Regards,
Tony
From: Mike Rapoport
Date: Sat, 16 Apr 2011 22:29:30 +
Subject: [PATCH] omap: convert boards that use SMSC911x to use gpmc-smsc911x
Convert boards that use SMSC911x to use gpmc-smsc911x.
Also allocate struct platform_device dynamically.
Signed-off-by: Mike Rapoport
Signed-off-by: Igor Grinberg
[t...@atomide.com: folded in a fix from Igor Grindberg]
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 02a12b4..7c70f56 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -66,86 +66,28 @@
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include
+#include
-static struct smsc911x_platform_config cm_t35_smsc911x_config = {
- .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
- .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
- .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
- .phy_interface = PHY_INTERFACE_MODE_MII,
-};
-
-static struct resource cm_t35_smsc911x_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP_GPIO_IRQ(CM_T35_SMSC911X_GPIO),
- .end= OMAP_GPIO_IRQ(CM_T35_SMSC911X_GPIO),
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
- },
-};
-
-static struct platform_device cm_t35_smsc911x_device = {
- .name = "smsc911x",
+static struct omap_smsc911x_platform_data cm_t35_smsc911x_cfg = {
.id = 0,
- .num_resources = ARRAY_SIZE(cm_t35_smsc911x_resources),
- .resource = cm_t35_smsc911x_resources,
- .dev= {
- .platform_data = &cm_t35_smsc911x_config,
- },
-};
-
-static struct resource sb_t35_smsc911x_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP_GPIO_IRQ(SB_T35_SMSC911X_GPIO),
- .end= OMAP_GPIO_IRQ(SB_T35_SMSC911X_GPIO),
- .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
- },
+ .cs = CM_T35_SMSC911X_CS,
+ .gpio_irq = CM_T35_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
};
-static struct platform_device sb_t35_smsc911x_device = {
- .name = "smsc911x",
+static struct omap_smsc911x_platform_data sb_t35_smsc911x_cfg = {
.id = 1,
- .num_resources = ARRAY_SIZE(sb_t35_smsc911x_resources),
- .resource = sb_t35_smsc911x_resources,
- .dev= {
- .platform_data = &cm_t35_smsc911x_config,
- },
+ .cs = SB_T35_SMSC911X_CS,
+ .gpio_irq = SB_T35_SMSC911X_GPIO,
+ .gpio_reset = -EINVAL,
+ .flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
};
-static void __init cm_t35_init_smsc911x(struct platform_device *dev,
- int cs, int irq_gpio)
-{
- unsigned long cs_mem_base;
-
- if (gpmc_cs_request(cs, SZ_16M, &cs_mem_base) < 0) {
- pr_err("CM-T35: Failed request for GPMC mem for smsc911x\n");
- return;
- }
-
- dev->resource[0].start = cs_mem_base + 0x0;
- dev->resource[0].end = cs_mem_base + 0xff;
-
- if ((gpio_request(irq_gpio, "ETH IRQ") == 0) &&
- (gpio_direction_input(irq_gpio) == 0)) {
- gpio_export(irq_gpio, 0);
- } else {
- pr_err("CM-T35: could not obtain gpio for SMSC911X IRQ\n");
- return;
- }
-
- platform_device_register(dev);
-}
-
static void __init cm_t35_init_ethernet(void)
{
- cm_t35_init_smsc911x(&cm_t35_smsc911x_device,
-CM_T35_SMSC911X_CS, CM_T35_SMSC911X_GPIO);
- cm_t35_init_smsc911x(&sb_t35_smsc911x_device,
-SB_T35_SMSC911X_CS, SB_T35_SMSC911X_GPIO);
+ gpmc_smsc911x_init(&cm_t35_smsc911x_cfg);
+ gpmc_smsc911x_init(&sb_t35_smsc911x_cfg);
}
#else
static inline void __init cm_t35_init_ethernet(void) { return; }
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 34cf982..5b9bde7 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -192,57 +192,18 @@ static void __init igep2_flash_init(void) {}
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
#include
+#include
-static stru
[PATCHv2 2/2] OMAP: DSS2: Support for Powertip PH480272T
Add support for Powertip PH480242T, a LCD 4.3inch (480x242) display
type with 24-bit RGB interface, to panel-generic-dpi.
Tested with IGEP v2 board.
Signed-off-by: Enric Balletbo i Serra
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 644d370..416e645 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -206,6 +206,31 @@ static struct panel_config generic_dpi_panels[] = {
.power_off_delay= 0,
.name = "seiko_70wvw1tz3",
},
+
+ /* Powertip PH480272T */
+ {
+ {
+ .x_res = 480,
+ .y_res = 272,
+
+ .pixel_clock= 9000,
+
+ .hsw= 40,
+ .hfp= 2,
+ .hbp= 2,
+
+ .vsw= 10,
+ .vfp= 2,
+ .vbp= 2,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IEO,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = "powertip_ph480272t",
+ },
};
struct panel_drv_data {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/2] OMAP: DSS2: Support for Seiko 70WVW1TZ3
Add support for Seiko 70WVW1TZ3, a LCD 7.0inch WVGA (800x480) display
type with 24-bit RGB interface and Touch-Panel, to panel-generic-dpi
Tested with IGEP v2 board.
Signed-off-by: Enric Balletbo i Serra
---
drivers/video/omap2/displays/panel-generic-dpi.c | 25 ++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 4a9b9ff..644d370 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -181,6 +181,31 @@ static struct panel_config generic_dpi_panels[] = {
.power_off_delay= 0,
.name = "samsung_lte430wq_f0c",
},
+
+ /* Seiko 70WVW1TZ3Z3 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 480,
+
+ .pixel_clock= 33000,
+
+ .hsw= 128,
+ .hfp= 10,
+ .hbp= 10,
+
+ .vsw= 2,
+ .vfp= 4,
+ .vbp= 11,
+ },
+ .acbi = 0x0,
+ .acb= 0x0,
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS,
+ .power_on_delay = 0,
+ .power_off_delay= 0,
+ .name = "seiko_70wvw1tz3",
+ },
};
struct panel_drv_data {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] OMAP: DSS: Support new dpi panels
Hi all, These patches add support for two new panels to the generic-dpi-panel. The first patch adds support for the Seiko 70WVW1TZ3 LCD panel, and the second adds support for the Powertip PH480272T LCD panel. Tested with an IGEP v2 board. Changes since v1: - Change the names of both panels in the panel_config struct to include the name of the manufacturer. - Mention the board which uses those panels. Please consider to add in next merge window, thanks, Enric Balletbo i Serra (2): OMAP: DSS2: Support for Seiko 70WVW1TZ3 OMAP: DSS2: Support for Powertip PH480272T drivers/video/omap2/displays/panel-generic-dpi.c | 50 ++ 1 files changed, 50 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
