[patch 2.6.27-rc7-omap-git 2/2] twl4030 uses gpiolib
From: David Brownell <[EMAIL PROTECTED]>
Make the twl4030 core create a platform device to which its
GPIO code will bind, with platform_data used to configure
board-specific behaviors and configuration.
Update the twl4030 GPIO code:
- Morph its gpio function code into a platform driver.
- Move away from IRQ (and GPIO) numbers hard-wired in headers.
- Hook up the twl4030 GPIO code to gpiolib.
- Start phasing out the older TWL-specific calls ... currently
those are used only by arch/arm/mach-omap2/hsmmc.c setup code.
- Use a mutex for locking, not a binary semaphore.
NOTE: more patches pending: (a) this doesn't use pdata->pullups
to initialize (currently hsmmc code always sets GPIO-0 pullup even
if the board has an external pullup); (b) there's a new gpio
request/free hook forthcoming in 2.6.28, which this should use;
(c) likewise there's a new gpio_to_irq() hook; (d) the irq_chip
set_type() mechanism needs to be supported; (e) needs to move over
to drivers/gpio; (f) upcoming threaded IRQ infrastructure should
be used, when that merges.
NYET-Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig|2
drivers/i2c/chips/twl4030-core.c | 44 +
drivers/i2c/chips/twl4030-gpio.c | 273 ++---
3 files changed, 238 insertions(+), 81 deletions(-)
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -159,7 +159,7 @@ config TWL4030_CORE
config TWL4030_GPIO
bool "TWL4030 GPIO Driver"
- depends on TWL4030_CORE
+ depends on TWL4030_CORE && GPIOLIB
config TWL4030_MADC
tristate "TWL4030 MADC Driver"
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -46,6 +46,12 @@
#define DRIVER_NAME"twl4030"
+#ifdef CONFIG_TWL4030_GPIO
+#define twl_has_gpio() true
+#else
+#define twl_has_gpio() false
+#endif
+
/* Primary Interrupt Handler on TWL4030 Registers */
/* Register Definitions */
@@ -639,6 +645,44 @@ static int add_children(struct twl4030_p
struct twl4030_client *twl = NULL;
int status = 0;
+ if (twl_has_gpio() && pdata->gpio) {
+ twl = &twl4030_modules[TWL4030_SLAVENUM_NUM1];
+
+ pdev = platform_device_alloc("twl4030_gpio", -1);
+ if (!pdev)
+ status = -ENOMEM;
+
+ /* more driver model init */
+ if (status == 0) {
+ pdev->dev.parent = &twl->client->dev;
+ /* device_init_wakeup(&pdev->dev, 1); */
+
+ status = platform_device_add_data(pdev, pdata->gpio,
+ sizeof(*pdata->gpio));
+ }
+
+ /* GPIO module IRQ */
+ if (status == 0) {
+ struct resource r = {
+ .start = pdata->irq_base + 0,
+ .flags = IORESOURCE_IRQ,
+ };
+
+ status = platform_device_add_resources(pdev, &r, 1);
+ }
+
+ if (status == 0)
+ status = platform_device_add(pdev);
+
+ if (status < 0) {
+ platform_device_put(pdev);
+ dev_dbg(&twl->client->dev,
+ "can't create gpio dev, %d\n",
+ status);
+ goto err;
+ }
+ }
+
if (twl_has_rtc()) {
pdev = platform_device_alloc("twl4030_rtc", -1);
if (pdev) {
--- a/drivers/i2c/chips/twl4030-gpio.c
+++ b/drivers/i2c/chips/twl4030-gpio.c
@@ -31,22 +31,31 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include
+#include
+#include
+#include
-#include
#include
#include
-#include
#include
#include
#include
#include
-#include
+
+/* REVISIT when these symbols vanish elsewhere, remove them here too */
+#undef TWL4030_GPIO_IRQ_BASE
+#undef TWL4030_GPIO_IRQ_END
+#undef TWL4030_MODIRQ_GPIO
+
+static struct gpio_chip twl_gpiochip;
+static int twl4030_gpio_irq_base;
+static int twl4030_gpio_irq_end;
+
/* BitField Definitions */
@@ -130,7 +139,7 @@
#define GPIO_32_MASK 0x0003
/* Data structures */
-static struct semaphore gpio_sem;
+static DEFINE_MUTEX(gpio_lock);
/* store usage of each GPIO. - each bit represents one GPIO */
static unsigned int gpio_usage_count;
@@ -147,7 +156,7 @@ static struct task_struct *gpio_unmask_t
/*
* Helper functions to read and write the GPIO ISR and IMR registers as
* 32-bit integers. Functions return 0 on success, non-zero otherwise.
- * The caller must hold a lock on gpio_sem.
+ * The caller must hold gpio_lock.
*/
static int gpio_read_isr(unsigned int *isr)
@@ -197,25 +206,25 @@ static int gpio_write_imr(unsigned int i
*/
static void twl4030_
[patch 2.6.27-rc7-omap-git 0/2] twl4030 uses gpiolib
Two patches follow ... they go on top of (a) the four from Felipe, which he's updating to move the twl_has_XYZ() macros into the core; (b) the pullup tweak from Jagadeesh: - Define and initialize platform data - Be a platform_driver which uses that and gpiolib There's more work to be done, but this is IMO a good start and seems mergeable as-is. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.27-rc7-omap-git 1/2] twl4030 gpio platform data
From: David Brownell <[EMAIL PROTECTED]>
Define platform data for configuring TWL4030 GPIOs,
and provide it for all boards using these chips.
For now all boards use the same fixed assignments for
GPIO and IRQ numbers. Eventually we should be able
to shuffle them without changing platform headers.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
This goes in before code using this data ... so that git
bisection can work.
arch/arm/mach-omap2/board-2430sdp.c |7 +++
arch/arm/mach-omap2/board-3430sdp.c |7 +++
arch/arm/mach-omap2/board-ldp.c |7 +++
arch/arm/mach-omap2/board-omap2evm.c|7 +++
arch/arm/mach-omap2/board-omap3beagle.c | 12
arch/arm/mach-omap2/board-omap3evm.c|7 +++
arch/arm/mach-omap2/board-overo.c |7 +++
include/linux/i2c/twl4030.h | 24 +---
8 files changed, 75 insertions(+), 3 deletions(-)
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -345,6 +345,12 @@ static struct omap_board_config_kernel s
};
+static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+};
+
static struct twl4030_usb_data sdp2430_usb_data = {
.usb_mode = T2_MODE_ULPI,
};
@@ -354,6 +360,7 @@ static struct twl4030_platform_data sdp2
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
+ .gpio = &sdp2430_gpio_data,
.keypad = &sdp2430_kp_data,
.usb= &sdp2430_usb_data,
};
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -300,6 +300,12 @@ static struct omap_board_config_kernel s
{ OMAP_TAG_LCD, &sdp3430_lcd_config },
};
+static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+};
+
static struct twl4030_usb_data sdp3430_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -309,6 +315,7 @@ static struct twl4030_platform_data sdp3
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
+ .gpio = &sdp3430_gpio_data,
.keypad = &sdp3430_kp_data,
.usb= &sdp3430_usb_data,
};
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -183,9 +183,16 @@ static struct omap_board_config_kernel l
{ OMAP_TAG_UART,&ldp_uart_config },
};
+static struct twl4030_gpio_platform_data ldp_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+};
+
static struct twl4030_platform_data ldp_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
+ .gpio = &ldp_gpio_data,
};
static struct i2c_board_info __initdata ldp_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -226,6 +226,12 @@ static struct omap_board_config_kernel o
{ OMAP_TAG_LCD, &omap2_evm_lcd_config },
};
+static struct twl4030_gpio_platform_data omap2evm_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+};
+
static struct twl4030_usb_data omap2evm_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -235,6 +241,7 @@ static struct twl4030_platform_data omap
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
+ .gpio = &omap2evm_gpio_data,
.keypad = omap2evm_kp_data,
.usb= &omap2evm_usb_data,
};
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -110,9 +110,21 @@ static struct omap_uart_config omap3_bea
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
};
+static struct twl4030_gpio_platform_data beagle_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+
+ /* REVISIT: setup() should use twl gpio index
+* - 0 as MMC card detect,
+* - 1 as EHCI port overcurrent (active low)
+*/
+};
+
static struct twl4030_platform_data beagle_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
+ .gpio = &beagle_gpio_data,
};
static struct i2c_board_info __initdata beagle_i2c_boardinfo[] = {
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -90,6 +90,12 @@ static struct omap_u
Re: [PATCH 1/4] i2c: clean add_children a bit
Hi Dave,
On Thu, 25 Sep 2008 10:28:00 -0700, David Brownell <[EMAIL PROTECTED]>
wrote:
> On Thursday 25 September 2008, Felipe Balbi wrote:
>> Clean up add_children a bit before adding more children
>> to twl4030-core.c
>>
>> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
>
> ACK, except for:
>
>> --- a/include/linux/i2c/twl4030.h
>> +++ b/include/linux/i2c/twl4030.h
>> @@ -145,4 +145,10 @@ int twl4030_free_gpio(int gpio);
>> static inline int twl4030charger_usb_en(int enable) { return 0; }
>> #endif
>>
>> +#if defined(CONFIG_RTC_DRV_TWL4030) ||
> defined(CONFIG_RTC_DRV_TWL4030_MODULE)
>> +#define twl_has_rtc() (1)
>> +#else
>> +#define twl_has_rtc() (0)
>> +#endif
>
> Who else would need this, other than the core?
> I think the answer is "nobody" ... so these macros
> belong in the core itself, not a public header.
>
> Also: parens not appropriate around those values; and
> "true" and "false" values would be a bit more clear...
you sure got a point here, I'll update the series when
I get to work tomorrow (actualy today, already 1am).
Anyways, I'll update and resend the series.
--
Best Regards,
Felipe Balbi
http://blog.felipebalbi.com
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
Op 25 sep 2008, om 19:34 heeft Steve Sakoman het volgende geschreven: On Thu, Sep 25, 2008 at 10:22 AM, David Brownell [EMAIL PROTECTED]> wrote: On Thursday 25 September 2008, Arun KS wrote: I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the bug both with N810 and Beagle but not when using CONFIG_SLAB. So it's confirmed that SLUB is a factor, but the root cause is still not known or resolved? Correct. I suspect that somewhere in alsa-lib code is not checking an error return on a memory allocation. When I previously discussed this issue with the folks on alsa-devel they suspected a bug in alsa-lib. I'll give them this additional data and see if someone there wants to help track down the root cause. Hmmm, SLAB makes it trigger the null pointer less, not make it go away completely :( regards, Koen PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Debobs and ETK padconf implementation
On Thursday 25 September 2008, Kevin Hilman wrote: > But I'm still not sure how to best deal with the possibiltity that the > pin might not always be a GPIO, but might be reconfigured/re-mux'd by > this debobs interface as a debug observability pin. Some platforms have interfaces to reserve and unreserve pins. Normally used to ensure drivers can't do things like remux address bus pins, but I suppose it could also be used for this sort of thing too. > My initial thought > was to have the debobs interface gpio_request() the line if it was in > observability mode so that nobody else could use it as a GPIO line, then > gpio_free() it when it was put back into GPIO mode thus making it > available to other users as a GPIO. While that may work, it seems > counter-intuitive and rather kludgy. Not sure what the best way is.. GPIOs are all that get managed with GPIO calls. The pinmux calls use enums for pins, which could be used as identifiers with some reservation scheme that copes with other non-GPIO usages. The worst case, design wise, is OMAP1 chips where many GPIOs can come out on several pins ... and conversely, many pins could be connected to any of several GPIOs (or MPUIOs). - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debobs and ETK padconf implementation
David Brownell wrote: On Thursday 25 September 2008, Kevin Hilman wrote: In that case, what is the proposed method for other kernel code to use the debobs lines? Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 - GPIO29, but then there is no way for a user to know if the GPIO was assigned to debobs or not... Maybe debobs should register as gpiolib 'chip' and reexport those lines ? Would that make sense ? >> I think debobs should simply 'gpio_export' each pin. It does not need to hold them. Peter said the right abstraction here was pads (pins/balls?) not GPIOs, so I'm not sure this is relevant any more, but ... You can't gpio_export() to userspace, via sysfs, without having first done a gpio_request(). And then later a gpio_free() will release that export. So that won't work. Thanks Dave, I was kind of hoping you would chime in on this one :) OK, then I guess Peter's idea of a gpio_chip type abstraction makes more sense. But I'm still not sure how to best deal with the possibiltity that the pin might not always be a GPIO, but might be reconfigured/re-mux'd by this debobs interface as a debug observability pin. My initial thought was to have the debobs interface gpio_request() the line if it was in observability mode so that nobody else could use it as a GPIO line, then gpio_free() it when it was put back into GPIO mode thus making it available to other users as a GPIO. While that may work, it seems counter-intuitive and rather kludgy. Not sure what the best way is... Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
On Tuesday 23 September 2008, Arun KS wrote: > Hi all, > > I am writing an ASOC driver for tlvaic23 on osk5912 platform. [...] Hi. Coincidentally I have been hacking the old aic23 driver in the last few days to make it work on Nokia 770. Don't know if these fixes have any value for linux-omap tree, but I would be glad if anybody finds some of them useful. Patch against old 2.6.16 kernel can be found here: http://lists.maemo.org/pipermail/maemo-developers/2008-September/035053.html A bug with current position detection in 'audio_get_dma_pos' is especially bad as it causes sound stuttering on video playback. -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] twl4030-gpio: Remove default pullup enable/disable of GPIO
> On Thursday 25 September 2008, Pakaravoor, Jagadeesh wrote: >> From: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]> >> >> One twl4030_request_gpio() should not tamper with the pullup >> enabling/disabling of the rest of the GPIOs. So removing the default >> pullup values written to REG_GPIOPUPDCTR1. >> >> Signed-off-by: Girish S G <[EMAIL PROTECTED]> >> Signed-off-by: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]> > > Acked-by: David Brownell <[EMAIL PROTECTED]> > > Now I can remove this from my own GPIO cleanups. ;) that all MMC/SD signals have > an external pullup. (Except maybe DAT4..DAT7 for MMC+.) > > Need for such a pullup should be in board-specific init > data, for boards which need it. I second that, pullup/dn can go in board-specific file. Girish -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc6-omap] ASOC: quieter boot for non-Overo boards
On Thursday 25 September 2008, Steve Sakoman wrote: > On Thu, 2008-09-25 at 09:50 -0700, David Brownell wrote: > > On Thursday 25 September 2008, Tony Lindgren wrote: > > > > Get rid of bogus ASOC boot messages on non-Overo boards. > > > > > > I'm not touching this without an ack from alsa list :) > > > > Has this driver even gone to that list yet? ;) > > Yes, the initial submission was reviewed and acked by folks on > alsa-devel. > > And now that I think of it, this code should never execute on non-overo > boards since they will have their own machine ASoC driver! So this > patch isn't really necessary. But it *did* execute on a Beagle. The kernel had both Overo and Beagle configured in. Ergo the $SUBJECT patch. :) > > I haven't really looked at initialization for this yet, > > but my initial reaction to seeing the Beagle's version > > of the overo.c file is that more sharing should exist. > > (Wasn't the beagle ASOC init described as a clone?) > > This was discussed, but since the overo has some additional > functionality that will be added to the machine portion of the driver it > was decided to have separate machine files for overo and beagle. I'm > waiting for an overo "buddy" board that brings out the additional > microphone inputs before I can add and test this functionality. OK. The amount of code isn't actually that much, but what's there looks like it should be sharable. > > And then ... that, hey, this should hook into the same > > MFD-style initialization as we're making the other > > twl4030 code use. > > > > And finally ... whoa, maybe someone else can split > > out the board-specific bits so they can be put in > > the arch/arm/mach-omap2/board-XYZ.c files, since I'd > > surely lose a lot of time learning ASOC if I were > > to start that! (These messages are right at the > > core of that bit.) > > Putting the board specific bits in the arch/arm/mach-omap2/board-XYZ.c > file has been discussed a number of times on alsa-devel and the folks > there insist that for now (i.e. ASoC V1) this is the proper way to do > things. Hmm, I'm not sure I follow. They want the SOC devices in the wrong place in the driver model tree, potentially impacting power management? I don't want to fight that fight, but ... that seems unwise. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
On Thu, Sep 25, 2008 at 10:22 AM, David Brownell <[EMAIL PROTECTED]> wrote: > On Thursday 25 September 2008, Arun KS wrote: >> >>> I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the >> >>> bug both with N810 and Beagle but not when using CONFIG_SLAB. > > So it's confirmed that SLUB is a factor, but > the root cause is still not known or resolved? Correct. I suspect that somewhere in alsa-lib code is not checking an error return on a memory allocation. When I previously discussed this issue with the folks on alsa-devel they suspected a bug in alsa-lib. I'll give them this additional data and see if someone there wants to help track down the root cause. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] i2c: clean add_children a bit
On Thursday 25 September 2008, Felipe Balbi wrote:
> Clean up add_children a bit before adding more children
> to twl4030-core.c
>
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
ACK, except for:
> --- a/include/linux/i2c/twl4030.h
> +++ b/include/linux/i2c/twl4030.h
> @@ -145,4 +145,10 @@ int twl4030_free_gpio(int gpio);
> static inline int twl4030charger_usb_en(int enable) { return 0; }
> #endif
>
> +#if defined(CONFIG_RTC_DRV_TWL4030) || defined(CONFIG_RTC_DRV_TWL4030_MODULE)
> +#define twl_has_rtc()(1)
> +#else
> +#define twl_has_rtc()(0)
> +#endif
Who else would need this, other than the core?
I think the answer is "nobody" ... so these macros
belong in the core itself, not a public header.
Also: parens not appropriate around those values; and
"true" and "false" values would be a bit more clear...
> +
> #endif /* End of __TWL4030_H */
> --
> 1.6.0.2.307.gc427
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
On Thursday 25 September 2008, Arun KS wrote: > >>> I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the > >>> bug both with N810 and Beagle but not when using CONFIG_SLAB. So it's confirmed that SLUB is a factor, but the root cause is still not known or resolved? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] twl4030-gpio: Remove default pullup enable/disable of GPIO
On Thursday 25 September 2008, Pakaravoor, Jagadeesh wrote:
> From: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
>
> One twl4030_request_gpio() should not tamper with the pullup
> enabling/disabling of the rest of the GPIOs. So removing the default
> pullup values written to REG_GPIOPUPDCTR1.
>
> Signed-off-by: Girish S G <[EMAIL PROTECTED]>
> Signed-off-by: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
Now I can remove this from my own GPIO cleanups. ;)
I was wondering why this code existed in the first
place ... at *best* it makes sense when initializing
the TWL4030. But some boards may need to use some
of those pullups; others, not.
For that matter ... why does the hsmmc init glue always
enable pullups on the card detect signals? Are there
boards which don't actually have external pullups there?
It's fairly conventional that all MMC/SD signals have
an external pullup. (Except maybe DAT4..DAT7 for MMC+.)
Need for such a pullup should be in board-specific init
data, for boards which need it.
- Dave
> ---
> Index: linux-omap-git/drivers/i2c/chips/twl4030-gpio.c
> ===
> --- linux-omap-git.orig/drivers/i2c/chips/twl4030-gpio.c 2008-09-25
> 17:30:27.0 +0530
> +++ linux-omap-git/drivers/i2c/chips/twl4030-gpio.c 2008-09-25
> 18:43:08.932257869 +0530
> @@ -301,7 +301,6 @@ int twl4030_request_gpio(int gpio)
> if (gpio_usage_count & (0x1 << gpio))
> ret = -EBUSY;
> else {
> - u8 clear_pull[6] = { 0, 0, 0, 0, 0, 0 };
> /* First time usage? - switch on GPIO module */
> if (!gpio_usage_count) {
> ret =
> @@ -311,10 +310,6 @@ int twl4030_request_gpio(int gpio)
> }
> if (!ret)
> gpio_usage_count |= (0x1 << gpio);
> -
> - ret =
> - twl4030_i2c_write(TWL4030_MODULE_GPIO, clear_pull,
> - REG_GPIOPUPDCTR1, 5);
> }
> up(&gpio_sem);
> return ret;
>
> --
> With Regards,
> Jagadeesh Bhaskar P
>
>
> Some men see things as they are and say why - I dream things that never were
> and say why not.
> - George Bernard Shaw
> ---
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc6-omap] ASOC: quieter boot for non-Overo boards
On Thu, 2008-09-25 at 09:50 -0700, David Brownell wrote: > On Thursday 25 September 2008, Tony Lindgren wrote: > > > Get rid of bogus ASOC boot messages on non-Overo boards. > > > > I'm not touching this without an ack from alsa list :) > > Has this driver even gone to that list yet? ;) Yes, the initial submission was reviewed and acked by folks on alsa-devel. And now that I think of it, this code should never execute on non-overo boards since they will have their own machine ASoC driver! So this patch isn't really necessary. > I haven't really looked at initialization for this yet, > but my initial reaction to seeing the Beagle's version > of the overo.c file is that more sharing should exist. > (Wasn't the beagle ASOC init described as a clone?) This was discussed, but since the overo has some additional functionality that will be added to the machine portion of the driver it was decided to have separate machine files for overo and beagle. I'm waiting for an overo "buddy" board that brings out the additional microphone inputs before I can add and test this functionality. > And then ... that, hey, this should hook into the same > MFD-style initialization as we're making the other > twl4030 code use. > > And finally ... whoa, maybe someone else can split > out the board-specific bits so they can be put in > the arch/arm/mach-omap2/board-XYZ.c files, since I'd > surely lose a lot of time learning ASOC if I were > to start that! (These messages are right at the > core of that bit.) Putting the board specific bits in the arch/arm/mach-omap2/board-XYZ.c file has been discussed a number of times on alsa-devel and the folks there insist that for now (i.e. ASoC V1) this is the proper way to do things. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debobs and ETK padconf implementation
On Thursday 25 September 2008, Kevin Hilman wrote: > > >> In that case, what is the proposed method for other kernel code to use > >> the debobs lines? > > > > Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 - > > GPIO29, but then there is no way for a user to know if the GPIO was > > assigned to debobs or not... Maybe debobs should register as gpiolib > > 'chip' and reexport those lines ? Would that make sense ? > > I think debobs should simply 'gpio_export' each pin. It does not need > to hold them. Peter said the right abstraction here was pads (pins/balls?) not GPIOs, so I'm not sure this is relevant any more, but ... You can't gpio_export() to userspace, via sysfs, without having first done a gpio_request(). And then later a gpio_free() will release that export. So that won't work. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] some drivers switch away from OMAP-specific GPIO calls
On Thursday 25 September 2008, Tony Lindgren wrote: > > > > This updates most of the OMAP drivers which are in mainline to > > switch to using the cross-platform GPIO calls instead of the > > older OMAP-specific ones. > > > > This is all fairly brainless/obvious stuff. Probably the > > most interesting bit is to observe that the omap-keypad > > code seems to now have a portable core that could work with > > non-OMAP matrix keypads. (That would improve with hardware > > IRQ debouncing enabled, of course...) > > Do you want push this to mainline as part of gpiolib patches? I'l send it now that I have your Signed-off-By. CC a few subsystem maintainers ... but I see no point in splitting this into mini-patchlets. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc6-omap] ASOC: quieter boot for non-Overo boards
On Thursday 25 September 2008, Tony Lindgren wrote: > > Get rid of bogus ASOC boot messages on non-Overo boards. > > I'm not touching this without an ack from alsa list :) Has this driver even gone to that list yet? ;) I haven't really looked at initialization for this yet, but my initial reaction to seeing the Beagle's version of the overo.c file is that more sharing should exist. (Wasn't the beagle ASOC init described as a clone?) And then ... that, hey, this should hook into the same MFD-style initialization as we're making the other twl4030 code use. And finally ... whoa, maybe someone else can split out the board-specific bits so they can be put in the arch/arm/mach-omap2/board-XYZ.c files, since I'd surely lose a lot of time learning ASOC if I were to start that! (These messages are right at the core of that bit.) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] twl4030 driver changes
On Thu, 25 Sep 2008 09:26:12 -0700, David Brownell <[EMAIL PROTECTED]> wrote: > On Thursday 25 September 2008, Felipe Balbi wrote: >> Move twl4030 keypad and usb to new style of >> registration for twl4030 driver > > I can tell I'm going to need to accelerate my > GPIO updates! :) > > Cool. I'll look at this after breakfast... ehehe, I'm planning on playing with madc tomorrow, so maybe yeah, we're gonna need your gpio changes soonish :-) on the other hand, remember I already had a patch converting twl4030-usb to platform_device, I just had to update a few stuff and that was it :-p -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] twl4030 driver changes
On Thursday 25 September 2008, Felipe Balbi wrote: > Move twl4030 keypad and usb to new style of > registration for twl4030 driver I can tell I'm going to need to accelerate my GPIO updates! :) Cool. I'll look at this after breakfast... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC broken on beagleboard with current git
On Thu, Sep 25, 2008 at 3:39 AM, Tony Lindgren <[EMAIL PROTECTED]> wrote: > Hmm, I don't understand how it could work on 3430sdp... > > Looks like board-omap3beagle.c calls hsmmc_init() just like > board-3430sdp.c. Maybe timings have changed and you need > a longer delay somewhere during the init? I can confirm that mmc is also broken on Overo. I'll spend some time today investigating. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] i2c: clean add_children a bit
Clean up add_children a bit before adding more children
to twl4030-core.c
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-core.c | 58 -
include/linux/i2c/twl4030.h |6
2 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index 47f65f8..bbffc40 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -639,34 +639,38 @@ static int add_children(struct twl4030_platform_data
*pdata)
struct twl4030_client *twl = NULL;
int status = 0;
-#ifdef CONFIG_RTC_DRV_TWL4030
- pdev = platform_device_alloc("twl4030_rtc", -1);
- if (pdev) {
- twl = &twl4030_modules[TWL4030_SLAVENUM_NUM3];
- pdev->dev.parent = &twl->client->dev;
- device_init_wakeup(&pdev->dev, 1);
-
- /*
-* FIXME add the relevant IRQ resource, and make the
-* rtc driver use it instead of hard-wiring ...
-*
-* REVISIT platform_data here currently only supports
-* setting up the "msecure" line ... which actually
-* violates the "princple of least privilege", since
-* it's effectively always in "high trust" mode.
-*
-* For now, expect equivalent treatment at board init:
-* setting msecure high. Eventually, Linux might
-* become more aware of those HW security concerns.
-*/
-
- status = platform_device_add(pdev);
- if (status < 0)
- platform_device_put(pdev);
- } else
- status = -ENOMEM;
-#endif
+ if (twl_has_rtc()) {
+ pdev = platform_device_alloc("twl4030_rtc", -1);
+ if (pdev) {
+ twl = &twl4030_modules[TWL4030_SLAVENUM_NUM3];
+ pdev->dev.parent = &twl->client->dev;
+ device_init_wakeup(&pdev->dev, 1);
+
+ /*
+* FIXME add the relevant IRQ resource, and make the
+* rtc driver use it instead of hard-wiring ...
+*
+* REVISIT platform_data here currently only supports
+* setting up the "msecure" line ... which actually
+* violates the "princple of least privilege", since
+* it's effectively always in "high trust" mode.
+*
+* For now, expect equivalent treatment at board init:
+* setting msecure high. Eventually, Linux might
+* become more aware of those HW security concerns.
+*/
+
+ status = platform_device_add(pdev);
+ if (status < 0)
+ platform_device_put(pdev);
+ } else {
+ status = -ENOMEM;
+ goto err;
+ }
+ }
+err:
+ pr_err("failed to add twl4030's children\n");
return status;
}
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 2434ad0..ff1dff4 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -145,4 +145,10 @@ int twl4030_free_gpio(int gpio);
static inline int twl4030charger_usb_en(int enable) { return 0; }
#endif
+#if defined(CONFIG_RTC_DRV_TWL4030) || defined(CONFIG_RTC_DRV_TWL4030_MODULE)
+#define twl_has_rtc() (1)
+#else
+#define twl_has_rtc() (0)
+#endif
+
#endif /* End of __TWL4030_H */
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] i2c: move twl4030-usb to platform_device
use new style twl4030-core to register a platform_device
for twl4030-usb.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-2430sdp.c |6 +
arch/arm/mach-omap2/board-3430sdp.c |5 +
arch/arm/mach-omap2/board-omap2evm.c |5 +
arch/arm/mach-omap2/board-omap3evm.c |4 +
drivers/i2c/chips/Kconfig| 16 --
drivers/i2c/chips/twl4030-core.c | 21 +++
drivers/i2c/chips/twl4030-usb.c | 328 +++---
include/linux/i2c/twl4030.h | 16 ++
8 files changed, 202 insertions(+), 199 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 8c4c9dd..f35c252 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -344,12 +344,18 @@ static struct omap_board_config_kernel sdp2430_config[]
__initdata = {
{OMAP_TAG_SERIAL_CONSOLE, &sdp2430_serial_console_config},
};
+
+static struct twl4030_usb_data sdp2430_usb_data = {
+ .usb_mode = T2_MODE_ULPI,
+};
+
static struct twl4030_platform_data sdp2430_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
.keypad = &sdp2430_kp_data,
+ .usb= &sdp2430_usb_data,
};
static struct i2c_board_info __initdata sdp2430_i2c_boardinfo[] = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index fe1ba4e..e0c39c2 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -300,12 +300,17 @@ static struct omap_board_config_kernel sdp3430_config[]
__initdata = {
{ OMAP_TAG_LCD, &sdp3430_lcd_config },
};
+static struct twl4030_usb_data sdp3430_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
static struct twl4030_platform_data sdp3430_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
.keypad = &sdp3430_kp_data,
+ .usb= &sdp3430_usb_data,
};
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
diff --git a/arch/arm/mach-omap2/board-omap2evm.c
b/arch/arm/mach-omap2/board-omap2evm.c
index 350f147..0f9ad3f 100644
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -226,12 +226,17 @@ static struct omap_board_config_kernel omap2_evm_config[]
__initdata = {
{ OMAP_TAG_LCD, &omap2_evm_lcd_config },
};
+static struct twl4030_usb_data omap2evm_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
static struct twl4030_platform_data omap2evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
/* platform_data for children goes here */
.keypad = omap2evm_kp_data,
+ .usb= &omap2evm_usb_data,
};
static struct i2c_board_info __initdata omap2evm_i2c_boardinfo[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index a9346b1..94e5744 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -90,6 +90,10 @@ static struct omap_uart_config omap3_evm_uart_config
__initdata = {
.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
};
+static struct twl4030_usb_data omap3evm_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index e91be60..121aec9 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -186,22 +186,6 @@ config TWL4030_USB
tristate "TWL4030 USB Transceiver Driver"
depends on TWL4030_CORE
-choice
- prompt "Transceiver mode"
- depends on TWL4030_USB
- help
- TWL4030 USB transceiver can operate in various
- mutually-exclusive modes. Select one of them.
-
-config TWL4030_USB_HS_ULPI
- depends on TWL4030_USB
- bool "High-speed ULPI"
- help
- Say Y here if the TWL4030 is connected to high-speed USB
- controller through a ULPI interface.
-
-endchoice
-
config TWL4030_PWRBUTTON
tristate "TWL4030 Power button Driver"
depends on TWL4030_CORE
diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c
index 241752f..afc566a 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -690,6 +690,27 @@ static int add_children(struct twl4030_platform_data
*pdata)
}
}
+ if (twl_has_usb() && pdata->usb) {
+ pdev = platform_device_alloc("twl4030_usb", -1);
+ if (pdev) {
+ twl = &twl4030_modules[TW
[PATCH 4/4] i2c: twl4030-usb: add 'vbus' sysfs file
vbus sysfs file will report the state of vbus irq coming from
twl4030-usb.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-usb.c | 51 ++-
1 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c
index e790c34..dbd2e43 100644
--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -259,11 +261,17 @@
struct twl4030_usb {
+ struct work_struct irq_work;
struct otg_transceiver otg;
struct device *dev;
+ /* for vbus reporting with irqs disabled */
+ spinlock_t lock;
+
/* pin configuration */
enum twl4030_usb_mode usb_mode;
+
+ unsignedvbus:1;
int irq;
u8 asleep;
};
@@ -529,6 +537,29 @@ static void twl4030_usb_ldo_init(struct twl4030_usb *twl)
twl4030_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, PROTECT_KEY);
}
+static ssize_t twl4030_usb_vbus_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct twl4030_usb *twl = dev_get_drvdata(dev);
+ unsigned long flags;
+ int ret = -EINVAL;
+
+ spin_lock_irqsave(&twl->lock, flags);
+ ret = sprintf(buf, "%s\n", twl->vbus ? "on" : "off");
+ spin_unlock_irqrestore(&twl->lock, flags);
+
+ return ret;
+}
+static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL);
+
+static void twl4030_usb_irq_work(struct work_struct *work)
+{
+ struct twl4030_usb *twl = container_of(work,
+ struct twl4030_usb, irq_work);
+
+ sysfs_notify(&twl->dev->kobj, NULL, "vbus");
+}
+
static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
{
struct twl4030_usb *twl = _twl;
@@ -541,10 +572,13 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
if (val & USB_PRES_RISING) {
twl4030_phy_resume(twl);
twl4030charger_usb_en(1);
+ twl->vbus = 1;
} else {
twl4030charger_usb_en(0);
+ twl->vbus = 0;
twl4030_phy_suspend(twl, 0);
}
+ schedule_work(&twl->irq_work);
return IRQ_HANDLED;
}
@@ -634,16 +668,22 @@ static int __init twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb *twl;
int status;
+ u8 vbus;
twl = kzalloc(sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ WARN_ON(twl4030_i2c_read_u8(TWL4030_MODULE_INT,
+ &vbus, REG_PWR_EDR1) < 0);
+ vbus &= USB_PRES_RISING;
+
twl->dev= &pdev->dev;
twl->irq= TWL4030_PWRIRQ_USB_PRES;
twl->otg.set_host = twl4030_set_host;
twl->otg.set_peripheral = twl4030_set_peripheral;
twl->otg.set_suspend= twl4030_set_suspend;
+ twl->vbus = vbus ? 1 : 0;
if (!pdata) {
dev_info(&pdev->dev, "platform_data not available, defaulting"
@@ -653,6 +693,12 @@ static int __init twl4030_usb_probe(struct platform_device
*pdev)
twl->usb_mode = pdata->usb_mode;
}
+ /* init spinlock for workqueue */
+ spin_lock_init(&twl->lock);
+
+ /* init irq workqueue before request_irq */
+ INIT_WORK(&twl->irq_work, twl4030_usb_irq_work);
+
usb_irq_disable(twl);
status = request_irq(twl->irq, twl4030_usb_irq, 0, "twl4030_usb", twl);
if (status < 0) {
@@ -662,7 +708,6 @@ static int __init twl4030_usb_probe(struct platform_device
*pdev)
return status;
}
-
twl4030_usb_ldo_init(twl);
twl4030_phy_power(twl, 1);
twl4030_i2c_access(twl, 1);
@@ -679,6 +724,9 @@ static int __init twl4030_usb_probe(struct platform_device
*pdev)
dev_set_drvdata(&pdev->dev, twl);
dev_info(&pdev->dev, "Initialized TWL4030 USB module\n");
+ if (device_create_file(&pdev->dev, &dev_attr_vbus))
+ dev_warn(&pdev->dev, "could not create sysfs file\n");
+
return 0;
}
@@ -689,6 +737,7 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
usb_irq_disable(twl);
free_irq(twl->irq, twl);
+ device_remove_file(twl->dev, &dev_attr_vbus);
/* set transceiver mode to power on defaults */
twl4030_usb_set_mode(twl, -1);
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] i2c: move twl4030_keypad to new style registration
let twl4030-core.c take care of twl4030_keypad registration.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-2430sdp.c | 14 --
arch/arm/mach-omap2/board-3430sdp.c | 14 --
arch/arm/mach-omap2/board-omap2evm.c| 16 +---
arch/arm/mach-omap2/board-omap3evm.c| 16 +---
drivers/i2c/chips/twl4030-core.c| 21 +
drivers/input/keyboard/omap-twl4030keypad.c |6 +++---
include/linux/i2c/twl4030.h | 16
7 files changed, 58 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 3649a94..8c4c9dd 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -173,7 +173,7 @@ static int sdp2430_keymap[] = {
0
};
-static struct omap_kp_platform_data sdp2430_kp_data = {
+static struct twl4030_keypad_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
.keymap = sdp2430_keymap,
@@ -182,14 +182,6 @@ static struct omap_kp_platform_data sdp2430_kp_data = {
.irq= TWL4030_MODIRQ_KEYPAD,
};
-static struct platform_device sdp2430_kp_device = {
- .name = "omap_twl4030keypad",
- .id = -1,
- .dev= {
- .platform_data = &sdp2430_kp_data,
- },
-};
-
static int __init msecure_init(void)
{
int ret = 0;
@@ -216,7 +208,6 @@ out:
static struct platform_device *sdp2430_devices[] __initdata = {
&sdp2430_smc91x_device,
&sdp2430_flash_device,
- &sdp2430_kp_device,
&sdp2430_lcd_device,
};
@@ -356,6 +347,9 @@ static struct omap_board_config_kernel sdp2430_config[]
__initdata = {
static struct twl4030_platform_data sdp2430_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
+
+ /* platform_data for children goes here */
+ .keypad = &sdp2430_kp_data,
};
static struct i2c_board_info __initdata sdp2430_i2c_boardinfo[] = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4c60d7b..fe1ba4e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -110,7 +110,7 @@ static int sdp3430_keymap[] = {
0
};
-static struct omap_kp_platform_data sdp3430_kp_data = {
+static struct twl4030_keypad_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
.keymap = sdp3430_keymap,
@@ -119,14 +119,6 @@ static struct omap_kp_platform_data sdp3430_kp_data = {
.irq= TWL4030_MODIRQ_KEYPAD,
};
-static struct platform_device sdp3430_kp_device = {
- .name = "omap_twl4030keypad",
- .id = -1,
- .dev= {
- .platform_data = &sdp3430_kp_data,
- },
-};
-
static int ts_gpio;
static int __init msecure_init(void)
@@ -252,7 +244,6 @@ static struct platform_device sdp3430_lcd_device = {
static struct platform_device *sdp3430_devices[] __initdata = {
&sdp3430_smc91x_device,
- &sdp3430_kp_device,
&sdp3430_lcd_device,
};
@@ -312,6 +303,9 @@ static struct omap_board_config_kernel sdp3430_config[]
__initdata = {
static struct twl4030_platform_data sdp3430_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
+
+ /* platform_data for children goes here */
+ .keypad = &sdp3430_kp_data,
};
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
diff --git a/arch/arm/mach-omap2/board-omap2evm.c
b/arch/arm/mach-omap2/board-omap2evm.c
index 6ce7740..350f147 100644
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -200,23 +200,15 @@ static int omap2evm_keymap[] = {
KEY(3, 3, KEY_P)
};
-static struct omap_kp_platform_data omap2evm_kp_data = {
+static struct twl4030_keypad_data omap2evm_kp_data = {
.rows = 4,
.cols = 4,
- .keymap = omap2evm_keymap,
+ .keymap = omap2evm_keymap,
.keymapsize = ARRAY_SIZE(omap2evm_keymap),
.rep= 1,
.irq= TWL4030_MODIRQ_KEYPAD,
};
-static struct platform_device omap2evm_kp_device = {
- .name = "omap_twl4030keypad",
- .id = -1,
- .dev= {
- .platform_data = &omap2evm_kp_data,
- },
-};
-
static void __init omap2_evm_init_irq(void)
{
omap2_init_common_hw(NULL);
@@ -237,6 +229,9 @@ static struct omap_board_config_kernel omap2_evm_config[]
__initdata = {
static struct twl4030_platform_data omap2evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
+
+ /
[PATCH 0/4] twl4030 driver changes
Move twl4030 keypad and usb to new style of registration for twl4030 driver introduced by David Brownell. This is how the device tree looks now: $ find /sys | grep twl4030 /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/uevent /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/modalias /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/subsystem /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/bus /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/power /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/power/wakeup /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/driver /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/uevent /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/modalias /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/subsystem /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/bus /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/power /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/power/wakeup /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/driver /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/input:input1 /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/uevent /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/modalias /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/subsystem /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/bus /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/power /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/power/wakeup /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/driver /sys/class/i2c-adapter/i2c-1/1-004b/twl4030_rtc/rtc:rtc0 Felipe Balbi (4): i2c: clean add_children a bit i2c: move twl4030_keypad to new style registration i2c: move twl4030-usb to platform_device i2c: twl4030-usb: add 'vbus' sysfs file arch/arm/mach-omap2/board-2430sdp.c | 20 +- arch/arm/mach-omap2/board-3430sdp.c | 19 +- arch/arm/mach-omap2/board-omap2evm.c| 21 +- arch/arm/mach-omap2/board-omap3evm.c| 20 +- drivers/i2c/chips/Kconfig | 16 -- drivers/i2c/chips/twl4030-core.c| 100 ++-- drivers/i2c/chips/twl4030-usb.c | 373 ++- drivers/input/keyboard/omap-twl4030keypad.c |6 +- include/linux/i2c/twl4030.h | 38 +++ 9 files changed, 344 insertions(+), 269 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3 clock: put DPLL into bypass if bypass rate = clk->rate, not hardware rate
When a non-CORE DPLL is enabled via omap3_noncore_dpll_enable(), use the user's desired rate in clk->rate to determine whether to put the DPLL into bypass or lock mode, rather than reading the DPLL's current idle state from its hardware registers. This fixes a bug observed when leaving retention. Non-CORE DPLLs were not being relocked when downstream clocks re-enabled; rather, the DPLL entered bypass mode. Problem reported by Tero Kristo <[EMAIL PROTECTED]>. Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]> --- arch/arm/mach-omap2/clock34xx.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index c89d6bc..df258f7 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -281,9 +281,7 @@ static int omap3_noncore_dpll_enable(struct clk *clk) if (!dd) return -EINVAL; - rate = omap2_get_dpll_rate(clk); - - if (dd->bypass_clk->rate == rate) + if (clk->rate == dd->bypass_clk->rate) r = _omap3_noncore_dpll_bypass(clk); else r = _omap3_noncore_dpll_lock(clk); -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] input: keypad: fix null pointer dereference
From: Felipe Balbi <[EMAIL PROTECTED]>
There was a potential NULL pointer dereference if we don't pass
some fields of omap_kp_platform_data.
At the point of the error message, kp->dbg_dev is not set so it
would generate a NULL pointer dereference right away.
Fix it by using &pdev->dev
Signed-of-by: Felipe Balbi <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 3893d63..48f29d3 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -238,7 +238,7 @@ static int __init omap_kp_probe(struct platform_device
*pdev)
return -ENOMEM;
if (!pdata->rows || !pdata->cols || !pdata->keymap) {
- dev_err(kp->dbg_dev, "No rows, cols or keymap from pdata\n");
+ dev_err(&pdev->dev, "No rows, cols or keymap from pdata\n");
kfree(kp);
return -EINVAL;
}
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: get rid of OMAP_TAG_USB
OMAP_TAGS should vanish soon since they're not generic arm tags.
Most of them can be converted to a platform_data or parsed
from a command line line the serial tag.
For OMAP_TAG_USB we just let boards call omap_usb_init()
passing a pointer to omap_usb_config.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
arch/arm/mach-omap1/board-ams-delta.c |2 +-
arch/arm/mach-omap1/board-generic.c |5 ++---
arch/arm/mach-omap1/board-h2.c |2 +-
arch/arm/mach-omap1/board-h3.c |2 +-
arch/arm/mach-omap1/board-innovator.c |5 ++---
arch/arm/mach-omap1/board-nokia770.c|3 +--
arch/arm/mach-omap1/board-osk.c |2 +-
arch/arm/mach-omap1/board-palmte.c |2 +-
arch/arm/mach-omap1/board-palmtt.c |2 +-
arch/arm/mach-omap1/board-palmz71.c |2 +-
arch/arm/mach-omap1/board-sx1.c |2 +-
arch/arm/mach-omap1/board-voiceblue.c |2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/plat-omap/include/mach/board.h |1 -
arch/arm/plat-omap/include/mach/usb.h |1 +
arch/arm/plat-omap/usb.c| 25 -
18 files changed, 22 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 2e61839..8b40aac 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -175,7 +175,6 @@ static struct omap_usb_config ams_delta_usb_config
__initdata = {
static struct omap_board_config_kernel ams_delta_config[] = {
{ OMAP_TAG_LCD, &ams_delta_lcd_config },
{ OMAP_TAG_UART,&ams_delta_uart_config },
- { OMAP_TAG_USB, &ams_delta_usb_config },
};
static struct resource ams_delta_kp_resources[] = {
@@ -232,6 +231,7 @@ static void __init ams_delta_init(void)
/* Clear latch2 (NAND, LCD, modem enable) */
ams_delta_latch2_write(~0, 0);
+ omap_usb_init(&ams_delta_usb_config);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
}
diff --git a/arch/arm/mach-omap1/board-generic.c
b/arch/arm/mach-omap1/board-generic.c
index 7d26702..e724940 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -62,7 +62,6 @@ static struct omap_uart_config generic_uart_config __initdata
= {
};
static struct omap_board_config_kernel generic_config[] __initdata = {
- { OMAP_TAG_USB, NULL },
{ OMAP_TAG_UART,&generic_uart_config },
};
@@ -70,12 +69,12 @@ static void __init omap_generic_init(void)
{
#ifdef CONFIG_ARCH_OMAP15XX
if (cpu_is_omap15xx()) {
- generic_config[0].data = &generic1510_usb_config;
+ omap_usb_init(&generic1510_usb_config);
}
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
if (!cpu_is_omap1510()) {
- generic_config[0].data = &generic1610_usb_config;
+ omap_usb_init(&generic1610_usb_config);
}
#endif
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 2c12dfa..ab1109b 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -494,7 +494,6 @@ static struct omap_lcd_config h2_lcd_config __initdata = {
};
static struct omap_board_config_kernel h2_config[] __initdata = {
- { OMAP_TAG_USB, &h2_usb_config },
{ OMAP_TAG_UART,&h2_uart_config },
{ OMAP_TAG_LCD, &h2_lcd_config },
};
@@ -549,6 +548,7 @@ static void __init h2_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, h2_i2c_board_info,
ARRAY_SIZE(h2_i2c_board_info));
+ omap_usb_init(&h2_usb_config);
h2_mmc_init();
}
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index c333db1..2bf50f1 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -471,7 +471,6 @@ static struct omap_lcd_config h3_lcd_config __initdata = {
};
static struct omap_board_config_kernel h3_config[] __initdata = {
- { OMAP_TAG_USB, &h3_usb_config },
{ OMAP_TAG_UART,&h3_uart_config },
{ OMAP_TAG_LCD, &h3_lcd_config },
};
@@ -630,6 +629,7 @@ static void __init h3_init(void)
omap_serial_init();
omap_register_i2c_bus(1, 100, h3_i2c_board_info,
ARRAY_SIZE(h3_i2c_board_info));
+ omap_usb_init(&h3_usb_config);
h3_mmc_init();
}
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index 7a97f6b..228c86d 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -409,7 +409,6 @@ static struct omap_uart_config innovator_uart_config
__initdata = {
};
static struct omap_board_confi
[PATCH 0/1] omap tag removal
Hi all, The following patch was *compile tested* only with h4 defconfig. If anyone has the boards to try it on, please do. regards, Felipe Balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3 clock: fix dss1_alwon_fck
Commit a63efb1547ac35dcb0f007090396a3c7510eb691 broke the dss1_alwon_fck
clock enable on 3430ES2+. The clock code was not waiting for the module
to come out of idle.
Problem reported by Rajendra Nayak <[EMAIL PROTECTED]>.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 8ce7097..4722277 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -2304,7 +2304,7 @@ static struct clk dss1_alwon_fck_3430es1 = {
.prcm_mod = OMAP3430_DSS_MOD,
.enable_reg = CM_FCLKEN,
.enable_bit = OMAP3430_EN_DSS1_SHIFT,
- .flags = CLOCK_IN_OMAP343X,
+ .flags = CLOCK_IN_OMAP3430ES1,
.clkdm = { .name = "dss_clkdm" },
.recalc = &followparent_recalc,
};
@@ -2317,7 +2317,7 @@ static struct clk dss1_alwon_fck_3430es2 = {
.enable_reg = CM_FCLKEN,
.enable_bit = OMAP3430_EN_DSS1_SHIFT,
.idlest_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
- .flags = CLOCK_IN_OMAP343X | WAIT_READY,
+ .flags = CLOCK_IN_OMAP3430ES2 | WAIT_READY,
.clkdm = { .name = "dss_clkdm" },
.recalc = &followparent_recalc,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] input: keypad: fix null pointer dereference
There was a potential NULL pointer dereference if we don't pass
some fields of omap_kp_platform_data.
At the point of the error message, kp->dbg_dev is not set so it
would generate a NULL pointer dereference right away.
Fix it by using &pdev->dev
Signed-of-by: Felipe Balbi <[EMAIL PROTECTED]>
---
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 3893d63..48f29d3 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -238,7 +238,7 @@ static int __init omap_kp_probe(struct platform_device
*pdev)
return -ENOMEM;
if (!pdata->rows || !pdata->cols || !pdata->keymap) {
- dev_err(kp->dbg_dev, "No rows, cols or keymap from pdata\n");
+ dev_err(&pdev->dev, "No rows, cols or keymap from pdata\n");
kfree(kp);
return -EINVAL;
}
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
On Thu, Sep 25, 2008 at 7:02 PM, Koen Kooi <[EMAIL PROTECTED]> wrote: > > Op 25 sep 2008, om 15:27 heeft Philip Balister het volgende geschreven: > >> Jarkko Nikula wrote: >>> >>> On Tue, 23 Sep 2008 11:50:53 +0300 >>> "ext Jarkko Nikula" <[EMAIL PROTECTED]> wrote: On Tue, 23 Sep 2008 11:56:00 +0530 "ext Arun KS" <[EMAIL PROTECTED]> wrote: > Hi all, > > I am writing an ASOC driver for tlvaic23 on osk5912 platform. > When do an aplay, I m getting a NULL pointer dereference. I added > some debug prints in the soc/core/pcm_native.c, also in codec and > platform drivers. The null pointer is comming in IOCTL > SNDRV_PCM_IOCTL_SYNC_PTR. Log is pasted below. > It's good that you can reproduce this on OSK as well. I think some configuration difference is revealing this bug out. For instance I can trigger this on Beagle with overo_defconfig + manually adding support for Beagle (CONFIG_MACH_OMAP3_BEAGLE=y) and ASoC Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). But I cannot reproduce this with Beagle defconfig + manually adding support for Overo (CONFIG_MACH_OVERO=y) and ASoC Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). >>> I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the >>> bug both with N810 and Beagle but not when using CONFIG_SLAB. >>> Can you try will the problem disappear on your OSK and Overo if you >>> select slab allocator instead? You find selection under "General >>> setup" menu. >> >> I've also verified this works on a Beagle with Angstrom. >> >> Thanks for tracking this down! > > > For people wanting to test it: > > http://www.angstrom-distribution.org/demo/beagleboard/uImage > > regards, > > Koen > Jarkko that was a great. The problem disappeared now on osk also. Thanks, Arun -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
Op 25 sep 2008, om 15:27 heeft Philip Balister het volgende geschreven: Jarkko Nikula wrote: On Tue, 23 Sep 2008 11:50:53 +0300 "ext Jarkko Nikula" <[EMAIL PROTECTED]> wrote: On Tue, 23 Sep 2008 11:56:00 +0530 "ext Arun KS" <[EMAIL PROTECTED]> wrote: Hi all, I am writing an ASOC driver for tlvaic23 on osk5912 platform. When do an aplay, I m getting a NULL pointer dereference. I added some debug prints in the soc/core/pcm_native.c, also in codec and platform drivers. The null pointer is comming in IOCTL SNDRV_PCM_IOCTL_SYNC_PTR. Log is pasted below. It's good that you can reproduce this on OSK as well. I think some configuration difference is revealing this bug out. For instance I can trigger this on Beagle with overo_defconfig + manually adding support for Beagle (CONFIG_MACH_OMAP3_BEAGLE=y) and ASoC Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). But I cannot reproduce this with Beagle defconfig + manually adding support for Overo (CONFIG_MACH_OVERO=y) and ASoC Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the bug both with N810 and Beagle but not when using CONFIG_SLAB. Can you try will the problem disappear on your OSK and Overo if you select slab allocator instead? You find selection under "General setup" menu. I've also verified this works on a Beagle with Angstrom. Thanks for tracking this down! For people wanting to test it: http://www.angstrom-distribution.org/demo/beagleboard/uImage regards, Koen PGP.sig Description: This is a digitally signed message part
Re: NULL pointer dereference when using ALSA SOC
Jarkko Nikula wrote: On Tue, 23 Sep 2008 11:50:53 +0300 "ext Jarkko Nikula" <[EMAIL PROTECTED]> wrote: On Tue, 23 Sep 2008 11:56:00 +0530 "ext Arun KS" <[EMAIL PROTECTED]> wrote: Hi all, I am writing an ASOC driver for tlvaic23 on osk5912 platform. When do an aplay, I m getting a NULL pointer dereference. I added some debug prints in the soc/core/pcm_native.c, also in codec and platform drivers. The null pointer is comming in IOCTL SNDRV_PCM_IOCTL_SYNC_PTR. Log is pasted below. It's good that you can reproduce this on OSK as well. I think some configuration difference is revealing this bug out. For instance I can trigger this on Beagle with overo_defconfig + manually adding support for Beagle (CONFIG_MACH_OMAP3_BEAGLE=y) and ASoC Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). But I cannot reproduce this with Beagle defconfig + manually adding support for Overo (CONFIG_MACH_OVERO=y) and ASoC Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the bug both with N810 and Beagle but not when using CONFIG_SLAB. Can you try will the problem disappear on your OSK and Overo if you select slab allocator instead? You find selection under "General setup" menu. I've also verified this works on a Beagle with Angstrom. Thanks for tracking this down! Philip Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html smime.p7s Description: S/MIME Cryptographic Signature
[PATCH] twl4030-gpio: Remove default pullup enable/disable of GPIO
From: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
One twl4030_request_gpio() should not tamper with the pullup
enabling/disabling of the rest of the GPIOs. So removing the default
pullup values written to REG_GPIOPUPDCTR1.
Signed-off-by: Girish S G <[EMAIL PROTECTED]>
Signed-off-by: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
---
Index: linux-omap-git/drivers/i2c/chips/twl4030-gpio.c
===
--- linux-omap-git.orig/drivers/i2c/chips/twl4030-gpio.c2008-09-25
17:30:27.0 +0530
+++ linux-omap-git/drivers/i2c/chips/twl4030-gpio.c 2008-09-25
18:43:08.932257869 +0530
@@ -301,7 +301,6 @@ int twl4030_request_gpio(int gpio)
if (gpio_usage_count & (0x1 << gpio))
ret = -EBUSY;
else {
- u8 clear_pull[6] = { 0, 0, 0, 0, 0, 0 };
/* First time usage? - switch on GPIO module */
if (!gpio_usage_count) {
ret =
@@ -311,10 +310,6 @@ int twl4030_request_gpio(int gpio)
}
if (!ret)
gpio_usage_count |= (0x1 << gpio);
-
- ret =
- twl4030_i2c_write(TWL4030_MODULE_GPIO, clear_pull,
- REG_GPIOPUPDCTR1, 5);
}
up(&gpio_sem);
return ret;
--
With Regards,
Jagadeesh Bhaskar P
Some men see things as they are and say why - I dream things that never were
and say why not.
- George Bernard Shaw
---
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch linux-omap-git] twl4030-core: cleanups
* David Brownell <[EMAIL PROTECTED]> [080925 10:34]:
> From: David Brownell <[EMAIL PROTECTED]>
>
> A bunch of little cleanups to twl4030-core.
>
> - Remove needless header inclusions, symbols, and
>forward declarations.
>
> - Make coding style more standard.
>
> And shrink the object size a bit.
Pushing today.
Tony
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
> drivers/i2c/chips/twl4030-core.c | 79 +
> 1 file changed, 28 insertions(+), 51 deletions(-)
>
> --- a/drivers/i2c/chips/twl4030-core.c
> +++ b/drivers/i2c/chips/twl4030-core.c
> @@ -25,34 +25,23 @@
> * 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
> #include
> #include
> -#include
> #include
> #include
> +#include
> #include
> -#include
> #include
> #include
> +#include
>
> #include
> #include
> #include
> #include
> #include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#include
> -#include
>
> #define DRIVER_NAME "twl4030"
>
> @@ -70,16 +59,13 @@
> /* Last - for index max*/
> #define TWL4030_MODULE_LAST TWL4030_MODULE_SECURED_REG
>
> +#define TWL4030_NUM_SLAVES 4
> +
> /* Slave address */
> -#define TWL4030_NUM_SLAVES 0x04
> #define TWL4030_SLAVENUM_NUM00x00
> #define TWL4030_SLAVENUM_NUM10x01
> #define TWL4030_SLAVENUM_NUM20x02
> #define TWL4030_SLAVENUM_NUM30x03
> -#define TWL4030_SLAVEID_ID0 0x48
> -#define TWL4030_SLAVEID_ID1 0x49
> -#define TWL4030_SLAVEID_ID2 0x4A
> -#define TWL4030_SLAVEID_ID3 0x4B
>
> /* Base Address defns */
> /* USB ID */
> @@ -143,9 +129,6 @@
> #define HFCLK_FREQ_38p4_MHZ (3 << 0)
> #define HIGH_PERF_SQ (1 << 3)
>
> -/* on I2C-1 for 2430SDP */
> -#define CONFIG_I2C_TWL4030_ID1
> -
> /* SIH_CTRL registers that aren't defined elsewhere */
> #define TWL4030_INTERRUPTS_BCISIHCTRL0x0d
> #define TWL4030_MADC_MADC_SIH_CTRL 0x67
> @@ -284,9 +267,6 @@ static const struct twl4030_mod_iregs __
> };
>
>
> -/* Helper functions */
> -static void do_twl4030_irq(unsigned int irq, irq_desc_t *desc);
> -
> /* Data Structures */
> /* To have info on T2 IRQ substem activated or not */
> static struct completion irq_event;
> @@ -294,8 +274,7 @@ static struct completion irq_event;
> /* Structure to define on TWL4030 Slave ID */
> struct twl4030_client {
> struct i2c_client *client;
> - const unsigned char address;
> - const char adapter_index;
> + u8 address;
> bool inuse;
>
> /* max numb of i2c_msg required is for read =2 */
> @@ -337,33 +316,24 @@ static struct twl4030mapping twl4030_map
> { TWL4030_SLAVENUM_NUM3, TWL4030_BASEADD_SECURED_REG },
> };
>
> -static struct twl4030_client twl4030_modules[TWL4030_NUM_SLAVES] = {
> - {
> - .address= TWL4030_SLAVEID_ID0,
> - .adapter_index = CONFIG_I2C_TWL4030_ID,
> - },
> - {
> - .address= TWL4030_SLAVEID_ID1,
> - .adapter_index = CONFIG_I2C_TWL4030_ID,
> - },
> - {
> - .address= TWL4030_SLAVEID_ID2,
> - .adapter_index = CONFIG_I2C_TWL4030_ID,
> - },
> - {
> - .address= TWL4030_SLAVEID_ID3,
> - .adapter_index = CONFIG_I2C_TWL4030_ID,
> - },
> -};
> +static struct twl4030_client twl4030_modules[TWL4030_NUM_SLAVES];
>
> /*
> * TWL4030 doesn't have PIH mask, hence dummy function for mask
> * and unmask.
> */
>
> -static void twl4030_i2c_ackirq(unsigned int irq) {}
> -static void twl4030_i2c_disableint(unsigned int irq) {}
> -static void twl4030_i2c_enableint(unsigned int irq) {}
> +static void twl4030_i2c_ackirq(unsigned int irq)
> +{
> +}
> +
> +static void twl4030_i2c_disableint(unsigned int irq)
> +{
> +}
> +
> +static void twl4030_i2c_enableint(unsigned int irq)
> +{
> +}
>
> /* information for processing in the Work Item */
> static struct irq_chip twl4030_irq_chip = {
> @@ -749,7 +719,7 @@ static struct task_struct * __init start
>"twl4030 irq %d", irq);
> if (!thread)
> pr_err("%s: could not create twl4030 irq %d thread!\n",
> -__func__, irq);
> +DRIVER_NAME, irq);
>
> return thread;
> }
> @@ -799,9 +769,15 @@ static int __init power_companion_init(v
> clk_put(osc);
>
> switch (rate) {
> - case 1920 : ctrl = HFCLK_FREQ_19p2_MHZ; break;
> - case 2600 : ctrl = HFCLK_FREQ_26_MHZ; break;
> - case 3840 : ctrl = HFCLK_FREQ_38p4_MHZ; break;
> + case 1920:
> + ctrl = HFCLK_FREQ_19p2
Re: [patch] some drivers switch away from OMAP-specific GPIO calls
* David Brownell <[EMAIL PROTECTED]> [080925 05:36]:
> From: David Brownell <[EMAIL PROTECTED]>
>
> This updates most of the OMAP drivers which are in mainline to
> switch to using the cross-platform GPIO calls instead of the
> older OMAP-specific ones.
>
> This is all fairly brainless/obvious stuff. Probably the
> most interesting bit is to observe that the omap-keypad
> code seems to now have a portable core that could work with
> non-OMAP matrix keypads. (That would improve with hardware
> IRQ debouncing enabled, of course...)
Do you want push this to mainline as part of gpiolib patches?
Will apply to l-o tree.
Tony
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
> By "most", I mean it omits three drivers I know have patches
> pending for the initial 2.6.28 merge window. This should
> apply as-is to both mainline and the OMAP tree ... so if
> it passes muster to the OMAP team it's ready for upstream.
>
> Other than those drivers, most of the relevant changes are
> for board support files.
>
> drivers/input/keyboard/omap-keypad.c | 27 -
> drivers/mtd/nand/ams-delta.c |4 -
> drivers/video/omap/lcd_inn1610.c | 22 +++
> drivers/video/omap/lcd_osk.c | 10 +--
> drivers/video/omap/lcd_sx1.c | 97 +++--
> 5 files changed, 74 insertions(+), 86 deletions(-)
>
> --- a/drivers/input/keyboard/omap-keypad.c
> +++ b/drivers/input/keyboard/omap-keypad.c
> @@ -72,12 +72,9 @@ static unsigned int *col_gpios;
> static void set_col_gpio_val(struct omap_kp *omap_kp, u8 value)
> {
> int col;
> - for (col = 0; col < omap_kp->cols; col++) {
> - if (value & (1 << col))
> - omap_set_gpio_dataout(col_gpios[col], 1);
> - else
> - omap_set_gpio_dataout(col_gpios[col], 0);
> - }
> +
> + for (col = 0; col < omap_kp->cols; col++)
> + gpio_set_value(col_gpios[col], value & (1 << col));
> }
>
> static u8 get_row_gpio_val(struct omap_kp *omap_kp)
> @@ -86,7 +83,7 @@ static u8 get_row_gpio_val(struct omap_k
> u8 value = 0;
>
> for (row = 0; row < omap_kp->rows; row++) {
> - if (omap_get_gpio_datain(row_gpios[row]))
> + if (gpio_get_value(row_gpios[row]))
> value |= (1 << row);
> }
> return value;
> @@ -333,23 +330,23 @@ static int __init omap_kp_probe(struct p
> if (cpu_is_omap24xx()) {
> /* Cols: outputs */
> for (col_idx = 0; col_idx < omap_kp->cols; col_idx++) {
> - if (omap_request_gpio(col_gpios[col_idx]) < 0) {
> + if (gpio_request(col_gpios[col_idx], "omap_kp_col") <
> 0) {
> printk(KERN_ERR "Failed to request"
> "GPIO%d for keypad\n",
> col_gpios[col_idx]);
> goto err1;
> }
> - omap_set_gpio_direction(col_gpios[col_idx], 0);
> + gpio_direction_output(col_gpios[col_idx], 0);
> }
> /* Rows: inputs */
> for (row_idx = 0; row_idx < omap_kp->rows; row_idx++) {
> - if (omap_request_gpio(row_gpios[row_idx]) < 0) {
> + if (gpio_request(row_gpios[row_idx], "omap_kp_row") <
> 0) {
> printk(KERN_ERR "Failed to request"
> "GPIO%d for keypad\n",
> row_gpios[row_idx]);
> goto err2;
> }
> - omap_set_gpio_direction(row_gpios[row_idx], 1);
> + gpio_direction_input(row_gpios[row_idx]);
> }
> } else {
> col_idx = 0;
> @@ -418,10 +415,10 @@ err3:
> device_remove_file(&pdev->dev, &dev_attr_enable);
> err2:
> for (i = row_idx - 1; i >=0; i--)
> - omap_free_gpio(row_gpios[i]);
> + gpio_free(row_gpios[i]);
> err1:
> for (i = col_idx - 1; i >=0; i--)
> - omap_free_gpio(col_gpios[i]);
> + gpio_free(col_gpios[i]);
>
> kfree(omap_kp);
> input_free_device(input_dev);
> @@ -438,9 +435,9 @@ static int omap_kp_remove(struct platfor
> if (cpu_is_omap24xx()) {
> int i;
> for (i = 0; i < omap_kp->cols; i++)
> - omap_free_gpio(col_gpios[i]);
> + gpio_free(col_gpios[i]);
> for (i = 0; i < omap_kp->rows; i++) {
> - omap_free_gpio(row_gpios[i]);
> + gpio_free(row_gpios[i]);
> free_irq(OMAP_GPIO_IRQ(row_gpios[i]), 0);
> }
> } else {
> --- a/drivers/mtd/nand/ams-delta.c
> +++ b/drivers/mtd/nand/ams-delta.c
> @@ -145,7 +145,7 @@ static void ams_delta_hwcontrol(struct m
>
>
Re: [patch 2.6.27-rc6-omap] hsmmc: request_irq says which controller is involved
* David Brownell <[EMAIL PROTECTED]> [080922 00:50]:
> Make the hsmmc driver irq requests say which controller they're
> associated with (e.g. "mmc0") so /proc/interrupts is more useful.
Pushing today.
Tony
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -908,8 +908,8 @@ static int __init omap_mmc_probe(struct platform_device
> *pdev)
> OMAP_HSMMC_READ(host->base, HCTL) | SDBP);
>
> /* Request IRQ for MMC operations */
> - ret = request_irq(host->irq, mmc_omap_irq, IRQF_DISABLED, pdev->name,
> - host);
> + ret = request_irq(host->irq, mmc_omap_irq, IRQF_DISABLED,
> + mmc_hostname(mmc), host);
> if (ret) {
> dev_dbg(mmc_dev(host->mmc), "Unable to grab HSMMC IRQ\n");
> goto err_irq;
> @@ -918,8 +918,8 @@ static int __init omap_mmc_probe(struct platform_device
> *pdev)
> /* Request IRQ for card detect */
> if ((mmc_slot(host).card_detect_irq) && (mmc_slot(host).card_detect)) {
> ret = request_irq(mmc_slot(host).card_detect_irq,
> - omap_mmc_cd_handler, IRQF_DISABLED, "MMC CD",
> - host);
> + omap_mmc_cd_handler, IRQF_DISABLED,
> + mmc_hostname(mmc), host);
> if (ret) {
> dev_dbg(mmc_dev(host->mmc),
> "Unable to grab MMC CD IRQ\n");
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc6-omap] ASOC: quieter boot for non-Overo boards
* David Brownell <[EMAIL PROTECTED]> [080922 00:50]:
> Get rid of bogus ASOC boot messages on non-Overo boards.
I'm not touching this without an ack from alsa list :)
Tony
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> ---
> sound/soc/omap/overo.c |7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> --- a/sound/soc/omap/overo.c
> +++ b/sound/soc/omap/overo.c
> @@ -107,11 +107,11 @@ static int __init overo_soc_init(void)
> {
> int ret;
>
> - printk(KERN_INFO "overo SoC init\n");
> if (!machine_is_overo()) {
> - printk(KERN_ERR "Not Overo!\n");
> + pr_debug("Not Overo!\n");
> return -ENODEV;
> }
> + printk(KERN_INFO "overo SoC init\n");
>
> overo_snd_device = platform_device_alloc("soc-audio", -1);
> if (!overo_snd_device) {
> @@ -135,13 +135,12 @@ err1:
>
> return ret;
> }
> +module_init(overo_soc_init);
>
> static void __exit overo_soc_exit(void)
> {
> platform_device_unregister(overo_snd_device);
> }
> -
> -module_init(overo_soc_init);
> module_exit(overo_soc_exit);
>
> MODULE_AUTHOR("Steve Sakoman <[EMAIL PROTECTED]>");
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debobs and ETK padconf implementation
"Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
> On Thu, Sep 25, 2008 at 02:40:19PM +0300, ext Kevin Hilman wrote:
>> "Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
>>
>> >>
>> >> The cross-platform gpiolib calls should be used here.
>> >>
>> >> > + snprintf(name, sizeof(name), "hw_dbg%d", i);
>> >> > + err = _new_debobs_pad(&debobs_pads[i], name, i,
>> >> > + debobs_root);
>> >> > + if (err) {
>> >> > + omap_free_gpio(ETK_GPIO(i));
>> >> > + return err;
>> >> > + }
>> >> > + }
>> >> > + }
>> >>
>> >> In the successful case, future calls to gpio_request() to use these
>> >> lines will fail, since the line is reserved by the omap_request_gpio()
>> >> call.
>> >>
>> >
>> > Yes. That's intended. If debobs sucessfully claims the GPIO line, noone
>> > else should be allowed to claim it, unless debobs releases it again.
>> >
>>
>> In that case, what is the proposed method for other kernel code to use
>> the debobs lines?
>
> Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 -
> GPIO29, but then there is no way for a user to know if the GPIO was
> assigned to debobs or not... Maybe debobs should register as gpiolib
> 'chip' and reexport those lines ? Would that make sense ?
I think debobs should simply 'gpio_export' each pin. It does not need
to hold them.
Later on, if other kernel code comes along and does a gpio_request() I
think the /sysfs entry for that line will disappear until it has been
gpio_free'd.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed OMAP3 version check
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080925 15:10]:
> Hi,
>
> Here is a fix that works on top of your patch. Tested with ES2.1 and
> ES3.0 chips. I left out the caching for CPU type.
Thanks, I'll merge your fix into my patch and push it to l-o. Will
also create a series for patches for upstream to fix cpu detection.
For the caching of the omap type, if we need to set up something,
let's set up some other register in addition to system_rev. That allows
more tests, like the package type. But let's do it once we really need
it.
Tony
>
> -Tero
>
> >-Original Message-
> >From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
> >Sent: 25 September, 2008 13:18
> >To: Kristo Tero (Nokia-D/Tampere)
> >Cc: linux-omap@vger.kernel.org
> >Subject: Re: [PATCH] Fixed OMAP3 version check
> >
> >Hi,
> >
> >* Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> >> CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
> >> Also added a piece of optimization for CPU type check (omap_type()).
> >>
> >> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> >> ---
> >> arch/arm/mach-omap2/id.c |7 +--
> >> 1 files changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/id.c
> >b/arch/arm/mach-omap2/id.c index
> >> ab7a6e9..4e2b449 100644
> >> --- a/arch/arm/mach-omap2/id.c
> >> +++ b/arch/arm/mach-omap2/id.c
> >> @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
> >>
> >> int omap_type(void)
> >> {
> >> - u32 val = 0;
> >> + static u32 val;
> >> +
> >> + if (val != 0)
> >> + return val;
> >
> >Hmm I guess this would return a random val? :)
> >
> >
> >>if (cpu_is_omap24xx()) {
> >>val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
> >> @@ -169,7 +172,7 @@ void __init omap34xx_check_revision(void)
> >>rev = (idcode >> 28) & 0xff;
> >>
> >>if (hawkeye == 0xb7ae)
> >> - system_rev = 0x34300034 | ((1 + rev) << 12);
> >> + system_rev = 0x34300034 | (rev << 12);
> >>
> >> out:
> >>switch (system_rev) {
> >
> >Well AFAIK here are the numbers for rev:
> >
> >ES1.0 0/* Cannot read idcode register */
> >ES2.0 0
> >ES2.1 1
> >ES3.0 2
> >
> >While ES3.0 TRM claims:
> >
> >ES1.0 0
> >ES2.0 1
> >ES2.1 2
> >ES3.0 3
> >
> >Which I think is incorrect at least for ES2.0 and ES2.1.
> >
> >Can you please try the attached patch and see if it detects
> >your ES3.0 correctly?
> >
> >Tony
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
>-Original Message-
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
>Sent: 25 September, 2008 14:50
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: Balbi Felipe (Nokia-D/Helsinki); linux-omap@vger.kernel.org
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>* Tony Lindgren <[EMAIL PROTECTED]> [080925 14:47]:
>> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080925 14:45]:
>> >
>> >
>> > >-Original Message-
>> > >From: Balbi Felipe (Nokia-D/Helsinki)
>> > >Sent: 25 September, 2008 14:41
>> > >To: ext Tony Lindgren
>> > >Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
>(Nokia-D/Tampere);
>> > >linux-omap@vger.kernel.org
>> > >Subject: Re: [PATCH] Fixed OMAP3 version check
>> > >
>> > >On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
>> > >> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
>> > >> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
>> > >> > > > CPU version was reported incorrectly (e.g. ES3.0
>instead of
>> > >> > > > ES2.1.) Also added a piece of optimization for CPU
>> > >type check (omap_type()).
>> > >> > > >
>> > >> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> > >> > > > ---
>> > >> > > > arch/arm/mach-omap2/id.c |7 +--
>> > >> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
>> > >> > > >
>> > >> > > > diff --git a/arch/arm/mach-omap2/id.c
>> > >b/arch/arm/mach-omap2/id.c
>> > >> > > > index ab7a6e9..4e2b449 100644
>> > >> > > > --- a/arch/arm/mach-omap2/id.c
>> > >> > > > +++ b/arch/arm/mach-omap2/id.c
>> > >> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>> > >> > > >
>> > >> > > > int omap_type(void)
>> > >> > > > {
>> > >> > > > - u32 val = 0;
>> > >> > > > + static u32 val;
>> > >> > > > +
>> > >> > > > + if (val != 0)
>> > >> > > > + return val;
>> > >> > >
>> > >> > > Hmm I guess this would return a random val? :)
>> > >> >
>> > >> > it would return 0, look that val is static.
>> > >>
>> > >> Ah, sorry I did not see the static. So this is to cache the
>> > >result to
>> > >> optimize it? I'd assume this function is only needed during
>> > >some init
>> > >> code hopefully where performance does not matter..
>> > >
>> > >Yeah, it's not like we're gonna check the revision after
>the board
>> > >is botted all up I guess.
>> >
>> > PM code will need to either cache the type information or
>call this
>> > check every time when entering off-mode. Some things work
>> > differently in secure chips. Could probably just cache
>this inside PM code.
>>
>> How about setting up the save and restore registers properly for GP
>> and HS omap once during PM init?
>
>To clarify: Set the save and restore registers and needed
>functions only once during PM init depending on the omap type.
That would be possible also. We only have two additional things to do in
secure OMAP chips anyway, so it is not a big deal. Need to get the damn
thing working first though, can think about optimizations later. >.<
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
Hi,
Here is a fix that works on top of your patch. Tested with ES2.1 and
ES3.0 chips. I left out the caching for CPU type.
-Tero
>-Original Message-
>From: ext Tony Lindgren [mailto:[EMAIL PROTECTED]
>Sent: 25 September, 2008 13:18
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>Hi,
>
>* Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
>> CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
>> Also added a piece of optimization for CPU type check (omap_type()).
>>
>> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> ---
>> arch/arm/mach-omap2/id.c |7 +--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/id.c
>b/arch/arm/mach-omap2/id.c index
>> ab7a6e9..4e2b449 100644
>> --- a/arch/arm/mach-omap2/id.c
>> +++ b/arch/arm/mach-omap2/id.c
>> @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>>
>> int omap_type(void)
>> {
>> -u32 val = 0;
>> +static u32 val;
>> +
>> +if (val != 0)
>> +return val;
>
>Hmm I guess this would return a random val? :)
>
>
>> if (cpu_is_omap24xx()) {
>> val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
>> @@ -169,7 +172,7 @@ void __init omap34xx_check_revision(void)
>> rev = (idcode >> 28) & 0xff;
>>
>> if (hawkeye == 0xb7ae)
>> -system_rev = 0x34300034 | ((1 + rev) << 12);
>> +system_rev = 0x34300034 | (rev << 12);
>>
>> out:
>> switch (system_rev) {
>
>Well AFAIK here are the numbers for rev:
>
>ES1.0 0/* Cannot read idcode register */
>ES2.0 0
>ES2.1 1
>ES3.0 2
>
>While ES3.0 TRM claims:
>
>ES1.0 0
>ES2.0 1
>ES2.1 2
>ES3.0 3
>
>Which I think is incorrect at least for ES2.0 and ES2.1.
>
>Can you please try the attached patch and see if it detects
>your ES3.0 correctly?
>
>Tony
>
0001-OMAP3-Fixed-version-check.patch
Description: 0001-OMAP3-Fixed-version-check.patch
Re: [PATCH] Debobs and ETK padconf implementation
> > In that case, what is the proposed method for other kernel code to use > > the debobs lines? > > Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 - > GPIO29, but then there is no way for a user to know if the GPIO was > assigned to debobs or not... Maybe debobs should register as gpiolib > 'chip' and reexport those lines ? Would that make sense ? > Actually, debobs should be claiming IO pads, not GPIOs. Unfortunately there is no way to do that currently :( Cheers, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debobs and ETK padconf implementation
On Thu, Sep 25, 2008 at 02:40:19PM +0300, ext Kevin Hilman wrote:
> "Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
>
> >>
> >> The cross-platform gpiolib calls should be used here.
> >>
> >> > +snprintf(name, sizeof(name), "hw_dbg%d", i);
> >> > +err = _new_debobs_pad(&debobs_pads[i], name, i,
> >> > +debobs_root);
> >> > +if (err) {
> >> > +omap_free_gpio(ETK_GPIO(i));
> >> > +return err;
> >> > +}
> >> > +}
> >> > +}
> >>
> >> In the successful case, future calls to gpio_request() to use these
> >> lines will fail, since the line is reserved by the omap_request_gpio()
> >> call.
> >>
> >
> > Yes. That's intended. If debobs sucessfully claims the GPIO line, noone
> > else should be allowed to claim it, unless debobs releases it again.
> >
>
> In that case, what is the proposed method for other kernel code to use
> the debobs lines?
Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 -
GPIO29, but then there is no way for a user to know if the GPIO was
assigned to debobs or not... Maybe debobs should register as gpiolib
'chip' and reexport those lines ? Would that make sense ?
Cheers,
Peter.
--
goa is a state of mind
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed OMAP3 version check
* Tony Lindgren <[EMAIL PROTECTED]> [080925 14:47]:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080925 14:45]:
> >
> >
> > >-Original Message-
> > >From: Balbi Felipe (Nokia-D/Helsinki)
> > >Sent: 25 September, 2008 14:41
> > >To: ext Tony Lindgren
> > >Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
> > >(Nokia-D/Tampere); linux-omap@vger.kernel.org
> > >Subject: Re: [PATCH] Fixed OMAP3 version check
> > >
> > >On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
> > >> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
> > >> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
> > >> > > Hi,
> > >> > >
> > >> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> > >> > > > CPU version was reported incorrectly (e.g. ES3.0 instead of
> > >> > > > ES2.1.) Also added a piece of optimization for CPU
> > >type check (omap_type()).
> > >> > > >
> > >> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> > >> > > > ---
> > >> > > > arch/arm/mach-omap2/id.c |7 +--
> > >> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
> > >> > > >
> > >> > > > diff --git a/arch/arm/mach-omap2/id.c
> > >b/arch/arm/mach-omap2/id.c
> > >> > > > index ab7a6e9..4e2b449 100644
> > >> > > > --- a/arch/arm/mach-omap2/id.c
> > >> > > > +++ b/arch/arm/mach-omap2/id.c
> > >> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
> > >> > > >
> > >> > > > int omap_type(void)
> > >> > > > {
> > >> > > > - u32 val = 0;
> > >> > > > + static u32 val;
> > >> > > > +
> > >> > > > + if (val != 0)
> > >> > > > + return val;
> > >> > >
> > >> > > Hmm I guess this would return a random val? :)
> > >> >
> > >> > it would return 0, look that val is static.
> > >>
> > >> Ah, sorry I did not see the static. So this is to cache the
> > >result to
> > >> optimize it? I'd assume this function is only needed during
> > >some init
> > >> code hopefully where performance does not matter..
> > >
> > >Yeah, it's not like we're gonna check the revision after the
> > >board is botted all up I guess.
> >
> > PM code will need to either cache the type information or call this
> > check every time when entering off-mode. Some things work differently in
> > secure chips. Could probably just cache this inside PM code.
>
> How about setting up the save and restore registers properly for GP
> and HS omap once during PM init?
To clarify: Set the save and restore registers and needed functions only
once during PM init depending on the omap type.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed OMAP3 version check
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080925 14:45]:
>
>
> >-Original Message-
> >From: Balbi Felipe (Nokia-D/Helsinki)
> >Sent: 25 September, 2008 14:41
> >To: ext Tony Lindgren
> >Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
> >(Nokia-D/Tampere); linux-omap@vger.kernel.org
> >Subject: Re: [PATCH] Fixed OMAP3 version check
> >
> >On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
> >> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
> >> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
> >> > > Hi,
> >> > >
> >> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> >> > > > CPU version was reported incorrectly (e.g. ES3.0 instead of
> >> > > > ES2.1.) Also added a piece of optimization for CPU
> >type check (omap_type()).
> >> > > >
> >> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> >> > > > ---
> >> > > > arch/arm/mach-omap2/id.c |7 +--
> >> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
> >> > > >
> >> > > > diff --git a/arch/arm/mach-omap2/id.c
> >b/arch/arm/mach-omap2/id.c
> >> > > > index ab7a6e9..4e2b449 100644
> >> > > > --- a/arch/arm/mach-omap2/id.c
> >> > > > +++ b/arch/arm/mach-omap2/id.c
> >> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
> >> > > >
> >> > > > int omap_type(void)
> >> > > > {
> >> > > > -u32 val = 0;
> >> > > > +static u32 val;
> >> > > > +
> >> > > > +if (val != 0)
> >> > > > +return val;
> >> > >
> >> > > Hmm I guess this would return a random val? :)
> >> >
> >> > it would return 0, look that val is static.
> >>
> >> Ah, sorry I did not see the static. So this is to cache the
> >result to
> >> optimize it? I'd assume this function is only needed during
> >some init
> >> code hopefully where performance does not matter..
> >
> >Yeah, it's not like we're gonna check the revision after the
> >board is botted all up I guess.
>
> PM code will need to either cache the type information or call this
> check every time when entering off-mode. Some things work differently in
> secure chips. Could probably just cache this inside PM code.
How about setting up the save and restore registers properly for GP
and HS omap once during PM init?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fixed OMAP3 version check
>-Original Message-
>From: Balbi Felipe (Nokia-D/Helsinki)
>Sent: 25 September, 2008 14:41
>To: ext Tony Lindgren
>Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero
>(Nokia-D/Tampere); linux-omap@vger.kernel.org
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
>> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
>> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
>> > > Hi,
>> > >
>> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
>> > > > CPU version was reported incorrectly (e.g. ES3.0 instead of
>> > > > ES2.1.) Also added a piece of optimization for CPU
>type check (omap_type()).
>> > > >
>> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>> > > > ---
>> > > > arch/arm/mach-omap2/id.c |7 +--
>> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
>> > > >
>> > > > diff --git a/arch/arm/mach-omap2/id.c
>b/arch/arm/mach-omap2/id.c
>> > > > index ab7a6e9..4e2b449 100644
>> > > > --- a/arch/arm/mach-omap2/id.c
>> > > > +++ b/arch/arm/mach-omap2/id.c
>> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>> > > >
>> > > > int omap_type(void)
>> > > > {
>> > > > - u32 val = 0;
>> > > > + static u32 val;
>> > > > +
>> > > > + if (val != 0)
>> > > > + return val;
>> > >
>> > > Hmm I guess this would return a random val? :)
>> >
>> > it would return 0, look that val is static.
>>
>> Ah, sorry I did not see the static. So this is to cache the
>result to
>> optimize it? I'd assume this function is only needed during
>some init
>> code hopefully where performance does not matter..
>
>Yeah, it's not like we're gonna check the revision after the
>board is botted all up I guess.
PM code will need to either cache the type information or call this
check every time when entering off-mode. Some things work differently in
secure chips. Could probably just cache this inside PM code.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] HDQ driver: Remove global pointer
Hi. On Thu, Sep 25, 2008 at 12:19:44PM +0530, Gadiyar, Anand ([EMAIL PROTECTED]) wrote: > From: Madhusudhan Chikkature <[EMAIL PROTECTED]> > > This patch provides the necessary modifications to the driver to > remove the global ptr hdq_data. > > Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]> Looks ok, IA ck the whole serie. Thank you. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed OMAP3 version check
On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
> * Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
> > > Hi,
> > >
> > > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> > > > CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
> > > > Also added a piece of optimization for CPU type check (omap_type()).
> > > >
> > > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> > > > ---
> > > > arch/arm/mach-omap2/id.c |7 +--
> > > > 1 files changed, 5 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > > > index ab7a6e9..4e2b449 100644
> > > > --- a/arch/arm/mach-omap2/id.c
> > > > +++ b/arch/arm/mach-omap2/id.c
> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
> > > >
> > > > int omap_type(void)
> > > > {
> > > > - u32 val = 0;
> > > > + static u32 val;
> > > > +
> > > > + if (val != 0)
> > > > + return val;
> > >
> > > Hmm I guess this would return a random val? :)
> >
> > it would return 0, look that val is static.
>
> Ah, sorry I did not see the static. So this is to cache the result
> to optimize it? I'd assume this function is only needed during some
> init code hopefully where performance does not matter..
Yeah, it's not like we're gonna check the revision after the board is
botted all up I guess.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debobs and ETK padconf implementation
"Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
>>
>> The cross-platform gpiolib calls should be used here.
>>
>> > + snprintf(name, sizeof(name), "hw_dbg%d", i);
>> > + err = _new_debobs_pad(&debobs_pads[i], name, i,
>> > + debobs_root);
>> > + if (err) {
>> > + omap_free_gpio(ETK_GPIO(i));
>> > + return err;
>> > + }
>> > + }
>> > + }
>>
>> In the successful case, future calls to gpio_request() to use these
>> lines will fail, since the line is reserved by the omap_request_gpio()
>> call.
>>
>
> Yes. That's intended. If debobs sucessfully claims the GPIO line, noone
> else should be allowed to claim it, unless debobs releases it again.
>
In that case, what is the proposed method for other kernel code to use
the debobs lines?
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] i2c-omap: Clean-up i2c-omap, v3
* Tony Lindgren <[EMAIL PROTECTED]> [080925 10:55]:
> Minor checkpatch and formatting clean-up. Also update copyrights.
Here's this one updated with correct email addresses for Juha
and Nishant.
Tony
>From 738680e6b79e87132b6cdb15a0b9727b381b87ac Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Thu, 25 Sep 2008 14:35:16 +0300
Subject: [PATCH] i2c-omap: Clean-up i2c-omap
Minor checkpatch and formatting clean-up. Also update copyrights.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5c54864..7308648 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -2,13 +2,16 @@
* TI OMAP I2C master mode driver
*
* Copyright (C) 2003 MontaVista Software, Inc.
- * Copyright (C) 2004 Texas Instruments.
- *
- * Updated to work with multiple I2C interfaces on 24xx by
- * Tony Lindgren <[EMAIL PROTECTED]> and Imre Deak <[EMAIL PROTECTED]>
* Copyright (C) 2005 Nokia Corporation
+ * Copyright (C) 2004 - 2007 Texas Instruments.
*
- * Cleaned up by Juha Yrjölä <[EMAIL PROTECTED]>
+ * Originally written by MontaVista Software, Inc.
+ * Additional contributions by:
+ * Tony Lindgren <[EMAIL PROTECTED]>
+ * Imre Deak <[EMAIL PROTECTED]>
+ * Juha Yrjölä <[EMAIL PROTECTED]>
+ * Syed Khasim <[EMAIL PROTECTED]>
+ * Nishant Menon <[EMAIL PROTECTED]>
*
* 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
@@ -33,8 +36,7 @@
#include
#include
#include
-
-#include
+#include
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -215,7 +217,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1)
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
+ iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
/*
@@ -334,9 +336,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Enable interrupts */
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -402,8 +404,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
w |= OMAP_I2C_CON_XA;
if (!(msg->flags & I2C_M_RD))
w |= OMAP_I2C_CON_TRX;
+
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
@@ -476,7 +480,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
omap_i2c_unidle(dev);
- if ((r = omap_i2c_wait_for_bb(dev)) < 0)
+ r = omap_i2c_wait_for_bb(dev);
+ if (r < 0)
goto out;
for (i = 0; i < num; i++) {
--
1.5.6.rc3.21.g8c6b5
Re: [PATCH 4/8] i2c-omap: FIFO handling support and broken hw workaround for i2c-omap, v3
* Tony Lindgren <[EMAIL PROTECTED]> [080925 10:54]:
> From: Nishanth Menon <[EMAIL PROTECTED]>
>
> Based on an earlier patch from Nishant Menon:
>
> - Transfers can use FIFO on FIFO capable devices
> - Prevents errors for HSI2C if FIFO is not used
> - Implemented errenous handling of STT-STP handling on SDP2430
>
> Also merged in is a fix from Jaron Marini to fix occasional i2c
> hang if OMAP_I2C_CON_STT remains asserted.
>
> Signed-off-by: Jason P Marini <[EMAIL PROTECTED]>
> Signed-off-by: Nishanth Menon <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
Here's this one update with current email address for Nishant
Menon as requested by Nishant.
Tony
>From 5ee572214da6efd0dfbd3765616caa0f03aca25d Mon Sep 17 00:00:00 2001
From: Nishanth Menon <[EMAIL PROTECTED]>
Date: Thu, 25 Sep 2008 10:46:43 +0300
Subject: [PATCH] i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
Based on an earlier patch from Nishant Menon:
- Transfers can use FIFO on FIFO capable devices
- Prevents errors for HSI2C if FIFO is not used
- Implemented errenous handling of STT-STP handling on SDP2430
Also merged in is a fix from Jaron Marini to fix occasional i2c
hang if OMAP_I2C_CON_STT remains asserted.
Signed-off-by: Jason P Marini <[EMAIL PROTECTED]>
Signed-off-by: Nishanth Menon <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 189 -
1 files changed, 149 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0d30790..ded4636 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,8 +55,11 @@
#define OMAP_I2C_SCLL_REG 0x34
#define OMAP_I2C_SCLH_REG 0x38
#define OMAP_I2C_SYSTEST_REG 0x3c
+#define OMAP_I2C_BUFSTAT_REG 0x40
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
+#define OMAP_I2C_IE_XDR (1 << 14) /* TX Buffer drain int enable */
+#define OMAP_I2C_IE_RDR (1 << 13) /* RX Buffer drain int enable */
#define OMAP_I2C_IE_XRDY (1 << 4) /* TX data ready int enable */
#define OMAP_I2C_IE_RRDY (1 << 3) /* RX data ready int enable */
#define OMAP_I2C_IE_ARDY (1 << 2) /* Access ready int enable */
@@ -64,7 +67,8 @@
#define OMAP_I2C_IE_AL (1 << 0) /* Arbitration lost int ena */
/* I2C Status Register (OMAP_I2C_STAT): */
-#define OMAP_I2C_STAT_SBD (1 << 15) /* Single byte data */
+#define OMAP_I2C_STAT_XDR (1 << 14) /* TX Buffer draining */
+#define OMAP_I2C_STAT_RDR (1 << 13) /* RX Buffer draining */
#define OMAP_I2C_STAT_BB (1 << 12) /* Bus busy */
#define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */
#define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */
@@ -78,12 +82,14 @@
/* I2C Buffer Configuration Register (OMAP_I2C_BUF): */
#define OMAP_I2C_BUF_RDMA_EN (1 << 15) /* RX DMA channel enable */
+#define OMAP_I2C_BUF_RXFIF_CLR (1 << 14) /* RX FIFO Clear */
#define OMAP_I2C_BUF_XDMA_EN (1 << 7) /* TX DMA channel enable */
+#define OMAP_I2C_BUF_TXFIF_CLR (1 << 6) /* TX FIFO Clear */
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN (1 << 15) /* I2C module enable */
#define OMAP_I2C_CON_BE (1 << 14) /* Big endian mode */
-#define OMAP_I2C_CON_OPMODE (1 << 12) /* High Speed support */
+#define OMAP_I2C_CON_OPMODE_HS (1 << 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 << 9) /* TX/RX mode (master only) */
@@ -127,7 +133,12 @@ struct omap_i2c_dev {
u8 *buf;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 fifo_size; /* use as flag and value
+ * fifo_size==0 implies no fifo
+ * if set, should be trsh+1
+ */
unsigned rev1:1;
+ unsigned b_hw:1; /* bad h/w fixes */
unsigned idle:1;
u16 iestate; /* Saved interrupt register */
};
@@ -310,6 +321,14 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
+ if (dev->fifo_size)
+ /* Note: setup required fifo size - 1 */
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
+ (dev->fifo_size - 1) << 8 | /* RTRSH */
+ OMAP_I2C_BUF_RXFIF_CLR |
+ (dev->fifo_size - 1) | /* XTRSH */
+ OMAP_I2C_BUF_TXFIF_CLR);
+
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -317,7 +336,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
(OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL));
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -364,6 +384,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev->buf_len);
+ /* Clear the FIFO Buffers */
+
Re: [PATCH] Debobs and ETK padconf implementation
>
> The cross-platform gpiolib calls should be used here.
>
> > + snprintf(name, sizeof(name), "hw_dbg%d", i);
> > + err = _new_debobs_pad(&debobs_pads[i], name, i,
> > + debobs_root);
> > + if (err) {
> > + omap_free_gpio(ETK_GPIO(i));
> > + return err;
> > + }
> > + }
> > + }
>
> In the successful case, future calls to gpio_request() to use these
> lines will fail, since the line is reserved by the omap_request_gpio()
> call.
>
Yes. That's intended. If debobs sucessfully claims the GPIO line, noone
else should be allowed to claim it, unless debobs releases it again.
Cheers,
Peter.
--
goa is a state of mind
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NULL pointer dereference when using ALSA SOC
On Tue, 23 Sep 2008 11:50:53 +0300 "ext Jarkko Nikula" <[EMAIL PROTECTED]> wrote: > On Tue, 23 Sep 2008 11:56:00 +0530 > "ext Arun KS" <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > I am writing an ASOC driver for tlvaic23 on osk5912 platform. > > When do an aplay, I m getting a NULL pointer dereference. I added > > some debug prints in the soc/core/pcm_native.c, also in codec and > > platform drivers. The null pointer is comming in IOCTL > > SNDRV_PCM_IOCTL_SYNC_PTR. Log is pasted below. > > > It's good that you can reproduce this on OSK as well. > > I think some configuration difference is revealing this bug out. For > instance I can trigger this on Beagle with overo_defconfig + manually > adding support for Beagle (CONFIG_MACH_OMAP3_BEAGLE=y) and ASoC > Beagle (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). > > But I cannot reproduce this with Beagle defconfig + manually adding > support for Overo (CONFIG_MACH_OVERO=y) and ASoC Beagle > (CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE=y). > I narrowed this into CONFIG_SLUB. When it's set, I can reproduce the bug both with N810 and Beagle but not when using CONFIG_SLAB. Can you try will the problem disappear on your OSK and Overo if you select slab allocator instead? You find selection under "General setup" menu. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Fixed clockdomain state control for OMAP3
* Paul Walmsley <[EMAIL PROTECTED]> [080923 16:22]:
> On Tue, 16 Sep 2008, Tero Kristo wrote:
>
> > Hardware supervised control for clockdomain power state transitions now
> > enabled in omap3_pm_init(). Also fixed set_pwrdm_state() to allow state
> > changes between sleep states (i.e. RET<->OFF.)
> >
> > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
>
> Acked-by: Paul Walmsley <[EMAIL PROTECTED]>
Pushing today.
Tony
>
>
> > ---
> > arch/arm/mach-omap2/pm34xx.c | 38 +++---
> > 1 files changed, 19 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > index 01b637a..2bccdab 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -227,28 +227,13 @@ static int omap3_can_sleep(void)
> > return 1;
> > }
> >
> > -/* _clkdm_deny_idle - private callback function used by set_pwrdm_state()
> > */
> > -static int _clkdm_deny_idle(struct powerdomain *pwrdm,
> > - struct clockdomain *clkdm)
> > -{
> > - omap2_clkdm_deny_idle(clkdm);
> > - return 0;
> > -}
> > -
> > -/* _clkdm_allow_idle - private callback function used by set_pwrdm_state()
> > */
> > -static int _clkdm_allow_idle(struct powerdomain *pwrdm,
> > -struct clockdomain *clkdm)
> > -{
> > - omap2_clkdm_allow_idle(clkdm);
> > - return 0;
> > -}
> > -
> > /* This sets pwrdm state (other than mpu & core. Currently only ON &
> > * RET are supported. Function is assuming that clkdm doesn't have
> > * hw_sup mode enabled. */
> > static int set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
> > {
> > u32 cur_state;
> > + int sleep_switch = 0;
> > int ret = 0;
> >
> > if (pwrdm == NULL || IS_ERR(pwrdm))
> > @@ -259,8 +244,12 @@ static int set_pwrdm_state(struct powerdomain *pwrdm,
> > u32 state)
> > if (cur_state == state)
> > return ret;
> >
> > - pwrdm_for_each_clkdm(pwrdm, _clkdm_deny_idle);
> > -
> > + if (pwrdm_read_pwrst(pwrdm) < PWRDM_POWER_ON) {
> > + omap2_clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
> > + sleep_switch = 1;
> > + pwrdm_wait_transition(pwrdm);
> > + }
> > +
> > ret = pwrdm_set_next_pwrst(pwrdm, state);
> > if (ret) {
> > printk(KERN_ERR "Unable to set state of powerdomain: %s\n",
> > @@ -268,7 +257,10 @@ static int set_pwrdm_state(struct powerdomain *pwrdm,
> > u32 state)
> > goto err;
> > }
> >
> > - pwrdm_for_each_clkdm(pwrdm, _clkdm_allow_idle);
> > + if (sleep_switch) {
> > + omap2_clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
> > + pwrdm_wait_transition(pwrdm);
> > + }
> >
> > err:
> > return ret;
> > @@ -540,6 +532,12 @@ static int __init pwrdms_setup(struct powerdomain
> > *pwrdm)
> > return set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
> > }
> >
> > +static int __init clkdms_setup(struct clockdomain *clkdm)
> > +{
> > + omap2_clkdm_allow_idle(clkdm);
> > + return 0;
> > +}
> > +
> > int __init omap3_pm_init(void)
> > {
> > struct power_state *pwrst;
> > @@ -566,6 +564,8 @@ int __init omap3_pm_init(void)
> > goto err2;
> > }
> >
> > + (void) clkdm_for_each(clkdms_setup);
> > +
> > mpu_pwrdm = pwrdm_lookup("mpu_pwrdm");
> > if (mpu_pwrdm == NULL) {
> > printk(KERN_ERR "Failed to get mpu_pwrdm\n");
> > --
> > 1.5.4.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC broken on beagleboard with current git
* Koen Kooi <[EMAIL PROTECTED]> [080925 13:25]: > > Op 25 sep 2008, om 11:47 heeft Tony Lindgren het volgende geschreven: > >> * Koen Kooi <[EMAIL PROTECTED]> [080925 12:23]: >>> >>> Op 25 sep 2008, om 10:51 heeft Tony Lindgren het volgende geschreven: >>> * Koen Kooi <[EMAIL PROTECTED]> [080925 11:42]: > Hi, > > I just built a kernel from current git[1] and the mmc controller > doesn't > get detected on boot on my beagleboards. The omap mmc system has > seen a > lot of changes lately, does anyone have a hint where to start > looking > before attemping a bisect? Sounds like the recent mmc init changes we've done: 535e1808d1c77a580815f7d7daacc6c030e29cb1 - 12 september 2008 >>> 8e6e06c71b9d21d85a3ae652868e2802c054a08a - 12 september 2008 >>> c434c15d28c82d92e55897bd265c423e9ab69362 - 24 september 2008 >>> >>> I've verified that it works on omap3430sdp. But mach-omap2/hsmmc.c needs some more work done to support other mmc controllers besides the first one. I don't think other controllers ever worked before these patches either though.. Let me know if you can narrow it down to some commit and I may be able to help further from there. >>> >>> The previous working version I built was based of >>> de1121fdb899f762b9e717f44eaf3fae7c00cd3e which was commited at 13 >>> september 2008, so 535e18.. and 8e6e06c.. don't break it. >> >> OK, good to know. Can you try to git-bisect it? > > That proved to be a lot less work than expected :) > > Last good: 9d1dff8638c9e96a401e1885f9948662e9ff9636 > First bad: c434c15d28c82d92e55897bd265c423e9ab69362 > > So > http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 > > breaks MMC on beagle. Hmm, I don't understand how it could work on 3430sdp... Looks like board-omap3beagle.c calls hsmmc_init() just like board-3430sdp.c. Maybe timings have changed and you need a longer delay somewhere during the init? Maybe sprinkle some printks to hsmmc.c and see if that makes it to work? Also make sure omap_hsmmc.c probe finishes OK. Tony > [1] > http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed OMAP3 version check
* Felipe Balbi <[EMAIL PROTECTED]> [080925 13:24]:
> On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
> > Hi,
> >
> > * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> > > CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
> > > Also added a piece of optimization for CPU type check (omap_type()).
> > >
> > > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> > > ---
> > > arch/arm/mach-omap2/id.c |7 +--
> > > 1 files changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > > index ab7a6e9..4e2b449 100644
> > > --- a/arch/arm/mach-omap2/id.c
> > > +++ b/arch/arm/mach-omap2/id.c
> > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
> > >
> > > int omap_type(void)
> > > {
> > > - u32 val = 0;
> > > + static u32 val;
> > > +
> > > + if (val != 0)
> > > + return val;
> >
> > Hmm I guess this would return a random val? :)
>
> it would return 0, look that val is static.
Ah, sorry I did not see the static. So this is to cache the result
to optimize it? I'd assume this function is only needed during some
init code hopefully where performance does not matter..
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/10] HDQ driver:protect the shared flag
On Thu, Sep 25, 2008 at 12:28:22PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> This patch moves the shared variable into the local structure and
> protects its updation.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 52
> ++
> 1 files changed, 38 insertions(+), 14 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 11:49:45.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 14:41:43.0 +0530
> @@ -61,6 +61,12 @@ struct hdq_data {
> struct clk *hdq_fck;
> u8 hdq_irqstatus;
> spinlock_t hdq_spinlock;
> + /*
> + * Used to control the call to omap_hdq_get and omap_hdq_put.
> + * HDQ Protocol: Write the CMD|REG_address first, followed by
> + * the data wrire or read.
> + */
> + int init_trans;
> };
>
> static int omap_hdq_get(struct hdq_data *hdq_data);
> @@ -505,13 +511,6 @@ omap_hdq_put(struct hdq_data *hdq_data)
> }
>
> /*
> - * Used to control the call to omap_hdq_get and omap_hdq_put.
> - * HDQ Protocol: Write the CMD|REG_address first, followed by
> - * the data wrire or read.
> - */
> -static int init_trans;
> -
> -/*
> * Read a byte of data from the device.
> */
> static u8 omap_w1_read_byte(void *_hdq)
> @@ -522,14 +521,26 @@ static u8 omap_w1_read_byte(void *_hdq)
>
> ret = hdq_read_byte(hdq_data, &val);
> if (ret) {
> - init_trans = 0;
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> + if (ret < 0) {
> + dev_dbg(hdq_data->dev, "Could not acquire mutex\n");
> + return -EINTR;
> + }
> + hdq_data->init_trans = 0;
> + mutex_unlock(&hdq_data->hdq_mutex);
> omap_hdq_put(hdq_data);
> return -1;
> }
>
> /* Write followed by a read, release the module */
> - if (init_trans) {
> - init_trans = 0;
> + if (hdq_data->init_trans) {
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> + if (ret < 0) {
> + dev_dbg(hdq_data->dev, "Could not acquire mutex\n");
> + return -EINTR;
> + }
> + hdq_data->init_trans = 0;
> + mutex_unlock(&hdq_data->hdq_mutex);
> omap_hdq_put(hdq_data);
> }
>
> @@ -542,21 +553,34 @@ static u8 omap_w1_read_byte(void *_hdq)
> static void omap_w1_write_byte(void *_hdq, u8 byte)
> {
> struct hdq_data *hdq_data = _hdq;
> + int ret;
> u8 status;
>
> /* First write to initialize the transfer */
> - if (init_trans == 0)
> + if (hdq_data->init_trans == 0)
> omap_hdq_get(hdq_data);
>
> - init_trans++;
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> + if (ret < 0) {
> + dev_dbg(hdq_data->dev, "Could not acquire mutex\n");
> + return;
> + }
> + hdq_data->init_trans++;
> + mutex_unlock(&hdq_data->hdq_mutex);
>
> hdq_write_byte(hdq_data, byte, &status);
> dev_dbg(hdq_data->dev, "Ctrl status %x\n", status);
>
> /* Second write, data transfered. Release the module */
> - if (init_trans > 1) {
> + if (hdq_data->init_trans > 1) {
> omap_hdq_put(hdq_data);
> - init_trans = 0;
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> + if (ret < 0) {
> + dev_dbg(hdq_data->dev, "Could not acquire mutex\n");
> + return;
> + }
> + hdq_data->init_trans = 0;
> + mutex_unlock(&hdq_data->hdq_mutex);
> }
>
> return;--
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: GPIO: Enable debounce clock only when debounce is enabled v3.
* Paul Walmsley <[EMAIL PROTECTED]> [080916 16:02]: > On Tue, 16 Sep 2008, Jouni Hogander wrote: > > > This patch changes gpio "driver" to enable debounce clock for > > gpio-bank only when debounce is enabled for some gpio in that bank. > > > > Gpio functional clocks are also renamed in clock tree, gpioX_fck -> > > gpioX_dbck. > > > > This patch triggers problem with gpio wake-up and Omap3. Gpios in PER > > domain aren't capable to generate wake-up if PER domain is in sleep > > state. For this iopad wake-up should be used and needed pad > > configuration should be done. Enabling iopad wake-up for gpio pads is > > left for bootloader or omap mux configuration in kernel. > > > > Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]> > > Acked-by: Paul Walmsley <[EMAIL PROTECTED]> Pushing today. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC broken on beagleboard with current git
Op 25 sep 2008, om 11:47 heeft Tony Lindgren het volgende geschreven: * Koen Kooi <[EMAIL PROTECTED]> [080925 12:23]: Op 25 sep 2008, om 10:51 heeft Tony Lindgren het volgende geschreven: * Koen Kooi <[EMAIL PROTECTED]> [080925 11:42]: Hi, I just built a kernel from current git[1] and the mmc controller doesn't get detected on boot on my beagleboards. The omap mmc system has seen a lot of changes lately, does anyone have a hint where to start looking before attemping a bisect? Sounds like the recent mmc init changes we've done: 535e1808d1c77a580815f7d7daacc6c030e29cb1 - 12 september 2008 8e6e06c71b9d21d85a3ae652868e2802c054a08a - 12 september 2008 c434c15d28c82d92e55897bd265c423e9ab69362 - 24 september 2008 I've verified that it works on omap3430sdp. But mach-omap2/hsmmc.c needs some more work done to support other mmc controllers besides the first one. I don't think other controllers ever worked before these patches either though.. Let me know if you can narrow it down to some commit and I may be able to help further from there. The previous working version I built was based of de1121fdb899f762b9e717f44eaf3fae7c00cd3e which was commited at 13 september 2008, so 535e18.. and 8e6e06c.. don't break it. OK, good to know. Can you try to git-bisect it? That proved to be a lot less work than expected :) Last good: 9d1dff8638c9e96a401e1885f9948662e9ff9636 First bad: c434c15d28c82d92e55897bd265c423e9ab69362 So http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 breaks MMC on beagle. regards, Koen Tony [1] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Fixed OMAP3 version check
On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
> Hi,
>
> * Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> > CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
> > Also added a piece of optimization for CPU type check (omap_type()).
> >
> > Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> > ---
> > arch/arm/mach-omap2/id.c |7 +--
> > 1 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > index ab7a6e9..4e2b449 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
> >
> > int omap_type(void)
> > {
> > - u32 val = 0;
> > + static u32 val;
> > +
> > + if (val != 0)
> > + return val;
>
> Hmm I guess this would return a random val? :)
it would return 0, look that val is static.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed OMAP3 version check
Hi,
* Tero Kristo <[EMAIL PROTECTED]> [080916 14:59]:
> CPU version was reported incorrectly (e.g. ES3.0 instead of ES2.1.)
> Also added a piece of optimization for CPU type check (omap_type()).
>
> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/id.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index ab7a6e9..4e2b449 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>
> int omap_type(void)
> {
> - u32 val = 0;
> + static u32 val;
> +
> + if (val != 0)
> + return val;
Hmm I guess this would return a random val? :)
> if (cpu_is_omap24xx()) {
> val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
> @@ -169,7 +172,7 @@ void __init omap34xx_check_revision(void)
> rev = (idcode >> 28) & 0xff;
>
> if (hawkeye == 0xb7ae)
> - system_rev = 0x34300034 | ((1 + rev) << 12);
> + system_rev = 0x34300034 | (rev << 12);
>
> out:
> switch (system_rev) {
Well AFAIK here are the numbers for rev:
ES1.0 0/* Cannot read idcode register */
ES2.0 0
ES2.1 1
ES3.0 2
While ES3.0 TRM claims:
ES1.0 0
ES2.0 1
ES2.1 2
ES3.0 3
Which I think is incorrect at least for ES2.0 and ES2.1.
Can you please try the attached patch and see if it detects your ES3.0
correctly?
Tony
>From 51b488cee3cea1e791728fd6dc69941448a951ce Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Thu, 25 Sep 2008 13:07:23 +0300
Subject: [PATCH] ARM: OMAP: Improve 34xx detection
Fix it for ES3.0. Also use ES3.0 now as the default for unknown
future revision, and make the code easier to follow.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index ab7a6e9..bf3691f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -150,45 +150,49 @@ void __init omap34xx_check_revision(void)
char *rev_name;
/*
+ * We cannot access revision registers on ES1.0.
* If the processor type is Cortex-A8 and the revision is 0x0
- * it means its Cortex r0p0 which is 3430 ES1
+ * it means its Cortex r0p0 which is 3430 ES1.0.
*/
cpuid = read_cpuid(CPUID_ID);
if cpuid >> 4) & 0xfff) == 0xc08) && ((cpuid & 0xf) == 0x0)) {
system_rev = OMAP3430_REV_ES1_0;
+ rev_name = "ES1.0";
goto out;
}
/*
* Detection for 34xx ES2.0 and above can be done with just
* hawkeye and rev. See TRM 1.5.2 Device Identification.
- * Note that rev cannot be used directly as ES1.0 uses value 0.
+ * Note that rev does not map directly to our defined processor
+ * revision numbers as ES1.0 uses value 0.
*/
idcode = read_tap_reg(OMAP_TAP_IDCODE);
hawkeye = (idcode >> 12) & 0x;
rev = (idcode >> 28) & 0xff;
- if (hawkeye == 0xb7ae)
- system_rev = 0x34300034 | ((1 + rev) << 12);
-
-out:
- switch (system_rev) {
- case OMAP3430_REV_ES1_0:
- rev_name = "ES1.0";
- break;
- case OMAP3430_REV_ES2_0:
- rev_name = "ES2.0";
- break;
- case OMAP3430_REV_ES2_1:
- rev_name = "ES2.1";
- break;
- case OMAP3430_REV_ES3_0:
- rev_name = "ES3.0";
- break;
- default:
- rev_name = "Unknown revision\n";
+ if (hawkeye == 0xb7ae) {
+ switch (rev) {
+ case 0:
+ system_rev = OMAP3430_REV_ES2_0;
+ rev_name = "ES2.0";
+ break;
+ case 1:
+ system_rev = OMAP3430_REV_ES2_1;
+ rev_name = "ES2.1";
+ break;
+ case 2:
+ system_rev = OMAP3430_REV_ES3_0;
+ rev_name = "ES3.0";
+ break;
+ default:
+ /* Use the latest known revision as default */
+ system_rev = OMAP3430_REV_ES3_0;
+ rev_name = "Unknown revision\n";
+ }
}
+out:
pr_info("OMAP%04x %s\n", system_rev >> 16, rev_name);
}
Re: [PATCH 2/10] HDQ driver: replace pr_debug with dev_dbg
On Thu, Sep 25, 2008 at 12:22:04PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> Replace pr_debug with dev_dbg with device information added for
> debug prints.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 54
> +++---
> 1 files changed, 30 insertions(+), 24 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-23
> 12:39:19.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-23
> 17:04:50.0 +0530
> @@ -53,6 +53,7 @@ DECLARE_WAIT_QUEUE_HEAD(hdq_wait_queue);
> int W1_ID;
>
> struct hdq_data {
> + struct device *dev;
> resource_size_t hdq_base;
> struct semaphore hdq_semlock;
> int hdq_usecount;
> @@ -182,7 +183,7 @@ hdq_write_byte(struct hdq_data *hdq_data
> ret = wait_event_interruptible_timeout(hdq_wait_queue,
> hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
> if (unlikely(ret < 0)) {
> - pr_debug("wait interrupted");
> + dev_dbg(hdq_data->dev, "wait interrupted");
> return -EINTR;
> }
>
> @@ -191,8 +192,8 @@ hdq_write_byte(struct hdq_data *hdq_data
> spin_unlock_irqrestore(&hdq_data->hdq_spinlock, irqflags);
> /* check irqstatus */
> if (!(*status & OMAP_HDQ_INT_STATUS_TXCOMPLETE)) {
> - pr_debug("timeout waiting for TXCOMPLETE/RXCOMPLETE, %x",
> - *status);
> + dev_dbg(hdq_data->dev, "timeout waiting for"
> + "TXCOMPLETE/RXCOMPLETE, %x", *status);
> return -ETIMEDOUT;
> }
>
> @@ -201,8 +202,8 @@ hdq_write_byte(struct hdq_data *hdq_data
> OMAP_HDQ_CTRL_STATUS_GO,
> OMAP_HDQ_FLAG_CLEAR, &tmp_status);
> if (ret) {
> - pr_debug("timeout waiting GO bit return to zero, %x",
> - tmp_status);
> + dev_dbg(hdq_data->dev, "timeout waiting GO bit"
> + "return to zero, %x", tmp_status);
> return ret;
> }
>
> @@ -220,7 +221,7 @@ static irqreturn_t hdq_isr(int irq, void
> spin_lock_irqsave(&hdq_data->hdq_spinlock, irqflags);
> hdq_data->hdq_irqstatus = hdq_reg_in(hdq_data, OMAP_HDQ_INT_STATUS);
> spin_unlock_irqrestore(&hdq_data->hdq_spinlock, irqflags);
> - pr_debug("hdq_isr: %x", hdq_data->hdq_irqstatus);
> + dev_dbg(hdq_data->dev, "hdq_isr: %x", hdq_data->hdq_irqstatus);
>
> if (hdq_data->hdq_irqstatus &
> (OMAP_HDQ_INT_STATUS_TXCOMPLETE | OMAP_HDQ_INT_STATUS_RXCOMPLETE
> @@ -284,7 +285,8 @@ static int _omap_hdq_reset(struct hdq_da
> ret = hdq_wait_for_flag(hdq_data, OMAP_HDQ_SYSSTATUS,
> OMAP_HDQ_SYSSTATUS_RESETDONE, OMAP_HDQ_FLAG_SET, &tmp_status);
> if (ret)
> - pr_debug("timeout waiting HDQ reset, %x", tmp_status);
> + dev_dbg(hdq_data->dev, "timeout waiting HDQ reset, %x",
> + tmp_status);
> else {
> hdq_reg_out(hdq_data, OMAP_HDQ_CTRL_STATUS,
> OMAP_HDQ_CTRL_STATUS_CLOCKENABLE |
> @@ -332,7 +334,7 @@ omap_hdq_break(struct hdq_data *hdq_data
> ret = wait_event_interruptible_timeout(hdq_wait_queue,
> hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
> if (unlikely(ret < 0)) {
> - pr_debug("wait interrupted");
> + dev_dbg(hdq_data->dev, "wait interrupted");
> up(&hdq_data->hdq_semlock);
> return -EINTR;
> }
> @@ -342,7 +344,8 @@ omap_hdq_break(struct hdq_data *hdq_data
> spin_unlock_irqrestore(&hdq_data->hdq_spinlock, irqflags);
> /* check irqstatus */
> if (!(tmp_status & OMAP_HDQ_INT_STATUS_TIMEOUT)) {
> - pr_debug("timeout waiting for TIMEOUT, %x", tmp_status);
> + dev_dbg(hdq_data->dev, "timeout waiting for TIMEOUT, %x",
> + tmp_status);
> up(&hdq_data->hdq_semlock);
> return -ETIMEDOUT;
> }
> @@ -355,8 +358,8 @@ omap_hdq_break(struct hdq_data *hdq_data
> OMAP_HDQ_CTRL_STATUS_GO, OMAP_HDQ_FLAG_CLEAR,
> &tmp_status);
> if (ret)
> - pr_debug("timeout waiting INIT&GO bits return to zero, %x",
> - tmp_status);
> + dev_dbg(hdq_data->dev, "timeout waiting INIT&GO bits"
> + "return to zero, %x", tmp_status);
>
> up(&hdq_data->hdq_semlock);
> return ret;
> @@ -402,7 +405,8 @@ static int hdq_read_byte(struct hdq_data
> spin_unlock_irqrestore(&hdq_data->hdq_spinlock, irqflags);
> /*
Re: [PATCH 7/10] HDQ driver:replace semaphore with mutex
On Thu, Sep 25, 2008 at 12:27:23PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> This patch replaces the usage of semaphore by mutex.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 42
> ++
> 1 files changed, 22 insertions(+), 20 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 11:13:12.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 11:49:45.0 +0530
> @@ -55,7 +55,7 @@ static int w1_id;
> struct hdq_data {
> struct device *dev;
> void __iomem*hdq_base;
> - struct semaphore hdq_semlock;
> + struct mutex hdq_mutex;
> int hdq_usecount;
> struct clk *hdq_ick;
> struct clk *hdq_fck;
> @@ -308,12 +308,12 @@ omap_hdq_break(struct hdq_data *hdq_data
> u8 tmp_status;
> unsigned long irqflags;
>
> - ret = down_interruptible(&hdq_data->hdq_semlock);
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> if (ret < 0)
> return -EINTR;
>
> if (!hdq_data->hdq_usecount) {
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return -EINVAL;
> }
>
> @@ -335,7 +335,7 @@ omap_hdq_break(struct hdq_data *hdq_data
> hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
> if (ret < 0) {
> dev_dbg(hdq_data->dev, "wait interrupted");
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return -EINTR;
> }
>
> @@ -346,7 +346,7 @@ omap_hdq_break(struct hdq_data *hdq_data
> if (!(tmp_status & OMAP_HDQ_INT_STATUS_TIMEOUT)) {
> dev_dbg(hdq_data->dev, "timeout waiting for TIMEOUT, %x",
> tmp_status);
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return -ETIMEDOUT;
> }
> /*
> @@ -361,7 +361,7 @@ omap_hdq_break(struct hdq_data *hdq_data
> dev_dbg(hdq_data->dev, "timeout waiting INIT&GO bits"
> "return to zero, %x", tmp_status);
>
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return ret;
> }
>
> @@ -371,12 +371,12 @@ static int hdq_read_byte(struct hdq_data
> u8 status;
> unsigned long irqflags;
>
> - ret = down_interruptible(&hdq_data->hdq_semlock);
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> if (ret < 0)
> return -EINTR;
>
> if (!hdq_data->hdq_usecount) {
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return -EINVAL;
> }
>
> @@ -407,13 +407,13 @@ static int hdq_read_byte(struct hdq_data
> if (!(status & OMAP_HDQ_INT_STATUS_RXCOMPLETE)) {
> dev_dbg(hdq_data->dev, "timeout waiting for"
> "RXCOMPLETE, %x", status);
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return -ETIMEDOUT;
> }
> }
> /* the data is ready. Read it in! */
> *val = hdq_reg_in(hdq_data, OMAP_HDQ_RX_DATA);
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
>
> return 0;
>
> @@ -427,13 +427,13 @@ omap_hdq_get(struct hdq_data *hdq_data)
> {
> int ret = 0;
>
> - ret = down_interruptible(&hdq_data->hdq_semlock);
> + ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> if (ret < 0)
> return -EINTR;
>
> if (OMAP_HDQ_MAX_USER == hdq_data->hdq_usecount) {
> dev_dbg(hdq_data->dev, "attempt to exceed the max use count");
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> ret = -EINVAL;
> } else {
> hdq_data->hdq_usecount++;
> @@ -443,14 +443,14 @@ omap_hdq_get(struct hdq_data *hdq_data)
> dev_dbg(hdq_data->dev, "Can not enable ick\n");
> clk_put(hdq_data->hdq_ick);
> clk_put(hdq_data->hdq_fck);
> - up(&hdq_data->hdq_semlock);
> + mutex_unlock(&hdq_data->hdq_mutex);
> return -ENODEV;
> }
> if (clk_enable(hdq_data->hdq_fck)) {
> dev_dbg(hdq_data->dev, "Can not enable fck\n");
> clk_put(hdq
Re: [PATCH 6/10] HDQ driver: use ioremap for HDQ base
On Thu, Sep 25, 2008 at 12:26:17PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> This patch provides the ioremap related changes to the driver.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 21 ++---
> 1 files changed, 14 insertions(+), 7 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 10:46:53.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 11:13:12.0 +0530
> @@ -54,7 +54,7 @@ static int w1_id;
>
> struct hdq_data {
> struct device *dev;
> - resource_size_t hdq_base;
> + void __iomem*hdq_base;
> struct semaphore hdq_semlock;
> int hdq_usecount;
> struct clk *hdq_ick;
> @@ -99,12 +99,12 @@ static struct w1_bus_master omap_w1_mast
> */
> static inline u8 hdq_reg_in(struct hdq_data *hdq_data, u32 offset)
> {
> - return omap_readb(hdq_data->hdq_base + offset);
> + return __raw_readb(hdq_data->hdq_base + offset);
> }
>
> static inline u8 hdq_reg_out(struct hdq_data *hdq_data, u32 offset, u8 val)
> {
> - omap_writeb(val, hdq_data->hdq_base + offset);
> + __raw_writeb(val, hdq_data->hdq_base + offset);
>
> return val;
> }
> @@ -112,9 +112,9 @@ static inline u8 hdq_reg_out(struct hdq_
> static inline u8 hdq_reg_merge(struct hdq_data *hdq_data, u32 offset,
> u8 val, u8 mask)
> {
> - u8 new_val = (omap_readb(hdq_data->hdq_base + offset) & ~mask)
> + u8 new_val = (__raw_readb(hdq_data->hdq_base + offset) & ~mask)
> | (val & mask);
> - omap_writeb(new_val, hdq_data->hdq_base + offset);
> + __raw_writeb(new_val, hdq_data->hdq_base + offset);
>
> return new_val;
> }
> @@ -589,7 +589,12 @@ static int __init omap_hdq_probe(struct
> goto err_resource;
> }
>
> - hdq_data->hdq_base = res->start;
> + hdq_data->hdq_base = ioremap(res->start, SZ_4K);
> + if (!hdq_data->hdq_base) {
> + dev_dbg(&pdev->dev, "ioremap failed\n");
> + ret = -EINVAL;
> + goto err_ioremap;
> + }
>
> /* get interface & functional clock objects */
> hdq_data->hdq_ick = clk_get(&pdev->dev, "hdq_ick");
> @@ -668,8 +673,9 @@ err_ick:
> clk_put(hdq_data->hdq_fck);
>
> err_clk:
> - hdq_data->hdq_base = NULL;
> + iounmap(hdq_data->hdq_base);
>
> +err_ioremap:
> err_resource:
> platform_set_drvdata(pdev, NULL);
> kfree(hdq_data);
> @@ -695,6 +701,7 @@ static int omap_hdq_remove(struct platfo
> clk_put(hdq_data->hdq_fck);
> free_irq(INT_24XX_HDQ_IRQ, hdq_data);
> platform_set_drvdata(pdev, NULL);
> + iounmap(hdq_data->hdq_base);
> kfree(hdq_data);
>
> return 0;
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/10] HDQ driver: modify probe fn exit points
On Thu, Sep 25, 2008 at 12:23:22PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> This patch fix the exit paths in the probe function.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 85
> ++
> 1 files changed, 45 insertions(+), 40 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-23
> 17:04:50.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 09:33:39.0 +0530
> @@ -573,17 +573,20 @@ static int __init omap_hdq_probe(struct
> return -ENODEV;
>
> hdq_data = kmalloc(sizeof(*hdq_data), GFP_KERNEL);
> - if (!hdq_data)
> - return -ENODEV;
> + if (!hdq_data) {
> + dev_dbg(&pdev->dev, "unable to allocate memory\n");
> + ret = -ENODEV;
> + goto err_kmalloc;
> + }
>
> hdq_data->dev = &pdev->dev;
> platform_set_drvdata(pdev, hdq_data);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (res == NULL) {
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return -ENXIO;
> + if (!res) {
> + dev_dbg(&pdev->dev, "unable to get resource\n");
> + ret = ENXIO;
> + goto err_resource;
> }
>
> hdq_data->hdq_base = res->start;
> @@ -596,15 +599,12 @@ static int __init omap_hdq_probe(struct
> dev_dbg(&pdev->dev, "Can't get HDQ clock objects\n");
> if (IS_ERR(hdq_data->hdq_ick)) {
> ret = PTR_ERR(hdq_data->hdq_ick);
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return ret;
> + goto err_clk;
> }
> if (IS_ERR(hdq_data->hdq_fck)) {
> ret = PTR_ERR(hdq_data->hdq_fck);
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return ret;
> + clk_put(hdq_data->hdq_ick);
> + goto err_clk;
> }
> }
>
> @@ -613,21 +613,14 @@ static int __init omap_hdq_probe(struct
>
> if (clk_enable(hdq_data->hdq_ick)) {
> dev_dbg(&pdev->dev, "Can not enable ick\n");
> - clk_put(hdq_data->hdq_ick);
> - clk_put(hdq_data->hdq_fck);
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err_ick;
> }
>
> if (clk_enable(hdq_data->hdq_fck)) {
> dev_dbg(&pdev->dev, "Can not enable fck\n");
> - clk_disable(hdq_data->hdq_ick);
> - clk_put(hdq_data->hdq_ick);
> - clk_put(hdq_data->hdq_fck);
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err_fck;
> }
>
> rev = hdq_reg_in(hdq_data, OMAP_HDQ_REVISION);
> @@ -639,20 +632,14 @@ static int __init omap_hdq_probe(struct
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return -ENXIO;
> + ret = -ENXIO;
> + goto err_irq;
> }
>
> - if (request_irq(irq, hdq_isr, IRQF_DISABLED, "OMAP HDQ",
> - hdq_data)) {
> - dev_dbg(&pdev->dev, "request_irq failed\n");
> - clk_disable(hdq_data->hdq_ick);
> - clk_put(hdq_data->hdq_ick);
> - clk_put(hdq_data->hdq_fck);
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return -ENODEV;
> + ret = request_irq(irq, hdq_isr, IRQF_DISABLED, "omap_hdq", hdq_data);
> + if (ret < 0) {
> + dev_dbg(&pdev->dev, "could not request irq\n");
> + goto err_irq;
> }
>
> /* don't clock the HDQ until it is needed */
> @@ -664,14 +651,32 @@ static int __init omap_hdq_probe(struct
> ret = w1_add_master_device(&omap_w1_master);
> if (ret) {
> dev_dbg(&pdev->dev, "Failure in registering w1 master\n");
> - clk_put(hdq_data->hdq_ick);
> - clk_put(hdq_data->hdq_fck);
> - platform_set_drvdata(pdev, NULL);
> - kfree(hdq_data);
> - return ret;
> + goto err_w1;
> }
>
> return 0;
> +
> +err_w1:
> +err_irq:
> + clk_disable(hdq_data->hdq_fck);
> +
> +err_fck:
> + clk_disable(hdq_data->hdq_ick);
> +
> +err_ick:
> + clk_put(hdq_data->hdq_ick);
Re: [PATCH 4/10] HDQ driver: remove unlikely calls
On Thu, Sep 25, 2008 at 12:24:18PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> Remove the unneeded "unlikely" calls.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 09:33:39.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 10:10:07.0 +0530
> @@ -138,7 +138,7 @@ static int hdq_wait_for_flag(struct hdq_
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(1);
> }
> - if (unlikely(*status & flag))
> + if (*status & flag)
> ret = -ETIMEDOUT;
> } else if (flag_set == OMAP_HDQ_FLAG_SET) {
> /* wait for the flag set */
> @@ -147,7 +147,7 @@ static int hdq_wait_for_flag(struct hdq_
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(1);
> }
> - if (unlikely(!(*status & flag)))
> + if (!(*status & flag))
> ret = -ETIMEDOUT;
> } else
> return -EINVAL;
> @@ -182,7 +182,7 @@ hdq_write_byte(struct hdq_data *hdq_data
> /* wait for the TXCOMPLETE bit */
> ret = wait_event_interruptible_timeout(hdq_wait_queue,
> hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
> - if (unlikely(ret < 0)) {
> + if (ret < 0) {
> dev_dbg(hdq_data->dev, "wait interrupted");
> return -EINTR;
> }
> @@ -333,7 +333,7 @@ omap_hdq_break(struct hdq_data *hdq_data
> /* wait for the TIMEOUT bit */
> ret = wait_event_interruptible_timeout(hdq_wait_queue,
> hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
> - if (unlikely(ret < 0)) {
> + if (ret < 0) {
> dev_dbg(hdq_data->dev, "wait interrupted");
> up(&hdq_data->hdq_semlock);
> return -EINTR;
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] HDQ driver: Make hdq_reg_out as void
On Thu, Sep 25, 2008 at 12:31:38PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> Make hdq_reg_out as void and remove suspend, resume from the driver structure.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 12 +---
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 15:37:18.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-25
> 10:19:22.0 +0530
> @@ -55,11 +55,13 @@ static int w1_id;
> struct hdq_data {
> struct device *dev;
> void __iomem*hdq_base;
> + /* lock status update */
> struct mutex hdq_mutex;
> int hdq_usecount;
> struct clk *hdq_ick;
> struct clk *hdq_fck;
> u8 hdq_irqstatus;
> + /* device lock */
> spinlock_t hdq_spinlock;
> /*
>* Used to control the call to omap_hdq_get and omap_hdq_put.
> @@ -79,8 +81,6 @@ static int omap_hdq_remove(struct platfo
> static struct platform_driver omap_hdq_driver = {
> .probe =omap_hdq_probe,
> .remove = omap_hdq_remove,
> - .suspend = NULL,
> - .resume = NULL,
> .driver = {
> .name = "omap_hdq",
> },
> @@ -106,11 +106,9 @@ static inline u8 hdq_reg_in(struct hdq_d
> return __raw_readb(hdq_data->hdq_base + offset);
> }
>
> -static inline u8 hdq_reg_out(struct hdq_data *hdq_data, u32 offset, u8 val)
> +static inline void hdq_reg_out(struct hdq_data *hdq_data, u32 offset, u8 val)
> {
> __raw_writeb(val, hdq_data->hdq_base + offset);
> -
> - return val;
> }
>
> static inline u8 hdq_reg_merge(struct hdq_data *hdq_data, u32 offset,
> @@ -715,17 +713,17 @@ omap_hdq_init(void)
> {
> return platform_driver_register(&omap_hdq_driver);
> }
> +module_init(omap_hdq_init);
>
> static void __exit
> omap_hdq_exit(void)
> {
> platform_driver_unregister(&omap_hdq_driver);
> }
> -
> -module_init(omap_hdq_init);
> module_exit(omap_hdq_exit);
>
> module_param(w1_id, int, S_IRUSR);
> +MODULE_PARM_DESC(w1_id, "1-wire id for the slave detection");
>
> MODULE_AUTHOR("Texas Instruments");
> MODULE_DESCRIPTION("HDQ driver Library");
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/10] HDQ driver: Fix indentation and commenting style
On Thu, Sep 25, 2008 at 12:30:48PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> This patch fixes the indentation, commenting style of a single line comment.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 81
> +++---
> 1 files changed, 29 insertions(+), 52 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 14:41:43.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 15:37:18.0 +0530
> @@ -77,12 +77,12 @@ static int __init omap_hdq_probe(struct
> static int omap_hdq_remove(struct platform_device *pdev);
>
> static struct platform_driver omap_hdq_driver = {
> - .probe = omap_hdq_probe,
> - .remove = omap_hdq_remove,
> - .suspend = NULL,
> - .resume = NULL,
> - .driver = {
> - .name = "omap_hdq",
> + .probe =omap_hdq_probe,
> + .remove = omap_hdq_remove,
> + .suspend = NULL,
> + .resume = NULL,
> + .driver = {
> + .name = "omap_hdq",
> },
> };
>
> @@ -100,9 +100,7 @@ static struct w1_bus_master omap_w1_mast
> .search = omap_w1_search_bus,
> };
>
> -/*
> - * HDQ register I/O routines
> - */
> +/* HDQ register I/O routines */
> static inline u8 hdq_reg_in(struct hdq_data *hdq_data, u32 offset)
> {
> return __raw_readb(hdq_data->hdq_base + offset);
> @@ -161,11 +159,8 @@ static int hdq_wait_for_flag(struct hdq_
> return ret;
> }
>
> -/*
> - * write out a byte and fill *status with HDQ_INT_STATUS
> - */
> -static int
> -hdq_write_byte(struct hdq_data *hdq_data, u8 val, u8 *status)
> +/* write out a byte and fill *status with HDQ_INT_STATUS */
> +static int hdq_write_byte(struct hdq_data *hdq_data, u8 val, u8 *status)
> {
> int ret;
> u8 tmp_status;
> @@ -216,9 +211,7 @@ hdq_write_byte(struct hdq_data *hdq_data
> return ret;
> }
>
> -/*
> - * HDQ Interrupt service routine.
> - */
> +/* HDQ Interrupt service routine */
> static irqreturn_t hdq_isr(int irq, void *_hdq)
> {
> struct hdq_data *hdq_data = _hdq;
> @@ -239,17 +232,13 @@ static irqreturn_t hdq_isr(int irq, void
> return IRQ_HANDLED;
> }
>
> -/*
> - * HDQ Mode: always return success.
> - */
> +/* HDQ Mode: always return success */
> static u8 omap_w1_reset_bus(void *_hdq)
> {
> return 0;
> }
>
> -/*
> - * W1 search callback function.
> - */
> +/* W1 search callback function */
> static void omap_w1_search_bus(void *_hdq, u8 search_type,
> w1_slave_found_callback slave_found)
> {
> @@ -304,11 +293,8 @@ static int _omap_hdq_reset(struct hdq_da
> return ret;
> }
>
> -/*
> - * Issue break pulse to the device.
> - */
> -static int
> -omap_hdq_break(struct hdq_data *hdq_data)
> +/* Issue break pulse to the device */
> +static int omap_hdq_break(struct hdq_data *hdq_data)
> {
> int ret;
> u8 tmp_status;
> @@ -368,6 +354,7 @@ omap_hdq_break(struct hdq_data *hdq_data
> "return to zero, %x", tmp_status);
>
> mutex_unlock(&hdq_data->hdq_mutex);
> +
> return ret;
> }
>
> @@ -376,6 +363,7 @@ static int hdq_read_byte(struct hdq_data
> int ret;
> u8 status;
> unsigned long irqflags;
> + unsigned long timeout = jiffies + OMAP_HDQ_TIMEOUT;
>
> ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
> if (ret < 0)
> @@ -395,14 +383,11 @@ static int hdq_read_byte(struct hdq_data
>* triggers another interrupt before we
>* sleep. So we have to wait for RXCOMPLETE bit.
>*/
> - {
> - unsigned long timeout = jiffies + OMAP_HDQ_TIMEOUT;
> - while (!(hdq_data->hdq_irqstatus
> - & OMAP_HDQ_INT_STATUS_RXCOMPLETE)
> - && time_before(jiffies, timeout)) {
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - schedule_timeout(1);
> - }
> + while (!(hdq_data->hdq_irqstatus
> + & OMAP_HDQ_INT_STATUS_RXCOMPLETE)
> + && time_before(jiffies, timeout)) {
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + schedule_timeout(1);
> }
> hdq_reg_merge(hdq_data, OMAP_HDQ_CTRL_STATUS, 0,
> OMAP_HDQ_CTRL_STATUS_DIR);
> @@ -425,11 +410,8 @@ static int hdq_read_byte(struct hdq_data
>
> }
>
> -/*
> - * Enable clocks and set the controller to HDQ mode.
> - */
> -static int
> -omap_hdq_get(struct hdq_data *hdq_data)
> +/* Enable clocks and set the controller to HDQ mode */
> +
Re: [PATCH 5/10] HDQ driver: Convert few declarations to static
On Thu, Sep 25, 2008 at 12:25:11PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> Convert declaration to static.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/w1/masters/omap_hdq.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-09-24
> 10:10:07.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-24
> 10:19:28.0 +0530
> @@ -49,8 +49,8 @@
>
> #define OMAP_HDQ_MAX_USER4
>
> -DECLARE_WAIT_QUEUE_HEAD(hdq_wait_queue);
> -int W1_ID;
> +static DECLARE_WAIT_QUEUE_HEAD(hdq_wait_queue);
> +static int w1_id;
>
> struct hdq_data {
> struct device *dev;
> @@ -249,8 +249,8 @@ static void omap_w1_search_bus(void *_hd
> {
> u64 module_id, rn_le, cs, id;
>
> - if (W1_ID)
> - module_id = W1_ID;
> + if (w1_id)
> + module_id = w1_id;
> else
> module_id = 0x1;
>
> @@ -715,7 +715,7 @@ omap_hdq_exit(void)
> module_init(omap_hdq_init);
> module_exit(omap_hdq_exit);
>
> -module_param(W1_ID, int, S_IRUSR);
> +module_param(w1_id, int, S_IRUSR);
>
> MODULE_AUTHOR("Texas Instruments");
> MODULE_DESCRIPTION("HDQ driver Library");
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] HDQ driver: Remove global pointer
On Thu, Sep 25, 2008 at 12:19:44PM +0530, ext Gadiyar, Anand wrote:
> From: Madhusudhan Chikkature <[EMAIL PROTECTED]>
>
> This patch provides the necessary modifications to the driver to
> remove the global ptr hdq_data.
>
> Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]>
Acked-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> Sending this series on behalf of Madhu
>
> drivers/w1/masters/omap_hdq.c | 137
> ++
> 1 files changed, 72 insertions(+), 65 deletions(-)
>
> Index: linux-omap-2.6/drivers/w1/masters/omap_hdq.c
> ===
> --- linux-omap-2.6.orig/drivers/w1/masters/omap_hdq.c 2008-08-18
> 14:48:26.0 +0530
> +++ linux-omap-2.6/drivers/w1/masters/omap_hdq.c 2008-09-23
> 12:39:19.0 +0530
> @@ -62,11 +62,9 @@ struct hdq_data {
> spinlock_t hdq_spinlock;
> };
>
> -static struct hdq_data *hdq_data;
> -
> -static int omap_hdq_get(void);
> -static int omap_hdq_put(void);
> -static int omap_hdq_break(void);
> +static int omap_hdq_get(struct hdq_data *hdq_data);
> +static int omap_hdq_put(struct hdq_data *hdq_data);
> +static int omap_hdq_break(struct hdq_data *hdq_data);
>
> static int __init omap_hdq_probe(struct platform_device *pdev);
> static int omap_hdq_remove(struct platform_device *pdev);
> @@ -81,12 +79,13 @@ static struct platform_driver omap_hdq_d
> },
> };
>
> -static u8 omap_w1_read_byte(void *data);
> -static void omap_w1_write_byte(void *data, u8 byte);
> -static u8 omap_w1_reset_bus(void *data);
> -static void omap_w1_search_bus(void *data, u8 search_type,
> +static u8 omap_w1_read_byte(void *_hdq);
> +static void omap_w1_write_byte(void *_hdq, u8 byte);
> +static u8 omap_w1_reset_bus(void *_hdq);
> +static void omap_w1_search_bus(void *_hdq, u8 search_type,
> w1_slave_found_callback slave_found);
>
> +
> static struct w1_bus_master omap_w1_master = {
> .read_byte = omap_w1_read_byte,
> .write_byte = omap_w1_write_byte,
> @@ -97,25 +96,25 @@ static struct w1_bus_master omap_w1_mast
> /*
> * HDQ register I/O routines
> */
> -static inline u8
> -hdq_reg_in(u32 offset)
> +static inline u8 hdq_reg_in(struct hdq_data *hdq_data, u32 offset)
> {
> return omap_readb(hdq_data->hdq_base + offset);
> }
>
> -static inline u8
> -hdq_reg_out(u32 offset, u8 val)
> +static inline u8 hdq_reg_out(struct hdq_data *hdq_data, u32 offset, u8 val)
> {
> omap_writeb(val, hdq_data->hdq_base + offset);
> +
> return val;
> }
>
> -static inline u8
> -hdq_reg_merge(u32 offset, u8 val, u8 mask)
> +static inline u8 hdq_reg_merge(struct hdq_data *hdq_data, u32 offset,
> + u8 val, u8 mask)
> {
> u8 new_val = (omap_readb(hdq_data->hdq_base + offset) & ~mask)
> | (val & mask);
> omap_writeb(new_val, hdq_data->hdq_base + offset);
> +
> return new_val;
> }
>
> @@ -125,15 +124,15 @@ hdq_reg_merge(u32 offset, u8 val, u8 mas
> * HDQ_FLAG_CLEAR: wait until all bits in the flag are cleared.
> * return 0 on success and -ETIMEDOUT in the case of timeout.
> */
> -static int
> -hdq_wait_for_flag(u32 offset, u8 flag, u8 flag_set, u8 *status)
> +static int hdq_wait_for_flag(struct hdq_data *hdq_data, u32 offset,
> + u8 flag, u8 flag_set, u8 *status)
> {
> int ret = 0;
> unsigned long timeout = jiffies + OMAP_HDQ_TIMEOUT;
>
> if (flag_set == OMAP_HDQ_FLAG_CLEAR) {
> /* wait for the flag clear */
> - while (((*status = hdq_reg_in(offset)) & flag)
> + while (((*status = hdq_reg_in(hdq_data, offset)) & flag)
> && time_before(jiffies, timeout)) {
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(1);
> @@ -142,7 +141,7 @@ hdq_wait_for_flag(u32 offset, u8 flag, u
> ret = -ETIMEDOUT;
> } else if (flag_set == OMAP_HDQ_FLAG_SET) {
> /* wait for the flag set */
> - while (!((*status = hdq_reg_in(offset)) & flag)
> + while (!((*status = hdq_reg_in(hdq_data, offset)) & flag)
> && time_before(jiffies, timeout)) {
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(1);
> @@ -159,7 +158,7 @@ hdq_wait_for_flag(u32 offset, u8 flag, u
> * write out a byte and fill *status with HDQ_INT_STATUS
> */
> static int
> -hdq_write_byte(u8 val, u8 *status)
> +hdq_write_byte(struct hdq_data *hdq_data, u8 val, u8 *status)
> {
> int ret;
> u8 tmp_status;
> @@ -169,15 +168,15 @@ hdq_write_byte(u8 val, u8 *status)
>
> spin_lock_irqsave(&hdq_data->hdq_spinlock, irqflags);
> /* clear interrupt flags via a dummy read */
> - hdq_reg_in(OMAP_HDQ_INT_STATUS);
> + hdq_reg_in(hdq_data, OMAP_HDQ_INT_STATUS);
> /* ISR loads it with new INT_STATUS */
>
[PATCH] ARM: OMAP3: DMA: Fix for sDMA Errata 1.113
From: Santosh Shilimkar <[EMAIL PROTECTED]>
SDMA channel is not disabled after transaction error. So explicitly disable it.
Signed-off-by: Santosh Shilimkar <[EMAIL PROTECTED]>
Acked By : Nishant kamat <[EMAIL PROTECTED]>
---
Index: linux-omap-2.6/arch/arm/plat-omap/dma.c
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/dma.c2008-09-23
16:41:23.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/dma.c 2008-09-25 14:54:00.162059260
+0530
@@ -1849,9 +1849,22 @@ static int omap2_dma_handle_ch(int ch)
printk(KERN_INFO
"DMA synchronization event drop occurred with device "
"%d\n", dma_chan[ch].dev_id);
- if (unlikely(status & OMAP2_DMA_TRANS_ERR_IRQ))
+ if (unlikely(status & OMAP2_DMA_TRANS_ERR_IRQ)) {
printk(KERN_INFO "DMA transaction error with device %d\n",
dma_chan[ch].dev_id);
+ if (cpu_class_is_omap2()) {
+ /* Errata: sDMA Channel is not disabled
+* after a transaction error. So we explicitely
+* disable the channel
+*/
+ u32 ccr;
+
+ ccr = dma_read(CCR(ch));
+ ccr &= ~OMAP_DMA_CCR_EN;
+ dma_write(ccr, CCR(ch));
+ dma_chan[ch].flags &= ~OMAP_DMA_ACTIVE;
+ }
+ }
if (unlikely(status & OMAP2_DMA_SECURE_ERR_IRQ))
printk(KERN_INFO "DMA secure error with device %d\n",
dma_chan[ch].dev_id);--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC broken on beagleboard with current git
* Koen Kooi <[EMAIL PROTECTED]> [080925 12:23]: > > Op 25 sep 2008, om 10:51 heeft Tony Lindgren het volgende geschreven: > >> * Koen Kooi <[EMAIL PROTECTED]> [080925 11:42]: >>> Hi, >>> >>> I just built a kernel from current git[1] and the mmc controller >>> doesn't >>> get detected on boot on my beagleboards. The omap mmc system has >>> seen a >>> lot of changes lately, does anyone have a hint where to start looking >>> before attemping a bisect? >> >> Sounds like the recent mmc init changes we've done: >> >> 535e1808d1c77a580815f7d7daacc6c030e29cb1 - 12 september 2008 > >> 8e6e06c71b9d21d85a3ae652868e2802c054a08a - 12 september 2008 > >> c434c15d28c82d92e55897bd265c423e9ab69362 - 24 september 2008 > > >> I've verified that it works on omap3430sdp. But mach-omap2/hsmmc.c >> needs >> some more work done to support other mmc controllers besides the first >> one. >> I don't think other controllers ever worked before these patches >> either though.. >> >> Let me know if you can narrow it down to some commit and I may be able >> to help further from there. > > The previous working version I built was based of > de1121fdb899f762b9e717f44eaf3fae7c00cd3e which was commited at 13 > september 2008, so 535e18.. and 8e6e06c.. don't break it. OK, good to know. Can you try to git-bisect it? Tony >> >>> [1] >>> http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 >> >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC broken on beagleboard with current git
Op 25 sep 2008, om 10:51 heeft Tony Lindgren het volgende geschreven: * Koen Kooi <[EMAIL PROTECTED]> [080925 11:42]: Hi, I just built a kernel from current git[1] and the mmc controller doesn't get detected on boot on my beagleboards. The omap mmc system has seen a lot of changes lately, does anyone have a hint where to start looking before attemping a bisect? Sounds like the recent mmc init changes we've done: 535e1808d1c77a580815f7d7daacc6c030e29cb1 - 12 september 2008 8e6e06c71b9d21d85a3ae652868e2802c054a08a - 12 september 2008 c434c15d28c82d92e55897bd265c423e9ab69362 - 24 september 2008 I've verified that it works on omap3430sdp. But mach-omap2/hsmmc.c needs some more work done to support other mmc controllers besides the first one. I don't think other controllers ever worked before these patches either though.. Let me know if you can narrow it down to some commit and I may be able to help further from there. The previous working version I built was based of de1121fdb899f762b9e717f44eaf3fae7c00cd3e which was commited at 13 september 2008, so 535e18.. and 8e6e06c.. don't break it. regards, Koen Tony [1] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 PGP.sig Description: This is a digitally signed message part
Re: [PATCH] Add debobs Kconfig item
"Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes: > Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]> > --- > arch/arm/mach-omap2/Kconfig | 10 +- > arch/arm/mach-omap2/Makefile |3 +++ > 2 files changed, 12 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index d0bbbf8..639af08 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -151,4 +151,12 @@ config OMAP3_OFF_MODE > depends on ARCH_OMAP3 > default n > help > - Use off mode for powerdomains. > \ No newline at end of file > + Use off mode for powerdomains. > + > +config OMAP3_DEBOBS > + bool "OMAP 3430 Debug observability support" > + depends on ARCH_OMAP3 && DEBUG_FS > + default n > + help > + Use ETK pads for debug observability > + This should go into arch/arm/plat-omap/Kconfig, under the 'OMAP Feature Selections' list. Kevin > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > index 23fc127..88d3af0 100644 > --- a/arch/arm/mach-omap2/Makefile > +++ b/arch/arm/mach-omap2/Makefile > @@ -40,6 +40,9 @@ obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o > mailbox_mach-objs:= mailbox.o > mmu_mach-objs:= mmu.o > > +# Debobs > +obj-$(CONFIG_OMAP3_DEBOBS) += debobs.o > + > # Specific board support > obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o > obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o board-h4-mmc.o > -- > 1.5.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debobs and ETK padconf implementation
"Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
> Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/debobs.c | 214
> ++
> 1 files changed, 214 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/debobs.c
>
> diff --git a/arch/arm/mach-omap2/debobs.c b/arch/arm/mach-omap2/debobs.c
> new file mode 100644
> index 000..1bde1f4
> --- /dev/null
> +++ b/arch/arm/mach-omap2/debobs.c
> @@ -0,0 +1,214 @@
> +/*
> + * arch/arm/mach-omap2/debobs.c
> + *
> + * Handle debobs pads
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Written by Peter De Schrijver <[EMAIL PROTECTED]>
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ETK_GPIO_BEGIN 12
> +#define ETK_GPIO(i) (ETK_GPIO_BEGIN + i)
> +#define NUM_OF_DEBOBS_PADS 18
> +
> +enum debobs_pad_mode {
> + GPIO = 0,
> + OBS = 1,
> + ETK = 2,
> + NO_MODE = 3,
> +};
> +
> +static char *debobs_pad_mode_names[] = {
> + [GPIO] = "GPIO",
> + [OBS] = "OBS",
> + [ETK] = "ETK",
> +};
> +
> +struct obs {
> + u16 offset;
> + u8 value;
> + u8 mask;
> +};
> +
> +struct debobs_pad {
> + enum debobs_pad_mode mode;
> + struct obs core_obs;
> + struct obs wakeup_obs;
> +};
> +
> +static struct debobs_pad debobs_pads[NUM_OF_DEBOBS_PADS];
> +
> +static int debobs_mode_open(struct inode *inode, struct file *file)
> +{
> + file->private_data = inode->i_private;
> +
> + return 0;
> +}
> +
> +static ssize_t debobs_mode_read(struct file *file, char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + char buffer[10];
> + int size;
> + int pad_number = (int)file->private_data;
> + struct debobs_pad *e = &debobs_pads[pad_number];
> +
> + size = snprintf(buffer, sizeof(buffer), "%s\n",
> + debobs_pad_mode_names[e->mode]);
> + return simple_read_from_buffer(user_buf, count, ppos, buffer, size);
> +}
> +
> +static ssize_t debobs_mode_write(struct file *file, const char __user
> *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + char buffer[10];
> + int buf_size, i, pad_number;
> + u16 muxmode = OMAP34XX_MUX_MODE7;
> +
> + memset(buffer, 0, sizeof(buffer));
> + buf_size = min(count, (sizeof(buffer)-1));
> +
> + if (copy_from_user(buffer, user_buf, buf_size))
> + return -EFAULT;
> +
> + pad_number = (int)file->private_data;
> +
> + for (i = 0; i < NO_MODE; i++) {
> + if (!strnicmp(debobs_pad_mode_names[i],
> + buffer,
> + strlen(debobs_pad_mode_names[i]))) {
> + switch (i) {
> + case ETK:
> + muxmode = OMAP34XX_MUX_MODE0;
> + break;
> + case GPIO:
> + muxmode = OMAP34XX_MUX_MODE4;
> + break;
> + case OBS:
> + muxmode = OMAP34XX_MUX_MODE7;
> + break;
> + }
> + omap_ctrl_writew(muxmode,
> + OMAP343X_PADCONF_ETK(pad_number));
> + debobs_pads[pad_number].mode = i;
> +
> + return count;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static const struct file_operations debobs_mode_fops = {
> + .open = debobs_mode_open,
> + .read = debobs_mode_read,
> + .write = debobs_mode_write,
> +};
> +
> +static int debobs_get(void *data, u64 *val)
> +{
> + struct obs *o = data;
> +
> + *val = o->value;
> +
> + return 0;
> +}
> +
> +static int debobs_set(void *data, u64 val)
> +{
> + struct obs *o = data;
> +
> + val &= BIT(o->mask) - 1;
> +
> + omap_ctrl_writeb(val, o->offset);
> + o->value = val;
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(debobs_fops, debobs_get, debobs_set, "%llu\n");
> +
> +static inline int __init _new_debobs_pad(struct debobs_pad *pad, char *name,
> +
Re: MMC broken on beagleboard with current git
* Koen Kooi <[EMAIL PROTECTED]> [080925 11:42]: > Hi, > > I just built a kernel from current git[1] and the mmc controller doesn't > get detected on boot on my beagleboards. The omap mmc system has seen a > lot of changes lately, does anyone have a hint where to start looking > before attemping a bisect? Sounds like the recent mmc init changes we've done: 535e1808d1c77a580815f7d7daacc6c030e29cb1 8e6e06c71b9d21d85a3ae652868e2802c054a08a c434c15d28c82d92e55897bd265c423e9ab69362 I've verified that it works on omap3430sdp. But mach-omap2/hsmmc.c needs some more work done to support other mmc controllers besides the first one. I don't think other controllers ever worked before these patches either though.. Let me know if you can narrow it down to some commit and I may be able to help further from there. Tony > [1] > http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
MMC broken on beagleboard with current git
Hi, I just built a kernel from current git[1] and the mmc controller doesn't get detected on boot on my beagleboards. The omap mmc system has seen a lot of changes lately, does anyone have a hint where to start looking before attemping a bisect? regards, Koen [1] http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=c434c15d28c82d92e55897bd265c423e9ab69362 PGP.sig Description: This is a digitally signed message part
[PATCH 7/8] i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
From: Paul Walmsley <[EMAIL PROTECTED]>
Skip compiling OMAP15xx I2C ISR for non-OMAP15xx builds. Saves 400 bytes
of text for most OMAP builds.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e71f1f2..5c54864 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -511,6 +511,9 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+/* rev1 devices are apparently only on some 15xx */
+#ifdef CONFIG_ARCH_OMAP15XX
+
static irqreturn_t
omap_i2c_rev1_isr(int this_irq, void *dev_id)
{
@@ -565,6 +568,9 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
+#else
+#define omap_i2c_rev1_isr 0
+#endif
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
@@ -843,14 +849,14 @@ static struct platform_driver omap_i2c_driver = {
};
/* I2C may be needed to bring up other drivers */
-static int __init
+static int __devinit
omap_i2c_init_driver(void)
{
return platform_driver_register(&omap_i2c_driver);
}
subsys_initcall(omap_i2c_init_driver);
-static void __exit omap_i2c_exit_driver(void)
+static void __devexit omap_i2c_exit_driver(void)
{
platform_driver_unregister(&omap_i2c_driver);
}
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] i2c-omap: Clean-up i2c-omap
Minor checkpatch and formatting clean-up. Also update copyrights.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5c54864..a41b655 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -2,13 +2,15 @@
* TI OMAP I2C master mode driver
*
* Copyright (C) 2003 MontaVista Software, Inc.
- * Copyright (C) 2004 Texas Instruments.
- *
- * Updated to work with multiple I2C interfaces on 24xx by
- * Tony Lindgren <[EMAIL PROTECTED]> and Imre Deak <[EMAIL PROTECTED]>
* Copyright (C) 2005 Nokia Corporation
+ * Copyright (C) 2004 - 2007 Texas Instruments.
*
- * Cleaned up by Juha Yrjölä <[EMAIL PROTECTED]>
+ * Originally written by MontaVista Software, Inc.
+ * Additional contributions by:
+ * Tony Lindgren <[EMAIL PROTECTED]>
+ * Imre Deak <[EMAIL PROTECTED]>
+ * Juha Yrjölä <[EMAIL PROTECTED]>
+ * Syed Khasim <[EMAIL PROTECTED]>
*
* 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
@@ -33,8 +35,7 @@
#include
#include
#include
-
-#include
+#include
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -215,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1)
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
*/
+ iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
/*
@@ -334,9 +335,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Enable interrupts */
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -402,8 +403,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
w |= OMAP_I2C_CON_XA;
if (!(msg->flags & I2C_M_RD))
w |= OMAP_I2C_CON_TRX;
+
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
@@ -476,7 +479,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_unidle(dev);
- if ((r = omap_i2c_wait_for_bb(dev)) < 0)
+ r = omap_i2c_wait_for_bb(dev);
+ if (r < 0)
goto out;
for (i = 0; i < num; i++) {
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] i2c-omap: Mark init-only functions as __init
From: Paul Walmsley <[EMAIL PROTECTED]>
Mark functions called only at init time as __init.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b41431a..e71f1f2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -154,7 +154,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
return __raw_readw(i2c_dev->base + reg);
}
-static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev->iclk = clk_get(dev->dev, "i2c_ick");
@@ -697,7 +697,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
-static int
+static int __init
omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] i2c-omap: Add support on 34xx
From: Chandra shekhar <[EMAIL PROTECTED]>
Signed-off-by: chandra shekhar <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ded4636..b41431a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -156,7 +156,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
- if (cpu_is_omap16xx() || cpu_is_omap24xx()) {
+ if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev->iclk = clk_get(dev->dev, "i2c_ick");
if (IS_ERR(dev->iclk)) {
dev->iclk = NULL;
@@ -279,7 +279,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* HSI2C controller internal clk rate should be 19.2 Mhz */
internal_clk = 19200;
@@ -616,7 +616,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
*dev->buf++ = w;
dev->buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430()) {
+ if (!cpu_is_omap2430() &&
+ !cpu_is_omap34xx()) {
if (dev->buf_len) {
*dev->buf++ = w >> 8;
dev->buf_len--;
@@ -654,7 +655,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
w = *dev->buf++;
dev->buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430()) {
+ if (!cpu_is_omap2430() &&
+ !cpu_is_omap34xx()) {
if (dev->buf_len) {
w |= *dev->buf++ << 8;
dev->buf_len--;
@@ -748,7 +750,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (cpu_is_omap15xx())
dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
u16 s;
/* Set up the fifo size - Get total size */
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
From: Nishanth Menon <[EMAIL PROTECTED]>
Based on an earlier patch from Nishant Menon:
- Transfers can use FIFO on FIFO capable devices
- Prevents errors for HSI2C if FIFO is not used
- Implemented errenous handling of STT-STP handling on SDP2430
Also merged in is a fix from Jaron Marini to fix occasional i2c
hang if OMAP_I2C_CON_STT remains asserted.
Signed-off-by: Jason P Marini <[EMAIL PROTECTED]>
Signed-off-by: Nishanth Menon <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 189 -
1 files changed, 149 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 0d30790..ded4636 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,8 +55,11 @@
#define OMAP_I2C_SCLL_REG 0x34
#define OMAP_I2C_SCLH_REG 0x38
#define OMAP_I2C_SYSTEST_REG 0x3c
+#define OMAP_I2C_BUFSTAT_REG 0x40
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
+#define OMAP_I2C_IE_XDR(1 << 14) /* TX Buffer drain int
enable */
+#define OMAP_I2C_IE_RDR(1 << 13) /* RX Buffer drain int
enable */
#define OMAP_I2C_IE_XRDY (1 << 4)/* TX data ready int enable */
#define OMAP_I2C_IE_RRDY (1 << 3)/* RX data ready int enable */
#define OMAP_I2C_IE_ARDY (1 << 2)/* Access ready int enable */
@@ -64,7 +67,8 @@
#define OMAP_I2C_IE_AL (1 << 0)/* Arbitration lost int ena */
/* I2C Status Register (OMAP_I2C_STAT): */
-#define OMAP_I2C_STAT_SBD (1 << 15) /* Single byte data */
+#define OMAP_I2C_STAT_XDR (1 << 14) /* TX Buffer draining */
+#define OMAP_I2C_STAT_RDR (1 << 13) /* RX Buffer draining */
#define OMAP_I2C_STAT_BB (1 << 12) /* Bus busy */
#define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */
#define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */
@@ -78,12 +82,14 @@
/* I2C Buffer Configuration Register (OMAP_I2C_BUF): */
#define OMAP_I2C_BUF_RDMA_EN (1 << 15) /* RX DMA channel enable */
+#define OMAP_I2C_BUF_RXFIF_CLR (1 << 14) /* RX FIFO Clear */
#define OMAP_I2C_BUF_XDMA_EN (1 << 7)/* TX DMA channel enable */
+#define OMAP_I2C_BUF_TXFIF_CLR (1 << 6)/* TX FIFO Clear */
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN(1 << 15) /* I2C module enable */
#define OMAP_I2C_CON_BE(1 << 14) /* Big endian mode */
-#define OMAP_I2C_CON_OPMODE(1 << 12) /* High Speed support */
+#define OMAP_I2C_CON_OPMODE_HS (1 << 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
@@ -127,7 +133,12 @@ struct omap_i2c_dev {
u8 *buf;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 fifo_size; /* use as flag and value
+* fifo_size==0 implies no fifo
+* if set, should be trsh+1
+*/
unsignedrev1:1;
+ unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
};
@@ -310,6 +321,14 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
+ if (dev->fifo_size)
+ /* Note: setup required fifo size - 1 */
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
+ (dev->fifo_size - 1) << 8 | /* RTRSH */
+ OMAP_I2C_BUF_RXFIF_CLR |
+ (dev->fifo_size - 1) | /* XTRSH */
+ OMAP_I2C_BUF_TXFIF_CLR);
+
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -317,7 +336,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
(OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL));
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -364,6 +384,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
omap_i2c_write_reg(dev, OMA
[PATCH 3/8] i2c-omap: Add high-speed support to omap-i2c
From: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Omap2430 has additional support for high-speed I2C.
This patch moves I2C speed parameter (from module) to platform data.
Also added basic High Speed support based on I2C bus speed.
This patch is tested for high speed I2C (with TWL4030 Keypad) and works as
expected.
Signed-off-by: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 111 +---
1 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a06ad42..0d30790 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -83,6 +83,7 @@
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN(1 << 15) /* I2C module enable */
#define OMAP_I2C_CON_BE(1 << 14) /* Big endian mode */
+#define OMAP_I2C_CON_OPMODE(1 << 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
@@ -91,6 +92,10 @@
#define OMAP_I2C_CON_STP (1 << 1)/* Stop cond (master only) */
#define OMAP_I2C_CON_STT (1 << 0)/* Start condition (master) */
+/* I2C SCL time value when Master */
+#define OMAP_I2C_SCLL_HSSCLL 8
+#define OMAP_I2C_SCLH_HSSCLH 8
+
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 << 15) /* System test enable */
@@ -109,12 +114,6 @@
/* I2C System Configuration Register (OMAP_I2C_SYSC): */
#define OMAP_I2C_SYSC_SRST (1 << 1)/* Soft Reset */
-/* REVISIT: Use platform_data instead of module parameters */
-/* Fast Mode = 400 kHz, Standard = 100 kHz */
-static int clock = 100; /* Default: 100 kHz */
-module_param(clock, int, 0);
-MODULE_PARM_DESC(clock, "Set I2C clock in kHz: 400=fast mode (default ==
100)");
-
struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
@@ -123,6 +122,7 @@ struct omap_i2c_dev {
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
+ u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
size_t buf_len;
@@ -152,17 +152,28 @@ static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
return -ENODEV;
}
}
-
- dev->fclk = clk_get(dev->dev, "i2c_fck");
- if (IS_ERR(dev->fclk)) {
- if (dev->iclk != NULL) {
- clk_put(dev->iclk);
- dev->iclk = NULL;
+ /* For I2C operations on 2430 we need 96Mhz clock */
+ if (cpu_is_omap2430()) {
+ dev->fclk = clk_get(dev->dev, "i2chs_fck");
+ if (IS_ERR(dev->fclk)) {
+ if (dev->iclk != NULL) {
+ clk_put(dev->iclk);
+ dev->iclk = NULL;
+ }
+ dev->fclk = NULL;
+ return -ENODEV;
+ }
+ } else {
+ dev->fclk = clk_get(dev->dev, "i2c_fck");
+ if (IS_ERR(dev->fclk)) {
+ if (dev->iclk != NULL) {
+ clk_put(dev->iclk);
+ dev->iclk = NULL;
+ }
+ dev->fclk = NULL;
+ return -ENODEV;
}
- dev->fclk = NULL;
- return -ENODEV;
}
-
return 0;
}
@@ -210,9 +221,11 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
+ unsigned long internal_clk = 0;
if (!dev->rev1) {
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
@@ -255,18 +268,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
+ if (cpu_is_omap2430()) {
+
+ /* HSI2C controller internal clk rate should be 19.2 Mhz */
+ internal_clk = 19200;
+ fclk_rate = clk_get_rate(dev->fclk) / 1000;
+
+ /* Compute prescaler divisor */
+ psc = fclk_rate / internal_clk;
+ psc = psc - 1;
+
+ /* If configured for High Speed */
+ if (dev->spee
[PATCH 2/8] i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr()
From: Paul Walmsley <[EMAIL PROTECTED]>
omap_i2c_idle() sets an internal flag, "dev->idle", instructing its
ISR to decline interrupts. It sets this flag before it actually masks
the interrupts on the I2C controller. This is problematic, since an
I2C interrupt could arrive after dev->idle is set, but before the
interrupt source is masked. When this happens, Linux disables the I2C
controller's IRQ, causing all future transactions on the bus to fail.
Symptoms, happening on about 7% of boots:
irq 56: nobody cared (try booting with the "irqpoll" option)
Disabling IRQ #56
i2c_omap i2c_omap.1: controller timed out
In omap_i2c_idle(), this patch sets dev->idle only after the interrupt
mask write to the I2C controller has left the ARM write buffer.
That's probably the major offender. For additional prophylaxis, in
omap_i2c_unidle(), the patch clears the dev->idle flag before
interrupts are enabled, rather than afterwards.
The patch has survived twenty-two reboots on the 3430SDP here without
wedging I2C1. Not absolutely dispositive, but promising!
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index cfb76f5..a06ad42 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -181,22 +181,28 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
if (dev->iclk != NULL)
clk_enable(dev->iclk);
clk_enable(dev->fclk);
+ dev->idle = 0;
if (dev->iestate)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
- dev->idle = 0;
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
u16 iv;
- dev->idle = 1;
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1)
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
*/
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
+ /*
+* The wmb() is to ensure that the I2C interrupt mask write
+* reaches the I2C controller before the dev->idle store
+* occurs.
+*/
+ wmb();
+ dev->idle = 1;
clk_disable(dev->fclk);
if (dev->iclk != NULL)
clk_disable(dev->iclk);
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg
From: Jarkko Nikula <[EMAIL PROTECTED]> If there is a signal pending and wait_for_completion_interruptible_timeout terminates with -ERESTARTSYS, we return and disable the i2c clocks in omap_i2c_xfer. If we terminate before sending last i2c message with a stop condition, the bus remains busy and we are not able to send new messages into bus with successive omap_i2c_xfer calls. Therefore a pending signal is not caught here and we return only because of timeout or i2c error. Signed-off-by: Jarkko Nikula <[EMAIL PROTECTED]> Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> --- drivers/i2c/busses/i2c-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index e7eb7bf..cfb76f5 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -328,8 +328,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_CON_STP; omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w); - r = wait_for_completion_interruptible_timeout(&dev->cmd_complete, - OMAP_I2C_TIMEOUT); + r = wait_for_completion_timeout(&dev->cmd_complete, + OMAP_I2C_TIMEOUT); dev->buf_len = 0; if (r < 0) return r; -- 1.5.6.rc3.21.g8c6b5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Updates for i2c-omap from linux-omap tree for review, v2
Hi all, Here's a repost of the whole series, the first series had a compile error starting with one of the patches. Sorry for the extra noise. This series contains pending i2c-omap patches from linux-omap tree for review. Looks like we've managed to pile up stuff in the omap tree for this driver again... Anyways, future patches will be coming straight via the i2c list. The first two patches could be pushed as fixes to current -rc series, but I'm fine with them going in later too. I've left out some clean-up from the last patch so it won't conflict with omap ioremp changes that are currently in Russell King's devel branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Updates for i2c-omap from linux-omap tree for review
* Tony Lindgren <[EMAIL PROTECTED]> [080925 10:16]: > Hi all, > > This series contains pending i2c-omap patches from linux-omap tree > for review. > > Looks like we've managed to pile up stuff in the omap tree for this > driver again... Anyways, future patches will be coming straight via > the i2c list. > > The first two patches could be pushed as fixes to current -rc series, > but I'm fine with them going in later too. > > I've left out some clean-up from the last patch so it won't conflict with > omap ioremp changes that are currently in Russell King's devel > branch. Grr, I'll repost the whole series. There was a compile error in one of the patches. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: clk_disable_unused() is bugged
Hi Rajendra,
On Thu, 25 Sep 2008, Rajendra Nayak wrote:
> I tried this patch on top of the pm-1 branch. On the 3430SDP I see idle being
> able to
> hit CORE RET, but system suspend seems to crash. See the crash log below.
thanks for the report. Does this patch fix it?
- Paul
OMAP3 clock: fix dss1_alwon_fck
From: Paul Walmsley <[EMAIL PROTECTED]>
Commit a63efb1547ac35dcb0f007090396a3c7510eb691 broke the dss1_alwon_fck
clock enable on 3430ES2+. The clock code was not waiting for the module
to come out of idle.
Problem reported by Rajendra Nayak <[EMAIL PROTECTED]>.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 8ce7097..4722277 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -2304,7 +2304,7 @@ static struct clk dss1_alwon_fck_3430es1 = {
.prcm_mod = OMAP3430_DSS_MOD,
.enable_reg = CM_FCLKEN,
.enable_bit = OMAP3430_EN_DSS1_SHIFT,
- .flags = CLOCK_IN_OMAP343X,
+ .flags = CLOCK_IN_OMAP3430ES1,
.clkdm = { .name = "dss_clkdm" },
.recalc = &followparent_recalc,
};
@@ -2317,7 +2317,7 @@ static struct clk dss1_alwon_fck_3430es2 = {
.enable_reg = CM_FCLKEN,
.enable_bit = OMAP3430_EN_DSS1_SHIFT,
.idlest_bit = OMAP3430ES2_ST_DSS_IDLE_SHIFT,
- .flags = CLOCK_IN_OMAP343X | WAIT_READY,
+ .flags = CLOCK_IN_OMAP3430ES2 | WAIT_READY,
.clkdm = { .name = "dss_clkdm" },
.recalc = &followparent_recalc,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Adds MCBSP mux settings
Adding MCBSP port 1, 3, 4 and 5 ports mux settings for 2430.
Signed-off-by: Arun KS <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/mux.c | 24
arch/arm/plat-omap/include/mach/mux.h | 24
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 3e877ab..f272bfa 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -202,6 +202,15 @@ MUX_CFG_24XX("AE9_2430_USB0HS_NXT",0x13D, 0,
0, 0, 1)
MUX_CFG_24XX("AC7_2430_USB0HS_DATA7", 0x13E, 0, 0, 0, 1)
/* 2430 McBSP */
+MUX_CFG_24XX("AD6_2430_MCBSP_CLKS",0x011E, 0, 0, 0, 1)
+
+MUX_CFG_24XX("AB2_2430_MCBSP1_CLKR", 0x011A, 0, 0, 0, 1)
+MUX_CFG_24XX("AD5_2430_MCBSP1_FSR",0x011B, 0, 0, 0, 1)
+MUX_CFG_24XX("AA1_2430_MCBSP1_DX", 0x011C, 0, 0, 0, 1)
+MUX_CFG_24XX("AF3_2430_MCBSP1_DR", 0x011D, 0, 0, 0, 1)
+MUX_CFG_24XX("AB3_2430_MCBSP1_FSX",0x011F, 0, 0, 0, 1)
+MUX_CFG_24XX("Y9_2430_MCBSP1_CLKX",0x0120, 0, 0, 0, 1)
+
MUX_CFG_24XX("AC10_2430_MCBSP2_FSX", 0x012E, 1, 0, 0, 1)
MUX_CFG_24XX("AD16_2430_MCBSP2_CLX", 0x012F, 1, 0, 0, 1)
MUX_CFG_24XX("AE13_2430_MCBSP2_DX",0x0130, 1, 0, 0, 1)
@@ -211,6 +220,21 @@ MUX_CFG_24XX("AD16_2430_MCBSP2_CLX_OFF",0x012F,0,
0, 0, 1)
MUX_CFG_24XX("AE13_2430_MCBSP2_DX_OFF",0x0130, 0, 0, 0,
1)
MUX_CFG_24XX("AD13_2430_MCBSP2_DR_OFF",0x0131, 0, 0, 0,
1)
+MUX_CFG_24XX("AC9_2430_MCBSP3_CLKX", 0x0103, 0, 0, 0, 1)
+MUX_CFG_24XX("AE4_2430_MCBSP3_FSX",0x0104, 0, 0, 0, 1)
+MUX_CFG_24XX("AE2_2430_MCBSP3_DR", 0x0105, 0, 0, 0, 1)
+MUX_CFG_24XX("AF4_2430_MCBSP3_DX", 0x0106, 0, 0, 0, 1)
+
+MUX_CFG_24XX("N3_2430_MCBSP4_CLKX",0x010B, 1, 0, 0, 1)
+MUX_CFG_24XX("AD23_2430_MCBSP4_DR",0x010C, 1, 0, 0, 1)
+MUX_CFG_24XX("AB25_2430_MCBSP4_DX",0x010D, 1, 0, 0, 1)
+MUX_CFG_24XX("AC25_2430_MCBSP4_FSX", 0x010E, 1, 0, 0, 1)
+
+MUX_CFG_24XX("AE16_2430_MCBSP5_CLKX", 0x00ED, 1, 0, 0, 1)
+MUX_CFG_24XX("AF12_2430_MCBSP5_FSX", 0x00ED, 1, 0, 0, 1)
+MUX_CFG_24XX("K7_2430_MCBSP5_DX", 0x00EF, 1, 0, 0, 1)
+MUX_CFG_24XX("M1_2430_MCBSP5_DR", 0x00F0, 1, 0, 0, 1)
+
/* 2430 MCSPI1 */
MUX_CFG_24XX("Y18_2430_MCSPI1_CLK",0x010F, 0, 0, 0, 1)
MUX_CFG_24XX("AD15_2430_MCSPI1_SIMO", 0x0110, 0, 0, 0, 1)
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 683474f..1798bfe 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -632,6 +632,15 @@ enum omap24xx_index {
AC7_2430_USB0HS_DATA7,
/* 2430 McBSP */
+ AD6_2430_MCBSP_CLKS,
+
+ AB2_2430_MCBSP1_CLKR,
+ AD5_2430_MCBSP1_FSR,
+ AA1_2430_MCBSP1_DX,
+ AF3_2430_MCBSP1_DR,
+ AB3_2430_MCBSP1_FSX,
+ Y9_2430_MCBSP1_CLKX,
+
AC10_2430_MCBSP2_FSX,
AD16_2430_MCBSP2_CLX,
AE13_2430_MCBSP2_DX,
@@ -641,6 +650,21 @@ enum omap24xx_index {
AE13_2430_MCBSP2_DX_OFF,
AD13_2430_MCBSP2_DR_OFF,
+ AC9_2430_MCBSP3_CLKX,
+ AE4_2430_MCBSP3_FSX,
+ AE2_2430_MCBSP3_DR,
+ AF4_2430_MCBSP3_DX,
+
+ N3_2430_MCBSP4_CLKX,
+ AD23_2430_MCBSP4_DR,
+ AB25_2430_MCBSP4_DX,
+ AC25_2430_MCBSP4_FSX,
+
+ AE16_2430_MCBSP5_CLKX,
+ AF12_2430_MCBSP5_FSX,
+ K7_2430_MCBSP5_DX,
+ M1_2430_MCBSP5_DR,
+
/* 2430 McSPI*/
Y18_2430_MCSPI1_CLK,
AD15_2430_MCSPI1_SIMO,
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Adds MCBSP mux settings
Adding MCBSP port 1, 3, 4 and 5 ports mux settings for 2430.
Signed-off-by: Arun KS <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/mux.c | 24
arch/arm/plat-omap/include/mach/mux.h | 24
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 3e877ab..f272bfa 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -202,6 +202,15 @@ MUX_CFG_24XX("AE9_2430_USB0HS_NXT",0x13D, 0,
0, 0, 1)
MUX_CFG_24XX("AC7_2430_USB0HS_DATA7", 0x13E, 0, 0, 0, 1)
/* 2430 McBSP */
+MUX_CFG_24XX("AD6_2430_MCBSP_CLKS",0x011E, 0, 0, 0, 1)
+
+MUX_CFG_24XX("AB2_2430_MCBSP1_CLKR", 0x011A, 0, 0, 0, 1)
+MUX_CFG_24XX("AD5_2430_MCBSP1_FSR",0x011B, 0, 0, 0, 1)
+MUX_CFG_24XX("AA1_2430_MCBSP1_DX", 0x011C, 0, 0, 0, 1)
+MUX_CFG_24XX("AF3_2430_MCBSP1_DR", 0x011D, 0, 0, 0, 1)
+MUX_CFG_24XX("AB3_2430_MCBSP1_FSX",0x011F, 0, 0, 0, 1)
+MUX_CFG_24XX("Y9_2430_MCBSP1_CLKX",0x0120, 0, 0, 0, 1)
+
MUX_CFG_24XX("AC10_2430_MCBSP2_FSX", 0x012E, 1, 0, 0, 1)
MUX_CFG_24XX("AD16_2430_MCBSP2_CLX", 0x012F, 1, 0, 0, 1)
MUX_CFG_24XX("AE13_2430_MCBSP2_DX",0x0130, 1, 0, 0, 1)
@@ -211,6 +220,21 @@ MUX_CFG_24XX("AD16_2430_MCBSP2_CLX_OFF",0x012F,0,
0, 0, 1)
MUX_CFG_24XX("AE13_2430_MCBSP2_DX_OFF",0x0130, 0, 0, 0,
1)
MUX_CFG_24XX("AD13_2430_MCBSP2_DR_OFF",0x0131, 0, 0, 0,
1)
+MUX_CFG_24XX("AC9_2430_MCBSP3_CLKX", 0x0103, 0, 0, 0, 1)
+MUX_CFG_24XX("AE4_2430_MCBSP3_FSX",0x0104, 0, 0, 0, 1)
+MUX_CFG_24XX("AE2_2430_MCBSP3_DR", 0x0105, 0, 0, 0, 1)
+MUX_CFG_24XX("AF4_2430_MCBSP3_DX", 0x0106, 0, 0, 0, 1)
+
+MUX_CFG_24XX("N3_2430_MCBSP4_CLKX",0x010B, 1, 0, 0, 1)
+MUX_CFG_24XX("AD23_2430_MCBSP4_DR",0x010C, 1, 0, 0, 1)
+MUX_CFG_24XX("AB25_2430_MCBSP4_DX",0x010D, 1, 0, 0, 1)
+MUX_CFG_24XX("AC25_2430_MCBSP4_FSX", 0x010E, 1, 0, 0, 1)
+
+MUX_CFG_24XX("AE16_2430_MCBSP5_CLKX", 0x00ED, 1, 0, 0, 1)
+MUX_CFG_24XX("AF12_2430_MCBSP5_FSX", 0x00ED, 1, 0, 0, 1)
+MUX_CFG_24XX("K7_2430_MCBSP5_DX", 0x00EF, 1, 0, 0, 1)
+MUX_CFG_24XX("M1_2430_MCBSP5_DR", 0x00F0, 1, 0, 0, 1)
+
/* 2430 MCSPI1 */
MUX_CFG_24XX("Y18_2430_MCSPI1_CLK",0x010F, 0, 0, 0, 1)
MUX_CFG_24XX("AD15_2430_MCSPI1_SIMO", 0x0110, 0, 0, 0, 1)
diff --git a/arch/arm/plat-omap/include/mach/mux.h
b/arch/arm/plat-omap/include/mach/mux.h
index 683474f..1798bfe 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -632,6 +632,15 @@ enum omap24xx_index {
AC7_2430_USB0HS_DATA7,
/* 2430 McBSP */
+ AD6_2430_MCBSP_CLKS,
+
+ AB2_2430_MCBSP1_CLKR,
+ AD5_2430_MCBSP1_FSR,
+ AA1_2430_MCBSP1_DX,
+ AF3_2430_MCBSP1_DR,
+ AB3_2430_MCBSP1_FSX,
+ Y9_2430_MCBSP1_CLKX,
+
AC10_2430_MCBSP2_FSX,
AD16_2430_MCBSP2_CLX,
AE13_2430_MCBSP2_DX,
@@ -641,6 +650,21 @@ enum omap24xx_index {
AE13_2430_MCBSP2_DX_OFF,
AD13_2430_MCBSP2_DR_OFF,
+ AC9_2430_MCBSP3_CLKX,
+ AE4_2430_MCBSP3_FSX,
+ AE2_2430_MCBSP3_DR,
+ AF4_2430_MCBSP3_DX,
+
+ N3_2430_MCBSP4_CLKX,
+ AD23_2430_MCBSP4_DR,
+ AB25_2430_MCBSP4_DX,
+ AC25_2430_MCBSP4_FSX,
+
+ AE16_2430_MCBSP5_CLKX,
+ AF12_2430_MCBSP5_FSX,
+ K7_2430_MCBSP5_DX,
+ M1_2430_MCBSP5_DR,
+
/* 2430 McSPI*/
Y18_2430_MCSPI1_CLK,
AD15_2430_MCSPI1_SIMO,
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch linux-omap-git] twl4030-core: cleanups
From: David Brownell <[EMAIL PROTECTED]>
A bunch of little cleanups to twl4030-core.
- Remove needless header inclusions, symbols, and
forward declarations.
- Make coding style more standard.
And shrink the object size a bit.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/i2c/chips/twl4030-core.c | 79 +
1 file changed, 28 insertions(+), 51 deletions(-)
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -25,34 +25,23 @@
* 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
#include
#include
-#include
#include
#include
+#include
#include
-#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include
-#include
#define DRIVER_NAME"twl4030"
@@ -70,16 +59,13 @@
/* Last - for index max*/
#define TWL4030_MODULE_LASTTWL4030_MODULE_SECURED_REG
+#define TWL4030_NUM_SLAVES 4
+
/* Slave address */
-#define TWL4030_NUM_SLAVES 0x04
#define TWL4030_SLAVENUM_NUM0 0x00
#define TWL4030_SLAVENUM_NUM1 0x01
#define TWL4030_SLAVENUM_NUM2 0x02
#define TWL4030_SLAVENUM_NUM3 0x03
-#define TWL4030_SLAVEID_ID00x48
-#define TWL4030_SLAVEID_ID10x49
-#define TWL4030_SLAVEID_ID20x4A
-#define TWL4030_SLAVEID_ID30x4B
/* Base Address defns */
/* USB ID */
@@ -143,9 +129,6 @@
#define HFCLK_FREQ_38p4_MHZ(3 << 0)
#define HIGH_PERF_SQ (1 << 3)
-/* on I2C-1 for 2430SDP */
-#define CONFIG_I2C_TWL4030_ID 1
-
/* SIH_CTRL registers that aren't defined elsewhere */
#define TWL4030_INTERRUPTS_BCISIHCTRL 0x0d
#define TWL4030_MADC_MADC_SIH_CTRL 0x67
@@ -284,9 +267,6 @@ static const struct twl4030_mod_iregs __
};
-/* Helper functions */
-static void do_twl4030_irq(unsigned int irq, irq_desc_t *desc);
-
/* Data Structures */
/* To have info on T2 IRQ substem activated or not */
static struct completion irq_event;
@@ -294,8 +274,7 @@ static struct completion irq_event;
/* Structure to define on TWL4030 Slave ID */
struct twl4030_client {
struct i2c_client *client;
- const unsigned char address;
- const char adapter_index;
+ u8 address;
bool inuse;
/* max numb of i2c_msg required is for read =2 */
@@ -337,33 +316,24 @@ static struct twl4030mapping twl4030_map
{ TWL4030_SLAVENUM_NUM3, TWL4030_BASEADD_SECURED_REG },
};
-static struct twl4030_client twl4030_modules[TWL4030_NUM_SLAVES] = {
- {
- .address= TWL4030_SLAVEID_ID0,
- .adapter_index = CONFIG_I2C_TWL4030_ID,
- },
- {
- .address= TWL4030_SLAVEID_ID1,
- .adapter_index = CONFIG_I2C_TWL4030_ID,
- },
- {
- .address= TWL4030_SLAVEID_ID2,
- .adapter_index = CONFIG_I2C_TWL4030_ID,
- },
- {
- .address= TWL4030_SLAVEID_ID3,
- .adapter_index = CONFIG_I2C_TWL4030_ID,
- },
-};
+static struct twl4030_client twl4030_modules[TWL4030_NUM_SLAVES];
/*
* TWL4030 doesn't have PIH mask, hence dummy function for mask
* and unmask.
*/
-static void twl4030_i2c_ackirq(unsigned int irq) {}
-static void twl4030_i2c_disableint(unsigned int irq) {}
-static void twl4030_i2c_enableint(unsigned int irq) {}
+static void twl4030_i2c_ackirq(unsigned int irq)
+{
+}
+
+static void twl4030_i2c_disableint(unsigned int irq)
+{
+}
+
+static void twl4030_i2c_enableint(unsigned int irq)
+{
+}
/* information for processing in the Work Item */
static struct irq_chip twl4030_irq_chip = {
@@ -749,7 +719,7 @@ static struct task_struct * __init start
"twl4030 irq %d", irq);
if (!thread)
pr_err("%s: could not create twl4030 irq %d thread!\n",
- __func__, irq);
+ DRIVER_NAME, irq);
return thread;
}
@@ -799,9 +769,15 @@ static int __init power_companion_init(v
clk_put(osc);
switch (rate) {
- case 1920 : ctrl = HFCLK_FREQ_19p2_MHZ; break;
- case 2600 : ctrl = HFCLK_FREQ_26_MHZ; break;
- case 3840 : ctrl = HFCLK_FREQ_38p4_MHZ; break;
+ case 1920:
+ ctrl = HFCLK_FREQ_19p2_MHZ;
+ break;
+ case 2600:
+ ctrl = HFCLK_FREQ_26_MHZ;
+ break;
+ case 3840:
+ ctrl = HFCLK_FREQ_38p4_MHZ;
+ break;
}
ctrl |= HIGH_PERF_SQ;
@@ -980,6 +956,7 @@ twl4030_probe(struct i2c_client *client,
for (i = 0; i < TWL4030_NUM_SLAVES;
Re: [PATCH 8/8] i2c-omap: Clean-up i2c-omap, v2
* Tony Lindgren <[EMAIL PROTECTED]> [080925 10:18]:
> Minor checkpatch and formatting clean-up. Also update copyrights.
Oops, left out the last hunk too to avoid merge conflicts, here's an
updated version of this patch.
Tony
>From a50275a85a81be007c74293b5519c3cbb01f6fa5 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Thu, 25 Sep 2008 10:23:55 +0300
Subject: [PATCH] i2c-omap: Clean-up i2c-omap
Minor checkpatch and formatting clean-up. Also update copyrights.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9ac64c7..3dc608c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -2,13 +2,15 @@
* TI OMAP I2C master mode driver
*
* Copyright (C) 2003 MontaVista Software, Inc.
- * Copyright (C) 2004 Texas Instruments.
- *
- * Updated to work with multiple I2C interfaces on 24xx by
- * Tony Lindgren <[EMAIL PROTECTED]> and Imre Deak <[EMAIL PROTECTED]>
* Copyright (C) 2005 Nokia Corporation
+ * Copyright (C) 2004 - 2007 Texas Instruments.
*
- * Cleaned up by Juha Yrjölä <[EMAIL PROTECTED]>
+ * Originally written by MontaVista Software, Inc.
+ * Additional contributions by:
+ * Tony Lindgren <[EMAIL PROTECTED]>
+ * Imre Deak <[EMAIL PROTECTED]>
+ * Juha Yrjölä <[EMAIL PROTECTED]>
+ * Syed Khasim <[EMAIL PROTECTED]>
*
* 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
@@ -33,8 +35,7 @@
#include
#include
#include
-
-#include
+#include
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -215,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1)
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
+ iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
/*
@@ -334,9 +335,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Enable interrupts */
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -402,8 +403,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
w |= OMAP_I2C_CON_XA;
if (!(msg->flags & I2C_M_RD))
w |= OMAP_I2C_CON_TRX;
+
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
@@ -475,7 +478,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
omap_i2c_unidle(dev);
- if ((r = omap_i2c_wait_for_bb(dev)) < 0)
+ r = omap_i2c_wait_for_bb(dev)
+ if (r < 0)
goto out;
for (i = 0; i < num; i++) {
--
1.5.6.rc3.21.g8c6b5
[PATCH 8/8] i2c-omap: Clean-up i2c-omap
Minor checkpatch and formatting clean-up. Also update copyrights.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 31 ++-
1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9ac64c7..0c5d101 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -2,13 +2,15 @@
* TI OMAP I2C master mode driver
*
* Copyright (C) 2003 MontaVista Software, Inc.
- * Copyright (C) 2004 Texas Instruments.
- *
- * Updated to work with multiple I2C interfaces on 24xx by
- * Tony Lindgren <[EMAIL PROTECTED]> and Imre Deak <[EMAIL PROTECTED]>
* Copyright (C) 2005 Nokia Corporation
+ * Copyright (C) 2004 - 2007 Texas Instruments.
*
- * Cleaned up by Juha Yrjölä <[EMAIL PROTECTED]>
+ * Originally written by MontaVista Software, Inc.
+ * Additional contributions by:
+ * Tony Lindgren <[EMAIL PROTECTED]>
+ * Imre Deak <[EMAIL PROTECTED]>
+ * Juha Yrjölä <[EMAIL PROTECTED]>
+ * Syed Khasim <[EMAIL PROTECTED]>
*
* 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
@@ -33,8 +35,7 @@
#include
#include
#include
-
-#include
+#include
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -215,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1)
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
*/
+ iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
/*
@@ -334,9 +335,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Enable interrupts */
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -402,8 +403,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
w |= OMAP_I2C_CON_XA;
if (!(msg->flags & I2C_M_RD))
w |= OMAP_I2C_CON_TRX;
+
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
@@ -475,7 +478,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_unidle(dev);
- if ((r = omap_i2c_wait_for_bb(dev)) < 0)
+ r = omap_i2c_wait_for_bb(dev)
+ if (r < 0)
goto out;
for (i = 0; i < num; i++) {
@@ -745,7 +749,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->base = (void __iomem *) IO_ADDRESS(mem->start);
platform_set_drvdata(pdev, dev);
- if ((r = omap_i2c_get_clocks(dev)) != 0)
+ r = omap_i2c_get_clocks(dev)
+ if (r != 0)
goto err_free_mem;
omap_i2c_unidle(dev);
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
From: Paul Walmsley <[EMAIL PROTECTED]>
Skip compiling OMAP15xx I2C ISR for non-OMAP15xx builds. Saves 400 bytes
of text for most OMAP builds.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 52ecddd..9ac64c7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -510,6 +510,9 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+/* rev1 devices are apparently only on some 15xx */
+#ifdef CONFIG_ARCH_OMAP15XX
+
static irqreturn_t
omap_i2c_rev1_isr(int this_irq, void *dev_id)
{
@@ -564,6 +567,9 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
+#else
+#define omap_i2c_rev1_isr 0
+#endif
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
@@ -840,14 +846,14 @@ static struct platform_driver omap_i2c_driver = {
};
/* I2C may be needed to bring up other drivers */
-static int __init
+static int __devinit
omap_i2c_init_driver(void)
{
return platform_driver_register(&omap_i2c_driver);
}
subsys_initcall(omap_i2c_init_driver);
-static void __exit omap_i2c_exit_driver(void)
+static void __devexit omap_i2c_exit_driver(void)
{
platform_driver_unregister(&omap_i2c_driver);
}
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] i2c-omap: Mark init-only functions as __init
From: Paul Walmsley <[EMAIL PROTECTED]>
Mark functions called only at init time as __init.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fdebf96..52ecddd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -154,7 +154,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
return __raw_readw(i2c_dev->base + reg);
}
-static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev->iclk = clk_get(dev->dev, "i2c_ick");
@@ -694,7 +694,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
-static int
+static int __init
omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] i2c-omap: Add support on 34xx
From: Chandra shekhar <[EMAIL PROTECTED]>
Signed-off-by: chandra shekhar <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6cd4d54..fdebf96 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -156,7 +156,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
- if (cpu_is_omap16xx() || cpu_is_omap24xx()) {
+ if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev->iclk = clk_get(dev->dev, "i2c_ick");
if (IS_ERR(dev->iclk)) {
dev->iclk = NULL;
@@ -279,7 +279,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* HSI2C controller internal clk rate should be 19.2 Mhz */
internal_clk = 19200;
@@ -614,7 +614,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
*dev->buf++ = w;
dev->buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430() {
+ if (!cpu_is_omap2430() &&
+ !cpu_is_omap34xx()) {
if (dev->buf_len) {
*dev->buf++ = w >> 8;
dev->buf_len--;
@@ -651,7 +652,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
w = *dev->buf++;
dev->buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430() {
+ if (!cpu_is_omap2430() &&
+ !cpu_is_omap34xx()) {
if (dev->buf_len) {
w |= *dev->buf++ << 8;
dev->buf_len--;
@@ -745,7 +747,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (cpu_is_omap15xx())
dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
u16 s;
/* Set up the fifo size - Get total size */
--
1.5.6.rc3.21.g8c6b5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] i2c-omap: Add high-speed support to omap-i2c
From: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Omap2430 has additional support for high-speed I2C.
This patch moves I2C speed parameter (from module) to platform data.
Also added basic High Speed support based on I2C bus speed.
This patch is tested for high speed I2C (with TWL4030 Keypad) and works as
expected.
Signed-off-by: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 111 +---
1 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a06ad42..0d30790 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -83,6 +83,7 @@
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN(1 << 15) /* I2C module enable */
#define OMAP_I2C_CON_BE(1 << 14) /* Big endian mode */
+#define OMAP_I2C_CON_OPMODE(1 << 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
@@ -91,6 +92,10 @@
#define OMAP_I2C_CON_STP (1 << 1)/* Stop cond (master only) */
#define OMAP_I2C_CON_STT (1 << 0)/* Start condition (master) */
+/* I2C SCL time value when Master */
+#define OMAP_I2C_SCLL_HSSCLL 8
+#define OMAP_I2C_SCLH_HSSCLH 8
+
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 << 15) /* System test enable */
@@ -109,12 +114,6 @@
/* I2C System Configuration Register (OMAP_I2C_SYSC): */
#define OMAP_I2C_SYSC_SRST (1 << 1)/* Soft Reset */
-/* REVISIT: Use platform_data instead of module parameters */
-/* Fast Mode = 400 kHz, Standard = 100 kHz */
-static int clock = 100; /* Default: 100 kHz */
-module_param(clock, int, 0);
-MODULE_PARM_DESC(clock, "Set I2C clock in kHz: 400=fast mode (default ==
100)");
-
struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
@@ -123,6 +122,7 @@ struct omap_i2c_dev {
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
+ u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
size_t buf_len;
@@ -152,17 +152,28 @@ static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
return -ENODEV;
}
}
-
- dev->fclk = clk_get(dev->dev, "i2c_fck");
- if (IS_ERR(dev->fclk)) {
- if (dev->iclk != NULL) {
- clk_put(dev->iclk);
- dev->iclk = NULL;
+ /* For I2C operations on 2430 we need 96Mhz clock */
+ if (cpu_is_omap2430()) {
+ dev->fclk = clk_get(dev->dev, "i2chs_fck");
+ if (IS_ERR(dev->fclk)) {
+ if (dev->iclk != NULL) {
+ clk_put(dev->iclk);
+ dev->iclk = NULL;
+ }
+ dev->fclk = NULL;
+ return -ENODEV;
+ }
+ } else {
+ dev->fclk = clk_get(dev->dev, "i2c_fck");
+ if (IS_ERR(dev->fclk)) {
+ if (dev->iclk != NULL) {
+ clk_put(dev->iclk);
+ dev->iclk = NULL;
+ }
+ dev->fclk = NULL;
+ return -ENODEV;
}
- dev->fclk = NULL;
- return -ENODEV;
}
-
return 0;
}
@@ -210,9 +221,11 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
+ unsigned long internal_clk = 0;
if (!dev->rev1) {
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
@@ -255,18 +268,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
+ if (cpu_is_omap2430()) {
+
+ /* HSI2C controller internal clk rate should be 19.2 Mhz */
+ internal_clk = 19200;
+ fclk_rate = clk_get_rate(dev->fclk) / 1000;
+
+ /* Compute prescaler divisor */
+ psc = fclk_rate / internal_clk;
+ psc = psc - 1;
+
+ /* If configured for High Speed */
+ if (dev->spee
