* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Olof Johansson @ 2008-01-10 3:17 UTC (permalink / raw)
To: Linas Vepstas; +Cc: mahuja, linuxppc-dev, lkessler, Nathan Lynch, strosake
In-Reply-To: <3ae3aa420801091833i6cf32616o2a060579be1f3191@mail.gmail.com>
On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
> Heh. That's the elbow-grease of this thing. The easy part is to get
> the core function working. The hard part is to test these various configs,
> and when they don't work, figure out what went wrong. That will take
> perseverence and brains.
This just sounds like a whole lot of extra work to get a feature that
already exists. Also, features like these seem to just get tested when the
next enterprise distro is released, so they're broken for long stretches
of time in mainline.
There's a bunch of problems like the NUMA ones, which would by far be
easiest to solve by just doing another reboot or kexec, wouldn't they?
-Olof
^ permalink raw reply
* Re: How complete should the DTS be?
From: David Gibson @ 2008-01-10 3:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <86AA8535-E2CF-4891-900B-340049A5CA19@kernel.crashing.org>
On Tue, Jan 08, 2008 at 12:04:36AM -0600, Kumar Gala wrote:
>
> On Jan 7, 2008, at 8:07 PM, Sean MacLennan wrote:
>
> > Just a general question about DTS "completeness". Like all 440EP
> > processors, the taco has two i2c buses. However, only one bus has
> > anything connected to it.
> >
> > Should I show both bus entries in the DTS, or only the one that is
> > used?
> > I have generally only been showing the devices that are present. i.e.
> > Only one emac, only one serial port.
> >
> > Is there a convention for this?
>
> The .dts should reflect the HW as its used. On some reference boards
> we might put out more info because of the various configs these types
> of boards can be setup in. However if something has a static config
> just describe that. So in your example of two i2c buses with only one
> connected, just describe the one that is used.
Hrm... I'd say this is not something which has a firm convention yet.
It's going to become more of an issue once we get a macros system for
dtc, so the "440EP" macro would have all the devices, even if some are
not connected on a given board.
I'm contemplating suggesting that we adopt the "status" property from
IEEE1275 to cover this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/5] Warp Base Platform - dts
From: Sean MacLennan @ 2008-01-10 3:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080110024753.GC17816@localhost.localdomain>
David Gibson wrote:
> On Wed, Jan 09, 2008 at 03:21:07PM -0500, Sean MacLennan wrote:
>
>> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>> ---
>> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
>> +++ arch/powerpc/boot/dts/warp.dts 2008-01-08 12:04:10.000000000 -0500
>>
>
> [snip]
>
>> + plb {
>> + compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + ranges;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> +
>> + SDRAM0: sdram {
>> + compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
>> + dcr-reg = <010 2>;
>> + };
>> +
>> + DMA0: dma {
>> + compatible = "ibm,dma-440ep", "ibm,dma-440gp";
>> + dcr-reg = <100 027>;
>> + };
>> +
>> + FPGA0: fpga {
>>
>
> Surely this must be off the EBC, not directly of the PLB...?
>
Could be, I don't really know :( I will move it if it makes more sense.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 3/5] Warp Base Platform
From: Sean MacLennan @ 2008-01-10 3:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080110024926.GD17816@localhost.localdomain>
David Gibson wrote:
> On Wed, Jan 09, 2008 at 03:22:46PM -0500, Sean MacLennan wrote:
>
>> Basically the powerpc/boot directory files.
>>
>
> [snip]
>
>> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
>> +++ arch/powerpc/boot/cuboot-warp.c 2008-01-08 12:09:39.000000000 -0500
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Copyright (c) 2008 PIKA Technologies
>> + * Sean MacLennan <smaclennan@pikatech.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published
>> + * by the Free Software Foundation.
>> + */
>> +
>> +#include "ops.h"
>> +#include "44x.h"
>> +#include "cuboot.h"
>> +
>> +#define TARGET_44x
>> +#include "ppcboot.h"
>> +
>> +static bd_t bd;
>> +
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> + CUBOOT_INIT();
>> +
>> + warp_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
>> +}
>> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
>> +++ arch/powerpc/boot/warp.c 2008-01-08 12:09:54.000000000 -0500
>>
>
> Fold all this into cuboot-warp.c, unless you actually anticipate
> adding another wrapper for another firmware which will also use the
> functions in warp.c.
>
>
Yes, there is still a plan to use the u-boot device tree. Although not
in the near feature. I could roll them togeather for now and split them
out later.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 2/5] Warp Base Platform - dts
From: Josh Boyer @ 2008-01-10 3:17 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47858D89.4070706@pikatech.com>
On Wed, 09 Jan 2008 22:14:17 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> David Gibson wrote:
> > On Wed, Jan 09, 2008 at 03:21:07PM -0500, Sean MacLennan wrote:
> >
> >> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> >> ---
> >> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
> >> +++ arch/powerpc/boot/dts/warp.dts 2008-01-08 12:04:10.000000000 -0500
> >>
> >
> > [snip]
> >
> >> + plb {
> >> + compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
> >> + #address-cells = <2>;
> >> + #size-cells = <1>;
> >> + ranges;
> >> + clock-frequency = <0>; /* Filled in by zImage */
> >> +
> >> + SDRAM0: sdram {
> >> + compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
> >> + dcr-reg = <010 2>;
> >> + };
> >> +
> >> + DMA0: dma {
> >> + compatible = "ibm,dma-440ep", "ibm,dma-440gp";
> >> + dcr-reg = <100 027>;
> >> + };
> >> +
> >> + FPGA0: fpga {
> >>
> >
> > Surely this must be off the EBC, not directly of the PLB...?
> >
> Could be, I don't really know :( I will move it if it makes more sense.
Well, "making more sense" would be finding out where it is on the board
and putting it in the proper place :).
josh
^ permalink raw reply
* Re: [PATCH 3/5] Warp Base Platform
From: David Gibson @ 2008-01-10 3:29 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47858E46.9010505@pikatech.com>
On Wed, Jan 09, 2008 at 10:17:26PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > On Wed, Jan 09, 2008 at 03:22:46PM -0500, Sean MacLennan wrote:
> >
> >> Basically the powerpc/boot directory files.
> >>
> >
> > [snip]
> >
> >> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
> >> +++ arch/powerpc/boot/cuboot-warp.c 2008-01-08 12:09:39.000000000 -0500
> >> @@ -0,0 +1,25 @@
> >> +/*
> >> + * Copyright (c) 2008 PIKA Technologies
> >> + * Sean MacLennan <smaclennan@pikatech.com>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General Public License version 2 as published
> >> + * by the Free Software Foundation.
> >> + */
> >> +
> >> +#include "ops.h"
> >> +#include "44x.h"
> >> +#include "cuboot.h"
> >> +
> >> +#define TARGET_44x
> >> +#include "ppcboot.h"
> >> +
> >> +static bd_t bd;
> >> +
> >> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> >> + unsigned long r6, unsigned long r7)
> >> +{
> >> + CUBOOT_INIT();
> >> +
> >> + warp_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
> >> +}
> >> --- /dev/null 2005-11-20 22:22:37.000000000 -0500
> >> +++ arch/powerpc/boot/warp.c 2008-01-08 12:09:54.000000000 -0500
> >>
> >
> > Fold all this into cuboot-warp.c, unless you actually anticipate
> > adding another wrapper for another firmware which will also use the
> > functions in warp.c.
> >
> >
> Yes, there is still a plan to use the u-boot device tree. Although not
> in the near feature. I could roll them togeather for now and split them
> out later.
Yes, but device-tree aware u-boot doesn't need anything platform
specific in the bootwrapper, so won't be a second user of warp.c.
--
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
* Re: [PATCH 2/5] Warp Base Platform - dts
From: Sean MacLennan @ 2008-01-10 3:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080109211758.26c8e235@zod.rchland.ibm.com>
Ok, the FPGA is off the EBC, I found it in the documentation.
Under the ebc, I notice the walnut has @n,m. What are n,m? Are they tied
to chip selects?
The FPGA is CS2 according to the documentation. Do I make it fpga@2,0?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 2/5] Warp Base Platform - dts
From: Josh Boyer @ 2008-01-10 3:36 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47859224.70109@pikatech.com>
On Wed, 09 Jan 2008 22:33:56 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Ok, the FPGA is off the EBC, I found it in the documentation.
>
> Under the ebc, I notice the walnut has @n,m. What are n,m? Are they tied
> to chip selects?
chip select,offset.
> The FPGA is CS2 according to the documentation. Do I make it fpga@2,0?
If the fpga is on chip select 2, offset 0 from that, yes. Otherwise,
substitute the proper offset in place of 0.
The ranges property of the EBC node will do the actual address
translation.
josh
^ permalink raw reply
* Re: [PATCH 2/5] Warp Base Platform - dts
From: David Gibson @ 2008-01-10 3:35 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <47859224.70109@pikatech.com>
On Wed, Jan 09, 2008 at 10:33:56PM -0500, Sean MacLennan wrote:
> Ok, the FPGA is off the EBC, I found it in the documentation.
>
> Under the ebc, I notice the walnut has @n,m. What are n,m? Are they tied
> to chip selects?
n is the chipselect, m is the address offset within that chipselect.
> The FPGA is CS2 according to the documentation. Do I make it
> fpga@2,0?
Probably, yes.
--
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
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-10 3:49 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <20080107182853.GA17312@sirena.org.uk>
On Mon, Jan 07, 2008 at 06:28:54PM +0000, Mark Brown wrote:
> On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
> > David Gibson wrote:
>
> > > Ok, but couldn't you strucutre your I2S or fabric driver so that it
> > > only becomes fully operational once the codec driver has registered
> > > with it?
>
> > Not in ASoC V1. You have to understand, ASoC V1 was designed without any
> > consideration for runtime-bindings and other OF goodies. All connections
> > between the drivers are static, literally. In fact, I wouldn't be surprised if
> > some ASoC drivers cannot be compiled as modules.
>
> I'd just like to emphasise this point - ASoC v1 really doesn't
> understand the idea that the components of the sound subsystem might be
> probed separately. It's set up to handle bare hardware with everything
> being probed from code in the machine/fabric driver. This makes life
> very messy for platforms with something like the device tree.
>
> As has been said, handling this properly is one of the major motivations
> behind ASoC v2.
Ick. Ok.
Nonetheless, messing up the device tree to workaround ASoC V1's silly
limitations is not a good idea. The device tree must represent the
hardware as much as possible. If that means we have to have a bunch
of platform-specific hacks to instatiate the drivers in the correct
order / combination, that's unfortunate, but there you go.
--
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
* Re: [PATCH 2/3] Look for include files in the directory of the including file.
From: David Gibson @ 2008-01-10 3:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080106225252.GB8239@ld0162-tx32.am.freescale.net>
On Sun, Jan 06, 2008 at 04:52:52PM -0600, Scott Wood wrote:
> On Fri, Jan 04, 2008 at 03:27:39PM +1100, David Gibson wrote:
> > > + newfile = dtc_open_file(filename, searchptr);
> > > + if (!newfile) {
> > > + yyerrorf("Couldn't open \"%s\": %s",
> > > + filename, strerror(errno));
> > > + exit(1);
> >
> > Use die() here, that's what it's for.
>
> die() doesn't print file and line information.
>
> > > + while (search) {
> > > + if (dtc_open_one(file, search->dir, fname))
> > > + return file;
> >
> > Don't we need a different case here somewhere for if someone specifies
> > an include file as an absolute path? Have I missed something?
>
> Yeah, I forgot about that, and sent another patch to fix it when I
> noticed (jdl had already pulled, so I didn't send an amended patch).
>
> > [snip]
> > > +struct search_path {
> > > + const char *dir; /* NULL for current directory */
> > > + struct search_path *prev, *next;
> > > +};
> >
> > I wouldn't suggest a doubly linked list here. Or at least not without
> > converting our many existing singly linked lists at the same time.
>
> The doubly-linked list is intended to make it easier to construct search
> path lists one-at-a-time from arguments in the proper order, without
> needing to reverse the list at the end.
We've already got that problem with a bunch of the lists we create
during parsing (we have several ugly add-to-end-of-singly-linked-list
functions). Going to doubly-linked lists might not be a bad idea, but
we should do it across the board, probably using the kernel's list.h
or something like it.
--
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
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Michael Ellerman @ 2008-01-10 3:55 UTC (permalink / raw)
To: linasvepstas; +Cc: mahuja, linuxppc-dev, lkessler, Nathan Lynch, strosake
In-Reply-To: <3ae3aa420801091847l189df8dwb2348624f0267af@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3344 bytes --]
On Wed, 2008-01-09 at 20:47 -0600, Linas Vepstas wrote:
> On 09/01/2008, Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > > > Only if you can get at rtas, but you can't get at rtas at that point.
> >
> > AFAICT you don't need to get at RTAS, you just need to look at the
> > device tree to see if the property is present, and that is trivial.
> >
> > You probably just need to add a check in early_init_dt_scan_rtas() which
> > sets a flag for the PHYP dump stuff, or add your own scan routine if you
> > need.
>
> I no longer remember the details. I do remember spending a lot of time
> trying to figure out how to do this. I know I didn't want to write my own scan
> routine; maybe that's what stopped me. As it happens, we also did most
> of the development on a broken phyp which simply did not even have
> this property, no matter what, and so that may have brain-damaged me.
Sure, the API docs for the kernel are a little lacking ;)
> I went for the "most elegant" solution, where "most elegant" is defined
> as "fewest lines of code", "least effort", etc.
>
> Manish may need some hands-on help to extract this token during
> early boot. Hopefully, he'll let us know.
It would just be something like:
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -901,6 +901,11 @@ int __init early_init_dt_scan_rtas(unsigned long node,
rtas.size = *sizep;
}
+#ifdef CONFIG_PHYP_DUMP
+ if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
+ phyp_dump_is_active++;
+#endif
+
#ifdef CONFIG_UDBG_RTAS_CONSOLE
basep = of_get_flat_dt_prop(node, "put-term-char", NULL);
if (basep)
Or to do your own scan routine:
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index acc0d24..442134e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1022,6 +1022,7 @@ void __init early_init_devtree(void *params)
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
#endif
+ of_scan_flat_dt(early_init_dt_scan_phyp_dump, NULL);
/* Retrieve various informations from the /chosen node of the
* device-tree, including the platform type, initrd location and
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 52e95c2..af2b6e8 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -883,6 +883,19 @@ void __init rtas_initialize(void)
#endif
}
+int __init early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+#ifdef CONFIG_PHYP_DUMP
+ if (depth != 1 || strcmp(uname, "rtas") != 0)
+ return 0;
+
+ if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
+ phyp_dump_is_active++;
+#endif
+ return 1;
+}
+
int __init early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data)
{
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 3/3] Return a non-zero exit code if an error occurs during dts parsing.
From: David Gibson @ 2008-01-10 3:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080106225509.GC8239@ld0162-tx32.am.freescale.net>
On Sun, Jan 06, 2008 at 04:55:09PM -0600, Scott Wood wrote:
> On Fri, Jan 04, 2008 at 03:30:33PM +1100, David Gibson wrote:
> > This is unequivocally wrong. boot_info should have information about
> > the contents of the blob, not state information like the error.
>
> "This blob is invalid" *is* information about the contents of the blob.
>
> > If you're going to use an ugly global, then use it everywhere.
>
> Why go out of our way to make the code even less library-able/thread-safe?
It doesn't make it any less thread-safe. A global variable used some
places is just as bad as a global variable used everywhere from that
point of view, and is more complicated.
--
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
* Re: [DTC PATCH 2/2] Preserve scanner state when /include/ing.
From: David Gibson @ 2008-01-10 4:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080107202751.GB17782@ld0162-tx32.am.freescale.net>
On Mon, Jan 07, 2008 at 02:27:51PM -0600, Scott Wood wrote:
> This allows /include/s to work when in non-default states,
> such as PROPNODECHAR.
>
> We may want to use state stacks to get rid of BEGIN_DEFAULT() altogether...
And we should, if we're going to go to stacked states at all. I was
anticipating we might need to use stacked states for handling
propnamestate as we need expression support. I just hadn't realised
we already needed it for includes.
--
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
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Linas Vepstas @ 2008-01-10 4:12 UTC (permalink / raw)
To: Olof Johansson; +Cc: mahuja, linuxppc-dev, lkessler, Nathan Lynch, strosake
In-Reply-To: <20080110031723.GA22168@lixom.net>
On 09/01/2008, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
>
> > Heh. That's the elbow-grease of this thing. The easy part is to get
> > the core function working. The hard part is to test these various configs,
> > and when they don't work, figure out what went wrong. That will take
> > perseverence and brains.
>
> This just sounds like a whole lot of extra work to get a feature that
> already exists.
Well, no. kexec is horribly ill-behaved with respect to PCI. The
kexec kernel starts running with PCI devices in some random
state; maybe they're DMA'ing or who knows what. kexec tries
real hard to whack a few needed pci devices into submission
but it has been hit-n-miss, and the source of 90% of the kexec
headaches and debugging effort. Its not pretty.
If all pci-host bridges could shut-down or settle the bus, and
raise the #RST line high, and then if all BIOS'es supported
this, you'd be right. But they can't ....
--linas
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Michael Ellerman @ 2008-01-10 4:52 UTC (permalink / raw)
To: linasvepstas
Cc: linuxppc-dev, lkessler, mahuja, Nathan Lynch, Olof Johansson,
strosake
In-Reply-To: <3ae3aa420801092012m5e47cbd7lc7a5f91842074af7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
On Wed, 2008-01-09 at 22:12 -0600, Linas Vepstas wrote:
> On 09/01/2008, Olof Johansson <olof@lixom.net> wrote:
> > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote:
> >
> > > Heh. That's the elbow-grease of this thing. The easy part is to get
> > > the core function working. The hard part is to test these various configs,
> > > and when they don't work, figure out what went wrong. That will take
> > > perseverence and brains.
> >
> > This just sounds like a whole lot of extra work to get a feature that
> > already exists.
>
> Well, no. kexec is horribly ill-behaved with respect to PCI. The
> kexec kernel starts running with PCI devices in some random
> state; maybe they're DMA'ing or who knows what. kexec tries
> real hard to whack a few needed pci devices into submission
> but it has been hit-n-miss, and the source of 90% of the kexec
> headaches and debugging effort. Its not pretty.
Isn't that what EEH and the IOMMU are for? :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] add phy-handle property for fec_mpc52xx
From: Benjamin Herrenschmidt @ 2008-01-10 5:01 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, olaf, sven
In-Reply-To: <20080109163058.21643.30876.stgit@trillian.secretlab.ca>
On Wed, 2008-01-09 at 09:32 -0700, Grant Likely wrote:
> From: Olaf Hering <olaf@aepfle.de>
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>
> (Olaf's s-o-b line needs to go here)
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
As much as I despise having to work around firmware bugs, it looks
indeed like this one has been broken for way too long to the point where
users are being hurt, distros are being hurt, and telling people to
whack things in nvramrc is just plain gross, so let's merge it.
> ---
>
> Here's my respin of Olaf's patch to move it to fixup_device_tree_efika()
> and to make it check if the nodes exist before blindly creating them.
>
> Cheers,
> g.
>
> arch/powerpc/kernel/prom_init.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 1add6ef..5d89a21 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2216,6 +2216,45 @@ static void __init fixup_device_tree_efika(void)
> prom_printf("fixup_device_tree_efika: ",
> "skipped entry %x - setprop error\n", i);
> }
> +
> + /* Make sure ethernet mdio bus node exists */
> + node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio"));
> + if (!PHANDLE_VALID(node)) {
> + prom_printf("Adding Ethernet MDIO node\n");
> + call_prom("interpret", 1, 1,
> + " s\" /builtin\" find-device"
> + " new-device"
> + " 1 encode-int s\" #address-cells\" property"
> + " 0 encode-int s\" #size-cells\" property"
> + " s\" mdio\" 2dup device-name device-type"
> + " s\" mpc5200b-fec-phy\" encode-string"
> + " s\" compatible\" property"
> + " 0xf0003000 0x400 reg"
> + " 0x2 encode-int"
> + " 0x5 encode-int encode+"
> + " 0x3 encode-int encode+"
> + " s\" interrupts\" property"
> + " finish-device");
> + };
> +
> + /* Make sure ethernet phy device node exist */
> + node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio/ethernet-phy"));
> + if (!PHANDLE_VALID(node)) {
> + prom_printf("Adding Ethernet PHY node\n");
> + call_prom("interpret", 1, 1,
> + " s\" /builtin/mdio\" find-device"
> + " new-device"
> + " s\" ethernet-phy\" device-name"
> + " 0x10 encode-int s\" reg\" property"
> + " my-self"
> + " ihandle>phandle"
> + " finish-device"
> + " s\" /builtin/ethernet\" find-device"
> + " encode-int"
> + " s\" phy-handle\" property"
> + " device-end");
> + }
> +
> }
> #else
> #define fixup_device_tree_efika()
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Benjamin Herrenschmidt @ 2008-01-10 5:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Olaf Hering, David Woodhouse
In-Reply-To: <18309.33088.653225.116715@cargo.ozlabs.ibm.com>
On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > It would be much better if the kernel would 'just work'. The ideal way
> > of achieving that is for the firmware to be fixed -- but that's been
> > promised for a long time now, and we just don't believe you any more. So
> > working round it in the kernel seems to be the next best option.
>
> Does the efika use a boot wrapper? If so then putting the fixup in
> the boot wrapper might be better.
It's standard OF boot process, the fixup belongs in prom_init. Grant has
a better version of the patch that puts the fixup along with other efika
related ones that are already there.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC] add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-10 5:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, olaf, sven
In-Reply-To: <1199941261.6734.224.camel@pasglop>
On 1/9/08, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Wed, 2008-01-09 at 09:32 -0700, Grant Likely wrote:
> > From: Olaf Hering <olaf@aepfle.de>
> >
> > This should go into the kernel because its appearently
> > impossible to boot the script via tftp and then load the real boot
> > binary (yaboot or zimage).
> >
> > (Olaf's s-o-b line needs to go here)
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> As much as I despise having to work around firmware bugs, it looks
> indeed like this one has been broken for way too long to the point where
> users are being hurt, distros are being hurt, and telling people to
> whack things in nvramrc is just plain gross, so let's merge it.
Thanks Ben.
Olaf, can you please reply with your signed-off-by line? Then I'll
ask paulus to pick this up for .24
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.
From: David Gibson @ 2008-01-10 5:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080106224623.GA8239@ld0162-tx32.am.freescale.net>
On Sun, Jan 06, 2008 at 04:46:24PM -0600, Scott Wood wrote:
> On Sun, Jan 06, 2008 at 02:37:16PM +1100, David Gibson wrote:
> > > out:
> > > + free((void *)file->dir);
> >
> > That cast shouldn't be there.
>
> It generates a constness warning otherwise. I was on the fence over
> whether to just remove the constness (even though the data is never
> modified during its lifetime); would that be preferable?
I think that is preferable.
--
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
* [PATCH V3] [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
From: Grant Likely @ 2008-01-10 5:26 UTC (permalink / raw)
To: sfr, linuxppc-dev, dragos.carp
From: Grant Likely <grant.likely@secretlab.ca>
PSC drivers should not access the CDM registers directly. Instead provide
a common routine for setting the PSC clock parameters with the required
locking.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/52xx/efika.c | 3 +
arch/powerpc/platforms/52xx/lite5200.c | 10 ++--
arch/powerpc/platforms/52xx/mpc5200_simple.c | 6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 65 ++++++++++++++++++++++++--
arch/ppc/syslib/mpc52xx_setup.c | 36 ++++++++++++++
include/asm-powerpc/mpc52xx.h | 9 ++--
6 files changed, 114 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c b/arch/powerpc/platforms/52xx/efika.c
index a0da70c..a2068fa 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -180,6 +180,9 @@ static void __init efika_setup_arch(void)
{
rtas_initialize();
+ /* Map important registers from the internal memory map */
+ mpc52xx_map_common_devices();
+
efika_pcisetup();
#ifdef CONFIG_PM
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index f8ba5f2..42e87b6 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -150,15 +150,15 @@ static void __init lite5200_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("lite5200_setup_arch()", 0);
- /* Fix things that firmware should have done. */
- lite5200_fix_clock_config();
- lite5200_fix_port_config();
+ /* Map important registers from the internal memory map */
+ mpc52xx_map_common_devices();
/* Some mpc5200 & mpc5200b related configuration */
mpc5200_setup_xlb_arbiter();
- /* Map wdt for mpc52xx_restart() */
- mpc52xx_map_wdt();
+ /* Fix things that firmware should have done. */
+ lite5200_fix_clock_config();
+ lite5200_fix_port_config();
#ifdef CONFIG_PM
mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index 754aa93..c48b82b 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -39,12 +39,12 @@ static void __init mpc5200_simple_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc5200_simple_setup_arch()", 0);
+ /* Map important registers from the internal memory map */
+ mpc52xx_map_common_devices();
+
/* Some mpc5200 & mpc5200b related configuration */
mpc5200_setup_xlb_arbiter();
- /* Map wdt for mpc52xx_restart() */
- mpc52xx_map_wdt();
-
mpc52xx_setup_pci();
}
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 0211890..bf842e0 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -13,6 +13,7 @@
#undef DEBUG
#include <linux/kernel.h>
+#include <linux/spinlock.h>
#include <linux/of_platform.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -24,7 +25,9 @@
* from interrupt context while node mapping (which calls ioremap())
* cannot be used at such point.
*/
-static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
+static spinlock_t mpc52xx_lock = SPIN_LOCK_UNLOCKED;
+static struct mpc52xx_gpt __iomem *mpc52xx_wdt;
+static struct mpc52xx_cdm __iomem *mpc52xx_cdm;
/**
* mpc52xx_find_ipb_freq - Find the IPB bus frequency for a device
@@ -121,18 +124,27 @@ mpc52xx_declare_of_platform_devices(void)
}
/*
- * match tables used by mpc52xx_map_wdt()
+ * match tables used by mpc52xx_map_common_devices()
*/
static struct of_device_id mpc52xx_gpt_ids[] __initdata = {
{ .compatible = "fsl,mpc5200-gpt", },
{ .compatible = "mpc5200-gpt", }, /* old */
{}
};
+static struct of_device_id mpc52xx_cdm_ids[] __initdata = {
+ { .compatible = "fsl,mpc5200-cdm", },
+ { .compatible = "mpc5200-cdm", }, /* old */
+ {}
+};
+/**
+ * mpc52xx_map_common_devices: iomap devices required by common code
+ */
void __init
-mpc52xx_map_wdt(void)
+mpc52xx_map_common_devices(void)
{
struct device_node *np;
+
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
* possibly from a interrupt context. wdt is only implement
* on a gpt0, so check has-wdt property before mapping.
@@ -142,11 +154,56 @@ mpc52xx_map_wdt(void)
of_get_property(np, "has-wdt", NULL)) {
mpc52xx_wdt = of_iomap(np, 0);
of_node_put(np);
- return;
+ break;
}
}
+
+ /* Clock Distribution Module, used by PSC clock setting function */
+ np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
+ mpc52xx_cdm = of_iomap(np, 0);
+ of_node_put(np);
}
+/**
+ * mpc52xx_set_psc_clkdiv: Set clock divider in the CDM for PSC ports
+ *
+ * @psc_id: id of psc port; must be 1,2,3 or 6
+ * @clkdiv: clock divider value to put into CDM PSC register.
+ */
+int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
+{
+ unsigned long flags;
+ u16 __iomem *reg;
+ u32 val;
+ u32 mask;
+ u32 mclken_div;
+
+ if (!mpc52xx_cdm)
+ return -ENODEV;
+
+ mclken_div = 0x8000 | (clkdiv & 0x1FF);
+ switch (psc_id) {
+ case 1: reg = &mpc52xx_cdm->mclken_div_psc1; mask = 0x20; break;
+ case 2: reg = &mpc52xx_cdm->mclken_div_psc2; mask = 0x40; break;
+ case 3: reg = &mpc52xx_cdm->mclken_div_psc3; mask = 0x80; break;
+ case 6: reg = &mpc52xx_cdm->mclken_div_psc6; mask = 0x10; break;
+ default:
+ return -ENODEV;
+ }
+
+ /* Set the rate and enable the clock */
+ spin_lock_irqsave(&mpc52xx_lock, flags);
+ out_be16(reg, mclken_div);
+ val = in_be32(&mpc52xx_cdm->clk_enables);
+ out_be32(&mpc52xx_cdm->clk_enables, val | mask);
+ spin_unlock_irqrestore(&mpc52xx_lock, flags);
+
+ return 0;
+}
+
+/**
+ * mpc52xx_restart: ppc_md->restart hook for mpc5200 using the watchdog timer
+ */
void
mpc52xx_restart(char *cmd)
{
diff --git a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
index ecfa2c0..9f504fc 100644
--- a/arch/ppc/syslib/mpc52xx_setup.c
+++ b/arch/ppc/syslib/mpc52xx_setup.c
@@ -16,6 +16,7 @@
*/
+#include <linux/spinlock.h>
#include <asm/io.h>
#include <asm/time.h>
#include <asm/mpc52xx.h>
@@ -275,3 +276,38 @@ int mpc52xx_match_psc_function(int psc_idx, const char *func)
return 0;
}
+
+int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
+{
+ static spinlock_t lock = SPIN_LOCK_UNLOCKED;
+ struct mpc52xx_cdm __iomem *cdm;
+ unsigned long flags;
+ u16 mclken_div;
+ u16 __iomem *reg;
+ u32 mask;
+
+ cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
+ if (!cdm) {
+ printk(KERN_ERR __FILE__ ": Error mapping CDM\n");
+ return -ENODEV;
+ }
+
+ mclken_div = 0x8000 | (clkdiv & 0x1FF);
+ switch (psc_id) {
+ case 1: reg = &cdm->mclken_div_psc1; mask = 0x20; break;
+ case 2: reg = &cdm->mclken_div_psc2; mask = 0x40; break;
+ case 3: reg = &cdm->mclken_div_psc3; mask = 0x80; break;
+ case 6: reg = &cdm->mclken_div_psc6; mask = 0x10; break;
+ default:
+ return -ENODEV;
+ }
+
+ /* Set the rate and enable the clock */
+ spin_lock_irqsave(&lock, flags);
+ out_be16(reg, mclken_div);
+ out_be32(&cdm->clk_enables, in_be32(&cdm->clk_enables) | mask);
+ spin_unlock_irqrestore(&lock, flags);
+
+ iounmap(cdm);
+ return 0;
+}
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 1c48c6d..81ef10b 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -248,13 +248,19 @@ struct mpc52xx_cdm {
#ifndef __ASSEMBLY__
+/* mpc52xx_common.c */
extern unsigned int mpc52xx_find_ipb_freq(struct device_node *node);
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
+extern void mpc52xx_map_common_devices(void);
+extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
+extern void mpc52xx_restart(char *cmd);
+/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
+/* mpc52xx_pci.c */
#ifdef CONFIG_PCI
extern int __init mpc52xx_add_bridge(struct device_node *node);
extern void __init mpc52xx_setup_pci(void);
@@ -262,9 +268,6 @@ extern void __init mpc52xx_setup_pci(void);
static inline void mpc52xx_setup_pci(void) { }
#endif
-extern void __init mpc52xx_map_wdt(void);
-extern void mpc52xx_restart(char *cmd);
-
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_PM
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-10 5:41 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <20080110034919.GI17816@localhost.localdomain>
On 1/9/08, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Jan 07, 2008 at 06:28:54PM +0000, Mark Brown wrote:
> > On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
> > > David Gibson wrote:
> >
> > > > Ok, but couldn't you strucutre your I2S or fabric driver so that it
> > > > only becomes fully operational once the codec driver has registered
> > > > with it?
> >
> > > Not in ASoC V1. You have to understand, ASoC V1 was designed without any
> > > consideration for runtime-bindings and other OF goodies. All connections
> > > between the drivers are static, literally. In fact, I wouldn't be surprised if
> > > some ASoC drivers cannot be compiled as modules.
> >
> > I'd just like to emphasise this point - ASoC v1 really doesn't
> > understand the idea that the components of the sound subsystem might be
> > probed separately. It's set up to handle bare hardware with everything
> > being probed from code in the machine/fabric driver. This makes life
> > very messy for platforms with something like the device tree.
> >
> > As has been said, handling this properly is one of the major motivations
> > behind ASoC v2.
>
> Ick. Ok.
>
> Nonetheless, messing up the device tree to workaround ASoC V1's silly
> limitations is not a good idea. The device tree must represent the
> hardware as much as possible. If that means we have to have a bunch
> of platform-specific hacks to instatiate the drivers in the correct
> order / combination, that's unfortunate, but there you go.
ASOC v2 is sitting on a Wolfson server out of tree. I have been using
it for several months without problem. The pace of it being merged
could probably be sped up.
>
> --
> 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
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: How complete should the DTS be?
From: Sean MacLennan @ 2008-01-10 5:53 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In-Reply-To: <20080110031331.GF17816@localhost.localdomain>
David Gibson wrote:
> Hrm... I'd say this is not something which has a firm convention yet.
> It's going to become more of an issue once we get a macros system for
> dtc, so the "440EP" macro would have all the devices, even if some are
> not connected on a given board.
>
> I'm contemplating suggesting that we adopt the "status" property from
> IEEE1275 to cover this.
>
>
When I am laying out the dts, leaving out what isn't used makes the dts
file cleaner, at least in my view. It doesn't hurt to have the second
i2c bus there, but it also doesn't help and leaving it out points out
that it is not used.
When we get a macro system I assume the second i2c bus will be there but
hidden by a macro. It will still be clean and shouldn't cause grief.
Cheers,
Sean
^ permalink raw reply
* Re: How complete should the DTS be?
From: David Gibson @ 2008-01-10 6:02 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <4785B2F5.6040001@pikatech.com>
On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > Hrm... I'd say this is not something which has a firm convention yet.
> > It's going to become more of an issue once we get a macros system for
> > dtc, so the "440EP" macro would have all the devices, even if some are
> > not connected on a given board.
> >
> > I'm contemplating suggesting that we adopt the "status" property from
> > IEEE1275 to cover this.
> >
> >
> When I am laying out the dts, leaving out what isn't used makes the dts
> file cleaner, at least in my view. It doesn't hurt to have the second
> i2c bus there, but it also doesn't help and leaving it out points out
> that it is not used.
>
> When we get a macro system I assume the second i2c bus will be there but
> hidden by a macro. It will still be clean and shouldn't cause grief.
Right, but if it is there we'll want to mark it as unused in some way
so that the kernel doesn't waste resources attempting to drive it.
--
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
* Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
From: Kumar Gala @ 2008-01-10 6:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <478525E7.3060106@freescale.com>
On Jan 9, 2008, at 1:52 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> I'm thinking I'll add something like:
>> if (addr < total_lowmem)
>> reserve_bootmem(lmb.reserved.region[i].base,
>>
>> lmb_size_bytes(&lmb.reserved, i));
>> + else if (lmb.reserved.region[i].base >
>> total_lowmem) {
>
> less than, surely?
damn, why didn't I see your email before a spent 20 minutes debugging
this ;)
>> + unsigned long adjusted_size;
>> +// adjusted_size = xxx;
>> need to figure out the math here.
>
> Wouldn't it just be total_lowmem - lmb.reserved.region[i].base?
yep, but that required my brain to have enough time to think about this.
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox