* Re: "lseek/write char driver" versus "usermode iomem access"
From: David Hawkins @ 2006-03-29 16:46 UTC (permalink / raw)
To: Josef Angermeier; +Cc: linuxppc-embedded
In-Reply-To: <442A43C6.5050605@cs.fau.de>
> besides adapting linux to my custom board, i now have to write a driver
> for a special device. This device mainly consists of an up to 512 bytes
> big IO memory. Because performance matters alot, i wonder if i shall
> write a simple char driver offering a write/lseek-interface to access
> this memory or if i shall do something new to me, mapping the IO-memory
> to the userspace, so that the user-program can directly access the
> device memory. Can anyone tell me how performance probably differs
> between those two design.
>
> Thanks, you probably save me alot of time to tryout!
Hi Josef,
Here's a couple of comments that may help:
lseek()/read()/write():
- read and write need to use copy_to_user and copy_from_user
commands to copy bytes from the registers into the user-space
buffer.
mmap()
- maps pages directly, so avoids the overhead of the copy_xx_user
calls.
So, if you have a set of control *registers* that you want to
manipulate, then mmap would be recommended.
However, this 512-bytes of memory is just that, *memory*, and the
requirement is to move it off the device as fast as possible,
then you probably want to create a device that has a linked
list of 512-byte buffers internally, and use a DMA channel
to move data from the device into the buffer. Then the
'read' function of the driver would consume the contents of
the buffer.
So, as always, things are application dependent. If you
could describe things in more detail, I can help make
more suggestions and supply you with code.
Regards,
Dave
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Heiko J Schick @ 2006-03-29 16:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <2691DBEE-C7E2-46A3-8455-6F98806C3102@kernel.crashing.org>
Hello,
On 29.03.2006, at 17:09, Segher Boessenkool wrote:
> All the other defines use StudlyCaps, yours use SHOUTING_CAPS, you
> might want to choose just one style (though I prefer the shouting
> one).
if StudlyCaps are better (and more readable) than SHOUTING CAPS I can
change it. Not a big deal.
Regards,
Heiko
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Heiko J Schick @ 2006-03-29 16:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <2691DBEE-C7E2-46A3-8455-6F98806C3102@kernel.crashing.org>
Hello Segher,
On 29.03.2006, at 17:09, Segher Boessenkool wrote:
> and it looks like you posted two
> patches
I've posted the patch as attachment and and directly in the
e-mail. I think my mail application messed it up. Sorry. I
will post the next patches without attachment. Thanks for
your comment.
Regards,
Heiko
^ permalink raw reply
* Re: [OT] ppc64 serialization problem
From: Greg Smith @ 2006-03-29 18:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17450.2061.510951.479016@cargo.ozlabs.ibm.com>
On Wed, 2006-03-29 at 15:07 +1100, Paul Mackerras wrote:
> Greg Smith writes:
>
> > On rare occasions, values A and B will differ! In the examples that I
> > have seen, there is contention with `lock'. This phenomenon does not
> > occur on ppc32 or a number of other architectures that we support.
>
> I would be interested to see the assembler code being generated for
> your code snippets.
>
> Paul.
This is looking like a compiler optimization issue. We have two fields
_u32 x,y;
Field y is what we are trying to serialize with the lock. However,
while we are doing that it appears another thread is updating x. When x
is updated and with optimization, the code is doing an 8 byte load of x
and y then doing an 8 byte store, wiping out what was stored in y.
Which explains why changing the type to _u64 seemed to fix the problem.
Below are some of the notes the other developer sent me.
Thanks,
Greg Smith
There are OTHER field neighbouring the ints_state field.. (and this is
probably some of the flags)..
gcc, when optimizing, gcc load and stores 64 bit values, *INCLUDING* the
ints_state field effectivelly breaking serialization.
Here is a sample program :
struct _test1
{
unsigned long long z;
unsigned char c;
unsigned int a:1;
const volatile unsigned int b;
};
int main()
{
}
unsigned int toto(struct _test1 *data)
{
data->a=1;
return data->b;
}
And here is the relevant asm snippet :
.A
ld 11,8(9) - get 64 bits ->a
lis 0,0x80 *
sldi 0,0,32 *
or 0,11,0 *
.B
std 0,8(9) * Store 64 bits -> a
ld 9,112(31) *
lwz 0,12(9) * get 32 bit b
So it is clear between .A and .B -> value of b was read then written. If
anything happens between .A and .B to ->b, then it is lost.
^ permalink raw reply
* Re: [OT] ppc64 serialization problem
From: Olaf Hering @ 2006-03-29 18:32 UTC (permalink / raw)
To: Greg Smith; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1143656433.3075.108.camel@localhost.localdomain>
On Wed, Mar 29, Greg Smith wrote:
> So it is clear between .A and .B -> value of b was read then written. If
> anything happens between .A and .B to ->b, then it is lost.
Even gcc4.1 does it that way with -O0.
^ permalink raw reply
* Re: [OT] ppc64 serialization problem
From: Ivan Warren @ 2006-03-29 18:42 UTC (permalink / raw)
To: Olaf Hering; +Cc: Greg Smith, linuxppc-dev, Paul Mackerras
In-Reply-To: <20060329183259.GA18514@suse.de>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Olaf Hering wrote:
> On Wed, Mar 29, Greg Smith wrote:
>
>
>> So it is clear between .A and .B -> value of b was read then written. If
>> anything happens between .A and .B to ->b, then it is lost.
>>
>
> Even gcc4.1 does it that way with -O0
Yeah.. Noticed that..gcc 3.3.3 and gcc 4.0.3 also do this
Even declaring the field volatile has no effect..
Question :
Is this *NORMAL* behavior ? I discussed this with some C folks and they
seem to think (at least some of them) that it's broken per standards..
(volatile fields should be only read/written IFF read/written explicitly
- pretty much what section 6.3.7 of the C std says).
Anyway I can produce perfectly valid sample code (to my understanding
anyway) that produces incorrect result.. YUCK !
This is also possibly a problem with the powerpc64 back end of gcc..
Anyway.. It's OT.. Sorry to have bothered you guys ! (And thanks Greg
for pointing me here).
--Ivan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3216 bytes --]
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Wolfgang Denk @ 2006-03-29 20:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060329153941.GD95498@server.idefix.loc>
Dear Matthias,
in message <20060329153941.GD95498@server.idefix.loc> you wrote:
>
> i tried the following trees:
> linux-2.6.15 (from kernel.org)
> linux-2.6-denx (from cg-clone http://www.denx.de/git/<project_name>)
MPC5200 support known to be broken in these two.
> linux-2.6-denx-git (see above)
Does not exist...
> linuxppc_2_4_mpc5200 (see above)
Is NOT a git repository and marked as obsolete.
The only stable tree we offer for 5200 is the linuxppc_2_4_devel
tree.
> > > I copied the file arch/ppc/configs/lite5200_defconfig to .config, and
> > > tried the following one:
> > > make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
> >
> > That's not the official way to build images.
>
> oh, sry I played with crosscompiling the firt time, it would be a
> pleasure for me if you could correct me.
Read the README, and probably the DULG. You missed at leat the "make
oldconfig" step which is essential.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Blast medicine anyway! We've learned to tie into every organ in the
human body but one. The brain! The brain is what life is all about.
-- McCoy, "The Menagerie", stardate 3012.4
^ permalink raw reply
* Re: [OT] ppc64 serialization problem
From: Ivan Warren @ 2006-03-29 21:29 UTC (permalink / raw)
To: Ivan Warren; +Cc: Greg Smith, linuxppc-dev, Paul Mackerras, Olaf Hering
In-Reply-To: <442AD531.2040702@vmfacility.fr>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
Ivan Warren wrote:
> Question :
> Is this *NORMAL* behavior ? I discussed this with some C folks and
> they seem to think (at least some of them) that it's broken per
> standards.. (volatile fields should be only read/written IFF
> read/written explicitly - pretty much what section 6.3.7 of the C std
> says).
>
...For Info...
I've submitted a gcc PR :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
Anyway.. My apologies since this was a bit off topic..
--Ivan
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3216 bytes --]
^ permalink raw reply
* [PATCH]: powerpc/pseries: print message if EEH recovery fails
From: Linas Vepstas @ 2006-03-29 21:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-pci, linux-kernel
Paul,
Pleae review/apply/forward upstream.
--linas
[PATCH]: powerpc/pseries: print message if EEH recovery fails
The current code prints an ambiguous message if the recovery
of a failed PCI device fails. Give this special case its own
unique message.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
Index: linux-2.6.16-git6/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.16-git6.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-03-29 14:45:42.000000000 -0600
+++ linux-2.6.16-git6/arch/powerpc/platforms/pseries/eeh_driver.c 2006-03-29 15:02:19.648928196 -0600
@@ -301,7 +301,7 @@ void handle_eeh_events (struct eeh_event
}
if (frozen_pdn->eeh_freeze_count > EEH_MAX_ALLOWED_FREEZES)
- goto hard_fail;
+ goto excess_failures;
/* If the reset state is a '5' and the time to reset is 0 (infinity)
* or is more then 15 seconds, then mark this as a permanent failure.
@@ -356,7 +356,7 @@ void handle_eeh_events (struct eeh_event
return;
-hard_fail:
+excess_failures:
/*
* About 90% of all real-life EEH failures in the field
* are due to poorly seated PCI cards. Only 10% or so are
@@ -367,7 +367,15 @@ hard_fail:
"and has been permanently disabled. Please try reseating\n"
"this device or replacing it.\n",
drv_str, pci_str, frozen_pdn->eeh_freeze_count);
+ goto perm_error;
+
+hard_fail:
+ printk(KERN_ERR
+ "EEH: Unable to recover from failure of PCI device %s - %s\n"
+ "Please try reseating this device or replacing it.\n",
+ drv_str, pci_str);
+perm_error:
eeh_slot_error_detail(frozen_pdn, 2 /* Permanent Error */);
/* Notify all devices that they're about to go down. */
^ permalink raw reply
* [PATCH]: powerpc/pseries: mutex lock to serialze EEH event processing
From: Linas Vepstas @ 2006-03-29 21:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-pci, linux-kernel
Paul,
Please review/apply/forward upstream. Seems I forgot to do this before.
--linas
[PATCH]: powerpc/pseries: mutex lock to serialze EEH event processing
This patch forces the processing of EEH PCI events to be serialized,
using a very simple mutex lock. This serialization is required to
avoid races involving additional PCI device failures that may occur
during the recovery hase of a previous failure.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_event.c | 30 +++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
Index: linux-2.6.16-git6/arch/powerpc/platforms/pseries/eeh_event.c
===================================================================
--- linux-2.6.16-git6.orig/arch/powerpc/platforms/pseries/eeh_event.c 2006-03-28 17:44:38.000000000 -0600
+++ linux-2.6.16-git6/arch/powerpc/platforms/pseries/eeh_event.c 2006-03-29 14:45:42.522111515 -0600
@@ -19,7 +19,9 @@
*/
#include <linux/list.h>
+#include <linux/mutex.h>
#include <linux/pci.h>
+#include <linux/workqueue.h>
#include <asm/eeh_event.h>
#include <asm/ppc-pci.h>
@@ -37,14 +39,18 @@ LIST_HEAD(eeh_eventlist);
static void eeh_thread_launcher(void *);
DECLARE_WORK(eeh_event_wq, eeh_thread_launcher, NULL);
+/* Serialize reset sequences for a given pci device */
+DEFINE_MUTEX(eeh_event_mutex);
+
/**
- * eeh_event_handler - dispatch EEH events. The detection of a frozen
- * slot can occur inside an interrupt, where it can be hard to do
- * anything about it. The goal of this routine is to pull these
- * detection events out of the context of the interrupt handler, and
- * re-dispatch them for processing at a later time in a normal context.
- *
+ * eeh_event_handler - dispatch EEH events.
* @dummy - unused
+ *
+ * The detection of a frozen slot can occur inside an interrupt,
+ * where it can be hard to do anything about it. The goal of this
+ * routine is to pull these detection events out of the context
+ * of the interrupt handler, and re-dispatch them for processing
+ * at a later time in a normal context.
*/
static int eeh_event_handler(void * dummy)
{
@@ -64,23 +70,24 @@ static int eeh_event_handler(void * dumm
event = list_entry(eeh_eventlist.next, struct eeh_event, list);
list_del(&event->list);
}
-
- if (event)
- eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
-
spin_unlock_irqrestore(&eeh_eventlist_lock, flags);
+
if (event == NULL)
break;
+ /* Serialize processing of EEH events */
+ mutex_lock(&eeh_event_mutex);
+ eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
+
printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
pci_name(event->dev));
handle_eeh_events(event);
eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
-
pci_dev_put(event->dev);
kfree(event);
+ mutex_unlock(&eeh_event_mutex);
}
return 0;
@@ -88,7 +95,6 @@ static int eeh_event_handler(void * dumm
/**
* eeh_thread_launcher
- *
* @dummy - unused
*/
static void eeh_thread_launcher(void *dummy)
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Benjamin Herrenschmidt @ 2006-03-29 22:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143637243.9481.17.camel@localhost>
On Wed, 2006-03-29 at 15:00 +0200, Johannes Berg wrote:
> On Wed, 2006-03-29 at 15:01 +1100, Benjamin Herrenschmidt wrote:
> > BTW.. with the current stuff, if I install the modules and then do
> >
> > modprobe i2sbus
> >
> > I get a registration error in dmesg.
>
> Hmm. What's the error? Can't reproduce this at all. Also, what machine?
> It works fine on my powermac, even when i2sbus is auto-loaded due to
> binding to the macio i2s device alias.
On the laptop.
Mar 29 11:11:51 localhost kernel: [ 192.069735] i2sbus: found i2s
controller
Mar 29 11:11:51 localhost kernel: [ 192.069752] soundbus: adding device
failed sanity check!
Mar 29 11:11:51 localhost kernel: [ 192.069757] i2sbus: device
registration error!
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Sylvain Munaut @ 2006-03-29 23:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060329201128.2FB713535EE@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Matthias,
>
> in message <20060329153941.GD95498@server.idefix.loc> you wrote:
>
>> i tried the following trees:
>> linux-2.6.15 (from kernel.org)
>> linux-2.6-denx (from cg-clone http://www.denx.de/git/<project_name>)
>>
>
> MPC5200 support known to be broken in these two.
>
It is ?
I don't know about the 2.6-denx, but the stock 2.6.15 should work just fine.
What's wrong with it ? (except it misses some drivers ... it should compile
and boot just fine)
Sylvain
^ permalink raw reply
* Re: [PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
From: Jeff Garzik @ 2006-03-29 22:35 UTC (permalink / raw)
To: Linas Vepstas; +Cc: tsbogend, netdev, linux-kernel, jklewis, linuxppc-dev, donf
In-Reply-To: <20060328223623.GD2172@austin.ibm.com>
Linas Vepstas wrote:
> Please sign-off/ack/apply and/or forward upstream.
>
> [PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
>
> The comments concerning how the pcnet32 ethernet device driver selects
> the MAC addr to use are incorrect. A recent patch (in the last 3 months)
> changed how the code worked, but did not change the comments.
>
> Side comment: the new behaviour is good; I've got a pcnet32 card which
> powers up with garbage in the CSR's, and a good MAC addr in the PROM.
>
> Signed-off-by: Linas Vepstas <linas@linas.org>
applied
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Benjamin Herrenschmidt @ 2006-03-29 23:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143637899.9481.28.camel@localhost>
> Note sure what you mean here...
I'll come back with a better explanation later :) I want first to have a
look at the most recent code and think a bit more :)
> > Then, the core would get events from interrupts (or clock switches from
> > the codecs) via a yet-to-be-defined call and would react by calling the
> > various mute/unmutes accordingly for available inputs and outputs on the
> > bus where the event occured.
>
> Ah but you see, the codec actually "mutes" the digital output when it
> isn't usable, and the codec also mutes the analog output when we
> transfer compressed data. We don't amp-mute in that case, but just from
> the codec, so no analog audio is even leaving the codec.
Yes, but we should probably still mute the amps... especially when using
a separate analog codec (like tas3004 + topaz setups).
> > For things like headphone/speaker automute, I think we need a kind of
> > tristate.. either that, or we need a bit mask of mute conditions. When
> > any of them is set, it's muted. That way, the "user" mute control sticks
> > regardless of the automute action or temporary mute to analog outputs
> > because, for example, the digital input lost its clock and we are
> > switching (we need to mute to avoid "clics").
>
> Yeah. I have to think a bit about an in-snd-aoa api for all this.
I was thinking about an event based mecanism... snd-aoa has an array of
all inputs & outputs, which codec handles them, and, if relevant,
handles to connector detect GPIOs and amp mute GPIOs.
Then it has an event notification callback that's called in by the codec
and the GPIO interrupts as a result of state changes, clock changes
etc...
>From these, snd-aoa can "do the right thing", do mutes, unmutes, etc..
when needed.
> > Hrm... So my feature calls are doing too much at once... (they both do
> > the clocks and the cell enable). I don't do clock refcounting like Apple
> > does tho, thus the main clock sources are always enabled. So I think all
> > you have to do is toggle the I2Sn_CLK_ENABLE bits ...
>
> Hmm. How do I get at those bits? Clock refcounting would be nice too,
> along with proper power save management...
Clock refcounting will be done ... some other time :)
> > Can you verify if all machines that have digital inputs (thus all
> > machines for which you may need to do that kind of clock switching) also
> > have working platform functions for doing so ? If they do, then it's
> > really just a matter of calling those. If not, then we can either
> > ioremap the FCR's in the driver and play with them (evil solution +
> > possibly locking problems) or add a feature call.
>
> The former isn't feasible since I need to do clock switching even on
> analog-only machines to support more sample rates than the 44.1 KHz that
> the firmware sets for the boing sound :)
And you need to turn the clock off for that ? All the FCRs are useful
for you is to turn the clock input on and off, you shouldn't need that
except when switching to an external clock no ? And even then ... AFAIK,
Darwin AppleOnBoardAudio isn't playing with those FCRs at all unless
I've missed something, all it does is to call in PowerI2S via platform
calls to AppleKeyLargo which is equivalent to the existing pmac feature
call...
I need to understand better what you are exactly trying to do here and
what FCR bits you want to toggle and when.
In any case, if you look at arch/powerpc/platforms/powermac/feature.c,
You can see how FCRs are manipulated. The macros MACIO_IN/OUT read/write
from FCRs and MACIO_BIC/BIS clear/set bits. LOCK/UNLOCK are used to
protect (it's just a spinlock).
Look specifically at g5_i2s_enable() for K2/shasta based machines. There
is also core99_sound_chip_enable() for Keylargo based machines (32 bits
machines) though the current version does nothing to the i2s bus, it
just toggles a GPIO known to control power to the codec on some
machines. That is, it assumes that i2s is enabled and clocked at boot.
The sleep code in there does switch it off on sleep and back on though
but that's a different thing.
> > In the later case, you add a feature call in pmac_feature.h and the
> > appropriate entry in the table in feature.c and then you can toggle bits
> > as you wish with appropriate locking (look at eixsting code in there). I
> > can give you more details on irc if you need.
>
> Ok. I definitely need more details I think.
>
> > But it would be nice if it could all be done with platform functions
> > instead.
>
> Hardly possible though, see above.
Well, again, I have to understand better why here ...You shouldn't need
to touch the FCRs for normal frequency changes unless I missed
something.
> > > Modalias situtation. I played some tricks: i2sbus depends on soundbus
>
> > Yeah :) There might be some issue with the macio automatching from
> > userland, not sure yet, could just be missing bits in hotplug scripts.
>
> macio automatching is working, i2sbus loads, but the latter modules
> don't. I guess there's a userland issue in that it doesn't pick up new
> devices that are added to /sys while it is loading another module.
How so ? autoloading only works for devices on a bus type known by the
autoloader.. like macio. Thus other modules won't autoload unless you
have a bus type that supports the loading stuff for hotplug and
appropriate scripts... macio has such things, I don't think it will
handle your soundbus though without some changes, and the modules
themselves must expose via tables what they match on. I'm not sure I
fully understand what you are expecting there
> > > Recording. There's code to record sound, but it doesn't do anything on
> > > my machine. I have no idea why.
> >
> > What machine ? The quad ? maybe you need some gpio manipulation or maybe
> > you just didn't get something right in onyx ... I'll try later.
>
> Yeah the quad. I was thinking that no matter what, I should at least be
> recording silence, but my userland app (arecord) doesn't get *any* data
> at all. It's like the dbdma controller isn't doing anything.
Maybe you aren;t getting the right addresses for it from OF :) I told
you there are some dodgy things going on with the device-tree ... I
think tx is at 0x8000 and rx at 0x8100 inside the MacIO ASIC (thus
0x8008000 and 0x8008100). Another possibility is that you are
programming it wrong or haven't enabled something somewhere in the codec
to actually emit data :) I'll have a look as soon as I manage to find
some time. Maybe on the plane this week-end.
> > - macio_device gets the suspend resume event. That is, the i2s busses
> > basically. That code should forward to all attaches sub-busses which
> > then dispatch to codecs.
>
> right.
>
> > - ordering of things should be: mute all, stop alsa, stop codecs
> > (enable whatever internal power management mode they may have), stop
> > clocks, disable i2s cells.
>
> yeah. It's slightly more complicated unless we assume that the control
> interface (i2c) is always available, because we'd also get power
> management through the i2c device stuff.
It is always available. Just ignore PM callbacks from i2c
> > I'll play with adapting the whole stuff to older machines, I have plenty
> > of those :) We also need to implement a davbus module, so make sure you
> > don't have too much i2s-related assumptions in your core.. No timeframe
> > for that though, I'm fairly busy with other things at the moment
>
> I don't think there are any i2s assumptions. Well, except that on any
> given soundbus_dev, you have at most one input and one output stream...
That should be ok.
> > It's also a complicated thing because of the need to deal with old
> > machines and the need to coordinate properly & serialize... things like
> > interrupts or events from the codec should, if possible, use alsa hidden
> > controls or whatever other ways to properly serialize, if possible, be
> > run at task level (from a work queue) and things like that (due to the
> > need for delays etc...
>
> Good points.
>
> johannes
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Wolfgang Denk @ 2006-03-30 0:34 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <442B11E8.7020107@246tNt.com>
In message <442B11E8.7020107@246tNt.com> you wrote:
>
> It is ?
I think so.
> I don't know about the 2.6-denx, but the stock 2.6.15 should work just fine.
> What's wrong with it ? (except it misses some drivers ... it should compile
> and boot just fine)
Isn't the current reengineered implementation of the BestComm code
based on an very old Freescale version, which has known limitations
and problems?
Or has there any action resulted out of the discussion with the
Freescale engineers, and I have missed it?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In accord with UNIX philosophy, Perl gives you enough rope to hang
yourself. - L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Benjamin Herrenschmidt @ 2006-03-30 4:19 UTC (permalink / raw)
To: Heiko J Schick; +Cc: linuxppc-dev, paulus
In-Reply-To: <FEF4C367-872B-416D-8166-E439D1F4F9A4@schihei.de>
> if StudlyCaps are better (and more readable) than SHOUTING CAPS I can
> change it. Not a big deal.
They are not... but consistency is better :)
Ben.
^ permalink raw reply
* Re: [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Benjamin Herrenschmidt @ 2006-03-30 4:26 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1143631816.9481.5.camel@localhost>
> + /* so if the workaround is in effect, and we have the right
> + * node found, we increase the workaround count (we use the
> + * same variable) and then set allnextpp to NULL on the second
> + * one around so the node isn't added to the allnodes list */
> + if (powermac_i2c_bus_0_workaround &&
> + strcmp(np->full_name,
> + "/ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0") == 0) {
> + powermac_i2c_bus_0_workaround++;
> + if (powermac_i2c_bus_0_workaround == 3)
> + allnextpp = NULL;
> + }
> + if (allnextpp) {
> + **allnextpp = np;
> + *allnextpp = &np->allnext;
> + if (dad != NULL) {
> + np->parent = dad;
> + /* we temporarily use the next field as `last_child'*/
> + if (dad->next == 0)
> + dad->child = np;
> + else
> + dad->next->sibling = np;
> + dad->next = np;
> + }
> }
> kref_init(&np->kref);
> }
Hrm... you set allnextpp to NULL ... won't that prevent any further node
from being enqueued in the global node list ?
In fact, I think the workaround should be in prom_init.c when
flattening... easier to skip a node there, and that's also where you are
reasonably sure of getting the nodes in the right order, not when
unflattening.
Also, you don't even need to test for PowerMac11,2 .. .prom_init.c
already has a machine type, so just test that it's a mac and has this
node duplicated, and if yes, remove the dup. In fact, you could probably
even run a bit of forth with "interpret" to do so before the tree is
even walked though :)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Heiko J Schick @ 2006-03-30 5:11 UTC (permalink / raw)
To: Herrenschmidt Benjamin; +Cc: linuxppc-dev, paulus
In-Reply-To: <1143692376.16706.5.camel@localhost.localdomain>
Ok, I will change it to StudlyCaps. ;)
On 30.03.2006, at 06:19, Benjamin Herrenschmidt wrote:
>
>> if StudlyCaps are better (and more readable) than SHOUTING CAPS I can
>> change it. Not a big deal.
>
> They are not... but consistency is better :)
>
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Dan Malek @ 2006-03-30 5:05 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com>
On Mar 28, 2006, at 11:14 AM, Vitaly Bordug wrote:
> Updated the documentation to include the initial description of the
> CPM2
> device that are used on PQII and PQIII families.
I haven't followed the device tree development in detail, but when
looking at this the only question that comes to mind is wondering
what this really does to help me. None of the information provided
here is variable nor configurable .... except I guess for the internal
register base address (IMMR), which for some reason has turned
into a variable which hasn't changed since I did the first kernel port.
About the only thing that is variable, which is the two different bank
addresses of the CPM memory that affects the configuration of
the FCCs in Ethernet mode, isn't reflected here in any way.
> + brg@119f0 {
> + device_type = "brg";
> + model = "BRG1";
> + reg = <119f0>;
> + linux,phandle = <775>;
> + };
Why? We already know it's at this address offset.
> +
> + cpmux@11b04 {
> + device_type = "cpmux";
> + compatible = "fcc";
> + reg = <11b04>;
> + };
> +
> + cpmux@11b08 {
> + device_type = "cpmux";
> + compatible = "scc";
> + reg = <11b08>;
> + };
I don't understand the value of these either.
> +
> + scc@11a20 {
> + device_type = "serial";
> + compatible = "cpm_uart";
> + model = "SCC1";
> + reg = <11a20 100>;
> + reg_pram = <8000 ff>;
> + clock_setup = <0x00ffffff 0>;
> + interrupts = <28 3>;
None of this is variable. If you know you are using scc1,
you must use certain configuration bits in the cmxscr (the
thing you are calling cpmux). Why would you want to make
this variable and prone to error? The driver knows, and
there are no options. Same for the interrupts that are used.
> + fcc@11300 {
> + device_type = "network";
> + compatible = "fs_enet";
> + model = "FCC1";
> + reg = <11300 1f>;
> + reg_pram = <8400 ff>;
> + address = [00 00 00 00 00 00];
I'm assuming this is the MAC address, and is probably
the only thing I see of value here.
> More devices will be defined as this spec matures.
I just don't understand the value of this. Will you explain
it for me?
Thanks.
-- Dan
^ permalink raw reply
* LINUX source code of WRED Queuing Algorithm
From: Prabhat_Singh @ 2006-03-30 5:20 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
Hi all,
I am implementing voice enabled vpn router using mpc8248 processor so i want to implement WRED algorithm for congestion mangement in Qos implementation of linux-2.4.24 source code.
Can anyone please tell me , is the implementation of WRED algorithm is available as open source ? If it is not available what will be the best solution for congestion management at peak bandwidth(100% traffic) so that voice packet get priortized and not dropped at layer-3,only data packet is
dropped.
Thanks
Prabhat Singh
SE
Satyam Computer Services Ltd.
DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
[-- Attachment #2: Type: text/html, Size: 2038 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Segher Boessenkool @ 2006-03-30 6:06 UTC (permalink / raw)
To: Heiko J Schick; +Cc: paulus, linuxppc-dev
In-Reply-To: <57A56F67-44B3-489D-A600-537CE65D6FC2@schihei.de>
> Ok, I will change it to StudlyCaps. ;)
>
>>> if StudlyCaps are better (and more readable) than SHOUTING CAPS I
>>> can
>>> change it. Not a big deal.
>>
>> They are not... but consistency is better :)
Don't top-post, please.
How about we change the existing Studly's? It's only 132 lines...
Opinions?
I guess I'll have to volunteer for that job now. Oops.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Paul Mackerras @ 2006-03-30 6:10 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <bed6c40abe7664da7506270a46611d00@embeddededge.com>
Dan Malek writes:
> I haven't followed the device tree development in detail, but when
> looking at this the only question that comes to mind is wondering
> what this really does to help me. None of the information provided
> here is variable nor configurable .... except I guess for the internal
> register base address (IMMR), which for some reason has turned
> into a variable which hasn't changed since I did the first kernel port.
> About the only thing that is variable, which is the two different bank
> addresses of the CPM memory that affects the configuration of
> the FCCs in Ethernet mode, isn't reflected here in any way.
I don't know much about the CPM or CPM2, so I don't know precisely why
these bits have been put in. If the CPM2 is completely unique and is
identical across all possible past and future implementations, then
indeed there isn't a lot of value in putting details about it in the
device tree. Having details in the device tree becomes useful if:
* there are variants that have different collections of subdevices, or
subdevices at different offsets, or
* there are common subdevices between CPM and CPM2 (or future CPM*
devices), potentially with subtle variations in offset, method of
enabling, etc., or
* there are subdevices in CPM/CPM2 which match some common device
(e.g. a 16550 uart) for which a generic driver can be used with some
appropriate configuration.
As I say, I don't know if these points apply to CPM/CPM2 specifically.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Paul Mackerras @ 2006-03-30 6:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <74436DEF-2E23-440B-B797-E4CADEB70BA1@kernel.crashing.org>
Segher Boessenkool writes:
> How about we change the existing Studly's? It's only 132 lines...
> Opinions?
Yes, that's the best idea.
> I guess I'll have to volunteer for that job now. Oops.
Thanks, Segher! :)
Paul.
^ permalink raw reply
* [PATCH 0/5] powerpc: Cleanup htab code a little
From: Michael Ellerman @ 2006-03-30 6:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
A few cleanups to the htab. Built for pSeries, iSeries, pmac, pmac32 and maple. Booted on P5 LPAR and iSeries.
^ permalink raw reply
* [PATCH 1/5] powerpc: Initialise ppc_md htab pointers earlier
From: Michael Ellerman @ 2006-03-30 6:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1143699173.339118.857634197021.qpush@concordia>
Initialise the ppc_md htab callbacks earlier, in the probe routines. This
allows us to call htab_finish_init() from htab_initialize(), and makes it
private to hash_utils_64.c.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 6 --
arch/powerpc/mm/hash_native_64.c | 3 -
arch/powerpc/mm/hash_utils_64.c | 72 ++++++++++++++++----------------
arch/powerpc/platforms/iseries/htab.c | 4 -
arch/powerpc/platforms/iseries/setup.c | 7 ---
arch/powerpc/platforms/maple/setup.c | 7 ---
arch/powerpc/platforms/powermac/setup.c | 9 ----
arch/powerpc/platforms/pseries/lpar.c | 4 -
arch/powerpc/platforms/pseries/setup.c | 10 ++--
include/asm-powerpc/mmu.h | 1
10 files changed, 52 insertions(+), 71 deletions(-)
Index: to-merge/arch/powerpc/kernel/setup_64.c
===================================================================
--- to-merge.orig/arch/powerpc/kernel/setup_64.c
+++ to-merge/arch/powerpc/kernel/setup_64.c
@@ -371,11 +371,7 @@ void __init setup_system(void)
* Fill the ppc64_caches & systemcfg structures with informations
* retrieved from the device-tree. Need to be called before
* finish_device_tree() since the later requires some of the
- * informations filled up here to properly parse the interrupt
- * tree.
- * It also sets up the cache line sizes which allows to call
- * routines like flush_icache_range (used by the hash init
- * later on).
+ * informations filled up here to properly parse the interrupt tree.
*/
initialize_cache_info();
Index: to-merge/arch/powerpc/mm/hash_native_64.c
===================================================================
--- to-merge.orig/arch/powerpc/mm/hash_native_64.c
+++ to-merge/arch/powerpc/mm/hash_native_64.c
@@ -520,7 +520,7 @@ static inline int tlb_batching_enabled(v
}
#endif
-void hpte_init_native(void)
+void __init hpte_init_native(void)
{
ppc_md.hpte_invalidate = native_hpte_invalidate;
ppc_md.hpte_updatepp = native_hpte_updatepp;
@@ -530,5 +530,4 @@ void hpte_init_native(void)
ppc_md.hpte_clear_all = native_hpte_clear;
if (tlb_batching_enabled())
ppc_md.flush_hash_range = native_flush_hash_range;
- htab_finish_init();
}
Index: to-merge/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- to-merge.orig/arch/powerpc/mm/hash_utils_64.c
+++ to-merge/arch/powerpc/mm/hash_utils_64.c
@@ -397,6 +397,41 @@ void create_section_mapping(unsigned lon
}
#endif /* CONFIG_MEMORY_HOTPLUG */
+static inline void make_bl(unsigned int *insn_addr, void *func)
+{
+ unsigned long funcp = *((unsigned long *)func);
+ int offset = funcp - (unsigned long)insn_addr;
+
+ *insn_addr = (unsigned int)(0x48000001 | (offset & 0x03fffffc));
+ flush_icache_range((unsigned long)insn_addr, 4+
+ (unsigned long)insn_addr);
+}
+
+static void __init htab_finish_init(void)
+{
+ extern unsigned int *htab_call_hpte_insert1;
+ extern unsigned int *htab_call_hpte_insert2;
+ extern unsigned int *htab_call_hpte_remove;
+ extern unsigned int *htab_call_hpte_updatepp;
+
+#ifdef CONFIG_PPC_64K_PAGES
+ extern unsigned int *ht64_call_hpte_insert1;
+ extern unsigned int *ht64_call_hpte_insert2;
+ extern unsigned int *ht64_call_hpte_remove;
+ extern unsigned int *ht64_call_hpte_updatepp;
+
+ make_bl(ht64_call_hpte_insert1, ppc_md.hpte_insert);
+ make_bl(ht64_call_hpte_insert2, ppc_md.hpte_insert);
+ make_bl(ht64_call_hpte_remove, ppc_md.hpte_remove);
+ make_bl(ht64_call_hpte_updatepp, ppc_md.hpte_updatepp);
+#endif /* CONFIG_PPC_64K_PAGES */
+
+ make_bl(htab_call_hpte_insert1, ppc_md.hpte_insert);
+ make_bl(htab_call_hpte_insert2, ppc_md.hpte_insert);
+ make_bl(htab_call_hpte_remove, ppc_md.hpte_remove);
+ make_bl(htab_call_hpte_updatepp, ppc_md.hpte_updatepp);
+}
+
void __init htab_initialize(void)
{
unsigned long table;
@@ -509,6 +544,8 @@ void __init htab_initialize(void)
mmu_linear_psize));
}
+ htab_finish_init();
+
DBG(" <- htab_initialize()\n");
}
#undef KB
@@ -721,16 +758,6 @@ void flush_hash_range(unsigned long numb
}
}
-static inline void make_bl(unsigned int *insn_addr, void *func)
-{
- unsigned long funcp = *((unsigned long *)func);
- int offset = funcp - (unsigned long)insn_addr;
-
- *insn_addr = (unsigned int)(0x48000001 | (offset & 0x03fffffc));
- flush_icache_range((unsigned long)insn_addr, 4+
- (unsigned long)insn_addr);
-}
-
/*
* low_hash_fault is called when we the low level hash code failed
* to instert a PTE due to an hypervisor error
@@ -749,28 +776,3 @@ void low_hash_fault(struct pt_regs *regs
}
bad_page_fault(regs, address, SIGBUS);
}
-
-void __init htab_finish_init(void)
-{
- extern unsigned int *htab_call_hpte_insert1;
- extern unsigned int *htab_call_hpte_insert2;
- extern unsigned int *htab_call_hpte_remove;
- extern unsigned int *htab_call_hpte_updatepp;
-
-#ifdef CONFIG_PPC_64K_PAGES
- extern unsigned int *ht64_call_hpte_insert1;
- extern unsigned int *ht64_call_hpte_insert2;
- extern unsigned int *ht64_call_hpte_remove;
- extern unsigned int *ht64_call_hpte_updatepp;
-
- make_bl(ht64_call_hpte_insert1, ppc_md.hpte_insert);
- make_bl(ht64_call_hpte_insert2, ppc_md.hpte_insert);
- make_bl(ht64_call_hpte_remove, ppc_md.hpte_remove);
- make_bl(ht64_call_hpte_updatepp, ppc_md.hpte_updatepp);
-#endif /* CONFIG_PPC_64K_PAGES */
-
- make_bl(htab_call_hpte_insert1, ppc_md.hpte_insert);
- make_bl(htab_call_hpte_insert2, ppc_md.hpte_insert);
- make_bl(htab_call_hpte_remove, ppc_md.hpte_remove);
- make_bl(htab_call_hpte_updatepp, ppc_md.hpte_updatepp);
-}
Index: to-merge/arch/powerpc/platforms/iseries/htab.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/htab.c
+++ to-merge/arch/powerpc/platforms/iseries/htab.c
@@ -242,13 +242,11 @@ static void iSeries_hpte_invalidate(unsi
local_irq_restore(flags);
}
-void hpte_init_iSeries(void)
+void __init hpte_init_iSeries(void)
{
ppc_md.hpte_invalidate = iSeries_hpte_invalidate;
ppc_md.hpte_updatepp = iSeries_hpte_updatepp;
ppc_md.hpte_updateboltedpp = iSeries_hpte_updateboltedpp;
ppc_md.hpte_insert = iSeries_hpte_insert;
ppc_md.hpte_remove = iSeries_hpte_remove;
-
- htab_finish_init();
}
Index: to-merge/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/iseries/setup.c
+++ to-merge/arch/powerpc/platforms/iseries/setup.c
@@ -326,11 +326,6 @@ static void __init iSeries_init_early(vo
iSeries_recal_titan = HvCallXm_loadTod();
/*
- * Initialize the hash table management pointers
- */
- hpte_init_iSeries();
-
- /*
* Initialize the DMA/TCE management
*/
iommu_init_early_iSeries();
@@ -684,6 +679,8 @@ static int __init iseries_probe(void)
powerpc_firmware_features |= FW_FEATURE_ISERIES;
powerpc_firmware_features |= FW_FEATURE_LPAR;
+ hpte_init_iSeries();
+
return 1;
}
Index: to-merge/arch/powerpc/platforms/maple/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/maple/setup.c
+++ to-merge/arch/powerpc/platforms/maple/setup.c
@@ -199,11 +199,6 @@ static void __init maple_init_early(void
{
DBG(" -> maple_init_early\n");
- /* Initialize hash table, from now on, we can take hash faults
- * and call ioremap
- */
- hpte_init_native();
-
/* Setup interrupt mapping options */
ppc64_interrupt_controller = IC_OPEN_PIC;
@@ -272,6 +267,8 @@ static int __init maple_probe(void)
*/
alloc_dart_table();
+ hpte_init_native();
+
return 1;
}
Index: to-merge/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/powermac/setup.c
+++ to-merge/arch/powerpc/platforms/powermac/setup.c
@@ -588,13 +588,6 @@ pmac_halt(void)
*/
static void __init pmac_init_early(void)
{
-#ifdef CONFIG_PPC64
- /* Initialize hash table, from now on, we can take hash faults
- * and call ioremap
- */
- hpte_init_native();
-#endif
-
/* Enable early btext debug if requested */
if (strstr(cmd_line, "btextdbg")) {
udbg_adb_init_early();
@@ -671,6 +664,8 @@ static int __init pmac_probe(void)
* part of the cacheable linar mapping
*/
alloc_dart_table();
+
+ hpte_init_native();
#endif
#ifdef CONFIG_PPC32
Index: to-merge/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/pseries/lpar.c
+++ to-merge/arch/powerpc/platforms/pseries/lpar.c
@@ -512,7 +512,7 @@ void pSeries_lpar_flush_hash_range(unsig
spin_unlock_irqrestore(&pSeries_lpar_tlbie_lock, flags);
}
-void hpte_init_lpar(void)
+void __init hpte_init_lpar(void)
{
ppc_md.hpte_invalidate = pSeries_lpar_hpte_invalidate;
ppc_md.hpte_updatepp = pSeries_lpar_hpte_updatepp;
@@ -521,6 +521,4 @@ void hpte_init_lpar(void)
ppc_md.hpte_remove = pSeries_lpar_hpte_remove;
ppc_md.flush_hash_range = pSeries_lpar_flush_hash_range;
ppc_md.hpte_clear_all = pSeries_lpar_hptab_clear;
-
- htab_finish_init();
}
Index: to-merge/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- to-merge.orig/arch/powerpc/platforms/pseries/setup.c
+++ to-merge/arch/powerpc/platforms/pseries/setup.c
@@ -322,11 +322,6 @@ static void __init pSeries_init_early(vo
DBG(" -> pSeries_init_early()\n");
fw_feature_init();
-
- if (firmware_has_feature(FW_FEATURE_LPAR))
- hpte_init_lpar();
- else
- hpte_init_native();
if (firmware_has_feature(FW_FEATURE_LPAR))
find_udbg_vterm();
@@ -384,6 +379,11 @@ static int __init pSeries_probe_hypertas
if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL) != NULL)
powerpc_firmware_features |= FW_FEATURE_LPAR;
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ hpte_init_lpar();
+ else
+ hpte_init_native();
+
return 1;
}
Index: to-merge/include/asm-powerpc/mmu.h
===================================================================
--- to-merge.orig/include/asm-powerpc/mmu.h
+++ to-merge/include/asm-powerpc/mmu.h
@@ -226,7 +226,6 @@ extern int hash_huge_page(struct mm_stru
unsigned long ea, unsigned long vsid, int local,
unsigned long trap);
-extern void htab_finish_init(void);
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox