* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-07-18 1:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <b1bc50e84cd3f8009eca2b470bea026f@kernel.crashing.org>
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is at:
> > http://ozlabs.org/~dgibson/home/prep-support
>
> Too lazy to split the patch into bite-size chunks, you mean ;-)
Well... much as I like small patches, I don't really like having a big
string of patches, each of which does basically nothing on its own,
i.e. split up just for the sake of making smaller, rather than into
separate logically separate changes.
> Anyway, here goes the DTS bits:
>
> +/*
> + * PReP skeleton device tree
> + *
> + * Paul Mackerras <paulus@samba.org>
> + */
> +
> +/ {
> + device_type = "prep";
> + model = "IBM,PReP";
>
> Not specific enough, leave it out or fill it in in the bootwrapper.
Yeah, I should fill that in with the string from the residual data.
Haven't gotten around to it.
> + compatible = "prep";
>
> Maybe fill this in, too.
>
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
>
> Do all (supported) PReP boards have one CPU only?
Well, depends what you mean by "supported", really. My arch/powerpc
port only support UP boards so far... I realise this will need to
change at some point.
>
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; // filled in by bootwrapper
> + bus-frequency = <0>; // filled in by bootwrapper
> + timebase-frequency = <0>; // filled in by bootwrapper
> + i-cache-line-size = <0>; // filled in by bootwrapper
> + d-cache-line-size = <0>; // filled in by bootwrapper
> + d-cache-size = <0>; // filled in by bootwrapper
> + i-cache-size = <0>; // filled in by bootwrapper
> + external-control;
>
> Really?
No idea, just copied that from earlier work of Paulus'. Don't even
know what the property means.
> + graphics;
> + performance-monitor;
> +
> + l2-cache {
> + device_type = "cache";
> + i-cache-size = <00100000>;
> + d-cache-size = <00100000>;
> + i-cache-sets = <00008000>;
> + d-cache-sets = <00008000>;
> + i-cache-line-size = <00000020>;
> + d-cache-line-size = <00000020>;
>
> Drop the leading zeroes, they make my head spin :-)
>
> + cache-unified;
> + };
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + // dummy range here, zImage wrapper will fill in the actual
> + // amount of memory from the residual data
> + reg = <00000000 00000000>;
> + };
> +
> + pci@80000000 {
> + device_type = "pci";
> + compatible = "prep";
>
> Is that specific enough?
Well, AFAICT, the prep PCI code doesn't need any more info.
> + clock-frequency = <01fca055>;
> + reg = <80000000 7effffff>;
> + 8259-interrupt-acknowledge = <bffffff0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges=<01000000 00000000 00000000 80000000 00000000 00800000
> + 01000000 00000000 00800000 81000000 00000000 3e800000
> + 02000000 00000000 00000000 c0000000 00000000 01000000
> + 02000000 00000000 01000000 c1000000 00000000 3e000000>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <6000 0 0 1 &MPIC 6 0
> + 8000 0 0 1 &MPIC 7 0
> + 9000 0 0 1 &MPIC 2 0
> + b000 0 0 1 &MPIC 1 0>;
>
> I can't believe this "ranges" and interrupt mapping will
> work on all PReP systems...
Probably not, but it should work on a chunk of them. Like I say,
there's still a good deal more that needs to be filled in from
residual data or wherever.
> + isa {
> + device_type = "isa";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + ranges = <00000001 00000000
> + 01005800 00000000 00000000 00010000
> + 00000000 00000000
> + 02005800 00000000 00000000 01000000>;
> +
> + parallel {
> + device_type = "parallel";
> + compatible = "ecp", "pnpPNP,400";
>
> "pnpPNP,401", "pnpPNP,400"
>
> + reg = <00000001 000003bc 00000008
> + 00000001 000007bc 00000006>;
> + interrupts = <00000007 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> +
> + serial@3f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501";
>
> "pnpPNP,501", "pnpPNP,500" I'd say. Many/some device
> tree users will only care it is _some_ 8250 family thing.
>
> + clock-frequency = <001c2000>;
> + reg = <00000001 000003f8 00000008>;
> + interrupts = <00000004 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> + serial@2f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501";
> + clock-frequency = <001c2000>;
> + reg = <00000001 000002f8 00000008>;
> + interrupts = <00000003 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> + PIC8259: interrupt-controller {
> + device_type = "i8259";
>
> device_type = "interrupt-controller".
>
> + compatible = "prep,iic";
> + reg = < 00000001 00000020 00000002
> + 00000001 000000a0 00000002
> + 00000001 000004d0 00000002>;
> + interrupts = <00000000 00000003
> + 00000002 00000003>;
> + interrupt-parent = <&MPIC>;
> + };
> + };
> +
> + MPIC: interrupt-controller@d {
> + device_type = "open-pic";
>
> device_type = "interrupt-controller".
>
> + compatible = "mpic";
> + reg = < 00006800 00000000 00000000 00000000 00000000
> + 02006810 00000000 00000000 00000000 00040000>;
> + assigned-addresses = <
> + 82006810 00000000 3afc0000 00000000 00040000>;
> + };
> + };
> +
> + chosen {
> + linux,stdout-path = "/pci/isa/serial@3f8";
> + };
> +};
>
> What is the plan here -- have the bootwrapper build the
> device tree / fill in the details from the residual data?
Not sure at this stage if it will be best for the bootwrapper to build
a complete tree from residual, or to have a dts skeleton with
substantial chunks filled in by bootwrapper from residual. I was
intending to merge libfdt into the kernel for more flexible device
tree manipulation before investigating that further.
--
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
^ permalink raw reply
* - add-missing-data_data-in-powerpc.patch removed from -mm tree
From: akpm @ 2007-07-17 23:09 UTC (permalink / raw)
To: mathieu.desnoyers, linuxppc-dev, paulus, mm-commits
The patch titled
powerpc: add missing DATA_DATA
has been removed from the -mm tree. Its filename was
add-missing-data_data-in-powerpc.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
Subject: powerpc: add missing DATA_DATA
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: <paulus@samba.org>
Cc: <linuxppc-dev@ozlabs.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
diff -puN arch/powerpc/kernel/vmlinux.lds.S~add-missing-data_data-in-powerpc arch/powerpc/kernel/vmlinux.lds.S
--- a/arch/powerpc/kernel/vmlinux.lds.S~add-missing-data_data-in-powerpc
+++ a/arch/powerpc/kernel/vmlinux.lds.S
@@ -174,7 +174,9 @@ SECTIONS
}
#else
.data : {
- *(.data .data.rel* .toc1)
+ DATA_DATA
+ *(.data.rel*)
+ *(.toc1)
*(.branch_lt)
}
_
Patches currently in -mm which might be from mathieu.desnoyers@polymtl.ca are
origin.patch
git-kbuild.patch
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-17 22:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <20070717222507.GA4682@ld0162-tx32.am.freescale.net>
> It could lead someone to the erroneous conclusion that an #address-cells
> other than zero in an interrupt controller that is not a device parent is
> in any way a sane or supported thing to do.
I fail why anyone would ever want to do it though :-)
> It could lead people to write code that doesn't handle the absence of
> #address-cells in such a node properly.
We just need to make mention that it can be absent in the spec, there
shouldn't be that many parsers out there.
> It could lead to flamewars. :-)
Yeah well.
> If there's only one value that could possibly make sense, it *not* being
> the default is crap.
Only for leaf nodes. Other values do make sense for non-leaf nodes.
> The obvious way (which indeed isn't what the suggested algorithm does --
> but the suggested algorithm doesn't do anything sensible) is that if you
> got to the node via an interrupt-parent or interrupt-map, it doesn't use
> #address-cells, and if you got to it by going to the regular device tree
> parent, it does.
Yeah well, that's also somewhat debatable too. You need a #address-cells
to be able to parse an interrupt-map. You can imagine cross-links and
special maps used to handle things like the multiple UICs as David did
in the past. I wouldn't get rid of that flexibility to handle corner
cases that aren't easily represented by the "standard" stuff.
> Pretty much any time you use the unit address in a context other than the
> bus parent, things cease making sense.
I tend to agree.
> There is the ePAPR working group, though.
Yup, true.
Ben.
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2007-07-17 22:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <469D43DD.8020102@freescale.com>
So, like, the other day Scott Wood mumbled:
> Jon Loeliger wrote:
> > How about "soc8241@80000000" instead?
>
> How about just "soc@80000000"? Those model numbers in the names are a
> PITA to find from limited functionality environments such as the
> bootwrapper, require things like stdout-path to be different on every
> soc, and don't comply with the generic names recommendation.
Oh! Right. No problem.
jdl
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Scott Wood @ 2007-07-17 22:51 UTC (permalink / raw)
To: Siva Prasad; +Cc: suresh suresh, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D78D7FAF@corpexc01.corp.networkrobots.com>
Siva Prasad wrote:
> Well!... you can manage any way you want.
>
>
>
> 1) You can store the virtual address in the DpRAM, and convert to
> physical (should I say DMA mapped address) and then pass it on to the
> device under consideration here.
The DPRAM is read directly by the microcode (if it didn't, you'd just be
using RAM). You don't want to put virtual addresses in there.
-Scott
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Scott Wood @ 2007-07-17 22:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <E1IAvmA-00062M-F4@jdl.com>
Jon Loeliger wrote:
> A: They haven't been posted yet.
>
> Q: How do we know Segher has new patches?
He sent it to me to test, and I told him it worked...
-Scott
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Jon Loeliger @ 2007-07-17 22:44 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <469D3F60.8000401@freescale.com>
<Top Posting Carnac>
A: They haven't been posted yet.
Q: How do we know Segher has new patches?
</Top Posting Carnac>
So, like, the other day Scott Wood mumbled:
> Jon Loeliger wrote:
> > But luckily, this gave me the opportunity to then realize that
> > we should give a great big...
> >
> > Amen-brother-by: Jon Loeliger <jdl@freescale.com>
> >
> > to this patch from Scott.
> >
> > So, an official plea to Paul to apply this to his tree.
>
> Segher has a newer patch that supersedes this one. I don't know if he's
> posted it to the list yet, though.
>
> -Scott
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Siva Prasad @ 2007-07-17 22:41 UTC (permalink / raw)
To: suresh suresh, Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]
Well!... you can manage any way you want.
1) You can store the virtual address in the DpRAM, and convert to
physical (should I say DMA mapped address) and then pass it on to the
device under consideration here.
2) Other way would be... store the physical address in DpRAM. Use that
address for the device, and convert to virtual before you use it in the
code.
My preference is for first option.
- Siva
________________________________
From: suresh suresh [mailto:sureshtang@gmail.com]
Sent: Monday, July 16, 2007 10:59 PM
To: Scott Wood
Cc: Siva Prasad; linuxppc-embedded@ozlabs.org
Subject: Re: Linuxppc-embedded Digest, Vol 35, Issue 33
Thanks....
MPC8280 has internal memory space which contains Dualport(Dp) RAM. In
the DpRAM we allocate some tables and these has to store pointer of the
buffers which are allocated in external memory. Core will use this
pointer to access the buffers, basically these buffers are used for DMA.
Using IMMR register we can get physical address of the internal memory.
Now can I store the address return by the kmalloc() function? or I
should convert it into physical?
Please help me how to resove this address translation.
Regards,
Suresh
On 7/16/07, Scott Wood <scottwood@freescale.com> wrote:
Siva Prasad wrote:
> It returns kernel virtual address. If you use this buffer space for
DMA,
> please use appropriate flags. You may use __pa(address) or
> virt_to_phys() to convert virtual to physical.
No, you may not -- physical and DMA addresses are not always identical.
Use the DMA mapping API.
-Scott
[-- Attachment #2: Type: text/html, Size: 6080 bytes --]
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Scott Wood @ 2007-07-17 22:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IAvVm-0005yQ-LO@jdl.com>
Jon Loeliger wrote:
> How about "soc8241@80000000" instead?
>
> That would be similar to:
> soc8641@f8000000 {
> and
> soc8272@f0000000 {
How about just "soc@80000000"? Those model numbers in the names are a
PITA to find from limited functionality environments such as the
bootwrapper, require things like stdout-path to be different on every
soc, and don't comply with the generic names recommendation.
-Scott
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2007-07-17 22:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <630B6BC9-389F-4F5C-AE8F-9C3131C4543E@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> > +/ {
> > + model = "StorCenter";
>
> If you can find a real model number, put it in here, instead.
Yep, "StorCenter" is it. No model numer/name beyond that.
> > + compatible = "storcenter";
>
> Needs a manufacturer name in there.
Right. Will use:
compatible = "iomega,storcenter"
> > + PowerPC,603e { /* Really 8241 */
>
> So say "PowerPC,8241@0", or "PowerPC,e300@0" (or whatever
> the CPU core in there is), or simply "cpu@0", following
> the generic naming recommended practice.
Well, its the 8241 SoC with a 603e core... (This is
the same phrase currently being used on the Kurobox.)
I'll use:
PowerPC,8241@0 }
> > + bus-frequency = <0>;
>
> Is this filled in anywhere? Please document that, if so.
Right. boot{loader,wrapper}
> > + soc10x {
>
> Bad name. Where is the binding for this? I don't think
> I saw it before.
It's what is being used, again, by the Kurobox. I understand
that doesn't make it "right", just precedented by now.
How about "soc8241@80000000" instead?
That would be similar to:
soc8641@f8000000 {
and
soc8272@f0000000 {
> > + store-gathering = <0>; /* 0 == off, !0 == on */
>
> Don't define this as "!0", but as "1".
OK.
> > + i2c@fdf03000 {
> > + device_type = "i2c";
>
> No device_type, there is no I2C binding.
Right.
> > + compatible = "fsl-i2c";
>
> Needs to be more specific.
Hmmm... Not sure what to use here then. There are many
existing examples using "fsl-i2c" already. Granted, we've
established that they could be wrong... Should this be
more like this?:
compatible = "fsl,mpc8241-i2c", "fsl-i2c";
> > + mpic: pic@fdf40000 {
>
> interrupt-controller@fdf40000
OK.
> > + pci@fe800000 {
> > + clock-frequency = <d# 100000000>; /* Hz */
>
> 100MHz PCI? Interesting.
Good point. 66666666 seems more likely...
Thanks for the review and help here!
jdl
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Scott Wood @ 2007-07-17 22:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <1184707558.25235.159.camel@localhost.localdomain>
On Wed, Jul 18, 2007 at 07:25:57AM +1000, Benjamin Herrenschmidt wrote:
> > > which is why I tend to prefer having it
> > > explicitely in the interrupt controller node :-)
> >
> > Which is simply incorrect.
>
> It's absolutely not. Please, stop that moronic pin-head behaviour and
> find me a single case where that would actually be a problem of any sort
> or form.
It could lead someone to the erroneous conclusion that an #address-cells
other than zero in an interrupt controller that is not a device parent is
in any way a sane or supported thing to do.
It could lead people to write code that doesn't handle the absence of
#address-cells in such a node properly.
It could lead to flamewars. :-)
> > You mean, the magic default values you used for #address-cells
> > and #size-cells? That was simply a bug, someone forgot to read
> > the documentation...
>
> No, defaults are crap, period.
If there's only one value that could possibly make sense, it *not* being
the default is crap.
> See above. Besides, as I said, default values are crap. And no, it's not
> obvious which nodes define a physical address space or not, at least not
> for a generic parser.
The obvious way (which indeed isn't what the suggested algorithm does --
but the suggested algorithm doesn't do anything sensible) is that if you
got to the node via an interrupt-parent or interrupt-map, it doesn't use
#address-cells, and if you got to it by going to the regular device tree
parent, it does.
Pretty much any time you use the unit address in a context other than the
bus parent, things cease making sense.
> > In some areas, perhaps. And it would be nice to bring those
> > areas to the attention of the working group, instead of just
> > to complain.
>
> The working group is dead and some of the ex members of it expressed
> their lack of interest in pursuing these matters.
There is the ePAPR working group, though.
-Scott
^ permalink raw reply
* [PATCH] POWERPC: Fix misspelled "CONFIG_CHECK_CACHE_COHERENCY" Kconfig option.
From: Robert P. J. Day @ 2007-07-17 22:21 UTC (permalink / raw)
To: Linux PPC Mailing List; +Cc: Paul Mackerras
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
---
arch/powerpc/configs/prpmc2800_defconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/powerpc/platforms/embedded6xx/Kconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/configs/prpmc2800_defconfig b/arch/powerpc/configs/prpmc2800_defconfig
index fb504a7..858f865 100644
--- a/arch/powerpc/configs/prpmc2800_defconfig
+++ b/arch/powerpc/configs/prpmc2800_defconfig
@@ -48,7 +48,7 @@ CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_NOT_COHERENT_CACHE=y
-CONFIG_CONFIG_CHECK_CACHE_COHERENCY=y
+CONFIG_CHECK_CACHE_COHERENCY=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index b8b5fde..e4b2aee 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -215,7 +215,7 @@ config NOT_COHERENT_CACHE
depends on 4xx || 8xx || E200
default y
-config CONFIG_CHECK_CACHE_COHERENCY
+config CHECK_CACHE_COHERENCY
bool
endmenu
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index bec7726..2d12f77 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -59,7 +59,7 @@ config MPC10X_BRIDGE
config MV64X60
bool
select PPC_INDIRECT_PCI
- select CONFIG_CHECK_CACHE_COHERENCY
+ select CHECK_CACHE_COHERENCY
config MPC10X_OPENPIC
bool
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply related
* Re: [PATCH] POWERPC: Correct misspelled config variable in arch/powerpc/Kconfig.
From: Robert P. J. Day @ 2007-07-17 22:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linux PPC Mailing List
In-Reply-To: <18076.46827.932735.590316@cargo.ozlabs.ibm.com>
On Tue, 17 Jul 2007, Paul Mackerras wrote:
> Robert P. J. Day writes:
>
> > -config CONFIG_CHECK_CACHE_COHERENCY
> > +config CHECK_CACHE_COHERENCY
>
> Please also fix the occurrence in
> arch/powerpc/platforms/embedded6xx/Kconfig.
ah, i completely missed that one. i'll resubmit the patch shortly.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-17 22:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E0E696F1-2F9E-4D6B-A194-EB42BA826BCD@kernel.crashing.org>
On Wed, 4 Jul 2007, Segher Boessenkool wrote:
> Your device is an rs5c372b. So, that's what you put in
> your device tree. Simple so far, right?
>
> Now some OF I2C code goes looking for IIC devices in the
> device tree. It finds this thing, and from a table or
> something it derives that it has to tell the kernel I2C
> layer this is an "rtc-rs5c372". [It would be nicer if it
> could just instantiate the correct driver directly, but
> if that's how the Linux I2C layer works, so be it].
>
> No change in the I2C "core" needed, just an OF "compatible"
> matching thing like is needed *everywhere else* too.
How about the patch below?
Thanks
Guennadi
---
Guennadi Liakhovetski
Scan the device tree for i2c devices, check their "compatible" property
against a hard-coded table, and, if found, register with i2c boardinfo.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 9588b60..c3c7eba 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -296,6 +296,62 @@ err:
arch_initcall(gfar_of_init);
+#ifdef CONFIG_I2C_BOARDINFO
+#include <linux/i2c.h>
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_driver;
+ char *i2c_type;
+};
+
+static struct i2c_driver_device i2c_devices[] = {
+ {"rs5c372a", "rtc-rs5c372", "rs5c372a",},
+ {"rs5c372b", "rtc-rs5c372", "rs5c372b",},
+ {"rv5c386", "rtc-rs5c372", "rv5c386",},
+ {"rv5c387a", "rtc-rs5c372", "rv5c387a",},
+};
+
+static int of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
+ strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ return 0;
+ }
+ return -ENODEV;
+}
+
+static void of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > 0xffff)
+ continue;
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ if (of_find_i2c_driver(node, &info) < 0)
+ continue;
+
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_register_board_info(bus_num, &info, 1);
+ }
+}
+
static int __init fsl_i2c_of_init(void)
{
struct device_node *np;
@@ -340,6 +396,8 @@ static int __init fsl_i2c_of_init(void)
fsl_i2c_platform_data));
if (ret)
goto unreg;
+
+ of_register_i2c_devices(np, i);
}
return 0;
@@ -351,6 +409,7 @@ err:
}
arch_initcall(fsl_i2c_of_init);
+#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
^ permalink raw reply related
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Scott Wood @ 2007-07-17 22:14 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <1184705168.24473.32.camel@ld0161-tx32>
Jon Loeliger wrote:
> But luckily, this gave me the opportunity to then realize that
> we should give a great big...
>
> Amen-brother-by: Jon Loeliger <jdl@freescale.com>
>
> to this patch from Scott.
>
> So, an official plea to Paul to apply this to his tree.
Segher has a newer patch that supersedes this one. I don't know if he's
posted it to the list yet, though.
-Scott
^ permalink raw reply
* Cypress c67x00 Support?
From: Robertson, Joseph M. @ 2007-07-17 22:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
Hi,
I have some questions about the Cypress c67x00 code that was posted a few days ago.
I got the many patches from the git (thanks Grant!), but I am wondering,
How did you guys fix up the Kconfigs to work with the Xilinx Virtex-4 fpga?
My hw guys have put the cypress chip on 'the system ace'(OPB?) bus, a 16 bit bus, and I have the address to it.
But its definetely not PCI, and if you use a plain kernel tree like I have, I cannot access any features without turning on the PCI options. Which of course fails, since I have no PCI parameters to feed the code.
Perhaps a better question is: Is this code intended for the Virtex-4?
If no, then I will have to fix it up.
Thanks,
Joe Robertson
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 2385 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
From: Michael S. Tsirkin @ 2007-07-17 21:32 UTC (permalink / raw)
To: Roland Dreier
Cc: Joachim Fenkes, LKML, LinuxPPC-Dev, Hoang-Nam Nguyen, OF-General,
Michael S. Tsirkin, Stefan Roscher
In-Reply-To: <adalkdesyrs.fsf@cisco.com>
> Quoting Roland Dreier <rdreier@cisco.com>:
> Subject: Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
>
> > Here's some anecdotal evidence :)
> > http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
>
> Right, but then we went on to say that we probably want to use
> multiple vectors to separate out multiple HCA ports rather than
> send/sreceive on the same port. And the current IPoIB implementation
> of having that second CQ seems suboptimal anyway, since it seems to
> leave us susceptible to the interrupt overload that NAPI was supposed
> to solve.
Sure, the ipoib patch is just a proof of concept anyway.
And I'm actually working on merging send/recv CQs now,
to address the livelocks.
> At a higher level, I'm left wondering why nobody talked about multiple
> EQs during the last months of the 2.6.22 process and now all of a
> sudden it becomes urgent in the last few days of the 2.6.23 merge
> window.
I don't see any emergency in merging the IPoIB hack either.
I just hoped that once we merge the core changes people will start
experimenting with multiple vectors. This did not seem to have happened.
Could this be because there's no low level driver support upstream yet?
So I wonder whether merging the mthca patch [that was patch 2 of the series]
in 2.6.23 will finally get the
ball rolling, get people to experiment with multiple vectors
in userspace, and that will hopefully teach us something.
> That's not really how I like to merge features....
If you look just at the mthca patch in isolation,
do you still see a problem?
--
MST
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Benjamin Herrenschmidt @ 2007-07-17 21:25 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <C2D29334-489F-49B0-8220-0D94E89FEAC3@kernel.crashing.org>
> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
> simply has no unit address part, in an interrupt domain that
> doesn't correspond to a "normal" bus. But saying it like this
> is a little bit inexact, and it uses more words.
>
> > which is why I tend to prefer having it
> > explicitely in the interrupt controller node :-)
>
> Which is simply incorrect.
It's absolutely not. Please, stop that moronic pin-head behaviour and
find me a single case where that would actually be a problem of any sort
or form.
> You mean, the magic default values you used for #address-cells
> and #size-cells? That was simply a bug, someone forgot to read
> the documentation...
No, defaults are crap, period. This is a general thing. Besides, the
spec itself has issues about the default values (remember those blurbs
about PCI and ISA supposedly having different defaults ?) In any way,
defaults are a bad idea and I'm happy to say don't use them.
> For this? No way:
>
> [From the base spec]:
>
> “#address-cells” S
> Standard property name to define the package’s address format.
> prop-encoded-array: Integer, encoded with encode-int.
>
> This property applies to packages that define a physical
> address space, i.e., those packages with “decode-unit”
> methods. The property value specifies the number of cells
> that are used to encode a physical address within that
> address space. The value of this property affects the other
> functions, commands, and methods that deal with physical
> addresses. In a package with a “decode-unit” method, a missing
> “#address-cells” property signifies that the number of
> address cells is two.
And you omit the various bus bindings that have come up with different
defaults...
> See? The flat device tree unfortunately has no decode-unit, but
> it is still pretty clear which nodes "define a physical address
> space" and which do not.
>
> There is nothing badly defined here.
See above. Besides, as I said, default values are crap. And no, it's not
obvious which nodes define a physical address space or not, at least not
for a generic parser. Defaults are a bad idea, just get it and move on
and stop arguing just for the sake of arguing. Pointing out the letter
of the spec is not a constructive attitude here.
> Nothing in the "interrupt mapping" spec redefines #address-cells
> (OF isn't all that stupid you know); it simply says that a /unit
> interrupt specifier/ has no /unit address/ part if there is no
> #address-cells. The algorithm in paragraph 7 makes it super
> clear how exactly this should work.
No, the algorithm provided isn't clear and is buggy. I have implemented
it so I know what I'm talking about. The fact that basically you end up
with "different" defaults for what is essentially the value
#address-cells depending on whether you are walking the device-tree for
address resolution or for interrupt resolution is stupid. Thus, the
solution is simple: don't do defaults. Explicit values are good.
> > and the spec contains gray areas
> > and contradictions as to what the default values should be in some
> > circumstances.
>
> In some areas, perhaps. And it would be nice to bring those
> areas to the attention of the working group, instead of just
> to complain.
The working group is dead and some of the ex members of it expressed
their lack of interest in pursuing these matters.
> Linux will have to keep supporting them for "real OF", so
> requiring an explicit #address-cells where its value is 2
> doesn't really help much. I'm not opposed to this though,
> for flat device trees at least (I think it's a good thing
> for OF trees as well, but for different reasons; and that's
> beside the point here).
>
> On the other hand, requiring an #address-cells where it is
> supposed to be absent, and you only want it so you can wrap
> your head around the interrupt mapping recommended practice
> in a more confusing and confused way, is simply WRONG.
No, it's not, It's purely having an explicit representation of what was
a stupid default behaviour.
> If it would, the interrupt mapping spec would have had to say
> how the semantics of #address-cells were changed (and they
> weren't, and they shouldn't, and this is such a laughable idea
> I wonder why anyone would suggest it did).
That's bullshit. The semantics are exactly the same. You obviously
decided to be immune to any kind of common sense today.
> What the interrupt mapping spec defines is how to _use_ the
> value of #address-cells, and how to interpret its absence;
> what should be put in #address-cells for separate nodes is
> defined elsewhere (namely, in the base spec, and in relevant
> device bindings).
There is no such crackpot interpretation. A unit interrupt specifier
contains ... an address. An address format/size is defined by a
#address-cells. Period. That's not an "interpretation", that's the
basic, primary semantic of #address-cells. The fact that the absence of
#address-cells will give a different "default" for the address size
depending on "how" you walk the tree is just a plain wrong bad idea. I
see no reason why it would be or cause or be in any way shape or form
wrong or against the "spirit" of the spec (if not the letter) to
explicitely specify in the case of leaf interrupt controllers, that
their #address-cells is 0 and be done with it.
Ben.
^ permalink raw reply
* Re: hugetlbfs for ppc440 - kernel BUG -- follow up
From: Satya @ 2007-07-17 21:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kazutomo, edi, david
hello,
Upon investigating the below issue further, I found that
pte_alloc_map() calls kmap_atomic. The allocated pte page must be
unmapped before invoking any function that might_sleep.
In this case clear_huge_page() is being called without invoking
pte_unmap(). The 'normal' counterpart of hugetlb_no_page (which is
do_no_page() in mm/memory.c) does call pte_unmap() before calling
alloc_page() (which might sleep).
So, I believe pte_unmap() must be invoked first in hugetlb_no_page().
But the problem here is, we do not have a reference to the pmd to map
the pte again (using pte_offset_map()). The do_no_page() function does
have a pmd_t* parameter, so it can remap the pte when required.
For now, I resolved the problem by expanding the pte_alloc_map() macro
by hand and replacing kmap_atomic with kmap(), although I think it is
not the right thing to do.
Let me know if my analysis is helping you figure out the problem here. Thanks!
--satya.
On 7/10/07, Satya <satyakiran@gmail.com> wrote:
> hello,
> I am trying to implement hugetlbfs on the IBM Bluegene/L IO node
> (ppc440) and I have a big problem as well as a few questions to ask
> the group. I patched a 2.6.21.6 linux kernel (manually) with Edi
> Shmueli's hugetlbfs implementation (found here:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did
> have to make slight changes (described at the end) to make it work.
> My test program is a shortened version of a sys v shared memory
> example described in Documentation/vm/hugetlbpage.txt
>
> I get the following kernel BUG when a page fault occurs on a huge page address:
> BUG: scheduling while atomic: shmtest2/0x10000001/1291
> Call Trace:
> [CFF0BCE0] [C00084F4] show_stack+0x4c/0x194 (unreliable)
> [CFF0BD20] [C01A53C4] schedule+0x664/0x668
> [CFF0BD60] [C00175F8] __cond_resched+0x24/0x50
> [CFF0BD80] [C01A5A6C] cond_resched+0x50/0x58
> [CFF0BD90] [C005A31C] clear_huge_page+0x28/0x174
> [CFF0BDC0] [C005B360] hugetlb_no_page+0xb4/0x220
> [CFF0BE00] [C005B5BC] hugetlb_fault+0xf0/0xf4
> [CFF0BE30] [C0052AC0] __handle_mm_fault+0x3a8/0x3ac
> [CFF0BE70] [C00094A0] do_page_fault+0x118/0x428
> [CFF0BF40] [C0002360] handle_page_fault+0xc/0x80
> BUG: scheduling while atomic: shmtest2/0x10000001/1291
>
> Now for my questions:
>
> 1. Can the kernel really reschedule in a page fault handler context ?
>
> 2. Just to test where this "scheduling while atomic" bug is arising, i
> put schedule() calls at various places in the path of the stack trace
> shown above.
> I found that a call to pte_alloc_map() puts the kernel in a context
> where it cannot reschedule without throwing up. Here is a trace of
> what's going on:
>
> __handle_mm_fault -> hugetlb_fault -> huge_pte_alloc() -> pte_alloc_map()
>
> Any call to schedule() before pte_alloc_map() does not throw this
> error. Well, this might be a flawed experiment, I am no expert kernel
> hacker. Does this throw any light on the problem?
>
> Here are the modifications I made to Edi's patch:
>
> arch/ppc/mm/hugetlbpage.c
> struct page *
> follow_huge_addr(struct mm_struct *mm, unsigned long address, int write)
> {
> pte_t *pte;
> struct page *page;
> + struct vm_area_struct *vma;
> +
> + vma = find_vma(mm, address);
> + if (!vma || !is_vm_hugetlb_page(vma))
> + return ERR_PTR(-EINVAL);
>
> pte = huge_pte_offset(mm, address);
> page = pte_page(*pte);
> return page;
> }
>
> +int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
> +{
> + return 0;
> +}
>
> Here is my test program:
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/ipc.h>
> #include <sys/shm.h>
> #include <sys/mman.h>
>
> #ifndef SHM_HUGETLB
> #define SHM_HUGETLB 04000
> #endif
>
> #define LENGTH (16UL*1024*1024)
>
> #define dprintf(x) printf(x)
>
> #define ADDR (void *)(0x0UL)
> #define SHMAT_FLAGS (0)
>
>
> int main(void)
> {
> int shmid;
> unsigned long i;
> char *shmaddr;
>
> if ((shmid = shmget(2, LENGTH,
> SHM_HUGETLB | IPC_CREAT | SHM_R | SHM_W)) < 0) {
> perror("shmget");
> exit(1);
> }
> printf("shmid: 0x%x\n", shmid);
>
> shmaddr = shmat(shmid, ADDR, SHMAT_FLAGS);
> if (shmaddr == (char *)-1) {
> perror("Shared memory attach failure");
> shmctl(shmid, IPC_RMID, NULL);
> exit(2);
> }
> printf("shmaddr: %p\n", shmaddr);
> printf("touching a huge page..\n");
>
> shmaddr[0]='a';
> shmaddr[1]='b';
>
> if (shmdt((const void *)shmaddr) != 0) {
> perror("Detach failure");
> shmctl(shmid, IPC_RMID, NULL);
> exit(3);
> }
>
> shmctl(shmid, IPC_RMID, NULL);
>
> return 0;
> }
>
> thanks!
> Satya.
>
--
...what's remarkable, is that atoms have assembled into entities which
are somehow able to ponder their origins.
--
http://cs.uic.edu/~spopuri
^ permalink raw reply
* Re: [PATCH] iommu virtual merge no longer experimental
From: Benjamin Herrenschmidt @ 2007-07-17 20:56 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, paulus, Arnd Bergmann, Tim Schimke
In-Reply-To: <20070717160935.GE5771@austin.ibm.com>
On Tue, 2007-07-17 at 11:09 -0500, Linas Vepstas wrote:
> Per conversations with BenH, iommu virtual merging should no longer
> be considered to be an "experimental" feature. In particular,
> CONFIG_VMERGE has been set to "y" in te defconfigs for quite a while.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ----
> arch/powerpc/Kconfig | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> Index: linux-2.6.22-git2/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.22-git2.orig/arch/powerpc/Kconfig 2007-07-08 18:32:17.000000000 -0500
> +++ linux-2.6.22-git2/arch/powerpc/Kconfig 2007-07-17 11:08:18.000000000 -0500
> @@ -430,16 +430,17 @@ config MATH_EMULATION
> instructions to run.
>
> config IOMMU_VMERGE
> - bool "Enable IOMMU virtual merging (EXPERIMENTAL)"
> - depends on EXPERIMENTAL && PPC64
> - default n
> + bool "Enable IOMMU virtual merging"
> + depends on PPC64
> + default y
> help
> Cause IO segments sent to a device for DMA to be merged virtually
> by the IOMMU when they happen to have been allocated contiguously.
> This doesn't add pressure to the IOMMU allocator. However, some
> drivers don't support getting large merged segments coming back
> - from *_map_sg(). Say Y if you know the drivers you are using are
> - properly handling this case.
> + from *_map_sg().
> +
> + Most drivers don't have this problem; it is safe to say Y here.
>
> config HOTPLUG_CPU
> bool "Support for enabling/disabling CPUs"
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Jon Loeliger @ 2007-07-17 20:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <20070709214853.GA29912@ld0162-tx32.am.freescale.net>
On Mon, 2007-07-09 at 16:48, Scott Wood wrote:
> In older versions of glibc (through 2.3), the dynamic linker executes a
> small amount of code from the data segment, which is not marked as
> executable. A recent change (commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; there should be a deprecation period before
> older glibc versions stop working.
>
> The problem has been observed on glibc 2.2. While glibc 2.3 has the same
> code, I did not see the problem; it may be that it accesses the page in
> question as data before executing from it, and thus it is already mapped.
>
> Note that this only applies to the classic 32-bit PowerPC MMU and the
> MPC8xx MMU, not Book E, 64-bit, etc. These MMUs do not support per-page
> no-exec, and thus this patch isn't taking away any effective protection
> enforcement. Currently, such accesses will fail only if the page in
> question has not already been faulted on (and thus mapped).
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
Well now. I've spent a good chunk of today with Our Friend, git-bisect,
verifying that, in fact, the commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf
breaks the 8641 HPCN port. init doesn't run off an old NFS'ed root FS
worth a Steven J Hill of beans.
But luckily, this gave me the opportunity to then realize that
we should give a great big...
Amen-brother-by: Jon Loeliger <jdl@freescale.com>
to this patch from Scott.
So, an official plea to Paul to apply this to his tree.
jdl
> v2: Added to the changelog to explain why this change isn't harmful.
>
> arch/powerpc/mm/fault.c | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 0ece513..2445512 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -125,6 +125,18 @@ static void do_dabr(struct pt_regs *regs, unsigned long address,
> }
> #endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
>
> +#ifdef CONFIG_PPC32
> +static void warn_exec_from_noexec(void)
> +{
> + if (printk_ratelimit())
> + printk(KERN_WARNING "Process %s (%d) attempted to execute from "
> + "a non-executable page.\n"
> + KERN_WARNING "This may stop working in future kernels. "
> + "Please upgrade your libc.\n",
> + current->comm, current->pid);
> +}
> +#endif
> +
> /*
> * For 600- and 800-family processors, the error_code parameter is DSISR
> * for a data fault, SRR1 for an instruction fault. For 400-family processors
> @@ -283,8 +295,16 @@ good_area:
> /* protection fault */
> if (error_code & DSISR_PROTFAULT)
> goto bad_area;
> - if (!(vma->vm_flags & VM_EXEC))
> + if (!(vma->vm_flags & VM_EXEC)) {
> +#ifdef CONFIG_PPC32
> + if (vma->vm_flags & VM_READ)
> + warn_exec_from_noexec();
> + else
> + goto bad_area;
> +#else
> goto bad_area;
> +#endif
> + }
> #else
> pte_t *ptep;
> pmd_t *pmdp;
^ permalink raw reply
* [PATCH] powerpc: mpc5200 low power mode
From: Sylvain Munaut @ 2007-07-17 20:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linux PPC Mailing List, Sylvain Munaut, Domen Puncer
From: Domen Puncer <domen.puncer@telargo.com>
Low-power mode implementation for Lite5200b.
Some I/O registers are also saved here.
A recent U-Boot that supports this (lite5200b_PM_config) is needed.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
Hi Paulus,
Could you push this with you next merge ? It's the support for lite5200 low power
mode, posted on -embedded a few days ago.
Sylvain
---
arch/powerpc/platforms/52xx/Makefile | 3 +
arch/powerpc/platforms/52xx/lite5200.c | 14 +-
arch/powerpc/platforms/52xx/lite5200_pm.c | 213 +++++++++++++
arch/powerpc/platforms/52xx/lite5200_sleep.S | 413 ++++++++++++++++++++++++++
include/asm-powerpc/mpc52xx.h | 10 +
5 files changed, 648 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/lite5200_pm.c
create mode 100644 arch/powerpc/platforms/52xx/lite5200_sleep.S
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index b91e39c..307dbc1 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -10,3 +10,6 @@ obj-$(CONFIG_PPC_EFIKA) += efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
obj-$(CONFIG_PM) += mpc52xx_sleep.o mpc52xx_pm.o
+ifeq ($(CONFIG_PPC_LITE5200),y)
+ obj-$(CONFIG_PM) += lite5200_sleep.o lite5200_pm.o
+endif
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 5c46e89..16eb5ad 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -86,7 +86,6 @@ error:
}
#ifdef CONFIG_PM
-static u32 descr_a;
static void lite5200_suspend_prepare(void __iomem *mbar)
{
u8 pin = 1; /* GPIO_WKUP_1 (GPIO_PSC2_4) */
@@ -97,13 +96,18 @@ static void lite5200_suspend_prepare(void __iomem *mbar)
* power down usb port
* this needs to be called before of-ohci suspend code
*/
- descr_a = in_be32(mbar + 0x1048);
- out_be32(mbar + 0x1048, (descr_a & ~0x200) | 0x100);
+
+ /* set ports to "power switched" and "powered at the same time"
+ * USB Rh descriptor A: NPS = 0, PSM = 0 */
+ out_be32(mbar + 0x1048, in_be32(mbar + 0x1048) & ~0x300);
+ /* USB Rh status: LPS = 1 - turn off power */
+ out_be32(mbar + 0x1050, 0x00000001);
}
static void lite5200_resume_finish(void __iomem *mbar)
{
- out_be32(mbar + 0x1048, descr_a);
+ /* USB Rh status: LPSC = 1 - turn on power */
+ out_be32(mbar + 0x1050, 0x00010000);
}
#endif
@@ -132,7 +136,7 @@ static void __init lite5200_setup_arch(void)
#ifdef CONFIG_PM
mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
mpc52xx_suspend.board_resume_finish = lite5200_resume_finish;
- mpc52xx_pm_init();
+ lite5200_pm_init();
#endif
#ifdef CONFIG_PCI
diff --git a/arch/powerpc/platforms/52xx/lite5200_pm.c b/arch/powerpc/platforms/52xx/lite5200_pm.c
new file mode 100644
index 0000000..f26afcd
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/lite5200_pm.c
@@ -0,0 +1,213 @@
+#include <linux/init.h>
+#include <linux/pm.h>
+#include <asm/io.h>
+#include <asm/time.h>
+#include <asm/mpc52xx.h>
+#include "mpc52xx_pic.h"
+
+/* defined in lite5200_sleep.S and only used here */
+extern void lite5200_low_power(void __iomem *sram, void __iomem *mbar);
+
+static struct mpc52xx_cdm __iomem *cdm;
+static struct mpc52xx_intr __iomem *pic;
+static struct mpc52xx_sdma __iomem *bes;
+static struct mpc52xx_xlb __iomem *xlb;
+static struct mpc52xx_gpio __iomem *gps;
+static struct mpc52xx_gpio_wkup __iomem *gpw;
+static void __iomem *sram;
+static const int sram_size = 0x4000; /* 16 kBytes */
+static void __iomem *mbar;
+
+static int lite5200_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+static int lite5200_pm_prepare(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY)
+ return mpc52xx_pm_prepare(state);
+
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ /* map registers */
+ mbar = mpc52xx_find_and_map("mpc5200");
+ if (!mbar) {
+ printk(KERN_ERR "%s:%i Error mapping registers\n", __func__, __LINE__);
+ return -ENOSYS;
+ }
+
+ cdm = mbar + 0x200;
+ pic = mbar + 0x500;
+ gps = mbar + 0xb00;
+ gpw = mbar + 0xc00;
+ bes = mbar + 0x1200;
+ xlb = mbar + 0x1f00;
+ sram = mbar + 0x8000;
+
+ return 0;
+}
+
+/* save and restore registers not bound to any real devices */
+static struct mpc52xx_cdm scdm;
+static struct mpc52xx_intr spic;
+static struct mpc52xx_sdma sbes;
+static struct mpc52xx_xlb sxlb;
+static struct mpc52xx_gpio sgps;
+static struct mpc52xx_gpio_wkup sgpw;
+
+static void lite5200_save_regs(void)
+{
+ _memcpy_fromio(&spic, pic, sizeof(*pic));
+ _memcpy_fromio(&sbes, bes, sizeof(*bes));
+ _memcpy_fromio(&scdm, cdm, sizeof(*cdm));
+ _memcpy_fromio(&sxlb, xlb, sizeof(*xlb));
+ _memcpy_fromio(&sgps, gps, sizeof(*gps));
+ _memcpy_fromio(&sgpw, gpw, sizeof(*gpw));
+
+ _memcpy_fromio(saved_sram, sram, sram_size);
+}
+
+static void lite5200_restore_regs(void)
+{
+ int i;
+ _memcpy_toio(sram, saved_sram, sram_size);
+
+
+ /*
+ * GPIOs. Interrupt Master Enable has higher address then other
+ * registers, so just memcpy is ok.
+ */
+ _memcpy_toio(gpw, &sgpw, sizeof(*gpw));
+ _memcpy_toio(gps, &sgps, sizeof(*gps));
+
+
+ /* XLB Arbitrer */
+ out_be32(&xlb->snoop_window, sxlb.snoop_window);
+ out_be32(&xlb->master_priority, sxlb.master_priority);
+ out_be32(&xlb->master_pri_enable, sxlb.master_pri_enable);
+
+ /* enable */
+ out_be32(&xlb->int_enable, sxlb.int_enable);
+ out_be32(&xlb->config, sxlb.config);
+
+
+ /* CDM - Clock Distribution Module */
+ out_8(&cdm->ipb_clk_sel, scdm.ipb_clk_sel);
+ out_8(&cdm->pci_clk_sel, scdm.pci_clk_sel);
+
+ out_8(&cdm->ext_48mhz_en, scdm.ext_48mhz_en);
+ out_8(&cdm->fd_enable, scdm.fd_enable);
+ out_be16(&cdm->fd_counters, scdm.fd_counters);
+
+ out_be32(&cdm->clk_enables, scdm.clk_enables);
+
+ out_8(&cdm->osc_disable, scdm.osc_disable);
+
+ out_be16(&cdm->mclken_div_psc1, scdm.mclken_div_psc1);
+ out_be16(&cdm->mclken_div_psc2, scdm.mclken_div_psc2);
+ out_be16(&cdm->mclken_div_psc3, scdm.mclken_div_psc3);
+ out_be16(&cdm->mclken_div_psc6, scdm.mclken_div_psc6);
+
+
+ /* BESTCOMM */
+ out_be32(&bes->taskBar, sbes.taskBar);
+ out_be32(&bes->currentPointer, sbes.currentPointer);
+ out_be32(&bes->endPointer, sbes.endPointer);
+ out_be32(&bes->variablePointer, sbes.variablePointer);
+
+ out_8(&bes->IntVect1, sbes.IntVect1);
+ out_8(&bes->IntVect2, sbes.IntVect2);
+ out_be16(&bes->PtdCntrl, sbes.PtdCntrl);
+
+ for (i=0; i<32; i++)
+ out_8(&bes->ipr[i], sbes.ipr[i]);
+
+ out_be32(&bes->cReqSelect, sbes.cReqSelect);
+ out_be32(&bes->task_size0, sbes.task_size0);
+ out_be32(&bes->task_size1, sbes.task_size1);
+ out_be32(&bes->MDEDebug, sbes.MDEDebug);
+ out_be32(&bes->ADSDebug, sbes.ADSDebug);
+ out_be32(&bes->Value1, sbes.Value1);
+ out_be32(&bes->Value2, sbes.Value2);
+ out_be32(&bes->Control, sbes.Control);
+ out_be32(&bes->Status, sbes.Status);
+ out_be32(&bes->PTDDebug, sbes.PTDDebug);
+
+ /* restore tasks */
+ for (i=0; i<16; i++)
+ out_be16(&bes->tcr[i], sbes.tcr[i]);
+
+ /* enable interrupts */
+ out_be32(&bes->IntPend, sbes.IntPend);
+ out_be32(&bes->IntMask, sbes.IntMask);
+
+
+ /* PIC */
+ out_be32(&pic->per_pri1, spic.per_pri1);
+ out_be32(&pic->per_pri2, spic.per_pri2);
+ out_be32(&pic->per_pri3, spic.per_pri3);
+
+ out_be32(&pic->main_pri1, spic.main_pri1);
+ out_be32(&pic->main_pri2, spic.main_pri2);
+
+ out_be32(&pic->enc_status, spic.enc_status);
+
+ /* unmask and enable interrupts */
+ out_be32(&pic->per_mask, spic.per_mask);
+ out_be32(&pic->main_mask, spic.main_mask);
+ out_be32(&pic->ctrl, spic.ctrl);
+}
+
+static int lite5200_pm_enter(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY) {
+ return mpc52xx_pm_enter(state);
+ }
+
+ lite5200_save_regs();
+
+ /* effectively save FP regs */
+ enable_kernel_fp();
+
+ lite5200_low_power(sram, mbar);
+
+ lite5200_restore_regs();
+
+ /* restart jiffies */
+ wakeup_decrementer();
+
+ iounmap(mbar);
+ return 0;
+}
+
+static int lite5200_pm_finish(suspend_state_t state)
+{
+ /* deep sleep? let mpc52xx code handle that */
+ if (state == PM_SUSPEND_STANDBY) {
+ return mpc52xx_pm_finish(state);
+ }
+ return 0;
+}
+
+static struct pm_ops lite5200_pm_ops = {
+ .valid = lite5200_pm_valid,
+ .prepare = lite5200_pm_prepare,
+ .enter = lite5200_pm_enter,
+ .finish = lite5200_pm_finish,
+};
+
+int __init lite5200_pm_init(void)
+{
+ pm_set_ops(&lite5200_pm_ops);
+ return 0;
+}
diff --git a/arch/powerpc/platforms/52xx/lite5200_sleep.S b/arch/powerpc/platforms/52xx/lite5200_sleep.S
new file mode 100644
index 0000000..2064119
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/lite5200_sleep.S
@@ -0,0 +1,413 @@
+#include <asm/reg.h>
+#include <asm/ppc_asm.h>
+#include <asm/processor.h>
+#include <asm/cache.h>
+
+
+#define SDRAM_CTRL 0x104
+#define SC_MODE_EN (1<<31)
+#define SC_CKE (1<<30)
+#define SC_REF_EN (1<<28)
+#define SC_SOFT_PRE (1<<1)
+
+#define GPIOW_GPIOE 0xc00
+#define GPIOW_DDR 0xc08
+#define GPIOW_DVO 0xc0c
+
+#define CDM_CE 0x214
+#define CDM_SDRAM (1<<3)
+
+
+/* helpers... beware: r10 and r4 are overwritten */
+#define SAVE_SPRN(reg, addr) \
+ mfspr r10, SPRN_##reg; \
+ stw r10, ((addr)*4)(r4);
+
+#define LOAD_SPRN(reg, addr) \
+ lwz r10, ((addr)*4)(r4); \
+ mtspr SPRN_##reg, r10; \
+ sync; \
+ isync;
+
+
+ .data
+registers:
+ .space 0x5c*4
+ .text
+
+/* ---------------------------------------------------------------------- */
+/* low-power mode with help of M68HLC908QT1 */
+
+ .globl lite5200_low_power
+lite5200_low_power:
+
+ mr r7, r3 /* save SRAM va */
+ mr r8, r4 /* save MBAR va */
+
+ /* setup wakeup address for u-boot at physical location 0x0 */
+ lis r3, CONFIG_KERNEL_START@h
+ lis r4, lite5200_wakeup@h
+ ori r4, r4, lite5200_wakeup@l
+ sub r4, r4, r3
+ stw r4, 0(r3)
+
+
+ /*
+ * save stuff BDI overwrites
+ * 0xf0 (0xe0->0x100 gets overwritten when BDI connected;
+ * even when CONFIG_BDI* is disabled and MMU XLAT commented; heisenbug?))
+ * WARNING: self-refresh doesn't seem to work when BDI2000 is connected,
+ * possibly because BDI sets SDRAM registers before wakeup code does
+ */
+ lis r4, registers@h
+ ori r4, r4, registers@l
+ lwz r10, 0xf0(r3)
+ stw r10, (0x1d*4)(r4)
+
+ /* save registers to r4 [destroys r10] */
+ SAVE_SPRN(LR, 0x1c)
+ bl save_regs
+
+ /* flush caches [destroys r3, r4] */
+ bl flush_data_cache
+
+
+ /* copy code to sram */
+ mr r4, r7
+ li r3, (sram_code_end - sram_code)/4
+ mtctr r3
+ lis r3, sram_code@h
+ ori r3, r3, sram_code@l
+1:
+ lwz r5, 0(r3)
+ stw r5, 0(r4)
+ addi r3, r3, 4
+ addi r4, r4, 4
+ bdnz 1b
+
+ /* get tb_ticks_per_usec */
+ lis r3, tb_ticks_per_usec@h
+ lwz r11, tb_ticks_per_usec@l(r3)
+
+ /* disable I and D caches */
+ mfspr r3, SPRN_HID0
+ ori r3, r3, HID0_ICE | HID0_DCE
+ xori r3, r3, HID0_ICE | HID0_DCE
+ sync; isync;
+ mtspr SPRN_HID0, r3
+ sync; isync;
+
+ /* jump to sram */
+ mtlr r7
+ blrl
+ /* doesn't return */
+
+
+sram_code:
+ /* self refresh */
+ lwz r4, SDRAM_CTRL(r8)
+
+ /* send NOP (precharge) */
+ oris r4, r4, SC_MODE_EN@h /* mode_en */
+ stw r4, SDRAM_CTRL(r8)
+ sync
+
+ ori r4, r4, SC_SOFT_PRE /* soft_pre */
+ stw r4, SDRAM_CTRL(r8)
+ sync
+ xori r4, r4, SC_SOFT_PRE
+
+ xoris r4, r4, SC_MODE_EN@h /* !mode_en */
+ stw r4, SDRAM_CTRL(r8)
+ sync
+
+ /* delay (for NOP to finish) */
+ li r12, 1
+ bl udelay
+
+ /*
+ * mode_en must not be set when enabling self-refresh
+ * send AR with CKE low (self-refresh)
+ */
+ oris r4, r4, (SC_REF_EN | SC_CKE)@h
+ xoris r4, r4, (SC_CKE)@h /* ref_en !cke */
+ stw r4, SDRAM_CTRL(r8)
+ sync
+
+ /* delay (after !CKE there should be two cycles) */
+ li r12, 1
+ bl udelay
+
+ /* disable clock */
+ lwz r4, CDM_CE(r8)
+ ori r4, r4, CDM_SDRAM
+ xori r4, r4, CDM_SDRAM
+ stw r4, CDM_CE(r8)
+ sync
+
+ /* delay a bit */
+ li r12, 1
+ bl udelay
+
+
+ /* turn off with QT chip */
+ li r4, 0x02
+ stb r4, GPIOW_GPIOE(r8) /* enable gpio_wkup1 */
+ sync
+
+ stb r4, GPIOW_DVO(r8) /* "output" high */
+ sync
+ stb r4, GPIOW_DDR(r8) /* output */
+ sync
+ stb r4, GPIOW_DVO(r8) /* output high */
+ sync
+
+ /* 10uS delay */
+ li r12, 10
+ bl udelay
+
+ /* turn off */
+ li r4, 0
+ stb r4, GPIOW_DVO(r8) /* output low */
+ sync
+
+ /* wait until we're offline */
+ 1:
+ b 1b
+
+
+ /* local udelay in sram is needed */
+ udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */
+ mullw r12, r12, r11
+ mftb r13 /* start */
+ addi r12, r13, r12 /* end */
+ 1:
+ mftb r13 /* current */
+ cmp cr0, r13, r12
+ blt 1b
+ blr
+
+sram_code_end:
+
+
+
+/* uboot jumps here on resume */
+lite5200_wakeup:
+ bl restore_regs
+
+
+ /* HIDs, MSR */
+ LOAD_SPRN(HID1, 0x19)
+ LOAD_SPRN(HID2, 0x1a)
+
+
+ /* address translation is tricky (see turn_on_mmu) */
+ mfmsr r10
+ ori r10, r10, MSR_DR | MSR_IR
+
+
+ mtspr SPRN_SRR1, r10
+ lis r10, mmu_on@h
+ ori r10, r10, mmu_on@l
+ mtspr SPRN_SRR0, r10
+ sync
+ rfi
+mmu_on:
+ /* kernel offset (r4 is still set from restore_registers) */
+ addis r4, r4, CONFIG_KERNEL_START@h
+
+
+ /* restore MSR */
+ lwz r10, (4*0x1b)(r4)
+ mtmsr r10
+ sync; isync;
+
+ /* invalidate caches */
+ mfspr r10, SPRN_HID0
+ ori r5, r10, HID0_ICFI | HID0_DCI
+ mtspr SPRN_HID0, r5 /* invalidate caches */
+ sync; isync;
+ mtspr SPRN_HID0, r10
+ sync; isync;
+
+ /* enable caches */
+ lwz r10, (4*0x18)(r4)
+ mtspr SPRN_HID0, r10 /* restore (enable caches, DPM) */
+ /* ^ this has to be after address translation set in MSR */
+ sync
+ isync
+
+
+ /* restore 0xf0 (BDI2000) */
+ lis r3, CONFIG_KERNEL_START@h
+ lwz r10, (0x1d*4)(r4)
+ stw r10, 0xf0(r3)
+
+ LOAD_SPRN(LR, 0x1c)
+
+
+ blr
+
+
+/* ---------------------------------------------------------------------- */
+/* boring code: helpers */
+
+/* save registers */
+#define SAVE_BAT(n, addr) \
+ SAVE_SPRN(DBAT##n##L, addr); \
+ SAVE_SPRN(DBAT##n##U, addr+1); \
+ SAVE_SPRN(IBAT##n##L, addr+2); \
+ SAVE_SPRN(IBAT##n##U, addr+3);
+
+#define SAVE_SR(n, addr) \
+ mfsr r10, n; \
+ stw r10, ((addr)*4)(r4);
+
+#define SAVE_4SR(n, addr) \
+ SAVE_SR(n, addr); \
+ SAVE_SR(n+1, addr+1); \
+ SAVE_SR(n+2, addr+2); \
+ SAVE_SR(n+3, addr+3);
+
+save_regs:
+ stw r0, 0(r4)
+ stw r1, 0x4(r4)
+ stw r2, 0x8(r4)
+ stmw r11, 0xc(r4) /* 0xc -> 0x5f, (0x18*4-1) */
+
+ SAVE_SPRN(HID0, 0x18)
+ SAVE_SPRN(HID1, 0x19)
+ SAVE_SPRN(HID2, 0x1a)
+ mfmsr r10
+ stw r10, (4*0x1b)(r4)
+ /*SAVE_SPRN(LR, 0x1c) have to save it before the call */
+ /* 0x1d reserved by 0xf0 */
+ SAVE_SPRN(RPA, 0x1e)
+ SAVE_SPRN(SDR1, 0x1f)
+
+ /* save MMU regs */
+ SAVE_BAT(0, 0x20)
+ SAVE_BAT(1, 0x24)
+ SAVE_BAT(2, 0x28)
+ SAVE_BAT(3, 0x2c)
+ SAVE_BAT(4, 0x30)
+ SAVE_BAT(5, 0x34)
+ SAVE_BAT(6, 0x38)
+ SAVE_BAT(7, 0x3c)
+
+ SAVE_4SR(0, 0x40)
+ SAVE_4SR(4, 0x44)
+ SAVE_4SR(8, 0x48)
+ SAVE_4SR(12, 0x4c)
+
+ SAVE_SPRN(SPRG0, 0x50)
+ SAVE_SPRN(SPRG1, 0x51)
+ SAVE_SPRN(SPRG2, 0x52)
+ SAVE_SPRN(SPRG3, 0x53)
+ SAVE_SPRN(SPRG4, 0x54)
+ SAVE_SPRN(SPRG5, 0x55)
+ SAVE_SPRN(SPRG6, 0x56)
+ SAVE_SPRN(SPRG7, 0x57)
+
+ SAVE_SPRN(IABR, 0x58)
+ SAVE_SPRN(DABR, 0x59)
+ SAVE_SPRN(TBRL, 0x5a)
+ SAVE_SPRN(TBRU, 0x5b)
+
+ blr
+
+
+/* restore registers */
+#define LOAD_BAT(n, addr) \
+ LOAD_SPRN(DBAT##n##L, addr); \
+ LOAD_SPRN(DBAT##n##U, addr+1); \
+ LOAD_SPRN(IBAT##n##L, addr+2); \
+ LOAD_SPRN(IBAT##n##U, addr+3);
+
+#define LOAD_SR(n, addr) \
+ lwz r10, ((addr)*4)(r4); \
+ mtsr n, r10;
+
+#define LOAD_4SR(n, addr) \
+ LOAD_SR(n, addr); \
+ LOAD_SR(n+1, addr+1); \
+ LOAD_SR(n+2, addr+2); \
+ LOAD_SR(n+3, addr+3);
+
+restore_regs:
+ lis r4, registers@h
+ ori r4, r4, registers@l
+
+ /* MMU is not up yet */
+ subis r4, r4, CONFIG_KERNEL_START@h
+
+ lwz r0, 0(r4)
+ lwz r1, 0x4(r4)
+ lwz r2, 0x8(r4)
+ lmw r11, 0xc(r4)
+
+ /*
+ * these are a bit tricky
+ *
+ * 0x18 - HID0
+ * 0x19 - HID1
+ * 0x1a - HID2
+ * 0x1b - MSR
+ * 0x1c - LR
+ * 0x1d - reserved by 0xf0 (BDI2000)
+ */
+ LOAD_SPRN(RPA, 0x1e);
+ LOAD_SPRN(SDR1, 0x1f);
+
+ /* restore MMU regs */
+ LOAD_BAT(0, 0x20)
+ LOAD_BAT(1, 0x24)
+ LOAD_BAT(2, 0x28)
+ LOAD_BAT(3, 0x2c)
+ LOAD_BAT(4, 0x30)
+ LOAD_BAT(5, 0x34)
+ LOAD_BAT(6, 0x38)
+ LOAD_BAT(7, 0x3c)
+
+ LOAD_4SR(0, 0x40)
+ LOAD_4SR(4, 0x44)
+ LOAD_4SR(8, 0x48)
+ LOAD_4SR(12, 0x4c)
+
+ /* rest of regs */
+ LOAD_SPRN(SPRG0, 0x50);
+ LOAD_SPRN(SPRG1, 0x51);
+ LOAD_SPRN(SPRG2, 0x52);
+ LOAD_SPRN(SPRG3, 0x53);
+ LOAD_SPRN(SPRG4, 0x54);
+ LOAD_SPRN(SPRG5, 0x55);
+ LOAD_SPRN(SPRG6, 0x56);
+ LOAD_SPRN(SPRG7, 0x57);
+
+ LOAD_SPRN(IABR, 0x58);
+ LOAD_SPRN(DABR, 0x59);
+ LOAD_SPRN(TBWL, 0x5a); /* these two have separate R/W regs */
+ LOAD_SPRN(TBWU, 0x5b);
+
+ blr
+
+
+
+/* cache flushing code. copied from arch/ppc/boot/util.S */
+#define NUM_CACHE_LINES (128*8)
+
+/*
+ * Flush data cache
+ * Do this by just reading lots of stuff into the cache.
+ */
+ .globl flush_data_cache
+flush_data_cache:
+ lis r3,CONFIG_KERNEL_START@h
+ ori r3,r3,CONFIG_KERNEL_START@l
+ li r4,NUM_CACHE_LINES
+ mtctr r4
+1:
+ lwz r4,0(r3)
+ addi r3,r3,L1_CACHE_BYTES /* Next line, please */
+ bdnz 1b
+ blr
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index c4631f6..1a3dbb7 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -262,6 +262,16 @@ struct mpc52xx_suspend {
extern struct mpc52xx_suspend mpc52xx_suspend;
extern int __init mpc52xx_pm_init(void);
extern int mpc52xx_set_wakeup_gpio(u8 pin, u8 level);
+
+#ifdef CONFIG_PPC_LITE5200
+extern int __init lite5200_pm_init(void);
+
+/* lite5200 calls mpc5200 suspend functions, so here they are */
+extern int mpc52xx_pm_prepare(suspend_state_t);
+extern int mpc52xx_pm_enter(suspend_state_t);
+extern int mpc52xx_pm_finish(suspend_state_t);
+extern char saved_sram[0x4000]; /* reuse buffer from mpc52xx suspend */
+#endif
#endif /* CONFIG_PM */
#endif /* __ASM_POWERPC_MPC52xx_H__ */
--
1.5.0.1
^ permalink raw reply related
* Re: [PATCH] POWERPC: Added RTC support for mpc8313RDB and utilize "clock-frequency"
From: Guennadi Liakhovetski @ 2007-07-17 19:58 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717214824.04db9e88@vitb.ru.mvista.com>
On Tue, 17 Jul 2007, Vitaly Bordug wrote:
> > Please don't do this; drivers/i2c/chips/ds1337.c is deprecated. You
> > should be using the RTC-class driver in drivers/rtc/rtc-ds1307.c, which
> > has a non-device-specific API that can be used.
> >
> > The ppc_md RTC functions should really just go away, though -- setting
> > the clock on bootup can be done by generic code, and periodically
> > updating the RTC when using NTP can be done from userspace.
>
> If those ppc_md hookups would be declared deprecated, there's no much sense in the upper,
> apparently. But I am not sure they will be... I'm inclined to let this patch floating since
> interacting with rtc class from within BSP code just does not worth it.
Exactly! Don't interact with it. Just leave it alone. No need to re-write
[sg]et_rtc_time, bother with setting system time on bootup... Just let the
rtc driver and framework do it for you.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* [patch 14/14] Bamboo zImage wrapper
From: Josh Boyer @ 2007-07-17 18:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070717181547.310201000@linux.vnet.ibm.com>
Add a bootwrapper for Bamboo
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/44x.h | 1
arch/powerpc/boot/Makefile | 5 -
arch/powerpc/boot/bamboo.c | 126 ++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/dcr.h | 11 +++
arch/powerpc/boot/treeboot-bamboo.c | 27 +++++++
5 files changed, 168 insertions(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -44,10 +44,10 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
- 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
+ 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c treeboot-walnut.c
+ ps3-head.S ps3-hvcall.S ps3.c treeboot-walnut.c treeboot-bamboo.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -143,6 +143,7 @@ image-$(CONFIG_PPC_83xx) += cuImage.83x
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_WALNUT) += treeImage.walnut
+image-$(CONFIG_BAMBOO) += treeImage.bamboo
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/bamboo.c
@@ -0,0 +1,126 @@
+/*
+ * Copyright IBM Corporation, 2007
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Based on ebony wrapper:
+ * Copyright 2007 David Gibson, IBM Corporation.
+ *
+ * Clocking code based on code by:
+ * Stefan Roese <sr@denx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the License
+ */
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "44x.h"
+
+extern char _dtb_start[];
+extern char _dtb_end[];
+
+#define SPRN_CCR1 0x378
+void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
+{
+ u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
+ u32 reg;
+ u32 fwdva, fwdvb, fbdv, lfbdv, opbdv0, perdv0, spcid0, prbdv0, tmp;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PLLD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x000F0000) >> 16;
+ fwdva = tmp ? tmp : 16;
+ tmp = (reg & 0x00000700) >> 8;
+ fwdvb = tmp ? tmp : 8;
+ tmp = (reg & 0x1F000000) >> 24;
+ fbdv = tmp ? tmp : 32;
+ lfbdv = (reg & 0x0000007F);
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_OPBD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x03000000) >> 24;
+ opbdv0 = tmp ? tmp : 4;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PERD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x07000000) >> 24;
+ perdv0 = tmp ? tmp : 8;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PRIMBD0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x07000000) >> 24;
+ prbdv0 = tmp ? tmp : 8;
+
+ mtdcr(DCRN_CPR0_ADDR, CPR0_SCPID);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x03000000) >> 24;
+ spcid0 = tmp ? tmp : 4;
+
+ /* Calculate M */
+ mtdcr(DCRN_CPR0_ADDR, CPR0_PLLC0);
+ reg = mfdcr(DCRN_CPR0_DATA);
+ tmp = (reg & 0x03000000) >> 24;
+ if (tmp == 0) { /* PLL output */
+ tmp = (reg & 0x20000000) >> 29;
+ if (!tmp) /* PLLOUTA */
+ m = fbdv * lfbdv * fwdva;
+ else
+ m = fbdv * lfbdv * fwdvb;
+ }
+ else if (tmp == 1) /* CPU output */
+ m = fbdv * fwdva;
+ else
+ m = perdv0 * opbdv0 * fwdvb;
+
+ vco = (m * sysclk) + (m >> 1);
+ cpu = vco / fwdva;
+ plb = vco / fwdvb / prbdv0;
+ opb = plb / opbdv0;
+ ebc = plb / perdv0;
+
+ /* FIXME */
+ uart0 = ser_clk;
+
+ /* Figure out timebase. Either CPU or default TmrClk */
+ asm volatile (
+ "mfspr %0,%1\n"
+ :
+ "=&r"(reg) : "i"(SPRN_CCR1));
+ if (reg & 0x0080)
+ tb = 25000000; /* TmrClk is 25MHz */
+ else
+ tb = cpu;
+
+ dt_fixup_cpu_clocks(cpu, tb, 0);
+ dt_fixup_clock("/plb", plb);
+ dt_fixup_clock("/plb/opb", opb);
+ dt_fixup_clock("/plb/opb/ebc", ebc);
+ dt_fixup_clock("/plb/opb/serial@ef600300", uart0);
+ dt_fixup_clock("/plb/opb/serial@ef600400", uart0);
+ dt_fixup_clock("/plb/opb/serial@ef600500", uart0);
+ dt_fixup_clock("/plb/opb/serial@ef600600", uart0);
+}
+
+static void bamboo_fixups(void)
+{
+ unsigned long sysclk = 33333333;
+ ibm440ep_fixup_clocks(sysclk, 11059200);
+ ibm4xx_fixup_memsize();
+ ibm4xx_reset_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+}
+
+void bamboo_init(void)
+{
+ platform_ops.fixups = bamboo_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ ft_init(_dtb_start, 0, 32);
+ serial_console_init();
+}
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -11,5 +11,6 @@
#define _PPC_BOOT_44X_H_
void ebony_init(void *mac0, void *mac1);
+void bamboo_init(void);
#endif /* _PPC_BOOT_44X_H_ */
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
@@ -0,0 +1,27 @@
+/*
+ * Copyright IBM Corporation, 2007
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Based on ebony wrapper:
+ * Copyright 2007 David Gibson, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the License
+ */
+#include "ops.h"
+#include "stdio.h"
+#include "44x.h"
+
+extern char _end[];
+
+BSS_STACK(4096);
+
+void platform_init(void)
+{
+ unsigned long end_of_ram = 0x8000000;
+ unsigned long avail_ram = end_of_ram - (unsigned long)_end;
+
+ simple_alloc_init(_end, avail_ram, 32, 64);
+ bamboo_init();
+}
--- linux-2.6.orig/arch/powerpc/boot/dcr.h
+++ linux-2.6/arch/powerpc/boot/dcr.h
@@ -123,4 +123,15 @@ static const unsigned long sdram_bxcr[]
#define DCRN_MAL0_CFG 0x180
+/* 440EP Clock/Power-on Reset regs */
+#define DCRN_CPR0_ADDR 0xc
+#define DCRN_CPR0_DATA 0xd
+#define CPR0_PLLD0 0x60
+#define CPR0_OPBD0 0xc0
+#define CPR0_PERD0 0xe0
+#define CPR0_PRIMBD0 0xa0
+#define CPR0_SCPID 0x120
+#define CPR0_PLLC0 0x40
+
+
#endif /* _PPC_BOOT_DCR_H_ */
--
^ permalink raw reply
* [patch 09/14] Walnut defconfig
From: Josh Boyer @ 2007-07-17 18:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070717181547.310201000@linux.vnet.ibm.com>
Walnut board defconfig
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
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 generated make config: don't edit
+# Linux kernel version: 2.6.22-rc4
+# Tue Jul 10 11:16:06 2007
+#
+# CONFIG_PPC64 is not set
+
+#
+# Processor support
+#
+# CONFIG_6xx is not set
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_8xx is not set
+CONFIG_40x=y
+# CONFIG_44x is not set
+# CONFIG_E200 is not set
+CONFIG_4xx=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_NOT_COHERENT_CACHE=y
+CONFIG_PPC32=y
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_IRQ_PER_CPU=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_ARCH_HAS_ILOG2_U32=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+# CONFIG_PPC_UDBG_16550 is not set
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_GENERIC_BUG=y
+# CONFIG_DEFAULT_UIMAGE is not set
+CONFIG_PPC_DCR_NATIVE=y
+# CONFIG_PPC_DCR_MMIO is not set
+CONFIG_PPC_DCR=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_IPC_NS is not set
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_UTS_NS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_SYSFS_DEPRECATED=y
+# CONFIG_RELAY is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_ANON_INODES=y
+CONFIG_EPOLL=y
+CONFIG_SIGNALFD=y
+CONFIG_TIMERFD=y
+CONFIG_EVENTFD=y
+CONFIG_SHMEM=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+CONFIG_KMOD=y
+
+#
+# Block layer
+#
+CONFIG_BLOCK=y
+CONFIG_LBD=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+
+#
+# Platform support
+#
+# CONFIG_PPC_MPC52xx is not set
+# CONFIG_PPC_MPC5200 is not set
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+# CONFIG_PQ2ADS is not set
+CONFIG_WALNUT=y
+CONFIG_405GP=y
+CONFIG_IBM405_ERR77=y
+CONFIG_IBM405_ERR51=y
+# CONFIG_MPIC is not set
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+# CONFIG_PPC_RTAS is not set
+# CONFIG_MMIO_NVRAM is not set
+# CONFIG_PPC_MPC106 is not set
+# CONFIG_PPC_970_NAP is not set
+# CONFIG_PPC_INDIRECT_IO is not set
+# CONFIG_GENERIC_IOMAP is not set
+# CONFIG_CPU_FREQ is not set
+# CONFIG_CPM2 is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_300 is not set
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_MATH_EMULATION is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+CONFIG_SECCOMP=y
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE="walnut.dts"
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_ZONE_DMA=y
+# CONFIG_PCI is not set
+# CONFIG_PCI_DOMAINS is not set
+# CONFIG_ARCH_SUPPORTS_MSI is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_CONSISTENT_START=0xff100000
+CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_BOOT_LOAD=0x00400000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+# CONFIG_IP_MULTICAST is not set
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_ARPD is not set
+# CONFIG_SYN_COOKIES is not set
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+# CONFIG_IP_DCCP is not set
+# CONFIG_IP_SCTP is not set
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_AF_RXRPC is not set
+
+#
+# Wireless
+#
+# CONFIG_CFG80211 is not set
+# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
+# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+CONFIG_FW_LOADER=y
+# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
+# CONFIG_SYS_HYPERVISOR is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+CONFIG_CONNECTOR=y
+CONFIG_PROC_EVENTS=y
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+# CONFIG_PNPACPI is not set
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+# CONFIG_BLK_DEV_LOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=35000
+CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# Misc devices
+#
+# CONFIG_BLINK is not set
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+# CONFIG_SCSI is not set
+# CONFIG_SCSI_NETLINK is not set
+# CONFIG_ATA is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+# CONFIG_NET_ETHERNET is not set
+# CONFIG_IBM_EMAC is not set
+CONFIG_NETDEV_1000=y
+CONFIG_NETDEV_10000=y
+
+#
+# Wireless LAN
+#
+# CONFIG_WLAN_PRE80211 is not set
+# CONFIG_WLAN_80211 is not set
+# CONFIG_WAN is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+# CONFIG_INPUT is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+CONFIG_SERIAL_8250_EXTENDED=y
+# CONFIG_SERIAL_8250_MANY_PORTS is not set
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+# CONFIG_SERIAL_8250_DETECT_IRQ is not set
+# CONFIG_SERIAL_8250_RSA is not set
+
+#
+# Non-8250 serial port support
+#
+# CONFIG_SERIAL_UARTLITE is not set
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+# CONFIG_WATCHDOG is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_NVRAM is not set
+# CONFIG_GEN_RTC is not set
+# CONFIG_R3964 is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_I2C is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+
+#
+# Dallas's 1-wire bus
+#
+# CONFIG_W1 is not set
+# CONFIG_HWMON is not set
+
+#
+# Multifunction device drivers
+#
+# CONFIG_MFD_SM501 is not set
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+# CONFIG_DVB_CORE is not set
+# CONFIG_DAB is not set
+
+#
+# Graphics support
+#
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+# CONFIG_VGASTATE is not set
+# CONFIG_FB is not set
+# CONFIG_FB_IBM_GXT4500 is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+# CONFIG_USB_ARCH_HAS_HCD is not set
+# CONFIG_USB_ARCH_HAS_OHCI is not set
+# CONFIG_USB_ARCH_HAS_EHCI is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+# CONFIG_MMC is not set
+
+#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
+# InfiniBand support
+#
+
+#
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
+#
+
+#
+# Real Time Clock
+#
+# CONFIG_RTC_CLASS is not set
+
+#
+# DMA Engine support
+#
+# CONFIG_DMA_ENGINE is not set
+
+#
+# DMA Clients
+#
+
+#
+# DMA Devices
+#
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+# CONFIG_EXT3_FS is not set
+# CONFIG_EXT4DEV_FS is not set
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_GFS2_FS is not set
+# CONFIG_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+CONFIG_CRAMFS=y
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+# CONFIG_NFS_V4 is not set
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
+# CONFIG_RPCSEC_GSS_KRB5 is not set
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
+
+#
+# Partition Types
+#
+# CONFIG_PARTITION_ADVANCED is not set
+CONFIG_MSDOS_PARTITION=y
+
+#
+# Native Language Support
+#
+# CONFIG_NLS is not set
+
+#
+# Distributed Lock Manager
+#
+# CONFIG_DLM is not set
+# CONFIG_UCC_SLOW is not set
+
+#
+# Library routines
+#
+CONFIG_BITREVERSE=y
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
+CONFIG_CRC32=y
+# CONFIG_LIBCRC32C is not set
+CONFIG_ZLIB_INFLATE=y
+CONFIG_PLIST=y
+CONFIG_HAS_IOMEM=y
+CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
+
+#
+# Instrumentation Support
+#
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_MUST_CHECK=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_FS is not set
+# CONFIG_HEADERS_CHECK is not set
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DETECT_SOFTLOCKUP=y
+# CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
+# CONFIG_DEBUG_SLAB is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
+# CONFIG_DEBUG_SPINLOCK is not set
+# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
+# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
+# CONFIG_DEBUG_KOBJECT is not set
+CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_DEBUG_INFO is not set
+# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_LIST is not set
+CONFIG_FORCED_INLINING=y
+# CONFIG_RCU_TORTURE_TEST is not set
+# CONFIG_FAULT_INJECTION is not set
+# CONFIG_DEBUG_STACKOVERFLOW is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+# CONFIG_DEBUGGER is not set
+# CONFIG_BDI_SWITCH is not set
+# CONFIG_BOOTX_TEXT is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_BLKCIPHER=y
+CONFIG_CRYPTO_MANAGER=y
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_XCBC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+CONFIG_CRYPTO_MD5=y
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+# CONFIG_CRYPTO_GF128MUL is not set
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=y
+# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_CRYPTD is not set
+CONFIG_CRYPTO_DES=y
+# CONFIG_CRYPTO_FCRYPT is not set
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_CAMELLIA is not set
+# CONFIG_CRYPTO_TEST is not set
+
+#
+# Hardware crypto devices
+#
--
^ 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