Re: [RFC] How to pass camera Orientation to userspace
Trent Piepho wrote: On Mon, 23 Feb 2009, Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Trent Piepho wrote: On Sun, 22 Feb 2009, Hans de Goede wrote: Yes that is what we are talking about, the camera having a gravity switch (usually nothing as advanced as a gyroscope). Also the bits we are talking about are in a struct which communicates information one way, from the camera to userspace, so there is no way to clear the bits to make the camera do something. First, I'd like to say I agree with most that the installed orientation of the camera sensor really is a different concept than the current value of a gravity sensor. It's not necessary, and maybe not even desirable, to handle them in the same way. I do not see the advantage of using reserved bits instead of controls. The are a limited number of reserved bits. In some structures there are only a few left. They will run out. Then what? Packing non-standard sensor attributes and camera sensor meta-data into a few reserved bits is not a sustainable policy. Controls on the other card are not limited and won't run out. Yes but these things are *not* controls, end of discussion. The control API is for controls, not to stuff all kind of cruft in. All kind of cruft belongs in the reserved bits of whatever field it can be stuffed in? Not whatever field, these are input properties which happen to also be pretty binary so putting them in the input flags field makes plenty of sense. What is the difference? Why does it matter? Performance? Maintenance? Is there something that's not possible? I do not find end of discussion to be a very convincing argument. Well they are not controls, that is the difference, the control interface is for controls (and only for controls, end of discussion if you ask me). These are not controls but properties, they do not have a default min and max value, Camera pivot sensor ranges from 0 to 270. How is that not a min and max? they have only one *unchanging* value, there is nothing the application can Camera sensors don't have an unchanging value. And who says scan order can't change? Suppose the camera returns raw bayer format data top to bottom, but if you request yuv then an image processing section needs to kick in and that returns the data bottom to top. Yes, because hardware designers like throwing away lots of transistors to memory so they are going to put memory in the controller to buffer an entire frame and then scan out the memory buffer in different order then the sensor gave them the data, so they cannot do FIFO, so they will actually need 2 frames of memory. If the sensor is soldered upside down on the PCB that is a very much unchanging value, and an input property if you ask me. So new proposal: use 2 bits in the input flags to indicate if the input is hardwired vflipped and/or hflipped. Create a new class of controls for querying possible changing camera properties like pivoting and aperture. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Monday 23 February 2009 10:08:54 ext DongSoo(Nathaniel) Kim wrote: So, logically it does not make sense with making device nodes of every single slave attached with OMAP3camera interface. Because they can't be opened at the same time,even if it is possible it should not work properly. So.. how about making only single device node like /dev/video0 for OMAP3 camera interface and make it switchable through V4L2 API. Like VIDIOC_S_INPUT? You are right that if the OMAP3 has several camera sensors attached to its camera interface, generally just one can be used at once. However, from user's perspective those are still distinct cameras. Many v4l2 applications don't support VIDIOC_S_INPUT or at least it will be more difficult to use than just pointing an app to the correct video device. Logically they are two independent cameras, which can't be used simultaneously due to HW restrictions. - Tuukka -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to pass camera Orientation to userspace
On Sat, 21 Feb 2009 12:53:57 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Adam, Sorry for the late reply, it's been very busy. Me too. 1) Reuse the existing HFLIP and VFLIP controls, marking them as read-only Pros : No change needed to videodev2.h Cons: It is confusing to have controls that have a subtly different meaning if they are read only. Existing apps that support those controls might get confused. Would require polling to support the case of a camera being turned toward / away from the user while streaming. Reusing an existing control for a different meaning seems wrong. What happens when some cam has the capability of doing hardware flipping, and have the cam flipped? 2) Introduce a new orientation control (possibly in a new CAMERA_PROPERTIES class) Pros: libv4l can easily tell if the driver supports the control. Cons: It is really a property, not a control so calling it a control is wrong. Controls add lots of overhead in terms of driver code. Would require polling to support the case of a camera being turned toward / away from the user while streaming. I think this could be a good idea, but I agree with Hans Verkuil comments: since this is a characteristics for a given input, using a control here would mean that the driver will return it based on the selected input. Seems a little messy. Also, a mounted characteristics of the device, is not really a sensor, as Hans de Goede pointed. 3) Use an extra couple of bits in V4L2_BUF_FLAGS Pros: Simple to implement. Can change per frame without needing polling. Cons: Doesn't work for non libv4l apps that try to use the read() interface. Can't easily identify drivers that don't support it (does 0 mean not rotated or just not implemented). Can only be read when streaming (does that matter?) I think that matters, yes. I don't think this is a good idea. The metadata at the frame polling is meant to return the stream info. We shouldn't mix sensor position here. 4) Use some reserved bits from the v4l2_capability structure Pros: Less overhead than controls. Cons: Would require polling to support the case of a camera being turned toward / away from the user while streaming. Can't easily identify drivers that don't support it. 5) Use some reserved bits from the v4l2_input structure (or possibly the status word but that is normally only valid for current input) Pros: Less overhead than controls. Could support multiple sensors in one camera if such a beast exists. What does exist is devices with a video input (e.g. composite) and a camera input: each input will have different flags. Since these vflip/hflip properties do not change they can be enumerated in advance and you know what each input supports. Cons: Would require polling to support the case of a camera being turned toward / away from the user while streaming. Polling applies only to the bits that tell the orientation of the camera. See below for a discussion of this. Analog tv does polling for signal strength, since userspace apps do mute and stops presenting video, if the signal is too weak. IMO, a similar mechanism should be used by pivoting. IMO, this would be better addressed as a property of v4l2_input. So, I think that (5) is better than (4). Can't easily identify drivers that don't support it. Not too difficult to add through the use of a capability bit. Either in v4l2_input or (perhaps) v4l2_capability. Another Pro is that this approach will also work for v4l2_output in the case of, say, rotated LCD displays. Using camera orientation bits in v4l2_buffer while capturing will work, but using similar bits for output will fail since the data is going in the wrong direction. The interest in detecting if a driver provides this informnation is to allow libv4l to know when it should use the driver provided information and when it should use its internal table (which needs to be retained for backward compatibility). With no detection capability the driver provided info should be ignored for USB IDs in the built in table. Thoughts please There is a case that we should think: at libv4l, we may need to override the default orientation, by a custom one. For example: Surveillance systems have cameras mounted on a fixed position. Depending on the camera, and the desired position, some cameras may needed to be mounted rotated (the same case also applies to some embedded hardware like ATM machines, where a webcam maybe mounted with 180 degrees, due to hardware constraints). Ok, this is nothing that kernel needs to handle, but, at userspace, we need to have a file where the user could edit and store the camera position, to override whatever we have in kernel. Is polling bad in this case? It is not something that needs immediate attention IMHO. The overhead for checking once every X seconds is quite low. Furthermore, it is only needed on devices that cannot do v/hflipping in
Help- twl4030 audio driver for linux2.6.26 + OMAP2430
Hi, Please forgive me if i am interepting you all. I am a newbie in linux, and i am trying to make audio working on OMAP-2430 board. Linux version used is linux-2.6.26. I am trying to find twl4030 audio driver in net. But couldn't get it. Can anybody please help me??? thanks regards Mathews John __ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
Hi,
On Mon, Feb 23, 2009 at 5:04 PM, Adrian Hunter
ext-adrian.hun...@nokia.com wrote:
ext Kim Kyuwon wrote:
Hi,
On Sat, Feb 21, 2009 at 6:11 AM, David Brownell davi...@pacbell.net wrote:
On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id == OMAP_MMC1_DEVID) {
+ hctl = SDVS30;
Shouldn't it be remembering what voltage it was using,
and then restore that, instead of always making MMC1
restart at a 3.0V level? That's pretty awkward to test
unless you have a 1.8V-capable card in MMC1...
You are somewhat right, thank you.
But remebering what voltage it was using doesn't feasible to me,
because the card can be changed while in 'Sleep' state. I should have
inserted a function that detect the right voltage after intializing. I
will resend the patch later.
Doesn't it already do that? Can you explain more?
Although I have not tested it, I very much doubt
dual-voltage cards work. That is because VMMC1_185V
is zero, which has the side-effect of turning the
regulator off (see arch/arm/mach-omap2/mmc-twl4030.c)
It's also to difficult to test in our H/W since it's configured only
support 3.0V.
How about to separate it two phases, first fix the mmc suspend/resume
works again, and then verify dual voltage if there are these hardware
How to you think?
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help- twl4030 audio driver for linux2.6.26 + OMAP2430
Mathews John said the following on 02/23/2009 02:18 PM: I am a newbie in linux, and i am trying to make audio working on OMAP-2430 board. Linux version used is linux-2.6.26. I am trying to find twl4030 audio driver in net. But couldn't get it. Can anybody please help me??? Just follow [1] to get the code downloaded. then look at sound/soc/codecs/twl4030.c (quick link - [2]) Regards, Nishanth Menon Ref: [1] http://muru.com/linux/omap/README_OMAP_GIT [2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=sound/soc/codecs/twl4030.c;h=ea370a4f86d5a2c74d97b176d977a55947ab120e;hb=HEAD -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3530 USB host problems
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 08:41:58PM +0100, ext Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
Sadly, I've already tried this and things just continue to fall apart.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
Internal error: : 1008 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-omap1-svn4799-dirty14 #60)
PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
LR is at release_console_sem+0x1a8/0x1d8
Hence, my desired to figure out the TLL timeout...
keep TLL as is, the problem now seems to be a clock that should be on
and is off. Try to figure (with printk() for example) at which line the
code stops, put printk() before and after register read/write operations
during probe and omap_start_ehc(), let's see where does it dies.
any news ??
Not really; I'd like to figure out *why* this part of the USB
device isn't working, not just find a way around it...
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
Kyungmin Park wrote:
Hi,
On Mon, Feb 23, 2009 at 5:04 PM, Adrian Hunter
ext-adrian.hun...@nokia.com wrote:
ext Kim Kyuwon wrote:
Hi,
On Sat, Feb 21, 2009 at 6:11 AM, David Brownell davi...@pacbell.net wrote:
On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, capa, value;
+
+ /* Only MMC1 supports 3.0V */
+ if (host-id == OMAP_MMC1_DEVID) {
+ hctl = SDVS30;
Shouldn't it be remembering what voltage it was using,
and then restore that, instead of always making MMC1
restart at a 3.0V level? That's pretty awkward to test
unless you have a 1.8V-capable card in MMC1...
You are somewhat right, thank you.
But remebering what voltage it was using doesn't feasible to me,
because the card can be changed while in 'Sleep' state. I should have
inserted a function that detect the right voltage after intializing. I
will resend the patch later.
Doesn't it already do that? Can you explain more?
Although I have not tested it, I very much doubt
dual-voltage cards work. That is because VMMC1_185V
is zero, which has the side-effect of turning the
regulator off (see arch/arm/mach-omap2/mmc-twl4030.c)
It's also to difficult to test in our H/W since it's configured only
support 3.0V.
How about to separate it two phases, first fix the mmc suspend/resume
works again, and then verify dual voltage if there are these hardware
How to you think?
Yes certainly.
The original code assumes that 'host' may be NULL in omap_mmc_suspend ()
and omap_mmc_resume(), whereas the patch assumes 'host' is never NULL.
I suggest:
static int omap_mmc_suspend(struct platform_device *pdev, pm_message_t state)
{
int ret = 0;
struct mmc_omap_host *host = platform_get_drvdata(pdev);
- if (host host-suspended)
+ if (!host || host-suspended)
return 0;
and
static int omap_mmc_resume(struct platform_device *pdev)
{
int ret = 0;
struct mmc_omap_host *host = platform_get_drvdata(pdev);
- if (host !host-suspended)
+ if (!host || !host-suspended)
return 0;
Also the patch does not wait for the bus voltage (SDBP bit) to
initialise. For the sake of correctness, I would add something
like:
OMAP_HSMMC_WRITE(host-base, HCTL, value | SDBP);
+ for (i = 0; i loops_per_jiffy; i++) {
+ if (OMAP_HSMMC_READ(host-base, HCTL) SDBP)
+ break;
+ cpu_relax();
+ }
Also, you will need the following patch if you actually want the power
to go off.
From: Adrian Hunter ext-adrian.hun...@nokia.com
Date: Fri, 30 Jan 2009 11:58:13 +0200
Subject: [PATCH] OMAP: HSMMC: do not power up after powering off
The power is configured when probing and when resuming
so the bus voltage does not need changing after power
off.
Signed-off-by: Adrian Hunter ext-adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1e4a2e0..04e5a0c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -859,16 +859,6 @@ static void omap_mmc_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_OFF:
mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
- /*
-* Reset bus voltage to 3V if it got set to 1.8V earlier.
-* REVISIT: If we are able to detect cards after unplugging
-* a 1.8V card, this code should not be needed.
-*/
- if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
- int vdd = fls(host-mmc-ocr_avail) - 1;
- if (omap_mmc_switch_opcond(host, vdd) != 0)
- host-mmc-ios.vdd = vdd;
- }
break;
case MMC_POWER_UP:
mmc_slot(host).set_power(host-dev, host-slot_id, 1, ios-vdd);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [pacth] I2C bug fixes for L-O and L-Z
On Fri, 2009-02-20 at 21:59 +0100, ext Woodruff, Richard wrote: I received the following comment from a HW Apps person whom has dealt with this at the board level. comment start Attached is the I2C spec that I have. As I understand it, the I2C only specify the minimum tLow and tHigh (which is not balanced). However what is more important is that the appropriate setup and hold time are followed. If the equal time still meets the setup/hold time then there should not be any issue from a compliance standpoint. comment end Regards, Richard W. Hi, With out board, the tLow and tHigh values are in line with I2C standard with the patch: http://marc.info/?l=linux-omapm=122770723311340w=2 Would that risk the setup and hold times? (If I remember correctly, the values (setup, hold) were within the I2C standard even with the patch.) I think it's a risk not to meet tLow and tHigh. I'm saying, with open source values with our board, the tLow was not in standard. If using TRM minimum values, things get even worse. Why? because it states, for example, Fast Mode SCLL = 5 and SCLH = 7. This means that the low period is smaller than the high! Shouldn't it be vice versa? (scope verified). - Eero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3530 USB host problems
On Mon, Feb 23, 2009 at 02:08:12PM +0100, ext Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 08:41:58PM +0100, ext Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device
*dev, struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
Sadly, I've already tried this and things just continue to fall apart.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
Internal error: : 1008 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-omap1-svn4799-dirty14 #60)
PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
LR is at release_console_sem+0x1a8/0x1d8
Hence, my desired to figure out the TLL timeout...
keep TLL as is, the problem now seems to be a clock that should be on
and is off. Try to figure (with printk() for example) at which line the
code stops, put printk() before and after register read/write operations
during probe and omap_start_ehc(), let's see where does it dies.
any news ??
Not really; I'd like to figure out *why* this part of the USB
device isn't working, not just find a way around it...
It's not a way around it. That bit is wrong, one problem is fixed now
but we came to another issue which is a non-linefetch, which makes me
wonder that's a clock issue.
You should just try to fetch me for information and I might be able to
help you more.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Configuring a TWL GPIO pin as an interrupt
On Mon, Feb 23, 2009 at 12:07:25AM -0600, Lopez Cruz, Misael wrote: In the particular case of ALSA SoC, could the machine/board driver be a better place to handle all GPIO/IRQ configuration? That driver also contains only board specific code.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Normally the arch/arm code would configure any multi-function pins (this is normally required for lowest power consumption) and the actual IRQ requesting and so on would be done by the machine and/or codec drivers (depending on how exactly the hardware implements this). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: leds-gpio broken with current git?
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of David Brownell Sent: Thursday, January 15, 2009 9:59 AM To: Koen Kooi Cc: linux-omap@vger.kernel.org List Subject: Re: leds-gpio broken with current git? On Thursday 15 January 2009, Koen Kooi wrote: I've been playing with different kernels on beagleboard lately and it seems that somewhere between 2.6.28rc8 and the final release leds- gpio got broken for beagleboard: Registered led device: beagleboard::usr0 Registered led device: beagleboard::usr1 leds-gpio: probe of leds-gpio failed with error -22 Works for me, no -EINVAL, on 2.6.28-omap1 and no patches that should affect GPIOs or LEDs. Last patch applied to GIT is 15f75b6226c2d3b82062bb721e7cb9a1d6f35efd (musbhsdma). OK, I'm just pulling a new batch of objects, I'm guessing Tony snuck in RC1 already ... yes, I see he just sent a post about that a few minutes ago. ;) Perhaps something broke with Tony's RC1 merge? The LEDs are broken for me as well. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH B 06/10] OMAP3 pwrdm: add CORE SAR handling (for USBTLL module)
On Thu, Feb 05, 2009 at 08:52:17PM -0700, Paul Walmsley wrote: Hello Russell, On Sat, 31 Jan 2009, Russell King - ARM Linux wrote: On Thu, Jan 29, 2009 at 02:15:44AM -0700, Paul Walmsley wrote: Hi Richard, On Thu, 29 Jan 2009, Paul Walmsley wrote: TLLSAR is not functional till ES3.1 (and beyound). Is it possible to flag it this way? Yes, it's easy in this case. Thanks for the note. I will send along an updated patch for this. N.B. - fixxing this required a separate change to the omap_chip flag system, so I'll send the two necessary patches to the linux-omap mailing list for further testing. I'll hold off on this patch then. The patches that obsolete patch B 06 have lasted a week on linux-o...@vger without any comment, so am passing them along in subsequent E-mails. It seems that the patches don't obsolete this patch, but instead require this patch to be applied first. We really really need to get out of this pattern of building fixes on top of bad patches. If a patch is the wrong approach then it is the wrong approach and should be dropped, or it should be merged with the patches which fix stuff up to the new approach. I'm going to combine B06 with patch 2 and hope things come out right. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH E 12/14] OMAP clock: unnecessary clock flag removal fiesta
On Wed, Jan 28, 2009 at 12:28:01PM -0700, Paul Walmsley wrote:
4. The CONFIG_PARTICIPANT flags indicates to the clock rate and parent
changing functions that they should not be used on this clock. Better
just to remove the clock function pointers that operate on those
clocks. The name of the flag is just terrible: its meaning has almost
nothing to do with its name, and the use of the CONFIG_ prefix makes
it appear to be a Kconfig option. Get rid of it.
Hmm. Completely agree over the naming issue, however I think this
opens a hole.
@@ -780,12 +772,6 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long
rate)
pr_debug(clock: set_rate for clock %s to rate %ld\n, clk-name, rate);
- /* CONFIG_PARTICIPANT clocks are changed only in sets via the
-rate table mechanism, driven by mpu_speed */
- if (clk-flags CONFIG_PARTICIPANT)
- return -EINVAL;
-
- /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
if (clk-set_rate)
ret = clk-set_rate(clk, rate);
The removal of this can be mitigated as indicated; not having a set_rate
method does indeed cause this to return -EINVAL.
@@ -830,9 +816,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
{
u32 field_val, v, parent_div;
- if (clk-flags CONFIG_PARTICIPANT)
- return -EINVAL;
-
if (!clk-clksel)
return -EINVAL;
This one, however, is not...
@@ -1020,16 +1018,13 @@ static struct clk mpu_ck = { /* Control cpu */
.parent = core_ck,
.prcm_mod = MPU_MOD,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
- ALWAYS_ENABLED | DELAYED_APP |
- CONFIG_PARTICIPANT | RATE_PROPAGATES,
+ ALWAYS_ENABLED | DELAYED_APP,
.clkdm = { .name = mpu_clkdm },
.init = omap2_init_clksel_parent,
.clksel_reg = CM_CLKSEL,
.clksel_mask= OMAP24XX_CLKSEL_MPU_MASK,
.clksel = mpu_clksel,
.recalc = omap2_clksel_recalc,
- .round_rate = omap2_clksel_round_rate,
- .set_rate = omap2_clksel_set_rate
};
/*
For example, here we have a clock which was previously marked with
CONFIG_PARTICIPANT, and has a non-NULL clksel member. This means
that clk_set_parent() would return -EINVAL before, but would have
an effect after the removal of this flag.
The same is true of dsp_fck, dsp_irate_ick, iva1_ifck, core_l3_ck,
usb_l4_ick and mdm_ick.
So, is this change safe for these clocks?
(Note: all the other flags have already gone in my tree.)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH E 11/14] OMAP clock: track child clocks
On Thu, Feb 19, 2009 at 06:50:52PM -0600, Woodruff, Richard wrote:
The historic usage of this has been against single use leaf clocks (1st
instance of gptimer). When it was used it did:
clk_get()
clk_set_parent()
clk_enable()
This usage was ok for that. Use on a disabled clock is needed.
If there are multiple users on the clock or it is enabled there are problems.
It sounds to me like clk_set_parent() needs this then to prevent enabled
clocks being reparented. By doing so, we no longer need to disable/enable
the clock within the OMAP2/3 set_parent function since we are now
guaranteed that the clock will be disabled.
Ack?
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 40cb65b..f49bce9 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -807,9 +807,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
if (!parent_div)
return -EINVAL;
- if (clk-usecount 0)
- _omap2_clk_disable(clk);
-
/* Set new source value (previous dividers if any in effect) */
v = __raw_readl(clk-clksel_reg);
v = ~clk-clksel_mask;
@@ -819,9 +816,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
_omap2xxx_clk_commit(clk);
- if (clk-usecount 0)
- _omap2_clk_enable(clk);
-
clk_reparent(clk, new_parent);
/* CLKSEL clocks follow their parents' rates, divided by a divisor */
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 08baa18..b2d9e1f 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -144,12 +144,14 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
return ret;
spin_lock_irqsave(clockfw_lock, flags);
- if (arch_clock-clk_set_parent)
- ret = arch_clock-clk_set_parent(clk, parent);
- if (ret == 0) {
- if (clk-recalc)
- clk-rate = clk-recalc(clk);
- propagate_rate(clk);
+ if (clk-usecount == 0) {
+ if (arch_clock-clk_set_parent)
+ ret = arch_clock-clk_set_parent(clk, parent);
+ if (ret == 0) {
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
+ propagate_rate(clk);
+ }
}
spin_unlock_irqrestore(clockfw_lock, flags);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
Eero Nurkkala said the following on 02/23/2009 03:37 PM: On Fri, 2009-02-20 at 21:59 +0100, ext Woodruff, Richard wrote: I received the following comment from a HW Apps person whom has dealt with this at the board level. comment start Attached is the I2C spec that I have. As I understand it, the I2C only specify the minimum tLow and tHigh (which is not balanced). However what is more important is that the appropriate setup and hold time are followed. If the equal time still meets the setup/hold time then there should not be any issue from a compliance standpoint. comment end Regards, Richard W. With out board, the tLow and tHigh values are in line with I2C standard with the patch: http://marc.info/?l=linux-omapm=122770723311340w=2 Would that risk the setup and hold times? (If I remember correctly, the values (setup, hold) were within the I2C standard even with the patch.) I think it's a risk not to meet tLow and tHigh. I'm saying, with open source values with our board, the tLow was not in standard. If using TRM minimum values, things get even worse. Why? because it states, for example, Fast Mode SCLL = 5 and SCLH = 7. This means that the low period is smaller than the high! Shouldn't it be vice versa? (scope verified). just couple of views: (Disclaimer - it might be good if someone could re validate my math :( ).. a) tHigh and tLow could be device dependent. for an I2C bus with multiple devices, we probably need a common denominator. the question is - is there a min and max for the tHigh and tLow? some of the datasheets I have seen seem to have this. b) the drivers/i2c/busses/i2c-omap.c does computation based on dev-speed. the equation is based on: tHigh = ( sclh +6 )*iclk period tLow = ( scll +6 )*iclk period the TRM ([2] table18-12(page 2942)) instead speaks of: tHigh = ( sclh +5 )*iclk period tLow = ( scll +7 )*iclk period current i2c driver attempts to put the same value to scll and sclh reg. The result would be that tHigh != tLow, unless I am missing something. I am not entirely sure about the basis of Eero's equation: scll = (scl+3) * iclk sclh = (scl+9) * iclk Now computing a bit, i2c spec [1] says in table 5 for minimum for FS as tLow as 1.3uS and tHigh as 0.6uS. max is not mentioned :(.. OMAP3430 TRM ([2] table 18-13 (page 2943)) says: psc=9, scl = 5, sch =7 - for fclk = 96Mhz. translating this: iclk =96M/(9+1) = 9.6Mhz = 0.104167uSec. tHigh = ( sclh +5 )*iclk = (7+5)*0.104167 = 1.250004 uSec (spec min is 0.6uSec) tLow = ( scll +7 )*iclk =(5+7)*0.104167 = 1.250004 uSec (spec min is 1.3uSec == I might be missing something here - but does that look like some sort of violation? Now, from a s/w perspective, If we would like to have it so that we can configure tHigh and tLow based on devices, electrical characteristics on a bus, not just speed of the bus, the current implementation would probably need to change(I think). Regards, Nishanth Menon Ref: [1] http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf [2] http://focus.ti.com/pdfs/wtbu/SWPU114I_PrelimFinalEPDF_06_10_2008.pdf -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3530 USB host problems
Felipe Balbi wrote:
On Mon, Feb 23, 2009 at 02:08:12PM +0100, ext Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 08:41:58PM +0100, ext Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:35:29PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 12:05:49PM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:50:44AM -0700, Gary Thomas wrote:
Felipe Balbi wrote:
On Fri, Feb 20, 2009 at 11:15:36AM -0700, Gary Thomas wrote:
I have a 3530 board (similar to the OMAP3EVM) and I'm trying
to get the USB host working. Sadly, this is failing, but I
don't quite see why. From drivers/usb/host/echi-omap.c:
/* Wait for TLL to be Active */
timeout = 1000;
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
{
if (--timeout = 0) {
printk(KERN_ERR USB TLL is unavailable\n);
return -ENODEV;
}
cpu_relax();
}
Any clues on why this might be? How do I solve it?
could you enable CONFIG_DEBUG_LL and post the seria console output ?
do you really use TLL ?? I don't really know omap3evm, but I guess it
uses PHY mode (correct me if I'm wrong).
It's not that I _need_ TLL, the driver function omap_start_ehci()
tries to reset the part of the USB controller and fails. I'm just
trying to understand why this part of the code falls over.
you have OMAP_EHCI_TLL_MODE set, you should probably use
OMAP_EHCI_PHY_MODE instead.
You can fix it via make menuconfig
I already have that; this code is still being used.
# CONFIG_OMAP_EHCI_TLL_MODE is not set
CONFIG_OMAP_EHCI_PHY_MODE=y
This is not used in the function above at all.
hmm.. true, just checked the function.
Weird, TRM says when that bit is 1, we cannot access ST_USBTLL, we
should access it when it's 0, try the following:
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..122e95b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -250,7 +250,7 @@ static int omap_start_ehc(struct platform_device
*dev, struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(0 OMAP3430ES2_ST_USBTLL_SHIFT)))
cpu_relax();
/* perform TLL soft reset, and wait until reset is complete */
and tell us if it worked
Sadly, I've already tried this and things just continue to fall apart.
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd8062010
Internal error: : 1008 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-omap1-svn4799-dirty14 #60)
PC is at ehci_hcd_omap_drv_probe+0x370/0x5e4
LR is at release_console_sem+0x1a8/0x1d8
Hence, my desired to figure out the TLL timeout...
keep TLL as is, the problem now seems to be a clock that should be on
and is off. Try to figure (with printk() for example) at which line the
code stops, put printk() before and after register read/write operations
during probe and omap_start_ehc(), let's see where does it dies.
any news ??
Not really; I'd like to figure out *why* this part of the USB
device isn't working, not just find a way around it...
It's not a way around it. That bit is wrong, one problem is fixed now
but we came to another issue which is a non-linefetch, which makes me
wonder that's a clock issue.
You should just try to fetch me for information and I might be able to
help you more.
It turns out that the various USB clocks were not enabled (this is prototype
hardware, only roughly equivalent to the OMAP3EVM and I started with a
kernel snapshot more than a month ago, so much may have changed in the
meantime). I can now get through this part of the USB host initialization
code (still doesn't work, but I think I can figure it out).
Thanks for the pointers
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH] DSPBRIDGE: Remove SEEK_* redefinitions
From: Fernando Guzman Lugo x0095...@ti.com Date: Mon, 23 Feb 2009 10:04:27 -0600 Subject: [PATCH] DSPBRIDGE: Remove SEEK_* redefinitions This patch removes the SEEK_* redefinitions in host_os.h Signed-off-by: Guzman Lugo Fernando x0095...@ti.com --- arch/arm/plat-omap/include/dspbridge/host_os.h | 6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/include/dspbridge/host_os.h b/arch/arm/plat-omap/include/dspbridge/host_os.h index ff49e0d..9245eea --- a/arch/arm/plat-omap/include/dspbridge/host_os.h +++ b/arch/arm/plat-omap/include/dspbridge/host_os.h @@ -60,12 +60,6 @@ #include asm/cacheflush.h #include linux/dma-mapping.h -/* --- Macros */ - -#define SEEK_SET 0 /* Seek from beginning of file. */ -#define SEEK_CUR 1 /* Seek from current position. */ -#define SEEK_END 2 /* Seek from end of file. */ - /* TODO -- Remove, once BP defines them */ #define INT_MAIL_MPU_IRQ 26 #define INT_DSP_MMU_IRQ 28 -- 1.5.6.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3530 USB host problems
On Mon, Feb 23, 2009 at 10:21:25AM -0700, Gary Thomas wrote: It turns out that the various USB clocks were not enabled (this is prototype hardware, only roughly equivalent to the OMAP3EVM and I started with a kernel snapshot more than a month ago, so much may have changed in the meantime). I can now get through this part of the USB host initialization code (still doesn't work, but I think I can figure it out). Yeah, as I suspected. Even in current linux-omap, I got report that vbus goes on, but enumeration doesn't happen, so you're at the same stage. Thanks for the pointers no problems -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
I am not entirely sure about the basis of Eero's equation: scll = (scl+3) * iclk sclh = (scl+9) * iclk No, no: Exactly the opposite, + fsscll = internal_clk / (dev-speed * 2) - 3; + fssclh = internal_clk / (dev-speed * 2) - 9; means a longer period for scll. (and shorter for sclh) - Eero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.29-rc5-omap-git] mach-omap2/mmc-twl4030: fix for vmmc = 0
From: David Brownell dbrown...@users.sourceforge.net
Resolve longstanding issue noted by Adrian Hunter: confusion
between settting VSEL=0 (which is 1.8V on MMC1) and poweroff.
Also, leave VSEL alone if we're just powering the regulator off.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
NOTE: won't apply to current mainline GIT.
arch/arm/mach-omap2/mmc-twl4030.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -178,7 +178,10 @@ static int twl_mmc_resume(struct device
static int twl_mmc_set_voltage(struct twl_mmc_controller *c, int vdd)
{
int ret;
- u8 vmmc, dev_grp_val;
+ u8 vmmc = 0, dev_grp_val;
+
+ if (!vdd)
+ goto doit;
if (c-twl_vmmc_dev_grp == VMMC1_DEV_GRP) {
/* VMMC1: max 220 mA. And for 8-bit mode,
@@ -203,8 +206,7 @@ static int twl_mmc_set_voltage(struct tw
/* error if VSIM needed */
break;
default:
- vmmc = 0;
- break;
+ return -EINVAL;
}
} else if (c-twl_vmmc_dev_grp == VMMC2_DEV_GRP) {
/* VMMC2: max 100 mA */
@@ -230,21 +232,21 @@ static int twl_mmc_set_voltage(struct tw
vmmc = VMMC2_315V;
break;
default:
- vmmc = 0;
- break;
+ return -EINVAL;
}
} else {
- return 0;
+ return -EINVAL;
}
- if (vmmc)
+doit:
+ if (vdd)
dev_grp_val = VMMC_DEV_GRP_P1; /* Power up */
else
dev_grp_val = LDO_CLR; /* Power down */
ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
dev_grp_val, c-twl_vmmc_dev_grp);
- if (ret)
+ if (ret || !vdd)
return ret;
ret = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
On Mon, Feb 23, 2009 at 8:10 PM, ext-eero.nurkk...@nokia.com wrote: I am not entirely sure about the basis of Eero's equation: scll = (scl+3) * iclk sclh = (scl+9) * iclk No, no: Exactly the opposite, + fsscll = internal_clk / (dev-speed * 2) - 3; + fssclh = internal_clk / (dev-speed * 2) - 9; means a longer period for scll. (and shorter for sclh) Oops.. copy-paste typo.. :( tLow = (scll+3) * iclk tHigh = (sclh+9) * iclk Vs: TRM: tHigh = ( sclh +5 )*iclk period tLow = ( scll +7 )*iclk period But my question is this: why are we trying to a different equation here compared to the equation in the TRM? if the reason is that the tLow and tHigh should be a variant based on board, probably precomputed values or run time computed values wont work for all platforms. the board file probably should give it as a platform specific data. if this is not provided, use the run time computation.. just a thought.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
On Monday 23 February 2009, Adrian Hunter wrote:
Also, you will need the following patch if you actually want the power
to go off.
Current GIT already has a patch supporting power-off for
MMC2; tested on SDP and some custom hardware. So this
patch won't apply.
Are you sure that's needed for MMC1? The led showing MMC1
power did go off correctly (when using MMC2 for root), and
the MMC1 regulator entry in sysfs agreed MMC1 was off. So
I thought this was only an issue for MMC2 (and presumably
MMC3, though I don't have a board using it.)
I agree that code removed by this patch is ugly and worth
removing if it's not actually needed for MMC1.
- Dave
From: Adrian Hunter ext-adrian.hun...@nokia.com
Date: Fri, 30 Jan 2009 11:58:13 +0200
Subject: [PATCH] OMAP: HSMMC: do not power up after powering off
The power is configured when probing and when resuming
so the bus voltage does not need changing after power
off.
Signed-off-by: Adrian Hunter ext-adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1e4a2e0..04e5a0c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -859,16 +859,6 @@ static void omap_mmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_OFF:
mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
- /*
- * Reset bus voltage to 3V if it got set to 1.8V earlier.
- * REVISIT: If we are able to detect cards after unplugging
- * a 1.8V card, this code should not be needed.
- */
- if (!(OMAP_HSMMC_READ(host-base, HCTL) SDVSDET)) {
- int vdd = fls(host-mmc-ocr_avail) - 1;
- if (omap_mmc_switch_opcond(host, vdd) != 0)
- host-mmc-ios.vdd = vdd;
- }
break;
case MMC_POWER_UP:
mmc_slot(host).set_power(host-dev, host-slot_id, 1,
ios-vdd);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] OMAP3 PM Add C0 state
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: This patch introduces a new C state C0 which keeps both core and mpu powerdomains in ON state. This gives us low latency at a cost of higher power consumption. I don't like the name 'C0' for an idle-state. In ACPI terms, C0 is an active state, not an idle state. I know this is not an ACPI system, but since we're using ACPI names, we should be consistent. Is there a real benefit to having an additional state here? Shouldn't we just make these changes or C1? Also, for a single patch, can you include the description in the patch itself instead of the 'PATCH 0/1'. Thanks. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
On Mon, Feb 23, 2009 at 8:20 PM, ext-eero.nurkk...@nokia.com wrote: Don't just blindly trust the TRM, all that matters is the real signal caught in the scope. That is what you want to verify. ;) Aye Aye I wonder if the equation you provided is based on emperical measurement? if so would it vary based on electrical characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP atleast have variances of i2c trace lengths and number of devices per i2c bus.. wont the equation change based on board configuration? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: HSMMC: Initialize hsmmc controller registers when resuming
On Monday 23 February 2009, Kyungmin Park wrote: Although I have not tested it, I very much doubt dual-voltage cards work. That is because VMMC1_185V is zero, which has the side-effect of turning the regulator off (see arch/arm/mach-omap2/mmc-twl4030.c) Right, looks like a longstanding bug in that glue. So IMO, no rush to fix for 2.6.29-rc ... It's also to difficult to test in our H/W since it's configured only support 3.0V. Easily tested with a Beagle or SDP though, if you have a 1.8V or dual-voltage card (maybe RS-MMC, as for an N770 tablet). How about to separate it two phases, first fix the mmc suspend/resume works again, and then verify dual voltage if there are these hardware Well, two patches for sure; I don't know that the order will matter. I just sent a patch fixing that code in the current OMAP git tree, which has some fixes that are scheduled to merge for 2.6.30-rc. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
;) Aye Aye I wonder if the equation you provided is based on emperical measurement? if so would it vary based on electrical characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP atleast have variances of i2c trace lengths and number of devices per i2c bus.. wont the equation change based on board configuration? Nothing empirical. It's just for one board. They say it differs from board to board. I haven't had time to spend with different boards. They call it the load on scl line, that makes the numbers different on other boards. (I'm not so sure about that, but agreed it may vary little) That patch is reverted these days, as it is not really empirical, and doesn't work on omap2430. - Eero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
On Mon, Feb 23, 2009 at 8:27 PM, ext-eero.nurkk...@nokia.com wrote: ;) Aye Aye I wonder if the equation you provided is based on emperical measurement? if so would it vary based on electrical characteristics of a platform? I mean beagleboard Vs Zoom Vs SDP atleast have variances of i2c trace lengths and number of devices per i2c bus.. wont the equation change based on board configuration? Nothing empirical. It's just for one board. They say it differs from board to board. I haven't had time to spend with different boards. They call it the load on scl line, that makes the numbers different on other boards. (I'm not so sure about that, but agreed it may vary little) So, it might be worth considering my following proposition? Now, from a s/w perspective, If we would like to have it so that we can configure tHigh and tLow based on devices, electrical characteristics on a bus, not just speed of the bus, the current implementation would probably need to change(I think). maybe take tHigh, tLow as a platform data input to the driver? that could allow scaling for all boards I wonder? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: tHigh tLow discussion (was [pacth] I2C bug fixes for L-O and L-Z)
So, it might be worth considering my following proposition? Now, from a s/w perspective, If we would like to have it so that we can configure tHigh and tLow based on devices, electrical characteristics on a bus, not just speed of the bus, the current implementation would probably need to change(I think). maybe take tHigh, tLow as a platform data input to the driver? that could allow scaling for all boards I wonder? Something like that I'd say. Something not happening soon, because not everybody has a scope and the time =) - Eero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 01/23] usb: host: ehci: make checkpatch.pl happy with ehci-omap
Trivial cleanup patch, no functional changes. Just
adding a few spaces here and there.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 50 +++--
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b3266c..88ed500 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -31,7 +31,6 @@
#include ehci-omap.h
-
#ifdef CONFIG_OMAP_EHCI_PHY_MODE
/* EHCI connected to External PHY */
@@ -80,7 +79,6 @@ struct ehci_omap_clock_defs {
#define USBHOST_TLL_FCLK usbtll_fck
/*-*/
-
#ifndef CONFIG_OMAP_EHCI_PHY_MODE
static void omap_usb_utmi_init(struct usb_hcd *hcd, u8 tll_channel_mask)
@@ -89,17 +87,17 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
/* Use UTMI Ports of TLL */
omap_writel((1 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT)|
- (1OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN_SHIFT)|
- (1OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN_SHIFT)|
- (1OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT)|
- (0OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN_SHIFT),
+ (1 OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN_SHIFT)|
+ (1 OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN_SHIFT)|
+ (1 OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT)|
+ (0 OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN_SHIFT),
OMAP_UHH_HOSTCONFIG);
/* Enusre bit is set */
while (!(omap_readl(OMAP_UHH_HOSTCONFIG)
(1 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT)))
cpu_relax();
- dev_dbg(hcd-self.controller, \nEntered UTMI MODE: success\n);
+ dev_dbg(hcd-self.controller, Entered UTMI MODE: success\n);
/* Program the 3 TLL channels upfront */
@@ -107,15 +105,15 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
/* Disable AutoIdle */
omap_writel(omap_readl(OMAP_TLL_CHANNEL_CONF(i))
- ~(1OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE_SHIFT),
+ ~(1 OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE_SHIFT),
OMAP_TLL_CHANNEL_CONF(i));
/* Disable BitStuffing */
omap_writel(omap_readl(OMAP_TLL_CHANNEL_CONF(i))
- ~(1OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF_SHIFT),
+ ~(1 OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF_SHIFT),
OMAP_TLL_CHANNEL_CONF(i));
/* SDR Mode */
omap_writel(omap_readl(OMAP_TLL_CHANNEL_CONF(i))
- ~(1OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE_SHIFT),
+ ~(1 OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE_SHIFT),
OMAP_TLL_CHANNEL_CONF(i));
}
@@ -135,11 +133,11 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
continue;
omap_writel(omap_readl(OMAP_TLL_CHANNEL_CONF(i)) |
- (1OMAP_TLL_CHANNEL_CONF_CHANEN_SHIFT),
+ (1 OMAP_TLL_CHANNEL_CONF_CHANEN_SHIFT),
OMAP_TLL_CHANNEL_CONF(i));
omap_writeb(0xBE, OMAP_TLL_ULPI_SCRATCH_REGISTER(i));
- dev_dbg(hcd-self.controller, \nULPI_SCRATCH_REG[ch=%d]
+ dev_dbg(hcd-self.controller, ULPI_SCRATCH_REG[ch=%d]
= 0x%02x\n,
i+1, omap_readb(OMAP_TLL_ULPI_SCRATCH_REGISTER(i)));
}
@@ -209,7 +207,6 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
return PTR_ERR(ehci_clocks-usbhost_ick_clk);
clk_enable(ehci_clocks-usbhost_ick_clk);
-
ehci_clocks-usbhost2_120m_fck_clk = clk_get(dev-dev,
USBHOST_120M_FCLK);
if (IS_ERR(ehci_clocks-usbhost2_120m_fck_clk))
@@ -281,10 +278,10 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
#ifdef CONFIG_OMAP_EHCI_PHY_MODE
/* Bypass the TLL module for PHY mode operation */
omap_writel((0 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT)|
- (1OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN_SHIFT)|
- (1OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN_SHIFT)|
- (1OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT)|
- (0OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN_SHIFT),
+ (1 OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN_SHIFT)|
+ (1 OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN_SHIFT)|
+ (1 OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT)|
+ (0
[rft/rfc/patch-v2.6.29-rc5+ 02/23] usb: host: ehci: use dev_name
We should stop using bus_id to pass the device name, dev_name() should be used instead. Cleanup only. Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 88ed500..3dd4a68 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -428,7 +428,8 @@ static int ehci_hcd_omap_drv_probe(struct platform_device *dev) retval = -ENOMEM; } - hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev, dev-dev.bus_id); + hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev, + dev_name(dev-dev)); if (!hcd) return -ENOMEM; -- 1.6.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 03/23] usb: host: ehci: standardize variables
Style only, normally we use pdev as the platform_device's
pointer name.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 3dd4a68..a4f5f16 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -412,39 +412,39 @@ static const struct hc_driver ehci_omap_hc_driver;
* through the hotplug entry's driver_data.
*
*/
-static int ehci_hcd_omap_drv_probe(struct platform_device *dev)
+static int ehci_hcd_omap_drv_probe(struct platform_device *pdev)
{
int retval = 0;
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
- dev_dbg(dev-dev, ehci_hcd_omap_drv_probe()\n);
+ dev_dbg(pdev-dev, ehci_hcd_omap_drv_probe()\n);
if (usb_disabled())
return -ENODEV;
- if (dev-resource[1].flags != IORESOURCE_IRQ) {
- dev_dbg(dev-dev, resource[1] is not IORESOURCE_IRQ\n);
+ if (pdev-resource[1].flags != IORESOURCE_IRQ) {
+ dev_dbg(pdev-dev, resource[1] is not IORESOURCE_IRQ\n);
retval = -ENOMEM;
}
- hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev,
- dev_name(dev-dev));
+ hcd = usb_create_hcd(ehci_omap_hc_driver, pdev-dev,
+ dev_name(pdev-dev));
if (!hcd)
return -ENOMEM;
- retval = omap_start_ehc(dev, hcd);
+ retval = omap_start_ehc(pdev, hcd);
if (retval)
return retval;
hcd-rsrc_start = 0;
hcd-rsrc_len = 0;
- hcd-rsrc_start = dev-resource[0].start;
- hcd-rsrc_len = dev-resource[0].end - dev-resource[0].start + 1;
+ hcd-rsrc_start = pdev-resource[0].start;
+ hcd-rsrc_len = pdev-resource[0].end - pdev-resource[0].start + 1;
hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
if (!hcd-regs) {
- dev_err(dev-dev, ioremap failed\n);
+ dev_err(pdev-dev, ioremap failed\n);
return -ENOMEM;
}
@@ -460,13 +460,13 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*dev)
/* SET 1 micro-frame Interrupt interval */
writel(readl(ehci-regs-command) | (1 16), ehci-regs-command);
- retval = usb_add_hcd(hcd, dev-resource[1].start,
+ retval = usb_add_hcd(hcd, pdev-resource[1].start,
IRQF_DISABLED | IRQF_SHARED);
if (retval == 0)
return retval;
- dev_dbg(hcd-self.controller, ERR: add_hcd\n);
- omap_stop_ehc(dev, hcd);
+ dev_dbg(pdev-dev, ERR: add_hcd\n);
+ omap_stop_ehc(pdev, hcd);
iounmap(hcd-regs);
usb_put_hcd(hcd);
@@ -480,7 +480,7 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*dev)
/**
* ehci_hcd_omap_drv_remove - shutdown processing for EHCI HCDs
- * @dev: USB Host Controller being removed
+ * @pdev: USB Host Controller being removed
* Context: !in_interrupt()
*
* Reverses the effect of usb_ehci_hcd_omap_probe(), first invoking
@@ -488,16 +488,16 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*dev)
* context, normally rmmod, apmd, or something similar.
*
*/
-static int ehci_hcd_omap_drv_remove(struct platform_device *dev)
+static int ehci_hcd_omap_drv_remove(struct platform_device *pdev)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
- dev_dbg(dev-dev, ehci_hcd_omap_drv_remove()\n);
+ dev_dbg(pdev-dev, ehci_hcd_omap_drv_remove()\n);
iounmap(hcd-regs);
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
- omap_stop_ehc(dev, hcd);
+ omap_stop_ehc(pdev, hcd);
return 0;
}
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 04/23] usb: host: ehci: tabify structures
Style only, no functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 46 +-
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index a4f5f16..e050795 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -518,57 +518,57 @@ static int omap_ehci_bus_resume(struct usb_hcd *hcd)
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
- .product_desc = OMAP-EHCI Host Controller,
- .hcd_priv_size = sizeof(struct ehci_hcd)
+ .product_desc = OMAP-EHCI Host Controller,
+ .hcd_priv_size = sizeof(struct ehci_hcd)
+ sizeof(struct ehci_omap_clock_defs),
/*
* generic hardware linkage
*/
- .irq = ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
+ .irq= ehci_irq,
+ .flags = HCD_MEMORY | HCD_USB2,
/*
* basic lifecycle operations
*/
- .reset = ehci_init,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
+ .reset = ehci_init,
+ .start = ehci_run,
+ .stop = ehci_stop,
+ .shutdown = ehci_shutdown,
/*
* managing i/o requests and associated device resources
*/
- .urb_enqueue = ehci_urb_enqueue,
- .urb_dequeue = ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
+ .urb_enqueue= ehci_urb_enqueue,
+ .urb_dequeue= ehci_urb_dequeue,
+ .endpoint_disable = ehci_endpoint_disable,
/*
* scheduling support
*/
- .get_frame_number = ehci_get_frame,
+ .get_frame_number = ehci_get_frame,
/*
* root hub support
*/
- .hub_status_data = ehci_hub_status_data,
- .hub_control = ehci_hub_control,
+ .hub_status_data= ehci_hub_status_data,
+ .hub_control= ehci_hub_control,
#ifdef CONFIG_PM
- .bus_suspend = omap_ehci_bus_suspend,
- .bus_resume = omap_ehci_bus_resume,
+ .bus_suspend= omap_ehci_bus_suspend,
+ .bus_resume = omap_ehci_bus_resume,
#endif
};
MODULE_ALIAS(platform:omap-ehci);
static struct platform_driver ehci_hcd_omap_driver = {
- .probe = ehci_hcd_omap_drv_probe,
- .remove = ehci_hcd_omap_drv_remove,
- .shutdown = usb_hcd_platform_shutdown,
- /*.suspend = ehci_hcd_omap_drv_suspend, */
- /*.resume = ehci_hcd_omap_drv_resume, */
+ .probe = ehci_hcd_omap_drv_probe,
+ .remove = ehci_hcd_omap_drv_remove,
+ .shutdown = usb_hcd_platform_shutdown,
+ /*.suspend = ehci_hcd_omap_drv_suspend, */
+ /*.resume = ehci_hcd_omap_drv_resume, */
.driver = {
- .name = ehci-omap,
- .bus = platform_bus_type
+ .name = ehci-omap,
+ .bus= platform_bus_type
}
};
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 07/23] usb: host: ehci: get rid of pm functions
That was just a useless function call, completely
unneeded. Remove it.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index db4576d..1b387cc 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -511,20 +511,6 @@ static int ehci_hcd_omap_drv_remove(struct platform_device
*pdev)
return 0;
}
-/*-*/
-#ifdef CONFIG_PM
-static int omap_ehci_bus_suspend(struct usb_hcd *hcd)
-{
- return ehci_bus_suspend(hcd);
-}
-
-static int omap_ehci_bus_resume(struct usb_hcd *hcd)
-{
- return ehci_bus_resume(hcd);
-}
-#endif
-/*-*/
-
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
.product_desc = OMAP-EHCI Host Controller,
@@ -562,10 +548,8 @@ static const struct hc_driver ehci_omap_hc_driver = {
*/
.hub_status_data= ehci_hub_status_data,
.hub_control= ehci_hub_control,
-#ifdef CONFIG_PM
- .bus_suspend= omap_ehci_bus_suspend,
- .bus_resume = omap_ehci_bus_resume,
-#endif
+ .bus_suspend= ehci_bus_suspend,
+ .bus_resume = ehci_bus_resume,
};
MODULE_ALIAS(platform:omap-ehci);
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 06/23] usb: host: ehci: sanitize error path
This patch:
- sanitizes error path in ehci_hcd_omap_drv_probe();
- removes two unnecessary debugging messages, we only need
debugging in the failing case generally;
- fix a memory leak when omap_start_ehc() fails: the recently
created hcd was never put in that case;
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 53 +
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index d994392..db4576d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -418,21 +418,24 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
struct usb_hcd *hcd;
int irq = platform_get_irq(pdev, 0);
- int retval = 0;
-
- dev_dbg(pdev-dev, ehci_hcd_omap_drv_probe()\n);
+ int ret = -ENODEV;
if (usb_disabled())
- return -ENODEV;
+ goto err_disabled;
hcd = usb_create_hcd(ehci_omap_hc_driver, pdev-dev,
dev_name(pdev-dev));
- if (!hcd)
- return -ENOMEM;
+ if (!hcd) {
+ dev_dbg(pdev-dev, failed to create hcd with err %d\n, ret);
+ ret = -ENOMEM;
+ goto err_create_hcd;
+ }
- retval = omap_start_ehc(pdev, hcd);
- if (retval)
- return retval;
+ ret = omap_start_ehc(pdev, hcd);
+ if (ret) {
+ dev_dbg(pdev-dev, failed to start ehci\n);
+ goto err_start;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -444,12 +447,12 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
if (!hcd-regs) {
dev_err(pdev-dev, ioremap failed\n);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_ioremap;
}
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
-
ehci-sbrn = 0x20;
ehci-regs = hcd-regs + HC_LENGTH(readl(ehci-caps-hc_capbase));
@@ -459,16 +462,26 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
/* SET 1 micro-frame Interrupt interval */
writel(readl(ehci-regs-command) | (1 16), ehci-regs-command);
- retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
- if (retval == 0)
- return retval;
+ ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ if (ret) {
+ dev_dbg(pdev-dev, failed to add hcd with err %d\n, ret);
+ goto err_add_hcd;
+ }
- dev_dbg(pdev-dev, ERR: add_hcd\n);
- omap_stop_ehc(pdev, hcd);
+ return 0;
+
+err_add_hcd:
iounmap(hcd-regs);
+
+err_ioremap:
+ omap_stop_ehc(pdev, hcd);
+
+err_start:
usb_put_hcd(hcd);
- return retval;
+err_create_hcd:
+err_disabled:
+ return ret;
}
/*-*/
@@ -490,12 +503,10 @@ static int ehci_hcd_omap_drv_remove(struct
platform_device *pdev)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
- dev_dbg(pdev-dev, ehci_hcd_omap_drv_remove()\n);
-
- iounmap(hcd-regs);
usb_remove_hcd(hcd);
- usb_put_hcd(hcd);
+ iounmap(hcd-regs);
omap_stop_ehc(pdev, hcd);
+ usb_put_hcd(hcd);
return 0;
}
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 09/23] usb: host: ehci: better function names
The drv in the function names was there just to make
it bigger, remove it so we have 4 characters smaller
lines. Also remove the platform_bus_type from platform_driver
since platform_driver_register() already does that.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e66f5f9..f5ffc5b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -404,14 +404,13 @@ static const struct hc_driver ehci_omap_hc_driver;
/* always called with process context; sleeping is OK */
/**
- * ehci_hcd_omap_drv_probe - initialize TI-based HCDs
- * Context: !in_interrupt()
+ * ehci_hcd_omap_probe - initialize TI-based HCDs
*
* Allocates basic resources for this USB host controller, and
* then invokes the start() method for the HCD associated with it
* through the hotplug entry's driver_data.
*/
-static int ehci_hcd_omap_drv_probe(struct platform_device *pdev)
+static int ehci_hcd_omap_probe(struct platform_device *pdev)
{
struct ehci_hcd *ehci;
struct resource *res;
@@ -484,22 +483,18 @@ err_disabled:
return ret;
}
-/*-*/
-
/* may be called without controller electrically present */
/* may be called with controller, bus, and devices active */
/**
- * ehci_hcd_omap_drv_remove - shutdown processing for EHCI HCDs
+ * ehci_hcd_omap_remove - shutdown processing for EHCI HCDs
* @pdev: USB Host Controller being removed
- * Context: !in_interrupt()
*
* Reverses the effect of usb_ehci_hcd_omap_probe(), first invoking
* the HCD's stop() method. It is always called from a thread
* context, normally rmmod, apmd, or something similar.
- *
*/
-static int ehci_hcd_omap_drv_remove(struct platform_device *pdev)
+static int ehci_hcd_omap_remove(struct platform_device *pdev)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
@@ -512,17 +507,18 @@ static int ehci_hcd_omap_drv_remove(struct
platform_device *pdev)
}
static struct platform_driver ehci_hcd_omap_driver = {
- .probe = ehci_hcd_omap_drv_probe,
- .remove = ehci_hcd_omap_drv_remove,
+ .probe = ehci_hcd_omap_probe,
+ .remove = ehci_hcd_omap_remove,
.shutdown = usb_hcd_platform_shutdown,
- /*.suspend = ehci_hcd_omap_drv_suspend, */
- /*.resume = ehci_hcd_omap_drv_resume, */
+ /*.suspend = ehci_hcd_omap_suspend, */
+ /*.resume = ehci_hcd_omap_resume, */
.driver = {
.name = ehci-omap,
- .bus= platform_bus_type
}
};
+/*-*/
+
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
.product_desc = OMAP-EHCI Host Controller,
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 00/23] ehci cleanup series
Hi all, Please give the following patches a good test. I don't have hw to test them so any comments will be really welcome. We still have lots to do before getting this driver upstream, let's try to keep track of our TODO list and get this driver in mainline for 2.6.31 merge window (2.6.30 is too close already). Let's not try to push this driver until ES2.x and ES3.x are fully supported, that will probably have to be done by an omap_rev check in ehci-omap driver, also, this driver doesn't really enumerate any attached devices, but that's old problem as Tony told me off list. Anyways, I guess this driver is finally walking. Me and Anand (and anyone interested) will be discussing how to get EHCI and OHCI working fine, I'm guessing we won't have really big issues with OHCI but you never know. Again, please give it a good test, see if you don't have any clock issues, NULL pointers, check if the error path is really fine, see if VBUS turns on or not, as I said, *I HAVE NO HW TO TEST THESE* thanks in advance for those who will read/test/comment these patches Felipe Balbi (22): usb: host: ehci: make checkpatch.pl happy with ehci-omap usb: host: ehci: use dev_name usb: host: ehci: standardize variables usb: host: ehci: tabify structures usb: host: ehci: use resource helpers usb: host: ehci: sanitize error path usb: host: ehci: get rid of pm functions usb: host: ehci: reorganize structures usb: host: ehci: better function names usb: host: ehci: move some comments usb: host: ehci: add MODULE_AUTHOR usb: host: ehci: include linux/gpio.h instead usb: host: ehci: remove ehci-omap.h usb: host: ehci: get rid of infinite loops usb: host: ehci: disable clocks on error usb: host: ehci: add platform_data usb: host: ehci: fix register definitions arm: omap: make usb base defines follow trm usb: host: ehci: ioremap all usb bases usb: host: ehci: align defines usb: host: ehci: don't ensure register write usb: host: ehci: add few comments and todo Tony Lindgren (1): ehci-omap: Remove defines for clock names arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/usb-ehci.c | 34 +- arch/arm/plat-omap/include/mach/omap34xx.h |4 +- arch/arm/plat-omap/include/mach/usb.h | 24 +- drivers/usb/host/Kconfig | 19 - drivers/usb/host/ehci-omap.c | 890 +--- drivers/usb/host/ehci-omap.h | 125 11 files changed, 591 insertions(+), 515 deletions(-) delete mode 100644 drivers/usb/host/ehci-omap.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 02/23] usb: host: ehci: use dev_name
We should stop using bus_id to pass the device name, dev_name() should be used instead. Cleanup only. Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 88ed500..3dd4a68 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -428,7 +428,8 @@ static int ehci_hcd_omap_drv_probe(struct platform_device *dev) retval = -ENOMEM; } - hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev, dev-dev.bus_id); + hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev, + dev_name(dev-dev)); if (!hcd) return -ENOMEM; -- 1.6.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 03/23] usb: host: ehci: standardize variables
Style only, normally we use pdev as the platform_device's
pointer name.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 3dd4a68..a4f5f16 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -412,39 +412,39 @@ static const struct hc_driver ehci_omap_hc_driver;
* through the hotplug entry's driver_data.
*
*/
-static int ehci_hcd_omap_drv_probe(struct platform_device *dev)
+static int ehci_hcd_omap_drv_probe(struct platform_device *pdev)
{
int retval = 0;
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
- dev_dbg(dev-dev, ehci_hcd_omap_drv_probe()\n);
+ dev_dbg(pdev-dev, ehci_hcd_omap_drv_probe()\n);
if (usb_disabled())
return -ENODEV;
- if (dev-resource[1].flags != IORESOURCE_IRQ) {
- dev_dbg(dev-dev, resource[1] is not IORESOURCE_IRQ\n);
+ if (pdev-resource[1].flags != IORESOURCE_IRQ) {
+ dev_dbg(pdev-dev, resource[1] is not IORESOURCE_IRQ\n);
retval = -ENOMEM;
}
- hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev,
- dev_name(dev-dev));
+ hcd = usb_create_hcd(ehci_omap_hc_driver, pdev-dev,
+ dev_name(pdev-dev));
if (!hcd)
return -ENOMEM;
- retval = omap_start_ehc(dev, hcd);
+ retval = omap_start_ehc(pdev, hcd);
if (retval)
return retval;
hcd-rsrc_start = 0;
hcd-rsrc_len = 0;
- hcd-rsrc_start = dev-resource[0].start;
- hcd-rsrc_len = dev-resource[0].end - dev-resource[0].start + 1;
+ hcd-rsrc_start = pdev-resource[0].start;
+ hcd-rsrc_len = pdev-resource[0].end - pdev-resource[0].start + 1;
hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
if (!hcd-regs) {
- dev_err(dev-dev, ioremap failed\n);
+ dev_err(pdev-dev, ioremap failed\n);
return -ENOMEM;
}
@@ -460,13 +460,13 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*dev)
/* SET 1 micro-frame Interrupt interval */
writel(readl(ehci-regs-command) | (1 16), ehci-regs-command);
- retval = usb_add_hcd(hcd, dev-resource[1].start,
+ retval = usb_add_hcd(hcd, pdev-resource[1].start,
IRQF_DISABLED | IRQF_SHARED);
if (retval == 0)
return retval;
- dev_dbg(hcd-self.controller, ERR: add_hcd\n);
- omap_stop_ehc(dev, hcd);
+ dev_dbg(pdev-dev, ERR: add_hcd\n);
+ omap_stop_ehc(pdev, hcd);
iounmap(hcd-regs);
usb_put_hcd(hcd);
@@ -480,7 +480,7 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*dev)
/**
* ehci_hcd_omap_drv_remove - shutdown processing for EHCI HCDs
- * @dev: USB Host Controller being removed
+ * @pdev: USB Host Controller being removed
* Context: !in_interrupt()
*
* Reverses the effect of usb_ehci_hcd_omap_probe(), first invoking
@@ -488,16 +488,16 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*dev)
* context, normally rmmod, apmd, or something similar.
*
*/
-static int ehci_hcd_omap_drv_remove(struct platform_device *dev)
+static int ehci_hcd_omap_drv_remove(struct platform_device *pdev)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
- dev_dbg(dev-dev, ehci_hcd_omap_drv_remove()\n);
+ dev_dbg(pdev-dev, ehci_hcd_omap_drv_remove()\n);
iounmap(hcd-regs);
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
- omap_stop_ehc(dev, hcd);
+ omap_stop_ehc(pdev, hcd);
return 0;
}
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 05/23] usb: host: ehci: use resource helpers
Don't access pdev-resource[n].start directly, we
can use the resource helpers for that, makes the
code more readable.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e050795..d994392 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -410,24 +410,21 @@ static const struct hc_driver ehci_omap_hc_driver;
* Allocates basic resources for this USB host controller, and
* then invokes the start() method for the HCD associated with it
* through the hotplug entry's driver_data.
- *
*/
static int ehci_hcd_omap_drv_probe(struct platform_device *pdev)
{
- int retval = 0;
- struct usb_hcd *hcd;
struct ehci_hcd *ehci;
+ struct resource *res;
+ struct usb_hcd *hcd;
+
+ int irq = platform_get_irq(pdev, 0);
+ int retval = 0;
dev_dbg(pdev-dev, ehci_hcd_omap_drv_probe()\n);
if (usb_disabled())
return -ENODEV;
- if (pdev-resource[1].flags != IORESOURCE_IRQ) {
- dev_dbg(pdev-dev, resource[1] is not IORESOURCE_IRQ\n);
- retval = -ENOMEM;
- }
-
hcd = usb_create_hcd(ehci_omap_hc_driver, pdev-dev,
dev_name(pdev-dev));
if (!hcd)
@@ -437,10 +434,12 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
if (retval)
return retval;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
hcd-rsrc_start = 0;
hcd-rsrc_len = 0;
- hcd-rsrc_start = pdev-resource[0].start;
- hcd-rsrc_len = pdev-resource[0].end - pdev-resource[0].start + 1;
+ hcd-rsrc_start = res-start;
+ hcd-rsrc_len = resource_size(res);
hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
if (!hcd-regs) {
@@ -460,8 +459,7 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
/* SET 1 micro-frame Interrupt interval */
writel(readl(ehci-regs-command) | (1 16), ehci-regs-command);
- retval = usb_add_hcd(hcd, pdev-resource[1].start,
- IRQF_DISABLED | IRQF_SHARED);
+ retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
if (retval == 0)
return retval;
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 06/23] usb: host: ehci: sanitize error path
This patch:
- sanitizes error path in ehci_hcd_omap_drv_probe();
- removes two unnecessary debugging messages, we only need
debugging in the failing case generally;
- fix a memory leak when omap_start_ehc() fails: the recently
created hcd was never put in that case;
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 53 +
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index d994392..db4576d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -418,21 +418,24 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
struct usb_hcd *hcd;
int irq = platform_get_irq(pdev, 0);
- int retval = 0;
-
- dev_dbg(pdev-dev, ehci_hcd_omap_drv_probe()\n);
+ int ret = -ENODEV;
if (usb_disabled())
- return -ENODEV;
+ goto err_disabled;
hcd = usb_create_hcd(ehci_omap_hc_driver, pdev-dev,
dev_name(pdev-dev));
- if (!hcd)
- return -ENOMEM;
+ if (!hcd) {
+ dev_dbg(pdev-dev, failed to create hcd with err %d\n, ret);
+ ret = -ENOMEM;
+ goto err_create_hcd;
+ }
- retval = omap_start_ehc(pdev, hcd);
- if (retval)
- return retval;
+ ret = omap_start_ehc(pdev, hcd);
+ if (ret) {
+ dev_dbg(pdev-dev, failed to start ehci\n);
+ goto err_start;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -444,12 +447,12 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
if (!hcd-regs) {
dev_err(pdev-dev, ioremap failed\n);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_ioremap;
}
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
-
ehci-sbrn = 0x20;
ehci-regs = hcd-regs + HC_LENGTH(readl(ehci-caps-hc_capbase));
@@ -459,16 +462,26 @@ static int ehci_hcd_omap_drv_probe(struct platform_device
*pdev)
/* SET 1 micro-frame Interrupt interval */
writel(readl(ehci-regs-command) | (1 16), ehci-regs-command);
- retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
- if (retval == 0)
- return retval;
+ ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+ if (ret) {
+ dev_dbg(pdev-dev, failed to add hcd with err %d\n, ret);
+ goto err_add_hcd;
+ }
- dev_dbg(pdev-dev, ERR: add_hcd\n);
- omap_stop_ehc(pdev, hcd);
+ return 0;
+
+err_add_hcd:
iounmap(hcd-regs);
+
+err_ioremap:
+ omap_stop_ehc(pdev, hcd);
+
+err_start:
usb_put_hcd(hcd);
- return retval;
+err_create_hcd:
+err_disabled:
+ return ret;
}
/*-*/
@@ -490,12 +503,10 @@ static int ehci_hcd_omap_drv_remove(struct
platform_device *pdev)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
- dev_dbg(pdev-dev, ehci_hcd_omap_drv_remove()\n);
-
- iounmap(hcd-regs);
usb_remove_hcd(hcd);
- usb_put_hcd(hcd);
+ iounmap(hcd-regs);
omap_stop_ehc(pdev, hcd);
+ usb_put_hcd(hcd);
return 0;
}
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 07/23] usb: host: ehci: get rid of pm functions
That was just a useless function call, completely
unneeded. Remove it.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index db4576d..1b387cc 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -511,20 +511,6 @@ static int ehci_hcd_omap_drv_remove(struct platform_device
*pdev)
return 0;
}
-/*-*/
-#ifdef CONFIG_PM
-static int omap_ehci_bus_suspend(struct usb_hcd *hcd)
-{
- return ehci_bus_suspend(hcd);
-}
-
-static int omap_ehci_bus_resume(struct usb_hcd *hcd)
-{
- return ehci_bus_resume(hcd);
-}
-#endif
-/*-*/
-
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
.product_desc = OMAP-EHCI Host Controller,
@@ -562,10 +548,8 @@ static const struct hc_driver ehci_omap_hc_driver = {
*/
.hub_status_data= ehci_hub_status_data,
.hub_control= ehci_hub_control,
-#ifdef CONFIG_PM
- .bus_suspend= omap_ehci_bus_suspend,
- .bus_resume = omap_ehci_bus_resume,
-#endif
+ .bus_suspend= ehci_bus_suspend,
+ .bus_resume = ehci_bus_resume,
};
MODULE_ALIAS(platform:omap-ehci);
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 08/23] usb: host: ehci: reorganize structures
Move the platform_driver closer to its functions.
No functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1b387cc..e66f5f9 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -511,6 +511,18 @@ static int ehci_hcd_omap_drv_remove(struct platform_device
*pdev)
return 0;
}
+static struct platform_driver ehci_hcd_omap_driver = {
+ .probe = ehci_hcd_omap_drv_probe,
+ .remove = ehci_hcd_omap_drv_remove,
+ .shutdown = usb_hcd_platform_shutdown,
+ /*.suspend = ehci_hcd_omap_drv_suspend, */
+ /*.resume = ehci_hcd_omap_drv_resume, */
+ .driver = {
+ .name = ehci-omap,
+ .bus= platform_bus_type
+ }
+};
+
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
.product_desc = OMAP-EHCI Host Controller,
@@ -554,14 +566,3 @@ static const struct hc_driver ehci_omap_hc_driver = {
MODULE_ALIAS(platform:omap-ehci);
-static struct platform_driver ehci_hcd_omap_driver = {
- .probe = ehci_hcd_omap_drv_probe,
- .remove = ehci_hcd_omap_drv_remove,
- .shutdown = usb_hcd_platform_shutdown,
- /*.suspend = ehci_hcd_omap_drv_suspend, */
- /*.resume = ehci_hcd_omap_drv_resume, */
- .driver = {
- .name = ehci-omap,
- .bus= platform_bus_type
- }
-};
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 04/23] usb: host: ehci: tabify structures
Style only, no functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 46 +-
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index a4f5f16..e050795 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -518,57 +518,57 @@ static int omap_ehci_bus_resume(struct usb_hcd *hcd)
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
- .product_desc = OMAP-EHCI Host Controller,
- .hcd_priv_size = sizeof(struct ehci_hcd)
+ .product_desc = OMAP-EHCI Host Controller,
+ .hcd_priv_size = sizeof(struct ehci_hcd)
+ sizeof(struct ehci_omap_clock_defs),
/*
* generic hardware linkage
*/
- .irq = ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
+ .irq= ehci_irq,
+ .flags = HCD_MEMORY | HCD_USB2,
/*
* basic lifecycle operations
*/
- .reset = ehci_init,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
+ .reset = ehci_init,
+ .start = ehci_run,
+ .stop = ehci_stop,
+ .shutdown = ehci_shutdown,
/*
* managing i/o requests and associated device resources
*/
- .urb_enqueue = ehci_urb_enqueue,
- .urb_dequeue = ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
+ .urb_enqueue= ehci_urb_enqueue,
+ .urb_dequeue= ehci_urb_dequeue,
+ .endpoint_disable = ehci_endpoint_disable,
/*
* scheduling support
*/
- .get_frame_number = ehci_get_frame,
+ .get_frame_number = ehci_get_frame,
/*
* root hub support
*/
- .hub_status_data = ehci_hub_status_data,
- .hub_control = ehci_hub_control,
+ .hub_status_data= ehci_hub_status_data,
+ .hub_control= ehci_hub_control,
#ifdef CONFIG_PM
- .bus_suspend = omap_ehci_bus_suspend,
- .bus_resume = omap_ehci_bus_resume,
+ .bus_suspend= omap_ehci_bus_suspend,
+ .bus_resume = omap_ehci_bus_resume,
#endif
};
MODULE_ALIAS(platform:omap-ehci);
static struct platform_driver ehci_hcd_omap_driver = {
- .probe = ehci_hcd_omap_drv_probe,
- .remove = ehci_hcd_omap_drv_remove,
- .shutdown = usb_hcd_platform_shutdown,
- /*.suspend = ehci_hcd_omap_drv_suspend, */
- /*.resume = ehci_hcd_omap_drv_resume, */
+ .probe = ehci_hcd_omap_drv_probe,
+ .remove = ehci_hcd_omap_drv_remove,
+ .shutdown = usb_hcd_platform_shutdown,
+ /*.suspend = ehci_hcd_omap_drv_suspend, */
+ /*.resume = ehci_hcd_omap_drv_resume, */
.driver = {
- .name = ehci-omap,
- .bus = platform_bus_type
+ .name = ehci-omap,
+ .bus= platform_bus_type
}
};
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 09/23] usb: host: ehci: better function names
The drv in the function names was there just to make
it bigger, remove it so we have 4 characters smaller
lines. Also remove the platform_bus_type from platform_driver
since platform_driver_register() already does that.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e66f5f9..f5ffc5b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -404,14 +404,13 @@ static const struct hc_driver ehci_omap_hc_driver;
/* always called with process context; sleeping is OK */
/**
- * ehci_hcd_omap_drv_probe - initialize TI-based HCDs
- * Context: !in_interrupt()
+ * ehci_hcd_omap_probe - initialize TI-based HCDs
*
* Allocates basic resources for this USB host controller, and
* then invokes the start() method for the HCD associated with it
* through the hotplug entry's driver_data.
*/
-static int ehci_hcd_omap_drv_probe(struct platform_device *pdev)
+static int ehci_hcd_omap_probe(struct platform_device *pdev)
{
struct ehci_hcd *ehci;
struct resource *res;
@@ -484,22 +483,18 @@ err_disabled:
return ret;
}
-/*-*/
-
/* may be called without controller electrically present */
/* may be called with controller, bus, and devices active */
/**
- * ehci_hcd_omap_drv_remove - shutdown processing for EHCI HCDs
+ * ehci_hcd_omap_remove - shutdown processing for EHCI HCDs
* @pdev: USB Host Controller being removed
- * Context: !in_interrupt()
*
* Reverses the effect of usb_ehci_hcd_omap_probe(), first invoking
* the HCD's stop() method. It is always called from a thread
* context, normally rmmod, apmd, or something similar.
- *
*/
-static int ehci_hcd_omap_drv_remove(struct platform_device *pdev)
+static int ehci_hcd_omap_remove(struct platform_device *pdev)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
@@ -512,17 +507,18 @@ static int ehci_hcd_omap_drv_remove(struct
platform_device *pdev)
}
static struct platform_driver ehci_hcd_omap_driver = {
- .probe = ehci_hcd_omap_drv_probe,
- .remove = ehci_hcd_omap_drv_remove,
+ .probe = ehci_hcd_omap_probe,
+ .remove = ehci_hcd_omap_remove,
.shutdown = usb_hcd_platform_shutdown,
- /*.suspend = ehci_hcd_omap_drv_suspend, */
- /*.resume = ehci_hcd_omap_drv_resume, */
+ /*.suspend = ehci_hcd_omap_suspend, */
+ /*.resume = ehci_hcd_omap_resume, */
.driver = {
.name = ehci-omap,
- .bus= platform_bus_type
}
};
+/*-*/
+
static const struct hc_driver ehci_omap_hc_driver = {
.description = hcd_name,
.product_desc = OMAP-EHCI Host Controller,
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 21/23] usb: host: ehci: don't ensure register write
There's no reason to think register writes would fail so remove
all unnecessary while() loops keeping only the ones checking
whether reset is done or not.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 185 --
1 files changed, 52 insertions(+), 133 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index c2b592f..e413601 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -7,6 +7,9 @@
* Copyright (C) 2007-2008 Texas Instruments, Inc.
* Author: Vikram Pandita vikram.pand...@ti.com
*
+ * Copyright (C) 2009 Nokia Corporation
+ * Contact: Felipe Balbi felipe.ba...@nokia.com
+ *
* Based on ehci-fsl.c and ehci-au1xxx.c ehci glue layers
*
* This program is free software; you can redistribute it and/or modify
@@ -28,15 +31,8 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/gpio.h
-
-/* platform_data lives here */
#include mach/usb.h
-/* FIXME remove platform-specific code */
-#include mach/hardware.h
-#include ../../../arch/arm/mach-omap2/cm.h
-#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h
-
/*
* OMAP USBHOST Register addresses: VIRTUAL ADDRESSES
* Use ehci_omap_readl()/ehci_omap_writel() functions
@@ -178,7 +174,6 @@ struct ehci_hcd_omap {
static void omap_usb_utmi_init(struct ehci_hcd_omap *omap, u8 tll_channel_mask)
{
- unsigned long timeout = jiffies + msecs_to_jiffies(100);
unsigned reg;
int i;
@@ -192,19 +187,6 @@ static void omap_usb_utmi_init(struct ehci_hcd_omap *omap,
u8 tll_channel_mask)
/* Use UTMI Ports of TLL */
ehci_omap_writel(omap-uhh_base, OMAP_UHH_HOSTCONFIG, reg);
- /* Ensure bit is set */
- while (!(ehci_omap_readl(omap-uhh_base, OMAP_UHH_HOSTCONFIG)
-OMAP_UHH_HOSTCONFIG_ULPI_BYPASS)) {
- cpu_relax();
-
- if (time_after(timeout, jiffies)) {
- dev_dbg(omap-dev, operation timed out\n);
- return;
- }
- }
-
- dev_dbg(omap-dev, Entered UTMI MODE: success\n);
-
/* Program the 3 TLL channels upfront */
for (i = 0; i OMAP_TLL_CHANNEL_COUNT; i++) {
reg = ehci_omap_readl(omap-tll_base, OMAP_TLL_CHANNEL_CONF(i));
@@ -246,6 +228,8 @@ static void omap_usb_utmi_init(struct ehci_hcd_omap *omap,
u8 tll_channel_mask)
/*-*/
+#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h
+
/* omap_start_ehc
* - Start the TI USBHOST controller
*/
@@ -274,32 +258,11 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
PLL_MOD, OMAP3430ES2_CM_CLKEN2);
while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2)
- OMAP3430ES2_ST_PERIPH2_CLK_MASK)) {
+ OMAP3430ES2_ST_PERIPH2_CLK_MASK))
dev_dbg(omap-dev, idlest2 = 0x%x\n,
cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
-
- if (time_after(timeout, jiffies)) {
- dev_dbg(omap-dev, operation timed out\n);
- ret = -EINVAL;
- goto err_idlest2;
- }
- }
/* End DPLL5 programming */
- /* PRCM settings for USBHOST:
-* Interface clk un-related to domain transition
-*/
- cm_write_mod_reg(0 OMAP3430ES2_AUTO_USBHOST_SHIFT,
- OMAP3430ES2_USBHOST_MOD, CM_AUTOIDLE);
-
- /* Disable sleep dependency with MPU and IVA */
- cm_write_mod_reg((0 OMAP3430ES2_EN_MPU_SHIFT) |
- (0 OMAP3430ES2_EN_IVA2_SHIFT),
- OMAP3430ES2_USBHOST_MOD, OMAP3430_CM_SLEEPDEP);
-
- /* Disable Automatic transition of clock */
- cm_write_mod_reg(0 OMAP3430ES2_CLKTRCTRL_USBHOST_SHIFT,
- OMAP3430ES2_USBHOST_MOD, CM_CLKSTCTRL);
/* Enable Clocks for USBHOST */
omap-usbhost_ick = clk_get(omap-dev, USBHOST_ICKL);
@@ -348,22 +311,6 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
}
clk_enable(omap-usbtll_ick);
- /* Disable Auto Idle of USBTLL */
- cm_write_mod_reg((0 OMAP3430ES2_AUTO_USBTLL),
- CORE_MOD, CM_AUTOIDLE3);
-
- /* Wait for TLL to be Active */
- while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(0 OMAP3430ES2_ST_USBTLL_SHIFT))) {
- cpu_relax();
-
- if (time_after(timeout, jiffies)) {
- dev_dbg(omap-dev, operation timed out\n);
- ret = -EINVAL;
- goto err_idlest3;
- }
- }
-
/* perform TLL soft reset, and wait until reset is complete
[rft/rfc/patch-v2.6.29-rc5+ 14/23] usb: host: ehci: get rid of infinite loops
Use time_after() to avoid looping forever.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 87 +-
1 files changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 2bdc978..35c645d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -182,6 +182,7 @@ struct ehci_omap_clock_defs {
static void omap_usb_utmi_init(struct usb_hcd *hcd, u8 tll_channel_mask)
{
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
int i;
/* Use UTMI Ports of TLL */
@@ -193,9 +194,15 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
OMAP_UHH_HOSTCONFIG);
/* Enusre bit is set */
while (!(omap_readl(OMAP_UHH_HOSTCONFIG)
-(1 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT)))
+(1 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT))) {
cpu_relax();
+ if (time_after(timeout, jiffies)) {
+ dev_dbg(hcd-self.controller, operation timed out\n);
+ return;
+ }
+ }
+
dev_dbg(hcd-self.controller, Entered UTMI MODE: success\n);
/* Program the 3 TLL channels upfront */
@@ -254,6 +261,7 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
static int omap_start_ehc(struct platform_device *dev, struct usb_hcd *hcd)
{
struct ehci_omap_clock_defs *ehci_clocks;
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
dev_dbg(hcd-self.controller, starting TI EHCI USB Controller\n);
@@ -278,10 +286,16 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
PLL_MOD, OMAP3430ES2_CM_CLKEN2);
while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2)
- OMAP3430ES2_ST_PERIPH2_CLK_MASK))
+ OMAP3430ES2_ST_PERIPH2_CLK_MASK)) {
dev_dbg(hcd-self.controller,
idlest2 = 0x%x\n,
cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
+
+ if (time_after(timeout, jiffies)) {
+ dev_dbg(hcd-self.controller, operation timed out\n);
+ return -EINVAL;
+ }
+ }
/* End DPLL5 programming */
@@ -347,17 +361,30 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Wait for TLL to be Active */
while ((cm_read_mod_reg(CORE_MOD, OMAP2430_CM_IDLEST3)
-(1 OMAP3430ES2_ST_USBTLL_SHIFT)))
+(1 OMAP3430ES2_ST_USBTLL_SHIFT))) {
cpu_relax();
+ if (time_after(timeout, jiffies)) {
+ dev_dbg(hcd-self.controller, operation timed out\n);
+ return -EINVAL;
+ }
+ }
+
/* perform TLL soft reset, and wait until reset is complete */
omap_writel(1 OMAP_USBTLL_SYSCONFIG_SOFTRESET_SHIFT,
OMAP_USBTLL_SYSCONFIG);
+
/* Wait for TLL reset to complete */
while (!(omap_readl(OMAP_USBTLL_SYSSTATUS)
-(1 OMAP_USBTLL_SYSSTATUS_RESETDONE_SHIFT)))
+(1 OMAP_USBTLL_SYSSTATUS_RESETDONE_SHIFT))) {
cpu_relax();
+ if (time_after(timeout, jiffies)) {
+ dev_dbg(hcd-self.controller, operation timed out\n);
+ return -EINVAL;
+ }
+ }
+
dev_dbg(hcd-self.controller, TLL RESET DONE\n);
/* (13) = no idle mode only for initial debugging */
@@ -383,11 +410,18 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
(1 OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT)|
(0 OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN_SHIFT),
OMAP_UHH_HOSTCONFIG);
+
/* Ensure that BYPASS is set */
while (omap_readl(OMAP_UHH_HOSTCONFIG)
-(1 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT))
+(1 OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT)) {
cpu_relax();
+ if (time_after(timeout, jiffies)) {
+ dev_dbg(hcd-self.controller, operation timed out\n);
+ return -EINVAL;
+ }
+ }
+
dev_dbg(hcd-self.controller, Entered ULPI PHY MODE: success\n);
#else
@@ -422,9 +456,15 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
EHCI_INSNREG05_ULPI);
while (!(omap_readl(EHCI_INSNREG05_ULPI)
-(1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT)))
+(1 EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) {
[rft/rfc/patch-v2.6.29-rc5+ 10/23] usb: host: ehci: move some comments
Move some of the comments used to separate the code
to more logical places. No functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index f5ffc5b..b7f02f6 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -77,6 +77,7 @@ struct ehci_omap_clock_defs {
#define USBHOST_48M_FCLK usbhost_48m_fck
#define USBHOST_TLL_ICKL usbtll_ick
#define USBHOST_TLL_FCLK usbtll_fck
+
/*-*/
#ifndef CONFIG_OMAP_EHCI_PHY_MODE
@@ -147,6 +148,7 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
# define omap_usb_utmi_init(x, y) 0
#endif
+/*-*/
/* omap_start_ehc
* - Start the TI USBHOST controller
@@ -330,8 +332,6 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
return 0;
}
-/*-*/
-
static void omap_stop_ehc(struct platform_device *dev, struct usb_hcd *hcd)
{
struct ehci_omap_clock_defs *ehci_clocks;
@@ -397,9 +397,10 @@ static void omap_stop_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
Clock to USB host has been disabled\n);
}
+/*-*/
+
static const struct hc_driver ehci_omap_hc_driver;
-/*-*/
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 16/23] usb: host: ehci: add platform_data
Adding a platform_data to the driver allow us
to remove some of the ifdeferry in the code.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/usb-ehci.c | 14 +-
arch/arm/plat-omap/include/mach/usb.h| 24 ++-
drivers/usb/host/Kconfig | 19 --
drivers/usb/host/ehci-omap.c | 401 +++---
9 files changed, 241 insertions(+), 227 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 758183c..3f85c6e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -643,7 +643,7 @@ static void __init omap_3430sdp_init(void)
msecure_init();
omap_serial_init();
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
}
static void __init omap_3430sdp_map_io(void)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5f5cc39..18d9a86 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -380,7 +380,7 @@ static void __init omap3_beagle_init(void)
gpio_direction_output(170, true);
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
omap3beagle_flash_init();
}
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 6577726..514058f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -255,7 +255,7 @@ static void __init omap3_evm_init(void)
omap_serial_init();
twl4030_mmc_init(mmc);
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
omap3evm_flash_init();
ads7846_dev_init();
}
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index b8a78c0..08215c0 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -297,7 +297,7 @@ static void __init omap3pandora_init(void)
spi_register_board_info(omap3pandora_spi_board_info,
ARRAY_SIZE(omap3pandora_spi_board_info));
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
omap3pandora_flash_init();
omap3pandora_ads7846_init();
}
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index e5a3412..b51c835 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -246,7 +246,7 @@ static void __init overo_init(void)
omap_serial_init();
twl4030_mmc_init(mmc);
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
overo_flash_init();
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c
index 23fe857..30e1ad6 100644
--- a/arch/arm/mach-omap2/usb-ehci.c
+++ b/arch/arm/mach-omap2/usb-ehci.c
@@ -145,8 +145,20 @@ static void setup_ehci_io_mux(void)
return;
}
-void __init usb_ehci_init(void)
+void __init usb_ehci_init(enum ehci_hcd_omap_mode phy_mode,
+ int chargepump, int phy_reset, int reset_gpio_port1,
+ int reset_gpio_port2)
{
+ struct ehci_hcd_omap_platform_data pdata = {
+ .phy_mode = phy_mode,
+ .chargepump = chargepump,
+ .phy_reset = phy_reset,
+ .reset_gpio_port1 = reset_gpio_port1,
+ .reset_gpio_port2 = reset_gpio_port2,
+ };
+
+ ehci_device.dev.platform_data = pdata;
+
/* Setup Pin IO MUX for EHCI */
if (cpu_is_omap34xx())
setup_ehci_io_mux();
diff --git a/arch/arm/plat-omap/include/mach/usb.h
b/arch/arm/plat-omap/include/mach/usb.h
index 47aba6b..8a341ca 100644
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -5,6 +5,22 @@
#include mach/board.h
+enum ehci_hcd_omap_mode {
+ EHCI_HCD_OMAP_MODE_UNKNOWN,
+ EHCI_HCD_OMAP_MODE_PHY,
+ EHCI_HCD_OMAP_MODE_TLL,
+};
+
+struct ehci_hcd_omap_platform_data {
+ enum ehci_hcd_omap_mode phy_mode;
+ unsignedchargepump:1;
+ unsignedphy_reset:1;
+
+ /* have to be valid if phy_reset is true */
+ int reset_gpio_port1;
+ int reset_gpio_port2;
+};
+
[rft/rfc/patch-v2.6.29-rc5+ 12/23] usb: host: ehci: include linux/gpio.h instead
include linux/gpio.h instead of mach/gpio.h Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 2fbf377..7f37b5f 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -27,7 +27,7 @@ #include linux/platform_device.h #include linux/clk.h -#include mach/gpio.h +#include linux/gpio.h #include ehci-omap.h -- 1.6.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 10/23] usb: host: ehci: move some comments
Move some of the comments used to separate the code
to more logical places. No functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index f5ffc5b..b7f02f6 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -77,6 +77,7 @@ struct ehci_omap_clock_defs {
#define USBHOST_48M_FCLK usbhost_48m_fck
#define USBHOST_TLL_ICKL usbtll_ick
#define USBHOST_TLL_FCLK usbtll_fck
+
/*-*/
#ifndef CONFIG_OMAP_EHCI_PHY_MODE
@@ -147,6 +148,7 @@ static void omap_usb_utmi_init(struct usb_hcd *hcd, u8
tll_channel_mask)
# define omap_usb_utmi_init(x, y) 0
#endif
+/*-*/
/* omap_start_ehc
* - Start the TI USBHOST controller
@@ -330,8 +332,6 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
return 0;
}
-/*-*/
-
static void omap_stop_ehc(struct platform_device *dev, struct usb_hcd *hcd)
{
struct ehci_omap_clock_defs *ehci_clocks;
@@ -397,9 +397,10 @@ static void omap_stop_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
Clock to USB host has been disabled\n);
}
+/*-*/
+
static const struct hc_driver ehci_omap_hc_driver;
-/*-*/
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 15/23] usb: host: ehci: disable clocks on error
The driver wasn't releasing the requested resources
on error, so make that work.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 82 ++
1 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 35c645d..b058ada 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -262,6 +262,7 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
{
struct ehci_omap_clock_defs *ehci_clocks;
unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ int ret = 0;
dev_dbg(hcd-self.controller, starting TI EHCI USB Controller\n);
@@ -293,7 +294,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_idlest2;
}
}
/* End DPLL5 programming */
@@ -317,20 +319,26 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Enable Clocks for USBHOST */
ehci_clocks-usbhost_ick_clk = clk_get(dev-dev,
USBHOST_ICKL);
- if (IS_ERR(ehci_clocks-usbhost_ick_clk))
- return PTR_ERR(ehci_clocks-usbhost_ick_clk);
+ if (IS_ERR(ehci_clocks-usbhost_ick_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbhost_ick_clk);
+ goto err_host_ick;
+ }
clk_enable(ehci_clocks-usbhost_ick_clk);
ehci_clocks-usbhost2_120m_fck_clk = clk_get(dev-dev,
USBHOST_120M_FCLK);
- if (IS_ERR(ehci_clocks-usbhost2_120m_fck_clk))
- return PTR_ERR(ehci_clocks-usbhost2_120m_fck_clk);
+ if (IS_ERR(ehci_clocks-usbhost2_120m_fck_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbhost2_120m_fck_clk);
+ goto err_host_120m_fck;
+ }
clk_enable(ehci_clocks-usbhost2_120m_fck_clk);
ehci_clocks-usbhost1_48m_fck_clk = clk_get(dev-dev,
USBHOST_48M_FCLK);
- if (IS_ERR(ehci_clocks-usbhost1_48m_fck_clk))
- return PTR_ERR(ehci_clocks-usbhost1_48m_fck_clk);
+ if (IS_ERR(ehci_clocks-usbhost1_48m_fck_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbhost1_48m_fck_clk);
+ goto err_host_48m_fck;
+ }
clk_enable(ehci_clocks-usbhost1_48m_fck_clk);
@@ -346,13 +354,17 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Configure TLL for 60Mhz clk for ULPI */
ehci_clocks-usbtll_fck_clk = clk_get(dev-dev, USBHOST_TLL_FCLK);
- if (IS_ERR(ehci_clocks-usbtll_fck_clk))
- return PTR_ERR(ehci_clocks-usbtll_fck_clk);
+ if (IS_ERR(ehci_clocks-usbtll_fck_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbtll_fck_clk);
+ goto err_tll_fck;
+ }
clk_enable(ehci_clocks-usbtll_fck_clk);
ehci_clocks-usbtll_ick_clk = clk_get(dev-dev, USBHOST_TLL_ICKL);
- if (IS_ERR(ehci_clocks-usbtll_ick_clk))
- return PTR_ERR(ehci_clocks-usbtll_ick_clk);
+ if (IS_ERR(ehci_clocks-usbtll_ick_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbtll_ick_clk);
+ goto err_tll_ick;
+ }
clk_enable(ehci_clocks-usbtll_ick_clk);
/* Disable Auto Idle of USBTLL */
@@ -366,7 +378,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_idlest3;
}
}
@@ -381,7 +394,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_sys_status;
}
}
@@ -418,7 +432,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_ulpi_bypass;
}
}
@@ -461,13 +476,50 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
[rft/rfc/patch-v2.6.29-rc5+ 15/23] usb: host: ehci: disable clocks on error
The driver wasn't releasing the requested resources
on error, so make that work.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 82 ++
1 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 35c645d..b058ada 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -262,6 +262,7 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
{
struct ehci_omap_clock_defs *ehci_clocks;
unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ int ret = 0;
dev_dbg(hcd-self.controller, starting TI EHCI USB Controller\n);
@@ -293,7 +294,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_idlest2;
}
}
/* End DPLL5 programming */
@@ -317,20 +319,26 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Enable Clocks for USBHOST */
ehci_clocks-usbhost_ick_clk = clk_get(dev-dev,
USBHOST_ICKL);
- if (IS_ERR(ehci_clocks-usbhost_ick_clk))
- return PTR_ERR(ehci_clocks-usbhost_ick_clk);
+ if (IS_ERR(ehci_clocks-usbhost_ick_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbhost_ick_clk);
+ goto err_host_ick;
+ }
clk_enable(ehci_clocks-usbhost_ick_clk);
ehci_clocks-usbhost2_120m_fck_clk = clk_get(dev-dev,
USBHOST_120M_FCLK);
- if (IS_ERR(ehci_clocks-usbhost2_120m_fck_clk))
- return PTR_ERR(ehci_clocks-usbhost2_120m_fck_clk);
+ if (IS_ERR(ehci_clocks-usbhost2_120m_fck_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbhost2_120m_fck_clk);
+ goto err_host_120m_fck;
+ }
clk_enable(ehci_clocks-usbhost2_120m_fck_clk);
ehci_clocks-usbhost1_48m_fck_clk = clk_get(dev-dev,
USBHOST_48M_FCLK);
- if (IS_ERR(ehci_clocks-usbhost1_48m_fck_clk))
- return PTR_ERR(ehci_clocks-usbhost1_48m_fck_clk);
+ if (IS_ERR(ehci_clocks-usbhost1_48m_fck_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbhost1_48m_fck_clk);
+ goto err_host_48m_fck;
+ }
clk_enable(ehci_clocks-usbhost1_48m_fck_clk);
@@ -346,13 +354,17 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
/* Configure TLL for 60Mhz clk for ULPI */
ehci_clocks-usbtll_fck_clk = clk_get(dev-dev, USBHOST_TLL_FCLK);
- if (IS_ERR(ehci_clocks-usbtll_fck_clk))
- return PTR_ERR(ehci_clocks-usbtll_fck_clk);
+ if (IS_ERR(ehci_clocks-usbtll_fck_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbtll_fck_clk);
+ goto err_tll_fck;
+ }
clk_enable(ehci_clocks-usbtll_fck_clk);
ehci_clocks-usbtll_ick_clk = clk_get(dev-dev, USBHOST_TLL_ICKL);
- if (IS_ERR(ehci_clocks-usbtll_ick_clk))
- return PTR_ERR(ehci_clocks-usbtll_ick_clk);
+ if (IS_ERR(ehci_clocks-usbtll_ick_clk)) {
+ ret = PTR_ERR(ehci_clocks-usbtll_ick_clk);
+ goto err_tll_ick;
+ }
clk_enable(ehci_clocks-usbtll_ick_clk);
/* Disable Auto Idle of USBTLL */
@@ -366,7 +378,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_idlest3;
}
}
@@ -381,7 +394,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_sys_status;
}
}
@@ -418,7 +432,8 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
dev_dbg(hcd-self.controller, operation timed out\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_ulpi_bypass;
}
}
@@ -461,13 +476,50 @@ static int omap_start_ehc(struct platform_device *dev,
struct usb_hcd *hcd)
if (time_after(timeout, jiffies)) {
[rft/rfc/patch-v2.6.29-rc5+ 20/23] usb: host: ehci: align defines
Just making it better for my bad eyes. Style only, no functional changes. Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c | 114 - 1 files changed, 56 insertions(+), 58 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 48ced8f..c2b592f 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -43,32 +43,33 @@ */ /* TLL Register Set */ -#defineOMAP_USBTLL_REVISION(0x00) -#defineOMAP_USBTLL_SYSCONFIG (0x10) - #define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8) - #define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3) - #define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2) - #define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1) - #define OMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0) -#defineOMAP_USBTLL_SYSSTATUS (0x14) - #define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 0) -#defineOMAP_USBTLL_IRQSTATUS (0x18) -#defineOMAP_USBTLL_IRQENABLE (0x1C) - -#defineOMAP_TLL_SHARED_CONF(0x30) - #define OMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6) - #define OMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5) - #define OMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2) - #define OMAP_TLL_SHARED_CONF_FCLK_REQ (1 1) - #define OMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0) - -#defineOMAP_TLL_CHANNEL_CONF(num)\ - (0x040 + 0x004 * num) - #define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11) - #define OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10) - #define OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9) - #define OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8) - #define OMAP_TLL_CHANNEL_CONF_CHANEN(1 0) +#defineOMAP_USBTLL_REVISION(0x00) +#defineOMAP_USBTLL_SYSCONFIG (0x10) +#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8) +#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3) +#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2) +#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1) +#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0) + +#defineOMAP_USBTLL_SYSSTATUS (0x14) +#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0) + +#defineOMAP_USBTLL_IRQSTATUS (0x18) +#defineOMAP_USBTLL_IRQENABLE (0x1C) + +#defineOMAP_TLL_SHARED_CONF(0x30) +#defineOMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6) +#defineOMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5) +#defineOMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2) +#defineOMAP_TLL_SHARED_CONF_FCLK_REQ (1 1) +#defineOMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0) + +#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004 * num) +#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11) +#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10) +#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9) +#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8) +#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 0) #defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)(0x804 + 0x100 * num) #defineOMAP_TLL_ULPI_INTERFACE_CTRL(num) (0x807 + 0x100 * num) @@ -80,42 +81,39 @@ #defineOMAP_TLL_ULPI_DEBUG(num)(0x815 + 0x100 * num) #defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num) (0x816 + 0x100 * num) -#define OMAP_TLL_CHANNEL_COUNT 3 - #define OMAP_TLL_CHANNEL_1_EN_MASK (1 1) - #define OMAP_TLL_CHANNEL_2_EN_MASK (1 2) - #define OMAP_TLL_CHANNEL_3_EN_MASK (1 4) +#define OMAP_TLL_CHANNEL_COUNT 3 +#define OMAP_TLL_CHANNEL_1_EN_MASK (1 1) +#define OMAP_TLL_CHANNEL_2_EN_MASK (1 2) +#define OMAP_TLL_CHANNEL_3_EN_MASK (1 4) /* UHH Register Set */ -#defineOMAP_UHH_REVISION (0x00) -#defineOMAP_UHH_SYSCONFIG (0x10) - #define OMAP_UHH_SYSCONFIG_MIDLEMODE(1 12) - #define OMAP_UHH_SYSCONFIG_CACTIVITY(1 8) - #define OMAP_UHH_SYSCONFIG_SIDLEMODE(1 3) - #define OMAP_UHH_SYSCONFIG_ENAWAKEUP(1 2) - #define OMAP_UHH_SYSCONFIG_SOFTRESET(1 1) - #define OMAP_UHH_SYSCONFIG_AUTOIDLE (1 0) - -#defineOMAP_UHH_SYSSTATUS (0x14) -#defineOMAP_UHH_HOSTCONFIG (0x40) - #define
[rft/rfc/patch-v2.6.29-rc5+ 13/23] usb: host: ehci: remove ehci-omap.h
That header is only used by ehci-omap.c for register definitions and indirectly include some other headers. Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c | 100 +- drivers/usb/host/ehci-omap.h | 125 -- 2 files changed, 99 insertions(+), 126 deletions(-) delete mode 100644 drivers/usb/host/ehci-omap.h diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 7f37b5f..2bdc978 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -29,7 +29,105 @@ #include linux/clk.h #include linux/gpio.h -#include ehci-omap.h +/* FIXME remove platform-specific code */ +#include mach/hardware.h +#include ../../../arch/arm/mach-omap2/cm.h +#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h + +/* + * OMAP USBHOST Register addresses: PHYSICAL ADDRESSES + * Use omap_readl()/omap_writel() functions + */ + +/* USBHOST: TLL, UUH, OHCI, EHCI */ +#defineOMAP_USBHOST_BASE (L4_34XX_BASE + 0x6) + +/* TLL Register Set */ +#defineOMAP_USBHOST_TLL_BASE (OMAP_USBHOST_BASE + 0x2000) +#defineOMAP_USBTLL_REVISION(OMAP_USBHOST_TLL_BASE + 0x00) +#defineOMAP_USBTLL_SYSCONFIG (OMAP_USBHOST_TLL_BASE + 0x10) + #define OMAP_USBTLL_SYSCONFIG_CACTIVITY_SHIFT 8 + #define OMAP_USBTLL_SYSCONFIG_SIDLEMODE_SHIFT 3 + #define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP_SHIFT 2 + #define OMAP_USBTLL_SYSCONFIG_SOFTRESET_SHIFT 1 + #define OMAP_USBTLL_SYSCONFIG_AUTOIDLE_SHIFT0 +#defineOMAP_USBTLL_SYSSTATUS (OMAP_USBHOST_TLL_BASE + 0x14) + #define OMAP_USBTLL_SYSSTATUS_RESETDONE_SHIFT 0 +#defineOMAP_USBTLL_IRQSTATUS (OMAP_USBHOST_TLL_BASE + 0x18) +#defineOMAP_USBTLL_IRQENABLE (OMAP_USBHOST_TLL_BASE + 0x1C) + +#defineOMAP_TLL_SHARED_CONF(OMAP_USBHOST_TLL_BASE + 0x30) + #define OMAP_TLL_SHARED_CONF_USB_90D_DDR_EN_SHFT6 + #define OMAP_TLL_SHARED_CONF_USB_180D_SDR_EN_SHIFT 5 + #define OMAP_TLL_SHARED_CONF_USB_DIVRATION_SHIFT2 + #define OMAP_TLL_SHARED_CONF_FCLK_REQ_SHIFT 1 + #define OMAP_TLL_SHARED_CONF_FCLK_IS_ON_SHIFT 0 + +#defineOMAP_TLL_CHANNEL_CONF(num)\ + (OMAP_USBHOST_TLL_BASE + (0x040 + 0x004 * num)) + #define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF_SHIFT 11 + #define OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE_SHIFT 10 + #define OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE_SHIFT9 + #define OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE_SHIFT 8 + #define OMAP_TLL_CHANNEL_CONF_CHANEN_SHIFT 0 + +#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x804 + 0x100 * num)) +#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x807 + 0x100 * num)) +#defineOMAP_TLL_ULPI_OTG_CTRL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x80A + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_EN_RISE(num)\ + (OMAP_USBHOST_TLL_BASE + (0x80D + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_EN_FALL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x810 + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_STATUS(num)\ + (OMAP_USBHOST_TLL_BASE + (0x813 + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_LATCH(num)\ + (OMAP_USBHOST_TLL_BASE + (0x814 + 0x100 * num)) +#defineOMAP_TLL_ULPI_DEBUG(num)\ + (OMAP_USBHOST_TLL_BASE + (0x815 + 0x100 * num)) +#defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num)\ + (OMAP_USBHOST_TLL_BASE + (0x816 + 0x100 * num)) + +#define OMAP_TLL_CHANNEL_COUNT 3 + #define OMAP_TLL_CHANNEL_1_EN_MASK 1 + #define OMAP_TLL_CHANNEL_2_EN_MASK 2 + #define OMAP_TLL_CHANNEL_3_EN_MASK 4 + +/* UHH Register Set */ +#defineOMAP_USBHOST_UHH_BASE (OMAP_USBHOST_BASE + 0x4000) +#defineOMAP_UHH_REVISION (OMAP_USBHOST_UHH_BASE + 0x00) +#defineOMAP_UHH_SYSCONFIG (OMAP_USBHOST_UHH_BASE + 0x10) + #define OMAP_UHH_SYSCONFIG_MIDLEMODE_SHIFT 12 + #define OMAP_UHH_SYSCONFIG_CACTIVITY_SHIFT 8 + #define OMAP_UHH_SYSCONFIG_SIDLEMODE_SHIFT 3 + #define OMAP_UHH_SYSCONFIG_ENAWAKEUP_SHIFT 2 + #define OMAP_UHH_SYSCONFIG_SOFTRESET_SHIFT 1 + #define OMAP_UHH_SYSCONFIG_AUTOIDLE_SHIFT 0 + +#defineOMAP_UHH_SYSSTATUS (OMAP_USBHOST_UHH_BASE + 0x14) +#defineOMAP_UHH_HOSTCONFIG (OMAP_USBHOST_UHH_BASE + 0x40) + #define OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT 0 + #define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN_SHIFT2 + #define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN_SHIFT3 + #define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT 4 + #define
[rft/rfc/patch-v2.6.29-rc5+ 19/23] usb: host: ehci: ioremap all usb bases
doing that will allow us to use standarnd __raw_read/write
calls and stop using omap_read/write ones.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
One patch from Tony ensuring register read only after clocks
where on, was melded into this one.
arch/arm/mach-omap2/usb-ehci.c | 20 +++-
drivers/usb/host/ehci-omap.c | 241 +++-
2 files changed, 155 insertions(+), 106 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c
index 6c1a46f..7f7b844 100644
--- a/arch/arm/mach-omap2/usb-ehci.c
+++ b/arch/arm/mach-omap2/usb-ehci.c
@@ -29,12 +29,22 @@
#include mach/usb.h
static struct resource ehci_resources[] = {
- [0] = {
- .start = OMAP34XX_EHCI_BASE,
- .end = OMAP34XX_EHCI_BASE + SZ_1K - 1,
- .flags = IORESOURCE_MEM,
+ {
+ .start = OMAP34XX_EHCI_BASE,
+ .end= OMAP34XX_EHCI_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
},
- [1] = { /* general IRQ */
+ {
+ .start = OMAP34XX_UHH_CONFIG_BASE,
+ .end= OMAP34XX_UHH_CONFIG_BASE + SZ_1K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_USBTLL_BASE,
+ .end= OMAP34XX_USBTLL_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* general IRQ */
.start = INT_34XX_EHCI_IRQ,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index c9305a3..48ced8f 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -38,28 +38,24 @@
#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h
/*
- * OMAP USBHOST Register addresses: PHYSICAL ADDRESSES
- * Use omap_readl()/omap_writel() functions
+ * OMAP USBHOST Register addresses: VIRTUAL ADDRESSES
+ * Use ehci_omap_readl()/ehci_omap_writel() functions
*/
-/* USBHOST: TLL, UUH, OHCI, EHCI */
-#defineOMAP_USBHOST_BASE (L4_34XX_BASE + 0x6)
-
/* TLL Register Set */
-#defineOMAP_USBHOST_TLL_BASE (OMAP_USBHOST_BASE + 0x2000)
-#defineOMAP_USBTLL_REVISION(OMAP_USBHOST_TLL_BASE + 0x00)
-#defineOMAP_USBTLL_SYSCONFIG (OMAP_USBHOST_TLL_BASE + 0x10)
+#defineOMAP_USBTLL_REVISION(0x00)
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
#define OMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
-#defineOMAP_USBTLL_SYSSTATUS (OMAP_USBHOST_TLL_BASE + 0x14)
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
-#defineOMAP_USBTLL_IRQSTATUS (OMAP_USBHOST_TLL_BASE + 0x18)
-#defineOMAP_USBTLL_IRQENABLE (OMAP_USBHOST_TLL_BASE + 0x1C)
+#defineOMAP_USBTLL_IRQSTATUS (0x18)
+#defineOMAP_USBTLL_IRQENABLE (0x1C)
-#defineOMAP_TLL_SHARED_CONF(OMAP_USBHOST_TLL_BASE + 0x30)
+#defineOMAP_TLL_SHARED_CONF(0x30)
#define OMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6)
#define OMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5)
#define OMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2)
@@ -67,31 +63,22 @@
#define OMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0)
#defineOMAP_TLL_CHANNEL_CONF(num)\
- (OMAP_USBHOST_TLL_BASE + (0x040 + 0x004 * num))
+ (0x040 + 0x004 * num)
#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11)
#define OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10)
#define OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9)
#define OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8)
#define OMAP_TLL_CHANNEL_CONF_CHANEN(1 0)
-#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)\
- (OMAP_USBHOST_TLL_BASE + (0x804 + 0x100 * num))
-#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num)\
- (OMAP_USBHOST_TLL_BASE + (0x807 + 0x100 * num))
-#defineOMAP_TLL_ULPI_OTG_CTRL(num)\
- (OMAP_USBHOST_TLL_BASE + (0x80A + 0x100 * num))
-#defineOMAP_TLL_ULPI_INT_EN_RISE(num)\
- (OMAP_USBHOST_TLL_BASE + (0x80D + 0x100 * num))
-#defineOMAP_TLL_ULPI_INT_EN_FALL(num)\
- (OMAP_USBHOST_TLL_BASE + (0x810 + 0x100 * num))
-#defineOMAP_TLL_ULPI_INT_STATUS(num)\
- (OMAP_USBHOST_TLL_BASE + (0x813 + 0x100 * num))
-#defineOMAP_TLL_ULPI_INT_LATCH(num)\
-
[rft/rfc/patch-v2.6.29-rc5+ 13/23] usb: host: ehci: remove ehci-omap.h
That header is only used by ehci-omap.c for register definitions and indirectly include some other headers. Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c | 100 +- drivers/usb/host/ehci-omap.h | 125 -- 2 files changed, 99 insertions(+), 126 deletions(-) delete mode 100644 drivers/usb/host/ehci-omap.h diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 7f37b5f..2bdc978 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -29,7 +29,105 @@ #include linux/clk.h #include linux/gpio.h -#include ehci-omap.h +/* FIXME remove platform-specific code */ +#include mach/hardware.h +#include ../../../arch/arm/mach-omap2/cm.h +#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h + +/* + * OMAP USBHOST Register addresses: PHYSICAL ADDRESSES + * Use omap_readl()/omap_writel() functions + */ + +/* USBHOST: TLL, UUH, OHCI, EHCI */ +#defineOMAP_USBHOST_BASE (L4_34XX_BASE + 0x6) + +/* TLL Register Set */ +#defineOMAP_USBHOST_TLL_BASE (OMAP_USBHOST_BASE + 0x2000) +#defineOMAP_USBTLL_REVISION(OMAP_USBHOST_TLL_BASE + 0x00) +#defineOMAP_USBTLL_SYSCONFIG (OMAP_USBHOST_TLL_BASE + 0x10) + #define OMAP_USBTLL_SYSCONFIG_CACTIVITY_SHIFT 8 + #define OMAP_USBTLL_SYSCONFIG_SIDLEMODE_SHIFT 3 + #define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP_SHIFT 2 + #define OMAP_USBTLL_SYSCONFIG_SOFTRESET_SHIFT 1 + #define OMAP_USBTLL_SYSCONFIG_AUTOIDLE_SHIFT0 +#defineOMAP_USBTLL_SYSSTATUS (OMAP_USBHOST_TLL_BASE + 0x14) + #define OMAP_USBTLL_SYSSTATUS_RESETDONE_SHIFT 0 +#defineOMAP_USBTLL_IRQSTATUS (OMAP_USBHOST_TLL_BASE + 0x18) +#defineOMAP_USBTLL_IRQENABLE (OMAP_USBHOST_TLL_BASE + 0x1C) + +#defineOMAP_TLL_SHARED_CONF(OMAP_USBHOST_TLL_BASE + 0x30) + #define OMAP_TLL_SHARED_CONF_USB_90D_DDR_EN_SHFT6 + #define OMAP_TLL_SHARED_CONF_USB_180D_SDR_EN_SHIFT 5 + #define OMAP_TLL_SHARED_CONF_USB_DIVRATION_SHIFT2 + #define OMAP_TLL_SHARED_CONF_FCLK_REQ_SHIFT 1 + #define OMAP_TLL_SHARED_CONF_FCLK_IS_ON_SHIFT 0 + +#defineOMAP_TLL_CHANNEL_CONF(num)\ + (OMAP_USBHOST_TLL_BASE + (0x040 + 0x004 * num)) + #define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF_SHIFT 11 + #define OMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE_SHIFT 10 + #define OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE_SHIFT9 + #define OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE_SHIFT 8 + #define OMAP_TLL_CHANNEL_CONF_CHANEN_SHIFT 0 + +#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x804 + 0x100 * num)) +#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x807 + 0x100 * num)) +#defineOMAP_TLL_ULPI_OTG_CTRL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x80A + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_EN_RISE(num)\ + (OMAP_USBHOST_TLL_BASE + (0x80D + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_EN_FALL(num)\ + (OMAP_USBHOST_TLL_BASE + (0x810 + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_STATUS(num)\ + (OMAP_USBHOST_TLL_BASE + (0x813 + 0x100 * num)) +#defineOMAP_TLL_ULPI_INT_LATCH(num)\ + (OMAP_USBHOST_TLL_BASE + (0x814 + 0x100 * num)) +#defineOMAP_TLL_ULPI_DEBUG(num)\ + (OMAP_USBHOST_TLL_BASE + (0x815 + 0x100 * num)) +#defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num)\ + (OMAP_USBHOST_TLL_BASE + (0x816 + 0x100 * num)) + +#define OMAP_TLL_CHANNEL_COUNT 3 + #define OMAP_TLL_CHANNEL_1_EN_MASK 1 + #define OMAP_TLL_CHANNEL_2_EN_MASK 2 + #define OMAP_TLL_CHANNEL_3_EN_MASK 4 + +/* UHH Register Set */ +#defineOMAP_USBHOST_UHH_BASE (OMAP_USBHOST_BASE + 0x4000) +#defineOMAP_UHH_REVISION (OMAP_USBHOST_UHH_BASE + 0x00) +#defineOMAP_UHH_SYSCONFIG (OMAP_USBHOST_UHH_BASE + 0x10) + #define OMAP_UHH_SYSCONFIG_MIDLEMODE_SHIFT 12 + #define OMAP_UHH_SYSCONFIG_CACTIVITY_SHIFT 8 + #define OMAP_UHH_SYSCONFIG_SIDLEMODE_SHIFT 3 + #define OMAP_UHH_SYSCONFIG_ENAWAKEUP_SHIFT 2 + #define OMAP_UHH_SYSCONFIG_SOFTRESET_SHIFT 1 + #define OMAP_UHH_SYSCONFIG_AUTOIDLE_SHIFT 0 + +#defineOMAP_UHH_SYSSTATUS (OMAP_USBHOST_UHH_BASE + 0x14) +#defineOMAP_UHH_HOSTCONFIG (OMAP_USBHOST_UHH_BASE + 0x40) + #define OMAP_UHH_HOSTCONFIG_ULPI_BYPASS_SHIFT 0 + #define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN_SHIFT2 + #define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN_SHIFT3 + #define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN_SHIFT 4 + #define
[rft/rfc/patch-v2.6.29-rc5+ 18/23] arm: omap: make usb base defines follow trm
Use names closer to what TRM says and define each
block separately so we don't have to use magic constants
anylonger.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
arch/arm/mach-omap2/usb-ehci.c |4 ++--
arch/arm/plat-omap/include/mach/omap34xx.h |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c
index 30e1ad6..6c1a46f 100644
--- a/arch/arm/mach-omap2/usb-ehci.c
+++ b/arch/arm/mach-omap2/usb-ehci.c
@@ -30,8 +30,8 @@
static struct resource ehci_resources[] = {
[0] = {
- .start = OMAP34XX_HSUSB_HOST_BASE + 0x800,
- .end = OMAP34XX_HSUSB_HOST_BASE + 0x800 + SZ_1K - 1,
+ .start = OMAP34XX_EHCI_BASE,
+ .end = OMAP34XX_EHCI_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
[1] = { /* general IRQ */
diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h
b/arch/arm/plat-omap/include/mach/omap34xx.h
index 27a1e45..53630dc 100644
--- a/arch/arm/plat-omap/include/mach/omap34xx.h
+++ b/arch/arm/plat-omap/include/mach/omap34xx.h
@@ -51,8 +51,10 @@
#define OMAP34XX_IC_BASE 0x4820
#define OMAP34XX_IVA_INTC_BASE 0x4000
#define OMAP34XX_HSUSB_OTG_BASE(L4_34XX_BASE + 0xAB000)
-#define OMAP34XX_HSUSB_HOST_BASE (L4_34XX_BASE + 0x64000)
#define OMAP34XX_USBTLL_BASE (L4_34XX_BASE + 0x62000)
+#define OMAP34XX_UHH_CONFIG_BASE (L4_34XX_BASE + 0x64000)
+#define OMAP34XX_OHCI_BASE (L4_34XX_BASE + 0x64400)
+#define OMAP34XX_EHCI_BASE (L4_34XX_BASE + 0x64800)
#define OMAP34XX_SR1_BASE 0x480C9000
#define OMAP34XX_SR2_BASE 0x480CB000
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 12/23] usb: host: ehci: include linux/gpio.h instead
include linux/gpio.h instead of mach/gpio.h Signed-off-by: Felipe Balbi m...@felipebalbi.com --- drivers/usb/host/ehci-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 2fbf377..7f37b5f 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -27,7 +27,7 @@ #include linux/platform_device.h #include linux/clk.h -#include mach/gpio.h +#include linux/gpio.h #include ehci-omap.h -- 1.6.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 11/23] usb: host: ehci: add MODULE_AUTHOR
add missing MODULE_AUTHOR(). No functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index b7f02f6..2fbf377 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -562,4 +562,5 @@ static const struct hc_driver ehci_omap_hc_driver = {
};
MODULE_ALIAS(platform:omap-ehci);
+MODULE_AUTHOR(Texas Instruments, Inc.);
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 11/23] usb: host: ehci: add MODULE_AUTHOR
add missing MODULE_AUTHOR(). No functional changes.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index b7f02f6..2fbf377 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -562,4 +562,5 @@ static const struct hc_driver ehci_omap_hc_driver = {
};
MODULE_ALIAS(platform:omap-ehci);
+MODULE_AUTHOR(Texas Instruments, Inc.);
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 16/23] usb: host: ehci: add platform_data
Adding a platform_data to the driver allow us
to remove some of the ifdeferry in the code.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/usb-ehci.c | 14 +-
arch/arm/plat-omap/include/mach/usb.h| 24 ++-
drivers/usb/host/Kconfig | 19 --
drivers/usb/host/ehci-omap.c | 401 +++---
9 files changed, 241 insertions(+), 227 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 758183c..3f85c6e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -643,7 +643,7 @@ static void __init omap_3430sdp_init(void)
msecure_init();
omap_serial_init();
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
}
static void __init omap_3430sdp_map_io(void)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5f5cc39..18d9a86 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -380,7 +380,7 @@ static void __init omap3_beagle_init(void)
gpio_direction_output(170, true);
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
omap3beagle_flash_init();
}
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 6577726..514058f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -255,7 +255,7 @@ static void __init omap3_evm_init(void)
omap_serial_init();
twl4030_mmc_init(mmc);
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
omap3evm_flash_init();
ads7846_dev_init();
}
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index b8a78c0..08215c0 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -297,7 +297,7 @@ static void __init omap3pandora_init(void)
spi_register_board_info(omap3pandora_spi_board_info,
ARRAY_SIZE(omap3pandora_spi_board_info));
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
omap3pandora_flash_init();
omap3pandora_ads7846_init();
}
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index e5a3412..b51c835 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -246,7 +246,7 @@ static void __init overo_init(void)
omap_serial_init();
twl4030_mmc_init(mmc);
usb_musb_init();
- usb_ehci_init();
+ usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
overo_flash_init();
if ((gpio_request(OVERO_GPIO_W2W_NRESET,
diff --git a/arch/arm/mach-omap2/usb-ehci.c b/arch/arm/mach-omap2/usb-ehci.c
index 23fe857..30e1ad6 100644
--- a/arch/arm/mach-omap2/usb-ehci.c
+++ b/arch/arm/mach-omap2/usb-ehci.c
@@ -145,8 +145,20 @@ static void setup_ehci_io_mux(void)
return;
}
-void __init usb_ehci_init(void)
+void __init usb_ehci_init(enum ehci_hcd_omap_mode phy_mode,
+ int chargepump, int phy_reset, int reset_gpio_port1,
+ int reset_gpio_port2)
{
+ struct ehci_hcd_omap_platform_data pdata = {
+ .phy_mode = phy_mode,
+ .chargepump = chargepump,
+ .phy_reset = phy_reset,
+ .reset_gpio_port1 = reset_gpio_port1,
+ .reset_gpio_port2 = reset_gpio_port2,
+ };
+
+ ehci_device.dev.platform_data = pdata;
+
/* Setup Pin IO MUX for EHCI */
if (cpu_is_omap34xx())
setup_ehci_io_mux();
diff --git a/arch/arm/plat-omap/include/mach/usb.h
b/arch/arm/plat-omap/include/mach/usb.h
index 47aba6b..8a341ca 100644
--- a/arch/arm/plat-omap/include/mach/usb.h
+++ b/arch/arm/plat-omap/include/mach/usb.h
@@ -5,6 +5,22 @@
#include mach/board.h
+enum ehci_hcd_omap_mode {
+ EHCI_HCD_OMAP_MODE_UNKNOWN,
+ EHCI_HCD_OMAP_MODE_PHY,
+ EHCI_HCD_OMAP_MODE_TLL,
+};
+
+struct ehci_hcd_omap_platform_data {
+ enum ehci_hcd_omap_mode phy_mode;
+ unsignedchargepump:1;
+ unsignedphy_reset:1;
+
+ /* have to be valid if phy_reset is true */
+ int reset_gpio_port1;
+ int reset_gpio_port2;
+};
+
[rft/rfc/patch-v2.6.29-rc5+ 22/23] ehci-omap: Remove defines for clock names
From: Tony Lindgren t...@atomide.com
This just makes it harder to figure out the clock names
when reading the code. If the clock change, they should
get set dynamically.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/host/ehci-omap.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e413601..ebfed95 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -163,13 +163,6 @@ struct ehci_hcd_omap {
void __iomem*ehci_base;
};
-/* Clock names as per clock framework: May change so keep as #defs */
-#define USBHOST_ICKL usbhost_ick
-#define USBHOST_120M_FCLK usbhost_120m_fck
-#define USBHOST_48M_FCLK usbhost_48m_fck
-#define USBHOST_TLL_ICKL usbtll_ick
-#define USBHOST_TLL_FCLK usbtll_fck
-
/*-*/
static void omap_usb_utmi_init(struct ehci_hcd_omap *omap, u8 tll_channel_mask)
@@ -265,21 +258,21 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
/* Enable Clocks for USBHOST */
- omap-usbhost_ick = clk_get(omap-dev, USBHOST_ICKL);
+ omap-usbhost_ick = clk_get(omap-dev, usbhost_ick);
if (IS_ERR(omap-usbhost_ick)) {
ret = PTR_ERR(omap-usbhost_ick);
goto err_host_ick;
}
clk_enable(omap-usbhost_ick);
- omap-usbhost2_120m_fck = clk_get(omap-dev, USBHOST_120M_FCLK);
+ omap-usbhost2_120m_fck = clk_get(omap-dev, usbhost_120m_fck);
if (IS_ERR(omap-usbhost2_120m_fck)) {
ret = PTR_ERR(omap-usbhost2_120m_fck);
goto err_host_120m_fck;
}
clk_enable(omap-usbhost2_120m_fck);
- omap-usbhost1_48m_fck = clk_get(omap-dev, USBHOST_48M_FCLK);
+ omap-usbhost1_48m_fck = clk_get(omap-dev, usbhost_48m_fck);
if (IS_ERR(omap-usbhost1_48m_fck)) {
ret = PTR_ERR(omap-usbhost1_48m_fck);
goto err_host_48m_fck;
@@ -297,14 +290,14 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
}
/* Configure TLL for 60Mhz clk for ULPI */
- omap-usbtll_fck = clk_get(omap-dev, USBHOST_TLL_FCLK);
+ omap-usbtll_fck = clk_get(omap-dev, usbtll_fck);
if (IS_ERR(omap-usbtll_fck)) {
ret = PTR_ERR(omap-usbtll_fck);
goto err_tll_fck;
}
clk_enable(omap-usbtll_fck);
- omap-usbtll_ick = clk_get(omap-dev, USBHOST_TLL_ICKL);
+ omap-usbtll_ick = clk_get(omap-dev, usbtll_ick);
if (IS_ERR(omap-usbtll_ick)) {
ret = PTR_ERR(omap-usbtll_ick);
goto err_tll_ick;
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rft/rfc/patch-v2.6.29-rc5+ 23/23] usb: host: ehci: add few comments and todo
Still a few stuff to be done with this driver, so add TODO
for us to keep track of what has to be done still.
Signed-off-by: Felipe Balbi m...@felipebalbi.com
---
drivers/usb/host/ehci-omap.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index ebfed95..ad2a353 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -26,6 +26,14 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
+ * TODO (last updated Feb 23rd, 2009):
+ * - add kernel-doc
+ * - enable AUTOIDLE
+ * - move DPLL5 programming to clock fw
+ * - add suspend/resume
+ * - move workarounds to board-files
+ * - differentiate between ES2.x and ES3.x
+ * - make it enumerate devices
*/
#include linux/platform_device.h
@@ -145,6 +153,15 @@ struct ehci_hcd_omap {
struct clk *usbtll_fck;
struct clk *usbtll_ick;
+ /* FIXME the following two workarounds are
+* board specific not silicon-specific so these
+* should be moved to board-file instead.
+*
+* Maybe someone from TI will know better which
+* board is affected and needs the workarounds
+* to be applied
+*/
+
/* gpio for resetting phy */
int reset_gpio_port1;
int reset_gpio_port2;
--
1.6.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rft/rfc/patch-v2.6.29-rc5+ 21/23] usb: host: ehci: don't ensure register write
On Mon, Feb 23, 2009 at 08:55:33PM +0200, Felipe Balbi wrote:
+#include ../../../arch/arm/mach-omap2/cm-regbits-34xx.h
+
/* omap_start_ehc
* - Start the TI USBHOST controller
*/
@@ -274,32 +258,11 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
PLL_MOD, OMAP3430ES2_CM_CLKEN2);
while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2)
- OMAP3430ES2_ST_PERIPH2_CLK_MASK)) {
+ OMAP3430ES2_ST_PERIPH2_CLK_MASK))
dev_dbg(omap-dev, idlest2 = 0x%x\n,
cm_read_mod_reg(PLL_MOD, CM_IDLEST2));
-
- if (time_after(timeout, jiffies)) {
- dev_dbg(omap-dev, operation timed out\n);
- ret = -EINVAL;
- goto err_idlest2;
- }
- }
/* End DPLL5 programming */
Hi Paul, could you look at how could we move dpll5 programming to clk
fw? This driver shouldn't have such code. Also, I guess this programming
is not right since I hear this driver doesn't enumerate anything.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rft/rfc/patch-v2.6.29-rc5+ 00/23] ehci cleanup series
On Mon, Feb 23, 2009 at 08:55:12PM +0200, Felipe Balbi wrote: Hi all, Please give the following patches a good test. I don't have hw to test them so any comments will be really welcome. We still have lots to do before getting this driver upstream, let's try to keep track of our TODO list and get this driver in mainline for 2.6.31 merge window (2.6.30 is too close already). Let's not try to push this driver until ES2.x and ES3.x are fully supported, that will probably have to be done by an omap_rev check in ehci-omap driver, also, this driver doesn't really enumerate any attached devices, but that's old problem as Tony told me off list. Anyways, I guess this driver is finally walking. Me and Anand (and anyone interested) will be discussing how to get EHCI and OHCI working fine, I'm guessing we won't have really big issues with OHCI but you never know. Again, please give it a good test, see if you don't have any clock issues, NULL pointers, check if the error path is really fine, see if VBUS turns on or not, as I said, *I HAVE NO HW TO TEST THESE* thanks in advance for those who will read/test/comment these patches btw, rebase version of these patches are at: git://gitorious.org/musb/mainline.git branch ehci -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: PM: Update voltage levels for OPP1/2 on VDD1/2
Nayak, Rajendra rna...@ti.com writes:
This patch updates the voltage levels for VDD1 OPP1/2 and
VDD2 OPP1/2 according to the latest operating condition
addendum for 3430.
The new voltage levels at various OPP's for VDD1/2 are as below
VDD1 OPP1 0.975v
VDD1 OPP2 1.050v
VDD1 OPP3 1.200v
VDD1 OPP4 1.270v
VDD1 OPP5 1.350v
VDD2 OPP1 0.975v
VDD2 OPP2 1.050v
VDD2 OPP3 1.150v
The patch applies on the latest pm head and is validated on 3430SDP.
This didn't apply to latest PM branch due to changes in the regbits
header. I manually fixed this up and applied to PM branch.
Thanks,
Kevin
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap3-opp.h| 12 ++--
arch/arm/mach-omap2/prm-regbits-34xx.h |8
2 files changed, 10 insertions(+), 10 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/omap3-opp.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/omap3-opp.h 2009-02-13
09:28:45.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/omap3-opp.h2009-02-13
09:37:35.767125634 +0530
@@ -24,9 +24,9 @@
static struct omap_opp omap3_mpu_rate_table[] = {
{0, 0, 0},
/*OPP1*/
- {S125M, VDD1_OPP1, 0x18},
+ {S125M, VDD1_OPP1, 0x1E},
/*OPP2*/
- {S250M, VDD1_OPP2, 0x20},
+ {S250M, VDD1_OPP2, 0x24},
/*OPP3*/
{S500M, VDD1_OPP3, 0x30},
/*OPP4*/
@@ -38,9 +38,9 @@ static struct omap_opp omap3_mpu_rate_ta
static struct omap_opp omap3_l3_rate_table[] = {
{0, 0, 0},
/*OPP1*/
- {0, VDD2_OPP1, 0x18},
+ {0, VDD2_OPP1, 0x1E},
/*OPP2*/
- {S83M, VDD2_OPP2, 0x20},
+ {S83M, VDD2_OPP2, 0x24},
/*OPP3*/
{S166M, VDD2_OPP3, 0x2C},
};
@@ -48,9 +48,9 @@ static struct omap_opp omap3_l3_rate_tab
static struct omap_opp omap3_dsp_rate_table[] = {
{0, 0, 0},
/*OPP1*/
- {S90M, VDD1_OPP1, 0x18},
+ {S90M, VDD1_OPP1, 0x1E},
/*OPP2*/
- {S180M, VDD1_OPP2, 0x20},
+ {S180M, VDD1_OPP2, 0x24},
/*OPP3*/
{S360M, VDD1_OPP3, 0x30},
/*OPP4*/
Index: linux-omap-2.6/arch/arm/mach-omap2/prm-regbits-34xx.h
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/prm-regbits-34xx.h
2009-02-13 09:26:16.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/prm-regbits-34xx.h 2009-02-13
10:12:07.005364895 +0530
@@ -464,14 +464,14 @@
/* PRM_VC_CMD_VAL_0 specific bits */
#define OMAP3430_VC_CMD_VAL0_ON (0x3 4)
-#define OMAP3430_VC_CMD_VAL0_ONLP(0x3 3)
-#define OMAP3430_VC_CMD_VAL0_RET (0x3 3)
+#define OMAP3430_VC_CMD_VAL0_ONLP(0xF 1)
+#define OMAP3430_VC_CMD_VAL0_RET (0xF 1)
#define OMAP3430_VC_CMD_VAL0_OFF (0x3 4)
/* PRM_VC_CMD_VAL_1 specific bits */
#define OMAP3430_VC_CMD_VAL1_ON (0xB 2)
-#define OMAP3430_VC_CMD_VAL1_ONLP(0x3 3)
-#define OMAP3430_VC_CMD_VAL1_RET (0x3 3)
+#define OMAP3430_VC_CMD_VAL1_ONLP(0xF 1)
+#define OMAP3430_VC_CMD_VAL1_RET (0xF 1)
#define OMAP3430_VC_CMD_VAL1_OFF (0xB 2)
/* PRM_VC_CH_CONF */--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Tuesday 10 February 2009, Mark Brown wrote: What I would suggest that you do for this is submit a patch allowing the regulators to supply a set of constraints when they register (but not doing anything with them), That pretty much needs to allow a list of discrete voltages, not just be a range ... and have a way for clients to retrieve that list. Else I have a very hard time imagining how to plug in MMC supplies without writing the type of regulator-specific code that this framework is intended to supplant. another with a TWL4030 driver using that API and a third patch making the core do something with that data. Best IMO to switch the last two around. Effectively there'd be one patch add new features to regulator core, followed by the first of a set of implement those new features in the driver for regulator X. And in fact that's what I've done with the two patches I'll be sending in a moment. This would result in something which maintains consistent behaviour over all regulator drivers, It's already consistent, even without such patches!! There is no driver which pays attention to regulator(_dev) constraints that does it any differently than this one. Your current patch does also set constraints for the voltages if they weren't there previously I was thinking that boards which don't need constraints shouldn't need to create any ... they could just pass on the capabilities of the underlying regulator. For safety the regulator API won't do anything without being explicitly told that it's OK to do so - if we were to do this we'd need to have an explicit flag in the constraints which says that this is what to do. Constraints are also permission grants. I like to avoid flags unless they're absolutely required. In this case my initial reaction is to say that hooking up the components in the first place was the permission grant. Only when that system is componentized that way. Not all are. Modular systems can have plug-in regulator boards; constraints on a mainboard would necessarily overlap with supported regulator boards ... but the regulators themselves would naturally have different constraints. Indeed. Like I say, a very large proportion of the development of the regulator API has been done on reference designs which are built in this fashion, including both pluggable PMIC boards and other daughtercards. That doesn't seem to have escaped its development cage yet. ;) Normally the primary PMIC cards are handled with conditional code in the machine file (either compile time or run time) or by registering drivers for all the PMICs and allowing failed device probes to sort everything out. So far handling things this way hasn't been a big deal - there are usually relatively few PMIC boards out there for a given platform and the PMIC itself is rarely a major restriction. Fair enough. I'd de-emphasize conditional, since that sounds way too much like #ifdeffing. The source code should just call something like is_pmic_cardX(), and not care how that works. One way to view this: what you're calling regulator constraints are really coming from the machine. Yes, of course. The constraints are applied to the regulator by the core, they are constraints for the regulator not constraints imposed by the regulator. Then what would you call constraints by/from the regulator? I suggest updating your terminology. machine constraints would be much more clear for what's there now: they relate to the machine. Other constraints (regulator, consumer) relate to the other components ... the ones for which they are an adjective. Those few lines of code that seem to bother you are only recognizing that they are, in fact, two very different entities. What's really bothering me is the *location* of the code. As I've said, my primary concern is that this introduces what are effectively API changes which will mean that this driver behaves differently to other drivers. Other concerns about precisely what we do with any information from the regulator driver are very much less important. I don't mind moving it ... later, after the regulator core has proper support for decoupling machine-specific constraints from regulator-specific ones. I view that code as a workaround for a current limitation of that core, so like all such workarounds it should vanish when it's no longer relevant. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch/rfc 2.6.29-rc6 1/2] regulator: enumerate voltages
From: David Brownell dbrown...@users.sourceforge.net
Add a basic mechanism for regulators to report the discrete
voltages they support: one method to count how many voltages
are available, and another to enumerate them.
Use those methods to force machine-level constraints into bounds.
(Example: regulator supports 1.8V, 2.4V, 2.6V, 3.3V, and board
constraints for that rail are 2.0V to 3.6V ... so the range of
voltages is then 2.4V to 3.3V on this board.)
Export those voltages to the regulator consumer interface, so for
example regulator hooked up to an MMC/SD/SDIO slot can report the
actual voltage options available to cards connected there.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
I'm not particularly pleased with these names; suggestions?
This could also be done with one fewer method by designating a
special list_voltage() return value, but I like this better.
drivers/regulator/core.c | 107 +++
include/linux/regulator/consumer.h |2
include/linux/regulator/driver.h | 10 +++
3 files changed, 119 insertions(+)
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -719,6 +719,44 @@ static int set_machine_constraints(struc
else
name = regulator;
+ /* maybe force machine-wide voltage constraints to match the
+* voltages supported by this regulator. use the regulator's
+* entire range for boards with no particular constraints.
+*/
+ if (ops-list_voltage) {
+ int count = ops-count_voltages(rdev);
+ int i;
+ int min_uV = INT_MAX;
+ int max_uV = INT_MIN;
+ int cmin = constraints-min_uV ? : INT_MIN;
+ int cmax = constraints-max_uV ? : INT_MAX;
+
+ /* initial: [cmin..cmax] valid, [min_uV..max_uV] not */
+ for (i = 0; i count; i++) {
+ int value;
+
+ value = ops-list_voltage(rdev, i);
+ if (value = 0)
+ continue;
+
+ /* maybe adjust [min_uV..max_uV] */
+ if (value = cmin value min_uV)
+ min_uV = value;
+ if (value = cmax value max_uV)
+ max_uV = value;
+ }
+
+ /* final: [min_uV..max_uV] valid iff constraints valid */
+ if (max_uV min_uV) {
+ pr_err(%s: bad '%s' voltage constraints\n,
+ __func__, name);
+ ret = -EINVAL;
+ goto out;
+ }
+ constraints-min_uV = min_uV;
+ constraints-max_uV = max_uV;
+ }
+
rdev-constraints = constraints;
/* do we need to apply the constraint voltage */
@@ -1245,6 +1283,75 @@ int regulator_is_enabled(struct regulato
EXPORT_SYMBOL_GPL(regulator_is_enabled);
/**
+ * regulator_count_voltages - count regulator_list_voltage() indices
+ * @regulator: regulator source
+ *
+ * Returns number of indices, or negative errno.
+ */
+int regulator_count_voltages(struct regulator *regulator)
+{
+ struct regulator_dev*rdev = regulator-rdev;
+ struct regulator_ops*ops;
+ int ret = -EINVAL;
+
+ mutex_lock(rdev-mutex);
+
+ ops = rdev-desc-ops;
+ if (ops-count_voltages)
+ ret = ops-count_voltages(rdev);
+
+ mutex_unlock(rdev-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(regulator_count_voltages);
+
+/**
+ * regulator_list_voltage - enumerate supported voltages
+ * @regulator: regulator source
+ * @index: identify voltage to list
+ *
+ * Returns a voltage that can be passed to @regulator_set_voltage(),
+ * or negative fault code.
+ *
+ * Faults include passing in invalid index, and using an index
+ * corresponding to a voltage that can't be used on this system.
+ */
+int regulator_list_voltage(struct regulator *regulator, unsigned index)
+{
+ struct regulator_dev*rdev = regulator-rdev;
+ struct regulator_ops*ops;
+ int ret = -EINVAL;
+
+ mutex_lock(rdev-mutex);
+
+ ops = rdev-desc-ops;
+ if (ops-count_voltages ops-list_voltage)
+ ret = ops-count_voltages(rdev);
+
+ if (ret == 0)
+ ret = -EIO;
+ else if (ret 0) {
+ if (index = ret)
+ ret = -EDOM;
+ else
+ ret = ops-list_voltage(rdev, index);
+ }
+
+ if (ret = 0) {
+ if (ret rdev-constraints-min_uV)
+ ret = -ERANGE;
+ else if (ret rdev-constraints-max_uV)
+ ret = -ERANGE;
+ }
+
+ mutex_unlock(rdev-mutex);
+
+ return ret;
+}
[patch/rfc 2.6.29-rc6 2/2] regulator: twl4030 voltage enumeration
From: David Brownell dbrown...@users.sourceforge.net
Update previously-posted twl4030 regulator driver to export
supported voltages to upper layers using a new mechanism.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/regulator/twl4030-regulator.c | 72 ++--
1 file changed, 33 insertions(+), 39 deletions(-)
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -42,7 +42,6 @@ struct twlreg_info {
/* chip constraints on regulator behavior */
u16 min_mV;
- u16 max_mV;
/* used by regulator core */
struct regulator_desc desc;
@@ -262,6 +261,24 @@ static const u16 VDAC_VSEL_table[] = {
};
+static int twl4030ldo_count_voltages(struct regulator_dev *rdev)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ return info-table_len ? : 1;
+}
+
+static int twl4030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int mV;
+
+ mV = info-table[index];
+ if (IS_UNSUP(mV))
+ return -ESRCH;
+ return LDO_MV(mV) * 1000;
+}
+
static int
twl4030ldo_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV)
{
@@ -276,6 +293,8 @@ twl4030ldo_set_voltage(struct regulator_
continue;
uV = LDO_MV(mV) * 1000;
+ /* REVISIT for VAUX2, first match may not be best/lowest */
+
/* use the first in-range value */
if (min_uV = uV uV = max_uV)
return twl4030reg_write(info, VREG_DEDICATED, vsel);
@@ -297,6 +316,9 @@ static int twl4030ldo_get_voltage(struct
}
static struct regulator_ops twl4030ldo_ops = {
+ .count_voltages = twl4030ldo_count_voltages,
+ .list_voltage = twl4030ldo_list_voltage,
+
.set_voltage= twl4030ldo_set_voltage,
.get_voltage= twl4030ldo_get_voltage,
@@ -314,6 +336,13 @@ static struct regulator_ops twl4030ldo_o
/*
* Fixed voltage LDOs don't have a VSEL field to update.
*/
+static int twl4030fixed_list_voltage(struct regulator_dev *rdev, unsigned
index)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ return info-min_mV * 1000;
+}
+
static int twl4030fixed_get_voltage(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -322,6 +351,9 @@ static int twl4030fixed_get_voltage(stru
}
static struct regulator_ops twl4030fixed_ops = {
+ .count_voltages = twl4030ldo_count_voltages,
+ .list_voltage = twl4030fixed_list_voltage,
+
.get_voltage= twl4030fixed_get_voltage,
.enable = twl4030reg_enable,
@@ -353,7 +385,6 @@ static struct regulator_ops twl4030fixed
.base = offset, \
.id = num, \
.min_mV = mVolts, \
- .max_mV = mVolts, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -402,14 +433,11 @@ static int twl4030reg_probe(struct platf
struct regulator_init_data *initdata;
struct regulation_constraints *c;
struct regulator_dev*rdev;
- int min_uV, max_uV;
for (i = 0, info = NULL; i ARRAY_SIZE(twl4030_regs); i++) {
if (twl4030_regs[i].desc.id != pdev-id)
continue;
info = twl4030_regs + i;
- min_uV = info-min_mV * 1000;
- max_uV = info-max_mV * 1000;
break;
}
if (!info)
@@ -423,10 +451,6 @@ static int twl4030reg_probe(struct platf
* this driver and the chip itself can actually do.
*/
c = initdata-constraints;
- if (!c-min_uV || c-min_uV min_uV)
- c-min_uV = min_uV;
- if (!c-max_uV || c-max_uV max_uV)
- c-max_uV = max_uV;
c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
| REGULATOR_CHANGE_MODE
@@ -471,36 +495,6 @@ static struct platform_driver twl4030reg
static int __init twl4030reg_init(void)
{
- unsigned i, j;
-
- /* determine min/max voltage constraints, taking into account
-* whether set_voltage() will use the unsupported settings
-*/
- for (i = 0; i ARRAY_SIZE(twl4030_regs); i++) {
- struct twlreg_info *info = twl4030_regs + i;
- const u16 *table;
-
- /* fixed-voltage regulators */
- if (!info-table_len)
- continue;
-
- /* LDO regulators: */
- for (j = 0, table = info-table;
- j info-table_len;
- j++, table++) {
-
Re: leds-gpio broken with current git?
On Monday 23 February 2009, Kridner, Jason wrote: Works for me, no -EINVAL, on 2.6.28-omap1 and no patches that should affect GPIOs or LEDs. Last patch applied to GIT is 15f75b6226c2d3b82062bb721e7cb9a1d6f35efd (musbhsdma). OK, I'm just pulling a new batch of objects, I'm guessing Tony snuck in RC1 already ... yes, I see he just sent a post about that a few minutes ago. ;) Perhaps something broke with Tony's RC1 merge? The LEDs are broken for me as well. Still works for me. Did you maybe not enable the twl4030 GPIO support in Kconfig? - dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Mon, Feb 23, 2009 at 12:45:44PM -0800, David Brownell wrote: another with a TWL4030 driver using that API and a third patch making the core do something with that data. Best IMO to switch the last two around. Effectively there'd be one patch add new features to regulator core, followed by the first of a set of implement those new features in the driver for regulator X. And in fact that's what I've done with the two patches I'll be sending in a moment. The reason I'm suggesting splitting things up the way I am is that it separates out the TWL4030 driver (which looks very mergable to me right now) from the behaviour changes. Ordering things that way makes it clear what the dependency is. Another way of splitting it out would be to remove the new API from the TWL4030, make that the first patch, then have further patches adding the new API and the TWL4030 code to use it. I don't see any reason why the TWL4030 regulator support needs to be blocked on adding the new API and it makes review easier to keep them separate. This would result in something which maintains consistent behaviour over all regulator drivers, It's already consistent, even without such patches!! There is no driver which pays attention to regulator(_dev) constraints that does it any differently than this one. That's because nobody's doing it at all; once we add a custom implementation in one driver we then need to police each driver individually for consistency with the new interface. If the logic is factored out then that problem doesn't exist and drivers don't need to reimplement any of it. Your current patch does also set constraints for the voltages if they weren't there previously I was thinking that boards which don't need constraints shouldn't need to create any ... they could just pass on the capabilities of the underlying regulator. For safety the regulator API won't do anything without being explicitly told that it's OK to do so - if we were to do this we'd need to have an explicit flag in the constraints which says that this is what to do. Constraints are also permission grants. I like to avoid flags unless they're absolutely required. In this case my initial reaction is to say that hooking up the components in the first place was the permission grant. The trouble is we don't know what's connected to the regulator without being told - even if some of the components hanging off the supply are visible to software that's no guarantee that all of them are. Keeping the responsibility in the hands of the machine driver helps ensure that users have made a concious decision that their settings are OK for their design. Indeed. Like I say, a very large proportion of the development of the regulator API has been done on reference designs which are built in this fashion, including both pluggable PMIC boards and other daughtercards. That doesn't seem to have escaped its development cage yet. ;) There's a couple on their way to mainline right now, should make it in the next merge window hopefully. Unfortunately they're for systems that aren't very completely supported in mainline right now which makes them less useful as examples than they might be. There's also none of them where there's any immediate prospect of more than one of the PMIC board options going into mainline. Normally the primary PMIC cards are handled with conditional code in the machine file (either compile time or run time) or by registering drivers Fair enough. I'd de-emphasize conditional, since that sounds way too much like #ifdeffing. The source code should just call something like is_pmic_cardX(), and not care how that works. It's normally a combination of the two - normally you don't get any form of board ID readback and you get things like mutually exclusive options for I2C or SPI control due to shared multi function pin setup that can't be autoprobed entirely safely, for example. Once you've decided on the control bus it's normally safe to do autoprobing, though. Then what would you call constraints by/from the regulator? They're subsumed within the constraints supplied by the machine driver at the minute. I suggest updating your terminology. machine constraints would be much more clear for what's there now: they relate to the machine. Other constraints (regulator, consumer) relate to the other components ... the ones for which they are an adjective. Yeah, I kind of agree. To avoid confusion from changing the names I'd be tempted to go for something like regulator driver constraints but it's not desparately nice. I don't mind moving it ... later, after the regulator core has proper support for decoupling machine-specific constraints from regulator-specific ones. I view that code as a workaround for a current limitation of that core, so like all such workarounds it should vanish when it's no longer relevant. I'd strongly suggest that if you're adding
Re: [PATCH 2/3] usb: musb: fix bug in musb_start_urb
On Friday 06 February 2009, Sergei Shtylyov 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) actual_length may not be zero. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com NAK, this is not a problem for the current driver since URBs do not ever get restarted. Resolvable by changing the patch description to not say this is a fix. However, since this is a two line change, I think I'll just merge this with the patch adding the bulk RX retry logic. Also, musb_host_tx() doesn't update urb-actual_length -- please fix it too. That would be a good point if the retry patch touched any TX paths. But it doesn't. Also, you must not clear qh-iso_idx when restarting -- you must not start ISO transfer all over again too. Also, you should not set musb-ep0_state to MUSB_EP0_START again in this case (I agree that control transfers will remain not restartable from an arbitatry place even then). But the [3/3] patch only adds NAK timeout support for bulk RX. And ISO transfers can't NAK in the first place. Plus, as noted in a comment you could see in this patch, this only touches (re)start for bulk/interrupt transfers. Not ISO; not control. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/4] dsp-bridge: cleanup and remove HW_MBOX_IsFull
Hi Felipe,
HW_MBOX_IsFull has many convoluted macros and is used only once. Clean
it up so it's easier to see what it's actually doing.
-- Is this the reason you added a new function that checks if fifo is full or
is there any issue with the existing function ?
Thank you,
Best regards,
Hari
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, February 22, 2009 3:32 AM
To: linux-omap@vger.kernel.org
Cc: Hiroshi DOYU; Kanigeri, Hari; ameya.pala...@nokia.com; Felipe
Contreras
Subject: [PATCH v2 3/4] dsp-bridge: cleanup and remove HW_MBOX_IsFull
HW_MBOX_IsFull has many convoluted macros and is used only once. Clean
it up so it's easier to see what it's actually doing.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/hw/hw_mbox.c| 25 -
drivers/dsp/bridge/hw/hw_mbox.h| 35 ---
drivers/dsp/bridge/wmd/tiomap_sm.c | 15 +--
3 files changed, 9 insertions(+), 66 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c
b/drivers/dsp/bridge/hw/hw_mbox.c
index 2c14ade..31b890a 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -104,31 +104,6 @@ HW_STATUS HW_MBOX_MsgWrite(const u32 baseAddress,
const HW_MBOX_Id_t mailBoxId,
return status;
}
-/* Reads the full status register for mailbox. */
-HW_STATUS HW_MBOX_IsFull(const u32 baseAddress, const HW_MBOX_Id_t
mailBoxId,
- u32 *const pIsFull)
-{
- HW_STATUS status = RET_OK;
- u32 fullStatus;
-
- /* Check input parameters */
- CHECK_INPUT_PARAM(baseAddress, 0, RET_BAD_NULL_PARAM, RES_MBOX_BASE
+
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_PARAM(pIsFull, NULL, RET_BAD_NULL_PARAM, RES_MBOX_BASE
+
- RES_INVALID_INPUT_PARAM);
- CHECK_INPUT_RANGE_MIN0(mailBoxId, HW_MBOX_ID_MAX, RET_INVALID_ID,
- RES_MBOX_BASE + RES_INVALID_INPUT_PARAM);
-
- /* read the is full status parameter for Mailbox */
- fullStatus =
MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress,
- (u32)mailBoxId);
-
- /* fill in return parameter */
- *pIsFull = (fullStatus 0xFF);
-
- return status;
-}
-
/* Gets number of messages in a specified mailbox. */
HW_STATUS HW_MBOX_NumMsgGet(const u32 baseAddress, const HW_MBOX_Id_t
mailBoxId,
u32 *const pNumMsg)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h
b/drivers/dsp/bridge/hw/hw_mbox.h
index 225fb40..d2981d3 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -130,41 +130,6 @@ extern HW_STATUS HW_MBOX_MsgWrite(
);
/*
-* FUNCTION : HW_MBOX_IsFull
-*
-* INPUTS:
-*
-* Identifier : baseAddress
-* Type : const u32
-* Description : Base Address of instance of Mailbox module
-*
-* Identifier : mailBoxId
-* Type : const HW_MBOX_Id_t
-* Description : Mail Box Sub module Id to check
-*
-* OUTPUTS:
-*
-* Identifier : pIsFull
-* Type : u32 *const
-* Description : false means mail box not Full
-* true means mailbox full.
-*
-* RETURNS:
-*
-* Type : ReturnCode_t
-* Description : RET_OK No errors occured
-* RET_BAD_NULL_PARAM Address/pointer Paramater was set to
0/NULL
-* RET_INVALID_ID Invalid Id used
-*
-* PURPOSE: : this function reads the full status register for
mailbox.
-*/
-extern HW_STATUS HW_MBOX_IsFull(
- const u32 baseAddress,
- const HW_MBOX_Id_t mailBoxId,
- u32 *constpIsFull
- );
-
-/*
* FUNCTION : HW_MBOX_NumMsgGet
*
* INPUTS:
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index 2f381c8..4ad893b 100644
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -156,6 +156,13 @@ DSP_STATUS CHNLSM_DisableInterrupt(struct
WMD_DEV_CONTEXT *hDevContext)
return status;
}
+#define MAILBOX_FIFOSTATUS(m) (0x80 + 4 * (m))
+
+static inline unsigned int fifo_full(void __iomem *mbox_base, int
mbox_id)
+{
+ return __raw_readl(mbox_base + MAILBOX_FIFOSTATUS(mbox_id)) 0x1;
+}
+
/*
* CHNLSM_InterruptDSP
* Send an interrupt to the DSP processor(s).
@@ -171,7 +178,6 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
u32 opplevel = 0;
#endif
HW_STATUS hwStatus;
- u32 mbxFull;
struct CFG_HOSTRES resources;
u16 cnt = 10;
u32 temp;
@@ -214,12 +220,9 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
pDevContext-dwBrdState = BRD_RUNNING;
}
while (--cnt) {
- hwStatus =
Re: leds-gpio broken with current git?
On Monday 23 February 2009, David Brownell wrote:
Perhaps something broke with Tony's RC1 merge?
The LEDs are broken for me as well.
Still works for me. Did you maybe not enable the twl4030
GPIO support in Kconfig?
Oh, and if you did *not*, please give this patch a try.
I've been meaning to test it.
- Dave
==
Sometimes it's awkward to make sure that the array in the
platform_data handed to the leds-gpio driver has only valid
data ... some leds may not be always available, and coping
with that currently requires patching or rebuilding the array.
This patch fixes that by making it be OK to pass an invalid
GPIO (such as -EINVAL) ... such table entries are skipped.
---
drivers/leds/leds-gpio.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -90,13 +90,19 @@ static int gpio_led_probe(struct platfor
cur_led = pdata-leds[i];
led_dat = leds_data[i];
+ /* skip leds that aren't available */
+ led_dat-gpio = cur_led-gpio;
+ if (!gpio_is_valid(led_dat-gpio)) {
+ dev_dbg(pdev-dev, skipping %s\n, cur_led-name);
+ continue;
+ }
+
ret = gpio_request(cur_led-gpio, cur_led-name);
if (ret 0)
goto err;
led_dat-cdev.name = cur_led-name;
led_dat-cdev.default_trigger = cur_led-default_trigger;
- led_dat-gpio = cur_led-gpio;
led_dat-can_sleep = gpio_cansleep(cur_led-gpio);
led_dat-active_low = cur_led-active_low;
if (pdata-gpio_blink_set) {
@@ -125,6 +131,8 @@ static int gpio_led_probe(struct platfor
err:
if (i 0) {
for (i = i - 1; i = 0; i--) {
+ if (!gpio_is_valid(leds_data[i].gpio))
+ continue;
led_classdev_unregister(leds_data[i].cdev);
cancel_work_sync(leds_data[i].work);
gpio_free(leds_data[i].gpio);
@@ -145,6 +153,8 @@ static int __devexit gpio_led_remove(str
leds_data = platform_get_drvdata(pdev);
for (i = 0; i pdata-num_leds; i++) {
+ if (!gpio_is_valid(leds_data[i].gpio))
+ continue;
led_classdev_unregister(leds_data[i].cdev);
cancel_work_sync(leds_data[i].work);
gpio_free(leds_data[i].gpio);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Configuring a TWL GPIO pin as an interrupt
On Sunday 22 February 2009, Lopez Cruz, Misael wrote: In the particular case of ALSA SoC, could the machine/board driver be a better place to handle all GPIO/IRQ configuration? That driver also contains only board specific code. It'd be best of the ASoC stuff could sit with all the other board-specfic init code, in arch/*/mach-*/board-*.c files, but I understand those interfaces are not yet stable enough to support that ... that's why they're in sound/soc/*/*.c files instead. In any case ... everything I said still stands. If you're doing this for ASoC, you'll need some way to pass data to the ASoC board-specific code from normal board-specific code, since some of the relevant config data is not static. I think that if I move the platform_device registration from machine driver to board file I can append jack detection information (gpio pin, irq) through platform_data of dev field in platform_device structure. And then in the probe part in ASoC machine driver I can receive it. Could that be correct? Any other better/standard option? The current ASoC model seems to be biased towards static configurations. Notice how it's got to create its own platform_device nodes ... it can't easily use the standard mechanisms for associating platform_data or archdata with those nodes, ditto clocks.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Configuring a TWL GPIO pin as an interrupt
On Mon, Feb 23, 2009 at 04:11:04PM -0600, Lopez Cruz, Misael wrote: [Please fix your mail client to wrap lines at ~80 characters, it makes your mails much easier to work with.] I think that if I move the platform_device registration from machine driver to board file I can append jack detection information (gpio pin, irq) through platform_data of dev field in platform_device structure. And then in the probe part in ASoC machine driver I can receive it. Yes, though unless you actually have a generic ASoC machine driver that works over multiple boards it's as well just skipping the platform data. Look at s3c24xx_uda134x for an example of doing this. If these are CPU side GPIOs that you're talking about you'll also want to write the standard utility for using gpiolib for jack detection that I've not got round to doing yet :) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/4] dsp-bridge: remove UTIL_Wait wrapper
Looks good.
We will do some internal validation and push this change to omapzoom tree.
Thank you,
Best regards,
Hari
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, February 22, 2009 3:32 AM
To: linux-omap@vger.kernel.org
Cc: Hiroshi DOYU; Kanigeri, Hari; ameya.pala...@nokia.com; Felipe
Contreras
Subject: [PATCH v2 2/4] dsp-bridge: remove UTIL_Wait wrapper
Wrappers only hurt readability, use native kernel functions instead
(udelay, mdelay).
Also remove useless defines.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/util.h | 33 --
-
drivers/dsp/bridge/wmd/_tiomap_pwr.h|4 ---
drivers/dsp/bridge/wmd/_tiomap_util.h |1 -
drivers/dsp/bridge/wmd/tiomap3430.c | 10
drivers/dsp/bridge/wmd/tiomap3430_pwr.c |4 +-
drivers/dsp/bridge/wmd/tiomap_sm.c |4 +-
6 files changed, 9 insertions(+), 47 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/util.h b/arch/arm/plat-
omap/include/dspbridge/util.h
index 9d8842a..e6815ca 100644
--- a/arch/arm/plat-omap/include/dspbridge/util.h
+++ b/arch/arm/plat-omap/include/dspbridge/util.h
@@ -26,7 +26,6 @@
* UTIL_Exit
* UTIL_GetSysInfo
* UTIL_Init
- * UTIL_Wait
*/
#ifndef _UTIL_H
@@ -120,36 +119,4 @@
return true;
}
-/*
- * UTIL_Wait
- * Purpose:
- * This fucntion busy waits given a certain number of micro seconds
- * independent of the processor speed. This is acheived by the
- * OEM functions QueryPerformanceCounter and
QueryPerformanceFrequency.
- * Parameters:
- * u32 Number of Micro seconds to busy wait
- * Returns:
- * Nothing
- * Requires:
- * UTIL_Initalized.
- * Ensures:
- * Busy waits x Micro seconds or Sleeps X milli seconds; in that
- * case, it is a blocking call there will be a context switching
- * hence it may not represent the absolute busy wait time.
- */
- static inline void UTIL_Wait(IN u32 dwMicroSeconds)
- {
- if (dwMicroSeconds / 1000 = 1) {
- /* = 1 millisecond delay */
- udelay(dwMicroSeconds);
- } else if (dwMicroSeconds * HZ / 100 = 1) {
- /* = 10 millisecond delay */
- mdelay(dwMicroSeconds / 1000);
- } else {
- /* 10 millisecond delay */
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(dwMicroSeconds * HZ / 100);
- }
- }
-
#endif /* _UTIL_H */
diff --git a/drivers/dsp/bridge/wmd/_tiomap_pwr.h
b/drivers/dsp/bridge/wmd/_tiomap_pwr.h
index 15ff2d3..8a7cf1b 100644
--- a/drivers/dsp/bridge/wmd/_tiomap_pwr.h
+++ b/drivers/dsp/bridge/wmd/_tiomap_pwr.h
@@ -28,10 +28,6 @@
#ifndef _TIOMAP_PWR_
#define _TIOMAP_PWR_
-/* Wait time between MBX and IDLE checks for PWR */
-#define PWR_WAIT_USECS 500
-#define PWR_WAIT_MSECS 50
-
/*
* WakeDSP =
* Wakes up the DSP from DeepSleep
diff --git a/drivers/dsp/bridge/wmd/_tiomap_util.h
b/drivers/dsp/bridge/wmd/_tiomap_util.h
index b655409..47e1e5d 100644
--- a/drivers/dsp/bridge/wmd/_tiomap_util.h
+++ b/drivers/dsp/bridge/wmd/_tiomap_util.h
@@ -30,7 +30,6 @@
/* Time out Values in uSeconds*/
#define TIHELEN_ACKTIMEOUT 1
-#define TIHELEN_WRITE_DELAY 10
/* Time delay for HOM-SAM transition. */
#define WAIT_SAM 100 /* in usec (1000 millisec) */
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index 94ad786..670ca14 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -459,9 +459,9 @@ static DSP_STATUS WMD_BRD_Start(struct WMD_DEV_CONTEXT
*hDevContext,
/* Reset and Unreset the RST2, so that BOOTADDR is copied to
* IVA2 SYSC register */
HW_RST_Reset(resources.dwPrmBase, HW_RST2_IVA2);
- UTIL_Wait(100);
+ udelay(100);
HW_RST_UnReset(resources.dwPrmBase, HW_RST2_IVA2);
- UTIL_Wait(100);
+ udelay(100);
DBG_Trace(DBG_LEVEL6, WMD_BRD_Start 0 ** \n);
GetHWRegs(resources.dwPrmBase, resources.dwCmBase);
/* Disbale the DSP MMU */
@@ -736,7 +736,7 @@ static DSP_STATUS WMD_BRD_Stop(struct WMD_DEV_CONTEXT
*hDevContext)
IO_InterruptDSP2(pDevContext, MBX_PM_DSPIDLE);
- UTIL_Wait(1); /* 10 msec */
+ mdelay(10);
GetHWRegs(resources.dwPrmBase, resources.dwCmBase);
@@ -1052,7 +1052,7 @@ static DSP_STATUS WMD_DEV_Create(OUT struct
WMD_DEV_CONTEXT
Re: [PATCH v2 3/4] dsp-bridge: cleanup and remove HW_MBOX_IsFull
On Tue, Feb 24, 2009 at 12:06 AM, Kanigeri, Hari h-kanige...@ti.com wrote: Hi Felipe, HW_MBOX_IsFull has many convoluted macros and is used only once. Clean it up so it's easier to see what it's actually doing. -- Is this the reason you added a new function that checks if fifo is full or is there any issue with the existing function ? fifo_full should do exactly the same as HW_MBOX_IsFulll, I just removed all the macros and used __raw_readl instead. I could have removed the fifo_full function and do the __raw_readl directly, but I thought this way it was more readable. The main reason I cleaned the function was for performance reasons; remove unnecessary checks, extra steps, and the function call (now inline). -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rft/rfc/patch-v2.6.29-rc5+ 05/23] usb: host: ehci: use resource helpers
On Mon, Feb 23, 2009 at 05:29:38PM -0500, Josh Karabin wrote:
- if (pdev-resource[1].flags != IORESOURCE_IRQ) {
- dev_dbg(pdev-dev, resource[1] is not IORESOURCE_IRQ\n);
- retval = -ENOMEM;
- }
-
Your patch description doesn't explain why you removed this code. Was it
intentional?
I didn't see that any of the helpers called below covered the case, but I
didn't look too hard.
int irq = platform_get_irq(pdev, 0);
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to pass camera Orientation to userspace
On Monday 23 February 2009, Mauro Carvalho Chehab wrote: On Sat, 21 Feb 2009 12:53:57 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Adam, Sorry for the late reply, it's been very busy. Me too. 1) Reuse the existing HFLIP and VFLIP controls, marking them as read-only Pros : No change needed to videodev2.h Cons: It is confusing to have controls that have a subtly different meaning if they are read only. Existing apps that support those controls might get confused. Would require polling to support the case of a camera being turned toward / away from the user while streaming. Reusing an existing control for a different meaning seems wrong. What happens when some cam has the capability of doing hardware flipping, and have the cam flipped? I thought that case had already been agreed, implement the flip controls but set the flip flag in the hardware to the opposite of what the control says. 4) Use some reserved bits from the v4l2_capability structure Pros: Less overhead than controls. Cons: Would require polling to support the case of a camera being turned toward / away from the user while streaming. Can't easily identify drivers that don't support it. 5) Use some reserved bits from the v4l2_input structure (or possibly the status word but that is normally only valid for current input) Pros: Less overhead than controls. Could support multiple sensors in one camera if such a beast exists. What does exist is devices with a video input (e.g. composite) and a camera input: each input will have different flags. Since these vflip/hflip properties do not change they can be enumerated in advance and you know what each input supports. Cons: Would require polling to support the case of a camera being turned toward / away from the user while streaming. Polling applies only to the bits that tell the orientation of the camera. See below for a discussion of this. Analog tv does polling for signal strength, since userspace apps do mute and stops presenting video, if the signal is too weak. IMO, a similar mechanism should be used by pivoting. IMO, this would be better addressed as a property of v4l2_input. So, I think that (5) is better than (4). Can't easily identify drivers that don't support it. Not too difficult to add through the use of a capability bit. Either in v4l2_input or (perhaps) v4l2_capability. Another Pro is that this approach will also work for v4l2_output in the case of, say, rotated LCD displays. Using camera orientation bits in v4l2_buffer while capturing will work, but using similar bits for output will fail since the data is going in the wrong direction. The interest in detecting if a driver provides this informnation is to allow libv4l to know when it should use the driver provided information and when it should use its internal table (which needs to be retained for backward compatibility). With no detection capability the driver provided info should be ignored for USB IDs in the built in table. Thoughts please There is a case that we should think: at libv4l, we may need to override the default orientation, by a custom one. For example: Surveillance systems have cameras mounted on a fixed position. Depending on the camera, and the desired position, some cameras may needed to be mounted rotated (the same case also applies to some embedded hardware like ATM machines, where a webcam maybe mounted with 180 degrees, due to hardware constraints). Agreed, Hans de Geode pointed out the similar case that 2 laptops may use the same camera but one mount it upside down so hardware info unrelated to the camera indicates the orientation. Ok, this is nothing that kernel needs to handle, but, at userspace, we need to have a file where the user could edit and store the camera position, to override whatever we have in kernel. Unfortunately what that doesn't address is the problem that first started this discussion. A camera where the orientation information is contained in the USB messages from the camera so the driver is the only thing that can reasonably access it. Note also that for sensor orientation I doubt that 90 or 270 degrees rotation will be seen but I do know that the case of data being flipped on just one axis does exist. Is polling bad in this case? It is not something that needs immediate attention IMHO. The overhead for checking once every X seconds is quite low. Furthermore, it is only needed on devices that cannot do v/hflipping in hardware. An alternative is to put some effort in a proper event interface. There is one implemented in include/linux/dvb/video.h and used by ivtv for video decoding. The idea is that the application registers events it wants to receive, and whenever such an event arrives the select() call will exit with a high-prio event (exception). The application then checks what happened. The video.h
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Monday 23 February 2009, Mark Brown wrote:
On Mon, Feb 23, 2009 at 12:45:44PM -0800, David Brownell wrote:
another with a TWL4030 driver using that API
and a third patch making the core do something with that data.
Best IMO to switch the last two around. Effectively
there'd be one patch add new features to regulator
core, followed by the first of a set of implement
those new features in the driver for regulator X.
And in fact that's what I've done with the two patches
I'll be sending in a moment.
The reason I'm suggesting splitting things up the way I am is that it
separates out the TWL4030 driver (which looks very mergable to me right
now) from the behaviour changes. Ordering things that way makes it
clear what the dependency is. Another way of splitting it out would be
to remove the new API from the TWL4030, make that the first patch, then
have further patches adding the new API and the TWL4030 code to use it.
I don't see any reason why the TWL4030 regulator support needs to be
blocked on adding the new API and it makes review easier to keep them
separate.
I think we're talking past each other. I agree the twl4030 driver
is very mergeable right now; that's why it was submitted. You could
do so, and then apply the two patches on top ... very clear what the
dependency is, and as I understand it the result would be more or less
to your liking.
My comment was more along the lines of avoid adding unused hooks,
just merge the create-hook and use-hook patches. Having create
separate from use is often troublesome.
Then what would you call constraints by/from the regulator?
They're subsumed within the constraints supplied by the machine driver
at the minute.
That is, they are not named. :)
I suggest updating your terminology. machine constraints
would be much more clear for what's there now: they relate
to the machine. Other constraints (regulator, consumer)
relate to the other components ... the ones for which they
are an adjective.
Yeah, I kind of agree. To avoid confusion from changing the names I'd
be tempted to go for something like regulator driver constraints but
it's not desparately nice.
Hence my suggestion: {regulator,machine,consumer} constraints,
going from bottom up. They aren't driver constraints; they
are hardware constraints: regulators can't supply arbitrary
voltages.
To be honest I'm not
100% clear why this new feature is essential to supporting the TWL4030 -
I can see that it could be useful but I'm not clear on what makes it
essential for this driver.
I never said it was essential. However it does simplify
the core driver code a lot by moving a lot of error checks
to the init code; the checks need to live someplace. You're
the one asking for them to be packaged as a new framework
feature.
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rft/rfc/patch-v2.6.29-rc5+ 05/23] usb: host: ehci: use resource helpers
Felipe Balbi wrote:
Don't access pdev-resource[n].start directly, we
can use the resource helpers for that, makes the
code more readable.
[...snip...]
- if (pdev-resource[1].flags != IORESOURCE_IRQ) {
- dev_dbg(pdev-dev, resource[1] is not IORESOURCE_IRQ\n);
- retval = -ENOMEM;
- }
-
Your patch description doesn't explain why you removed this code. Was it
intentional? I didn't see that any of the helpers called below covered the
case, but I didn't look too hard.
Regards,
- Josh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to pass camera Orientation to userspace
On Mon, 23 Feb 2009, Adam Baker wrote: On Monday 23 February 2009, Mauro Carvalho Chehab wrote: On Sat, 21 Feb 2009 12:53:57 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Adam, Sorry for the late reply, it's been very busy. Me too. big snip The interest in detecting if a driver provides this informnation is to allow libv4l to know when it should use the driver provided information and when it should use its internal table (which needs to be retained for backward compatibility). With no detection capability the driver provided info should be ignored for USB IDs in the built in table. snip Ok, this is nothing that kernel needs to handle, but, at userspace, we need to have a file where the user could edit and store the camera position, to override whatever we have in kernel. Unfortunately what that doesn't address is the problem that first started this discussion. A camera where the orientation information is contained in the USB messages from the camera so the driver is the only thing that can reasonably access it. Alas, this is so true. What started the entire discussion about passing the info about sensor orientation is a set of cameras all of which have the same Vendor:Product ID but require different handling of the data (vflip and hflip, or just vflip) depending upon information which can only be obtained by communication with the camera, *not* by just knowing its Vendor:Product ID. Therefore, it is a little bit disheartening to see discussions -- again -- which come back to some kind of internal table in V4L, or which come back to things like have a file where the user could edit and store the camera position, to override whatever we have in kernel. Repeating the obvious, which apparently still needs to be repeated because not all of the participants in the discussion get it: 1. The internal table in V4L could not handle this problem, because the internal table would be based upon what information? The USB Vendor:Product number? For that matter, no other table could work, either. Well, actually, a table could work. It would have to be inside the module supporting the camera, and the matter of which table entry corresponds to what camera would have to be settled by passing a USB command to the camera and then parsing the camera's response. So now the question is how to get the information out of the module, which can only be collected and analysed inside the module. 2. The have a file where the user could edit idea may seem attractive to some, because it shoves the whole problem of agreeing on the appropriate way to get needed information out of a kernel module and into userspace onto someone not present during the current discussion, the user. However, this is not a solution, and thinking about it just a little bit ought to make that totally obvious. This is a strongly worded statement, so I will proceed to explain why the matter is so obvious. Let us assume the very best, and assume that every app which is V4L conformant has a one time initialization step and creates a directory $HOME/.app containing stored settings. So we might have a file called $HOME/.app/sq905. This file gets automatically written when the hapless user hooks up his sq905 camera the first time, and has to go through a choice routine to decide which side of the frame is up and which side is to the left and to the right. One could even take serious steps to make this otherwise unnecessary and silly sequence to be as really nice and user friendly as it could possibly be, and set this all up to be done with a sequence of mouse clicks and then the file, very kindly, gets written automatically. Those of you who are thinking that this file a user could edit is the way to go are, presumably, thinking along these lines. Well there are at least four things which are obviously wrong with this solution: 2.1. The user is forced to deal with something which the user should not even have to confront. The user is called upon to remedy an omission and a deficiency which was ignored at a lower level, because a bunch of developers could not come together on a reasonable course of action. Well, some don't like to see this one, so there are three more reasons. 2.2 Every camera is going to require a file for itself in $HOME/.app even if there is nothing that the user needs to do. Many of the supported cameras need nothing of the kind, so this would be kind of silly. 2.3 The user has two apps for dealing with webcams. So now the user needs to have another directory called $HOME/.app2 with similar files in it? 2.4 (and this one is the worst of all) The user has two cameras which are both powered by the same kernel module, and the two cameras need two different things done. Now what??? Both cameras can not simultaneously have a valid entry in $HOME/.app/sq905 which tells what to do with the data out of the camera. Because what is right for one of them is wrong
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Mon, Feb 23, 2009 at 02:43:16PM -0800, David Brownell wrote:
On Monday 23 February 2009, Mark Brown wrote:
Yeah, I kind of agree. To avoid confusion from changing the names I'd
be tempted to go for something like regulator driver constraints but
it's not desparately nice.
Hence my suggestion: {regulator,machine,consumer} constraints,
going from bottom up. They aren't driver constraints; they
are hardware constraints: regulators can't supply arbitrary
voltages.
Trouble is that the term regulator gets very overloaded and causes
confusion. There's also fun and games to be had with accuracy once you
start looking too closely at the discrete voltages.
To be honest I'm not
100% clear why this new feature is essential to supporting the TWL4030 -
I can see that it could be useful but I'm not clear on what makes it
essential for this driver.
I never said it was essential. However it does simplify
Apologies, you didn't actually say that, no - I was reading between the
lines there.
the core driver code a lot by moving a lot of error checks
to the init code; the checks need to live someplace. You're
I'm not sure I see that for the constraint tightening, and indeed the
TWL4030 set_voltage() operation does have a range check in it. Unless
I'm missing something if the tightened constraint is usable then it
should flop out of the range based requests with the constraints left
unmodified. The reason the TWL4030 driver still has the range check in
the set_voltage() operation is that it is checking to make sure that the
requests that come in can be satisfied from the discrete values the
regulator is able to produce which is a good thing to do.
the one asking for them to be packaged as a new framework
feature.
The change to add voltage range constraints if none were supplied is a
noticable policy change from the existing framework standard - it allows
machines to enable voltage changes without specifying what the valid
values are. I'm not convinced that this is a good idea in the first
place and it will result in the opposite behaviour to the current core
code (which should end up erroring out in constraint checking at runtime).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Monday 23 February 2009, Mark Brown wrote: The change to add voltage range constraints if none were supplied is a noticable policy change from the existing framework standard - it allows machines to enable voltage changes without specifying what the valid values are. Whatever the hardware handles *is* a specification. And there's no more assurance it's right than any other specification would be ... except that, as a rule, hardware designers like to avoid assemblies subject to trivial misconfiguration mistakes (like firing up a 2.5V-max rail at 5V). I'm not convinced that this is a good idea in the first place and it will result in the opposite behaviour to the current core code (which should end up erroring out in constraint checking at runtime). Well, if you really dislike it so much, that can easily be removed. Got any comments on the framework patch I sent? I'll take that as the first one, even though it's a different thread. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Monday 23 February 2009, Mark Brown wrote:
Yeah, I kind of agree. To avoid confusion from changing the names I'd
be tempted to go for something like regulator driver constraints but
it's not desparately nice.
Hence my suggestion: {regulator,machine,consumer} constraints,
going from bottom up. They aren't driver constraints; they
are hardware constraints: regulators can't supply arbitrary
voltages.
Trouble is that the term regulator gets very overloaded and causes
confusion.
That's why one of the *first* jobs in architecture is to
ensure the terminology doesn't easily overload ... there's
always trouble when it isn't. Despite early groans from
peanut galleries about language lawyering and wanting
to code in C not English, etc. ;)
Thing is, there's already overloading here. Two types
of regulator -- struct regulator_dev wrapping hardware,
and the struct regulator is a client/consumer handle.
(And thus confusing to me, since it sounds like the more
fundamental concept, but instead it's a few layers up.)
If you're concerned about overloading terminology, then
best to address it sooner than later. I've noticed you
using the consumer, machine, and regulator terms
more or less like I suggested, and those make sense; but
the current struct names don't encourage that usage. It's
possible to adjust usage before changing names in C.
Thankfully, in Linux global name struct changes are not
rejected out of hand.
There's also fun and games to be had with accuracy once you
start looking too closely at the discrete voltages.
Yes; the patch I sent is explicitly making those available.
But I ignored issues like +/- 3% accurate output for LDOs
(or switchers) ... if anyone really needs to address them,
patches will be needed. For now I only care that a 3.1 Volt
output can match both MMC_VDD_30_31 and MMC_VDD_31_32! ;)
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git 1/2] regulator: twl4030 regulators
On Monday 23 February 2009, David Brownell wrote:
There's also fun and games to be had with accuracy once you
start looking too closely at the discrete voltages.
Yes; the patch I sent is explicitly making those available.
But I ignored issues like +/- 3% accurate output for LDOs
(or switchers) ... if anyone really needs to address them,
patches will be needed. For now I only care that a 3.1 Volt
output can match both MMC_VDD_30_31 and MMC_VDD_31_32! ;)
And -- for kicks -- here's one notion of what it might look
like to have the MMC stack support the regulator framework.
- Dave
=
Prototype glue between MMC and regulator stacks ... compiles,
and mmc_regulator_get_ocrmask() passed sanity testing.
NOTES:
- The MMC core does't call mmc_regulator_set_ocr() because hosts
may need to do that in conjunction with updating I/O voltage.
Case in point, MMC1 on omap_hsmmc ... where the host driver
must update MMC1_HCTL.SDVS and PBIAS registers in addition to
the regulator, supporting 1.8V or 3.0V voltage ranges. (MMC2
and MMC3 use external level shifting for Vdd != 1.8V.)
Likewise, using eMMC managed NAND solutions, powerup includes
not both Vcc (vdd to Linux, e.g. 3.0V) and an I/O interface
rail VccQ (e.g. 1.8V). The JEDEC spec for eMMC requires VccQ
powerup after Vcc, and powerdown before it.
- The vdd supply name isn't fixed, since platforms may need
to use more than one I/O supply.
Case in point, MMC1 on omap_hsmmc (again) ... where a second
supply is needed to kick in 8-bit I/O using DAT4..DAT7 signals.
That would not be handled quite like VccQ, since it's only
used for 8-bit I/O widths (MMCplus cards, some eMMC, etc).
---
drivers/mmc/core/Kconfig |8 +++
drivers/mmc/core/core.c | 98 +
include/linux/mmc/host.h |3 +
3 files changed, 109 insertions(+)
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -14,3 +14,11 @@ config MMC_UNSAFE_RESUME
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
+config MMC_REGULATOR
+ bool
+ depends on REGULATOR
+ default y
+ help
+ Select this to provide some helper utilities to access the
+ vdd (card) voltage supply associated with an MMC/SD slot.
+
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -21,6 +21,7 @@
#include linux/leds.h
#include linux/scatterlist.h
#include linux/log2.h
+#include linux/regulator/consumer.h
#include linux/mmc/card.h
#include linux/mmc/host.h
@@ -523,6 +524,103 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min,
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_MMC_REGULATOR
+
+/**
+ * mmc_regulator_get_ocrmask - return mask of supported voltages
+ * @host: mmc host whose supply will be consulted
+ * @supply: supply voltage to use; vdd if NULL
+ *
+ * This returns either a negative errno, or a mask of voltages
+ * that can be provided to MMC/SD/SDIO devices using the specified
+ * host's vdd supply.
+ */
+int mmc_regulator_get_ocrmask(struct mmc_host *host, const char *supply)
+{
+ int result = 0;
+ struct regulator*reg;
+ int count;
+ int i;
+
+ reg = regulator_get(host-parent, supply ? : vdd);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ count = regulator_count_voltages(reg);
+ if (count 0) {
+ result = count;
+ goto done;
+ }
+
+ for (i = 0; i count; i++) {
+ int vdd_uV;
+ int vdd_mV;
+
+ vdd_uV = regulator_list_voltage(reg, i);
+ if (vdd_uV = 0)
+ continue;
+
+ vdd_mV = vdd_uV / 1000;
+ result |= mmc_vddrange_to_ocrmask(vdd_mV, vdd_mV);
+ }
+
+done:
+ regulator_put(reg);
+ return result;
+}
+EXPORT_SYMBOL(mmc_regulator_get_ocrmask);
+
+/**
+ * mmc_regulator_set_ocr - set regulator to match host-ios voltage
+ * @host: mmc host whose supply voltage will be changed
+ * @supply: supply voltage to use; vdd if NULL
+ *
+ * MMC host drivers may use this to enable or disable a regulator
+ * using a particular supply voltage. This would normally be
+ * called from the set_ios() method, possibly as part of updating
+ * digital interfaces to support that voltage.
+ */
+int mmc_regulator_set_ocr(struct mmc_host *host, const char *supply)
+{
+ int result = 0;
+ struct regulator*reg;
+ int min_mV, max_mV;
+ int enabled;
+
+ reg = regulator_get(host-parent, supply ? : vdd);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+ enabled = regulator_is_enabled(reg);
+ if (WARN(enabled 0, %s: regulator_is_enabled -- %d\n,
+
