Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
Benjamin Herrenschmidt wrote: >>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem >>> with the DMA implementation on that architecture. There are enough cards >>> out there that only support 32-bit DMA that this really needs to work.. >> Yes, could the PPC folks please have a look at it? Thanks. > > Smells like we may have a bug there. No worries though, all current PPC > machines have an iommu that will not give out addresses above 32 bits > anyway, but I'll double check what's up. > > Do you see something in dmesg when that happens ? There was nothing in Olaf's report, except for trouble in sbp2 _after_ the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.) -- Stefan Richter -=-=-=== =--- --=-= http://arcgraph.de/sr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
On Sun, 5 Aug 2007, Arnd Bergmann wrote: > On Sunday 05 August 2007, Guennadi Liakhovetski wrote: > > I tried using of_serial.c on a (PPC) MPC8241 based system, which has a > > "16650A" compatible double UART built into the SoC. Using of_serial.c > > causes the ports to be autoconfigured, and this fails. The loopback test > > fails, because the MSR register on 824[15] doesn't implement the > > UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs > > without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these > > SOCs to skip the loopback test altogether? The latter is certainly easier > > and affects much fewer systems, so, I'd go for that. > > Yes, that sounds good. Just make sure you test the "compatible" property > in the device node for something appropriate. In of_platform_serial_probe(), > you can then do something like > > if (of_device_is_compatible(ofdev, "mpc8241-serial")) > flags |= UPF_SKIP_TEST; That would be a possibility, but that would mean all 8241/8245 have to adjust their .dts. Ok, there are not so many of them in the mainline now (in fact, hardly any apart from linkstation:-)), still. Cannot we use something already available to just check if we're running on such a CPU? Worst case - find and parse cpu node, or maybe using some cpu_feature? Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
Benjamin Herrenschmidt wrote: >>>Allow generic_calibrate_decr to work for 40x platforms. Given that the >>>hardware >>>behavior is identical, this also changes the set_dec function to reload the >>>PIT >>>on 40x to match the behavior 44x currently has. >>Why bother doing this?! This will only warrant you imprecise decrementer >>interrupts while it should be interrupting at the precise period currently >>(if >>you load PIT once)... > Because that's what the kernel timekeeping code expects ? The reference > time is the timebase and it doesn't drift. > The DEC/PIT is commonly used to trigger any timing, such as what is done > for lost interrupts on some platforms. Also, with dynticks, we'll most > certainly want variable reload values as well. That's another matter. :-) BTW, because of that mere return in set_dec() for the 40x case I had to write to the PIT myself in the decrementer clockevent's set_next_event() method -- while for classic PPC I was just calling set_dec(n-1)... > So I'm very happy to have Josh change the code that way. It makes things > more consistent accross the board and removes confusion. Yeah, it's OK now that's my temporary confusion has passed. Well, it wasn't only not only mine -- the set_dec() code was suggesting auto-reload mode, and has been obviosuly copied from , so arch/ppc/ was using the auto-reload mode indeed. > Ben. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 06/10] 40x decrementer fixes
Hello. Benjamin Herrenschmidt wrote: >>>Why bother doing this?! This will only warrant you imprecise decrementer >>>interrupts while it should be interrupting at the precise period currently >>>(if >>>you load PIT once)... >> >>I.e. the error will only accumulate. NAK. > No, it won't since the timebase is always used as the reference. I meant the error in the interrupt period itself (I know that this gets accounted for) but that was a thinko anyway... > Ben. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
On Sunday 05 August 2007, Guennadi Liakhovetski wrote: > That would be a possibility, but that would mean all 8241/8245 have to > adjust their .dts. Ok, there are not so many of them in the mainline now > (in fact, hardly any apart from linkstation:-)), still. Cannot we use > something already available to just check if we're running on such a CPU? > Worst case - find and parse cpu node, or maybe using some cpu_feature? It's fundamentally a property of the serial controller implementation, not of the processor, so the cpu_features are the wrong place to put this. There should at least be a generic way to define thsi in the device tree so that _future_ trees can just mark the port as compatible with one that has this bug. If you want to work around existing systems that don't mention this in the device_tree, you could perhaps use machine_is(foo) to test for it. Another option altogether would be to allow the device node to specify the linux specific serial port flags in a separate property, like "linux,uart-port-flags" that contains the same flags that setserial can set from user space. That would also be useful if you want to specify UPF_MAGIC_MULTIPLIER on certain high-speed ports, because it cannot be autoprobed. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
So, like, the other day Arnd Bergmann mumbled: > On Sunday 05 August 2007, Guennadi Liakhovetski wrote: > > That would be a possibility, but that would mean all 8241/8245 have to > > adjust their .dts. Ok, there are not so many of them in the mainline now > > (in fact, hardly any apart from linkstation:-)), still. Cannot we use Heck, I'm slowly working on the StorCenter too.. :-) I supect it will have the same issue in the end, right? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
On Sun, 5 Aug 2007, Jon Loeliger wrote: > So, like, the other day Arnd Bergmann mumbled: > > On Sunday 05 August 2007, Guennadi Liakhovetski wrote: > > > That would be a possibility, but that would mean all 8241/8245 have to > > > adjust their .dts. Ok, there are not so many of them in the mainline now > > > (in fact, hardly any apart from linkstation:-)), still. Cannot we use > > Heck, I'm slowly working on the StorCenter too.. :-) > > I supect it will have the same issue in the end, right? ...if you choose to use of_serial.c, yes, if you don't use it and just use legacy_serial.c, then you're fine. BTW, my offer still holds to see if we can build a single kernel for both with just specific device-trees, but that's a separate matter:-) Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
So, like, the other day Guennadi Liakhovetski mumbled: > On Sun, 5 Aug 2007, Jon Loeliger wrote: > > ...if you choose to use of_serial.c, yes, if you don't use it and just use > legacy_serial.c, then you're fine. Ah, I see. OK. > BTW, my offer still holds to see if we can build a single kernel for both > with just specific device-trees, but that's a separate matter:-) Indeed. I'm fully on-board with that goal, but it may take a couple rounds to refine it into that state. One question I have is the stupid ethernet driver. Is the driver that is in mainline now usable on the StorCenter? I haven't waded through the supplied vendor patch to verify how it compares to the r8169 in mainline yet. Also, what do you want to do about the Kconfig set up for these then? Specifically, do you want to have "TurboStation" and "StorCenter"? Or would it make more sense to have something like a generic "NAS8241" with sub-choices of "storcenter" and "turbostation"? Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: "Badness at kernel/irq/resend.c:70" on boot - via-pmu?
On Sat, 2007-08-04 at 21:41 -0700, Linus Torvalds wrote: > > On Sun, 5 Aug 2007, Paul Collins wrote: > > > > I got the message below on boot with 2.6.23-rc2 on my PowerBook. > > It's a debug message, I think we need to remove it. It's trying to figure > out what goes wrong with one particular machine, and I probably shouldn't > have merged it for mainline. > > Ignore it, it will be gone soon enough, and it should happen just once per > boot. Actually, it's interesting as that irq shouldn't hit that path :-) Not critical (won't break anything), but still something I'll look into just in case it hides something bad. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
On Sunday 05 August 2007, Guennadi Liakhovetski wrote: > > > I supect it will have the same issue in the end, right? > > ...if you choose to use of_serial.c, yes, if you don't use it and just use > legacy_serial.c, then you're fine. But of_serial can be a loadable module, which means you still get into trouble if you load it, even if the port was originally initialized by legacy_serial. Maybe the best solution would be for 824[15] to not claim compatibility with 8250 at all then. If the device tree contains an entry that matches what the generic driver looks for, it better be something that can be handled by that driver. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
On Sun, 2007-08-05 at 09:54 +0200, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> >>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> >>> with the DMA implementation on that architecture. There are enough cards
> >>> out there that only support 32-bit DMA that this really needs to work..
> >> Yes, could the PPC folks please have a look at it? Thanks.
> >
> > Smells like we may have a bug there. No worries though, all current PPC
> > machines have an iommu that will not give out addresses above 32 bits
> > anyway, but I'll double check what's up.
> >
> > Do you see something in dmesg when that happens ?
>
> There was nothing in Olaf's report, except for trouble in sbp2 _after_
> the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.)
Hrm, allright, that's a bit weird. Olaf machine has only 256M of RAM
according to that dmesg, and thus, the kernel isn't enabling the iommu,
we use the "trivial" version of the dma mapping ops.
I suspect we have a bug in our imlementation of set_dma_mask though, in
that it does the "dma_supported" check using the previous mask and not
the one passed in :-)
The implementation of dma_supported that we hit in the no-iommu case
looks like that:
static int dma_direct_dma_supported(struct device *dev, u64 mask)
{
/* Could be improved to check for memory though it better be
* done via some global so platforms can set the limit in case
* they have limited DMA windows
*/
return mask >= DMA_32BIT_MASK;
}
So that should have worked. (The comment is a bit obscure, just ignore
it for now).
However, as I said above, our dma_set_mask() wrapper uses the wrong
value (the old, not the new mask). But that still should have worked
since the default dma mask for a PCI device is 0x
Thus at this stable, I'm a bit at a loss of why it didn't work, I'll
have to test on one of those machines with some printk's in when I
manage to get to work (dunno when, kid's sick so I may have to stay home
today).
BTW. Any reason why you don't set the DMA mask in the ohci driver rather
than the sbp2 one ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 02/10] 4xx Kconfig cleanup
On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote: > Remove some leftover cruft in the 40x Kconfig file. Also make sure we > select WANT_DEVICE_TREE for 40x. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> > > --- > arch/powerpc/platforms/40x/Kconfig | 77 > - > arch/powerpc/platforms/Kconfig.cputype |1 > 2 files changed, 1 insertion(+), 77 deletions(-) > > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig > @@ -1,16 +1,3 @@ > -config 4xx > - bool > - depends on 40x || 44x > - default y You've removed this one, but I don't see you re-add it anywhere. We still need to define the CONFIG_4xx symbol or things will break.. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
On Fri, Aug 03, 2007 at 02:55:16PM -0700, Yoder Stuart-B08248 wrote:
>
> > > > > + MPIC: [EMAIL PROTECTED] {
> > > > > + device_type = "open-pic";
> > > > >
> > > > > device_type = "interrupt-controller".
> > >
> > > Not according to the binding in booting-without-of.txt
> >
> > My understanding here, though possibly flawed, is that the current
> > implementation has "open-pic" but _should_ have "interrupt-controller"
> > as that is the officially correct name.
> >
> > I _think_ this means we need a transitional period where we update
> > the code to look for "interrupt-controller", and obsoletedly, looks
> > for the "open-pic", while we transition to the new, correct name.
>
> "open-pic" is the correct value for the device_type property.
> See the binding at:
> http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps
> That is the definition for open pic interrupt controllers (AFAIK).
>
> I am not aware of any official binding with "interrupt-controller"
> as the device_type.
That's what I thought.
> However, the interrupt mapping spec says that all interrupt
> controller (regardless of device_type) must have a
> property named "interrupt-controller" to identify
> the device node as an interrupt controller and root of
> a interrupt tree.
> See: http://playground.sun.com/1275/practice/imap/imap0_9d.html
Ah, yes. Added to both the mpic and 8259.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
On Fri, Aug 03, 2007 at 07:47:43PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> >>>===
> >>>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
> >>>2007-07-30 17:07:14.0 +1000
> >>>+++ working-2.6/Documentation/powerpc/booting-without-of.txt
> >>>2007-07-30 17:07:14.0 +1000
> >>>@@ -1757,45 +1757,23 @@ platforms are moved over to use the flat
> >>> };
> >>> };
> >>>
> >>>-j) Flash chip nodes
> >>>+ j) CFI or JEDEC memory-mapped NOR flash
> >>>
> >>> Flash chips (Memory Technology Devices) are often used for solid state
> >>> file systems on embedded devices.
>
> >>>-Required properties:
> >>>+ - compatible : should contain the specific model of flash chip(s)
> >>>used
> >>>+ followed by either "cfi-flash" or "jedec-flash"
>
> >>This "compatible" prop (and the node in whole) doesn't say a
> >>thing about how the flash is mapped into the CPU address space. I
> >>strongly disagree that this node provides enough info to select a
> >>driver. :-/
>
> > To be honest, I'm not sure that describing the mapping is really the
> > job of the compatible property. That the flash is mapped into the
> > address space is kind of implicit in the way the reg interacts with
> > the parents' ranges property.
>
> Ah, I keep forgetting about implied 1:1 parent/child address
> correspondence... :-<
> But does it really imply how the (low) address bits of the *child* bus
> ("ebc" in this case) are connected to the chip? I don't think so...
>
> > Can you describe some of the options for *not* direct mapped flash
> > chips - I can't reasonably come up with a way of describing the
> > distinction when I've never seen NOR flash other than direct mapped.
>
> You're lucky to live in the single-endian world. Once you're in
> bi-endian
> one, all kinds of strange mappings become possible. I've seen the MIPS
> mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
> couldn't be served by physmap, yet that's not all... here's the code of its
> map read*() methods:
Aha! Ok, now I understand the sorts of situations you're talking
about. By "not direct mapped", I thought you were talking about some
kind of access via address/data registers on some indirect bus
controller, rather than weird variations on endianness and
bit-swizzling.
Hrm.. this is a property of how the flash is wired onto the bus,
rather than of the flash chips themselves, so I'm not entirely sure
where description of it belongs.
Simplest option seems to me to add a property "endianness" or
"bit-swizzling" or something which can be defined to describe some odd
connections. If absent we'd default to direct mapping. Segher, is
that idea going to cause you to scream?
> >>>+ - reg : Address range of the flash chip
> >>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the
> >>>device width
> >>>+ times the number of interleaved chips.
> >>>+ - device-width : (optional) Width of a single flash chip. If
> >>>omitted,
> >>>+ assumed to be equal to 'bank-width'.
>
> >>Why then not just introduce the "interleave" prop and obsolete the
> >>"bank-width"?
>
> > Because they're equivalent information, and bank-width is what the
> > code ends up actually caring about. I don't see any reason to prefer
> > giving the interleave.
>
> Well, "device-width" is not the thing that we care about either. ;-)
Well, yes but we need to encode it somehow. Segher preferred
device-width to interleave, because it's closer to a description of
the actual hardware, rather than an abstration decribing its wiring.
In other words I *still* don't see any reason to prefer giving the
interleave.
> >>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
> >>>===
> >>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30
> >>>17:07:11.0 +1000
> >>>+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30
> >>>17:07:14.0 +1000
> [...]
> >>>+ for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
> >>>+ const u32 *reg;
> >>>+ const char *name;
> >>>+ const void *ro;
> >>
> >>We hardly need the above 2 variables.
>
> > They're all used...
>
> I meant that there's no necessity in them.
By which you mean?
> >>Oh, I see that the new partition representation have really simplified
> >>parsing -- this function is hardly shorter than the old one... :-P
>
> > They new format isn't supposed to be simpler to parse: it's supposed
> > to be more flexible if we ever need to add more per-partition
> > information than just the offset / size / read-only.
>
> Well, if we ever need that indeed... :-)
>
> [...]
>
> >>>@@ -221,6 +297,14 @@ er
Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
On Fri, Aug 03, 2007 at 08:29:07PM +0400, Sergei Shtylyov wrote: > David Gibson wrote: > > > Duh, forgot to attach the actual patch. Here it is: > > > Index: working-2.6/Documentation/powerpc/booting-without-of.txt > > === > > --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt > > 2007-07-30 17:07:14.0 +1000 > > +++ working-2.6/Documentation/powerpc/booting-without-of.txt > > 2007-07-30 17:07:14.0 +1000 > > @@ -1757,45 +1757,23 @@ platforms are moved over to use the flat > > }; > > }; > > > > -j) Flash chip nodes > > + j) CFI or JEDEC memory-mapped NOR flash > > > > Flash chips (Memory Technology Devices) are often used for solid state > > file systems on embedded devices. > > > > -Required properties: > > + - compatible : should contain the specific model of flash chip(s) used > > + followed by either "cfi-flash" or "jedec-flash" > > Duh, have nearly forgotten to complain about "-flash" suffix. Isn't it > superfluous? For CFI, I guess so. But don't JEDEC standardise other things as well as flash? I think "-flash" makes the description a bit more obvious, but I'll be swayed if a few other people chime in with opinions on this. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 04/10] 4xx bootwrapper reworks
On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
> Make the fixup_memsize function common for all of 4xx as several chips share
> the same SDRAM controller. Also add functions to reset 40x chips and quiesce
> the ethernet.
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
>
> ---
> arch/powerpc/boot/44x.h |4
> arch/powerpc/boot/4xx.c | 36 +++-
> arch/powerpc/boot/4xx.h | 20
> arch/powerpc/boot/dcr.h |2 ++
> arch/powerpc/boot/ebony.c |3 ++-
> 5 files changed, 55 insertions(+), 10 deletions(-)
>
> --- linux-2.6.orig/arch/powerpc/boot/44x.h
> +++ linux-2.6/arch/powerpc/boot/44x.h
> @@ -10,10 +10,6 @@
> #ifndef _PPC_BOOT_44X_H_
> #define _PPC_BOOT_44X_H_
>
> -void ibm44x_fixup_memsize(void);
> -void ibm4xx_fixup_ebc_ranges(const char *ebc);
> -
> -void ibm44x_dbcr_reset(void);
> void ebony_init(void *mac0, void *mac1);
>
> #endif /* _PPC_BOOT_44X_H_ */
> --- linux-2.6.orig/arch/powerpc/boot/4xx.c
> +++ linux-2.6/arch/powerpc/boot/4xx.c
> @@ -21,8 +21,8 @@
> #include "reg.h"
> #include "dcr.h"
>
> -/* Read the 44x memory controller to get size of system memory. */
> -void ibm44x_fixup_memsize(void)
> +/* Read the 4xx SDRAM controller to get size of system memory. */
> +void ibm4xx_fixup_memsize(void)
> {
> int i;
> unsigned long memsize, bank_config;
> @@ -39,22 +39,48 @@ void ibm44x_fixup_memsize(void)
> dt_fixup_memory(0, memsize);
> }
>
> -#define SPRN_DBCR0 0x134
> -#define DBCR0_RST_SYSTEM 0x3000
> +#define DBCR0_RST_SYSTEM 0x3000
Rather than just removing these defines and using hardcoded values,
I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
[snip]
> +#define EMAC_RESET 0x2000
> +#define MAL_RESET 0x8000
I think the MAL_RESET definition should go in the same place as the
DCR number definition.
> +void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1)
> +{
As I think I said before, I'm not really happy with this being
hardcoded assuming exactly 2 ethernets.
> + /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us
> */
> + if (emac0)
> + *emac0 = EMAC_RESET;
> + if (emac1)
> + *emac1 = EMAC_RESET;
> +
> + mtdcr(DCRN_MAL0_CFG, MAL_RESET);
> +}
[snip]
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 03/10] Rename 44x bootwrapper
On Fri, Aug 03, 2007 at 11:09:03AM -0500, Josh Boyer wrote: > Rename the 44x.c wrapper file to 4xx.c. This will allow us to add common > functions in a single file that can be shared across all of 4xx. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 07/10] Fix 40x build
On Fri, Aug 03, 2007 at 11:09:07AM -0500, Josh Boyer wrote: > Remove inclusion of __res on 40x. We don't need it in arch/powerpc > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 05/10] 40x MMU
On Fri, Aug 03, 2007 at 11:09:05AM -0500, Josh Boyer wrote: > Add MMU definitions for 40x platforms. Also fixes two warnings in 40x_mmu.c. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 10/10] Bamboo zImage wrapper
On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote: > Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a > common fixup_clock function for all 440EP(x) chips. Ok, you have a separate bamboo.c and treeboot-bamboo.c, like with ebony. However here, therer's only one outermost wrapper - treeboot-bamboo.c which means there's not really any point to this separation. Do you know if there are Bamboo boards with old u-boot versions, or some other bootloader which would make the separation worthwhile later? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 09/10] Bamboo board support
On Fri, Aug 03, 2007 at 11:09:09AM -0500, Josh Boyer wrote: > Add support for the AMCC Bamboo board > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: David Gibson <[EMAIL PROTECTED]> -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 08/10] Bamboo DTS
On Fri, Aug 03, 2007 at 11:09:08AM -0500, Josh Boyer wrote: > AMCC Bamboo board DTS All the compatible properties should have "-440ep" as the most precise version, in addition to the more general strings. > --- /dev/null > +++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts > @@ -0,0 +1,248 @@ > +/* > + * Device Tree Source for AMCC Bamboo > + * > + * Copyright (c) 2006, 2007 IBM Corp. > + * Josh Boyer <[EMAIL PROTECTED]> > + * > + * FIXME: Draft only! > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without > + * any warranty of any kind, whether express or implied. > + * > + * To build: > + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts > + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts Can we ditch this "to build" boilerplate. It's just another thing people frequently forget to update as they copy it from dts to dts. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Please pull powerpc.git merge branch
Hi, Paul, How about following patches? [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC architecture with ULI chip quirk functions. URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html [PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and MPC8544DS boards. URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html [PATCH 1/3] Add a new member name to structure irq_host URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html [PATCH 2/3] Add irq host name for all powerpc interrupt controllors. URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html [PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html Thanks! Best Regards, Zhang Wei > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > g] On Behalf Of Paul Mackerras > Sent: Friday, August 03, 2007 6:33 PM > To: [EMAIL PROTECTED] > Cc: linuxppc-dev@ozlabs.org > Subject: Please pull powerpc.git merge branch > > Linus, > > Please do > > git pull \ > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge > > to get another batch of bug-fixes for powerpc. > > Thanks, > Paul. > > arch/powerpc/kernel/entry_64.S|3 +++ > arch/powerpc/kernel/pci_32.c |5 - > arch/powerpc/kernel/smp.c |9 +++-- > arch/powerpc/mm/hash_low_64.S |6 -- > arch/powerpc/mm/hash_utils_64.c |2 +- > arch/powerpc/mm/numa.c|4 ++-- > arch/powerpc/mm/slb.c | 28 > ++-- > arch/powerpc/platforms/cell/spufs/sched.c |3 ++- > arch/powerpc/platforms/powermac/feature.c |6 -- > arch/powerpc/platforms/ps3/setup.c|2 +- > include/asm-powerpc/mmu-hash64.h |1 + > include/asm-powerpc/pgtable-64k.h |8 +++- > 12 files changed, 46 insertions(+), 31 deletions(-) > > Andre Detsch (1): > [POWERPC] spufs: Fix affinity after introduction of > node_allowed() calls > > Kevin Corry (1): > [POWERPC] Fix num_cpus calculation in smp_call_function_map() > > Michael Ellerman (1): > [POWERPC] Fix parse_drconf_memory() for 64-bit start addresses > > Michael Neuling (1): > [POWERPC] Fixes for the SLB shadow buffer code > > Paul Mackerras (2): > [POWERPC] Expand RPN field to 34 bits when using 64k pages > [POWERPC] Fix special PTE code for secondary hash bucket > > Segher Boessenkool (2): > [POWERPC] Fix a compile warning in pci_32.c > [POWERPC] Fix a compile warning in powermac/feature.c > > Stephen Rothwell (1): > [POWERPC] ps3: Fix section mismatch in ps3/setup.c > > ___ > 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
Re: [PATCH 1/3] powerpc clk.h interface for platforms
Hi!
Paul, what do you say about this?
Sylvain suggested it could also be integrated with define_machine
interface.
If it's OK, it would be cool if it got merged in next release cycle.
Domen
On 11/07/07 11:32 +0200, Domen Puncer wrote:
> clk interface for arch/powerpc, platforms should fill
> clk_functions.
>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
>
> ---
> arch/powerpc/kernel/Makefile|3 -
> arch/powerpc/kernel/clock.c | 82
>
> include/asm-powerpc/clk_interface.h | 20
> 3 files changed, 104 insertions(+), 1 deletion(-)
>
> Index: work-powerpc.git/arch/powerpc/kernel/clock.c
> ===
> --- /dev/null
> +++ work-powerpc.git/arch/powerpc/kernel/clock.c
> @@ -0,0 +1,82 @@
> +/*
> + * Dummy clk implementations for powerpc.
> + * These need to be overridden in platform code.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct clk_interface clk_functions;
> +
> +struct clk *clk_get(struct device *dev, const char *id)
> +{
> + if (clk_functions.clk_get)
> + return clk_functions.clk_get(dev, id);
> + return ERR_PTR(-ENOSYS);
> +}
> +EXPORT_SYMBOL(clk_get);
> +
> +void clk_put(struct clk *clk)
> +{
> + if (clk_functions.clk_put)
> + clk_functions.clk_put(clk);
> +}
> +EXPORT_SYMBOL(clk_put);
> +
> +int clk_enable(struct clk *clk)
> +{
> + if (clk_functions.clk_enable)
> + return clk_functions.clk_enable(clk);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_enable);
> +
> +void clk_disable(struct clk *clk)
> +{
> + if (clk_functions.clk_disable)
> + clk_functions.clk_disable(clk);
> +}
> +EXPORT_SYMBOL(clk_disable);
> +
> +unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (clk_functions.clk_get_rate)
> + return clk_functions.clk_get_rate(clk);
> + return 0;
> +}
> +EXPORT_SYMBOL(clk_get_rate);
> +
> +long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk_functions.clk_round_rate)
> + return clk_functions.clk_round_rate(clk, rate);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_round_rate);
> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk_functions.clk_set_rate)
> + return clk_functions.clk_set_rate(clk, rate);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_set_rate);
> +
> +struct clk *clk_get_parent(struct clk *clk)
> +{
> + if (clk_functions.clk_get_parent)
> + return clk_functions.clk_get_parent(clk);
> + return ERR_PTR(-ENOSYS);
> +}
> +EXPORT_SYMBOL(clk_get_parent);
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + if (clk_functions.clk_set_parent)
> + return clk_functions.clk_set_parent(clk, parent);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL(clk_set_parent);
> Index: work-powerpc.git/include/asm-powerpc/clk_interface.h
> ===
> --- /dev/null
> +++ work-powerpc.git/include/asm-powerpc/clk_interface.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASM_POWERPC_CLK_INTERFACE_H
> +#define __ASM_POWERPC_CLK_INTERFACE_H
> +
> +#include
> +
> +struct clk_interface {
> + struct clk* (*clk_get) (struct device *dev, const char *id);
> + int (*clk_enable) (struct clk *clk);
> + void(*clk_disable) (struct clk *clk);
> + unsigned long (*clk_get_rate) (struct clk *clk);
> + void(*clk_put) (struct clk *clk);
> + long(*clk_round_rate) (struct clk *clk, unsigned long rate);
> + int (*clk_set_rate) (struct clk *clk, unsigned long rate);
> + int (*clk_set_parent) (struct clk *clk, struct clk *parent);
> + struct clk* (*clk_get_parent) (struct clk *clk);
> +};
> +
> +extern struct clk_interface clk_functions;
> +
> +#endif /* __ASM_POWERPC_CLK_INTERFACE_H */
> Index: work-powerpc.git/arch/powerpc/kernel/Makefile
> ===
> --- work-powerpc.git.orig/arch/powerpc/kernel/Makefile
> +++ work-powerpc.git/arch/powerpc/kernel/Makefile
> @@ -12,7 +12,8 @@ endif
>
> obj-y:= semaphore.o cputable.o ptrace.o
> syscalls.o \
> irq.o align.o signal_32.o pmc.o vdso.o \
> -init_task.o process.o systbl.o idle.o
> +init_task.o process.o systbl.o idle.o \
> +clock.o
> obj-y+= vdso32/
> obj-$(CONFIG_PPC64) += setup_64.o binfmt_elf32.o sys_ppc32.o \
> signal_64.o ptrace32.o \
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
__
