* 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
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Paul Mackerras @ 2006-05-26 11:30 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060523130717.GA22364@suse.de>
Olaf Hering writes:
> According to this change for EXCEPTION_PROLOG_COMMON, I get still into
> decremeter_common, but its not fatal anymore because the cpu is now in
> 64bit mode and the stack is forced to PACAKSAVE(r13).
>
> subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
> beq- 1f; \
> ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
> -1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
> +1: \
> + cmpdi cr1,r29,0x42; \
Ummm, what's r29 supposed to have in it here?
> + bne cr1,2f; \
> + li r29,2f@l; \
And why are we setting it?
Does it look like the SRR0 and SRR1 values are correct when we get
this problem occurring? Is it just the MSR that is bogus?
Paul.
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 11:41 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526083931.GA23938@powerlinux.fr>
Sven Luther wrote:
> I'm 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 ?
All of the relevant bits of "my work" are now in Jeff's upstream libata tree,
from the recently posted sata_mv patches.
After struggling with bad SDRAM earlier this week, I now have Ubuntu installed
and running reliably on my G3 box here. Next step is to upgrade the kernel
to something modern, and add in the latest sata_mv.
After that, I'll try my own 6081 Marvell card in it, and hopefully see the
same failures as you.. hopefully!
Cheers
^ 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 11:42 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: <4476E964.90509@rtr.ca>
On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >I'm 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 ?
>
> All of the relevant bits of "my work" are now in Jeff's upstream libata
> tree,
> from the recently posted sata_mv patches.
Ok. can i use this tree with a 2.6.16 base ?
> After struggling with bad SDRAM earlier this week, I now have Ubuntu
> installed
> and running reliably on my G3 box here. Next step is to upgrade the kernel
> to something modern, and add in the latest sata_mv.
Ok.
> After that, I'll try my own 6081 Marvell card in it, and hopefully see the
> same failures as you.. hopefully!
I tried getting a 6081 based low profile card, but they don't seem to sell in
europe.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-26 12:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17526.59069.781220.922878@cargo.ozlabs.ibm.com>
On Fri, May 26, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > According to this change for EXCEPTION_PROLOG_COMMON, I get still into
> > decremeter_common, but its not fatal anymore because the cpu is now in
> > 64bit mode and the stack is forced to PACAKSAVE(r13).
> >
> > subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
> > beq- 1f; \
> > ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
> > -1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
> > +1: \
> > + cmpdi cr1,r29,0x42; \
>
> Ummm, what's r29 supposed to have in it here?
0x42, from the spinning hello32 app. I filled all regs from r14 to r31
with a fixed value, and used these regs for debugging in the reset
handler.
> > + bne cr1,2f; \
> > + li r29,2f@l; \
>
> And why are we setting it?
Just a debug thing to find out how I got into bad_stack. I expected that
system_reset_common calls bad_stack, but it was decrementer_common. No
idea how that happend, MSR_EE is off, the timer interrupt has the lowest
priority, so it should not trigger.
> Does it look like the SRR0 and SRR1 values are correct when we get
> this problem occurring? Is it just the MSR that is bogus?
The MSR indicates 32bit mode, it is 0x1002 on entry and 0x1032 before
rfdi. I havent dumped the SRR1 content, SRR0 points to the hello32 'b .'
instruction.
It seems the JS20 and POWER4 firmware calls fwnmi on all cpus, while
JS21 (and probably POWER5) does it only on one cpu. The other cpus will
be stopped with an IPI, trap 501.
According to some firmware guys, the OS is supposed to force 64bit mode
on reset.
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Paul Mackerras @ 2006-05-26 12:40 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060526123321.GA21866@suse.de>
Olaf Hering writes:
> According to some firmware guys, the OS is supposed to force 64bit mode
> on reset.
Who? I'll get a platform architect to drop on them from a great
height. :)
Paul.
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-26 12:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17526.63315.759402.679928@cargo.ozlabs.ibm.com>
On Fri, May 26, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > According to some firmware guys, the OS is supposed to force 64bit mode
> > on reset.
>
> Who? I'll get a platform architect to drop on them from a great
> height. :)
LTC22581 for the full story.
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 13:19 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526114245.GA32330@powerlinux.fr>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Sven Luther wrote:
> On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
>> All of the relevant bits of "my work" are now in Jeff's upstream libata
>> tree,
>> from the recently posted sata_mv patches.
>
> Ok. can i use this tree with a 2.6.16 base ?
Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
the sata_mv driver to the latest source. Completely untested,
but it does compile.
I will hopefully test it later today, but in the meanwhile, have a go at it.
Cheers
[-- Attachment #2: sata_mv-2.6.16_backport.patch --]
[-- Type: text/x-patch, Size: 22667 bytes --]
--- linux-2.6.16.17/drivers/scsi/sata_mv.c 2006-04-14 23:14:22.000000000 -0400
+++ linux/drivers/scsi/sata_mv.c 2006-05-26 09:15:22.000000000 -0400
@@ -37,7 +37,7 @@
#include <asm/io.h>
#define DRV_NAME "sata_mv"
-#define DRV_VERSION "0.5"
+#define DRV_VERSION "0.7-backport"
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
@@ -50,6 +50,12 @@
MV_PCI_REG_BASE = 0,
MV_IRQ_COAL_REG_BASE = 0x18000, /* 6xxx part only */
+ MV_IRQ_COAL_CAUSE = (MV_IRQ_COAL_REG_BASE + 0x08),
+ MV_IRQ_COAL_CAUSE_LO = (MV_IRQ_COAL_REG_BASE + 0x88),
+ MV_IRQ_COAL_CAUSE_HI = (MV_IRQ_COAL_REG_BASE + 0x8c),
+ MV_IRQ_COAL_THRESHOLD = (MV_IRQ_COAL_REG_BASE + 0xcc),
+ MV_IRQ_COAL_TIME_THRESHOLD = (MV_IRQ_COAL_REG_BASE + 0xd0),
+
MV_SATAHC0_REG_BASE = 0x20000,
MV_FLASH_CTL = 0x1046c,
MV_GPIO_PORT_CTL = 0x104f0,
@@ -228,7 +234,9 @@
MV_HP_ERRATA_50XXB2 = (1 << 2),
MV_HP_ERRATA_60X1B2 = (1 << 3),
MV_HP_ERRATA_60X1C0 = (1 << 4),
- MV_HP_50XX = (1 << 5),
+ MV_HP_ERRATA_XX42A0 = (1 << 5),
+ MV_HP_50XX = (1 << 6),
+ MV_HP_GEN_IIE = (1 << 7),
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0),
@@ -237,6 +245,9 @@
#define IS_50XX(hpriv) ((hpriv)->hp_flags & MV_HP_50XX)
#define IS_60XX(hpriv) (((hpriv)->hp_flags & MV_HP_50XX) == 0)
+#define IS_GEN_I(hpriv) IS_50XX(hpriv)
+#define IS_GEN_II(hpriv) IS_60XX(hpriv)
+#define IS_GEN_IIE(hpriv) ((hpriv)->hp_flags & MV_HP_GEN_IIE)
enum {
/* Our DMA boundary is determined by an ePRD being unable to handle
@@ -255,29 +266,39 @@
chip_5080,
chip_604x,
chip_608x,
+ chip_6042,
+ chip_7042,
};
/* Command ReQuest Block: 32B */
struct mv_crqb {
- u32 sg_addr;
- u32 sg_addr_hi;
- u16 ctrl_flags;
- u16 ata_cmd[11];
+ __le32 sg_addr;
+ __le32 sg_addr_hi;
+ __le16 ctrl_flags;
+ __le16 ata_cmd[11];
+};
+
+struct mv_crqb_iie {
+ __le32 addr;
+ __le32 addr_hi;
+ __le32 flags;
+ __le32 len;
+ __le32 ata_cmd[4];
};
/* Command ResPonse Block: 8B */
struct mv_crpb {
- u16 id;
- u16 flags;
- u32 tmstmp;
+ __le16 id;
+ __le16 flags;
+ __le32 tmstmp;
};
/* EDMA Physical Region Descriptor (ePRD); A.K.A. SG */
struct mv_sg {
- u32 addr;
- u32 flags_size;
- u32 addr_hi;
- u32 reserved;
+ __le32 addr;
+ __le32 flags_size;
+ __le32 addr_hi;
+ __le32 reserved;
};
struct mv_port_priv {
@@ -287,9 +308,6 @@
dma_addr_t crpb_dma;
struct mv_sg *sg_tbl;
dma_addr_t sg_tbl_dma;
-
- unsigned req_producer; /* cp of req_in_ptr */
- unsigned rsp_consumer; /* cp of rsp_out_ptr */
u32 pp_flags;
};
@@ -328,6 +346,7 @@
static int mv_port_start(struct ata_port *ap);
static void mv_port_stop(struct ata_port *ap);
static void mv_qc_prep(struct ata_queued_cmd *qc);
+static void mv_qc_prep_iie(struct ata_queued_cmd *qc);
static int mv_qc_issue(struct ata_queued_cmd *qc);
static irqreturn_t mv_interrupt(int irq, void *dev_instance,
struct pt_regs *regs);
@@ -430,6 +449,33 @@
.host_stop = mv_host_stop,
};
+static const struct ata_port_operations mv_iie_ops = {
+ .port_disable = ata_port_disable,
+
+ .tf_load = ata_tf_load,
+ .tf_read = ata_tf_read,
+ .check_status = ata_check_status,
+ .exec_command = ata_exec_command,
+ .dev_select = ata_std_dev_select,
+
+ .phy_reset = mv_phy_reset,
+
+ .qc_prep = mv_qc_prep_iie,
+ .qc_issue = mv_qc_issue,
+
+ .eng_timeout = mv_eng_timeout,
+
+ .irq_handler = mv_interrupt,
+ .irq_clear = mv_irq_clear,
+
+ .scr_read = mv_scr_read,
+ .scr_write = mv_scr_write,
+
+ .port_start = mv_port_start,
+ .port_stop = mv_port_stop,
+ .host_stop = mv_host_stop,
+};
+
static const struct ata_port_info mv_port_info[] = {
{ /* chip_504x */
.sht = &mv_sht,
@@ -467,6 +513,21 @@
.udma_mask = 0x7f, /* udma0-6 */
.port_ops = &mv6_ops,
},
+ { /* chip_6042 */
+ .sht = &mv_sht,
+ .host_flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS),
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = 0x7f, /* udma0-6 */
+ .port_ops = &mv_iie_ops,
+ },
+ { /* chip_7042 */
+ .sht = &mv_sht,
+ .host_flags = (MV_COMMON_FLAGS | MV_6XXX_FLAGS |
+ MV_FLAG_DUAL_HC),
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = 0x7f, /* udma0-6 */
+ .port_ops = &mv_iie_ops,
+ },
};
static const struct pci_device_id mv_pci_tbl[] = {
@@ -477,6 +538,7 @@
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6040), 0, 0, chip_604x},
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6041), 0, 0, chip_604x},
+ {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6042), 0, 0, chip_6042},
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6080), 0, 0, chip_608x},
{PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6081), 0, 0, chip_608x},
@@ -572,8 +634,8 @@
* @base: port base address
* @pp: port private data
*
- * Verify the local cache of the eDMA state is accurate with an
- * assert.
+ * Verify the local cache of the eDMA state is accurate with a
+ * WARN_ON.
*
* LOCKING:
* Inherited from caller.
@@ -584,15 +646,15 @@
writelfl(EDMA_EN, base + EDMA_CMD_OFS);
pp->pp_flags |= MV_PP_FLAG_EDMA_EN;
}
- assert(EDMA_EN & readl(base + EDMA_CMD_OFS));
+ WARN_ON(!(EDMA_EN & readl(base + EDMA_CMD_OFS)));
}
/**
* mv_stop_dma - Disable eDMA engine
* @ap: ATA channel to manipulate
*
- * Verify the local cache of the eDMA state is accurate with an
- * assert.
+ * Verify the local cache of the eDMA state is accurate with a
+ * WARN_ON.
*
* LOCKING:
* Inherited from caller.
@@ -610,7 +672,7 @@
writelfl(EDMA_DS, port_mmio + EDMA_CMD_OFS);
pp->pp_flags &= ~MV_PP_FLAG_EDMA_EN;
} else {
- assert(!(EDMA_EN & readl(port_mmio + EDMA_CMD_OFS)));
+ WARN_ON(EDMA_EN & readl(port_mmio + EDMA_CMD_OFS));
}
/* now properly wait for the eDMA to stop */
@@ -690,7 +752,7 @@
mv_dump_mem(mmio_base+0xf00, 0x4);
mv_dump_mem(mmio_base+0x1d00, 0x6c);
for (hc = start_hc; hc < start_hc + num_hcs; hc++) {
- hc_base = mv_hc_base(mmio_base, port >> MV_PORT_HC_SHIFT);
+ hc_base = mv_hc_base(mmio_base, hc);
DPRINTK("HC regs (HC %i):\n", hc);
mv_dump_mem(hc_base, 0x1c);
}
@@ -773,6 +835,33 @@
dma_free_coherent(dev, MV_PORT_PRIV_DMA_SZ, pp->crpb, pp->crpb_dma);
}
+static void mv_edma_cfg(struct mv_host_priv *hpriv, void __iomem *port_mmio)
+{
+ u32 cfg = readl(port_mmio + EDMA_CFG_OFS);
+
+ /* set up non-NCQ EDMA configuration */
+ cfg &= ~0x1f; /* clear queue depth */
+ cfg &= ~EDMA_CFG_NCQ; /* clear NCQ mode */
+ cfg &= ~(1 << 9); /* disable equeue */
+
+ if (IS_GEN_I(hpriv))
+ cfg |= (1 << 8); /* enab config burst size mask */
+
+ else if (IS_GEN_II(hpriv))
+ cfg |= EDMA_CFG_RD_BRST_EXT | EDMA_CFG_WR_BUFF_LEN;
+
+ else if (IS_GEN_IIE(hpriv)) {
+ cfg |= (1 << 23); /* dis RX PM port mask */
+ cfg &= ~(1 << 16); /* dis FIS-based switching (for now) */
+ cfg &= ~(1 << 19); /* dis 128-entry queue (for now?) */
+ cfg |= (1 << 18); /* enab early completion */
+ cfg |= (1 << 17); /* enab host q cache */
+ cfg |= (1 << 22); /* enab cutthrough */
+ }
+
+ writelfl(cfg, port_mmio + EDMA_CFG_OFS);
+}
+
/**
* mv_port_start - Port specific init/start routine.
* @ap: ATA channel to manipulate
@@ -786,6 +875,7 @@
static int mv_port_start(struct ata_port *ap)
{
struct device *dev = ap->host_set->dev;
+ struct mv_host_priv *hpriv = ap->host_set->private_data;
struct mv_port_priv *pp;
void __iomem *port_mmio = mv_ap_base(ap);
void *mem;
@@ -829,22 +919,29 @@
pp->sg_tbl = mem;
pp->sg_tbl_dma = mem_dma;
- writelfl(EDMA_CFG_Q_DEPTH | EDMA_CFG_RD_BRST_EXT |
- EDMA_CFG_WR_BUFF_LEN, port_mmio + EDMA_CFG_OFS);
+ mv_edma_cfg(hpriv, port_mmio);
writel((pp->crqb_dma >> 16) >> 16, port_mmio + EDMA_REQ_Q_BASE_HI_OFS);
writelfl(pp->crqb_dma & EDMA_REQ_Q_BASE_LO_MASK,
port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
- writelfl(0, port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
- writelfl(0, port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+ if (hpriv->hp_flags & MV_HP_ERRATA_XX42A0)
+ writelfl(pp->crqb_dma & 0xffffffff,
+ port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
+ else
+ writelfl(0, port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
writel((pp->crpb_dma >> 16) >> 16, port_mmio + EDMA_RSP_Q_BASE_HI_OFS);
+
+ if (hpriv->hp_flags & MV_HP_ERRATA_XX42A0)
+ writelfl(pp->crpb_dma & 0xffffffff,
+ port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+ else
+ writelfl(0, port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+
writelfl(pp->crpb_dma & EDMA_RSP_Q_BASE_LO_MASK,
port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
- pp->req_producer = pp->rsp_consumer = 0;
-
/* Don't turn on EDMA here...do it before DMA commands only. Else
* we'll be unable to send non-data, PIO, etc due to restricted access
* to shadow regs.
@@ -915,7 +1012,7 @@
pp->sg_tbl[i].addr = cpu_to_le32(addr & 0xffffffff);
pp->sg_tbl[i].addr_hi = cpu_to_le32((addr >> 16) >> 16);
- pp->sg_tbl[i].flags_size = cpu_to_le32(len);
+ pp->sg_tbl[i].flags_size = cpu_to_le32(len & 0xffff);
sg_len -= len;
addr += len;
@@ -928,16 +1025,16 @@
}
}
-static inline unsigned mv_inc_q_index(unsigned *index)
+static inline unsigned mv_inc_q_index(unsigned index)
{
- *index = (*index + 1) & MV_MAX_Q_DEPTH_MASK;
- return *index;
+ return (index + 1) & MV_MAX_Q_DEPTH_MASK;
}
-static inline void mv_crqb_pack_cmd(u16 *cmdw, u8 data, u8 addr, unsigned last)
+static inline void mv_crqb_pack_cmd(__le16 *cmdw, u8 data, u8 addr, unsigned last)
{
- *cmdw = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
+ u16 tmp = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
(last ? CRQB_CMD_LAST : 0);
+ *cmdw = cpu_to_le16(tmp);
}
/**
@@ -956,34 +1053,32 @@
{
struct ata_port *ap = qc->ap;
struct mv_port_priv *pp = ap->private_data;
- u16 *cw;
+ __le16 *cw;
struct ata_taskfile *tf;
u16 flags = 0;
+ unsigned in_index;
- if (ATA_PROT_DMA != qc->tf.protocol) {
+ if (ATA_PROT_DMA != qc->tf.protocol)
return;
- }
-
- /* the req producer index should be the same as we remember it */
- assert(((readl(mv_ap_base(qc->ap) + EDMA_REQ_Q_IN_PTR_OFS) >>
- EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->req_producer);
/* Fill in command request block
*/
- if (!(qc->tf.flags & ATA_TFLAG_WRITE)) {
+ if (!(qc->tf.flags & ATA_TFLAG_WRITE))
flags |= CRQB_FLAG_READ;
- }
- assert(MV_MAX_Q_DEPTH > qc->tag);
+ WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
flags |= qc->tag << CRQB_TAG_SHIFT;
- pp->crqb[pp->req_producer].sg_addr =
+ /* get current queue index from hardware */
+ in_index = (readl(mv_ap_base(ap) + EDMA_REQ_Q_IN_PTR_OFS)
+ >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
+
+ pp->crqb[in_index].sg_addr =
cpu_to_le32(pp->sg_tbl_dma & 0xffffffff);
- pp->crqb[pp->req_producer].sg_addr_hi =
+ pp->crqb[in_index].sg_addr_hi =
cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
- pp->crqb[pp->req_producer].ctrl_flags = cpu_to_le16(flags);
+ pp->crqb[in_index].ctrl_flags = cpu_to_le16(flags);
- cw = &pp->crqb[pp->req_producer].ata_cmd[0];
+ cw = &pp->crqb[in_index].ata_cmd[0];
tf = &qc->tf;
/* Sadly, the CRQB cannot accomodate all registers--there are
@@ -1029,9 +1124,76 @@
mv_crqb_pack_cmd(cw++, tf->device, ATA_REG_DEVICE, 0);
mv_crqb_pack_cmd(cw++, tf->command, ATA_REG_CMD, 1); /* last */
- if (!(qc->flags & ATA_QCFLAG_DMAMAP)) {
+ if (!(qc->flags & ATA_QCFLAG_DMAMAP))
+ return;
+ mv_fill_sg(qc);
+}
+
+/**
+ * mv_qc_prep_iie - Host specific command preparation.
+ * @qc: queued command to prepare
+ *
+ * This routine simply redirects to the general purpose routine
+ * if command is not DMA. Else, it handles prep of the CRQB
+ * (command request block), does some sanity checking, and calls
+ * the SG load routine.
+ *
+ * LOCKING:
+ * Inherited from caller.
+ */
+static void mv_qc_prep_iie(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mv_port_priv *pp = ap->private_data;
+ struct mv_crqb_iie *crqb;
+ struct ata_taskfile *tf;
+ unsigned in_index;
+ u32 flags = 0;
+
+ if (ATA_PROT_DMA != qc->tf.protocol)
+ return;
+
+ /* Fill in Gen IIE command request block
+ */
+ if (!(qc->tf.flags & ATA_TFLAG_WRITE))
+ flags |= CRQB_FLAG_READ;
+
+ WARN_ON(MV_MAX_Q_DEPTH <= qc->tag);
+ flags |= qc->tag << CRQB_TAG_SHIFT;
+
+ /* get current queue index from hardware */
+ in_index = (readl(mv_ap_base(ap) + EDMA_REQ_Q_IN_PTR_OFS)
+ >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
+
+ crqb = (struct mv_crqb_iie *) &pp->crqb[in_index];
+ crqb->addr = cpu_to_le32(pp->sg_tbl_dma & 0xffffffff);
+ crqb->addr_hi = cpu_to_le32((pp->sg_tbl_dma >> 16) >> 16);
+ crqb->flags = cpu_to_le32(flags);
+
+ tf = &qc->tf;
+ crqb->ata_cmd[0] = cpu_to_le32(
+ (tf->command << 16) |
+ (tf->feature << 24)
+ );
+ crqb->ata_cmd[1] = cpu_to_le32(
+ (tf->lbal << 0) |
+ (tf->lbam << 8) |
+ (tf->lbah << 16) |
+ (tf->device << 24)
+ );
+ crqb->ata_cmd[2] = cpu_to_le32(
+ (tf->hob_lbal << 0) |
+ (tf->hob_lbam << 8) |
+ (tf->hob_lbah << 16) |
+ (tf->hob_feature << 24)
+ );
+ crqb->ata_cmd[3] = cpu_to_le32(
+ (tf->nsect << 0) |
+ (tf->hob_nsect << 8)
+ );
+
+ if (!(qc->flags & ATA_QCFLAG_DMAMAP))
return;
- }
mv_fill_sg(qc);
}
@@ -1051,6 +1213,7 @@
{
void __iomem *port_mmio = mv_ap_base(qc->ap);
struct mv_port_priv *pp = qc->ap->private_data;
+ unsigned in_index;
u32 in_ptr;
if (ATA_PROT_DMA != qc->tf.protocol) {
@@ -1062,23 +1225,20 @@
return ata_qc_issue_prot(qc);
}
- in_ptr = readl(port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
+ in_ptr = readl(port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
+ in_index = (in_ptr >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
- /* the req producer index should be the same as we remember it */
- assert(((in_ptr >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->req_producer);
/* until we do queuing, the queue should be empty at this point */
- assert(((in_ptr >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS) >>
- EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
+ WARN_ON(in_index != ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS)
+ >> EDMA_REQ_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
- mv_inc_q_index(&pp->req_producer); /* now incr producer index */
+ in_index = mv_inc_q_index(in_index); /* now incr producer index */
mv_start_dma(port_mmio, pp);
/* and write the request in pointer to kick the EDMA to life */
in_ptr &= EDMA_REQ_Q_BASE_LO_MASK;
- in_ptr |= pp->req_producer << EDMA_REQ_Q_PTR_SHIFT;
+ in_ptr |= in_index << EDMA_REQ_Q_PTR_SHIFT;
writelfl(in_ptr, port_mmio + EDMA_REQ_Q_IN_PTR_OFS);
return 0;
@@ -1090,7 +1250,7 @@
*
* This routine is for use when the port is in DMA mode, when it
* will be using the CRPB (command response block) method of
- * returning command completion information. We assert indices
+ * returning command completion information. We check indices
* are good, grab status, and bump the response consumer index to
* prove that we're up to date.
*
@@ -1101,28 +1261,26 @@
{
void __iomem *port_mmio = mv_ap_base(ap);
struct mv_port_priv *pp = ap->private_data;
+ unsigned out_index;
u32 out_ptr;
u8 ata_status;
- out_ptr = readl(port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
+ out_ptr = readl(port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
+ out_index = (out_ptr >> EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK;
- /* the response consumer index should be the same as we remember it */
- assert(((out_ptr >> EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->rsp_consumer);
-
- ata_status = pp->crpb[pp->rsp_consumer].flags >> CRPB_FLAG_STATUS_SHIFT;
+ ata_status = le16_to_cpu(pp->crpb[out_index].flags)
+ >> CRPB_FLAG_STATUS_SHIFT;
/* increment our consumer index... */
- pp->rsp_consumer = mv_inc_q_index(&pp->rsp_consumer);
+ out_index = mv_inc_q_index(out_index);
/* and, until we do NCQ, there should only be 1 CRPB waiting */
- assert(((readl(port_mmio + EDMA_RSP_Q_IN_PTR_OFS) >>
- EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK) ==
- pp->rsp_consumer);
+ WARN_ON(out_index != ((readl(port_mmio + EDMA_RSP_Q_IN_PTR_OFS)
+ >> EDMA_RSP_Q_PTR_SHIFT) & MV_MAX_Q_DEPTH_MASK));
/* write out our inc'd consumer index so EDMA knows we're caught up */
out_ptr &= EDMA_RSP_Q_BASE_LO_MASK;
- out_ptr |= pp->rsp_consumer << EDMA_RSP_Q_PTR_SHIFT;
+ out_ptr |= out_index << EDMA_RSP_Q_PTR_SHIFT;
writelfl(out_ptr, port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
/* Return ATA status register for completed CRPB */
@@ -1132,6 +1290,7 @@
/**
* mv_err_intr - Handle error interrupts on the port
* @ap: ATA channel to manipulate
+ * @reset_allowed: bool: 0 == don't trigger from reset here
*
* In most cases, just clear the interrupt and move on. However,
* some cases require an eDMA reset, which is done right before
@@ -1142,7 +1301,7 @@
* LOCKING:
* Inherited from caller.
*/
-static void mv_err_intr(struct ata_port *ap)
+static void mv_err_intr(struct ata_port *ap, int reset_allowed)
{
void __iomem *port_mmio = mv_ap_base(ap);
u32 edma_err_cause, serr = 0;
@@ -1164,9 +1323,8 @@
writelfl(0, port_mmio + EDMA_ERR_IRQ_CAUSE_OFS);
/* check for fatal here and recover if needed */
- if (EDMA_ERR_FATAL & edma_err_cause) {
+ if (reset_allowed && (EDMA_ERR_FATAL & edma_err_cause))
mv_stop_and_reset(ap);
- }
}
/**
@@ -1190,7 +1348,6 @@
{
void __iomem *mmio = host_set->mmio_base;
void __iomem *hc_mmio = mv_hc_base(mmio, hc);
- struct ata_port *ap;
struct ata_queued_cmd *qc;
u32 hc_irq_cause;
int shift, port, port0, hard_port, handled;
@@ -1213,21 +1370,34 @@
for (port = port0; port < port0 + MV_PORTS_PER_HC; port++) {
u8 ata_status = 0;
- ap = host_set->ports[port];
- hard_port = port & MV_PORT_MASK; /* range 0-3 */
+ struct ata_port *ap = host_set->ports[port];
+ struct mv_port_priv *pp = ap->private_data;
+
+ hard_port = mv_hardport_from_port(port); /* range 0..3 */
handled = 0; /* ensure ata_status is set if handled++ */
- if ((CRPB_DMA_DONE << hard_port) & hc_irq_cause) {
- /* new CRPB on the queue; just one at a time until NCQ
- */
- ata_status = mv_get_crpb_status(ap);
- handled++;
- } else if ((DEV_IRQ << hard_port) & hc_irq_cause) {
- /* received ATA IRQ; read the status reg to clear INTRQ
- */
- ata_status = readb((void __iomem *)
+ /* Note that DEV_IRQ might happen spuriously during EDMA,
+ * and should be ignored in such cases.
+ * The cause of this is still under investigation.
+ */
+ if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
+ /* EDMA: check for response queue interrupt */
+ if ((CRPB_DMA_DONE << hard_port) & hc_irq_cause) {
+ ata_status = mv_get_crpb_status(ap);
+ handled = 1;
+ }
+ } else {
+ /* PIO: check for device (drive) interrupt */
+ if ((DEV_IRQ << hard_port) & hc_irq_cause) {
+ ata_status = readb((void __iomem *)
ap->ioaddr.status_addr);
- handled++;
+ handled = 1;
+ /* ignore spurious intr if drive still BUSY */
+ if (ata_status & ATA_BUSY) {
+ ata_status = 0;
+ handled = 0;
+ }
+ }
}
if (ap &&
@@ -1241,14 +1411,14 @@
shift++; /* skip bit 8 in the HC Main IRQ reg */
}
if ((PORT0_ERR << shift) & relevant) {
- mv_err_intr(ap);
+ mv_err_intr(ap, 1);
err_mask |= AC_ERR_OTHER;
- handled++;
+ handled = 1;
}
- if (handled && ap) {
+ if (handled) {
qc = ata_qc_from_tag(ap, ap->active_tag);
- if (NULL != qc) {
+ if (qc && (qc->flags & ATA_QCFLAG_ACTIVE)) {
VPRINTK("port %u IRQ found for qc, "
"ata_status 0x%x\n", port,ata_status);
/* mark qc status appropriately */
@@ -1283,6 +1453,7 @@
struct ata_host_set *host_set = dev_instance;
unsigned int hc, handled = 0, n_hcs;
void __iomem *mmio = host_set->mmio_base;
+ struct mv_host_priv *hpriv;
u32 irq_stat;
irq_stat = readl(mmio + HC_MAIN_IRQ_CAUSE_OFS);
@@ -1304,6 +1475,17 @@
handled++;
}
}
+
+ hpriv = host_set->private_data;
+ if (IS_60XX(hpriv)) {
+ /* deal with the interrupt coalescing bits */
+ if (irq_stat & (TRAN_LO_DONE | TRAN_HI_DONE | PORTS_0_7_COAL_DONE)) {
+ writelfl(0, mmio + MV_IRQ_COAL_CAUSE_LO);
+ writelfl(0, mmio + MV_IRQ_COAL_CAUSE_HI);
+ writelfl(0, mmio + MV_IRQ_COAL_CAUSE);
+ }
+ }
+
if (PCI_ERR & irq_stat) {
printk(KERN_ERR DRV_NAME ": PCI ERROR; PCI IRQ cause=0x%08x\n",
readl(mmio + PCI_IRQ_CAUSE_OFS));
@@ -1684,6 +1866,12 @@
m2 |= hpriv->signal[port].pre;
m2 &= ~(1 << 16);
+ /* according to mvSata 3.6.1, some IIE values are fixed */
+ if (IS_GEN_IIE(hpriv)) {
+ m2 &= ~0xC30FF01F;
+ m2 |= 0x0000900F;
+ }
+
writel(m2, port_mmio + PHY_MODE2);
}
@@ -1696,7 +1884,8 @@
if (IS_60XX(hpriv)) {
u32 ifctl = readl(port_mmio + SATA_INTERFACE_CTL);
- ifctl |= (1 << 12) | (1 << 7);
+ ifctl |= (1 << 7); /* enable gen2i speed */
+ ifctl = (ifctl & 0xfff) | 0x9b1000; /* from chip spec */
writelfl(ifctl, port_mmio + SATA_INTERFACE_CTL);
}
@@ -1792,7 +1981,7 @@
ata_port_probe(ap);
} else {
printk(KERN_INFO "ata%u: no device found (phy stat %08x)\n",
- ap->id, scr_read(ap, SCR_STATUS));
+ ap->id, scr_read(ap, SCR_STATUS));
ata_port_disable(ap);
return;
}
@@ -1861,13 +2050,11 @@
ap->host_set->mmio_base, ap, qc, qc->scsicmd,
&qc->scsicmd->cmnd);
- mv_err_intr(ap);
+ mv_err_intr(ap, 0);
mv_stop_and_reset(ap);
- if (!qc) {
- printk(KERN_ERR "ata%u: BUG: timeout without command\n",
- ap->id);
- } else {
+ WARN_ON(!(qc->flags & ATA_QCFLAG_ACTIVE));
+ if (qc->flags & ATA_QCFLAG_ACTIVE) {
/* hack alert! We cannot use the supplied completion
* function from inside the ->eh_strategy_handler() thread.
* libata is the only user of ->eh_strategy_handler() in
@@ -1998,6 +2185,27 @@
}
break;
+ case chip_7042:
+ case chip_6042:
+ hpriv->ops = &mv6xxx_ops;
+
+ hp_flags |= MV_HP_GEN_IIE;
+
+ switch (rev_id) {
+ case 0x0:
+ hp_flags |= MV_HP_ERRATA_XX42A0;
+ break;
+ case 0x1:
+ hp_flags |= MV_HP_ERRATA_60X1C0;
+ break;
+ default:
+ dev_printk(KERN_WARNING, &pdev->dev,
+ "Applying 60X1C0 workarounds to unknown rev\n");
+ hp_flags |= MV_HP_ERRATA_60X1C0;
+ break;
+ }
+ break;
+
default:
printk(KERN_ERR DRV_NAME ": BUG: invalid board index %u\n", board_idx);
return 1;
@@ -2052,7 +2260,8 @@
void __iomem *port_mmio = mv_port_base(mmio, port);
u32 ifctl = readl(port_mmio + SATA_INTERFACE_CTL);
- ifctl |= (1 << 12);
+ ifctl |= (1 << 7); /* enable gen2i speed */
+ ifctl = (ifctl & 0xfff) | 0x9b1000; /* from chip spec */
writelfl(ifctl, port_mmio + SATA_INTERFACE_CTL);
}
@@ -2153,6 +2362,7 @@
if (rc) {
return rc;
}
+ pci_set_master(pdev);
rc = pci_request_regions(pdev, DRV_NAME);
if (rc) {
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-26 14:00 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded
In-Reply-To: <200605260949.48627.roger.larsson@norran.net>
Hi Roger,
The kernel is not linked with uClibc/glibc its user
application only which is linked with uClibc/glibc....
What i am able to conclude is that the library
internall might be using floating point operations and
might be genrating some floating point instructions
which are not handled by our board....and that might
be the reason....or this error might be mapped in a
generic way such that it is getting flashed in some
particular scenarios.....
I might be wrong but as of now i don't have any other
explaination as now after linking with glibs the
application is working fine.....
Regards,
Malik
--- Roger Larsson <roger.larsson@norran.net> wrote:
> On fredag 26 maj 2006 09.38, you wrote:
> > Hi Roger,
> >
> > The problem has been resolved...the issue was in
> the make
> > file.....actually we were cpmiling the code with
> gclibc and linking it with
> > 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....
> > Regards,
> > Malik
>
> Now I am confused!
>
> How could this cause
> "floating point used in kernel (task=c0398410,
> pc=3184)"
>
> 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
>
Send instant messages to your online friends http://in.messenger.yahoo.com
^ permalink raw reply
* [RFC/PATCH] powersave_nap cleanup
From: Nathan Lynch @ 2006-05-26 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
[ Please consider for 2.6.18. ]
Instead of having the machdep_calls.power_save routines (such as
ppc6xx_idle and power4_idle) individually check the value of the
powersave_nap sysctl variable, we can have the newly-consolidated idle
loop check the value of powersave_nap when deciding whether to call
machdep_calls.power_save. In this way, a platform can implement a
machdep_calls.power_save method but still have threads go low-priority
when idle if the user has set powersave_nap to 0.
Rename machdep_calls.power_save to machdep_calls.powersave_nap to make
more apparent the connection with the powersave_nap sysctl.
Add some documentation to machdep_calls.powersave_nap to more
completely describe its intended use.
Change cpu_idle to call ppc_md.powersave_nap only when the
powersave_nap sysctl is set.
Remove tests of the powersave_nap variable from the ppc6xx_idle and
power4_idle routines.
Set powersave_nap to 1 by default on pSeries when the shared processor
firmware feature is present, preserving current behavior.
Remove a superfluous declaration of powersave_nap from
platforms/powermac/feature.c.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index d491052..09bd0cf 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -53,7 +53,7 @@ void cpu_idle(void)
while (!need_resched() && !cpu_should_die()) {
ppc64_runlatch_off();
- if (ppc_md.power_save) {
+ if (ppc_md.powersave_nap && powersave_nap) {
clear_thread_flag(TIF_POLLING_NRFLAG);
/*
* smp_mb is so clearing of TIF_POLLING_NRFLAG
@@ -64,7 +64,7 @@ void cpu_idle(void)
/* check again after disabling irqs */
if (!need_resched() && !cpu_should_die())
- ppc_md.power_save();
+ ppc_md.powersave_nap();
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index b45fa0e..c685a8d 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -1,5 +1,5 @@
/*
- * This file contains the power_save function for 6xx & 7xxx CPUs
+ * This file contains the powersave_nap function for 6xx & 7xxx CPUs
* rewritten in assembler
*
* Warning ! This code assumes that if your machine has a 750fx
@@ -74,11 +74,6 @@ BEGIN_FTR_SECTION
lwz r4,CPU_SPEC_FEATURES(r4)
andi. r0,r4,CPU_FTR_CAN_NAP
beq 1f
- /* Now check if user or arch enabled NAP mode */
- lis r4,powersave_nap@ha
- lwz r4,powersave_nap@l(r4)
- cmpwi 0,r4,0
- beq 1f
lis r3,HID0_NAP@h
1:
END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
diff --git a/arch/powerpc/kernel/idle_power4.S b/arch/powerpc/kernel/idle_power4.S
index d85c7c9..14e3c18 100644
--- a/arch/powerpc/kernel/idle_power4.S
+++ b/arch/powerpc/kernel/idle_power4.S
@@ -1,5 +1,5 @@
/*
- * This file contains the power_save function for 970-family CPUs.
+ * This file contains the powersave_nap function for 970-family CPUs.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -24,12 +24,6 @@ _GLOBAL(power4_idle)
BEGIN_FTR_SECTION
blr
END_FTR_SECTION_IFCLR(CPU_FTR_CAN_NAP)
- /* Now check if user or arch enabled NAP mode */
- LOAD_REG_ADDRBASE(r3,powersave_nap)
- lwz r4,ADDROFF(powersave_nap)(r3)
- cmpwi 0,r4,0
- beqlr
-
/* Go to NAP now */
BEGIN_FTR_SECTION
DSSALL
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..57af9c4 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -142,7 +142,7 @@ void __init machine_init(unsigned long d
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
cpu_has_feature(CPU_FTR_CAN_NAP))
- ppc_md.power_save = ppc6xx_idle;
+ ppc_md.powersave_nap = ppc6xx_idle;
#endif
if (ppc_md.progress)
diff --git a/arch/powerpc/platforms/maple/setup.c b/arch/powerpc/platforms/maple/setup.c
index 24c0aef..eaa4c65 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -292,7 +292,7 @@ define_machine(maple_md) {
.get_rtc_time = maple_get_rtc_time,
.calibrate_decr = generic_calibrate_decr,
.progress = maple_progress,
- .power_save = power4_idle,
+ .powersave_nap = power4_idle,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
.machine_kexec_prepare = default_machine_kexec_prepare,
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index a5063cd..b9a45df 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -53,7 +53,6 @@
extern int powersave_lowspeed;
#endif
-extern int powersave_nap;
extern struct device_node *k2_skiplist[2];
/*
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 4d15e39..66e6a21 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -740,7 +740,7 @@ define_machine(powermac) {
.progress = udbg_progress,
#ifdef CONFIG_PPC64
.pci_probe_mode = pmac_pci_probe_mode,
- .power_save = power4_idle,
+ .powersave_nap = power4_idle,
.enable_pmcs = power4_enable_pmcs,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5f79f01..d094e9d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -236,11 +236,13 @@ static void __init pSeries_setup_arch(vo
vpa_init(boot_cpuid);
if (get_lppaca()->shared_proc) {
printk(KERN_INFO "Using shared processor idle loop\n");
- ppc_md.power_save = pseries_shared_idle_sleep;
+ ppc_md.powersave_nap = pseries_shared_idle_sleep;
} else {
printk(KERN_INFO "Using dedicated idle loop\n");
- ppc_md.power_save = pseries_dedicated_idle_sleep;
+ ppc_md.powersave_nap = pseries_dedicated_idle_sleep;
}
+ /* We want this on by default. */
+ powersave_nap = 1;
} else {
printk(KERN_INFO "Using default idle loop\n");
}
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 0f9254c..721fbe2 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -160,10 +160,11 @@ struct machdep_calls {
void (*idle_loop)(void);
/*
- * Function for waiting for work with reduced power in idle loop;
- * called with interrupts disabled.
+ * Function for waiting for work with reduced power and/or cpu
+ * utilization in idle loop; called with interrupts disabled.
+ * Can be overriden by the powersave_nap sysctl.
*/
- void (*power_save)(void);
+ void (*powersave_nap)(void);
/* Function to enable performance monitor counters for this
platform, called once per cpu. */
^ permalink raw reply related
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 14:15 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: <44770065.8070907@rtr.ca>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
> >>All of the relevant bits of "my work" are now in Jeff's upstream libata
> >>tree,
> >>from the recently posted sata_mv patches.
> >
> >Ok. can i use this tree with a 2.6.16 base ?
>
> Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
> the sata_mv driver to the latest source. Completely untested,
> but it does compile.
>
> I will hopefully test it later today, but in the meanwhile, have a go at it.
And here is attached my dmesg output. The last bit of mv_host_intr was when i
tried to access the partition table of the disk with parted.
Friendly,
Sven Luther
[-- Attachment #2: dmesg-2.6.16-mv_sata.gz --]
[-- Type: application/octet-stream, Size: 4002 bytes --]
^ permalink raw reply
* 2.6 (eldk) - I2C constants
From: Naru Sundar @ 2006-05-26 14:33 UTC (permalink / raw)
To: linuxppc-embedded
Hello folks, I'm porting a 2.4 driver over to 2.6 and noted some
weirdness in the I2C headers. I thought it was worth checking out here.
include/linux/i2c.h in 2.4 defined the following constants:
#define I2C_M_TEN 0x10 /* we have a ten bit chip address */
#define I2C_M_RD 0x01
#define I2C_M_WR 0x00 /* For readable code! */
#define I2C_M_NOSTART 0x4000
#define I2C_M_REV_DIR_ADDR 0x2000
in ELDK 2.6 source drop I have (2.6.15), the I2C_M_WR constant was removed.
Any thoughts? I can declare that constant locally in the driver, but
since these were standard I2C message constants I thought something
odd was up (or am I missing something obvious).
Thanks
--
Naru Sundar <nsundar@fulcrummicro.com>
Fulcrum Microsystems
http://www.fulcrummicro.com
^ 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