Hi, Segher,
> -Original Message-
> From: Segher Boessenkool [mailto:[EMAIL PROTECTED]
>
> > + [EMAIL PROTECTED]
> > + compatible = "fsl,mpc8xxx-dma";
>
> Please use a real name, not this "xxx" stuff.
Does the "xxx" seems to be an evil name? :-)
>
> > +
> > + [EMAIL PROTECTED]
>
> "dma-controller" btw. And a space before the "{" (here and
> elsewhere) :-)
All right! :-)
Wei.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
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!
Wei.
> -Original Message-
> Subject: Re: [PATCH 3/4] Extend t
From: Roy Zang <[EMAIL PROTECTED]>
This patch adds cuboot support for MPC7448HPC2 platform.
The cuImage can be used with legacy u-boot without FDT support.
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
Regenerate this patch based on current Paul's tree.
The original one was pasted at:
http://oz
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
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
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 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 +
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
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
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]
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 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 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 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 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, 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
>>> + 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
>>> 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 */
>>
> 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
>>> +- 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
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.
> >
> >
>>> + [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 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
>>> +- 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
>> 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
> 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
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
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
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
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/
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
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 +-
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
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
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
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
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
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
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 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 */
> >
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
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
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
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
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
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
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
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
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
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
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 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
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
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 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 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
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
> + 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
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
>>> 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
>>> 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
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
>>> 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
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
>>> + 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
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
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
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
> 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
>> 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
>>> 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
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
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
>>> 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:
>> 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
_
> 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
>>> 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
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
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
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 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 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, 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, 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 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
> 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
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
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
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
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
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
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,
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 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:
> 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 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:
> 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
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
1 - 100 of 104 matches
Mail list logo
