Attached is a rev-4 with the cpu_relax() added to while loops as
suggested by Ladislav, and CTRL register defines moved to the
right
location.
I confirm this version of the patch works on 3430 with latest
kernel.
I'll push the rev-4 version of the patch today. The second patch
On Thursday 03 April 2008, Felipe Balbi wrote:
+config TWL4030_MADC
+ tristate TWL4030 MADC Driver
+ depends on TWL4030_CORE
+
Again, what's a MADC?
It's an 'upset C' of course ;)
Really:
It's a 10-bit analog-to-digital converter combined with a 16-input analog
In that variant I just added a load_start() function in addition to
the
load function and converted all the in tree callers to use this as
they
all called load() then start() in order anyway. This left the API
behavior the same but optimized all current users.
Can you send a patch
Presumably this is from the CPU trace port, OMAP3 with NO_HZ.
Yes. Just using git-latest kernel and NO_HZ. You can get the same data
on OMAP2 also through ETM.
I don't see much profiling on the 'live' tree here. Internal trees at
TI generally get looked at more critically. It might be
I've not calibrated to verify but that seems to be what the picture is
showing so there is some chance the time base is off. All the
instruction
trace is there to walk it if necessary. There have been some comments
about NO_HZ adding some overhead from those who measure MHz around
here
for
Yes, I added it to u-boot to make a OneNAND boot image by using one
compile.
Of course, you can use the 1KiB boot image separately with other
bootloaders.
It has separate directory and can build it.
See reference board, apollon in u-boot tree.
Yes I took note when you added this.
Tony,
Would you participate in this?
Regards,
Richard W.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Nicolas Pitre
Sent: Monday, April 28, 2008 4:29 PM
To: Andrew Morton
Cc: Russell King - ARM Linux; [EMAIL PROTECTED]
Subject: Re: Fwd:
Enabling L2 cache was removed from proc-v7.S since was cortex specific
instead of armv7 specific and u-boot explicitly turns of L2 before
booting into linux. I made a reverse patch, but my omap3 board doesn't
boot if I use it:
Our 2.6.24 kernel does something close and boots fine on OMAP3-SDP
So what about this?
-Original Message-
From: Woodruff, Richard
Sent: Friday, April 04, 2008 3:04 PM
To: Tony Lindgren
Cc: Kevin Hilman; linux-omap@vger.kernel.org
Subject: [PATCH] timer optimization part 2.
Hi,
This patch adds a new function timer_load_start() which optimizes
On Mon, May 19, 2008 at 6:48 PM, Woodruff, Richard [EMAIL PROTECTED]
wrote:
You are just talking about your logo disappearing (usually tux)?
No not just tux.
If i run tslib (ts_test) and suspend resume the
board then also the same behavior is happening.
ie. The normal ts_test screen
On Tue, 17 Jun 2008 10:31:11 +0300, Jouni Hogander
[EMAIL PROTECTED] wrote:
Current hsmmc is not pm friendly. Disable it because it prevents omap3
retention
Disabling will just hide the bug. Better making it modular
and let mmc guys dig on it.
What do you need to make it more pm
If anyone wants I'll re-send larger trace pictures individually.
care to send it to my nokia mail?
felipe 'dot' balbi 'at' nokia 'dot' com
Ok.
I'll take a shot at this patch after summer holidays.
Ok. I did catch Thomas G. on IRC and he indicated it seemed fine and would try
later after
Perhaps more exciting would be to make sure x86 didn't care. My ARM
targets only work better.
better sending to lkml, then?
Actually I did that first when my confidence was high. No obvious interest.
The signal to noise ratio is pretty high. David B. did comment. As its
important for
PowerTOP version 1.10 (C) 2007 Intel Corporation
CnAvg residency P-states (frequencies)
C0 (cpu running)( 0.0%)
C00.0ms ( 0.0%)
C1 188.9ms (0.7%)*
C2 2036.1ms (8.0%)*
C3 23285.1ms (91.3%)*
Hi,
I was just debugging some hang and noticed that the WAKEUPEN bits of gpio banks
was cleared out unexpectedly when doing a post mordem.
The array in 1466 will almost be certainly wrong on an OMAP3. It's probably a
bit off for OMAP2 for that matter. Things which are not wake up capable
Hi,
On Mon, 2008-06-30 at 07:45 -0500, ext Woodruff, Richard wrote:
For things like bluetooth or other the protocol should re-transmit.
That's avoided with an out of band irq.
That can work assuming that external device gives you a 'pre' interrupt before
it generates the real timing
I forgot to mention that it seems that HS OMAP or something is
ceasing the operation just few seconds after bootup. Initfs gets
more scripts executed but Debian from mtdblock4 hangs just in init.
That is an odd statement. Are you commenting about an EMU/HS chip
resetting during
I am still trying to find my way thru the codebase in GIT; but here is
what I can suggest based on similar problem diagnosed (still under
test) on the OMAP3EVM:
1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2
2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2
For sure save/restore of
[x] Has anyone fixed the broken gpio wakeup enable code?
Right now this might even kill you as it will clear you
wakeup enable register. This could stop you from waking
from a partially idle/clock stop condition on the L3?
The problem was actually related
Hi Paul,
SRAM being mapped as cacheable could be a possible reason for this.
Second this.
Certainly possible, and that change needs to be included. But why
would
it only happen on the M2 2 - 1 transition?
Can you ping the board by chance when you are locked? Is only user space
locked
SRAM being mapped as cacheable could be a possible reason for
this.
Second this.
Yeah, agreed that it needs to be done, but SRAM in CDP 12.17 is still
marked cacheable too, right? Did CORE M2 divider changes work in CDP
12.17?
No CDP has it marked strongly order for a while now.
Hi,
I think we have now all the pieces here to get stable cpuidle +
pm_idle + suspend + off mode with minimal configuration on SDP
board. Could you Rajendra now gather these together and prepare new
patch set in sensible format?
Yes, I will do that. Will re-send the complete patch set
It is not so clear if gpio that hack is even needed on OMAP3. There
is some warning about spurious interrupts when going to RET/OFF for
OMAP2. I don't recall for OMAP3. didn't those prepare functions dink
with wake up masks in fear of spurious interrupts. So, wasn't the
result for you
The current check will: On activity raise a cpuidle bus master
activity failure for some number of seconds. This allows normal
typing for extended periods. It does this by marking UART function
IRQs with a time stamp and it checks internal state to make sure
RX/TX engine is not busy or
When OFF/RET mode is selected IO pad is enabled for the port
wakeup.
I have seen this in CDP reference code. Is there some specific
reason
why this is enabled dynamically in code?
Not that I am aware.
Do you think there is a need to toggle it? Today only the global
IOPAD
How about renaming it to twl92230c before submitting upstream? As far
as I can tell the name menelaus appears only in linux and makes it
hard to associate with the real hardware. Does someone know why was
it renamed that way?
The name was just an internal project name for that IO companion
Hi Peter,
Using Rajendra's cpuidle and offmode patches + the patches I posted to
configure triton2 and set the correct off mode polarity, I noticed the
system does not go to off mode when smartreflex is enabled. At least
sysoffmode is not deasserted and the VDD1 and VDD2 voltages do not
drop
The most visible BE-ARM seems to be Intel's IXP network processors.
The IXPs are one of the few cases where the vendors _ships an all-BE
software development environment by default_ -- but that doesn't mean
that BE doesn't work on ARM CPUs where the vendor ships a LE software
development
Hmmm. So bit [7] of the system control register is ignored entirely,
and if you write a 1 to it, nothing at all happens and the system
boots as usual? (To test, add a line OBJS += big-endian.o to the
top of arch/arm/boot/compressed/Makefile.)
Does it also mean that the ARMv6 based OMAPs
This needs to go in via LKML, I think Thomas Gleixner is looking into
it.
* Today it is in Andrew Morton's tree.
* Thomas has been in copy and Andrew has ack'ed it. So far Thomas hasn't had
much interest. I haven't bugged him since Andrew picked it up as I guess it
will flow in from his
Why not use normal uncached memory? Strongly ordered is pretty
inefficient as it cannot do any reordering or write buffer merging
(it's
like having a memory barrier before and after each instruction).
Speculative accesses are not allowed either. Strongly ordered memory
is
not really meant
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
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 tracked
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
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by
Richard
in 8250.c
I doubt that your changes to 8250.c will be applied. I have understood
that omap specific changes are not accepted to generic 8250
driver.
Hi,
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Tony Lindgren
* Hiroshi DOYU [EMAIL PROTECTED] [080815 13:34]:
Thank you guys for your comments,
It seems that some of the patches couldn't be sent to ML because of
the size limitation of vger.kernel.org ML.
Hi Felipe,
[EMAIL PROTECTED] On Behalf Of Felipe Contreras
snip
As part of contributing this code there has been a lot of reworking
of the code. Last I had heard checkpatch and sparse warnings had been
killed. There was also a lot of work in making sure there would be no
legal impact to
Hi,
[EMAIL PROTECTED] On Behalf Of Jarkko Lavinen
2: Disable smartidle mode while suspending (workaround)
This was the work around we had in internal trees for a long time.
However Madhu C. recently updated this based on an internal investigation. It
is required to reset the command pin
I think recently some one from TI posted OMAP3 camera driver at
linux-v4l2 mailing list and which I think was using camera MMU, but
not the common MMU framework it seems from the description. They
should first start converting to the common MMU infrastructure then.
Hi Hiroshi,
I sent some patches based on the above suggestion.
http://marc.info/?l=linux-omapm=121922597019873w=2
http://marc.info/?l=linux-omapm=121922593919766w=2
I think that this virtual clock may allow any arbitrary combination of
clocks and it may be possible to have multiple
Hi Hiroshi,
-Original Message-
From: Hiroshi DOYU [mailto:[EMAIL PROTECTED]
snip
I think that, in this virtual clock, frequency changing will be done
in the totally different path(just in a normal clock tree). This
virtual clock resides in an independent clock tree and supposed to
http://www.linuxdevices.com/news/NS8246055816.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Wednesday, September 15, 2010 2:15 PM
This patch fixes this problem by ensuring the branch prediction logic is
disabled while changing the L3 clock frequency. The branch
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Thursday, September 16, 2010 3:50 PM
Sounds fair. But it might be worth checking that you guys have a system
in place for collecting omap specific fixes and promptly merging
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Friday, December 31, 2010 2:02 AM
Is this true for OMAP2 as well?
OMAP2 used VSEL for direct and VMODE for voltage control not SR path methods. I
don't recall OMAP2 ever
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, January 14, 2011 6:03 PM
I've been seeing this on my omap4 panda. While debugging it, I left
u-boot console only running for a few minutes to see if that stays up.
It did.. And after doing that somehow now my panda boots all the
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, January 15, 2011 5:38 PM
Why does OMAP initialize its clock sources soo late, outside of
the timer initialization? This means you have no counter in place
(except for the jiffies counter) during early boot.
Is
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, January 17, 2011 11:35 AM
This happened for a few days both with 2.6.37 and current mainline
kernel. After I started debugging it went away with no changes to
anything.. So can't debug any further at this point unfortunately.
Odd.
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, January 05, 2010 11:54 AM
Also, what's the Cortex version on your v7? It's rev r2p3 on
omap3430.
Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and
From: ext-ari.kau...@nokia.com [mailto:ext-ari.kau...@nokia.com]
Sent: Saturday, October 31, 2009 4:40 AM
@@ -60,6 +60,9 @@ struct dpll_data {
void __iomem*idlest_reg;
u32 autoidle_mask;
u32 freqsel_mask;
+ u32
Hi Paul,
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, October 28, 2009 9:39 PM
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16 m,
u8 n)
+{
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ n++; /*
* Woodruff, Richard [EMAIL PROTECTED] [081014 12:47]:
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load);
- omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
}
I seem to recall
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Felipe Contreras
Sent: Saturday, November 29, 2008 6:52 AM
On Thu, Nov 27, 2008 at 2:29 AM, Kevin Hilman
[EMAIL PROTECTED] wrote:
This series enables UART clock disabling after an inactivity period.
It is based
From: Igor Stoppa [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 29, 2008 10:07 AM
On Sat, 2008-11-29 at 07:55 -0600, ext Woodruff, Richard wrote:
Not unless you use some kind of flow control or protocol retransmits.
What about bitbanging the entire first character?
Huh?
Typically
On Thu, Dec 04, 2008 at 06:41:21PM -0800, Tony Lindgren wrote:
omap_dm_timer_write_reg() already waits for pending writes to complete,
so the extra wait in omap_dm_timer_set_load() is superfluous.
Is this right? I mean - do you have to wait for each individual write
to each register to
Hi,
this 22-patch series updates the OMAP1/2/3 clock code. Highlights:
For OMAP3 as long as there is attention, much seems nice. I can't really
appreciate with out spending a lot more time.
Is there any way to get more OMAP1/2 testing? It would be nice to not cut off
any other upper level
Hi,
clockevent_delta2ns() used to initialize min_delta_ns rounds the value
down, so the result can be too small. When clockevents_program_event()
is using too small value it will try to program the timer with zero
ticks stalling the timer queue.
+ clockevent_delta2ns(1,
Hi,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aaro Koskinen
Sent: Friday, January 02, 2009 9:07 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP2: gptimer min_delta_ns corrected
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Hi,
* Hiremath, Vaibhav hvaib...@ti.com [090106 13:13]:
For capture driver I am also getting similar messages
4Spurious irq 95: 0xffdf, please flush posted write for irq 24
Spurious irq 95: 0xffdf, please flush posted write for irq 24
4Spurious irq 95: 0xffdf, please flush
Yes Russell doesn't like it. However, I didn't see any viable alternate
solution offered. If ARM or any hardware vendor does something badly in
hardware punishing the current generation in hopes of changing the next
is not so good. Especially if some work around exists.
I do hope you
Can some one help?
Ask at omapandroid-discuss...@omapzoom.org for zoom relegated android issues.
You can subscribe from the zoom site.
Regards,
Richard W.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
Hi,
a few quick comments, possibly nit-picking...
On Wed, 31 Dec 2008, Woodruff, Richard wrote:
Actually, the functional spec for timer says max re-sync time is:
3 OCP clock + 2.5 TIMER clock
3(1/83MHz) + 76uS = ~76uS
The OCP clock rate is dependent on the timer's
I'm trying to get powertop running on the latest git. It basically
works, but I do not get displays for the C and P states. This has worked
in the past, but the OE kernel I'm using had a lot of patches then :)
Does anyone have a list of things to check, before I start working
through my
Which says to me that grumbling about strongly ordered regions
is more of a developer discipline/training problem than any
kind of real technical issue. Not unlike how to do locking
right; or satisfy coding style guidelines; or follow correct
procedures to merge patches; or synchronize
With OMAP3530 on BeagleBoard we like to read OMAP3's
CONTROL_RAND_KEY_0 (0x4800 2318) register with something like
printf (attempting cpu_uid read\n);
u32 cpu_uid = *((u32 *) 0x48002318);
/* u32 cpu_uid = readl(ctrl_base-randkey_0); */
printf (cpu_uid read done\n);
This address is not
Subject: Question on how to best access a chip on init that needs VAUX1 power?
On the OMAP board I have, I want to access production information
(model, serial number, MAC addresses, etc), and the part requires 3v
which is powered off of VAUX1.
I need to pull this out at initialization time,
u-boot also has simple utility to read from mtd which has u-boot environment
where you could have stored it away.
Ultimately I should just pull the block of data in u-boot, extract what
I need for u-boot, and then pass it to the kernel. Outside of creating
a specific ATAG for this, what's
Running with latest linux-omap kernel on OMAP3 SDP board, I have problem
with iounmap(). It looks like iounmap() does not properly free large
areas. Below is a test which fails for me in 6-7 loops.
OMAP spesific ioremap code doesn't do much, so I think it's somewhere in
generic ARM code. I
The other thing to point out is that vunmap() does its work lazily
(as Richard tried to point out). However, it'll become unlazy when
it has more than 32MB * NR_CPUS to deal with. So, make sure that your
ioremap/vmalloc region is larger than 32MB otherwise you'll still see
crashes.
Where
Alternatively, you you do some experiments to see exactly which
C-states are causing the problems. You could modify cpuidle34xx.c and
set the 'valid' flag in the higher C-states to zero so that they
cannot be entered and see which C-states (if any) are working.
I recently added the
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Reviews and comments obviously welcome, testing more preferred. Probably
the easiest way to apply these changes for testing is to download the
diffs from the FTP site:
34xx TRM Delta G-H notes that the CORE powerdomain has a hardware
save-and-restore (SAR) control bit for the USBTLL module, similar to
the USBHOST powerdomain SAR bit. Split the existing core_34xx struct
powerdomain into two structs, one for ES1 and one for ES2, and add the
There's one bug that your version highlights in mine - the virtual mpu
clock in omap1 touches the DPLL and repropagates that rate. I've
removed that repropagation, so that needs fixing.
However, this raises a question: why is the virtual mpu clock touching
some other part of the clock
I wait for a min and try to wakeup - It works.
If i wait a little longer before waking it up say, 3 or 4 minutes.
It does not wakeup.
That is consistent with your memory not being placed into self refresh properly.
5 general bugs I've seen over time:
sw bug:
-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Friday, January 30, 2009 11:12 AM
Another possibility is that the the memory timings for the custom
board are not set correctly.
Yes this is correct also. For example if the XSR field is wrong in SDRC
registers (exit from self refresh
Just a thought, do you still see these problems when using the CPUfreq
performance governor instead of the ondemand governor?
It could be pointing to some bugs in the switching of operating
points.
Speaking of operating points, is there a reason why cpufreq only goes
to 550MHz? It's
If you look at http://beagleboard.org/hardware it says 600Mhz
multiple times, so I'd expect the board to be running at 600MHz if I
were a customer. If I read the TRM right I can run the cpu at 600MHz
continuously for a few years, which exceeds the lifespan of most
mobile products I have
In fact, you wouldn't even need a custom governor.
To avoid governor picking overdrive OPP:
# echo 55 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
To allow overdrive:
# echo 60 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
Sure. Now is someone going to fix up
Here should be 0x100. Fixing this won't cause problems with smsc911x
patches.
Yes it will - if it gets fixed in the -rc series for the smc911x driver
your patches will conflict.
There's more which needs fixing though - no platform data is being passed
so the smc911x driver still fails to
Virtual clocks should soon be eliminated from the OMAP clock tree. (
Virtual clocks is here used to refer a clock that does not have a
referent in the hardware; the usage of the term in the code is loose.)
So far as I know, all of the OMAP virtual clocks have either turned out to
be
Hi,
Recently one custom board was having some I2C issues. In looking at it a couple
things stood out. I've attached a patches for l-o and l-z for anyone to
comment on which cares.
Bug Fixes:
-1- OMAP_I2C_WE_STC_WE should never be enabled for wake up unless I+F
clk is cut. Having it
Hi,
Could you please also address the question of the load on the SCL line?
Are you talking about rise/fall time?
I can comment on bits I picked up reading and talking to others.
The current data sheets I looked at give a couple kinds of guidance for
resistor usage. One type has you measure
From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com]
On Mon, 2009-02-16 at 15:19 +0100, ext Woodruff, Richard wrote:
Hi,
Could you please also address the question of the load on the SCL line?
Are you talking about rise/fall time?
Sorry for being unclear;
The I2C standard
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Thursday, February 19, 2009 6:20 AM
Consider what happens when a clock is enabled - we walk up the tree
enabling all parents. If we then change the clock's parent, and
then disable the child, we will again walk
Eero,
From: Eero Nurkkala [mailto:ext-eero.nurkk...@nokia.com]
On Mon, 2009-02-16 at 15:19 +0100, ext Woodruff, Richard wrote:
Hi,
Could you please also address the question of the load on the SCL line?
Are you talking about rise/fall time?
Sorry for being unclear
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, February 23, 2009 10:04 AM
To: Woodruff, Richard
Ack?
Ack.
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
Well, it's implicite... Check the i2c spec table 7 for speeds 3400 and
1700. If you use TRM calculcations so that tLow == tHigh you get too
tLow that's below the minimum in both cases. So you must increase tLow,
and when you do that you must make tHigh shorter, otherwise you don't
match
Part of it is a poor prediction. A while back, I had hacked in a simple irq
time stamp and used a kind of crude running average over all irq sources. Then
I added this info into cpuidle for next state prediction. It did improve
latency a quite a bit. Simple idea is irqs might cluster and
I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
(and thus LOCKDEP) are disabled.
Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
but IRQF_DISABLED is needed for proper behaviour.
I only submitted on l-o list for information and comment.
How about McBSP? Same TRM.. I2C, Table 18-5 tells exactly the opposite
for I2C than what's said in Table 18-44: I2C_SYSC!!
Please, Richard?
- Eero
To answer to myself, I am 100% certain the McBSP FCLK is the
bit 8. I should have sent a patch about that already..
Kind of worried as
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Wednesday, March 11, 2009 9:51 AM
With the latest linux-omap pm + gitorious bridge changes on SDP3430, enabling
BRIDGE_DVFS and SRF seems to cause an issue with clock
From: Menon, Nishanth
Sent: Wednesday, March 11, 2009 11:33 AM
Does it need DVFS enabled to fail? Is voltage high enough (to current DM)?
There were some issues there.
Yes, Rajendra's VDD change is merged in [1] pm branch.
Ok.
It does not make sense for clock notifier_registration to
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kauppi Ari (EXT-Ixonos/Oulu)
Sent: Thursday, March 12, 2009 6:34 AM
3) Apply Richard's patch. All spurious interrupts for IRQ 56 are gone
but frequency of others increase.
The bugs fixed in
From: Felipe Balbi [mailto:[EMAIL PROTECTED]
On Fri, Aug 22, 2008 at 11:32:49PM +0300, Igor Stoppa wrote:
http://www.speaknspell.co.uk/speaknspell.html
wins hands down :-D
ehehe, great. My new time killer application :-)
I did work with someone who was on that project. He had a lot of
Hi,
From: David Brownell [mailto:[EMAIL PROTECTED]
Actually, this was talked about before a bit and the
SZ_xyz flags were left out.
The point of telling the geometry in the addition was
to be explicit about the number of sectors being used.
So ... this instead?
Yes that looks good
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Russell King - ARM Linux
Sent: Wednesday, September 03, 2008 2:34 PM
snip
The question is why do we need it? If the correct physical address
is passed, then things should work out just fine anyway, especially
if
From: David Brownell [mailto:[EMAIL PROTECTED]
snip
On Wednesday 03 September 2008, Woodruff, Richard wrote:
Fixed translations do have some benefits. You can ensure that you
are using section or super section descriptors to cover large areas.
This does result in better TLB usage. Along
Hi,
I have one problem - in 2.6.14 we used the enable_mmc_power function,
which is completely gone in 2.6.24, and i can't seem to find any
reasonable replacement. could you please assist me how can I power up
the mmc controller in 2.6.24 ?
(we have legacy reasons for not using the in-tree
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Russell King - ARM Linux
Well, the first question is... where has this come from, and why.
In OMAPs, a few devices have a local IO MMU. Their basic structure is similar
to an ARM MMU, but less featured. IVA Camera
Hi,
The usage in TI kernels has varied a bit. Some times they are just
load and lock TLB's, for others table walking can be enabled. In
all cases if a table walk miss happens it is fatal and the IP block
device will have to be reset.
In *theory*, from this IOMMU hardware perspective,
1 - 100 of 207 matches
Mail list logo
