I noticed an interesting feature in the getnstimeofday() function when
used with suspend. System clock is effectively reset to the value it was
just before suspend. ...
I.e., the calendar clock was only advanced 2 seconds. The time you spend
in suspend does not matter, the end result is the
f35ae6346850f6c192269b09088b20261760f0e0
Tony, actually ... there were some issues in the omap_udc code too.
Yeah, blame it on me, looks like I missed that one somehow with the
__REG removal.
So did a lot of other folk!
--
To unsubscribe from this list: send the line unsubscribe
If I have a USB camera with good Linux support, can I connect it
to omap3evm(or any omap2) and make it functional?
I'm told some folk have used ISO transfer support, but when I last did
much work with the musb code, none of it was tested.
Oh, one more point: it should work pretty well
That one isn't mine, the original code already has the problem.
Apparently this was broken by the following patch from David:
f35ae6346850f6c192269b09088b20261760f0e0
Tony, actually ... there were some issues in the omap_udc code too.
The fix should be sent to Linus ASAP, otherwise
Do you guys still have H2 boards there ?
Also H4 needs to be tested.
H2 needs to be tested with upstream kernels and OTG ... as I recall,
the linux-OMAP kernel has patches that made OTG work on H3 (and I'd
assume H4 too) but broke it completely on H2.
- Dave
--
To unsubscribe from this
Why are there any proc files in this driver? Drivers should not add
proc files. Hm, should have reviewed this code a bit better, sorry...
With that much code, it's just a question of _how much_ any review
ends up missing.
We needed a quick way to export the testmodes to userland. And
On Thursday 07 August 2008, Tony Lindgren wrote:
* David Brownell [EMAIL PROTECTED] [080808 03:37]:
On Thursday 07 August 2008, chandra shekhar wrote:
This patch is to fix I2C transmit overflow error.
I guess it should fix the OSK5912 error. I dont have the board to test it.
Yes
As I commented in
http://marc.info/?l=linux-omapm=121792042504348w=2
I can't quite see why anything is using omap_mmc_config for
anything related to hsmmc ... it contains two structs that
don't match what the hsmmc driver understands.
- Dave
@@ -83,9 +84,17 @@ static struct
On Thursday 07 August 2008, chandra shekhar wrote:
This patch is to fix I2C transmit overflow error.
I guess it should fix the OSK5912 error. I dont have the board to test it.
Yes, it makes those error reports go away.
I'd say to merge this patch.
--
To unsubscribe from this list: send the line
On Thursday 07 August 2008, Tony Lindgren wrote:
Two problems on the OSK5912:
- cpufreq oopses on boot
- continuous i2c overflow errors
ISTR both of these bugs are in mainline too. I'd say the
I2C regression is higher priority.
Hmm, I wonder what has broken I2C?
Seems
On Thursday 07 August 2008, Jean Delvare wrote:
Still no testers for these patches?
Right now I don't seem to be able to boot OMAP1 in mainline,
so pulling that H2 out of its box would be futile. :(
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
On Thursday 07 August 2008, Ashwin Bihari wrote:
I did use a Total Phase Beagle 480USB protocol analyzer when this
issue first manifested, but there is nothing that jumped out at me as
a possible error or glitch. It just looks like the transactions just
stopped mid-way without any rhyme or
Signed-off-by: David Brownell [EMAIL PROTECTED]
Update and fix Beagle LED declarations: gpios for USR0 and USR1
were swapped, and their names don't match docs or silksreen.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3beagle.c |9 +
1 file
On Monday 14 July 2008, Kumar, Purushotam wrote:
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- if (mmc-enabled)
+ if (mmc-enabled) {
+ mmc1_data.conf = *mmc;
(void)
On Monday 04 August 2008, Tony Lindgren wrote:
Looks like this driver does not exist outside linux-omap tree,
care to send the whole driver to MTD list?
Unless someone created a big-endian OMAP, the cpu_to_le16()
calls in the read/write buffer calls can be removed ... and
then the read buffer
On Monday 04 August 2008, Lennert Buytenhek wrote:
On Mon, Aug 04, 2008 at 01:02:46PM -0700, David Brownell wrote:
Looks like this driver does not exist outside linux-omap tree,
care to send the whole driver to MTD list?
Unless someone created a big-endian OMAP,
Don't they use
On Monday 04 August 2008, Lennert Buytenhek wrote:
I've never seen CPU endianity being hardwired in any ARM system ever
-- but maybe OMAP is different.
I'll let TI answer that one, since I'm not going to look at docs for
all the ARM's I've ever used.
My observation stands *REGARDLESS* of
On Monday 21 July 2008, Russell King - ARM Linux wrote:
On Wed, Jul 16, 2008 at 06:19:05PM +0300, Tony Lindgren wrote:
I'm reposting the series to a wider audience as Russell King suspected that
other archs may be interested in reviewing these too, or at least some
parts of the code.
It
On Sunday 06 July 2008, Dmitry Baryshkov wrote:
+ ohci-start_hnp = start_hnp;
Why? It's part of struct otg_transceiver.
Actually the ohci-omap.c:start_hnp does a bit more than just
otg_start_hnp(tranceiver). Maybe it should be merged. I dunno.
I'm fine with it staying the
Shrink the runtime footprint of the OMAP1 RTC driver a bunch by
removing some old hacks and switching to platform_driver_probe().
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/rtc/rtc-omap.c | 21 -
1 file changed, 4 insertions(+), 17 deletions
On Monday 30 June 2008, Felipe Balbi wrote:
The patch won't probe. But if you just copy what's added in
board-omap3430sdp.c
should work.
Better: that controller data should be provided by SOC glue
in those cases (omap2430, omap 3*, DaVinci, etc). If it's
not board-specific, it doesn't
On Wednesday 21 May 2008, Tony Lindgren wrote:
Great, after I enable the DMA mode 1 on Blackfin and cleanup the code,
I will send
out the code before you sent them to upstream
Maybe we should get the musb code to USB tree before that? It's been out
of the scope for linux-omap tree for
On Wednesday 21 May 2008, Felipe Balbi wrote:
I'm all for getting the musb_hdrc driver into the 2.6.27 queue...
I presume there are still some infrastructure changes in usbcore
that block that merge? It'd be nice if we could merge musb_hdrc
without those changes (OTG related) and then
On Saturday 17 May 2008, Bryan Wu wrote:
We discussed these 4 bugs before. Now we fixed them.
Please review following 2 patches.
They looked plausible to me ... though the urb-status
one is a bit of a band-aid, and when that field finally
vanishes a better fix will be needed.
- Dave
--
To
On Thursday 15 May 2008, Pandita, Vikram wrote:
Another observation:
There is a comment in isp1301_omap.c file:
static void power_up(struct isp1301 *isp)
/* do this only when cpu is driving transceiver,
* so host won't see a low speed device...
*/
Could anyone
On Friday 25 April 2008, Felipe Balbi wrote:
Hi Tony and Dave,
there's this one pending patch [1]. Do you guys have any comments on that
one?
Author: Felipe Balbi [EMAIL PROTECTED]
Date: Thu Apr 17 17:34:20 2008 +0300
USB: MUSB: Don't ignore disconnect on suspend
As
On Thursday 24 April 2008, Tony Lindgren wrote:
.../mach-omap2/{board-3430sdp-usb.c = usb-musb.c} | 32 ---
Good: so some of the inappropriate sdp_*() names will vanish ...
include/asm-arm/arch-omap/usb-musb.h | 35 +++
usb-musb.{c,h}? EHCI/OHCI has
On Thursday 17 April 2008, Paul Walmsley wrote:
But it would be nice to be able to call into clock functions like
round_rate, set_rate, and set_parent via filesystem writes for debugging
purposes, and I don't think that debugfs supports this.
It does, if you set up the files properly ...
On Thursday 17 April 2008, Paul Walmsley wrote:
Userspace should limit itself to changing policies.
CPUFreq is good, but it does not manage non-CPU-frequency knobs very well,
and there are plenty of those on OMAP3.
Similar issues are widely acknowledged.
Is there any reason why we
I've not been following these McBSP issues, but this
comment suggests to me that the clock API is just not
being used correctly here:
On Tuesday 15 April 2008, Chandra shekhar wrote:
1
Clock structure can be moved to header file and create a structure.
So that instead of calling each clock by
On Tuesday 15 April 2008, Luís Vitório Cargnini wrote:
where I found the documentation of the new GPIO lib ? since I'm using
legacy functions.
Documentation/gpio.txt ...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More
On Monday 07 April 2008, Felipe Balbi wrote:
e) So I hacked the usb-storage driver code, the Linux host on Blackfin
will not wait for the 2nc CSW. Then this bug is gone.
This is just a workaround for that, it should not be the right way.
Does anyone here meet this issue before, on
On Thursday 03 April 2008, Felipe Balbi wrote:
+ * TWL4030 MADC module driver
What's a MADC? The driver should explain that much,
especially for chips where the documentation isn't being
made generally available.
I'm guessing it's some flavor of ADC... 8 bit? How
many channels? Any special
On Thursday 03 April 2008, Felipe Balbi wrote:
+config TWL4030_MADC
+ tristate TWL4030 MADC Driver
+ depends on TWL4030_CORE
+
Again, what's a MADC?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo
Again, what's a MADC?
It's an 'upset C' of course ;)
Better than obfuscated C, I guess. http://www.ioccc.org/ ... :)
Really:
It's a 10-bit analog-to-digital converter combined with a 16-input
analog multiplexer. Multiplexed-ADC I suppose. It is used by
processor groups, battery
On Thursday 20 March 2008, Felipe Balbi wrote:
Could it be some
problem in the ULPI support for omap3 that's preventing musb to wake up
and switch to host role ?
Your theory is as good as mine; I don't have that hardware.
I was just pointing out that this specific area has always
been a
Another compile fix for DSP code ... these symbols are defined
as NOPs in a header.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/dsp/dspgateway/dsp_common.c |4
1 files changed, 4 insertions(+)
--- osk2.orig/drivers/dsp/dspgateway/dsp_common.c 2008-03-17
21:03
CC drivers/i2c/chips/isp1301_omap.o
drivers/i2c/chips/isp1301_omap.c: In function 'isp1301_set_peripheral':
drivers/i2c/chips/isp1301_omap.c:1360: error: implicit declaration of function
'machine_is_omap_h2'
drivers/i2c/chips/isp1301_omap.c:1360: error: implicit declaration of function
701 - 738 of 738 matches
Mail list logo
