* 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 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: [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 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: [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: 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: 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: [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: [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: 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: 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: [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: [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: [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: Grant Likely @ 2007-09-14 15:49 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <46EAA65E.5080006@genesi-usa.com>
On 9/14/07, Matt Sealey <matt@genesi-usa.com> wrote:
> 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? :)
No, they are explicitly numbered. Are you looking at the 5200 or the
5200B user manual? In my copy, on page 7-17, I see this: PSa0 in
peripheral interrupt 0 (l2=3D0), PSa23 is peripheral interrupt #23
(l2=3D23)
Bits Name
8 PSa23 BestCom
9 PSa22 BDLC
10 PSa0 BestCom
11 PSa1 PSC1
12 PSa2 PSC2
13 PSa3 PSC3
14 PSa4 PSC6
15 PSa5 Ethernet
16 PSa6 USB
17 PSa7 ATA
18 PSa8 PCI Contr
19 PSa9 PCI SC In
20 PSa10 PCI SC In
21 PSa11 PSC4
22 PSa12 PSC5
23 PSa13 SPI modf
24 PSa14 SPI spif
25 PSa15 I2C1
26 PSa16 I2C2
27 PSa17 CAN1
28 PSa18 CAN2
29:30 =97 Reserved
31 PSa21 XLB Arbit
>
> 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
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Laurent Pinchart @ 2007-09-14 15:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200707111517.52663.laurent.pinchart@technotrade.biz>
> On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote:
>> On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote:
>>> cpm2_clk_setup() supports setting FCC clocks only, even though the
>>> cpm_clk_target enumeration lists SCC clocks. This patch adds SCC =20
>>> clock support.
>>
>> Any chance this patch (and its 2/2 brother) could be committed ?
>
> Have you looked at Scott Wood's cleanup patches. They seem to do =20
> some of this.
Where can I find them ? I checked in
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
and found nothing relevant.
Best regard,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Matt Sealey @ 2007-09-14 16:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, S. Fricke
In-Reply-To: <fa686aa40709140849o400fc5d0oaaee540fa416fefe@mail.gmail.com>
Grant Likely wrote:
>
> No, they are explicitly numbered. Are you looking at the 5200 or the
> 5200B user manual?
MPC5200B User's Manual, Rev. 1.3 (MPC5200BUM.pdf)
> In my copy, on page 7-17, I see this:
Ah! 7-20 here. Do we have different revisions of the manual, perhaps? :)
PSa0 in
> peripheral interrupt 0 (l2=0), PSa23 is peripheral interrupt #23
> (l2=23)
>
> Bits Name
> 8 PSa23 BestCom
So, the numbering of the interrupts is not derived from anything but
the "Name" field in those tables? 0 1 3 would be Slice Timer 0, 1 0 3
would be Slice Timer 1 (main, interrupt 0, we always use 3 on Efika
for some reason) and 1 9 3 would be TMR0? PCI control and initiator
interrupts would be 2 (8,9,10) 3?
Well, this certainly makes a lot more sense, at least in terms of
deriving the numbers, however it looks like it's a fairly nonsensical
numbering system to be fair.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 02/12] IB/ehca: Add 1 is not longer needed because of firmware interface change
From: Roland Dreier @ 2007-09-14 16:05 UTC (permalink / raw)
To: Joachim Fenkes
Cc: OF-EWG, LKML, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <OF628247C3.FB0AFE13-ONC1257355.005E8356-C1257356.004BCE85@de.ibm.com>
> 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.
Yes, no problem, I'll drop this patch for now.
- R.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Scott Wood @ 2007-09-14 16:08 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200709141755.45559.laurentp@cse-semaphore.com>
On Fri, Sep 14, 2007 at 05:55:45PM +0200, Laurent Pinchart wrote:
> > On Sep 13, 2007, at 8:53 AM, Laurent Pinchart wrote:
> >> On Wednesday 11 July 2007 15:17, Laurent Pinchart wrote:
> >>> cpm2_clk_setup() supports setting FCC clocks only, even though the
> >>> cpm_clk_target enumeration lists SCC clocks. This patch adds SCC
> >>> clock support.
> >>
> >> Any chance this patch (and its 2/2 brother) could be committed ?
> >
> > Have you looked at Scott Wood's cleanup patches. They seem to do
> > some of this.
>
> Where can I find them ? I checked in
>
> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>
> and found nothing relevant.
Check the linuxppc-dev archives... I should have another respin soon
(hopefully today).
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Jon Loeliger @ 2007-09-14 16:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B89BC392-2366-42E0-BEA0-4A781A9437D3@kernel.crashing.org>
Kumar Gala wrote:
> Someone really needs to add some macro/preprocessor magic into DTC so
> this is made a lot simpler.
>
> - k
Kumar,
I am seriously contemplating this problem.
The trick is, I need to quit with the whole
Power Point Programmer job title for a bit...
jdl
^ permalink raw reply
* Re: rtc-ds1742.c should use resource_size_t for base address
From: Atsushi Nemoto @ 2007-09-14 16:09 UTC (permalink / raw)
To: david; +Cc: akpm, linuxppc-dev, linux-kernel, rtc-linux
In-Reply-To: <20070914055427.GM481@localhost.localdomain>
On Fri, 14 Sep 2007 15:54:27 +1000, David Gibson <david@gibson.dropbear.id.au> wrote:
> Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store
> the base mmio address of the NVRAM/RTC. This breaks on systems like
> PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO
> on the system, including the RTC, is typically above the 4GB point,
> and cannot fit into an unsigned long.
>
> This patch fixes the problem by replacing the unsigned long with a
> resource_size_t. Tested on Ebony (PPC440) (with additional patches to
> instantiate the ds1742 platform device appropriately).
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thanks!
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
^ permalink raw reply
* Re: [PATCH] pcmcia: Convert io_req_t to use kio_addr_t
From: Olof Johansson @ 2007-09-14 16:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel, hch
In-Reply-To: <20070914034854.1658a9cf.akpm@linux-foundation.org>
On Fri, Sep 14, 2007 at 03:48:54AM -0700, Andrew Morton wrote:
> 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.
A crap, I completely forgot to check drivers/, and my default builds
don't contain many of them. My bad.
I'll do a full pass and review all references to the changed variables. So
far I've only noticed printk stuff, but I'm not done. There's a fair
amount lot of places where they're cast into ints instead of longs,
but that's a whole other ball of wax (and shouldn't cause regressions
like the printk ones could).
-Olof
^ permalink raw reply
* Re: rtc-ds1742.c should use resource_size_t for base address
From: Josh Boyer @ 2007-09-14 17:20 UTC (permalink / raw)
To: David Gibson
Cc: Andrew Morton, linuxppc-dev, Atsushi Nemoto, linux-kernel,
rtc-linux
In-Reply-To: <20070914055427.GM481@localhost.localdomain>
On Fri, 14 Sep 2007 15:54:27 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store
> the base mmio address of the NVRAM/RTC. This breaks on systems like
> PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO
> on the system, including the RTC, is typically above the 4GB point,
> and cannot fit into an unsigned long.
>
> This patch fixes the problem by replacing the unsigned long with a
> resource_size_t. Tested on Ebony (PPC440) (with additional patches to
> instantiate the ds1742 platform device appropriately).
Where would those additional patches be? :)
josh
^ permalink raw reply
* Re: Please pull from for-2.6.24
From: Josh Boyer @ 2007-09-14 17:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <AC7B9A70-5050-4191-A20E-B92686B675D4@kernel.crashing.org>
On Fri, 14 Sep 2007 09:02:04 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> 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).
It is a tsi108 on hpc2. Holly has tsi109. From a Linux perspective,
there is no difference. And the comment Segher made on the list was
"Looks good, thanks!" So what other comment are you talking about?
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Kumar Gala @ 2007-09-14 18:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <46EAB69C.104@freescale.com>
On Sep 14, 2007, at 11:28 AM, Jon Loeliger wrote:
> Kumar Gala wrote:
>
>> Someone really needs to add some macro/preprocessor magic into DTC
>> so this is made a lot simpler.
>> - k
>
> Kumar,
>
> I am seriously contemplating this problem.
> The trick is, I need to quit with the whole
> Power Point Programmer job title for a bit...
I'm all for both of these things. You working on getting DTC to have
some macro/include ability and you not being a powerpoint programmer.
- k
^ 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