On 11/07/07 19:06 +0100, Matt Sealey wrote:
> Does anyone have the definitive patchset to enable the tickless hz,
> some kind of hrtimer and the other related improvements in the
> PowerPC tree?
I use attached patches for tickless.
Order in which they're applied:
PowerPC_GENERIC_CLOCKEVENTS.patch
On Wed, Jul 11, 2007 at 11:15:16PM +0100, Matt Sealey wrote:
> And I don't want to run -rt or wireless-dev for the benefit of a single
> feature. What I am after is something like Ingo Molnar throws out..
> single patches done the old way, not git trees. It's so much easier to
> handle and integr
Hi, Dan,
Thanks! I get it.
It's so lucky we have the same target.
When your patch could be accepted?
Cheers,
Wei.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams
> Sent: Thursday, July 12, 2007 12:57 AM
> To: Zhang Wei-r63237
> Cc: [
Commit 6a281856c02d2291df2f7d9df5bfdee2e7bdd747 modified of_detach_node
so that it now sets a flag in the passed device_node. Remove the const
from the parameter to get rid of this warning:
arch/powerpc/kernel/prom.c: In function 'of_detach_node':
arch/powerpc/kernel/prom.c:1468: warning: passing
Hi,
You could call *io_block_mapping* function from your setup.c file that will
add the entry into MMU.
regards
Bhupi
On 7/11/07, Nicolas Mederle <[EMAIL PROTECTED]> wrote:
Hi,
I am porting linux on a custom board equipped with a PPC750, and I
will like to have some advices on the MMU
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> Add a helper routine to map dcr's based on the "dcr-reg" property of
> a device node.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/dcr.c | 1
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can
> save them the trouble and do it in dcr_read()/dcr_write().
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL P
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> This requires us to do a sort-of fake dcr_map(), so that base is set
> properly. This will be fixed/removed when the device-tree-aware emac driver
> is merged.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin H
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> Now that dcr_host_t contains the base address, we can use that in the mpic
> code, rather than storing it separately.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
On Fri, 2007-06-22 at 16:18 +1000, Michael Ellerman wrote:
> In its current form, dcr_map() doesn't remember the base address you passed
> it, which means you need to store it somewhere else. Rather than adding the
> base to another struct it seems simpler to store it in the dcr_host_t.
>
> Signed
On Wed, Jul 11, 2007 at 10:33:51PM +0200, Arnd Bergmann wrote:
> On Wednesday 11 July 2007, Mark A. Greer wrote:
>
> > > +config CLASSIC32
> > > + def_bool y
> > > + depends on 6xx && PPC_MULTIPLATFORM
> >
> > Arnd, is this really what you wanted? With it,
In message <[EMAIL PROTECTED]> you wrote:
> On Wednesday 11 July 2007, Benjamin Herrenschmidt wrote:
> > There are two possibly solutions I see in the long run:
> > =
>
> > =A0- We could set the FW features earlier on pseries, though that is a bit
> > annoying because that means doing it before
Okay.
What I didn't want to do is spend a day sifting some other development
tree picking out what I think might be possibly sort of the right patches
for it.
I'd get it wrong because having not worked on it, I don't know what I am
even looking for.
And I don't want to run -rt or wireless-dev fo
From: Jon Loeliger <[EMAIL PROTECTED]>
out of the kernel's Documentation/powerpc/booting-without-of.txt.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
Documentation/manual.txt | 493 ++
1 files changed, 493 insertions(+), 0 deletions(-)
create
From: Jon Loeliger <[EMAIL PROTECTED]>
and its formats, command lines, descriptions, etc,
over to the Device Tree Compiler repositories now.
A corresponding patch adding these sections to the DTC
repository has been submitted to that repository as well.
Signed-off-by: Jon Loeliger <[EMAIL PROTEC
Folks,
Here are two patches, one to the kernel, the other to
the DTC repo, that moves the technical description
portions of the booting-without-of.txt documentation
out of the kernel and into the DTC repository.
Thanks,
jdl
___
Linuxppc-dev mailing li
> Which systems in particular should allow CONFIG_TAU? Is there a more
> specific dependency than (6xx && !(82xx || 83xx || 86xx || 52xx))?
7xx and 7xxx CPUs (G3 and G4). Nothing earlier (according to
the IEEE article introducing the TAU), maybe some later units
have it though (but I think they h
On Wed, 2007-07-11 at 22:56 +0200, Arnd Bergmann wrote:
> On Wednesday 11 July 2007, Josh Boyer wrote:
> > +#elif defined(CONFIG_40x)
> > +/* 40x-style software loaded TLB */
> > +# include
> > #elif defined(CONFIG_44x)
> > /* 44x-style software loaded TLB */
> > # include
>
> If you call i
On Wednesday 11 July 2007, Josh Boyer wrote:
> -#if defined(CONFIG_8xx) || defined(CONFIG_40x)
> +#if defined(CONFIG_8xx)
> EXPORT_SYMBOL(__res);
> #endif
Actually, __res also isn't defined on 8xx, so the export
should probably go away entirely.
Arnd <><
__
On Wednesday 11 July 2007, Josh Boyer wrote:
> +#elif defined(CONFIG_40x)
> +/* 40x-style software loaded TLB */
> +# include
> #elif defined(CONFIG_44x)
> /* 44x-style software loaded TLB */
> # include
If you call it mmu-4xx, shouldn't it be used
for 44x as well? I would think this either
On Wednesday 11 July 2007, Russell King wrote:
>
> IOW, talk to me and I'll talk back. Ignore me and I'll ignore them.
Exactly why I cc'd you ... if folk want any more sharable
cross-platform code than just the clk.h interface, I expect
you'll have useful comments.
- Dave
__
On Wednesday 11 July 2007, Mark A. Greer wrote:
> > +config CLASSIC32
> > + def_bool y
> > + depends on 6xx && PPC_MULTIPLATFORM
>
> Arnd, is this really what you wanted? With it, none of the embedded
> classics have CLASSIC32 defined which means they
On Tue, Jul 10, 2007 at 04:33:48PM -0500, Maynard Johnson wrote:
> Will Schmidt wrote:
>
> > On Tue, 2007-07-10 at 15:31 -0500, Michael Neuling wrote:
> >
> Does it make more sense to call this "ppc64/power5+rev3"?
>
> >>>
> >>>This is a change to support new counter setup for oprofi
On Wed, Jul 11, 2007 at 10:02:54AM -0700, David Brownell wrote:
> On Wednesday 11 July 2007, Christoph Hellwig wrote:
> > On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > > > Umm, this is about the fifth almost identical implementation of
> > > > the clk_ functions. Please, plea
Hi Joachim-
Joachim Fenkes wrote:
>
> idr_init(), when called for the first time, sets up the layer
> cache. idr_get_new() and friends expect the cache to exist. Now, what happens
> if the first call to idr_get_new() targets an idr initialized using
> DEFINE_IDR() before idr_init() has been called
>>> What if the mem-to-mem channels were explicitly labelled
>>> fsl,mpc8548-dma-mem-to-mem?
>> Why would you? Why would you put _any_ compatible property in
>> the individual channels, even; they aren't separate devices
>> after all.
>
> They should be. :-)
But they're not, no amount of wishi
> With this patch, idr.c should work as advertised allocating id
> values in the range 0...0x7fff. Andrew had speculated that
> it should allow the full range 0...0x to be used. I was
> tempted to make changes to allow this, but it would require changes
> to API, e.g. making the start
Segher Boessenkool wrote:
>> What if the mem-to-mem channels were explicitly labelled
>> fsl,mpc8548-dma-mem-to-mem?
>
>
> Why would you? Why would you put _any_ compatible property in
> the individual channels, even; they aren't separate devices
> after all.
They should be. :-)
-Scott
_
>>> that if we really wanted to we could describe as a
>>> second reg resource in each channel, combined with a channel-ID
>>> property.
>> You cannot describe one register in two different nodes.
>
> Why not? It's read-only.
Because a register belongs to one, and only one, device
node. There
Segher Boessenkool wrote:
>> that if we really wanted to we could describe as a
>> second reg resource in each channel, combined with a channel-ID
>> property.
>
>
> You cannot describe one register in two different nodes.
Why not? It's read-only.
>> I'm not inclined to bother, though -- not
Hello.
Vitaly Bordug wrote:
>>>+
>>>+#ifdef CONFIG_MPC834x_ITX
>>Erm, isn't this stuff misplaced? Is this really SoC device? I
>>remember seeng this in the arch/ppc/ platform code before (in the
>>internal tree)...
> The point is to declare methods bsp, as mmio access may effectively vary
>>> Indentify pci, pcie host by compatible property
>>> "fsl,mpc83xx-pci","83xx"
>>> "fsl,mpc85xx-pci","85xx"
>>> "fsl,mpc86xx-pci","86xx"
>>> and
>>> "fsl, mpc85xx-pciex","85xx"
>>> "fsl, mpc86xx-pciex","86xx"
>>
>> This can't ever work --
> It works!
How can any driver match for "85xx" if two co
>> The generic DMA driver can look at the device tree, too. It's more
>> convenient to only have to look at the dma-controller node, true.
>> But with the proposed tree you have to look at all the channel nodes
>> already.
>
> But if the only way to tell is a phandle from the sound device, it has
> Does anyone have the definitive patchset to enable the tickless hz,
> some kind of hrtimer and the other related improvements in the PowerPC
> tree?
Tony Breeds has been looking at this. I think he wanted to clean his
patch set up before he posted it.
Mikey
Hi all,
while the idr discussion is still hot, there's another thing that caught my
eye recently:
As to my reading of idr.h, I have two choices of initializing a global idr:
a) static struct idr foo; /* ... */ idr_init(&foo);
b) static DEFINE_IDR(foo);
idr_init(), when called for the first tim
Segher Boessenkool wrote:
> The generic DMA driver can look at the device tree, too. It's more
> convenient to only have to look at the dma-controller node, true.
> But with the proposed tree you have to look at all the channel nodes
> already.
But if the only way to tell is a phandle from the so
Hello.
Matt Sealey wrote:
> Does anyone have the definitive patchset to enable the tickless hz,
> some kind of hrtimer and the other related improvements in the
> PowerPC tree?
Look into the -rt patch which has the all this (minus TOD vsyscalls).
MBR, Sergei
>>> + plb {
>>> + ranges;
>>
>> Please make the valid address ranges explicit here.
>
> Meaning what exactly? I thought just specifying "ranges;" simply said
> "the addresses from this node don't have any translation from the
> parent
> node" (or something like that).
Just list the
Does anyone have the definitive patchset to enable the tickless hz,
some kind of hrtimer and the other related improvements in the
PowerPC tree?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
___
Linuxppc-dev mailing list
Linuxp
>>> Some hardware has DMA channels hardwired to certain peripherals,
>>> such as
>>> an audio codec. This keeps them from being used as general
>>> purpose DMA
>>> channels.
>> I think you need this knowledge in the kernel drivers anyway,
>> or at the very least, the device node for for exam
On Wed, 2007-07-11 at 19:49 +0200, Segher Boessenkool wrote:
> > + UIC0: interrupt-controller0 {
>
> Why not just "interrupt-controller"?
Copy/paste error from Ebony DTS, which has multiple UICs. Will fix.
>
> > + #address-cells = <0>;
> > + #size-cells = <0>;
>
> No nee
>>> I'd rather just treat the different DMA channels as independent
>>> devices,
>>> rather than children of a dma "bus", and change the compatible
>>> name if
>>> they're not general purpose. There's only one register that's
>>> shared
>>> among the channels, and it's a superfluous status s
>>> Fix mpc7448hpc2 tsi108 device_type bug.
>>> Wrong device type will break the board startup.
>>
>>> - device_type = "tsi108-bridge";
>>> + device_type = "tsi-bridge";
>>
>> The OS code shouldn't use "device_type" at all for this,
>> but "compatible" instead. You might wa
On Wed, 2007-07-11 at 09:32 -0700, Bhupender Saharan wrote:
> Hi,
>
> You could call io_block_mapping function from your setup.c file that
> will add the entry into MMU.
io_block_mapping doesn't exist in the arch/powerpc tree.
josh
___
Linuxppc-dev
> + UIC0: interrupt-controller0 {
Why not just "interrupt-controller"?
> + #address-cells = <0>;
> + #size-cells = <0>;
No need for these.
>
> + plb {
> + ranges;
Please make the valid address ranges explicit here.
> + SDRAM0: memory-cont
Creating platform devices (memory controller, sram error registers, cpu error
registers, PCI error registers) for Error Detection and Correction (EDAC)
driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from the
memory controller (ECC erorrs), SRAM controller, CPU data pat
On Wednesday 11 July 2007, Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > > Umm, this is about the fifth almost identical implementation of
> > > the clk_ functions. Please, please put it into common code.
> > >
> > > And talk to the mips folks whic
On 7/11/07, Zhang Wei-r63237 <[EMAIL PROTECTED]> wrote:
> Hi, Dan,
>
> Do you mention here: http://marc.info/?l=linux-raid&m=118290909614463&w=2 ?
> I see the async_tx is located at crypto/ of the above page, but my patch is
> for DMA engine in drivers/dma and for DMA engine driver.
>
> Thanks!
>
On Tue, Jul 10, 2007 at 05:45:26PM +0800, Zhang Wei wrote:
> +config FSL_DMA
> + bool "Freescale MPC8xxx DMA support"
> + depends on DMA_ENGINE && (PPC_86xx || PPC_85xx)
Remove the dependency on specific PPC chips... let the device tree say
whether the hardware is present.
> +static inli
On Wed, Jul 11, 2007 at 08:56:58AM -0700, David Brownell wrote:
> > Umm, this is about the fifth almost identical implementation of
> > the clk_ functions. Please, please put it into common code.
> >
> > And talk to the mips folks which just got a similar comment from me.
>
> You mean like a lib
On Wednesday 11 July 2007, Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 11:32:20AM +0200, Domen Puncer wrote:
> > clk interface for arch/powerpc, platforms should fill
> > clk_functions.
>
> Umm, this is about the fifth almost identical implementation of
> the clk_ functions. Please, please
Hi Vitaly,
What's the status of this patch? I didn't see any update since my
review on May 10th. It's too late for 2.6.23 already.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Nicolas,
On Wednesday 11 July 2007 17:39, Nicolas Mederle wrote:
> Hi,
>
> I am porting linux on a custom board equipped with a PPC750, and I
> will like to have some advices on the MMU. I used the powerpc arch, and
> I built my device tree.
> I will like to know in which files we can c
Hi,
I am porting linux on a custom board equipped with a PPC750, and I
will like to have some advices on the MMU. I used the powerpc arch, and
I built my device tree.
I will like to know in which files we can configure the
authorizations access for the I/O registers. When I use the func
On Sat, Jun 16, 2007 at 02:05:12AM +0200, [EMAIL PROTECTED] wrote:
> The cores used in the MPC82xx/83xx/86xx embedded controllers are very similar
> to those in the 32 bit general-purpose processors, so it makes sense to
> treat them as the same CPU family.
>
> Choosing between the embedded platfo
Segher Boessenkool wrote:
>> Actually I see no good reason to enforce no-exec at all if we can't do
>> it consistently. And if we're not going to enforce it then there is
>> no point whinging about it.
>
>
> I have a new patch with just this behaviour, Scott is
> testing it on old glibc (I think
Segher Boessenkool wrote:
>> Some hardware has DMA channels hardwired to certain peripherals, such as
>> an audio codec. This keeps them from being used as general purpose DMA
>> channels.
>
>
> I think you need this knowledge in the kernel drivers anyway,
> or at the very least, the device no
Zhang Wei-r63237 wrote:
>>Or don't call it anything. The ability to do extended chain mode is
>>implicit in being compatible with fsl,mpc8548-dma.
>
>
> The basic mode could be used for mpc83xx silicons.
Yes, and the 83xx device trees will list the compatible as
fsl,mpc8349-dma, not fsl,mpc854
On Wed, 2007-07-11 at 19:55, Segher Boessenkool wrote:
> > Fix mpc7448hpc2 tsi108 device_type bug.
> > Wrong device type will break the board startup.
>
> > - device_type = "tsi108-bridge";
> > + device_type = "tsi-bridge";
>
> The OS code shouldn't use "device_type" at al
LRO support for eHEA
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |9 +++-
drivers/net/ehea/ehea_main.c | 102 +++---
2 files changed, 104 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/driver
Kconfig and Makefile changes for LRO
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
net/ipv4/Kconfig |9 +
net/ipv4/Makefile |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 010fbb2..25279f4 100644
--- a/net
Large Receive Offload (tcp)
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
include/linux/inet_lro.h | 107
net/ipv4/inet_lro.c | 311 ++
2 files changed, 418 insertions(+), 0 deletions(-)
create mode 100644 include/lin
Generic Large Receive Offload proposal
After some discussions on the mailing list concerning our LRO approach,
we agreed to provide a generic LRO patch. The algorithm is based on
the version we developed for eHEA. The performance improvements we
observed were significant.
The LRO functionality is
On Wed, 2007-07-11 at 16:26 +0200, Stefan Roese wrote:
> On Wednesday 11 July 2007, Josh Boyer wrote:
> > + PowerPC,[EMAIL PROTECTED] {
> > + device_type = "cpu";
> > + reg = <0>;
> > + clock-frequency = ; /* Filled in by zImage */
> >
This patch adds support for DLPAR memory add to the eHEA driver. To detect
whether memory was added the driver uses its own memory mapping table and
checks for kernel addresses whether they're located in already known memory
sections. If not the function ehea_rereg_mrs() is triggered which performs
On Wednesday 11 July 2007, Josh Boyer wrote:
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = ; /* Filled in by zImage */
> + timebase-frequency = <0>; /* Filled
Board support for the PPC405 Walnut evaluation board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/4xx/Kconfig | 14 +++
arch/powerpc/platforms/4xx/Makefile |2 -
arch/powerpc/platforms/4xx/walnut.c | 68
arch/powerpc/p
Apparently I can't count, so here's one more patch.
Add zImage wrapper for walnut board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |3 -
arch/powerpc/boot/treeboot-walnut.c | 92
2 files changed, 94 insertions
Walnut board defconfig
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/configs/walnut_defconfig | 776 ++
1 file changed, 776 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/configs/walnut_defconfig
@@ -0,0 +1,776 @@
+#
+# Automatically gen
Device tree source file for the PPC405 Walnut evaluation board.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/walnut.dts | 113 +++
1 file changed, 113 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -0
Remove inclusion of __res on 40x. We don't need it in arch/powerpc
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_4xx.S |1 -
arch/powerpc/kernel/ppc_ksyms.c |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/kernel/ppc_k
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.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/time.c |2 +-
Add MMU definitions for 40x platforms. Also fixes two warnings in 4xx_mmu.c.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/mm/4xx_mmu.c |4 +-
include/asm-powerpc/mmu-4xx.h | 65 ++
include/asm-powerpc/mmu.h |3 +
3 file
Rename the 44x.c wrapper file to 4xx.c and make the fixup_memsize function
common for all of 4xx. Also adds a common function to reset ethernet and a
40x reset function.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.c| 85 --
arch/
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/4xx/Kconfig | 77 -
arch/powerpc/platforms/Kconfig.cputype |1
2 files chang
For those interested, here's my current patch set to get PPC405 support
working in arch/powerpc.
Patches 1, 2, 3, 4, and 5 are probably ready to merge whenever. The
patches specific to Walnut need some more work before I would consider
those remotely usable. However, you can use them to build a
On Wed, 2007-07-11 at 12:33 +0200, Christoph Hellwig wrote:
>
> mm_context_id_t isn't actually used anywhere but in te mm_context_t
> definition. So if you kill it you have two common fields and a bunch
> of additional ones for PPC64 leading to a defintion like:
>
> typedef struct {
> unsi
> Fix mpc7448hpc2 tsi108 device_type bug.
> Wrong device type will break the board startup.
> - device_type = "tsi108-bridge";
> + device_type = "tsi-bridge";
The OS code shouldn't use "device_type" at all for this,
but "compatible" instead. You might want to fix that.
Th
>> d) preload some SLB entries at very early boot to cover
>> the first 4GB or so.
>>
>> d) sounds nice and simple, but will it work?
>
> Nah, best to limit everything at boot to SLB 0. Thing is, 4G is not
> enough, you may have more RAM and have allocations from the top.
Yeah fair enough. Yo
>>> +- extended : Set the DMA channel to work at extended
>> chain mode.
>>> + If not set, the DMA channel will work at basic
>>> + chain mode.
>>
>> Call it "extended-chain-mode", perhaps?
>
> Is it maybe too long?
Not really no. It's only 19 characters, and i
On Wednesday 11 July 2007, Benjamin Herrenschmidt wrote:
> There are two possibly solutions I see in the long run:
>
> - We could set the FW features earlier on pseries, though that is a bit
> annoying because that means doing it before the device-tree is
> unflattened.
>
> - We could constrain
>>> + [EMAIL PROTECTED]
>>> + compatible = "fsl,mpc8xxx-dma";
>>
>> Please use a real name, not this "xxx" stuff.
>
> Does the "xxx" seems to be an evil name? :-)
You are stating this particular device is compatible to
the "mpc8xxx-dma" device, which doesn't exist. If
On Wed, 2007-07-11 at 13:06 +0200, Segher Boessenkool wrote:
> > There are two possibly solutions I see in the long run:
> >
> > - We could set the FW features earlier on pseries, though that is
> > a bit
> > annoying because that means doing it before the device-tree is
> > unflattened.
> >
> >
>>> +- compatible : Should be "fsl,mpc8xxx-dma"
>>
>> Should _include_, not should _be_. And none of this xxx
>> business, of course.
>
> Especially since the 85xx/86xx version is not 100% compatible with the
> 83xx version. How about fsl,mpc8349-dma and fsl,mpc8548-dma for
> the two
> vari
> There are two possibly solutions I see in the long run:
>
> - We could set the FW features earlier on pseries, though that is
> a bit
> annoying because that means doing it before the device-tree is
> unflattened.
>
> - We could constraint lmb_alloc to the first segment until the FW
> fixup
>>> pci1: [EMAIL PROTECTED] {
>>> interrupt-map-mask = <1f800 0 0 7>;
>>
>> Set the mask to <1800 0 0 7>, and you need only 16
>> entries to encode the swizzle. Except...
>>
>>> + /* bus 1 , idsel 0x2 Tsi310 bridge
>> secondary */
>>
>>> + compatible = "fsl,mpc86xx-pciex","86xx";
>>
>> And "xx" again. Aren't the 85- and 86- PCIe controllers
>> compatible, btw?
>
> They are, but we need to distinguish between 83xx, 85xx, and 86xx
> pci, pciex, pci-x controllers.
Sure, but if 85xx-pcie and 86xx-pcie are comp
On Sat, 07 Jul 2007 20:46:46 +0400
Sergei Shtylyov wrote:
> > +
> > +#ifdef CONFIG_MPC834x_ITX
>
> Erm, isn't this stuff misplaced? Is this really SoC device? I
> remember seeng this in the arch/ppc/ platform code before (in the
> internal tree)...
The point is to declare methods bsp, as m
On Sat, 7 Jul 2007 21:13:06 +0100
Alan Cox wrote:
> On Sat, 07 Jul 2007 13:48:52 +0400
> Vitaly Bordug <[EMAIL PROTECTED]> wrote:
>
> >
> > This adds support for MMIO IDE device like CompactFlash
> > in TrueIDE mode.
>
> Really we should be working towards libata support for all new
> devices.
On Sat, 7 Jul 2007 10:01:47 -0500
Olof Johansson wrote:
> On Sat, Jul 07, 2007 at 01:48:52PM +0400, Vitaly Bordug wrote:
> >
> > This adds support for MMIO IDE device like CompactFlash
> > in TrueIDE mode.
>
> Doesn't this duplicate most of pata_platform, but as the
> no-longer-preferred legac
On Wed, Jul 11, 2007 at 11:32:20AM +0200, Domen Puncer wrote:
> clk interface for arch/powerpc, platforms should fill
> clk_functions.
Umm, this is about the fifth almost identical implementation of
the clk_ functions. Please, please put it into common code.
And talk to the mips folks which just
On Tue, Jul 10, 2007 at 10:01:49AM -0500, Josh Boyer wrote:
> +
> +#ifdef CONFIG_PPC64
> +typedef unsigned long mm_context_id_t;
> +
> +typedef struct {
> + mm_context_id_t id;
> + u16 user_psize; /* page size index */
> +
> +#ifdef CONFIG_PPC_MM_SLICES
> + u64 low_slices_psize;
On Fri, 2007-06-08 at 14:00 +1000, Michael Neuling wrote:
> On pSeries the firmware features are not setup until ppc_md.init_early,
> so we can't do the firmware feature sections fixups till after this.
>
> Currently firmware feature sections is only used on iSeries which inits
> the firmware feat
On Wed, 11 Jul 2007 10:45:35 +0800, Albert Lee wrote:
> Mikael Pettersson wrote:
> >
> >
> > 2.6.22 + this prints the following on my G3:
> >
> > pata_pdc2027x :00:0e.0: version 0.9
> > usec_elapsed for mdelay(37) [35431]
> > start time: [1184112028]s [775333]us
> > end time: [1184112028]
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:[EMAIL PROTECTED]
>
> > + k) DMA
> > +
> > + This sector define DMA for dma-engine driver of Freescale
>
> It's called a "device node" or "node", not a "sector".
Ok, "node".
>
> > +- compatible : Should be "fsl,mpc8
Hi,
> -Original Message-
> From: Wood Scott-B07421
>
> On Tue, Jul 10, 2007 at 04:01:19PM +0200, Segher Boessenkool wrote:
> > > +- compatible : Should be "fsl,mpc8xxx-dma"
> >
> > Should _include_, not should _be_. And none of this xxx
> > business, of course.
>
> Especially sin
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 +
Use clocks subsystem in spi driver.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
drivers/spi/mpc52xx_psc_spi.c | 64 +-
1 file changed, 57 insertions(+), 7 deletions(-)
Index: work-powerpc.git/drivers/spi/mpc52xx_psc_spi.c
==
clk.h interface for mpc52xx
Currently only psc_mclks are defined.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/52xx/Makefile |2
arch/powerpc/platforms/52xx/mpc52xx_clock.c | 352 +++
arch/powerpc/platforms/52xx/mpc52xx_common
Hi!
Clock managing in mpc52xx psc spi driver grew a bit, to do it
"the right way" ;-)
1/3 - Generic powerpc clock interface, platforms that implement
it should fill clk_functions.
This is needed because powerpc supports multiple platforms
in same kernel image.
2/3 - psc spi cloc
1 - 100 of 104 matches
Mail list logo
