On Thursday 30 October 2008, Tony Lindgren wrote:
> * David Brownell <[EMAIL PROTECTED]> [081030 20:12]:
> >
> > Related: shouldn't hsmmc_init() accept a set of params, maybe even a
> > struct,
> > describing how each controller is wired?
> >
> > - which controller (1, 2, 3)
> > - how ma
> > >if (qh->type == USB_ENDPOINT_XFER_CONTROL) {
> > > - head = &musb->control;
> > >hw_ep = musb->control_ep;
> > > + head = &hw_ep->in_list;
> >
> > So we only support control in transfer and no hope for control out here?
> Control transfer req
> >
> >hw_ep->regs = MUSB_EP_OFFSET(i, 0) + mbase;
> > #ifdef CONFIG_USB_MUSB_HDRC_HCD
> > + /* init list of in and out qhs */
> > + INIT_LIST_HEAD(&hw_ep->in_list);
> > + INIT_LIST_HEAD(&hw_ep->out_list);
> >hw_ep->target_r
On Thu, Oct 30, 2008 at 8:12 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Thursday 30 October 2008, Tony Lindgren wrote:
>> @@ -212,7 +212,7 @@ static void __init overo_init(void)
>> omap_board_config = overo_config;
>> omap_board_config_size = ARRAY_SIZE(overo_config);
>>
On Thu, Oct 30, 2008 at 5:12 PM, Ajay Kumar Gupta <[EMAIL PROTECTED]> wrote:
> Currently qh list for control, bulkin and bulkout are
> part of musb structure as musb->control, musb->in_bulk
> and musb->out_bulk.This patch makes it generic across
> hw_ep by removing them from musb and mapping them t
* David Brownell <[EMAIL PROTECTED]> [081030 20:12]:
> On Thursday 30 October 2008, Tony Lindgren wrote:
> > @@ -212,7 +212,7 @@ static void __init overo_init(void)
> > omap_board_config = overo_config;
> > omap_board_config_size = ARRAY_SIZE(overo_config);
> > omap_serial_i
On Thursday 30 October 2008, Tony Lindgren wrote:
> @@ -212,7 +212,7 @@ static void __init overo_init(void)
> omap_board_config = overo_config;
> omap_board_config_size = ARRAY_SIZE(overo_config);
> omap_serial_init();
> - hsmmc_init();
> + hsmmc_init(HSMMC1);
O
Otherwise we may race, or will get spurious I2C interrupts:
i2c_omap.1: XDR IRQ while no data to send
...
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/
From: Paul Walmsley <[EMAIL PROTECTED]>
omap_i2c_unidle() and omap_i2c_idle() are called recursively during
omap_i2c_probe(). This is evidently unexpected and will wipe
out the I2C interrupt enable register the second time that
omap_i2c_idle() is called consecutively. Any I2C transactions
follow
Minor sparse, 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/dri
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 |6 ++
1 fil
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
From: Chandra shekhar <[EMAIL PROTECTED]>
Add support for omap34xx
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
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
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 wo
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,
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 w
Hi Ben,
Here's this series posted one more time. I've edited to the second
patch to do a read back of the register instead of wmb(), and also
added one more patch to ensure write posting.
Regards,
Tony
The following changes since commit 0173a3265b228da319ceb9c1ec6a5682fd1b2d92:
Linus Torvalds
Otherwise twl4030 gpios won't work.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/include/mach/irqs.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/irqs.h
b/arch/arm/plat-omap/include/mach/irqs.h
index a2929ac.
On omap24xx, INTCPS_SIR_IRQ_OFFSET bits [6:0] contains the current
active interrupt number.
However, on 34xx INTCPS_SIR_IRQ_OFFSET bits [31:7] also contains the
SPURIOUSIRQFLAG, which gets set if the interrupt sorting information
is invalid.
If the SPURIOUSIRQFLAG bits are not ignored, the interr
From: Zhaolei <[EMAIL PROTECTED]>
debugfs_create_*() returns NULL if an error occurs, returns -ENODEV
when debugfs is not enabled in the kernel.
Comparing to PATCH v1, because clk_debugfs_init is included in
"#if defined CONFIG_DEBUG_FS", we only need to check NULL return.
Thanks Li Zefan <[EMAIL
From: Sanjeev Premi <[EMAIL PROTECTED]>
Fix these compiler warnings:
gpmc.c: In function 'gpmc_init':
gpmc.c:432: warning: 'return' with a value, in function returning void
gpmc.c:439: warning: 'return' with a value, in function returning void
Signed-off-by: Sanjeev Premi <[EMAIL PROTECTED]>
Sig
Hi all,
Here are few omap fixes for the current -rc series.
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
Misc clean-up for hsmmc init
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap2/board-overo.c |2 ++
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/hsmmc.c | 16 +---
arch/
Add support for the second controller hopefully in a generic way.
Also put the twl4030 specific voltage configuration into a separate
function.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-2430sdp.c |4 +-
arch/arm/mach-omap2/board-3430sdp.c |4
Fix voltage defines, make card detect gpio controller specific
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/hsmmc.c | 60 --
1 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/ar
Make hsmmc use omap_ctrl_read/write and existing defines
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/hsmmc.c | 116 +++-
arch/arm/plat-omap/include/mach/control.h | 17
2 files changed, 79 insertions(+), 54 deletions(-)
d
Hi all,
I've been preparing the hsmmc code for mainline so we can mount root.
Here are the related changes for linux-omap for initializing the hsmmc.
This also makes the second controller work, at least on 3430sdp.
If anybody is interested in using the hsmmc with mainline, I've posted
my current
There is now an Android project for Omap on http://android.omapzoom.org and a
discussion list specifically for Android work on Omap. Should be helpful.
...Kd
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-omap-
> [EMAIL PROTECTED] On Behalf Of twebb
> Sent: Monday, Octob
* Lauri Leukkunen <[EMAIL PROTECTED]> [081030 16:29]:
> system_rev is meant for board revision, this patch changes
> all relevant instances to use the new omap_rev() function
> liberating system_rev to be used with ATAG_REVISION as it
> has been designed.
Looks good to me! Let's make sure things s
system_rev is meant for board revision, this patch changes
all relevant instances to use the new omap_rev() function
liberating system_rev to be used with ATAG_REVISION as it
has been designed.
Signed-off-by: Lauri Leukkunen <[EMAIL PROTECTED]>
---
arch/arm/mach-omap1/id.c
The following patch changes all instances where system_rev
is used to identify the omap chip to use omap_rev() instead.
This frees system_rev to be used in its original purpose
with ATAG_REVISION to communicate the board revision instead.
The patch has been compile tested for OMAP3, any feedback
w
From: David Brownell <[EMAIL PROTECTED]>
Build fixes for isp1301_omap; no behavior changes:
- fix incorrect probe() signature (it changed many months ago)
- provide missing functions on H3 and H4 boards
- "sparse" fixes (static, NULL-vs-0)
The H3 build bits subset some of the stuff that wa
* David Brownell <[EMAIL PROTECTED]> [081030 11:16]:
> On Thursday 30 October 2008, Tony Lindgren wrote:
> >
> > Great, to me those look safe to merge. Can you Cc Russell on the
> > arch/arm/*omap* patches if you merge them via gpiolib patches?
> >
> > Basically anything that will cause merge con
From: David Brownell <[EMAIL PROTECTED]>
Build fixes for isp1301_omap; no behavior changes:
- fix incorrect probe() signature (it changed many months ago)
- provide missing functions on H3 and H4 boards
- "sparse" fixes (static, NULL-vs-0)
The H3 build bits subset some of the stuff that wa
On Thursday 30 October 2008, Tony Lindgren wrote:
>
> Great, to me those look safe to merge. Can you Cc Russell on the
> arch/arm/*omap* patches if you merge them via gpiolib patches?
>
> Basically anything that will cause merge conflicts for omap-all
> should go via Russell so we don't frustrate
On Thu, Oct 30, 2008 at 10:41:15AM -0700, Tony Lindgren wrote:
> * twebb <[EMAIL PROTECTED]> [081030 09:22]:
> > Not being very familiar with the kernel development process and git,
> > I'm hoping someone can suggest which code from the l-o git offers the
> > best support of the OMAP35x EVM. I'm g
* twebb <[EMAIL PROTECTED]> [081030 09:22]:
> Not being very familiar with the kernel development process and git,
> I'm hoping someone can suggest which code from the l-o git offers the
> best support of the OMAP35x EVM. I'm guessing it would be the code
> tagged "v2.6.27-omap1" but I'm not sure.
* Jarkko Nikula <[EMAIL PROTECTED]> [081030 06:12]:
> On Wed, 29 Oct 2008 09:00:56 -0700
> "ext Tony Lindgren" <[EMAIL PROTECTED]> wrote:
>
> > Great. One request though:
> >
> > Let's do the clean-up patches in two phases, one series that
> > applies against the mainline kernel, then additional
* David Brownell <[EMAIL PROTECTED]> [081030 00:43]:
> On Wednesday 29 October 2008, Tony Lindgren wrote:
> > Let's do the clean-up patches in two phases, one series that
> > applies against the mainline kernel, then additional patches for
> > linux-omap. Otherwise we'll never get out of this merge
* David Brownell <[EMAIL PROTECTED]> [081029 16:49]:
> On Wednesday 29 October 2008, Tony Lindgren wrote:
> > Let's do the clean-up patches in two phases, one series that
> > applies against the mainline kernel, then additional patches for
> > linux-omap. Otherwise we'll never get out of this merge
On Thursday 30 October 2008, Jarkko Nikula wrote:
>
> > At the end of this patch series, delete these. :)
> >
> Probably these should exist over one release cycle so that out-kernel
> tree projects have time to convert their drivers? No big deal to me,
> but wanted to be kind :-)
The other GPIO
Not being very familiar with the kernel development process and git,
I'm hoping someone can suggest which code from the l-o git offers the
best support of the OMAP35x EVM. I'm guessing it would be the code
tagged "v2.6.27-omap1" but I'm not sure. What's the general
difference between tags "v2.6.2
On Thu, Oct 30, 2008 at 4:45 AM, Mark Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 22, 2008 at 09:44:48PM +0100, Mark Brown wrote:
>> On Wed, Oct 22, 2008 at 01:30:26PM -0700, Steve Sakoman wrote:
>
>> > I am happy to resubmit the patches, if that is what folks want. I'm
>> > copying alsa-devel
On Wed, 29 Oct 2008 09:00:56 -0700
"ext Tony Lindgren" <[EMAIL PROTECTED]> wrote:
> Great. One request though:
>
> Let's do the clean-up patches in two phases, one series that
> applies against the mainline kernel, then additional patches for
> linux-omap. Otherwise we'll never get out of this me
On Wed, 29 Oct 2008 10:46:03 -0700
"ext David Brownell" <[EMAIL PROTECTED]> wrote:
> On Wednesday 29 October 2008, Jarkko Nikula wrote:
> > arch/arm/mach-omap1/leds.c | 4 ++--
>
> A file which *certainly* should vanish,
> along with the leds-{h2p2,inn,osk}*.c
> files it supports.
>
> This is
On Wed, 29 Oct 2008 10:49:49 -0700
"ext David Brownell" <[EMAIL PROTECTED]> wrote:
> Looks OK to me, but I think there's a missing patch:
>
> On Wednesday 29 October 2008, Jarkko Nikula wrote:
> > +static inline int omap_request_gpio(int gpio)
> > +{
> > + return gpio_request(gpio, "FIXME")
On Wed, Oct 22, 2008 at 09:44:48PM +0100, Mark Brown wrote:
> On Wed, Oct 22, 2008 at 01:30:26PM -0700, Steve Sakoman wrote:
> > I am happy to resubmit the patches, if that is what folks want. I'm
> > copying alsa-devel so they can weigh in on the decision.
> Once mainline is merged up to the AS
Removing unnecessary '#ifdef' in 'nand/omap2.c' and changing hwecc config
option from 'int' to 'bool' in 'nand/Kconfig'.
Because of 'int' option hw ecc was always used even if sw ecc had been selected.
Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
---
drivers/mtd/nand/Kconfig |6 ++
dr
Vbus is switched off (after a_wait_bcon) whenever a device
is disconnected from musb host even when musb is configured
only as host.Earlier we use to switch on the power using
[echo "F" >/proc/driver/musb_hdrc] but now this proc entry is
deleted thus musb doesn't work after device disconnect.
This
Currently qh list for control, bulkin and bulkout are
part of musb structure as musb->control, musb->in_bulk
and musb->out_bulk.This patch makes it generic across
hw_ep by removing them from musb and mapping them to
in_list and out_list of hw_ep structure.
Signed-off-by: Ravi Babu <[EMAIL PROTECTE
Fixes endpoint starvation issue when more than one bulk qhs
are multiplexed on reserved bulk endpoint.NAK timeout interval
is set for such qhs and next qh is scheduled when NAK timeout
occurs.
This scheme doesn't work for devices which are connected to a
high to full speed tree as there is no NAK t
On Wednesday 29 October 2008, Tony Lindgren wrote:
> Let's do the clean-up patches in two phases, one series that
> applies against the mainline kernel, then additional patches for
> linux-omap. Otherwise we'll never get out of this merge hell.
Note that the patches I sent were in two phases ... b
From: Jarkko Nikula <[EMAIL PROTECTED]>
Clean up OMAP GPIO request/free functions
- Rename and declare static OMAP specific GPIO request/free functions
- Register them into gpiolib as chip-specific hooks
- Add omap_request_gpio/omap_free_gpio wrappers for existing code not
converted yet to
From: David Brownell <[EMAIL PROTECTED]>
Have most uses of OMAP_GPIO_IRQ() use gpio_to_irq() instead.
Calls used for table initialization are left alone, at least
this time around.
(This patch is for code in both the OMAP tree and mainline.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
From: David Brownell <[EMAIL PROTECTED]>
More conversion to the standard GPIO interfaces: stop using
omap_set_gpio_direction() entirely, and switch over to the
gpio_direction_output() call.
Note that because gpio_direction_output() includes the initial
value, this change isn't quite transparent.
From: David Brownell <[EMAIL PROTECTED]>
Have most uses of OMAP_GPIO_IRQ() use gpio_to_irq() instead.
Calls used for table initialization are left alone, at least
this time around.
(This patches code that's in the OMAP tree but not yet mainline.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
From: David Brownell <[EMAIL PROTECTED]>
More conversion to the standard GPIO interfaces: stop using
omap_set_gpio_direction() entirely, and switch over to the
gpio_direction_output() call.
Note that because gpio_direction_output() includes the initial
value, this change isn't quite transparent.
Second set, plus the first of Jarkko's:
- OMAP tree
* use gpio_direction_output()
* use gpio_to_irq()
- Mainline *and* OMAP trees:
* use gpio_direction_output(), remove the legacy version
* use gpio_to_irq()
* make legacy gpio_request()/gpio_free() calls superfluous
These go
59 matches
Mail list logo
