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 LDO
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} constrai
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 hard
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.
> He
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 wrote:
Hi Adam,
Sorry for the late reply, it's been very busy.
Me too.
The interest in detecting if a driver provides this informnation is
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")
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
> >
On Monday 23 February 2009, Mauro Carvalho Chehab wrote:
> On Sat, 21 Feb 2009 12:53:57 +0100
>
> Hans Verkuil 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 ch
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 re
On Tue, Feb 24, 2009 at 12:06 AM, Kanigeri, Hari 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 an
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 D
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 detectio
> 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
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 be
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
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
> > resta
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"
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
From: David Brownell
Update previously-posted twl4030 regulator driver to export
supported voltages to upper layers using a new mechanism.
Signed-off-by: David Brownell
---
drivers/regulator/twl4030-regulator.c | 72 ++--
1 file changed, 33 insertions(+), 39 delet
From: David Brownell
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,
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
"Nayak, Rajendra" 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
> VDD
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
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)
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
---
drivers/usb/host/ehci-omap.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/driv
Adding a platform_data to the driver allow us
to remove some of the ifdeferry in the code.
Signed-off-by: Felipe Balbi
---
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-oma
From: Tony Lindgren
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
---
drivers/usb/host/ehci-omap.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
di
add missing MODULE_AUTHOR(). No functional changes.
Signed-off-by: Felipe Balbi
---
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/ho
add missing MODULE_AUTHOR(). No functional changes.
Signed-off-by: Felipe Balbi
---
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/ho
include instead of
Signed-off-by: Felipe Balbi
---
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/u
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
---
arch/arm/mach-omap2/usb-ehci.c |4 ++--
arch/arm/plat-omap/include/mach/omap34xx.h |4 +++-
2 files changed, 5 insertions(+),
Use time_after() to avoid looping forever.
Signed-off-by: Felipe Balbi
---
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..3
That header is only used by ehci-omap.c for register
definitions and indirectly include some other headers.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/ehci-omap.c | 100 +-
drivers/usb/host/ehci-omap.h | 125 --
2 fi
doing that will allow us to use standarnd __raw_read/write
calls and stop using omap_read/write ones.
Signed-off-by: Felipe Balbi
Signed-off-by: Tony Lindgren
---
One patch from Tony ensuring register read only after clocks
where on, was melded into this one.
arch/arm/mach-omap2/usb-ehci.c |
That header is only used by ehci-omap.c for register
definitions and indirectly include some other headers.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/ehci-omap.c | 100 +-
drivers/usb/host/ehci-omap.h | 125 --
2 fi
Just making it better for my bad eyes. Style only, no
functional changes.
Signed-off-by: Felipe Balbi
---
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/hos
The driver wasn't releasing the requested resources
on error, so make that work.
Signed-off-by: Felipe Balbi
---
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
Move some of the comments used to separate the code
to more logical places. No functional changes.
Signed-off-by: Felipe Balbi
---
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
The driver wasn't releasing the requested resources
on error, so make that work.
Signed-off-by: Felipe Balbi
---
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
Make the register definitions in ehci-omap.c more sane.
Also change the parameter passed omap_start/stop_ehc().
Signed-off-by: Felipe Balbi
---
drivers/usb/host/ehci-omap.c | 219 +-
1 files changed, 111 insertions(+), 108 deletions(-)
diff --git a/drive
include instead of
Signed-off-by: Felipe Balbi
---
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/u
Adding a platform_data to the driver allow us
to remove some of the ifdeferry in the code.
Signed-off-by: Felipe Balbi
---
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-oma
Move some of the comments used to separate the code
to more logical places. No functional changes.
Signed-off-by: Felipe Balbi
---
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
Use time_after() to avoid looping forever.
Signed-off-by: Felipe Balbi
---
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..3
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
---
drivers/usb/host/ehci-omap.c | 185 --
1 files changed, 52 insertion
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
---
drivers/usb/host/ehci-omap.c | 24 ++
That was just a useless function call, completely
unneeded. Remove it.
Signed-off-by: Felipe Balbi
---
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 db457
Move the platform_driver closer to its functions.
No functional changes.
Signed-off-by: Felipe Balbi
---
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
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
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
---
drivers/usb/host/ehci-omap.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/ehc
Style only, no functional changes.
Signed-off-by: Felipe Balbi
---
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 1
Style only, normally we use pdev as the platform_device's
pointer name.
Signed-off-by: Felipe Balbi
---
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-
We should stop using bus_id to pass the device
name, dev_name() should be used instead.
Cleanup only.
Signed-off-by: Felipe Balbi
---
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
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
Trivial cleanup patch, no functional changes. Just
adding a few spaces here and there.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/ehci-omap.c | 50 +++--
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/dr
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
---
drivers/usb/host/ehci-omap.c | 24 ++
That was just a useless function call, completely
unneeded. Remove it.
Signed-off-by: Felipe Balbi
---
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 db457
Move the platform_driver closer to its functions.
No functional changes.
Signed-off-by: Felipe Balbi
---
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
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
---
drivers/usb/host/ehci-omap.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/ehc
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
Style only, no functional changes.
Signed-off-by: Felipe Balbi
---
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 1
We should stop using bus_id to pass the device
name, dev_name() should be used instead.
Cleanup only.
Signed-off-by: Felipe Balbi
---
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
Style only, normally we use pdev as the platform_device's
pointer name.
Signed-off-by: Felipe Balbi
---
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-
Trivial cleanup patch, no functional changes. Just
adding a few spaces here and there.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/ehci-omap.c | 50 +++--
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/dr
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
> 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 t
On Mon, Feb 23, 2009 at 8:27 PM, 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
> ;) 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 equat
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 longsta
On Mon, Feb 23, 2009 at 8:20 PM, 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 electrica
"Peter 'p2' De Schrijver" 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 id
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
> But my question is this: why are we trying to a different equation
> here compared to the equation in the TRM?
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.
- Eero
--
To unsubscribe from this list: send the line "uns
On Mon, Feb 23, 2009 at 8:10 PM, 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
From: David Brownell
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
---
NOTE: won't apply to current mainline GIT.
arch/
> 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
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).
From: Fernando Guzman Lugo
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
---
arch/arm/plat-omap/include/dspbridge/host_os.h | 6 --
1 files change
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
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.
>>
>>
>> Attached is the I2C spec that I have. As I understand
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 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
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:
> > >
> > > > > T
> 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
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 lin
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, G
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.
>
>
> Attached is the I2C spec that I have. As I understand it, the I2C only
> specify the minimum tLow and tHigh (which is
Kyungmin Park wrote:
> Hi,
>
> On Mon, Feb 23, 2009 at 5:04 PM, Adrian Hunter
> wrote:
>> ext Kim Kyuwon wrote:
>>> Hi,
>>>
>>> On Sat, Feb 21, 2009 at 6:11 AM, David Brownell wrote:
On Friday 20 February 2009, Kim Kyuwon wrote:
> +static void omap_hsmmc_init(struct mmc_omap_host *host)
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
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 foll
Hi,
On Mon, Feb 23, 2009 at 5:04 PM, Adrian Hunter
wrote:
> ext Kim Kyuwon wrote:
>> Hi,
>>
>> On Sat, Feb 21, 2009 at 6:11 AM, David Brownell wrote:
>>> On Friday 20 February 2009, Kim Kyuwon wrote:
+static void omap_hsmmc_init(struct mmc_omap_host *host)
+{
+ u32 hctl, cap
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
Mathe
On Mon, 23 Feb 2009 08:34:08 +0100
Hans Verkuil wrote:
> On Monday 23 February 2009 00:56:40 Trent Piepho wrote:
> > On Mon, 23 Feb 2009, Hans Verkuil wrote:
> > > On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
> > > > Trent Piepho wrote:
> > > > > On Sun, 22 Feb 2009, Hans de Goede wro
On Sat, 21 Feb 2009 12:53:57 +0100
Hans Verkuil 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
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, Ga
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.
>
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 a
97 matches
Mail list logo
