* Re: VME driver problem on MVME6100
From: Konstantin Boyanov @ 2006-05-25 23:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <929bf310605251200s66106eaer@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2960 bytes --]
2006/5/25, Konstantin Boyanov <kkboyanov@gmail.com>:
>
> Hi again,
>
> The problem persist even with the new driver for 2.6 ... :(
> It is obvious that the driver cannot allocate memory for the window... It
> fails that thing called __ioremap(), whatever it might be used for:
>
> [mvme6100]# vme_setoutboundwin -h
> vme_setoutboundwin
> Usage: vme_setoutboundwin <options>
> -w <window> window(where 0<=window<=6)
> -m <mode> address mode (where
> 0=A16,1=A24,2=A32,3=A64,4=CRCSR)
> -p <protocol> protocol (where
> 1=SCT,2=BLT,4=MBLT,8=2eVME,0x10=2eSST)
> -a <VME addr> VME address
> -d <data width> data width (8, 16, 32, 64)
> -s <window size> window size (where 0 < window_size <=
> 0x400000)
> -v Be more verbose
> -h Give this (short) help
>
> [mvme6100]# vme_setoutboundwin -w0 -m0 -p8 -a0x8800 -d16 -s400000 -v
> window = 0, mode = 0 protocol 0x8 vme_addr = 0x8800 data width = 16
> __ioremap(): phys addr 01000000 is RAM lr d100be34
> vmedrv: No memory for outbound window
> ioctl VME_IOCTL_SET_OUTBOUND failed.: Cannot allocate memory
>
> While searching on the web for information about __ioremap I found this:
>
> /*
> * Remap an arbitrary physical address space into the kernel virtual
> * address space. Needed when the kernel wants to access high addresses
> * directly.
> *
>
> * NOTE! We need to allow non-page-aligned mappings too: we will obviously
> * have to convert them into an offset in a page-aligned mapping, but the
> * caller shouldn't need to know that small detail.
> */
>
>
> And another thing - people should not be using __ioremap() unless they
> have a _good_ _reason_ in their driver. They should be using ioremap()
> instead. __ioremap() is an architecture implementation detail which
>
> has no interface stability guarantees _at all_.
>
> How's that? So it seems that the kernel can't translate the accesses to
> the VME bus propperly. Any ideas how to fix that?
> Actually I cant figure out why configuring a single outbound window is so
> damn tough to achieve.e maybe I'm missing some crutial settings. I tried
> to set up the window attribute register, and the outbound translation offset
> register in the hope to fit in the needed size for the window, but again
> failed. I'm trying to get frustrated about that...
>
> Best regards,
> Konstantin
>
> P.S. I forgot to say that on the target I'm booting a bare kernel with
not much functionality. Could it be that there are missing some settings for
the virtual memory management, which are crutial for the VME driver? I mean
the above message "phys addr 01000000 is RAM lr d100be34" is somehow
connected to misconfiguration (or lack of it at all) for the virtual memory
pages? That's what I can think of som late in the night...
Thank you anyways.
Best regards,
Konstantin
[-- Attachment #2: Type: text/html, Size: 4146 bytes --]
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Benjamin Herrenschmidt @ 2006-05-26 1:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148553785.11759.12.camel@johannes.berg>
On Thu, 2006-05-25 at 12:43 +0200, Johannes Berg wrote:
> Hey,
>
> In order to replace snd-powermac for the newer machines where the
> 'sound' node has the 'layout-id' property, I'm looking for testers on
> machines that have a layout-id [1] property with one of the following
> values: 0x24, 0x29, 0x33, 0x50 and 0x3a.
Some tips:
0x24 is old G5's (PowerMac7,2 and 7,3) primary i2s bus
0x29 is not in my list so I don't know what machine it is
0x33 is aluminium powerbook 15" rev. 2 (PowerMac5,4)
0x3a is mac mini (I can test that one one of these days but we'll need
the
toonie codec, which is basically a "null" codec with only
the amps GPIOs available)
0x50 is not in my list
Also not in your list nor in the driver:
0x3c is recent single CPU desktop G5 (PowerMac9,1) (SMU based) bus
i2s-a
0x3d is same as above bus i2s-c
The later is a onyx + topaz setup iirc, possibly similar to the quad.
> Once I have all these, I will, along with submitting snd-aoa [2], submit
> a patch to snd-powermac that makes it refuse loading in presence of a
> layout-id property as a first step to migrate to snd-aoa.
>
> At the same time, I'll probably make i2sbus refuse attaching to a device
> unless there's a layout-id property so that it doesn't claim devices aoa
> doesn't handle yet.
>
> johannes
>
> [1] to find your layout-id, execute the following:
>
> find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'
>
> If you get no output, you have no layout-id property. If you do get
> output, it will look like this:
> 0x46
> This is the layout-id of your sound node.
>
> [2] Before you ask: I will not do this before snd-aoa supports headphone
> detection :)
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Benjamin Herrenschmidt @ 2006-05-26 1:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148553785.11759.12.camel@johannes.berg>
> Once I have all these, I will, along with submitting snd-aoa [2], submit
> a patch to snd-powermac that makes it refuse loading in presence of a
> layout-id property as a first step to migrate to snd-aoa.
>
> At the same time, I'll probably make i2sbus refuse attaching to a device
> unless there's a layout-id property so that it doesn't claim devices aoa
> doesn't handle yet.
I think we need to be careful about a couple other things:
- We need non-pmf GPIO. Some layout-id based machines do need that,
like the mac mini
- I'm tempted to rename soundbus/i2sbus to snd-aoa-soundbus and
snd-aoa-i2sbus (at least the module names) for now.
Ben.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-26 1:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148550168.11759.0.camel@johannes.berg>
On Thu, 2006-05-25 at 11:42 +0200, Johannes Berg wrote:
> On Thu, 2006-05-25 at 18:00 +1000, Benjamin Herrenschmidt wrote:
>
> > So it's bcm's fault ? Did you do a bit of analysis ? that would be
> > useful...
>
> I kinda assumed the list was lagging again and my brother had already
> posted the solution. Yes, bcm does some measuring stuff that keeps
> interrupts disabled for lots of milliseconds (25 or something). It's
> being fixed.
>
> I still think, however, that we ought to be able to deal with lost
> interrupts.
Oh sure, but it's also useful to have a way to find who are the bast*rds
who are causing big latencies so we can fix them :)
Ben.
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Benjamin Herrenschmidt @ 2006-05-26 6:03 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1147960321.7607.9.camel@localhost.localdomain>
On Thu, 2006-05-18 at 08:52 -0500, Matthew McClintock wrote:
> Do you have any comments about how you envision updating the "virtual"
> mode image with information passed from the boot loader? I am asking
> this from the standpoint of updating the "virtual" flat tree with
> correct values, in order to boot from older firmware.
Well, that's what need to be discussed... I'll read Mark replies and
others and will try to come up with my own comments/suggestions asap.
I'm a bit overflowed with stuff at the moment though.
Ben.
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-26 6:05 UTC (permalink / raw)
To: Andy Fleming
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <2800AE5B-623D-4F1A-99A4-A67EF89A0D77@freescale.com>
On Thu, 2006-05-18 at 15:49 -0500, Andy Fleming wrote:
>
>
> So some of this needs to be moved into u-boot (look at my patches to
> u-boot for the 85xx CDS support, and support in the current
> powerpc.git tree). A lot of the PCI initialization is now there.
> However, the interrupt maps, while properly setup in the current
> 85xx
> u-boot oftree.dts files, is currently meaningless. I may be wrong,
> but I thought support for getting the map from the flat-dev tree was
> still pending....
Well, the kernel does get the map from the tree but can't use it if the
device itself doesn't have a device-node. I'll fix that for 2.6.18
hopefully.
Ben.
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-26 6:19 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Paul Mackerras, cbe-oss-dev, Arnd Bergmann,
Steve Munroe
In-Reply-To: <20060519051939.GJ8220@pb15.lixom.net>
So, replying to Olof and myself and asking for Steve Munroe point of
view...
> How are other userspace-exposed erratas normally handled? How are they
> handled on other architectures? Adding it to the feature aux table
> sounds like a bad idea.
Well, I suspect so far we have avoided the problem by just assuming
there are no such erratas :)
It's an ABI issue so I'd like Steve to provide some feedback on this. I
suppose we should probably define an AT_CPU_ERRATA capability
> > - Additional Altivec instructions (load/store right/left). A new
> > feature bit for these ?
I think a new feature bit is the way to go but we need to start now
about how to extend our feature bit facility, maybe by defining an
AT_HWCAP2 ? Steve, what is your position there ?
> > - Lack of data stream instructions. Until now, it was assumed that
> > those were tied to the presence
> > of an Altivec (and they are documented in the Altivec manual). Maybe
> > we should split that to a
> > new bit. I don't know if existing applications use them though, if
> > they do, there will be a
> > problem to get them updated as the new bit isn't present on older
> > kernels...
>
> I'm assuming you mean the instructions described under "AltiVec Memory
> Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
> dstst, dss and dssall?
Yes.
> Since they're explicitly part of the Altivec ISA, not the PPC ISA,
> I don't see a need for a separate feature bit for them. They are not
> marked as optional in the version I'm looking at right now (2.0).
They are not implemented on Cell though. I don't know yet if they are
NOP's or if they fault but we should still inform userland of the
situation.
Thus should we add a feature bit documenting the existence of those
instructions or should we use an errata bit (provided we define
something for passing them as suggested above) ?
> > - Extended implementation of dcbt. (Another bit ? Or sould we just have
> > a "CELL" bit ? In which
> > case should it cover the altivec additions too or are those likely to
> > exist in future non-Cell
> > processors ?)
>
> If you're referring to the extended dcbt that includes streaming hints
> (as documented in the 64-bit PEM, but not in PPC book2 2.02), then a
> separate bit is likely needed -- obviously at least 970 seems to
> implement them.
Yes, I think a new CPU feature bit for that too is needed. Not much of
these left...
> > - Not strictly Cell specific but we currently don't expose the support
> > for optional instructions
> > fres and frsqte (which are supported by Cell)
> >
> > Part of the problem is that we only have 32 userland feature bits and
> > for some reason decided to put the microarchitecture in there, thus we
> > are running out fast...
>
> From what I understood by Paul's choice of feature naming (see the
> POWER6 patch discussions), PPC_ARCH_2_05 and similar will mean base
> architecture version implemented and should not be used to assume
> anything about optional features.
>
> So, with that as a base, there will need to be a way to
> indicate which optional features are available, plus what possible
> extensions/implementation-specific features are there, at least if they
> are common to more than one implementation/processor version. Bit arrays
> seem to be the New Way of doing it between firmware and kernel, maybe
> the same can/should be used for kernel->userspace? Can the aux vectors
> be of arbitrary length?
So the question is should we specify a feature bit for fres and frsqte
or should we let userland assume they are always there on a given
microarchitecture level ?
Steve, another solution is to go to a completely different model (maybe
closer than what apple does) and add an interface similar to Apple old
Gestalt (as mentioned by Alex Rosenberg in a separate email) that could
go through the vDSO. The idea boils down to replacing our current
bitmaps with something like:
__kernel_cpu_feature(const char *name);
(Apple Gestalt returns a long in addition to a result code that can
contain arbitrary things like version numbers etc... but I'm against
that, I have first hand experience on how that can be abused :) I prefer
a simple boolean result.
The "feature" are named (ascii strings) with a strict naming convention.
For example, erratas always start with "err-", optional architecture
bits with "opt-", totally chip specific functions "chip-", etc...
As far as userland is concerned, glibc could expose a lot of this
through sysconf, or provide a way to get to the vDSO call (though we'll
have to fight with the folks there).
That doesn't completely solve another pending problem we have with
passing down to userland other specific infos like L2/L3 cache
characteristics but I don't see a good solution yet there. Maybe a
separate vDSO call for use by glibc to use to implement sysconf ? Among
the things we've been asked are cache line sizes (we have L1 I and D
already in AT_*), cache associativity (generally available in the device
tree but not provided to userland), cache total size (we put some L1
infos in the deprecated-but-still-present systemcfg, we need a
replacement API), etc... Note that we have been requested to also add
L2/L3 infos but I noticed that our firmware doesn't tell us on modern
CPUs, thus for each of these infos, we also need a way to say "unknown".
Ben.
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-26 6:19 UTC (permalink / raw)
To: Andrew Pinski
Cc: Olof Johansson, linuxppc-dev list, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <11D4E003-85A4-48A0-9654-BEAE5600B89C@physics.uc.edu>
> > I'm assuming you mean the instructions described under "AltiVec Memory
> > Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
> > dstst, dss and dssall?
>
> They are nops on the Cell though. They are also microcoded on the 970.
It's still useful to have a way to inform userland of their absence (or
inefficency).
> > If you're referring to the extended dcbt that includes streaming hints
> > (as documented in the 64-bit PEM, but not in PPC book2 2.02), then a
> > separate bit is likely needed -- obviously at least 970 seems to
> > implement them.
>
> Yes they are implemented on the 970.
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-26 6:22 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linuxppc-dev list, Paul Mackerras, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <20060519081654.GB22952@iram.es>
On Fri, 2006-05-19 at 10:16 +0200, Gabriel Paubert wrote:
> Is this bug really going to be exposed in the wild or is it
> an early silicon bug that will only bite early-testers?
In the wild.
> > - Additional Altivec instructions (load/store right/left). A new
> > feature bit for these ?
>
> Yes. So IBM was not happy with Altivec instructions to generate
> vsel control words and got their inspiration from MIPS?
No idea ;)
> Is it really important? These instructions become nop on Cell, so their
> impact on performance should be minimal while they may be useful in
> code designed to run on any processor having Altivec.
We can ignore that problem (datastream, I cut too much of the original
message :) I suppose but I'd like to have as much point of views here as
we are tackling kernel ABI issues so we can't change things every five
minutes here.
> I believe that a Cell bit would be useful. After all you need a bit
> that tell you that you have the SPUs and related infrastructure?
We already have microarchitecture and SPUs can be detected via the
device-tree or sysfs. But that dcbt X form also exist on other
processors
> > - Not strictly Cell specific but we currently don't expose the support
> > for optional instructions
> > fres and frsqte (which are supported by Cell)
>
> Should be exposed IMHO. But these instructions have been present
> in a lot of PPC processors AFAIR, they are in my original 603 and
> 604 manuals from 1994 (fsel is also marked as optional and is not
> implemented on the 601, but I'm not sure it's really supported
> anymore). I don't know about Power processors.
So what do you suggest I do ? Add feature bits for them and for fsel
too ?
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-26 6:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev list, cbe-oss-dev
In-Reply-To: <200605191211.18737.arnd@arndb.de>
On Fri, 2006-05-19 at 12:11 +0200, Arnd Bergmann wrote:
> On Friday 19 May 2006 06:07, Benjamin Herrenschmidt wrote:
> > - Extended implementation of dcbt. (Another bit ? Or sould we just have
> > a "CELL" bit ? In which case should it cover the altivec additions too
> > or are those likely to exist in future non-Cell processors ?)
>
> Isn't that already covered by PPC_FEATURE_CELL? Git log shows
Not specific to cell, 970 at least has it too.
Ben.
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Olof Johansson @ 2006-05-26 6:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Olof Johansson, cbe-oss-dev
In-Reply-To: <1148624357.8089.88.camel@localhost.localdomain>
On Fri, May 26, 2006 at 04:19:17PM +1000, Benjamin Herrenschmidt wrote:
> So, replying to Olof and myself and asking for Steve Munroe point of
> view...
>
> > How are other userspace-exposed erratas normally handled? How are they
> > handled on other architectures? Adding it to the feature aux table
> > sounds like a bad idea.
>
> Well, I suspect so far we have avoided the problem by just assuming
> there are no such erratas :)
>
> It's an ABI issue so I'd like Steve to provide some feedback on this. I
> suppose we should probably define an AT_CPU_ERRATA capability
>
> > > - Additional Altivec instructions (load/store right/left). A new
> > > feature bit for these ?
>
> I think a new feature bit is the way to go but we need to start now
> about how to extend our feature bit facility, maybe by defining an
> AT_HWCAP2 ? Steve, what is your position there ?
And what happens when that gets full? Or can we make that one dynamic in
size?
> > > - Lack of data stream instructions. Until now, it was assumed that
> > > those were tied to the presence
> > > of an Altivec (and they are documented in the Altivec manual). Maybe
> > > we should split that to a
> > > new bit. I don't know if existing applications use them though, if
> > > they do, there will be a
> > > problem to get them updated as the new bit isn't present on older
> > > kernels...
> >
> > I'm assuming you mean the instructions described under "AltiVec Memory
> > Bandwidth Management" in secion 5.2 of the Altivec PEM -- dst, dstt,
> > dstst, dss and dssall?
>
> Yes.
>
> > Since they're explicitly part of the Altivec ISA, not the PPC ISA,
> > I don't see a need for a separate feature bit for them. They are not
> > marked as optional in the version I'm looking at right now (2.0).
>
> They are not implemented on Cell though. I don't know yet if they are
> NOP's or if they fault but we should still inform userland of the
> situation.
>
> Thus should we add a feature bit documenting the existence of those
> instructions or should we use an errata bit (provided we define
> something for passing them as suggested above) ?
Only if there's truly uses for it. Do we really want to allocate global
bits for every errata that every vendor introduces?
Do we see this likely to be used in "global userspace", or more likely
in the processor-specific glibc sections? If it's in the
processor-specific ones, maybe we should have a per-processor bitfield
with erratas/features instead of a global one. That'd make allocation
easier too.
I.e. a main feature bitmask like we have now (architecture base
version), and a sub-bitmask with the optional features. That also avoids
the issue of allocating a global bit for something that is a feature in
version X but non-optional in X+1, you can never "get that bit back".
> > > - Extended implementation of dcbt. (Another bit ? Or sould we just have
> > > a "CELL" bit ? In which
> > > case should it cover the altivec additions too or are those likely to
> > > exist in future non-Cell
> > > processors ?)
> >
> > If you're referring to the extended dcbt that includes streaming hints
> > (as documented in the 64-bit PEM, but not in PPC book2 2.02), then a
> > separate bit is likely needed -- obviously at least 970 seems to
> > implement them.
>
> Yes, I think a new CPU feature bit for that too is needed. Not much of
> these left...
Well, are these instructions architected in some later version past
2.02? If so, the bit is only needed on the older processors -- yet again
a case for sub-feature/errata bitmasks.
[rest is good discussion but I don't have much input on it at this time.
Something gestalt-like could be good, it'd help remove some of the
current limits on bitmap sizes, etc]
-Olof
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-26 6:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Fleming Andy-afleming
Cc: linuxppc-dev list, Paul Mackerras, Alexandre.Bounine,
Yang Xin-Xin-r48390
>
> On Thu, 2006-05-18 at 15:49 -0500, Andy Fleming wrote:
> >
> >
> > So some of this needs to be moved into u-boot (look at my
> patches to
> > u-boot for the 85xx CDS support, and support in the current
> > powerpc.git tree). A lot of the PCI initialization is now there.
> > However, the interrupt maps, while properly setup in the
> current 85xx
> > u-boot oftree.dts files, is currently meaningless. I may be wrong,
> > but I thought support for getting the map from the flat-dev
> tree was
> > still pending....
>
> Well, the kernel does get the map from the tree but can't use
> it if the device itself doesn't have a device-node. I'll fix
> that for 2.6.18 hopefully.
>
> Ben.
>
What should we do?
Can we keep the map table unitl your code
is OK?
Roy
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Johannes Berg @ 2006-05-26 7:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148606268.8089.12.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Fri, 2006-05-26 at 11:17 +1000, Benjamin Herrenschmidt wrote:
> I think we need to be careful about a couple other things:
>
> - We need non-pmf GPIO. Some layout-id based machines do need that,
> like the mac mini
Yeah, I saw that, but I need more insight into how that should work with
a feature call or so...
> - I'm tempted to rename soundbus/i2sbus to snd-aoa-soundbus and
> snd-aoa-i2sbus (at least the module names) for now.
Yeah, I guess that ought to be done. Not just the module names, also the
sysfs visible part (though that's easy).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-26 7:33 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Paul Mackerras, cbe-oss-dev, Arnd Bergmann,
Steve Munroe
In-Reply-To: <20060526064341.GA6183@pb15.lixom.net>
> > I think a new feature bit is the way to go but we need to start now
> > about how to extend our feature bit facility, maybe by defining an
> > AT_HWCAP2 ? Steve, what is your position there ?
>
> And what happens when that gets full? Or can we make that one dynamic in
> size?
You can't make AT_* entries dynamic, though we can be ugly and have them
contain an offset to some space on the stack with a blob, though that
would require serious hacks in the kernel's binfmt_elf I suppose. Even
if it's a bit ugly, there is no fundamental problem with adding
AT_HWCAP2 and maybe later 3 etc... A given bit is defined to be in a
given one of these, thus apps who know about a bit that is in AT_HWCAP-N
(and are looking for it) will also know about AT_HWCAP-N. Still ugly
tho.
> > Thus should we add a feature bit documenting the existence of those
> > instructions or should we use an errata bit (provided we define
> > something for passing them as suggested above) ?
>
> Only if there's truly uses for it. Do we really want to allocate global
> bits for every errata that every vendor introduces?
If they affect userland, yes.
> Do we see this likely to be used in "global userspace", or more likely
> in the processor-specific glibc sections? If it's in the
> processor-specific ones, maybe we should have a per-processor bitfield
> with erratas/features instead of a global one. That'd make allocation
> easier too.
Do we have to deal with that many errata that affect userland ? It's
generally an area where processors are fairly well validated... I don't
think we need to scale up that much on this one.
> I.e. a main feature bitmask like we have now (architecture base
> version), and a sub-bitmask with the optional features. That also avoids
> the issue of allocating a global bit for something that is a feature in
> version X but non-optional in X+1, you can never "get that bit back".
Could be. Steve, what do you think ?
> > Yes, I think a new CPU feature bit for that too is needed. Not much of
> > these left...
>
> Well, are these instructions architected in some later version past
> 2.02? If so, the bit is only needed on the older processors -- yet again
> a case for sub-feature/errata bitmasks.
I have to check but I suspect it's still optional.
> [rest is good discussion but I don't have much input on it at this time.
> Something gestalt-like could be good, it'd help remove some of the
> current limits on bitmap sizes, etc]
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-26 7:34 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673064DA761@zch01exm40.ap.freescale.net>
> What should we do?
> Can we keep the map table unitl your code
> is OK?
Or you could have your platform-specific fixup_irq walk the
interrupt-map property in the tree, still better than a table and allows
you to validate the tree. When my code is fixed, you can then just
remove your fixup.
Ben.
^ permalink raw reply
* RE: Help Needed: floating point used in kernel (task=c0398410, pc =3184)
From: sandeep malik @ 2006-05-26 7:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673026FD914@zch01exm40.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]
.Hi All...
The problem has been resolved and was no where related to the hardware or software using the floating points....Actually it was associated with wrong linkage....the code was being compiled with gclibc and linked with uClibc....so sometime it was working and sometime it was failing and that too at various different points......
Thanks everyone for ur help.....
Regards,
Malik
.
Liu Dave-r63238 <DaveLiu@freescale.com> wrote:
Malik,
Because PPC8325 have NO float point unit, so please compile all of source code with gcc 8325 compiler
or use fixed simulate. The source code includs kernel, and filesystem.
Dave
-----Original Message-----
Hi All...
I am trying to run an application compiled with gcc toolchain gcc--3.4.3 and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I am getting following error....
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
I was suspecting this error might be because the hardware is not supporting floating point operations and hence i tried a simple program in which I intentionally did some floating point operation but that program was running as expected. So i concluded that it is not a problem related to floating point operations....I even tried compiling the application with classic ppc compiler(Ver 3.4.3) with -msoft-float option enabled, but still the results were same......
After these errors i am not able to get control of the system. If anyone who faced this or any such related issue please help me out like what could be probable reason for this error and what all options i have to debug this issue.....
Thanks & Regards,
Malik
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
---------------------------------
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
[-- Attachment #2: Type: text/html, Size: 2755 bytes --]
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: Roger Larsson @ 2006-05-26 7:49 UTC (permalink / raw)
To: sandeep malik, linuxppc-embedded
In-Reply-To: <20060526073815.32337.qmail@web8401.mail.in.yahoo.com>
On fredag 26 maj 2006 09.38, you wrote:
> Hi Roger,
>
> =A0 The problem has been resolved...the issue was in the make
> file.....actually we were cpmiling the code with gclibc and linking it wi=
th
> uClibc which was causing the problem.....But this was real test i faced
> till now as all the tricks realted to the message were failed.....any ways
> thanks for ur help....=20
> =A0 Regards,
> =A0 Malik
Now I am confused!
How could this cause
"floating point used in kernel (task=3Dc0398410, pc=3D3184)"
Both uClibc and gclibc are user land libraries. They should not be able to
cause an kernel floating point operation. No user land code should be able
to do this!
Or is it your kernel linked with uClibc/gclibc? I do not think that is the
right thing to do...
/RogerL
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Benjamin Herrenschmidt @ 2006-05-26 7:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148628484.16989.3.camel@johannes.berg>
On Fri, 2006-05-26 at 09:28 +0200, Johannes Berg wrote:
> On Fri, 2006-05-26 at 11:17 +1000, Benjamin Herrenschmidt wrote:
>
> > I think we need to be careful about a couple other things:
> >
> > - We need non-pmf GPIO. Some layout-id based machines do need that,
> > like the mac mini
>
> Yeah, I saw that, but I need more insight into how that should work with
> a feature call or so...
Well, look at the tumbler code. The address you pass to the feature call
is the GPIO offset from the beginning of mac-io. Since Apple stuff isn't
always consistent, you have 2 ways of getting to it:
- Use the "reg" property as normally expected... except that Apple has
bugs there where that property contains an offset that is either
relative to the beginning of the GPIO block (which itself is at 0x50 in
mac-io) or to the beginning of mac-io. It _seems_ however that they are
consistent with the bug in the sense that most GPIOs are relative to the
GPIO block except the audio ones that are relative to the beginning of
mac-io. The "trick" you can use is that since the GPIO block is less
than 0x50 bytes long, you can take the value of "reg" and do something
like:
offset = (reg >= 0x50) ? reg : (reg + 0x50);
It's ugly but will work I think will all incarnations of mac-io
- Specifically for audio-GPIOs it seems that they also have an
AAPL,address property that contains the physical address of the GPIO
within mac-io. For example, headphone-detect on the mac-mini contains:
AAPL,address 80000067
In that case, what you can do is take that property and strip off the
top bits
offset = aapl_addr & 0xff;
In both case, the resulting offset can then be passed to the feature
calls to access the GPIOs. Now there is the problem of the format of the
8 bits value you read/write. It's not exactly the same between keylargo
and k2/shasta (wether you have a G5 or not). However, since the later
always use platform functions afaik, it's a non-issue and thus you only
have to handle the old-style ones.
#define KEYLARGO_GPIO_OUTPUT_ENABLE 0x04
#define KEYLARGO_GPIO_OUTOUT_DATA 0x01
#define KEYLARGO_GPIO_INPUT_DATA 0x02
So to configure a GPIO as an input, make sure 0x04 is cleared. You can
read the input value then on bit 0x02. For some GPIOs, you want to leave
them as open collector (that is asserted to 0 or floating). In that
case, asserted to 0 is 0x04 (output enabled set to 1 and output data set
to 0) and floating (high-Z) is 0x00 (configurd as input). If you want to
always assert the GPIO, then use 0x04 and 0x05 as 0 and 1 values. (Look
what darwin does there).
You may want to have a look at the gpio code from Ben Collins too,
though it could be simplified now that we only deal with old-style ones.
On those old-style ones, there is a property "audio-gpio-active-state"
that gives you the polarity of the output.
In addition, look for "has-anded-reset" property (in the "sound" node).
Some platforms have that to tell you that setting both mutes at the same
time resets the codec. Thus you may have to be especially careful. Have
also a look at AppleMacRISC2PE since I think it adds or removes that
property on some machines.
> > - I'm tempted to rename soundbus/i2sbus to snd-aoa-soundbus and
> > snd-aoa-i2sbus (at least the module names) for now.
>
> Yeah, I guess that ought to be done. Not just the module names, also the
> sysfs visible part (though that's easy).
Yup.
Ben.
^ permalink raw reply
* Re: [PATCH 5/5] Updates for WRS SBC82xx boards
From: Vitaly Bordug @ 2006-05-25 21:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060525183231.GG679@windriver.com>
On Thu, 25 May 2006 14:32:32 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> patch5: fcc_enet-mac-addr.diff1
> - restore proper collection of mac addr data in obsolete FCC
> driver by replacing mix of #ifdef and if() with case
8260_io stuff is obsoleted by fs_enet. You should fit the board into
ppc_sys infrastructure, fill the platform data and do per-board
initialization in board-specific file - refer to
platforms/mpc8272_setup.c for example...
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
>
>
> --- linux-2.6.16_rc5/arch/ppc/8260_io/fcc_enet.c.orig
> 2006-01-02 22:21:10.000000000 -0500 +++
> linux-2.6.16_rc5/arch/ppc/8260_io/fcc_enet.c 2006-02-27
> 18:01:45.000000000 -0500 @@ -1962,32 +1962,30 @@
> * non-static part of the address.
> */
> eap = (unsigned char *)&(ep->fen_paddrh);
> - for (i=5; i>=0; i--) {
>
> /*
> * The EP8260 only uses FCC3, so we can safely give it the real
> * MAC address.
> */
> + for (i=5; i>=0; i--) switch(i) {
> + case 5:
> #ifdef CONFIG_SBC82xx
> - if (i == 5) {
> /* bd->bi_enetaddr holds the SCC0 address;
> the FCC devices count up from there */
> dev->dev_addr[i] = bd->bi_enetaddr[i] & ~3;
> dev->dev_addr[i] += 1 + fip->fc_fccnum;
> *eap++ = dev->dev_addr[i];
> - }
> -#else
> -#ifndef CONFIG_RPX8260
> - if (i == 3) {
> + break;
> +#endif
> + case 3:
> +#if !defined(CONFIG_RPX8260) && !defined(CONFIG_SBC82xx)
> dev->dev_addr[i] = bd->bi_enetaddr[i];
> dev->dev_addr[i] |= (1 << (7 -
> fip->fc_fccnum)); *eap++ = dev->dev_addr[i];
> - } else
> + break;
> #endif
> - {
> + default:
> *eap++ = dev->dev_addr[i] =
> bd->bi_enetaddr[i];
> - }
> -#endif
> }
>
> ep->fen_taddrh = 0;
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: [PATCH 4/5] Updates for WRS SBC82xx boards
From: Vitaly Bordug @ 2006-05-26 8:09 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-embedded
In-Reply-To: <20060525183036.GF679@windriver.com>
On Thu, 25 May 2006 14:30:38 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> patch4: sbc82xx-mchk-pci9.diff1
> - restore machine check disable for PCI9 that was in earlier
> m8260_pci.c
>
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
>
>
> --- linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c.orig
> 2006-02-27 15:02:01.000000000 -0500 +++
> linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c 2006-02-27
> 16:05:20.000000000 -0500 @@ -227,6 +227,11 @@
> immap->im_memctl.memc_pcibr1 = M82xx_PCI_SEC_WND_BASE |
> PCIBR_ENABLE; #endif
> +#ifdef CONFIG_8260_PCI9
> + /* Disable machine check on no response or target abort */
> + immap->im_pci.pci_emr = cpu_to_le32(0x1fe7);
> +#endif
> +
No need in such a level of splitness - this is going to be hard to
understand in common...
> #if defined CONFIG_ADS8272
> immap->im_siu_conf.siu_82xx.sc_siumcr =
> (immap->im_siu_conf.siu_82xx.sc_siumcr &
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: [PATCH 2/5] Updates for WRS SBC82xx boards
From: Vitaly Bordug @ 2006-05-26 8:22 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: p_gortmaker, linuxppc-embedded
In-Reply-To: <20060525182533.GD679@windriver.com>
On Thu, 25 May 2006 14:25:33 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> patch2: sbc82xx-PCI-diff1
> - allow m82xx_pci.c to be used by other platforms that have
> their own map_irq
>
> I'm open to doing this another way if desired -- I just went for the
> minimal impact on the existing code with this.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
>
> diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c ---
> orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09
> 16:20:35.000000000 -0500 +++
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09
> 16:01:40.000000000 -0500 @@ -198,7 +198,7 @@ } }
>
> -static int sbc82xx_pci_map_irq(struct pci_dev *dev, unsigned char
> idsel, +int pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel,
> unsigned char pin)
> {
> static char pci_irq_table[][4] = {
> @@ -247,7 +247,7 @@
> callback_init_IRQ = ppc_md.init_IRQ;
>
> ppc_md.init_IRQ = sbc82xx_init_IRQ;
> - ppc_md.pci_map_irq = sbc82xx_pci_map_irq;
> + ppc_md.pci_map_irq = pq2pci_map_irq;
> #ifdef CONFIG_GEN_RTC
> ppc_md.time_init = NULL;
> ppc_md.get_rtc_time = NULL;
> diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h ---
> orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09
> 16:20:35.000000000 -0500 +++
> linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09
> 16:35:05.000000000 -0500 @@ -24,6 +24,7 @@ #define
> BOOTROM_RESTART_ADDR ((uint)0x40000104)
> +#define HAVE_OWN_PQ2PCI_IRQ
> #define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
> #define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
> #define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
> diff -ur orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c
> linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c ---
> orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-01-02
> 22:21:10.000000000 -0500 +++
> linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-02-09
> 14:35:10.000000000 -0500 @@ -51,6 +51,10 @@
> * Interrupt routing
> */
>
> +#ifdef HAVE_OWN_PQ2PCI_IRQ
> +extern int
> +pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
> char pin); +#else
> static inline int
> pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
> char pin) {
> @@ -172,6 +176,7 @@
> setup_irq(PCI_INT_TO_SIU, &pq2pci_irqaction);
> return;
> }
> +#endif /* HAVE_OWN_PQ2PCI_IRQ */
Sorry, but I don't quite follow the reason of that. As I see,
you are going to call find_bridges stuff but with demux disabled.
I see no reason to add any defines - if you won't call init_irq,
nothing will happen, I mean demux will not be assigned and so on. BTW,
right now it will not be issued in case of sbc82xx. It is not code-size
optimal, but we'll leave optimizations to arch/powerpc time.
Actually, you'll just have to override map_irq with sbc_ thing after
find_bridges() call.
>
> static int
> pq2pci_exclude_device(u_char bus, u_char devfn)
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Jeff Garzik @ 2006-05-26 8:56 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linuxppc-dev list, Yang Xin-Xin-r48390,
linux-kernel, linux-ide, Paul Mackerras, Mark Lord
In-Reply-To: <20060526083931.GA23938@powerlinux.fr>
Sven Luther wrote:
> On Thu, May 18, 2006 at 04:50:46PM -0400, Mark Lord wrote:
>> Jeff Garzik wrote:
>>> Benjamin Herrenschmidt wrote:
>>>> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
>> ..
>>>>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>>>>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
>>>> *mmio)
>>>>> {
>>>>> u32 tmp;
>>>>> -
>>>>> +#ifndef CONFIG_PPC
>>>>> writel(0, mmio + MV_GPIO_PORT_CTL);
>>>>> +#endif
>>>> You'll have to do better here too... I don't wee why when compiled on
>>>> PPC, this driver should "magically" not clear those bits... At the very
>>>> least, you should test the machine type if you want to do something
>>>> specific to your platform, but first, you'll have to convince Jeff why
>>>> this change has to be done in the first place and if there is a better
>>>> way to handle it.
>>> Correct... it does seem some bugs were found, but #ifdef powerpc is
>>> certainly out of the question. We want the driver to work without
>>> ifdefs on all platforms.
>> Yup. I have a powerpc platform here with PCI-X, and a PCI-X Marvell card
>> to try in it. So I'll pick up these changes and try to integrate them a
>> little more nicely in my internal updated driver, and then pass it on to Jeff.
>
> Hi, ...
>
> I am trying to use a Marvell 88SX5081 based card here in my pegasos machine,
> and i never got it working with the libata driver, even with the patches Zang
> provided (and 2.6.16 though, maybe i should update to a newer version). The
> marvell provided driver worked though at some time.
>
> Would it be possible to have access to your work, in order to not duplicate
> effort or something ?
Do you have any debug output (see top of libata.h)?
Jeff
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 8:58 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alexandre.Bounine, linuxppc-dev list, Yang Xin-Xin-r48390,
linux-kernel, linux-ide, Paul Mackerras, Mark Lord
In-Reply-To: <4476C2A0.3030308@pobox.com>
On Fri, May 26, 2006 at 04:56:00AM -0400, Jeff Garzik wrote:
> Sven Luther wrote:
> >On Thu, May 18, 2006 at 04:50:46PM -0400, Mark Lord wrote:
> >>Jeff Garzik wrote:
> >>>Benjamin Herrenschmidt wrote:
> >>>>On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
> >>..
> >>>>>@@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
> >>>>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
> >>>>*mmio)
> >>>>> {
> >>>>> u32 tmp;
> >>>>>-
> >>>>>+#ifndef CONFIG_PPC
> >>>>> writel(0, mmio + MV_GPIO_PORT_CTL);
> >>>>>+#endif
> >>>>You'll have to do better here too... I don't wee why when compiled on
> >>>>PPC, this driver should "magically" not clear those bits... At the very
> >>>>least, you should test the machine type if you want to do something
> >>>>specific to your platform, but first, you'll have to convince Jeff why
> >>>>this change has to be done in the first place and if there is a better
> >>>>way to handle it.
> >>>Correct... it does seem some bugs were found, but #ifdef powerpc is
> >>>certainly out of the question. We want the driver to work without
> >>>ifdefs on all platforms.
> >>Yup. I have a powerpc platform here with PCI-X, and a PCI-X Marvell card
> >>to try in it. So I'll pick up these changes and try to integrate them a
> >>little more nicely in my internal updated driver, and then pass it on to
> >>Jeff.
> >
> >Hi, ...
> >
> >I am trying to use a Marvell 88SX5081 based card here in my pegasos
> >machine,
> >and i never got it working with the libata driver, even with the patches
> >Zang
> >provided (and 2.6.16 though, maybe i should update to a newer version). The
> >marvell provided driver worked though at some time.
> >
> >Would it be possible to have access to your work, in order to not duplicate
> >effort or something ?
>
> Do you have any debug output (see top of libata.h)?
Ah, not yet, but i can provide such.
Right now, i see the drive (with Zang's patch), but any attempt to access it
get me :
ata1: status=0x50 {DriveReady SeekComplete }
ata1: error=0x01 {AddrMarkNotFound }
sata_mv: PCI ERROR; PCI IRQ cause=0x00000400
sda: Current: sensekey: No Sense
Additional sense: No Additional sense information
The disk is a hitachi 80GB sata one.
I will compile a kernel with debug output and provide more info in a bit.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 8:39 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <446CDE26.8090504@rtr.ca>
On Thu, May 18, 2006 at 04:50:46PM -0400, Mark Lord wrote:
> Jeff Garzik wrote:
> > Benjamin Herrenschmidt wrote:
> >> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
> ..
> >>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
> >>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
> >> *mmio)
> >>> {
> >>> u32 tmp;
> >>> -
> >>> +#ifndef CONFIG_PPC
> >>> writel(0, mmio + MV_GPIO_PORT_CTL);
> >>> +#endif
> >>
> >> You'll have to do better here too... I don't wee why when compiled on
> >> PPC, this driver should "magically" not clear those bits... At the very
> >> least, you should test the machine type if you want to do something
> >> specific to your platform, but first, you'll have to convince Jeff why
> >> this change has to be done in the first place and if there is a better
> >> way to handle it.
> >
> > Correct... it does seem some bugs were found, but #ifdef powerpc is
> > certainly out of the question. We want the driver to work without
> > ifdefs on all platforms.
>
> Yup. I have a powerpc platform here with PCI-X, and a PCI-X Marvell card
> to try in it. So I'll pick up these changes and try to integrate them a
> little more nicely in my internal updated driver, and then pass it on to Jeff.
Hi, ...
I am trying to use a Marvell 88SX5081 based card here in my pegasos machine,
and i never got it working with the libata driver, even with the patches Zang
provided (and 2.6.16 though, maybe i should update to a newer version). The
marvell provided driver worked though at some time.
Would it be possible to have access to your work, in order to not duplicate
effort or something ?
Friendly,
Sven Luther
^ permalink raw reply
* Help Needed: PHY Driver
From: s.maiti @ 2006-05-26 11:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi all,
In our custom board (MPC8260) there is a child card, which is having the
PHY chip DM256, and is being memory mapped with the processor via CS 7 and
they are connected via local bus.
Now my question is what nessary changes I have to make in linux tree for
thi purpose.
Thanks in advance.
Souvik Maiti
Tata Consultancy Services Limited
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 1199 bytes --]
^ 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