* 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: 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: [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: 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: 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
* [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
* [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
* 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
* 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 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: [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: 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: [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: [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: "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: Kernel for MPC Lite 5200 will not compile
From: Matthias Fechner @ 2006-03-29 15:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060328223105.2E44D3535F7@atlas.denx.de>
Hello Wolfgang,
* Wolfgang Denk <wd@denx.de> [29-03-06 00:31]:
> Which kernel tree are you using? There is no support for MPC5200 in
> the DENX Linux tree. Well, some code is there, as there is in the
> public 2.6 kernel tree, but it's known to be broken and not supported
> by us.
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>)
linux-2.6-denx-git (see above)
linuxppc_2_4_mpc5200 (see above)
on the 2.4 kernel i got a different errormessage, but now with the
kernel linux-2.6-mpc52xx.git from Sylvain everthing seems to work fine,
I need to test it at first. :) But I think this will take now some
time from now.
> > For this I used the git repository.
>
> Which one?
see above
> > 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.
Best regards,
Matthias
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Matthias Fechner @ 2006-03-29 15:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4429A0E5.8010308@246tNt.com>
Hello Sylvain,
* Sylvain Munaut <tnt@246tNt.com> [28-03-06 22:47]:
> You might want to try the "quick start" section of
> http://www.246tnt.com/mpc52xx/
thx a lot, I'm sure this will help.
Best regards,
Matthias
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Matthias Fechner @ 2006-03-29 15:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com>
Hello John,
* John Rigby <jcrigby@gmail.com> [28-03-06 09:15]:
> kernel: http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx.git
thx a lot, the compile was successfully now.
Now i can start to play with the environment. :)
Best regards,
Matthias
^ permalink raw reply
* Re: [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Segher Boessenkool @ 2006-03-29 15:09 UTC (permalink / raw)
To: Heiko J Schick; +Cc: linuxppc-dev, paulus
In-Reply-To: <442AA34B.7050801@de.ibm.com>
> below (and attached) you will find my ib_hcall patch, which extends
> the HCALL interface for InfiniBand usage. I've made the patch
> agains the lates Linux kernel snapshot (linux-2.6.16-git14) from
> kernel.org. We moved this into the common powerpc code based on
> comments we got after posting the first eHCA InfiniBand device
> driver patch.
>
> Any comments or proposals for my patch?
Looks good /an sich/, but...
> #define H_Success 0
> #define H_Busy 1 /* Hardware busy -- retry later */
> #define H_Closed 2 /* Resource closed */
> +#define H_NOT_AVAILABLE 3
> #define H_Constrained 4 /* Resource request constrained to
> max allowed */
> +#define H_PARTIAL 5
> #define H_InProgress 14 /* Kind of like busy */
> +#define H_PARTIAL_STORE 16
> +#define H_PAGE_REGISTERED 15
All the other defines use StudlyCaps, yours use SHOUTING_CAPS, you
might want to choose just one style (though I prefer the shouting one).
> diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/
> hvCall.S.orig linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/
> hvCall.S.orig
> --- linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S.orig
> 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/
> hvCall.S.orig 2006-03-28 14:19:51.140018464 +0200
Erm... you messed up here :-)
In fact, the patch is broken in more places, please make sure just to
diff the files you wanted to diff, and it looks like you posted two
patches
in one?
Segher
^ permalink raw reply
* [PATCH] powerpc: Extends HCALL interface for InfiniBand usage
From: Heiko J Schick @ 2006-03-29 15:10 UTC (permalink / raw)
To: Anton Blanchard, paulus; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 23190 bytes --]
Hello,
below (and attached) you will find my ib_hcall patch, which extends
the HCALL interface for InfiniBand usage. I've made the patch
agains the lates Linux kernel snapshot (linux-2.6.16-git14) from
kernel.org. We moved this into the common powerpc code based on
comments we got after posting the first eHCA InfiniBand device
driver patch.
Any comments or proposals for my patch?
Regards,
Heiko
Signed-off-by: Heiko J Schick <schickhj@de.ibm.com>
arch/powerpc/platforms/pseries/hvCall.S | 101 ++++++++++++++++++++-
arch/powerpc/platforms/pseries/lpar.c | 3
include/asm-powerpc/hvcall.h | 100 ++++++++++++++++++++
4 files changed, 202 insertions(+), 2 deletions(-)
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S 2006-03-28 14:18:52.389031144 +0200
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S 2006-03-28 14:20:47.800056224 +0200
@@ -91,7 +91,6 @@ _GLOBAL(plpar_hcall_8arg_2ret)
mtcrf 0xff,r0
blr /* return r3 = status */
-
/* long plpar_hcall_4out(unsigned long opcode, R3
unsigned long arg1, R4
unsigned long arg2, R5
@@ -127,3 +126,103 @@ _GLOBAL(plpar_hcall_4out)
mtcrf 0xff,r0
blr /* return r3 = status */
+
+/* plpar_hcall_7arg_7ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long *out1, 112(R1)
+ unsigned long *out2, 110(R1)
+ unsigned long *out3, 108(R1)
+ unsigned long *out4, 106(R1)
+ unsigned long *out5, 104(R1)
+ unsigned long *out6, 102(R1)
+ unsigned long *out7); 100(R1)
+*/
+_GLOBAL(plpar_hcall_7arg_7ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+
+ ld r11,STK_PARM(r11)(r1) /* Fetch r4 ret arg */
+ std r4,0(r11)
+ ld r11,STK_PARM(r12)(r1) /* Fetch r5 ret arg */
+ std r5,0(r11)
+ ld r11,STK_PARM(r13)(r1) /* Fetch r6 ret arg */
+ std r6,0(r11)
+ ld r11,STK_PARM(r14)(r1) /* Fetch r7 ret arg */
+ std r7,0(r11)
+ ld r11,STK_PARM(r15)(r1) /* Fetch r8 ret arg */
+ std r8,0(r11)
+ ld r11,STK_PARM(r16)(r1) /* Fetch r9 ret arg */
+ std r9,0(r11)
+ ld r11,STK_PARM(r17)(r1) /* Fetch r10 ret arg */
+ std r10,0(r11)
+
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
+
+/* plpar_hcall_9arg_9ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long arg8, 112(R1)
+ unsigned long arg9, 110(R1)
+ unsigned long *out1, 108(R1)
+ unsigned long *out2, 106(R1)
+ unsigned long *out3, 104(R1)
+ unsigned long *out4, 102(R1)
+ unsigned long *out5, 100(R1)
+ unsigned long *out6, 98(R1)
+ unsigned long *out7); 96(R1)
+ unsigned long *out8, 94(R1)
+ unsigned long *out9, 92(R1)
+*/
+_GLOBAL(plpar_hcall_9arg_9ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ ld r11,STK_PARM(r11)(r1) /* put arg8 in R11 */
+ ld r12,STK_PARM(r12)(r1) /* put arg9 in R12 */
+
+ HVSC /* invoke the hypervisor */
+
+ ld r0,STK_PARM(r13)(r1) /* Fetch r4 ret arg */
+ stdx r4,r0,r0
+ ld r0,STK_PARM(r14)(r1) /* Fetch r5 ret arg */
+ stdx r5,r0,r0
+ ld r0,STK_PARM(r15)(r1) /* Fetch r6 ret arg */
+ stdx r6,r0,r0
+ ld r0,STK_PARM(r16)(r1) /* Fetch r7 ret arg */
+ stdx r7,r0,r0
+ ld r0,STK_PARM(r17)(r1) /* Fetch r8 ret arg */
+ stdx r8,r0,r0
+ ld r0,STK_PARM(r18)(r1) /* Fetch r9 ret arg */
+ stdx r9,r0,r0
+ ld r0,STK_PARM(r19)(r1) /* Fetch r10 ret arg */
+ stdx r10,r0,r0
+ ld r0,STK_PARM(r20)(r1) /* Fetch r11 ret arg */
+ stdx r11,r0,r0
+ ld r0,STK_PARM(r21)(r1) /* Fetch r12 ret arg */
+ stdx r12,r0,r0
+
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/lpar.c linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/lpar.c
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/lpar.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/lpar.c 2006-03-28 14:20:47.801056072 +0200
@@ -54,7 +54,8 @@ EXPORT_SYMBOL(plpar_hcall);
EXPORT_SYMBOL(plpar_hcall_4out);
EXPORT_SYMBOL(plpar_hcall_norets);
EXPORT_SYMBOL(plpar_hcall_8arg_2ret);
-
+EXPORT_SYMBOL(plpar_hcall_7arg_7ret);
+EXPORT_SYMBOL(plpar_hcall_9arg_9ret);
extern void pSeries_find_serial_port(void);
diff -Nurpw linux-2.6.16-git14/include/asm-powerpc/hvcall.h linux-2.6.16-git14-ib/include/asm-powerpc/hvcall.h
--- linux-2.6.16-git14/include/asm-powerpc/hvcall.h 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16-git14-ib/include/asm-powerpc/hvcall.h 2006-03-28 14:20:47.799056376 +0200
@@ -7,8 +7,12 @@
#define H_Success 0
#define H_Busy 1 /* Hardware busy -- retry later */
#define H_Closed 2 /* Resource closed */
+#define H_NOT_AVAILABLE 3
#define H_Constrained 4 /* Resource request constrained to max allowed */
+#define H_PARTIAL 5
#define H_InProgress 14 /* Kind of like busy */
+#define H_PARTIAL_STORE 16
+#define H_PAGE_REGISTERED 15
#define H_Continue 18 /* Returned from H_Join on success */
#define H_LongBusyStartRange 9900 /* Start of long busy range */
#define H_LongBusyOrder1msec 9900 /* Long busy, hint that 1msec is a good time to retry */
@@ -34,6 +38,36 @@
#define H_DestParm -14
#define H_RemoteParm -15
#define H_Resource -16
+#define H_ADAPTER_PARM -17
+#define H_RH_PARM -18
+#define H_RCQ_PARM -19
+#define H_SCQ_PARM -20
+#define H_EQ_PARM -21
+#define H_RT_PARM -22
+#define H_ST_PARM -23
+#define H_SIGT_PARM -24
+#define H_TOKEN_PARM -25
+#define H_MLENGTH_PARM -27
+#define H_MEM_PARM -28
+#define H_MEM_ACCESS_PARM -29
+#define H_ATTR_PARM -30
+#define H_PORT_PARM -31
+#define H_MCG_PARM -32
+#define H_VL_PARM -33
+#define H_TSIZE_PARM -34
+#define H_TRACE_PARM -35
+
+#define H_MASK_PARM -37
+#define H_MCG_FULL -38
+#define H_ALIAS_EXIST -39
+#define H_P_COUNTER -40
+#define H_TABLE_FULL -41
+#define H_ALT_TABLE -42
+#define H_MR_CONDITION -43
+#define H_NOT_ENOUGH_RESOURCES -44
+#define H_R_STATE -45
+#define H_RESCINDEND -46
+
/* Long Busy is a condition that can be returned by the firmware
* when a call cannot be completed now, but the identical call
@@ -65,6 +99,9 @@
#define H_DABRX_KERNEL (1UL<<(63-62))
#define H_DABRX_USER (1UL<<(63-63))
+/* Each control block has to be on a 4K bondary */
+#define H_CB_ALIGNMENT 4096
+
/* pSeries hypervisor opcodes */
#define H_REMOVE 0x04
#define H_ENTER 0x08
@@ -116,6 +153,33 @@
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
+#define H_RESET_EVENTS 0x15C
+#define H_ALLOC_RESOURCE 0x160
+#define H_FREE_RESOURCE 0x164
+#define H_MODIFY_QP 0x168
+#define H_QUERY_QP 0x16C
+#define H_REREGISTER_PMR 0x170
+#define H_REGISTER_SMR 0x174
+#define H_QUERY_MR 0x178
+#define H_QUERY_MW 0x17C
+#define H_QUERY_HCA 0x180
+#define H_QUERY_PORT 0x184
+#define H_MODIFY_PORT 0x188
+#define H_DEFINE_AQP1 0x18C
+#define H_GET_TRACE_BUFFER 0x190
+#define H_DEFINE_AQP0 0x194
+#define H_RESIZE_MR 0x198
+#define H_ATTACH_MCQP 0x19C
+#define H_DETACH_MCQP 0x1A0
+#define H_CREATE_RPT 0x1A4
+#define H_REMOVE_RPT 0x1A8
+#define H_REGISTER_RPAGES 0x1AC
+#define H_DISABLE_AND_GETC 0x1B0
+#define H_ERROR_DATA 0x1B4
+#define H_GET_HCA_INFO 0x1B8
+#define H_GET_PERF_COUNT 0x1BC
+#define H_MANAGE_TRACE 0x1C0
+#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_ENABLE_CRQ 0x2B0
@@ -175,6 +239,42 @@ long plpar_hcall_4out(unsigned long opco
unsigned long *out3,
unsigned long *out4);
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S 2006-03-28 14:18:52.389031144 +0200
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S 2006-03-28 14:20:47.800056224 +0200
@@ -91,7 +91,6 @@ _GLOBAL(plpar_hcall_8arg_2ret)
mtcrf 0xff,r0
blr /* return r3 = status */
-
/* long plpar_hcall_4out(unsigned long opcode, R3
unsigned long arg1, R4
unsigned long arg2, R5
@@ -127,3 +126,103 @@ _GLOBAL(plpar_hcall_4out)
mtcrf 0xff,r0
blr /* return r3 = status */
+
+/* plpar_hcall_7arg_7ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long *out1, 112(R1)
+ unsigned long *out2, 110(R1)
+ unsigned long *out3, 108(R1)
+ unsigned long *out4, 106(R1)
+ unsigned long *out5, 104(R1)
+ unsigned long *out6, 102(R1)
+ unsigned long *out7); 100(R1)
+*/
+_GLOBAL(plpar_hcall_7arg_7ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+
+ ld r11,STK_PARM(r11)(r1) /* Fetch r4 ret arg */
+ std r4,0(r11)
+ ld r11,STK_PARM(r12)(r1) /* Fetch r5 ret arg */
+ std r5,0(r11)
+ ld r11,STK_PARM(r13)(r1) /* Fetch r6 ret arg */
+ std r6,0(r11)
+ ld r11,STK_PARM(r14)(r1) /* Fetch r7 ret arg */
+ std r7,0(r11)
+ ld r11,STK_PARM(r15)(r1) /* Fetch r8 ret arg */
+ std r8,0(r11)
+ ld r11,STK_PARM(r16)(r1) /* Fetch r9 ret arg */
+ std r9,0(r11)
+ ld r11,STK_PARM(r17)(r1) /* Fetch r10 ret arg */
+ std r10,0(r11)
+
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
+
+/* plpar_hcall_9arg_9ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long arg8, 112(R1)
+ unsigned long arg9, 110(R1)
+ unsigned long *out1, 108(R1)
+ unsigned long *out2, 106(R1)
+ unsigned long *out3, 104(R1)
+ unsigned long *out4, 102(R1)
+ unsigned long *out5, 100(R1)
+ unsigned long *out6, 98(R1)
+ unsigned long *out7); 96(R1)
+ unsigned long *out8, 94(R1)
+ unsigned long *out9, 92(R1)
+*/
+_GLOBAL(plpar_hcall_9arg_9ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ ld r11,STK_PARM(r11)(r1) /* put arg8 in R11 */
+ ld r12,STK_PARM(r12)(r1) /* put arg9 in R12 */
+
+ HVSC /* invoke the hypervisor */
+
+ ld r0,STK_PARM(r13)(r1) /* Fetch r4 ret arg */
+ stdx r4,r0,r0
+ ld r0,STK_PARM(r14)(r1) /* Fetch r5 ret arg */
+ stdx r5,r0,r0
+ ld r0,STK_PARM(r15)(r1) /* Fetch r6 ret arg */
+ stdx r6,r0,r0
+ ld r0,STK_PARM(r16)(r1) /* Fetch r7 ret arg */
+ stdx r7,r0,r0
+ ld r0,STK_PARM(r17)(r1) /* Fetch r8 ret arg */
+ stdx r8,r0,r0
+ ld r0,STK_PARM(r18)(r1) /* Fetch r9 ret arg */
+ stdx r9,r0,r0
+ ld r0,STK_PARM(r19)(r1) /* Fetch r10 ret arg */
+ stdx r10,r0,r0
+ ld r0,STK_PARM(r20)(r1) /* Fetch r11 ret arg */
+ stdx r11,r0,r0
+ ld r0,STK_PARM(r21)(r1) /* Fetch r12 ret arg */
+ stdx r12,r0,r0
+
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S.orig linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S.orig
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S.orig 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S.orig 2006-03-28 14:19:51.140018464 +0200
@@ -0,0 +1,129 @@
+/*
+ * This file contains the generic code to perform a call to the
+ * pSeries LPAR hypervisor.
+ * NOTE: this file will go away when we move to inline this work.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <asm/hvcall.h>
+#include <asm/processor.h>
+#include <asm/ppc_asm.h>
+
+#define STK_PARM(i) (48 + ((i)-3)*8)
+
+ .text
+
+/* long plpar_hcall(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long *out1, R8
+ unsigned long *out2, R9
+ unsigned long *out3); R10
+ */
+_GLOBAL(plpar_hcall)
+ HMT_MEDIUM
+
+ mfcr r0
+
+ std r8,STK_PARM(r8)(r1) /* Save out ptrs */
+ std r9,STK_PARM(r9)(r1)
+ std r10,STK_PARM(r10)(r1)
+
+ stw r0,8(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+
+ ld r8,STK_PARM(r8)(r1) /* Fetch r4-r6 ret args */
+ ld r9,STK_PARM(r9)(r1)
+ ld r10,STK_PARM(r10)(r1)
+ std r4,0(r8)
+ std r5,0(r9)
+ std r6,0(r10)
+
+ mtcrf 0xff,r0
+ blr /* return r3 = status */
+
+
+/* Simple interface with no output values (other than status) */
+_GLOBAL(plpar_hcall_norets)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+ blr /* return r3 = status */
+
+
+/* long plpar_hcall_8arg_2ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long arg8, 112(R1)
+ unsigned long *out1); 120(R1)
+ */
+_GLOBAL(plpar_hcall_8arg_2ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ ld r11,STK_PARM(r11)(r1) /* put arg8 in R11 */
+ stw r0,8(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+ ld r10,STK_PARM(r12)(r1) /* Fetch r4 ret arg */
+ std r4,0(r10)
+ mtcrf 0xff,r0
+ blr /* return r3 = status */
+
+
+/* long plpar_hcall_4out(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long *out1, R8
+ unsigned long *out2, R9
+ unsigned long *out3, R10
+ unsigned long *out4); 112(R1)
+ */
+_GLOBAL(plpar_hcall_4out)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ std r8,STK_PARM(r8)(r1) /* Save out ptrs */
+ std r9,STK_PARM(r9)(r1)
+ std r10,STK_PARM(r10)(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+
+ ld r8,STK_PARM(r8)(r1) /* Fetch r4-r7 ret args */
+ ld r9,STK_PARM(r9)(r1)
+ ld r10,STK_PARM(r10)(r1)
+ ld r11,STK_PARM(r11)(r1)
+ std r4,0(r8)
+ std r5,0(r9)
+ std r6,0(r10)
+ std r7,0(r11)
+
+ mtcrf 0xff,r0
+ blr /* return r3 = status */
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/lpar.c linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/lpar.c
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/lpar.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/lpar.c 2006-03-28 14:20:47.801056072 +0200
@@ -54,7 +54,8 @@ EXPORT_SYMBOL(plpar_hcall);
EXPORT_SYMBOL(plpar_hcall_4out);
EXPORT_SYMBOL(plpar_hcall_norets);
EXPORT_SYMBOL(plpar_hcall_8arg_2ret);
-
+EXPORT_SYMBOL(plpar_hcall_7arg_7ret);
+EXPORT_SYMBOL(plpar_hcall_9arg_9ret);
extern void pSeries_find_serial_port(void);
diff -Nurpw linux-2.6.16-git14/include/asm-powerpc/hvcall.h linux-2.6.16-git14-ib/include/asm-powerpc/hvcall.h
--- linux-2.6.16-git14/include/asm-powerpc/hvcall.h 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16-git14-ib/include/asm-powerpc/hvcall.h 2006-03-28 14:20:47.799056376 +0200
@@ -7,8 +7,12 @@
#define H_Success 0
#define H_Busy 1 /* Hardware busy -- retry later */
#define H_Closed 2 /* Resource closed */
+#define H_NOT_AVAILABLE 3
#define H_Constrained 4 /* Resource request constrained to max allowed */
+#define H_PARTIAL 5
#define H_InProgress 14 /* Kind of like busy */
+#define H_PARTIAL_STORE 16
+#define H_PAGE_REGISTERED 15
#define H_Continue 18 /* Returned from H_Join on success */
#define H_LongBusyStartRange 9900 /* Start of long busy range */
#define H_LongBusyOrder1msec 9900 /* Long busy, hint that 1msec is a good time to retry */
@@ -34,6 +38,36 @@
#define H_DestParm -14
#define H_RemoteParm -15
#define H_Resource -16
+#define H_ADAPTER_PARM -17
+#define H_RH_PARM -18
+#define H_RCQ_PARM -19
+#define H_SCQ_PARM -20
+#define H_EQ_PARM -21
+#define H_RT_PARM -22
+#define H_ST_PARM -23
+#define H_SIGT_PARM -24
+#define H_TOKEN_PARM -25
+#define H_MLENGTH_PARM -27
+#define H_MEM_PARM -28
+#define H_MEM_ACCESS_PARM -29
+#define H_ATTR_PARM -30
+#define H_PORT_PARM -31
+#define H_MCG_PARM -32
+#define H_VL_PARM -33
+#define H_TSIZE_PARM -34
+#define H_TRACE_PARM -35
+
+#define H_MASK_PARM -37
+#define H_MCG_FULL -38
+#define H_ALIAS_EXIST -39
+#define H_P_COUNTER -40
+#define H_TABLE_FULL -41
+#define H_ALT_TABLE -42
+#define H_MR_CONDITION -43
+#define H_NOT_ENOUGH_RESOURCES -44
+#define H_R_STATE -45
+#define H_RESCINDEND -46
+
/* Long Busy is a condition that can be returned by the firmware
* when a call cannot be completed now, but the identical call
@@ -65,6 +99,9 @@
#define H_DABRX_KERNEL (1UL<<(63-62))
#define H_DABRX_USER (1UL<<(63-63))
+/* Each control block has to be on a 4K bondary */
+#define H_CB_ALIGNMENT 4096
+
/* pSeries hypervisor opcodes */
#define H_REMOVE 0x04
#define H_ENTER 0x08
@@ -116,6 +153,33 @@
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
+#define H_RESET_EVENTS 0x15C
+#define H_ALLOC_RESOURCE 0x160
+#define H_FREE_RESOURCE 0x164
+#define H_MODIFY_QP 0x168
+#define H_QUERY_QP 0x16C
+#define H_REREGISTER_PMR 0x170
+#define H_REGISTER_SMR 0x174
+#define H_QUERY_MR 0x178
+#define H_QUERY_MW 0x17C
+#define H_QUERY_HCA 0x180
+#define H_QUERY_PORT 0x184
+#define H_MODIFY_PORT 0x188
+#define H_DEFINE_AQP1 0x18C
+#define H_GET_TRACE_BUFFER 0x190
+#define H_DEFINE_AQP0 0x194
+#define H_RESIZE_MR 0x198
+#define H_ATTACH_MCQP 0x19C
+#define H_DETACH_MCQP 0x1A0
+#define H_CREATE_RPT 0x1A4
+#define H_REMOVE_RPT 0x1A8
+#define H_REGISTER_RPAGES 0x1AC
+#define H_DISABLE_AND_GETC 0x1B0
+#define H_ERROR_DATA 0x1B4
+#define H_GET_HCA_INFO 0x1B8
+#define H_GET_PERF_COUNT 0x1BC
+#define H_MANAGE_TRACE 0x1C0
+#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_ENABLE_CRQ 0x2B0
@@ -175,6 +239,42 @@ long plpar_hcall_4out(unsigned long opco
unsigned long *out3,
unsigned long *out4);
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
[-- Attachment #2: ib_hcalls-2616-git14.patch --]
[-- Type: text/x-patch, Size: 8857 bytes --]
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/hvCall.S 2006-03-28 14:18:52.389031144 +0200
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/hvCall.S 2006-03-28 14:20:47.800056224 +0200
@@ -91,7 +91,6 @@ _GLOBAL(plpar_hcall_8arg_2ret)
mtcrf 0xff,r0
blr /* return r3 = status */
-
/* long plpar_hcall_4out(unsigned long opcode, R3
unsigned long arg1, R4
unsigned long arg2, R5
@@ -127,3 +126,103 @@ _GLOBAL(plpar_hcall_4out)
mtcrf 0xff,r0
blr /* return r3 = status */
+
+/* plpar_hcall_7arg_7ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long *out1, 112(R1)
+ unsigned long *out2, 110(R1)
+ unsigned long *out3, 108(R1)
+ unsigned long *out4, 106(R1)
+ unsigned long *out5, 104(R1)
+ unsigned long *out6, 102(R1)
+ unsigned long *out7); 100(R1)
+*/
+_GLOBAL(plpar_hcall_7arg_7ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ HVSC /* invoke the hypervisor */
+
+ lwz r0,8(r1)
+
+ ld r11,STK_PARM(r11)(r1) /* Fetch r4 ret arg */
+ std r4,0(r11)
+ ld r11,STK_PARM(r12)(r1) /* Fetch r5 ret arg */
+ std r5,0(r11)
+ ld r11,STK_PARM(r13)(r1) /* Fetch r6 ret arg */
+ std r6,0(r11)
+ ld r11,STK_PARM(r14)(r1) /* Fetch r7 ret arg */
+ std r7,0(r11)
+ ld r11,STK_PARM(r15)(r1) /* Fetch r8 ret arg */
+ std r8,0(r11)
+ ld r11,STK_PARM(r16)(r1) /* Fetch r9 ret arg */
+ std r9,0(r11)
+ ld r11,STK_PARM(r17)(r1) /* Fetch r10 ret arg */
+ std r10,0(r11)
+
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
+
+/* plpar_hcall_9arg_9ret(unsigned long opcode, R3
+ unsigned long arg1, R4
+ unsigned long arg2, R5
+ unsigned long arg3, R6
+ unsigned long arg4, R7
+ unsigned long arg5, R8
+ unsigned long arg6, R9
+ unsigned long arg7, R10
+ unsigned long arg8, 112(R1)
+ unsigned long arg9, 110(R1)
+ unsigned long *out1, 108(R1)
+ unsigned long *out2, 106(R1)
+ unsigned long *out3, 104(R1)
+ unsigned long *out4, 102(R1)
+ unsigned long *out5, 100(R1)
+ unsigned long *out6, 98(R1)
+ unsigned long *out7); 96(R1)
+ unsigned long *out8, 94(R1)
+ unsigned long *out9, 92(R1)
+*/
+_GLOBAL(plpar_hcall_9arg_9ret)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+
+ ld r11,STK_PARM(r11)(r1) /* put arg8 in R11 */
+ ld r12,STK_PARM(r12)(r1) /* put arg9 in R12 */
+
+ HVSC /* invoke the hypervisor */
+
+ ld r0,STK_PARM(r13)(r1) /* Fetch r4 ret arg */
+ stdx r4,r0,r0
+ ld r0,STK_PARM(r14)(r1) /* Fetch r5 ret arg */
+ stdx r5,r0,r0
+ ld r0,STK_PARM(r15)(r1) /* Fetch r6 ret arg */
+ stdx r6,r0,r0
+ ld r0,STK_PARM(r16)(r1) /* Fetch r7 ret arg */
+ stdx r7,r0,r0
+ ld r0,STK_PARM(r17)(r1) /* Fetch r8 ret arg */
+ stdx r8,r0,r0
+ ld r0,STK_PARM(r18)(r1) /* Fetch r9 ret arg */
+ stdx r9,r0,r0
+ ld r0,STK_PARM(r19)(r1) /* Fetch r10 ret arg */
+ stdx r10,r0,r0
+ ld r0,STK_PARM(r20)(r1) /* Fetch r11 ret arg */
+ stdx r11,r0,r0
+ ld r0,STK_PARM(r21)(r1) /* Fetch r12 ret arg */
+ stdx r12,r0,r0
+
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
diff -Nurpw linux-2.6.16-git14/arch/powerpc/platforms/pseries/lpar.c linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/lpar.c
--- linux-2.6.16-git14/arch/powerpc/platforms/pseries/lpar.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16-git14-ib/arch/powerpc/platforms/pseries/lpar.c 2006-03-28 14:20:47.801056072 +0200
@@ -54,7 +54,8 @@ EXPORT_SYMBOL(plpar_hcall);
EXPORT_SYMBOL(plpar_hcall_4out);
EXPORT_SYMBOL(plpar_hcall_norets);
EXPORT_SYMBOL(plpar_hcall_8arg_2ret);
-
+EXPORT_SYMBOL(plpar_hcall_7arg_7ret);
+EXPORT_SYMBOL(plpar_hcall_9arg_9ret);
extern void pSeries_find_serial_port(void);
diff -Nurpw linux-2.6.16-git14/include/asm-powerpc/hvcall.h linux-2.6.16-git14-ib/include/asm-powerpc/hvcall.h
--- linux-2.6.16-git14/include/asm-powerpc/hvcall.h 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16-git14-ib/include/asm-powerpc/hvcall.h 2006-03-28 14:20:47.799056376 +0200
@@ -7,8 +7,12 @@
#define H_Success 0
#define H_Busy 1 /* Hardware busy -- retry later */
#define H_Closed 2 /* Resource closed */
+#define H_NOT_AVAILABLE 3
#define H_Constrained 4 /* Resource request constrained to max allowed */
+#define H_PARTIAL 5
#define H_InProgress 14 /* Kind of like busy */
+#define H_PARTIAL_STORE 16
+#define H_PAGE_REGISTERED 15
#define H_Continue 18 /* Returned from H_Join on success */
#define H_LongBusyStartRange 9900 /* Start of long busy range */
#define H_LongBusyOrder1msec 9900 /* Long busy, hint that 1msec is a good time to retry */
@@ -34,6 +38,36 @@
#define H_DestParm -14
#define H_RemoteParm -15
#define H_Resource -16
+#define H_ADAPTER_PARM -17
+#define H_RH_PARM -18
+#define H_RCQ_PARM -19
+#define H_SCQ_PARM -20
+#define H_EQ_PARM -21
+#define H_RT_PARM -22
+#define H_ST_PARM -23
+#define H_SIGT_PARM -24
+#define H_TOKEN_PARM -25
+#define H_MLENGTH_PARM -27
+#define H_MEM_PARM -28
+#define H_MEM_ACCESS_PARM -29
+#define H_ATTR_PARM -30
+#define H_PORT_PARM -31
+#define H_MCG_PARM -32
+#define H_VL_PARM -33
+#define H_TSIZE_PARM -34
+#define H_TRACE_PARM -35
+
+#define H_MASK_PARM -37
+#define H_MCG_FULL -38
+#define H_ALIAS_EXIST -39
+#define H_P_COUNTER -40
+#define H_TABLE_FULL -41
+#define H_ALT_TABLE -42
+#define H_MR_CONDITION -43
+#define H_NOT_ENOUGH_RESOURCES -44
+#define H_R_STATE -45
+#define H_RESCINDEND -46
+
/* Long Busy is a condition that can be returned by the firmware
* when a call cannot be completed now, but the identical call
@@ -65,6 +99,9 @@
#define H_DABRX_KERNEL (1UL<<(63-62))
#define H_DABRX_USER (1UL<<(63-63))
+/* Each control block has to be on a 4K bondary */
+#define H_CB_ALIGNMENT 4096
+
/* pSeries hypervisor opcodes */
#define H_REMOVE 0x04
#define H_ENTER 0x08
@@ -116,6 +153,33 @@
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
+#define H_RESET_EVENTS 0x15C
+#define H_ALLOC_RESOURCE 0x160
+#define H_FREE_RESOURCE 0x164
+#define H_MODIFY_QP 0x168
+#define H_QUERY_QP 0x16C
+#define H_REREGISTER_PMR 0x170
+#define H_REGISTER_SMR 0x174
+#define H_QUERY_MR 0x178
+#define H_QUERY_MW 0x17C
+#define H_QUERY_HCA 0x180
+#define H_QUERY_PORT 0x184
+#define H_MODIFY_PORT 0x188
+#define H_DEFINE_AQP1 0x18C
+#define H_GET_TRACE_BUFFER 0x190
+#define H_DEFINE_AQP0 0x194
+#define H_RESIZE_MR 0x198
+#define H_ATTACH_MCQP 0x19C
+#define H_DETACH_MCQP 0x1A0
+#define H_CREATE_RPT 0x1A4
+#define H_REMOVE_RPT 0x1A8
+#define H_REGISTER_RPAGES 0x1AC
+#define H_DISABLE_AND_GETC 0x1B0
+#define H_ERROR_DATA 0x1B4
+#define H_GET_HCA_INFO 0x1B8
+#define H_GET_PERF_COUNT 0x1BC
+#define H_MANAGE_TRACE 0x1C0
+#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_ENABLE_CRQ 0x2B0
@@ -175,6 +239,42 @@ long plpar_hcall_4out(unsigned long opco
unsigned long *out3,
unsigned long *out4);
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-29 13:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143589234.2284.63.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 5568 bytes --]
On Wed, 2006-03-29 at 10:40 +1100, Benjamin Herrenschmidt wrote:
> The GPIO stuff is a bit can-of-worms-ish ... we need at least 2
> different implementations for machines using "old style" direct GPIO
> access and machines using platform functions. So we may need a gpio
> "driver" with 2 instances there.
Yeah, was thinking like that too.
> I think we need to hook that with the input/output net... basically we
> just say things like mute/unmute(id) and the gpio "layer" sort of
> matches the input/output "id" with whatever gpios it has at hand. That's
> also why I think your input/output IDs should have separate entries for
> combo connectors vs. analog line out (at least you used not to, I
> haven't looked at the latest code).
Note sure what you mean here...
> 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.
> 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.
> 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...
> 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 :)
> 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.
> > 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.
> > 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.
> - 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.
> 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...
> 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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-29 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc, Alastair Poole
In-Reply-To: <1143604878.3585.5.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
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.
> If I then try to rmmod it, the
> machine blows up. Haven't had time to track that down at this point.
That sucks.
> Appart from that, it works and I can play morse with myh SPID output :)
Heh yeah, we did that too :)
> Oh, and jackd seems to be unhappy even if I tell it to ignore the
> capture channels, it's probably a problem with setting the sample
> formats, I haven't looked in detail (yet).
Hmm. I'll try to see what jackd does.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Johannes Berg @ 2006-03-29 11:30 UTC (permalink / raw)
To: linuxppc-dev
On a PowerMac11,2, there are two i2c-bus@0 nodes of which only the first
is correct. This patch makes the device tree unflattening code ignore
the second one on those machines.
Signed-Off-By: Johannes Berg <johannes@sipsolutions.net>
---
I'm not sure this is the right way to do it. Maybe we should have some
'dev-tree quirks fixer' that makes a third pass through the device tree
after the allnodes chain has been set up, and fixes it up. On the other
hand, as long as there aren't too many workarounds, this works fine.
The patch looks longer than it is because some code changed indentation
level.
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -624,6 +624,11 @@ static void *__init unflatten_dt_alloc(u
return res;
}
+/* PowerMac11,2 has a bug in the device tree where
+ * an i2c-bus@0 shows up twice. We ignore the second
+ * one since it is the bogus one */
+static __initdata int powermac_i2c_bus_0_workaround = 0;
+
static unsigned long __init unflatten_dt_node(unsigned long mem,
unsigned long *p,
struct device_node *dad,
@@ -695,17 +700,31 @@ static unsigned long __init unflatten_dt
memcpy(p, pathp, l);
} else
memcpy(np->full_name, pathp, l);
+ DBG("node %s found\n", np->full_name);
prev_pp = &np->properties;
- **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;
+ /* 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);
}
@@ -745,6 +764,14 @@ static unsigned long __init unflatten_dt
}
if (strcmp(pname, "ibm,phandle") == 0)
np->linux_phandle = *((u32 *)*p);
+ /* we check the root node's compatible property
+ * to see if we need to start the powermac i2c
+ * workaround */
+ if ((pathp[0] == '\0') &&
+ (strcmp(pname, "compatible") == 0) &&
+ (strncmp((char*)*p, "PowerMac11,2", sz) == 0)) {
+ powermac_i2c_bus_0_workaround = 1;
+ }
pp->name = pname;
pp->length = sz;
pp->value = (void *)*p;
^ permalink raw reply
* Re: linux-2.6-rt patch on ppc85xx and OOM messages
From: emre kara @ 2006-03-29 10:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <77C1FC46-AF49-4807-9AC4-C3DC448F79BF@kernel.crashing.org>
The OOM messages disappeared but the ethernet
throughput decreased significantly (90MBit for
1518Byte packet, and throughput without the patch is
about 900Bits) and the system can't manage load
balancing between to interfaces,the system acts like
the priorty of tsec0 is higher then tsec1 because of
this, the heavy load on tsec0 blocks packet receiving
on tsec1.
--- Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Mar 29, 2006, at 12:45 AM, emre kara wrote:
>
> > Dear All,
> > Is Ingo Molnar's realtime-preempt patch compatible
> > with ppc, or is there any work on a porting effort
> of
> > this patch ? I have made some tests on a 85xx
> machine
> > with this patch, under heavy load on ethernet
> > interfaces, thw system prints OOM messages on
> console
> > and hangs..
> > Thanks.
>
> Can you try setting the gfar interrupts to
> SA_INTERRUPT and see what
> happens.
>
> - k
>
> > --------------------------console output-----
> > softirq-net-rx/: page allocation failure. order:0,
> > mode:0x20
> > Call Trace:
> > [C04E3DB0] [C000A60C] show_stack+0x50/0x188
> > (unreliable)
> > [C04E3DE0] [C004C3EC] __alloc_pages+0x1c8/0x2a4
> > [C04E3E30] [C0063C90]
> cache_alloc_refill+0x35c/0x57c
> > [C04E3E80] [C0063FA4] __kmalloc+0xf4/0xfc
> > [C04E3EB0] [C012D460] __alloc_skb+0x58/0x118
> > [C04E3ED0] [C011AF20] gfar_new_skb+0x40/0xd4
> > [C04E3EF0] [C011D320]
> gfar_clean_rx_ring+0x25c/0x634
> > [C04E3F30] [C011D72C] gfar_poll+0x34/0x140
> > [C04E3F50] [C013364C] net_rx_action+0x94/0x188
> > [C04E3F80] [C0026730] ksoftirqd+0x104/0x1b4
> > [C04E3FC0] [C003779C] kthread+0xf8/0x100
> > [C04E3FF0] [C0004DB8] kernel_thread+0x44/0x60
> > Mem-info:
> > DMA per-cpu:
> > cpu 0 hot: high 90, batch 15 used:0
> > cpu 0 cold: high 30, batch 7 used:0
> > DMA32 per-cpu: empty
> > Normal per-cpu: empty
> > HighMem per-cpu: empty
> > Free pages: 768kB (0kB HighMem)
> > Active:1650 inactive:2036 dirty:0 writeback:0
> > unstable:0 free:192
> > slab:60106 mapped:764 pagetables:29
> > DMA free:768kB min:2048kB low:2560kB high:3072kB
> > active:6600kB
> > inactive:8144kB present:262144kB pages_scanned:0
> > all_unreclaimab
> > le? no
> > lowmem_reserve[]: 0 0 0 0
> > DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB
> > inactive:0kB
> > present:0kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0 0
> > Normal free:0kB min:0kB low:0kB high:0kB
> active:0kB
> > inactive:0kB
> > present:0kB pages_scanned:0 all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0 0
> > HighMem free:0kB min:128kB low:128kB high:128kB
> > active:0kB
> > inactive:0kB present:0kB pages_scanned:0
> > all_unreclaimable? no
> > lowmem_reserve[]: 0 0 0 0
> > DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> 1*256kB
> > 1*512kB 0*1024kB
> > 0*2048kB 0*4096kB = 768kB
> > DMA32: empty
> > Normal: empty
> > HighMem: empty
> > Swap cache: add 0, delete 0, find 0/0, race 0+0
> > Free swap = 0kB
> > Total swap = 0kB
> > Free swap: 0kB
> > 65536 pages of RAM
> > 0 pages of HIGHMEM
> > 662 free pages
> > 1180 reserved pages
> > 1249 pages shared
> > 0 pages swap cached
> > printk: 2159030 messages suppressed.
> >
> >
> >
> >
> >
>
___________________________________________________________
> > Yahoo! Photos – NEW, now offering a quality print
> service from just
> > 8p a photo http://uk.photos.yahoo.com
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
^ permalink raw reply
* "lseek/write char driver" versus "usermode iomem access"
From: Josef Angermeier @ 2006-03-29 8:22 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
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!
Josef
^ 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