* Re: [PATCH] PowerPC: usb ehci of_platform bindings for Sequoia 440EPx
From: Kumar Gala @ 2007-09-14 15:35 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EA9B44.6030606@ru.mvista.com>
On Sep 14, 2007, at 9:31 AM, Valentine Barshak wrote:
> Segher Boessenkool wrote:
>>> EHCI OF bindings for PowerPC 440EPx Sequoia.
>>
>> Those aren't bindings, they are examples. Bindings are pieces
>> of documentation that describe what device-specific properties
>> mean what, what standard properties are required with what
>> values, etc.
>>
>> Examples are good to have, of course.
>>
>> One thing you really need to document is what "ehci-be-desc"
>> and friends mean. I can give you one comment already: for
>> devices that are usually little-endian, but an implementation
>> implements registers as big-endian, precedent is to show that
>> in the device tree by including an (empty) "big-endian" property,
>> rather than inventing new "compatible" values.
>
> I was looking at the ohci-ppc-of driver that has "ohci-bigendian"
> compatible string and enables both be-mmio and be-desc for the
> device in
> this case. I just wanted to separate mmio and desc stuff for ehci,
> since
> some devices need be-mmio only.
> I'll use "big-endian" property instead of "ehci-be-mmio" compatible
> value. That's a good point, thanks.
> Do I have to add "sequoia usb ehci" description to
> Documentation/powerpc/booting-without-of.txt?
> Do I also have to describe ehci-ppc-of stuff in general?
> BTW, I see nothing about ohci-ppc-of there.
We may need to comprehend the Freescale USB controller since its
technically an EHCI controller. There should be some stuff in
booting-without-of.txt related to it.
- k
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Matt Sealey @ 2007-09-14 15:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <fa686aa40709140753sb3e0e9cv28fa5215f4db3a@mail.gmail.com>
Grant Likely wrote:
> On 9/14/07, Matt Sealey <matt@genesi-usa.com> wrote:
>> sparse, irq_of_find_and_map isn't much help). Maybe I am just not
>> looking in the right place but not being an MPC52xx PIC Expert I
>> wouldn't even know where to start...
>
> The l2 irq numbers map directly to the interrupt numbers listed in the
> 5200b user guide. For example, on p7-11, the masks are listed for
> main interrupts 0 through 16. and on p7-17,18, the peripherial
> interrupts are listed as numbered from 0 to 23 (but notice that it
> does *not* line up with bit positions).
Wow I even had to search.. it's on p7-13 here..
Right but it does start from a certain bit and progress linearly
across the rest of the register.
However, what is interrupt 0 and what is interrupt 16? Do you start
from the left or the right (i.e. Motorola big endian or Rest Of
World big endian)??
> However, it is interesting to note that other than in the register
> definitions, I don't think there is anywhere in the 5200b user manual
> that simple lists the interrupt numbers for each interrupt type.
I think the interesting note is that picking out "what does IRQ 4
in the main interrupt group handle" or picking out a device and
saying "this is IRQ 10" is still, even with your explanation, a
matter of luck and handedness.
Personally I would count from the right (Motorola bit 31) and
work my way from LSB to MSB, but Motorola likes it's backwards
representation and so do some other people. So, does bit 31
equal interrupt 0 or interrupt 16? :)
Then there are the status encoded registers, which report which
IRQ is firing. They are just values. But which value corresponds
to which interrupt (left or right reading) here or do they even
have completely different ones?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Grant Likely @ 2007-09-14 14:53 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <46EA8CD7.2050304@genesi-usa.com>
On 9/14/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Grant!
>
> I have a newbie question which I never had properly answered. On the
> MPC52xx and specifically regarding the device tree, how are interrupt
> numbers assigned?
>
> On Efika (and in the DT docs) it's basically the X Y Z where X is the
> type (critical, main, peripheral, sdma), Y is the number of the
> interrupt, and Z is it's sense level.
>
> However while X and Z are easy to derive, how do you work out what Y
> is meant to be given a device? Is it a bit number in the interrupt
> register, or the value of the encoded interrupt register or something
> else algorithmically determined?
>
> I am just finding the code in Linux that derives this number fairly
> elusive (the irq setup function for the mpc52xx platform is truly
> sparse, irq_of_find_and_map isn't much help). Maybe I am just not
> looking in the right place but not being an MPC52xx PIC Expert I
> wouldn't even know where to start...
The l2 irq numbers map directly to the interrupt numbers listed in the
5200b user guide. For example, on p7-11, the masks are listed for
main interrupts 0 through 16. and on p7-17,18, the peripherial
interrupts are listed as numbered from 0 to 23 (but notice that it
does *not* line up with bit positions).
However, it is interesting to note that other than in the register
definitions, I don't think there is anywhere in the 5200b user manual
that simple lists the interrupt numbers for each interrupt type.
Cheers,
g.
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Grant Likely wrote:
> > On 9/11/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
> >> Hello,
> >>
> >>>> [...]
> >>>> intr = mpc52xx_find_and_map("mpc52xx-pic");
> >>>> if(!intr) {
> >>>> panic(__FILE__ ": mpc52xx-pic - MAP failed");
> >>>> }
> >>>>
> >>>> set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
> >>> You probably don't want to do this (unless you are cascading IRQs to
> >>> custom external hardware). All you should need is the call to
> >>> request_irq() to register your irq handler, and code in your ISR
> >>> handler to clear the interrupt condition.
> >>>
> >>> You do *NOT* want to program the interrupt controller directly. The
> >>> mpc5200 interrupt controller already has a driver. Don't go twiddling
> >>> the registers manually.
> >> OK!
> >>
> >> I have tried it before and i get a "-ENOSYS" returned.
> >>
> >> My code was/is now:
> >> --==>
> >> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
> >> INTMOD_IRQ_BOARD);
> >> <==--
> >>
> >> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> >> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> >>
> >> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> >> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> >> IRQ-2 on a mpc5200b?
> >
> > The irq number you pass into request_irq is a system-wide irq number;
> > it doesn't necessarily map directly onto the MPC52xx irq number.
> > Typically, you'd have a node for your device in the device tree which
> > has a phandle back to the interrupt node and you would use
> > irq_of_parse_and_map() to map it back to a system-wide irq number.
> >
> > Otherwise, you need to call of_irq_map_raw with the pointer to the
> > 52xx interrupt controller node and the interrupt number in the form
> > expected by the device tree. (But adding a device tree node for your
> > device is far easier).
> >
> > Cheers,
> > g.
> >
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] PowerPC: usb ehci of_platform bindings for Sequoia 440EPx
From: Valentine Barshak @ 2007-09-14 14:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <2c5fb8f063c275286b6b26ca734ed64d@kernel.crashing.org>
Segher Boessenkool wrote:
>> EHCI OF bindings for PowerPC 440EPx Sequoia.
>
> Those aren't bindings, they are examples. Bindings are pieces
> of documentation that describe what device-specific properties
> mean what, what standard properties are required with what
> values, etc.
>
> Examples are good to have, of course.
>
> One thing you really need to document is what "ehci-be-desc"
> and friends mean. I can give you one comment already: for
> devices that are usually little-endian, but an implementation
> implements registers as big-endian, precedent is to show that
> in the device tree by including an (empty) "big-endian" property,
> rather than inventing new "compatible" values.
I was looking at the ohci-ppc-of driver that has "ohci-bigendian"
compatible string and enables both be-mmio and be-desc for the device in
this case. I just wanted to separate mmio and desc stuff for ehci, since
some devices need be-mmio only.
I'll use "big-endian" property instead of "ehci-be-mmio" compatible
value. That's a good point, thanks.
Do I have to add "sequoia usb ehci" description to
Documentation/powerpc/booting-without-of.txt?
Do I also have to describe ehci-ppc-of stuff in general?
BTW, I see nothing about ohci-ppc-of there.
Thanks,
Valentine.
>
>
> Segher
>
^ permalink raw reply
* RE: 2.6.23-rc3 boot hang on MPC8641D
From: sivaji @ 2007-09-14 14:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D82D@zch01exm26.fsl.freescale.net>
Hi Zhang,
Asper ur idea, i downloaded latest BSP(Jun,2007) and the
kernel (2.6.23-rc4) from the Paul's Git tree.
Uboot(1.2.0) was taken from the latest BSP. I portted the new uboot to my
custom board, i got uboot prompt.
When i compiling the kernel i got following warning messages
WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
When i try to boot the kernel, I got following messages
Booting image at 00200000 ...
Image Name: Linux-2.6.23-rc4-g5326152f-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1842307 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x600000
I can't know whether the problem is related to uboot or
kernel. But i tested the board with the 2.6.21 kernel, it was up.In that
kernel we face some issues on PCI Express so we plan to upgrade the kernel.
But the latest kernel was not up.
Please advice me.
By
Sivaji
Zhang Wei-r63237 wrote:
>
> Hi, Sivaji,
>
> I've tested the newest git tree of Paul's, which is aleady updated to
> 2.6.23-rc4. The kernel is no problem with the u-boot of our released BSP
> (Jun, 2007) on MPC8641HPCN board.
>
> Maybe you could update to the newest kernel git tree and try again.
>
> Cheers!
> -zw
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.or
>> g] On Behalf Of sivaji
>> Sent: Thursday, September 13, 2007 1:32 PM
>> To: linuxppc-dev@ozlabs.org
>> Subject: RE: 2.6.23-rc3 boot hang on MPC8641D
>>
>>
>> Hi,
>> Sorry i specify the wrong version, we r using
>> 1.2.0. This uboot
>> was taken from the BSP which was released by Freescale.
>> Previously we tested
>> linux 2.6.21 kernel, we got linux prompt. For this we are
>> using the same
>> uboot(1.2.0).
>> In that version we face some issues in the pci express, at
>> that time kumar
>> suggest to upgrade the kernel verison 2.6.23-rc3.
>> Zhang did u suspect the problem is related to uboot?.
>> by
>> sivaji
>>
>>
>> Zhang Wei-r63237 wrote:
>> >
>> > Yes, It's too old. Maybe not fully supports FDT. You can
>> try the version
>> > of Kumar said or in the BSP of Freescale released.
>> >
>> > - zw
>> >
>> >> -----Original Message-----
>> >> From: linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.org
>> >> [mailto:linuxppc-dev-bounces+wei.zhang=freescale.com@ozlabs.or
>> >> g] On Behalf Of Kumar Gala
>> >> Sent: Thursday, September 13, 2007 1:11 PM
>> >> To: sivaji
>> >> Cc: linuxppc-dev@ozlabs.org
>> >> Subject: Re: 2.6.23-rc3 boot hang on MPC8641D
>> >>
>> >>
>> >> On Sep 12, 2007, at 11:52 PM, sivaji wrote:
>> >>
>> >> >
>> >> >
>> >> > Hi,
>> >> > I tired to move the dtb to 0x2000000, but the
>> result was
>> >> > same.
>> >> > uboot version is 1.1.6
>> >>
>> >> seems like a pretty old u-boot. Willing to try a 1.3.0-rc1?
>> >>
>> >> - k
>> >> _______________________________________________
>> >> Linuxppc-dev mailing list
>> >> Linuxppc-dev@ozlabs.org
>> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >>
>> > _______________________________________________
>> > Linuxppc-dev mailing list
>> > Linuxppc-dev@ozlabs.org
>> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf44335
>> 08.html#a12648963
>> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12676464
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Alan Cox @ 2007-09-14 14:20 UTC (permalink / raw)
To: Christoph Hellwig, Heiko Carstens, Andrew Morton, Michael Neuling,
Linus Torvalds, paulus, Alan Cox, David S. Miller, linux-kernel,
linuxppc-dev, Martin Schwidefsky
In-Reply-To: <20070912134910.GA12660@infradead.org>
On Wed, Sep 12, 2007 at 02:49:10PM +0100, Christoph Hellwig wrote:
> On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote:
> > > I might be missing something, but the the right fix is probably to
> > > apply the arch patches from Alan to powerpc and s390. We don't want to
> > > be left over without all the nice termios features on these platforms,
> > > do we?
> >
> > But not in rc6 timeframe, I would guess?
>
> Ask Alan..
Well i've been chasing people for many months on the 390 side so if they missed
a release tough ...
Alan
--
--
"A wiki is where ideas go to die"
-- Becky Hogge
^ permalink raw reply
* Re: [PATCH] ucc_geth: fix compilation
From: Kumar Gala @ 2007-09-14 14:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org list, netdev
In-Reply-To: <20070913152333.GA2381@localhost.localdomain>
On Sep 13, 2007, at 10:23 AM, Anton Vorontsov wrote:
> Currently qe_bd_t is used in the macro call -- dma_unmap_single,
> which is a no-op on PPC32, thus error is hidden today. Starting
> with 2.6.24, macro will be replaced by the empty static function,
> and erroneous use of qe_bd_t will trigger compilation error.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Jeff, I'm going to pick this up via the powerpc.git tree since its
currently only broken in our for-2.6.24 branch (because of other
changes in there). Any issues?
- k
>
> Reposting this to include netdev in Cc.
>
> drivers/net/ucc_geth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 12e01b2..9a38dfe 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -2148,7 +2148,7 @@ static void ucc_geth_memclean(struct
> ucc_geth_private *ugeth)
> for (j = 0; j < ugeth->ug_info->bdRingLenTx[i]; j++) {
> if (ugeth->tx_skbuff[i][j]) {
> dma_unmap_single(NULL,
> - ((qe_bd_t *)bd)->buf,
> + ((struct qe_bd *)bd)->buf,
> (in_be32((u32 *)bd) &
> BD_LENGTH_MASK),
> DMA_TO_DEVICE);
> --
> 1.5.0.6
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Kumar Gala @ 2007-09-14 14:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0709131554530.29675@blarg.am.freescale.net>
On Sep 13, 2007, at 3:55 PM, Kumar Gala wrote:
> Please pull from 'for-2.6.24' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> for-2.6.24
>
> to receive the following updates:
I've updated the branch with the following changes:
> Anton Vorontsov (3):
> [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register
> mmc_spi stub
Updated commit message. (let me know if you want me to drop this for
now and wait til mmc_spi gets merged)
> Roy Zang (1):
> [POWERPC] Update mpc7448hpc2 device tree to be compatible for
> tsi109 chip
Dropped for now. I doubt we want this based on Segher's comments.
(pretty sure its a ts108 on the hpc2 board).
- k
^ permalink raw reply
* Re: RTC class drivers and powerpc arch
From: Kumar Gala @ 2007-09-14 13:59 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070914083907.321820@gmx.net>
On Sep 14, 2007, at 3:39 AM, Gerhard Pircher wrote:
> Hi,
>
> Since todc was removed from arch/powerpc I wonder how to use the
> rtc-cmos
> RTC class driver for my AmigaOne with its VIA southbridge. Do I
> have to
> define a platform device and the get/set_rtc_time hook functions or
> can
> the driver probe for and access the hardware automatically, if
> there's a
> device node for the RTC in the device tree?
Take a look at the RTC nodes that exist in arch/powerpc/boot/dts/
mpc8544ds.dts for an example related to rtc-cmos.
- k
^ permalink raw reply
* Re: [PATCH 02/12] IB/ehca: Add 1 is not longer needed because of firmware interface change
From: Joachim Fenkes @ 2007-09-14 13:48 UTC (permalink / raw)
To: Roland Dreier
Cc: OF-EWG, LKML, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <adaodg7ocrh.fsf@cisco.com>
Roland Dreier <rdreier@cisco.com> wrote on 12.09.2007 22:21:54:
> What happens if someone runs the new driver with older firmware? Or
> what if someone upgrades the firmware without updating the driver?
Thanks for pointing our noses to this. Your comment triggered some further
internal discussions about the meaning of the values for the current
system implementation. We'll think this one over again and repost the
final solution in time for 2.6.24-rc1.
If the rest of this patchset is okay with you, could you apply it and
leave out this one patch? The patchset will apply cleanly without it.
Thanks,
Joachim
^ permalink raw reply
* Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
From: Kumar Gala @ 2007-09-14 13:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <F0AE60D7-68AE-43F9-AD6F-5D7790387217@kernel.crashing.org>
On Sep 14, 2007, at 8:21 AM, Kumar Gala wrote:
>
> On Sep 14, 2007, at 7:32 AM, Paul Mackerras wrote:
>
>> Kumar Gala writes:
>>
>>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>>>
>>> mmc_spi already tested to work. When it will hit mainline
>>> the only change that will be needed is replacing "spidev"
>>> with "mmc_spi".
>>
>> That's a *remarkably* uninformative commit message. And what's the
>> use of putting in something about "when it will hit mainline" when
>> this is the point where it hits mainline?
>
> Yeah, I was afraid of that when I glanced at Anton's patches.
>
> I think the comment is in reference to a mainline SPI subsystem
> change intended for 2.6.24.
Let me know how you want to handle this. I see two options.
1. merge patch as is (with new commit message, see below)
2. drop patch for now and wait for mmc_spi to be merged.
Take a look at the following for Anton's comments on the situation:
http://ozlabs.org/pipermail/linuxppc-dev/2007-August/041370.html
How about a commit message like the following:
[POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register
mmc_spi stub
Enabled using SPI controller on the MPC832x RDB board. We
currently use
a modalias of "spidev" as a place holder (replace with
"mmc_spie") until
the mmc_spi driver support is merged in.
This gets us the ability to test SPI until then.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Matt Sealey @ 2007-09-14 13:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <fa686aa40709111205n5d9f9654m6f2b96d468dfd017@mail.gmail.com>
Grant!
I have a newbie question which I never had properly answered. On the
MPC52xx and specifically regarding the device tree, how are interrupt
numbers assigned?
On Efika (and in the DT docs) it's basically the X Y Z where X is the
type (critical, main, peripheral, sdma), Y is the number of the
interrupt, and Z is it's sense level.
However while X and Z are easy to derive, how do you work out what Y
is meant to be given a device? Is it a bit number in the interrupt
register, or the value of the encoded interrupt register or something
else algorithmically determined?
I am just finding the code in Linux that derives this number fairly
elusive (the irq setup function for the mpc52xx platform is truly
sparse, irq_of_find_and_map isn't much help). Maybe I am just not
looking in the right place but not being an MPC52xx PIC Expert I
wouldn't even know where to start...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> On 9/11/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
>> Hello,
>>
>>>> [...]
>>>> intr = mpc52xx_find_and_map("mpc52xx-pic");
>>>> if(!intr) {
>>>> panic(__FILE__ ": mpc52xx-pic - MAP failed");
>>>> }
>>>>
>>>> set_irq_chip(MPC52xx_IRQ2, &my_irq_chip);
>>> You probably don't want to do this (unless you are cascading IRQs to
>>> custom external hardware). All you should need is the call to
>>> request_irq() to register your irq handler, and code in your ISR
>>> handler to clear the interrupt condition.
>>>
>>> You do *NOT* want to program the interrupt controller directly. The
>>> mpc5200 interrupt controller already has a driver. Don't go twiddling
>>> the registers manually.
>> OK!
>>
>> I have tried it before and i get a "-ENOSYS" returned.
>>
>> My code was/is now:
>> --==>
>> request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_DISABLED , "intmod",
>> INTMOD_IRQ_BOARD);
>> <==--
>>
>> I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
>> "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
>>
>> THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
>> paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
>> IRQ-2 on a mpc5200b?
>
> The irq number you pass into request_irq is a system-wide irq number;
> it doesn't necessarily map directly onto the MPC52xx irq number.
> Typically, you'd have a node for your device in the device tree which
> has a phandle back to the interrupt node and you would use
> irq_of_parse_and_map() to map it back to a system-wide irq number.
>
> Otherwise, you need to call of_irq_map_raw with the pointer to the
> 52xx interrupt controller node and the interrupt number in the form
> expected by the device tree. (But adding a device tree node for your
> device is far easier).
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: [PATCH 04/22] [POWERPC] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
From: Kumar Gala @ 2007-09-14 13:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <7a05156b54e7de9c2c24a146e7826699@kernel.crashing.org>
On Sep 13, 2007, at 5:54 PM, Segher Boessenkool wrote:
>> Update mpc7448hpc2 device tree to be compatible for tsi109 chip.
>
> Do all those boards have a tsi109? If not, this patch is
> incorrect. If they do, is tsi109 actually backward-compatible
> to tsi108? That is, will a driver that knows about tsi108
> only work correctly on a tsi109?
I believe its a tsi108 and thus am going to drop this patch since I
agree with you. Unless Roy tells me otherwise.
> Also, all those names really should have a manufacturer
> prefix ("XXX,...").
More cleanup for someone :)
- k
^ permalink raw reply
* Re: [PATCH] adds support for Micrel KS8721BL PHY
From: Kumar Gala @ 2007-09-14 13:26 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-embedded
In-Reply-To: <1189761900.5113.8.camel@p60635-ste.ids.de>
On Sep 14, 2007, at 4:25 AM, Sergej Stepanov wrote:
> The patch adds the support for Micrel KS8721BL PHY
>
> Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
> --
Such patches should be sent to the netdev list.
- k
^ permalink raw reply
* Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
From: Kumar Gala @ 2007-09-14 13:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <18154.32614.502824.264341@cargo.ozlabs.ibm.com>
On Sep 14, 2007, at 7:32 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> mmc_spi already tested to work. When it will hit mainline
>> the only change that will be needed is replacing "spidev"
>> with "mmc_spi".
>
> That's a *remarkably* uninformative commit message. And what's the
> use of putting in something about "when it will hit mainline" when
> this is the point where it hits mainline?
Yeah, I was afraid of that when I glanced at Anton's patches.
I think the comment is in reference to a mainline SPI subsystem
change intended for 2.6.24.
- k
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-09-14 12:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F078FB151@itri.bte.mam.gov.tr>
Mustafa,
It would have been nice, if you would *NOT* repost my private mails I'd
send to you on the mailing list. At least you could have cut off my
footer from your mail!
As I thought that it is not of general interest I wrote directly to you
- but not too see my mails back again on the list. That's really bad style.
Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: [PATCH 22/22] [POWERPC] MPC832x_RDB: Update dts to use SPI1 in QE, register mmc_spi stub
From: Paul Mackerras @ 2007-09-14 12:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <11897177143496-git-send-email-galak@kernel.crashing.org>
Kumar Gala writes:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> mmc_spi already tested to work. When it will hit mainline
> the only change that will be needed is replacing "spidev"
> with "mmc_spi".
That's a *remarkably* uninformative commit message. And what's the
use of putting in something about "when it will hit mainline" when
this is the point where it hits mainline?
Paul.
^ permalink raw reply
* Re: Section mismatch warning
From: Josh Boyer @ 2007-09-14 12:15 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12673863.post@talk.nabble.com>
On Fri, 14 Sep 2007 05:01:14 -0700 (PDT)
sivaji <rameshmrm@gmail.com> wrote:
>
> Hi,
> When compiling the kernel 2.6.23-rc4 for our custom board based on
> MPC8641, I got following warning messages
>
> WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to
> .init.data:boot_command_line (between 'note_bootable_part' and
> 'pmac_restart')
> WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to
> .init.data:boot_command_line (between 'note_bootable_part' and
> 'pmac_restart')
> WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to
> .init.data:boot_command_line (between 'note_bootable_part' and
> 'pmac_restart')
>
> Give some idea to fix these warnings.
These should be fixed for 2.6.24
josh
^ permalink raw reply
* Section mismatch warning
From: sivaji @ 2007-09-14 12:01 UTC (permalink / raw)
To: linuxppc-dev
Hi,
When compiling the kernel 2.6.23-rc4 for our custom board based on
MPC8641, I got following warning messages
WARNING: vmlinux.o(.text+0x169f6): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a02): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
WARNING: vmlinux.o(.text+0x16a12): Section mismatch: reference to
.init.data:boot_command_line (between 'note_bootable_part' and
'pmac_restart')
Give some idea to fix these warnings.
by
Sivaji
--
View this message in context: http://www.nabble.com/Section-mismatch-warning-tf4442060.html#a12673863
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* RE: STK5200 pci_enable_device problem
From: Mustafa Cayır @ 2007-09-14 11:38 UTC (permalink / raw)
To: Oliver Rutsch; +Cc: linuxppc-embedded
Hi,
i get the latest kernel sources and u-boot sources directly=20
from the git archives from www.denx.de.
My kernel version is Linux-2.6.23-rc5-gaa8ddd08
u-boot version is U-Boot 1.2.0-ge251e00d-dirty
i use dtc compiler with following command:
dtc -O dtb -o tqm5200.dtb -b 0 tqm5200.dts
TQM5200 doesn't boot and gives following error. Any help would be =
approciated.
Thanks a lot.
=3D> run net_nfs_fdt
Using FEC ETHERNET device
TFTP from server 10.18.2.83; our IP address is 10.18.5.44
Filename 'uImage'.
Load address: 0x200000
Loading: =
#################################################################
###################################
done
Bytes transferred =3D 1461683 (164db3 hex)
Using FEC ETHERNET device
TFTP from server 10.18.2.83; our IP address is 10.18.5.44
Filename 'tqm5200.dtb'.
Load address: 0x400000
Loading: #
done
Bytes transferred =3D 3507 (db3 hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.23-rc5-gaa8ddd08
Created: 2007-09-14 6:44:52 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1461619 Bytes =3D 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x400000
WARNING: could not create /chosen FDT_ERR_NOSPACE.
ERROR: /chosen node create failed - must RESET the board to recover.
=
=20
-----Original Message-----
From: Oliver Rutsch [mailto:orutsch@sympatec.com]=20
Sent: Friday, August 31, 2007 12:35 PM
To: Mustafa Cay=FDr
Subject: Re: STK5200 pci_enable_device problem
Hi Mustafa,
> Hello Oliver,
>=20
> My problems continue, could you summarize your steps to bring up the =
board?
> which u-boot version is used?
> how build tqm5200.dts file?
> did you test pci bus?
>=20
> Thanks.
You should get the latest kernel sources and u-boot sources directly=20
from the git archives from www.denx.de.
Only use the native git protocol, not the HTTP git protocol.
E.g. "git-clone git://www.denx.de/git/linux-2.6-denx linux-2.6-denx"
Build u-boot with the configuration for your board. If your card is NOT=20
a 66 MHz PCI-card, then undefine CFG_PCICLK_EQUALS_IPBCLK_DIV2 in the=20
u-boot configuration to get a 33 MHz PCI bus.
Build u-boot and flash it to the module. Then install the dtc compiler=20
from the git archive (git://www.jdl.com/software/dtc.git). Do NOT use=20
the tar archive on the web, it is out of date. Compile a dtb file out of =
the tqm5200.dts file you find in the kernel sources.
Build the kernel with tqm5200_defconfig.
Boot your module and load the kernel and the dtb file in u-boot. E.g.=20
"tftp 200000 mykernel" and "tftp 400000 mydevicetree.dtb".
Don't forget to change the serial console output. On the 2.4 kernel the=20
internal mpc5200 uarts had the name ttyS0/ttyS1/ttyS2. On the 2.6 they=20
are called ttyPSC0 up to ttyPSC2. So type in u-boot
"set addcons 'setenv bootargs ${bootargs} =
console=3DttyPSC0,${baudrate}'"
"save" (don't forget the single quotes in line above!).
Boot now with "bootm 200000 - 400000".
Now it should boot fine.
I've tested a Korenix Jetcard 1404 (Oxford 16mPCI954 chip) with this=20
kernel and it runs fine. I had no luck with the 2.4 kernel as it failed=20
to give the card an interrupt.
Bye,
--=20
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com =B7 Tel.:+49 5323 717514
Sympatec GmbH =B7 Am Pulverhaus 1 =B7 D-38678 Clausthal-Zellerfeld =B7 =
Germany
Geschaeftsfuehrer: Dr.-Ing. E.h. Stephan Roethele =B7 Handelsregister:=20
Amtsgericht Braunschweig, HRB 110809
^ permalink raw reply
* Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
From: Andy Whitcroft @ 2007-09-14 11:03 UTC (permalink / raw)
To: Satyam Sharma
Cc: mel, linux-kernel, Kamalesh Babulal, linuxppc-dev, paulus, anton,
Balbir Singh
In-Reply-To: <a781481a0709140337u2c26f770h2af6d457bc39f280@mail.gmail.com>
Anton, this seems a little reminicient of that bug which popped up in
2.6.23-rc3 so do with SLB loading (if memory serves), with machine
checks and signal 7's. Of course that is _supposed_ to be fixed by this
time ...
I believe it was Paul who fixed up that one, and he is already copied.
-apw
On Fri, Sep 14, 2007 at 04:07:37PM +0530, Satyam Sharma wrote:
> > With 2.6.23-rc6 running on the ppc64 box, following oops is hit
> >
> > Oops: Machine check, sig: 7 [#1]
> >
> > SMP NR_CPUS=128 pSeries
> >
> > Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
> >
> > NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
> >
> > REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
> >
> > MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
> >
> > TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
> >
> > GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
> >
> > GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
> >
> > GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
> >
> > GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
> >
> > GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
> >
> > GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
> >
> > GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
> >
> > GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
> >
> > NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
> >
> > LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
> >
> > Call Trace:
> >
> > [c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
> >
> > [c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
> >
> > [c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
> >
> > [c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
> >
> > [c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
> >
> > [c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
> >
> > [c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
> >
> > [c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
> >
> > [c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
> >
> > [c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
> >
> > [c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
> >
> > [c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
> >
> > [c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
> >
> > [c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
> >
> > [c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
> >
> > --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
> >
> > LR = .pseries_dedicated_idle_sleep+0xd0/0x194
> >
> > [c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
> >
> > [c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
> >
> > [c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
> >
> > [c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
> >
> > Instruction dump:
> >
> > 409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
> >
> > 7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
> >
> > Kernel panic - not syncing: Fatal exception in interrupt
>
> This oops is the real bug here, but is that a machine check exception?
> If so, it could be a hardware failure what you saw there instead, and not
> really a kernel bug ...
^ permalink raw reply
* Re: [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
From: Andrew Morton @ 2007-09-14 10:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel, hch
In-Reply-To: <20070905142742.GA1760@lixom.net>
On Wed, 5 Sep 2007 09:27:43 -0500 Olof Johansson <olof@lixom.net> wrote:
> Convert the io_req_t members to kio_addr_t, to allow use on machines with
> more than 16 bits worth of IO port address space (ppc64 in this case,
> but it applies to others as well).
drivers/usb/host/sl811_cs.c: In function 'sl811_cs_config':
drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'kio_addr_t'
drivers/usb/host/sl811_cs.c:263: warning: format '%04x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
That's not just a cosmetic thing - the printk can print junk and if there's
a %s in the control string after the %x's, printk() will crash.
I don't know how many instances of this are in the tree, but they'll all
need to be found and fixed.
^ permalink raw reply
* Re: [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
From: Satyam Sharma @ 2007-09-14 10:37 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, paulus, linux-kernel, Balbir Singh
In-Reply-To: <46EA5CEB.7020104@linux.vnet.ibm.com>
Hi Kamalesh,
There's two things at work here ...
On 9/14/07, Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi,
>
> With 2.6.23-rc6 running on the ppc64 box, following oops is hit
>
> Oops: Machine check, sig: 7 [#1]
>
> SMP NR_CPUS=128 pSeries
>
> Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
>
> NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
>
> REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
>
> MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
>
> TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
>
> GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
>
> GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
>
> GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
>
> GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
>
> GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
>
> GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
>
> GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
>
> GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
>
> NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
>
> LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
>
> Call Trace:
>
> [c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
>
> [c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
>
> [c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
>
> [c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
>
> [c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
>
> [c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
>
> [c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
>
> [c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
>
> [c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
>
> [c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
>
> [c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
>
> [c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
>
> [c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
>
> [c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
>
> [c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
>
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
>
> LR = .pseries_dedicated_idle_sleep+0xd0/0x194
>
> [c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
>
> [c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
>
> [c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
>
> [c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
>
> Instruction dump:
>
> 409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
>
> 7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
>
> Kernel panic - not syncing: Fatal exception in interrupt
This oops is the real bug here, but is that a machine check exception?
If so, it could be a hardware failure what you saw there instead, and not
really a kernel bug ...
> ------------[ cut here ]------------
>
> Badness at arch/powerpc/kernel/smp.c:202
This one is not the real issue at all -- it's just a sad problem in the powerpc
panic() -> smp_send_stop() -> smp_call_function() -> smp_call_function_map()
call chain. The thing is, smp_call_function() cannot be allowed from interrupt
disabled contexts, hence the WARN_ON() there. But panic() is a special case,
and so we must *not* complain when called from panic -- doing so will only
scroll away the real call trace / oops log from the screen (thankfully you had
a serial cable there?) and distract from the real bug, like what
happened here ...
The fix is to define an alternative __smp_call_function(), that calls into
smp_call_function_map(), and is itself called from
smp_call_function(), and then:
1. Use the inner __smp_call_function() in smp_send_stop(), and,
2. Move the WARN_ON() to the smp_call_function() wrapper instead.
I'd be back at my desk only by Tuesday, so don't expect a patch before then,
unless Paul fixes this up by himself before that.
Cheers,
Satyam
^ permalink raw reply
* [BUG][2.6.23-rc6] Badness at arch/powerpc/kernel/smp.c:202
From: Kamalesh Babulal @ 2007-09-14 10:05 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: paulus, Balbir Singh
Hi,
With 2.6.23-rc6 running on the ppc64 box, following oops is hit
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=128 pSeries
Modules linked in: binfmt_misc ipv6 dm_mod ehci_hcd ohci_hcd usbcore
NIP: c0000000000ed560 LR: c0000000000efc7c CTR: c0000000000ed504
REGS: c00000000ffef680 TRAP: 0200 Not tainted (2.6.23-rc6-autokern1)
MSR: 8000000000109032 <EE,ME,IR,DR> CR: 28002042 XER: 00000010
TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
GPR00: 0000000000000000 c00000000ffef900 c0000000006fe598 c0000000d7a8f200
GPR04: 0000000000001000 0000000000000000 0000000000001000 8000000000c26393
GPR08: c0000000006b43d0 0000000000000001 0000000000001000 0000000000000000
GPR12: 0000000048000048 c0000000005f1700 0000000000000000 0000000007a8dcd0
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000001000 c0000000063234e8
GPR28: 0000000000001000 0000000000000000 c000000000689c08 c00000000ff3a480
NIP [c0000000000ed560] .end_bio_bh_io_sync+0x5c/0xac
LR [c0000000000efc7c] .bio_endio+0xb4/0xd4
Call Trace:
[c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
[c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
[c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
[c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
[c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
[c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
[c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
[c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
[c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
[c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
[c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
[c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
[c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
[c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
LR = .pseries_dedicated_idle_sleep+0xd0/0x194
[c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
[c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
[c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
[c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
Instruction dump:
409a0030 393f0018 38000080 7d6048a8 7d6b0378 7d6049ad 40a2fff4 38002000
7d2018a8 7d290378 7d2019ad 40a2fff4 <e9230038> e89f0018 e9690000 f8410028
Kernel panic - not syncing: Fatal exception in interrupt
------------[ cut here ]------------
Badness at arch/powerpc/kernel/smp.c:202
NIP: c000000000026024 LR: c00000000004e378 CTR: 800000000013f270
REGS: c00000000ffef120 TRAP: 0700 Tainted: G D (2.6.23-rc6-autokern1)
MSR: 8000000000021032 <ME,IR,DR> CR: 22002022 XER: 0000000a
TASK = c0000000ecf9f000[0] 'swapper' THREAD: c00000000ff8c000 CPU: 2
GPR00: 0000000000000001 c00000000ffef3a0 c0000000006fe598 c00000000069ffb8
GPR04: 0000000000000000 0000000000000001 0000000000000000 0000000000000007
GPR08: 0000000000000000 c000000000739818 c000000000742998 c00000000069ffb8
GPR12: 0000000000004000 c0000000005f1700 0000000000000000 0000000007a8dcd0
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000001000 0000000000001000 0000000000000000
GPR24: 0000000000000000 0000000000000000 0000000000001000 0000000000000007
GPR28: c0000000004e3190 0000000000000000 c000000000685b80 0000000000000000
NIP [c000000000026024] .smp_call_function_map+0x34/0x28c
LR [c00000000004e378] .panic+0x98/0x1b0
Call Trace:
[c00000000ffef3a0] [c0000000006943e8] 0xc0000000006943e8 (unreliable)
[c00000000ffef450] [c00000000004e378] .panic+0x98/0x1b0
[c00000000ffef4f0] [c00000000002213c] .die+0x224/0x264
[c00000000ffef590] [c0000000000231f0] .machine_check_exception+0x210/0x240
[c00000000ffef610] [c000000000003480] machine_check_common+0x100/0x180
--- Exception: 200 at .end_bio_bh_io_sync+0x5c/0xac
LR = .bio_endio+0xb4/0xd4
[c00000000ffef900] [c00000000ffef990] 0xc00000000ffef990 (unreliable)
[c00000000ffef980] [c0000000000efc7c] .bio_endio+0xb4/0xd4
[c00000000ffefa10] [c000000000290060] .__end_that_request_first+0x154/0x548
[c00000000ffefae0] [c00000000035af10] .scsi_end_request+0x40/0x138
[c00000000ffefb80] [c00000000035b234] .scsi_io_completion+0x188/0x454
[c00000000ffefc60] [c000000000372a24] .sd_rw_intr+0x2e4/0x338
[c00000000ffefd30] [c000000000354548] .scsi_finish_command+0xbc/0xe0
[c00000000ffefdc0] [c00000000035bdf0] .scsi_softirq_done+0x140/0x188
[c00000000ffefe60] [c000000000293184] .blk_done_softirq+0xa0/0xd0
[c00000000ffefef0] [c000000000055e1c] .__do_softirq+0xa8/0x164
[c00000000ffeff90] [c000000000023f14] .call_do_softirq+0x14/0x24
[c00000000ff8f960] [c00000000000bd30] .do_softirq+0x68/0xac
[c00000000ff8f9f0] [c000000000055f70] .irq_exit+0x54/0x6c
[c00000000ff8fa70] [c00000000000c358] .do_IRQ+0x170/0x1ac
[c00000000ff8fb00] [c000000000004780] hardware_interrupt_entry+0x18/0x98
--- Exception: 501 at .pseries_dedicated_idle_sleep+0xe0/0x194
LR = .pseries_dedicated_idle_sleep+0xd0/0x194
[c00000000ff8fdf0] [0000000000000000] .__start+0x4000000000000000/0x8 (unreliable)
[c00000000ff8fe80] [c000000000010bd4] .cpu_idle+0x104/0x1d8
[c00000000ff8ff00] [c00000000002672c] .start_secondary+0x160/0x184
[c00000000ff8ff90] [c000000000008364] .start_secondary_prolog+0xc/0x10
Instruction dump:
fba1ffe8 fbc1fff0 fbe1fff8 7c6b1b78 f8010010 f821ff51 7cdd3378 f8e10100
f9010108 880d01da 7c000074 7800d182 <0b000000> e922a500 3860ffff e8090000
I tired googling for similar bug and found two which where earlier reported one
at linuxppc-dev mailing list on 2.6.23-rc1 kernel
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039905.html
and other on 2.6.22-rc1 kernel
http://lkml.org/lkml/2007/5/22/390
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH] adds support for Micrel KS8721BL PHY
From: Sergej Stepanov @ 2007-09-14 9:25 UTC (permalink / raw)
To: linuxppc-embedded
The patch adds the support for Micrel KS8721BL PHY
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff -ruN linux-2.6.22.1/drivers/net/phy/Kconfig linux-2.6.22.1_ids8247/drivers/net/phy/Kconfig
--- linux-2.6.22.1/drivers/net/phy/Kconfig 2007-07-10 20:56:30.000000000 +0200
+++ linux-2.6.22.1_ids8247/drivers/net/phy/Kconfig 2007-08-02 10:54:34.000000000 +0200
@@ -55,6 +55,11 @@
---help---
Currently supports the BCM5411, BCM5421 and BCM5461 PHYs.
+config MICREL_PHY
+ tristate "Drivers for MICREL KS8721BL PHYs"
+ ---help---
+ Currently supports on MPC82xx_IDS8247 board.
+
config FIXED_PHY
tristate "Drivers for PHY emulation on fixed speed/link"
---help---
diff -ruN linux-2.6.22.1/drivers/net/phy/Makefile linux-2.6.22.1_ids8247/drivers/net/phy/Makefile
--- linux-2.6.22.1/drivers/net/phy/Makefile 2007-07-10 20:56:30.000000000 +0200
+++ linux-2.6.22.1_ids8247/drivers/net/phy/Makefile 2007-08-02 10:54:34.000000000 +0200
@@ -11,4 +11,5 @@
obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
+obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_FIXED_PHY) += fixed.o
diff -ruN linux-2.6.22.1/drivers/net/phy/micrel.c linux-2.6.22.1_ids8247/drivers/net/phy/micrel.c
--- linux-2.6.22.1/drivers/net/phy/micrel.c 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.22.1_ids8247/drivers/net/phy/micrel.c 2007-08-02 10:54:34.000000000 +0200
@@ -0,0 +1,109 @@
+/*
+ * drivers/net/phy/micrel.c
+ *
+ * Driver for Micrel KS8721BL PHY
+ * based on drivers/net/phy/lxt.c from Andy Fleming
+ *
+ * Author: Sergej Stepanov, IDS GmbH, Germany
+ * Copyright (c) 2007 IDS GmbH, Germany
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/unistd.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/skbuff.h>
+#include <linux/spinlock.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/uaccess.h>
+
+
+#define MII_KS8721BL_RXERCR 0x15
+#define MII_KS8721BL_ICSR 0x1B
+#define MII_KS8721BL_PHYCR 0x1F
+
+
+MODULE_DESCRIPTION("Micrel KS8721BL driver");
+MODULE_AUTHOR("Sergej Stepanov");
+MODULE_LICENSE("GPL");
+
+
+static int ks8721bl_config_intr(struct phy_device *phydev)
+{
+ int err1;
+
+ if(phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ {
+ err1 = phy_write(phydev, MII_KS8721BL_ICSR, 0xFF00);
+ err1 = phy_write(phydev, 0, 0x1200); /* control register */
+ }
+ else
+ err1 = phy_write(phydev, MII_KS8721BL_ICSR, 0);
+
+ return err1;
+}
+
+static int ks8721bl_config_init(struct phy_device *phydev)
+{
+ phy_write(phydev, MII_KS8721BL_ICSR, 0);
+ return 0;
+}
+
+
+static int ks8721bl_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, MII_KS8721BL_ICSR);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static struct phy_driver ks8721bl_driver = {
+ .phy_id = 0x000221619,
+ .name = "KS8721BL",
+ .phy_id_mask = 0xfffffff0,
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = ks8721bl_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = ks8721bl_ack_interrupt,
+ .config_intr = ks8721bl_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+static int __init ks8721_init(void)
+{
+ int ret;
+
+ ret = phy_driver_register(&ks8721bl_driver);
+ if (ret)
+ goto err1;
+
+ return 0;
+ err1:
+ return ret;
+}
+
+static void __exit ks8721_exit(void)
+{
+ phy_driver_unregister(&ks8721bl_driver);
+}
+
+module_init(ks8721_init);
+module_exit(ks8721_exit);
^ 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