* shekhar, chandra <[EMAIL PROTECTED]> [080808 09:52]:
>
>
>>> ===
>>> --- linux-omap-2.6.orig/arch/arm/plat-omap/mcbsp.c 2008-08-07
>>> 16:39:51.0 +0530
>>> +++ linux-omap-2.6/arch/arm/plat-omap/mcbsp.c 2008-08-07
>>> 16:45:
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/mcbsp.c 2008-08-07
16:39:51.0 +0530
+++ linux-omap-2.6/arch/arm/plat-omap/mcbsp.c 2008-08-07
16:45:00.0 +0530
@@ -29,9 +29,31 @@
struct omap_mcbsp **mcbsp_ptr;
int
Hi,
* chandra shekhar <[EMAIL PROTECTED]> [080808 09:07]:
> Hi,
>
> this patch modifies the read write function to do
> 16/32 bit read write depending on CPU.
>
> Regards,
> Chandra Shekhar
>
> Signed-off-by: Chandra Shekhar< [EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap1/mcbsp.c |1
* 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, it makes those error reports go away.
> I'd say to
Hi,
this patch modifies the read write function to do
16/32 bit read write depending on CPU.
Regards,
Chandra Shekhar
Signed-off-by: Chandra Shekhar< [EMAIL PROTECTED]>
---
arch/arm/mach-omap1/mcbsp.c |1 +
arch/arm/mach-omap2/mcbsp.c |3 +++
arch/arm/plat-omap/mcbsp.c
Hi,
This Patch adds base address for all the instances on OMAP34xx and defines some
relevant register.
It also populates McBSP structure for all the instances for 34xx.
Regards,
Chandra Shekhar
Signed-off-by: Chandra Shekhar< [EMAIL PROTECTED]>
---
arch/arm/mach-omap2/mcbsp.c | 53 +
Hi,
This a preamble patch series for McBSP support on OAMP34xx. it adds few
register definitions and and base addresses for all the McBSP instances.
It also modifies read/write functions to do 16/32 ops depending on CPU.
It doesn't add any functionality.
Regards,
Chandra Shekhar
--
To unsubscri
Hi,
I observed kernel crash in Linux 2.6.26 on OMAP35xx EVM with MUSB. The issue is
described here.
Case-1:
1) Connect USB stick to root hub of OMAP35xx board.
2) It gets detected successfully.
3) Disconnect the stick and connect it again
4) repeat step-3 and we get kernel crash (log-1 attached
From: Madhusudhan Chikkature<[EMAIL PROTECTED]>
ARM: OMAP3: Fixes required to make HSMMC driver work as module.Complete the
previously applied patch.
This patch provides the necessary fixes to make the HSMMC driver work as
loadble module.
Signed-off-by: Madhusudhan Chikkature<[EMAIL PROTECTED]>
> * Madhusudhan Chikkature <[EMAIL PROTECTED]> [080725 13:34]:
>> From: Madhusudhan Chikkature<[EMAIL PROTECTED]>
>>
>> ARM: OMAP3: Fixes required to make HSMMC driver as module.
>>
>> This patch provides the necessary fixes to make the HSMMC driver work as
>> loadble module.
>
> This one does not
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
On Thu, Aug 7, 2008 at 3:38 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Thursday 07 August 2008, Ashwin Bihari wrote:
>
>> sd 0:0:0:0: [sda] Attached SCSI removable disk
>> usb 1-2: reset high speed USB device using ehci-omap and address 2
>> usb 1-2: device descriptor read/64, error -110
>>
> On ke, 2008-08-06 at 12:12 -0500, ext Woodruff, Richard wrote:
> > > I would say no, we don't need the CONFIG_SYSOFFMODE option.
> >
> > One point is if you try an go to 0v on something under and ES2.1 you
> > will end up with crashes after a while. Some kind of conditional is
> > needed unless
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 mes
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
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 lin
On Thu, Aug 07, 2008 at 10:20:33PM +0100, Russell King - ARM Linux wrote:
> In the case of arch/arm/mach-omap2/irq.c, reading the INTC_REVISION
> reg after masking should be a sufficient solution.
And here's a patch to do exactly that.
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/
On Thu, Aug 07, 2008 at 03:38:55PM -0500, Woodruff, Richard wrote:
>
> > From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
> > > Is DEVICE really safe for things other than FIFOs with out the use of
> > > barriers?
> >
> > As far as I'm aware, yes - and that comment is based solely upon the
> From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
> > Is DEVICE really safe for things other than FIFOs with out the use of
> > barriers?
>
> As far as I'm aware, yes - and that comment is based solely upon the
> fact that no one has reported any problems with the kernel which have
> been
On Thursday 07 August 2008, Ashwin Bihari wrote:
> sd 0:0:0:0: [sda] Attached SCSI removable disk
> usb 1-2: reset high speed USB device using ehci-omap and address 2
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: device descriptor read/64, error -110
> usb 1-2: reset high speed USB d
On Thu, Aug 07, 2008 at 01:56:40PM -0500, Woodruff, Richard wrote:
> > From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
> > > Most of the weak memory attributes in newer ARMs are not exploited
> > > today in tree. I'll guess this was more a correctness and capability
> > > judgment from Ru
> From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
> > Most of the weak memory attributes in newer ARMs are not exploited
> > today in tree. I'll guess this was more a correctness and
> capability
> > judgment from Russell.
>
> Not entirely true. We do as much as is safe to do - which is
Greetings,
I've got a OMAP3530 based board on which I'm having some trouble with
HS USB transfers. I plug in a HS USB Flash drive and it is properly
detected. I can mount the drive and write any amount of data to it
without any problems. However, when I start reading from the drive,
the action hal
> On Wed, 2008-08-06 at 07:28 -0500, Woodruff, Richard wrote:
> > > The code need to execute in a non-cached region.
> >
> > I don't think there is any guarantee that dirty cache line won't be
> > evicted to SDRAM even if your code uses uncached memory only. The CPU
> > is
> > allowed to do specula
On Thu, 2008-08-07 at 07:01 +0100, Paul Walmsley wrote:
> On Wed, 6 Aug 2008, Catalin Marinas wrote:
>
> > On Tue, 2008-08-05 at 07:15 -0500, Woodruff, Richard wrote:
> > > > Is the controller allowed to write dirty cache lines out at any time
> > > > it
> > > > likes? Surely a better fix is to dr
Recent ARM kernel doesn't detect and output Cortex-A8 cache
configuration correctly. Result is something like this in kernel's
boot messages:
-- cut --
...
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
...
CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativit
On Tue, 17 Jun 2008 20:43:00 +0200, Jean Delvare wrote:
> Hi all,
>
> I have converted the isp1301_omap driver to a new-style i2c driver. The
> problem is that I don't have an OMAP system nor even an ARM compiler,
> so I cannot test my work at all. So, I would appreciate if someone with
> access t
On Thu, 2008-08-07 at 08:30 +0100, Russell King - ARM Linux wrote:
> What we don't do is mark DMA memory ask being normal uncached memory,
> thereby allowing that to be reordered with device accesses - we make
> it strongly ordered. The reason being that the kernel doesn't have
> barriers necessar
Hi,
I'm trying to pull from git.omapzoom and nothing happens, it seems you
are not running git-update-server-info (info/refs is outdated[1]). You
need to chmod +x .git/hooks/post-update.
Also, you don't have a .git/cloneurl file, so the URL is not displayed
by gitweb. It would also be good to sup
Hi,
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.
Regards,
Chandra Shekhar
Signed-off-by: Chandra Shekhar< [EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |4 +++-
1 files changed, 3 insertions(+), 1 deletio
Hi,
first - print is misleading, it should be i2c tarnsmit underflow.
I2C transmit underflow is because of interrupt handler error.
There was a patch to correct nack error ( ack for devices which are not
present) which also removed some continue statement.
now a race condition arises where even
* David Brownell <[EMAIL PROTECTED]> [080807 02:30]:
> On Tuesday 05 August 2008, Tony Lindgren wrote:
> > Also please check that things work for your board,
> > let's try to tag v2.6.26-omap1 within next few days so we can
> > move on again.
>
> Two problems on the OSK5912:
>
> - cpufreq oopses
On ke, 2008-08-06 at 18:42 +0530, ext Rajendra Nayak wrote:
> Hi,
>
> Re-posting a refreshed version of these patches.
I'm getting this error when trying to apply these patches with 'git-am'
command:
$ git-am ~/.evolution/mail/local/stage
Applying Basic cpuidle driver
fatal: patch fragment
Hi Tony,
This patch should be safe to apply now as the sys off mode pin polarity
was fixed in the patch "Add early init for voltage controller
configuration and off mode polarity" (index a6cfc46..fc72c11 100644).
I compile & boot tested it on SDP board, on both plain master branch and
with Jouni'
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vishal
> bhoj
> Sent: Wednesday, August 06, 2008 6:59 PM
> To: linux-omap@vger.kernel.org
> Subject: Fwd: how to use omap 2430 character led
>
> CAn anyone tell me howto use the character lcd display on
From: ext Rajendra Nayak <[EMAIL PROTECTED]>
This workaround enables autoidle for interface clocks and plls. Also
automatic control of external oscillator through sys_clkreq is
enabled.
Proper fix to this is to generalize omap3_dpll_allow_idle,
omap3_dpll_deny_idle, omap3_dpll_autoidle_read and c
From: Tero Kristo <[EMAIL PROTECTED]>
UART usage (e.g. serial console) now denies sleep for 5 seconds. This
makes it possible to use serial console when dynamic idle is
enabled. Write 1 to /sys/power/clocks_off_while_sleep to enable uart
clock disable on idle. Without this omap won't enter retenti
From: ext Rajendra Nayak <[EMAIL PROTECTED]>
In omap3 gpios 2-6 are in per domain. Functional clocks for these
should be disabled. This patch is needed until gpio driver disables
gpio clocks.
GPIO modules in PER domain are not able to act as a wake up source if
PER domain is in retention. PER dom
From: ext Rajendra Nayak <[EMAIL PROTECTED]>
This workaround shouldn't be needed when all drivers are configuring
their sysconfig registers properly and using their clocks properly.
Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm34xx.c | 31
On ke, 2008-08-06 at 18:30 +0530, ext Rajendra Nayak wrote:
> Hi,
>
> I am posting a set of 4 workaround patches from Jouni, refreshed against the
> latest l-o tree.
> These are yet to be pushed to mailine and are needed for the refreshed CPUidle
> patches to work, which I would post following thi
On Wed, Aug 06, 2008 at 07:21:14AM -0500, Woodruff, Richard wrote:
> Most of the weak memory attributes in newer ARMs are not exploited
> today in tree. I'll guess this was more a correctness and capability
> judgment from Russell.
Not entirely true. We do as much as is safe to do - which is bas
On ke, 2008-08-06 at 12:12 -0500, ext Woodruff, Richard wrote:
> > I would say no, we don't need the CONFIG_SYSOFFMODE option.
>
> One point is if you try an go to 0v on something under and ES2.1 you
> will end up with crashes after a while. Some kind of conditional is
> needed unless we get to d
42 matches
Mail list logo
