Hello.
Hema HK wrote:
With OMAP core-off support musb was not functional as context was getting
lost after wakeup from core-off. And also musb was blocking the core-off
after loading the gadget driver even with no cable connected sometimes.
Added the conext save/restore api in the platform
Hello.
Hema HK wrote:
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks,sysconfig settings.
used omap_hwmod_enable_wakeup omap_hwmod_disable_wakeup apis to set/clear
the wakeup enable bit.
Also need to put the USB in force standby and
Hello.
Kalliguddi, Hema wrote:
With OMAP core-off support musb was not functional as context was getting
lost after wakeup from core-off. And also musb was blocking the core-off
after loading the gadget driver even with no cable connected sometimes.
Added the conext save/restore api in the
Hello.
Kalliguddi, Hema wrote:
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hema HK
Sent: Friday, August 06, 2010 10:57 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema;
Hello.
I wrote:
Calling runtime pm APIs pm_runtime_put_sync() and
pm_runtime_get_sync() for enabling/disabling the clocks,sysconfig
settings.
used omap_hwmod_enable_wakeup omap_hwmod_disable_wakeup apis to
set/clear
the wakeup enable bit.
Also need to put the USB in force standby and
Hello.
Tony Lindgren wrote:
From: Kevin Hilman khil...@ti.com
Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
mistakenly removed the check for PER when disabling the IO chain.
During idle, if the PER powerdomain transitions and CORE does not (as
Does not what?
Hello.
Tony Lindgren wrote:
From: Kevin Hilman khil...@ti.com
Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
mistakenly removed the check for PER when disabling the IO chain.
During idle, if the PER powerdomain transitions and CORE does not (as
Does not what?
Hello.
Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
Commit 5a5f561 (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
mistakenly removed the check for PER when disabling the IO chain.
During idle, if the PER powerdomain transitions and CORE does not (as
Does not what?
Hello.
Ming Lei wrote:
Which codebase is this patch meant for?
I don't see the hb_mult in current mainline code?
Are there any patches which this one depends on?
This depends on the two iso for device mode patches:
http://marc.info/?l=linux-usbm=128076716001885w=2
Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
---
drivers/usb/musb/musb_gadget.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index
Hello.
I wrote:
But why not modify the conditional above all that code, just excluding
'is_dma' from it. This conditional already includes (request-actual ==
request-length) check. Please recast this patch.
The two condition is OR relation, not and, so we can't exclude
'is_dma' simply.
Hello.
On 14-09-2010 10:56, Felipe Balbi wrote:
Oops, I've been too fast and haven't realized that the check done here
_is_ actually wrong. It causes ZLP send to trigger too fast in the DMA
case. So please fix this patch. Felipe, please drop it for now.
patch is not even touching that part
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com
[...]
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index fa826f9..cacae96 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb
Hello.
Felipe Balbi wrote:
If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),
Oh, here I mixed some other patch with Ming Lei's ones...
it will pass due to the
than this is the actual problem, no ? If
Hello.
On 15-09-2010 10:53, Felipe Balbi wrote:
If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),
Oh, here I mixed some other patch with Ming Lei's ones...
it will pass due to the
than this is the actual
Hello.
On 15-09-2010 14:05, Felipe Balbi wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before giving back the request.
Well, look at the code ionce again. We need to send ZLP *after*
request-actual == request-length, but as the check is
Hello.
On 15-09-2010 14:14, Ming Lei wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before giving back the request.
Well, look at the code ionce again. We need to send ZLP *after*
request-actual == request-length, but as the check is
On 15.09.2010 14:22, Felipe Balbi wrote:
I don't see why we should fix only this problem, while it's obvious tha
the fix is incomplete and leaves the other problem exposed. Please recast the
patch.
IMO, the ZLP fix is *another* fix and as such subject to a different
patch.
IMHO, this
Hello.
On 15-09-2010 14:31, Felipe Balbi wrote:
IMHO, this fix as it is now is quite stupid. It's clear that the check is
misplaced and will be removed once the ZLP fix is done. So why not do it once
your forgetting the fact that not always you need to send ZLP after
completing a
Felipe Balbi wrote:
your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer,
So what?
what you're saying is that when we change the ZLP handling, the
request-actual == request-lenght check will have to be removed, but
that's not
Ming Lei wrote:
Hi All,
In another thread, Sergei pointed out there is a ZLP issue in musb_g_tx:
Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 15-09-2010 14:05, Felipe Balbi wrote:
I didn't say it was duplicate for DMA, just too late.
how come ? we need to send ZLP before
Hello.
Felipe Balbi wrote:
On Wed, Sep 15, 2010 at 06:02:22AM -0500, Ming Lei wrote:
If so, once the dma interrupt comes, will request-actual be same
with request-length in musb_g_tx? And if it is true, could we remove
the
check for 'is_dma'?
see that is_dma is set to true by just
Hello.
On 16-09-2010 10:05, Felipe Balbi wrote:
I don't see what to rework. The last short packet should still satisfy
(request-actual == request-length) condition, no?
of course not, it's short not zero. so the last short packet can be
anything from 1 to 511 bytes.
Sigh. Where have I
Hello.
On 22-09-2010 4:19, Paul Walmsley wrote:
From: Rajendra Nayakrna...@ti.com
If a module's OCP slave port is programmed to be in smartidle,
its also necessary that they have module level wakeup enabled.
Update _sysc_enable in hwmod framework to do this.
The thread [PATCH 7/8] :
Hello.
Hema HK wrote:
OMAP USBOTG modules has a requirement to set the auto idle bit only after
setting smart idle bit. Modified the _sys_enable api to set the smart idle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.
Signed-off-by: Hema HK
Hello.
On 23-09-2010 9:50, Maulik wrote:
-Original Message-
From: Hema HK [mailto:hem...@ti.com]
Sent: Thursday, September 23, 2010 6:01 AM
To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Cc: Hema HK; Maulik Mankad; Felipe Balbi; Tony Lindgren; Kevin Hilman;
Cousson, Benoit;
Hello.
Felipe Balbi wrote:
I guess that's Felipe's call, but I don't like that option.
I think it's cleaner to have the -set_clock hook be a noop on OMAP and
the runtime hooks be noops on the other platforms.
Agreed. We should focus on removing -set_clock for .38 actually. Is
DaVinci
Hello.
On 27-09-2010 10:07, Felipe Balbi wrote:
I guess that's Felipe's call, but I don't like that option.
I think it's cleaner to have the -set_clock hook be a noop on OMAP and
the runtime hooks be noops on the other platforms.
Agreed. We should focus on removing -set_clock for .38
Hello.
On 28-09-2010 14:35, Arun Murthy wrote:
A new element 'name' is added to pwm led platform data structure.
This is required to identify the pwm device.
Signed-off-by: Arun Murthyarun.mur...@stericsson.com
Acked-by: Linus Walleijlinus.wall...@stericsson.com
[...]
diff --git
Hello.
Ajay Kumar Gupta wrote:
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
drivers/usb/musb/am35x.c | 30 ++
drivers/usb/musb/musb_core.c |
Hello.
Ajay Kumar Gupta wrote:
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Also added USB_MUSB_AM35X which is required to differentiate musb ips
between OMAP3x and AM35x.
Hello.
Igor Grinberg wrote:
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Also added USB_MUSB_AM35X which is required to differentiate musb ips
between OMAP3x and AM35x.
Hello.
On 04-10-2010 23:15, Paul Walmsley wrote:
--- /dev/null
+++ b/arch/arm/plat-omap/32ksynctimer.c
@@ -0,0 +1,184 @@
+/*
+ * linux/arch/arm/plat-omap/clocksource.c
What name do you want to use? 32ksynctimer.c or clocksource.c?
Thanks, that's a bug.
And also note that filenames
Hello.
On 31-10-2010 8:25, Anand Gadiyar wrote:
The Inventra DMA engine in version 1.8 and later of the MUSB
controller cannot handle DMA addresses that are not aligned
to a 4 byte boundary. It ends up ignoring the last two bits
programmed in the DMA_ADDR register. This is a deliberate
design
Hello.
Hari Kanigeri wrote:
Fix the checkpatch warnings observed in mailbox module
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c
Hello.
On 14-11-2010 14:34, Marc Zyngier wrote:
Commit 72f381ba056 removed an unused regulator entry, but left
Linus has aksed to also specify the commit summary in parentheses.
Signed-off-by: Marc Zyngierm...@misterjones.org
Cc: Enric Balletbo i Serraeballe...@gmail.com
Cc: Tony
Hello.
On 16-11-2010 13:25, Paul Walmsley wrote:
After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog
Linus has asked to also specify the commit summary in parens...
probing is handled by files in mach-omap1/ and mach-omap2/, and the
plat-omap/devices.c probing code is no
Hello.
On 19-11-2010 19:07, srin...@mistralsolutions.com wrote:
From: Srinathsrin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
Signed-off-by:
Hello.
On 29-11-2010 20:25, Anand Gadiyar wrote:
Introduce helper functions to test port mode. These checks are
performed in several places in the driver, and these helpers
improve readability.
Signed-off-by: Anand Gadiyargadi...@ti.com
[...]
diff --git a/drivers/usb/host/ehci-omap.c
Hello.
Ajay Kumar Gupta wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[...]
diff --git
Hello.
On 06-12-2010 11:13, Ajay Kumar Gupta wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
I'm not fond of the whole approach. I'm not sure why
Hello.
Gupta, Ajay Kumar wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
I'm not fond of the whole approach. I'm not sure why accesses to the
Hello.
On 06-12-2010 20:54, Tony Lindgren wrote:
As the control.h have been moved to new location and it's
uses are not allowed to drivers directly so moving the phy
control, interrupt clear and reset functionality to board
files.
I'm not fond of the whole approach. I'm not sure why
Hello.
Hema HK wrote:
Selecting the twl6030-usb for OMAP4430SDP and OMAP4 PANDA board and
adding OMAP4 internal phy code for compilation
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
[...]
Index: linux-2.6/drivers/usb/musb/Kconfig
Hello.
Hema HK wrote:
Added the TWL6030-usb transceiver option in the Kconfig
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: David Brownell dbrown...@users.sourceforge.net
[...]
Index: linux-2.6/drivers/usb/otg/Kconfig
Hello.
On 08-12-2010 19:01, Hema HK wrote:
Registering the twl6030-usb transceiver device as a child to twl6030 core.
Removed the NOP transceiver init call from board file.
Populated twl4030_usb_data platform data structure with the function
pointers for OMAP4430 internal PHY operation to
Hello.
Kevin Hilman wrote:
The resource data is getting automatically populated from a set of data
generated from TI's hardware database for the OMAP platform,
While we could hack in some exceptions to that tool to generate resources
in a specific order, it seems less fragile to use the
Hello.
On 10-12-2010 7:46, Kalliguddi, Hema wrote:
The resource data is getting automatically populated from a set of data
generated from TI's hardware database for the OMAP platform, While we
could hack in some exceptions to that tool to generate resources
in a specific order, it seems less
Hello.
On 10-12-2010 15:38, Hema HK wrote:
Added the TWL6030-usb transceiver option in the Kconfig
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: David Brownelldbrown...@users.sourceforge.net
[...]
Index: usb/drivers/usb/otg/Kconfig
Hello.
On 10-12-2010 15:40, Hema HK wrote:
Add the twl6030_usb transceiver file for compilation.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe Balbiba...@ti.com
Index: usb/drivers/usb/otg/Makefile
===
---
Hello.
On 10-12-2010 16:20, Felipe Balbi wrote:
The resource data is getting automatically populated from a set of data
generated from TI's hardware database for the OMAP platform, While we
could hack in some exceptions to that tool to generate resources
in a specific order, it seems less
Hello.
Felipe Balbi wrote:
Index: linux-omap-pm/arch/arm/mach-davinci/usb.c
===
--- linux-omap-pm.orig/arch/arm/mach-davinci/usb.c
+++ linux-omap-pm/arch/arm/mach-davinci/usb.c
@@ -64,10 +64,12 @@ static struct resource
Hello.
Kevin Hilman wrote:
Removed the board_data parameter being passed to musb_platform_init function
as board data can be extracted from device structure which is already member of
musb structure.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren
Hello.
Greg KH wrote:
Removed the board_data parameter being passed to musb_platform_init function
as board data can be extracted from device structure which is already member of
musb structure.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Tony Lindgren
Hello.
On 11-12-2010 20:43, Greg KH wrote:
Removed the board_data parameter being passed to musb_platform_init function
as board data can be extracted from device structure which is already member of
musb structure.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: Tony
Hello.
On 16-12-2010 18:25, srin...@mistralsolutions.com wrote:
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
History:
Hello.
On 30-12-2010 15:27, Felipe Balbi wrote:
Is this change slated to go into 2.6.37? As it stands it looks like
2.6.37 will be released with completely broken musb support on many boards
(including the BeagleBoard).
yes, it is.
Are you sure? We are currently at -rc8 and yet this
Hello.
Felipe Balbi wrote:
Yes. The patch is waiting for the merge window, check linux-next or
Greg's usb-next branch.
So I guess no working USB in 2.6.37 in that case?
For am35x, I guess not. All in all, it was a change to omap's arch code
which broke am35x in the first place. Well, the
Hello.
On 03-01-2011 23:44, Felipe Balbi wrote:
Moreover, even Felipe also seems to move other musb
DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma.
Frankly speaking, I doubt that drivers/dma/ will have place for the
purely MUSB specific DMA engines such as the named ones (there's no TUSB
Hello.
Felipe Balbi wrote:
I think we will get more clarity once we start on this activity.
I agree, but I personally don't see that many limiting factors.
dmaengine is just a generic API for doing DMA transfers. If it's not
enough for us currently, we extend it.
Putting MUSB DMA
Hello.
Felipe Balbi wrote:
On Tue, Jan 04, 2011 at 11:41:05PM +0800, Ming Lei wrote:
OMAP GPIOs have many usages or use cases, so we can use gpiolib
to simplify access to GPIOs. If GPIOs has only one usage or use case,
it is not necessary to access GPIOs by gpiolib.
Now this kind of DMA
Hello.
On 17-01-2011 13:08, Vasiliy Kulikov wrote:
kzalloc() may fail, if so return -ENOMEM.
Signed-off-by: Vasiliy Kulikovseg...@openwall.com
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..871bca9 100644
---
Hello.
Thomas Weber wrote:
The reset_gpio pin for lcd is connected with TWL4030 LedA.
TWL4030 GPIO.1 has a not connected resistor.
Fix indention issue.
Indentation.
The comment line uses 8 whitespaces.
Replaced with one tabulator.
Reported-by: Daniel Morsing
Hello.
On 19-01-2011 11:19, Thomas Weber wrote:
The return value of gpio_request is ignored.
This patch adds the check of the return value of gpio_request.
Signed-off-by: Thomas Weberwe...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 16 ++--
1 files changed,
Hello.
On 19-01-2011 23:54, Ari Kauppi wrote:
Always allow backtrace when using oprofile on ARM, even if a PMU
isn't present.
Restores functionality originally introduced in
1b7b56982fdcd9d85effd76f3928cf5d6eb26155 by Richard Purdie.
You're lacking the commit summary specified in
Hello.
On 22-01-2011 13:05, Sumit Semwal wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
DSS IRQ number can be obtained from platform_get_irq(). This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.
Hello.
On 03-02-2011 12:49, Hema HK wrote:
Introduce the .phy_suspend function pointer to twl4030_usb_data structure.
assign the function to it for both sdp board and panda boards.
This will be used by the twl6030-usb transceiver driver.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe
Hello.
On 03-02-2011 12:49, Hema HK wrote:
Introduce the .phy_suspend function pointer to twl4030_usb_data structure.
assign the function to it for both sdp board and panda boards.
This will be used by the twl6030-usb transceiver driver.
Signed-off-by: Hema HKhem...@ti.com
Cc: Felipe
Hello.
On 01-02-2011 18:36, Aaro Koskinen wrote:
With the commit 757902513019e6ee469791ff76f954b19ca8d036 fixed voltage
Please also specify the commit summary in parens, as asked by Linus.
regulator setup will fail if there are voltage constraints defined. This
made MMC unusable on this
Tony Lindgren wrote:
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
In its current form, the omap_mcbsp_request() function can return after
irq_request() failure without any cleanups, effectively locking out the port
forever with clocks left running. Fix it.
Signed-off-by: Janusz
Hello.
Gadiyar, Anand wrote:
From: Felipe Balbi wrote:
+ /* On MUSB:RTL1.8 and above, DMA has to be word aligned */
+ if ((dma_addr % 4)
+ (musb-hwvers = MUSB_HWVERS_1800)) {
is it only inventra dma that suffers from this ? If not, we could move
this
Hello.
Paul Walmsley wrote:
From: Vishwanath BS vishwanath...@ti.com
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for
OMAP3630. So remove references to that.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
Hello.
Maulik Mankad wrote:
This patch adds CONFIG_ARCH_OMAP4 macro within MUSB driver
code and builds the MUSB driver for OMAP4.
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: David Brownell davi...@pacbell.net
Hello.
Venkatraman S wrote:
It is observed that sometimes the MMC Transfer Complete (TC) is not
received when DMA completion callback is processed (or takes too long
to process)
This patch moves the releasing of DMA channel from dma callback to the
mmc transfer complete handler.
This is
Hello.
Ajay Kumar Gupta wrote:
Adding 'musb_hdrc_board_data' which will have all the board specific
parameters such as; mA power, potpgt, extvbus, gpios etc.
Currently only 'power' and 'potpgt' is being moved from existing
'musb_hdrc_platform_data' to 'musb_hdrc_board_data' but any further
Hello.
Ajay Kumar Gupta wrote:
Different board may have different power sourcing capability and
now with 'struct musb_hdrc_board_data' in place; pass this data
from board files and also modify musb_core.c to get 'power' data
from 'plat-board_data'.
This should be part of the patch 1/8 to
Ajay Kumar Gupta wrote:
setup_usb() has been modified to pass board specific data so updating
this function call from all Davinci based boards.
Added struct device; to fix below compilation warning for Davinci boards.
musb.h: struct device, defined within parameter list
You should fix
Ajay Kumar Gupta wrote:
Adding 'musb_hdrc_board_data' which will have all the board specific
parameters such as; mA power, potpgt, extvbus, gpios etc.
Currently only 'power' and 'potpgt' is being moved from existing
'musb_hdrc_platform_data' to 'musb_hdrc_board_data' but any further
board
Ajay Kumar Gupta wrote:
Default value of 'extvbus' is being set as '0' to maintain the
current programming state of all OMAP3 musb boards.
This flag should be set to '1' for boards using external vbus
supply such as, OMAP3EVM Rev =E.
This patch is rather pointless as the struct fieds not
Ajay Kumar Gupta wrote:
Default value of 'extvbus' is being set as '0' to maintain the
current programming state of all Davinci musb boards.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Pointless patch again...
WBR, Sergei
--
To unsubscribe from this list: send the line
Ajay Kumar Gupta wrote:
setup_usb() has been modified to pass board specific data so updating
this function call from all Davinci based boards.
Added struct device; to fix below compilation warning for Davinci boards.
musb.h: struct device, defined within parameter list
Signed-off-by:
Ajay Kumar Gupta wrote:
setup_usb() has been modified to pass board specific data so updating
this function call from all Davinci based boards.
Added struct device; to fix below compilation warning for Davinci boards.
musb.h: struct device, defined within parameter list
Signed-off-by:
Ajay Kumar Gupta wrote:
Default value of 'extvbus' is being set as '0' to maintain the
current programming state of all Blackfin musb boards.
Again, you could keep the structures unitialized so that they default to
all zeros (which they do anyway for the 'power' and 'potpgt' fields with
Ajay Kumar Gupta wrote:
musb_init() has been modified to pass board specific data so updating
this function call from all OMAP3 boards.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index
Hello.
Ajay Kumar Gupta wrote:
This patch set adds a new structure 'musb_hdrc_board_data' to get all
board specific data from board files.
It is actually done to accomodate ULPI_VBUSCONTROL programming required
for OMAP3EVM Rev =E which uses external Vbus supply to support 500mA.
It's
Hello.
Santosh Shilimkar wrote:
On OMAP4430 the UART3 base address is different than that on OMAP3.
Because of this existing code needs additional #ifdef'ry to accommodate
that code. Hence this patch separates it. Also UART3 base address is
fixed for OMAP4430 in this patch.
Signed-off-by:
Hello.
Shilimkar, Santosh wrote:
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
Sent: Thursday, December 10, 2009 4:06 PM
To: Shilimkar, Santosh
Cc: t...@atomide.com; linux-omap@vger.kernel.org; li...@arm.linux.org.uk;
linux-arm-
ker...@lists.infradead.org
Hello.
Felipe Balbi wrote:
each board might have a different charge pump and
thus able to source more or less current on vbus
so let power be easily configurable.
Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
[...]
diff --git
Hello.
Felipe Balbi wrote:
get rid of the set_clock hackery.
Cc: linux-...@vger.kernel.org
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
Greg, I'll send this patch to you shortly, it's
only here so that Tony can have it in linux-omap-2.6
to avoid breaking any of his boards.
Hello.
Felipe Balbi wrote:
we are using clkdev and the driver can use whatever
name it wants.
It's not so actually. This depends on the matching mechanism
established within clkdev: by device, by name, or by both. Not all
implementations will match by device, e.g. DA8xx/OMAP-L1x will
Hello.
Maulik Mankad wrote:
ARM : OMAP4 : Add USB support to 4430 SDP board file
This patch adds support for Mentor USB to 4430 SDP board file.
It also defines the base address for HS USB OTG controller in OMAP4.
Also updates platform specfic structure with base address and IRQ details.
Hello.
Felipe Balbi wrote:
Why always ick?! Do you think OMAPs are the only boards using MUSB
out there?
err, I'm afraid you have to read more about clock framework. The clock
name should not matter when you issue clk_get().
It depends on the matching type determined from a
Hello.
Felipe Balbi wrote:
It's not so actually. This depends on the matching mechanism
established within clkdev: by device, by name, or by both. Not all
implementations will match by device, e.g. DA8xx/OMAP-L1x will match by
clock name.
then it has to be fixed. The name shouldn't
Hello.
Felipe Balbi wrote:
Why always ick?! Do you think OMAPs are the only boards using MUSB
out there?
err, I'm afraid you have to read more about clock framework. The clock
name should not matter when you issue clk_get().
It depends on the matching type
Hello.
Felipe Balbi wrote:
Gotcha. This will match in clk_find() by both device and clock name,
so clk_get() will fail with your patch.
then, when it doesn't find, it'll try device id only:
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy
Hello.
Felipe Balbi wrote:
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
* An entry with a NULL ID is assumed to be a wildcard.
* If an entry has a device ID, it must match
* If an entry has a connection ID, it must match
*
Hello.
Maulik Mankad wrote:
ARM : OMAP : Add empty function in header file
This patch adds empty functions for usb_nop_xceiv_register()
and usb_nop_xceiv_unregister() so that these functions
can be called even when CONFIG_NOP_USB_XCEIV is not
enabled.
It allows to remove ifdef's from
Ajay Kumar Gupta wrote:
urb-transfer_buffer_length and urb-transfer_buffer should be
updated based on urb-actual_length.For a fresh and first time urb,
actual_length will be zero but for urbs which has been stopped and
restarted (as bulk nak scheme does) actual_length may not be zero.
Hello.
David Brownell wrote:
Ajay Kumar Gupta wrote:
urb-transfer_buffer_length and urb-transfer_buffer should be
updated based on urb-actual_length.For a fresh and first time urb,
actual_length will be zero but for urbs which has been stopped and
restarted (as bulk nak scheme does)
Hello.
Ajay Kumar Gupta wrote:
AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode and there are on-going
discussions on location of CPPI4.1 DMA.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/Kconfig |4 +-
1 - 100 of 409 matches
Mail list logo
