* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Segher Boessenkool @ 2009-11-21 20:01 UTC (permalink / raw)
To: Li Yang; +Cc: Li Yang-R58472, linuxppc-dev
In-Reply-To: <2a27d3730911200123i23fa6dd1td9e19944d1737e73@mail.gmail.com>
>> You need to be a bit more careful tho. You must not allow RAM
>> managed by
>> the kernel to be mapped non-cachable.
>
> Even if the user explicitly sets the O_SYNC flag? IMHO, it's a bug of
> the application if it uses O_SYNC on main memory to be mmap'ed later.
> And we don't need to cover up the bug.
Is that "embedded thinking"? Conflicts like this cause machine
checks or
checkstops on many PowerPC implementations, we do not normally allow
such
to be caused by userland.
Segher
^ permalink raw reply
* DTS for PowerPC 440 based board
From: Vinayak Kale @ 2009-11-21 18:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
Hi,
I am porting 2.6.31 for a PowerPC 440 core based board. I have couple of
queries. I would really appreciate if someone could answer since i couldn't
find info from other places.
1) Is it mandatory to create a DTS file?
2) If uboot passes BDInfo struct to kernel instead of DT blob, then in this
case does kernel creates FDT at run time?
3) I believe in case of DTS, the kernel picks up the h/w info from DTS blob
so we need not hardcode any register addresses etc inside kernel other than
in dts file. What happens in case of uboot passing just BDInfo struct. How
do we specify the register addresses etc?
Thanks
Vinayak
[-- Attachment #2: Type: text/html, Size: 670 bytes --]
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-11-21 16:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40911210045v4be84e8dg8ef490472e06017b@mail.gmail.com>
On Sat, Nov 21, 2009 at 09:45:50 Grant Likely wrote:
[...]
> Hey Torsten, do you have an updated version of this change to address
> the comments? I'm collecting the last few things for some linux-next
> exposure now.
Hey Grant,
here is the updated version of the patch containing the recommended
changes.
Best Regards
Torsten
Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
---
diff -u -r -N linux-2.6.31.6_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.31.6/drivers/spi/spi_mpc8xxx.c
--- linux-2.6.31.6_orig//drivers/spi/spi_mpc8xxx.c 2009-11-10 01:32:31.000000000 +0100
+++ linux-2.6.31.6/drivers/spi/spi_mpc8xxx.c 2009-11-19 08:15:33.000000000 +0100
@@ -114,6 +114,7 @@
u32 rx_shift; /* RX data reg shift when in qe mode */
u32 tx_shift; /* TX data reg shift when in qe mode */
u32 hw_mode; /* Holds HW mode register settings */
+ int initialized;
};
static inline void mpc8xxx_spi_write_reg(__be32 __iomem *reg, u32 val)
@@ -503,15 +504,52 @@
return ret;
}
+
+
+struct mpc8xxx_spi_probe_info {
+ struct fsl_spi_platform_data pdata;
+ int *gpios;
+ bool *alow_flags;
+};
+
+static struct mpc8xxx_spi_probe_info *
+to_of_pinfo(struct fsl_spi_platform_data *pdata)
+{
+ return container_of(pdata, struct mpc8xxx_spi_probe_info, pdata);
+}
+
+static int mpc8xxx_spi_cs_init(struct spi_device *spi)
+{
+ struct device *dev = spi->dev.parent;
+ struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
+ u16 cs = spi->chip_select;
+ int gpio = pinfo->gpios[cs];
+ bool on = pinfo->alow_flags[cs] ^ !(spi->mode & SPI_CS_HIGH);
+
+ return gpio_direction_output(gpio, on);
+}
+
static int mpc8xxx_spi_transfer(struct spi_device *spi,
struct spi_message *m)
{
struct mpc8xxx_spi *mpc8xxx_spi = spi_master_get_devdata(spi->master);
+ struct spi_mpc8xxx_cs *cs = spi->controller_state;
unsigned long flags;
m->actual_length = 0;
m->status = -EINPROGRESS;
+ if (cs && !cs->initialized) {
+ int ret;
+
+ ret = mpc8xxx_spi_cs_init(spi);
+ if (ret) {
+ dev_dbg(&spi->dev, "cs_init failed: %d\n", ret);
+ return ret;
+ }
+ cs->initialized = 1;
+ }
+
spin_lock_irqsave(&mpc8xxx_spi->lock, flags);
list_add_tail(&m->queue, &mpc8xxx_spi->queue);
queue_work(mpc8xxx_spi->workqueue, &mpc8xxx_spi->work);
@@ -648,18 +686,6 @@
return 0;
}
-struct mpc8xxx_spi_probe_info {
- struct fsl_spi_platform_data pdata;
- int *gpios;
- bool *alow_flags;
-};
-
-static struct mpc8xxx_spi_probe_info *
-to_of_pinfo(struct fsl_spi_platform_data *pdata)
-{
- return container_of(pdata, struct mpc8xxx_spi_probe_info, pdata);
-}
-
static void mpc8xxx_spi_cs_control(struct spi_device *spi, bool on)
{
struct device *dev = spi->dev.parent;
@@ -720,14 +746,6 @@
pinfo->gpios[i] = gpio;
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
^ permalink raw reply
* Re: tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-21 11:03 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev@vger.kernel.org, mcarlson, linuxppc-dev@ozlabs.org
In-Reply-To: <1258671053.14964.20.camel@nseg_linux_HP1.broadcom.com>
Hi,
Michael Chan wrote:
> On Thu, 2009-11-19 at 08:08 -0800, Felix Radensky wrote:
>
>> Hi,
>>
>> The problem goes away if I remove the call to
>>
>> tg3_set_power_state(tp, PCI_D3hot);
>>
>> from tg3_close().
>>
>
> Added Matt to CC. He is on vacation and may not be able to look into
> this right away. Thanks.
>
>
Thanks, Michael. After digging some more into it, I've found that the
problem is in tg3_power_down_phy() routine. Apparently 57780 PHY
is not handled properly. If tg3_power_down_phy() is not invoked from
tg3_set_power_state(), the problem is not reproducible anymore. I don't
have enough information about NIC internals to dig further.
Felix.
^ permalink raw reply
* Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-11-21 10:27 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091120202838.GA25843@compile2.chatsunix.int.mrv.com>
Rex Feany <RFeany@mrv.com> wrote on 20/11/2009 21:28:38:
>
> Thus spake Joakim Tjernlund (Joakim.Tjernlund@transmode.se):
>
> > Yet again an iteration of the series.
> > Rex & Scott, please test and signoff.
> > Changes since last version:
> > - Fix rlwimi insn(from Scott)
>
> Hi Joakim,
>
> Things look much better with this patch set, I see none
> of the random crashes that I had with the earlier patches.
> I'll leave it running on a few boards here over the weekend and
> see if anything bad happens.
Good to hear that.
>
> Since patch #1 fixes a regression in the current kernel
> is there any way you can get that into .32? I know it is late,
> but without that patch .32 doesn't work for 8xx boards.
You need to convince Ben of that. I guess the best you can do
is to reply(include Ben too) with your s-o-b and explain that this
fixes a regression for you.
>
> On another note, how does your patch set affect performance?
> Have you been able to do any testing? What is the advantage
> of using dcbX in the kernel, besides keeping the code
> similar to other ppc platforms?
I consider this a big plus, not having to pay special attention
to 8xx anymore. There aren't many 8xx people around
to fix problems that are specific for 8xx.
> Maybe it is good to
> catch/fixup userspace uses of dcbX, but why change the
> kernel? How does it affect performance?
when I originally did the dcbX path many years ago I did
some perf testing and it was a win. Perhaps you could
run a some tests?
Consider that the dcbx workaround is only triggered by a DTLB errors
and the kernel never gets into DTLB errors for normal activity.
TLB errors are the slow path anyway with lots of mm code
so a few more insn won't matter.
There is also the case of dcbst setting the store bit wrongly
and this could generate a SEGV if it hits a RO page.
The kernel isn't free of dcbX insn anyway so if it ever hit
a DTLB error, it is possible that could bring down the kernel.
The only perf regression I can think of is the
8xx: Remove DIRTY pte handling in DTLB Error.
which will make dirty handling much slower.
I am happy to leave that one out, but Ben requested
this.
Jocke
PS.
You should consider fixing glibc's mem* functions to make
use of dcbX for 8xx once the kernel has this patchset.
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Grant Likely @ 2009-11-21 8:45 UTC (permalink / raw)
To: avorontsov; +Cc: Torsten Fleischer, linuxppc-dev
In-Reply-To: <20091118232920.GA24307@oksana.dev.rtsoft.ru>
On Wed, Nov 18, 2009 at 4:29 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Wed, Nov 18, 2009 at 05:20:06PM +0100, Torsten Fleischer wrote:
> [...]
>> > Oh. On the other hand, we can postpone the gpio_direction_output()
>> > call, and still require that the platform code (or firmware)
>> > should be responsible for setting a sane default values on the
>> > chip selects.
>> >
>>
>> How about that?
>
> Looks great, thanks!
>
> Few minor issues below.
Hey Torsten, do you have an updated version of this change to address
the comments? I'm collecting the last few things for some linux-next
exposure now.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [patch 06/13] powerpc: Fixup last users of irq_chip->typename
From: Grant Likely @ 2009-11-21 8:01 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Scott Wood, linuxppc-dev, Ingo Molnar, LKML
In-Reply-To: <alpine.LFD.2.00.0911182141060.24119@localhost.localdomain>
On Wed, Nov 18, 2009 at 1:41 PM, Thomas Gleixner <tglx@linutronix.de> wrote=
:
> On Wed, 18 Nov 2009, Scott Wood wrote:
>> On Tue, Nov 17, 2009 at 10:50:53PM +0000, Thomas Gleixner wrote:
>> > Index: linux-2.6/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > --- linux-2.6.orig/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
>> > +++ linux-2.6/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
>> > @@ -69,7 +69,7 @@ static void pq2ads_pci_unmask_irq(unsign
>> > =A0}
>> >
>> > =A0static struct irq_chip pq2ads_pci_ic =3D {
>> > - =A0 .typename =3D "PQ2 ADS PCI",
>> > + =A0 .name =3D "PQ2 ADS PCI",
>> > =A0 =A0 .name =3D "PQ2 ADS PCI",
>> > =A0 =A0 .end =3D pq2ads_pci_unmask_irq,
>> > =A0 =A0 .mask =3D pq2ads_pci_mask_irq,
>>
>> Duplicate ".name"...
>
> Darn.
Other than that, looks good to me.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Fw: Help with SPI node
From: Grant Likely @ 2009-11-21 7:57 UTC (permalink / raw)
To: Ravi Shekhar; +Cc: linuxppc-dev
In-Reply-To: <OF627E4B93.73CDD8FE-ON6525766A.0013CA01-6525766A.0013C6E5@lntemsys.com>
On Mon, Nov 9, 2009 at 8:36 PM, Ravi Shekhar <Ravi.Shekhar@lntemsys.com> wr=
ote:
>
>
> =A0I'm attempting to get SPI to work on my embedded design
> =A0that is based on the mpc8313erbd reference board wiht a
> =A02.6.27 kernel.
Are you able to use a more recent kernel? A lot of work has gone into
SPI drivers in the last 5 releases.
> =A0I cannot open the SPI device.
> =A0Tracing through the kernel code, it looks like the device is
> =A0not being found in the DTB file. =A0However there is a
> =A0SPI node in there already described. =A0Our boards is a
> SPI master, and the device we will attach is a SPI
> =A0slave. =A0Could someone elaborate on what is needed in
> =A0the DTS file to have our SPI driver work and respond to an
> =A0open() call?
Look in Documentation/powerpc/dts-bindings/spi-bus.txt. However, the
2.6.27 kernel may not have support for that binding on the mpc8313 SPI
bus driver (I'm not sure though, I haven't looked).
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Grant Likely @ 2009-11-21 7:51 UTC (permalink / raw)
To: John Linn; +Cc: Stephen Neuendorffer, Alon Ziv, linuxppc-dev, Arnd Bergmann
In-Reply-To: <e846a32c-5f37-4531-b23d-17c60d8b6449@SG2EHSMHS010.ehs.local>
On Fri, Nov 20, 2009 at 3:11 PM, John Linn <John.Linn@xilinx.com> wrote:
>
>> -----Original Message-----
>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Gr=
ant Likely
>> Sent: Friday, November 20, 2009 2:58 PM
>> To: Stephen Neuendorffer
>> Cc: Arnd Bergmann; John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: Bug in drivers/serial/of_serial.c?
>>
>> On Thu, Nov 19, 2009 at 10:42 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.o=
rg
>> > [mailto:linuxppc-dev-
>> >> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Ar=
nd
>> > Bergmann
>> >> Sent: Thursday, November 19, 2009 9:33 AM
>> >> To: Stephen Neuendorffer
>> >> Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
>> >> Subject: Re: Bug in drivers/serial/of_serial.c?
>> >>
>> >> On Thursday 19 November 2009, Stephen Neuendorffer wrote:
>> >> > If the problem is in the device trees that are being generated, we
>> >> > should fix the issue there.
>> >> > We've been trying to avoid putting the fully specified IP versions
>> > in
>> >> > the kernel like this, since
>> >> > the IP changes so often.
>> >>
>> >> No, the problem that Alon has is that the firmware currently has no
>> >> way whatsoever to give a correct device tree, because of-serial.c
>> >> does not even know about ns16550a.
>> >>
>> >> The patch adds both a special-case for the specific uart he
>> >> is using so that one is grandfathered in and a new compatible
>> >> value so future boards can specify both ns16550a and ns16550.
>> >
>> > That's true... =A0The 16550a line still needs to get added, but not th=
e
>> > xlnx-
>> > specific line.
>>
>> The xlnx- line should be added and is entirely appropriate for exactly
>> the reason Arnd stated.
>
> I'm just wanting to make sure I'm on the same page...
>
> It seems like you're saying that adding this line fixes the system before=
any device tree generator fix, for existing systems, true?
>
> If that's true, how do you know that the 16550 in the xilinx system is no=
t a 16450 as that's the default?
>
> Right now we're not generating the ns16450 as we should be when there are=
no FIFOs. =A0Since we've been using 16550 and not 16550A it probably hasn'=
t been a problem.
Hmmm, right. I forgot that we talked about that on the phone. Yes,
in that case it is not a good idea to add the
xlnx,xps-uart16550-2.00.b because we don't know if it is configured as
a 16450 or a 16550. At least, if the xlnx,... match is added, then
the driver *also* needs to look for the value of the "xlnx,is-a-16550"
property.
BTW, while looking at that file... Arnd, does the .type =3D "serial"
stuff really need to be there?
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Bug in drivers/serial/of_serial.c?
From: John Linn @ 2009-11-20 22:11 UTC (permalink / raw)
To: Grant Likely, Stephen Neuendorffer; +Cc: Alon Ziv, linuxppc-dev, Arnd Bergmann
In-Reply-To: <fa686aa40911201358n5e5eb871wbfa523bfc9adb59d@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Gra=
nt Likely
> Sent: Friday, November 20, 2009 2:58 PM
> To: Stephen Neuendorffer
> Cc: Arnd Bergmann; John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Bug in drivers/serial/of_serial.c?
> =
> On Thu, Nov 19, 2009 at 10:42 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.or=
g
> > [mailto:linuxppc-dev-
> >> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Arn=
d
> > Bergmann
> >> Sent: Thursday, November 19, 2009 9:33 AM
> >> To: Stephen Neuendorffer
> >> Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
> >> Subject: Re: Bug in drivers/serial/of_serial.c?
> >>
> >> On Thursday 19 November 2009, Stephen Neuendorffer wrote:
> >> > If the problem is in the device trees that are being generated, we
> >> > should fix the issue there.
> >> > We've been trying to avoid putting the fully specified IP versions
> > in
> >> > the kernel like this, since
> >> > the IP changes so often.
> >>
> >> No, the problem that Alon has is that the firmware currently has no
> >> way whatsoever to give a correct device tree, because of-serial.c
> >> does not even know about ns16550a.
> >>
> >> The patch adds both a special-case for the specific uart he
> >> is using so that one is grandfathered in and a new compatible
> >> value so future boards can specify both ns16550a and ns16550.
> >
> > That's true... =A0The 16550a line still needs to get added, but not the=
> > xlnx-
> > specific line.
> =
> The xlnx- line should be added and is entirely appropriate for exactly
> the reason Arnd stated.
I'm just wanting to make sure I'm on the same page...
It seems like you're saying that adding this line fixes the system before a=
ny device tree generator fix, for existing systems, true?
If that's true, how do you know that the 16550 in the xilinx system is not =
a 16450 as that's the default?
Right now we're not generating the ns16450 as we should be when there are n=
o FIFOs. Since we've been using 16550 and not 16550A it probably hasn't be=
en a problem.
-- John
> =
> g.
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [Q/RFC] mpc52xx gpt api
From: Grant Likely @ 2009-11-20 22:04 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <283847.1258305453891.JavaMail.ngmail@webmail10.arcor-online.net>
On Sun, Nov 15, 2009 at 10:17 AM, Albrecht Dre=DF <albrecht.dress@arcor.de>=
wrote:
> Hi all,
>
> I tried to use a '5200B internal timer for a very simple task - as pwm to=
make a led blink, but apparently the current gpt implementation from Grant=
's tree does only support internal (cpu timer) modes which do not use the t=
imer io pin.
>
> The first hurdle was to actually get the timer itself - mpc52xx_gpt_from_=
irq() never returned something when I passed the timers (v)irq to it. =A0Wh=
at is the intended use of this function? =A0BTW, I do not need timer irq's,=
so I believe there should be an other way to grab a timer!
There is a discussion running right now on the linux-embedded list
about implementing an PWM api. It's worth hopping over and taking a
look.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Grant Likely @ 2009-11-20 21:58 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, Alon Ziv, linuxppc-dev, Arnd Bergmann
In-Reply-To: <a1cde516-ea22-4411-bae1-74878f6bee43@SG2EHSMHS002.ehs.local>
On Thu, Nov 19, 2009 at 10:42 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org
> [mailto:linuxppc-dev-
>> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Arnd
> Bergmann
>> Sent: Thursday, November 19, 2009 9:33 AM
>> To: Stephen Neuendorffer
>> Cc: John Linn; Alon Ziv; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: Bug in drivers/serial/of_serial.c?
>>
>> On Thursday 19 November 2009, Stephen Neuendorffer wrote:
>> > If the problem is in the device trees that are being generated, we
>> > should fix the issue there.
>> > We've been trying to avoid putting the fully specified IP versions
> in
>> > the kernel like this, since
>> > the IP changes so often.
>>
>> No, the problem that Alon has is that the firmware currently has no
>> way whatsoever to give a correct device tree, because of-serial.c
>> does not even know about ns16550a.
>>
>> The patch adds both a special-case for the specific uart he
>> is using so that one is grandfathered in and a new compatible
>> value so future boards can specify both ns16550a and ns16550.
>
> That's true... =A0The 16550a line still needs to get added, but not the
> xlnx-
> specific line.
The xlnx- line should be added and is entirely appropriate for exactly
the reason Arnd stated.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Bug in drivers/serial/of_serial.c?
From: Grant Likely @ 2009-11-20 21:56 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, Alon Ziv, linuxppc-dev, Arnd Bergmann
In-Reply-To: <c2bc536b-3765-4ead-b942-88bb25253ad3@VA3EHSMHS013.ehs.local>
[fixed top-posting nonsense :-) ]
On Thu, Nov 19, 2009 at 10:22 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
>> index 02406ba..241be77 100644
>> --- a/drivers/serial/of_serial.c
>> +++ b/drivers/serial/of_serial.c
>> @@ -161,7 +161,9 @@ static int of_platform_serial_remove(struct
>> of_device *ofdev)
>> static struct of_device_id __devinitdata of_platform_serial_table[] =
> {
>> { .type = "serial", .compatible = "ns8250", .data = (void
>> *)PORT_8250, },
>> { .type = "serial", .compatible = "ns16450", .data = (void
>> *)PORT_16450, },
>> + { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b",
>> .data = (void *)PORT_16550A, },
>> { .type = "serial", .compatible = "ns16550", .data = (void
>> *)PORT_16550, },
>> + { .type = "serial", .compatible = "ns16550a", .data = (void
>> *)PORT_16550A, },
>> { .type = "serial", .compatible = "ns16750", .data = (void
>> *)PORT_16750, },
>> { .type = "serial", .compatible = "ns16850", .data = (void
>> *)PORT_16850, },
>> #ifdef CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL
>
> NAK.
No, I wouldn't NAK this. It is an appropriate fix to still support
older trees that use the ns16550 value. Arnd, I've got no problem
with this being merged.
g.
>
> If the problem is in the device trees that are being generated, we
> should fix the issue there.
> We've been trying to avoid putting the fully specified IP versions in
> the kernel like this, since
> the IP changes so often.
Yes, the error is in the device tree generator... which is *exactly*
why the fully specified IP version is in the device tree; so that a
driver can work around bugs like this. You're right that we avoid
specifying it to eliminate an explosion of xlnx,<device><version>
strings in the kernel; but it is perfectly safe to use in situations
like this.
As you also know, but it is worth stating here for the record, this is
also exactly why newer versions of the IP claim compatibility with
fully specified versions of older IP. So that the list of strings
doesn't explode, but also so that it claims compatibility with a real
version of the device (not a made up string whose meaning can change
over time).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] spi/mpc52xx-spi: cleanups
From: Grant Likely @ 2009-11-20 21:46 UTC (permalink / raw)
To: Wolfram Sang; +Cc: spi-devel-general, Luotao Fu, linuxppc-dev
In-Reply-To: <20091118095828.GA5166@pengutronix.de>
On Wed, Nov 18, 2009 at 2:58 AM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
>> > - =A0 =A0 =A0 =A0 =A0 rc |=3D request_irq(ms->irq1, mpc52xx_spi_irq, I=
RQF_SAMPLE_RANDOM,
>> > + =A0 =A0 =A0 =A0 =A0 rc |=3D request_irq(ms->irq1, mpc52xx_spi_irq, 0=
,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "mpc5200-s=
pi-spiF", ms);
>>
>> The "spiF" here is probably also a typo.
>
> Ack. Grant, if you think it is worth you may modify my patch to avoid a r=
esend.
> If it is easier for you, I will do the resend, of course.
Don't resend. Patch looks okay.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/4 v2] Merge OF dynamic patches
From: Grant Likely @ 2009-11-20 21:40 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: microblaze-uclinux, devicetree-discuss, linuxppc-dev
In-Reply-To: <4B06AF33.1000400@austin.ibm.com>
On Fri, Nov 20, 2009 at 8:01 AM, Nathan Fontenot <nfont@austin.ibm.com> wro=
te:
> This set of patches merges the common dynamic device tree
> updating routines of_attach_node() and of_detach_node() to
> drivers/of/of_dynamic.c.
>
> Built and tested on powerpc, I have no access to build/test
> this on microblaze.
Heh. Actually, I've got a patch in my tree that does the same thing
(except to a different location). I could pick up your version and
drop mine, but you need to rework it to be bi-sectable. As the series
exists right now, the build will fail if only part of the series is
applied. This change is simple enough that you can do the whole thing
in a single patch. Or, fix the Kconfig and include stuff in the first
patch with the merge of of_attach_node, and then move of_detach_node
in the second.
But I'm really close to posting my 3rd series, so it may be better to
wait until that is published and build a patch on top of that to move
them into of_dynamic.c
Cheers,
g.
> ---
>
> 1/4 - Merge of_attach_node
> 2/4 - Merge of_detach_node
> 3/4 - Makefile/Kconfig updates
> 4/4 - Update powerpc/pseries to include of_dynamic.h
>
> arch/microblaze/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A01
> arch/microblaze/include/asm/prom.h =A0 =A0 =A0 =A0| =A0 =A04 -
> arch/microblaze/kernel/prom.c =A0 =A0 =A0 =A0 =A0 =A0 | =A0 59 ----------=
-------------
> arch/powerpc/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0=
1
> arch/powerpc/include/asm/prom.h =A0 =A0 =A0 =A0 =A0 | =A0 =A04 -
> arch/powerpc/kernel/prom.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 59 ------=
-----------------
> arch/powerpc/platforms/pseries/reconfig.c | =A0 =A01 drivers/of/Kconfig
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A04 +
> drivers/of/Makefile =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0=
1 drivers/of/of_dynamic.c
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 75 ++++++++++++++++++++++++++++++
> include/linux/of_dynamic.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 27 ++++++=
++++
> 11 files changed, 110 insertions(+), 126 deletions(-)
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/p4080: Add basic support for p4080ds platform
From: Kumar Gala @ 2009-11-20 21:34 UTC (permalink / raw)
To: linuxppc-dev
Add basic support for the P4080 DS reference board. None of the data
path devices (ethernet, crypto, pme) are support at this time.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p4080ds.dts | 554 ++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 12 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_ds.c | 125 +++++++
arch/powerpc/platforms/85xx/corenet_ds.h | 19 +
arch/powerpc/platforms/85xx/p4080_ds.c | 74 ++++
6 files changed, 785 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p4080ds.dts
create mode 100644 arch/powerpc/platforms/85xx/corenet_ds.c
create mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h
create mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts
new file mode 100644
index 0000000..6b29eab
--- /dev/null
+++ b/arch/powerpc/boot/dts/p4080ds.dts
@@ -0,0 +1,554 @@
+/*
+ * P4080DS Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "fsl,P4080DS";
+ compatible = "fsl,P4080DS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ccsr = &soc;
+
+ serial0 = &serial0;
+ serial1 = &serial1;
+ serial2 = &serial2;
+ serial3 = &serial3;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ dma0 = &dma0;
+ dma1 = &dma1;
+ sdhc = &sdhc;
+
+ rio0 = &rapidio0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: PowerPC,4080@0 {
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ };
+ };
+ cpu1: PowerPC,4080@1 {
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ };
+ };
+ cpu2: PowerPC,4080@2 {
+ device_type = "cpu";
+ reg = <2>;
+ next-level-cache = <&L2_2>;
+ L2_2: l2-cache {
+ };
+ };
+ cpu3: PowerPC,4080@3 {
+ device_type = "cpu";
+ reg = <3>;
+ next-level-cache = <&L2_3>;
+ L2_3: l2-cache {
+ };
+ };
+ cpu4: PowerPC,4080@4 {
+ device_type = "cpu";
+ reg = <4>;
+ next-level-cache = <&L2_4>;
+ L2_4: l2-cache {
+ };
+ };
+ cpu5: PowerPC,4080@5 {
+ device_type = "cpu";
+ reg = <5>;
+ next-level-cache = <&L2_5>;
+ L2_5: l2-cache {
+ };
+ };
+ cpu6: PowerPC,4080@6 {
+ device_type = "cpu";
+ reg = <6>;
+ next-level-cache = <&L2_6>;
+ L2_6: l2-cache {
+ };
+ };
+ cpu7: PowerPC,4080@7 {
+ device_type = "cpu";
+ reg = <7>;
+ next-level-cache = <&L2_7>;
+ L2_7: l2-cache {
+ };
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc: soc@ffe000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ corenet-law@0 {
+ compatible = "fsl,corenet-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <32>;
+ };
+
+ memory-controller@8000 {
+ compatible = "fsl,p4080-memory-controller";
+ reg = <0x8000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <0x12 2>;
+ };
+
+ memory-controller@9000 {
+ compatible = "fsl,p4080-memory-controller";
+ reg = <0x9000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <0x12 2>;
+ };
+
+ corenet-cf@18000 {
+ compatible = "fsl,corenet-cf";
+ reg = <0x18000 0x1000>;
+ fsl,ccf-num-csdids = <32>;
+ fsl,ccf-num-snoopids = <32>;
+ };
+
+ iommu@20000 {
+ compatible = "fsl,p4080-pamu";
+ reg = <0x20000 0x10000>;
+ interrupts = <24 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ mpic: pic@40000 {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ };
+
+ dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p4080-dma", "fsl,eloplus-dma";
+ reg = <0x100300 0x4>;
+ ranges = <0x0 0x100100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <28 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <29 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <30 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <31 2>;
+ };
+ };
+
+ dma1: dma@101300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p4080-dma", "fsl,eloplus-dma";
+ reg = <0x101300 0x4>;
+ ranges = <0x0 0x101100 0x200>;
+ cell-index = <1>;
+ dma-channel@0 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <32 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <33 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <34 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,p4080-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <35 2>;
+ };
+ };
+
+ spi@110000 {
+ cell-index = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,espi";
+ reg = <0x110000 0x1000>;
+ interrupts = <53 0x2>;
+ interrupt-parent = <&mpic>;
+ espi,num-ss-bits = <4>;
+ mode = "cpu";
+
+ fsl_m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,espi-flash";
+ reg = <0>;
+ linux,modalias = "fsl_m25p80";
+ spi-max-frequency = <40000000>; /* input clock */
+ partition@u-boot {
+ label = "u-boot";
+ reg = <0x00000000 0x00100000>;
+ read-only;
+ };
+ partition@kernel {
+ label = "kernel";
+ reg = <0x00100000 0x00500000>;
+ read-only;
+ };
+ partition@dtb {
+ label = "dtb";
+ reg = <0x00600000 0x00100000>;
+ read-only;
+ };
+ partition@fs {
+ label = "file system";
+ reg = <0x00700000 0x00900000>;
+ };
+ };
+ };
+
+ sdhc: sdhc@114000 {
+ compatible = "fsl,p4080-esdhc", "fsl,esdhc";
+ reg = <0x114000 0x1000>;
+ interrupts = <48 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ i2c@118000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x118000 0x100>;
+ interrupts = <38 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ i2c@118100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x118100 0x100>;
+ interrupts = <38 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ eeprom@51 {
+ compatible = "at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@52 {
+ compatible = "at24,24c256";
+ reg = <0x52>;
+ };
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ interrupts = <0 0x1>;
+ interrupt-parent = <&mpic>;
+ };
+ };
+
+ i2c@119000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <2>;
+ compatible = "fsl-i2c";
+ reg = <0x119000 0x100>;
+ interrupts = <39 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ i2c@119100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <3>;
+ compatible = "fsl-i2c";
+ reg = <0x119100 0x100>;
+ interrupts = <39 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ serial0: serial@11c500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11c500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <36 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@11c600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11c600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <36 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial2: serial@11d500 {
+ cell-index = <2>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11d500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <37 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial3: serial@11d600 {
+ cell-index = <3>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x11d600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <37 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ gpio0: gpio@130000 {
+ compatible = "fsl,p4080-gpio";
+ reg = <0x130000 0x1000>;
+ interrupts = <55 2>;
+ interrupt-parent = <&mpic>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ usb0: usb@210000 {
+ compatible = "fsl,p4080-usb2-mph",
+ "fsl,mpc85xx-usb2-mph", "fsl-usb2-mph";
+ reg = <0x210000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <44 0x2>;
+ phy_type = "ulpi";
+ };
+
+ usb1: usb@211000 {
+ compatible = "fsl,p4080-usb2-dr",
+ "fsl,mpc85xx-usb2-dr", "fsl-usb2-dr";
+ reg = <0x211000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <45 0x2>;
+ dr_mode = "host";
+ phy_type = "ulpi";
+ };
+ };
+
+ rapidio0: rapidio@ffe0c0000 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "fsl,rapidio-delta";
+ reg = <0xf 0xfe0c0000 0 0x20000>;
+ ranges = <0 0 0xf 0xf5000000 0 0x01000000>;
+ interrupt-parent = <&mpic>;
+ /* err_irq bell_outb_irq bell_inb_irq
+ msg1_tx_irq msg1_rx_irq msg2_tx_irq msg2_rx_irq */
+ interrupts = <16 2 56 2 57 2 60 2 61 2 62 2 63 2>;
+ };
+
+ localbus@ffe124000 {
+ compatible = "fsl,p4080-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xf 0xfe124000 0 0x1000>;
+ interrupts = <25 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0xf 0xe8000000 0x08000000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x08000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ };
+ };
+
+ pci0: pcie@ffe200000 {
+ compatible = "fsl,p4080-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xfe200000 0 0x1000>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ clock-frequency = <0x1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 40 1
+ 0000 0 0 2 &mpic 1 1
+ 0000 0 0 3 &mpic 2 1
+ 0000 0 0 4 &mpic 3 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe201000 {
+ compatible = "fsl,p4080-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xfe201000 0 0x1000>;
+ bus-range = <0 0xff>;
+ ranges = <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ clock-frequency = <0x1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 41 1
+ 0000 0 0 2 &mpic 5 1
+ 0000 0 0 3 &mpic 6 1
+ 0000 0 0 4 &mpic 7 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe202000 {
+ compatible = "fsl,p4080-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xf 0xfe202000 0 0x1000>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x20000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ clock-frequency = <0x1fca055>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 42 1
+ 0000 0 0 2 &mpic 9 1
+ 0000 0 0 3 &mpic 10 1
+ 0000 0 0 4 &mpic 11 1
+ >;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x20000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 5de0d63..d951218 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -145,6 +145,18 @@ config SBC8560
help
This option enables support for the Wind River SBC8560 board
+config P4080_DS
+ bool "Freescale P4080 DS"
+ select DEFAULT_UIMAGE
+ select PPC_FSL_BOOK3E
+ select PPC_E500MC
+ select PHYS_64BIT
+ select SWIOTLB
+ select MPC8xxx_GPIO
+ select HAS_RAPIDIO
+ help
+ This option enables support for the P4080 DS board
+
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 9098aea..387c128 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_MPC8536_DS) += mpc8536_ds.o
obj-$(CONFIG_MPC85xx_DS) += mpc85xx_ds.o
obj-$(CONFIG_MPC85xx_MDS) += mpc85xx_mds.o
obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
+obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c b/arch/powerpc/platforms/85xx/corenet_ds.c
new file mode 100644
index 0000000..534c2ec
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -0,0 +1,125 @@
+/*
+ * Corenet based SoC DS Setup
+ *
+ * Maintained by Kumar Gala (see MAINTAINERS for contact information)
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/lmb.h>
+
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
+#include <mm/mmu_decl.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+
+void __init corenet_ds_pic_init(void)
+{
+ struct mpic *mpic;
+ struct resource r;
+ struct device_node *np = NULL;
+ unsigned int flags = MPIC_PRIMARY | MPIC_BIG_ENDIAN |
+ MPIC_BROKEN_FRR_NIRQS | MPIC_SINGLE_DEST_CPU;
+
+ np = of_find_node_by_type(np, "open-pic");
+
+ if (np == NULL) {
+ printk(KERN_ERR "Could not find open-pic node\n");
+ return;
+ }
+
+ if (of_address_to_resource(np, 0, &r)) {
+ printk(KERN_ERR "Failed to map mpic register space\n");
+ of_node_put(np);
+ return;
+ }
+
+ if (ppc_md.get_irq == mpic_get_coreint_irq)
+ flags |= MPIC_ENABLE_COREINT;
+
+ mpic = mpic_alloc(np, r.start, flags, 0, 256, " OpenPIC ");
+ BUG_ON(mpic == NULL);
+
+ mpic_init(mpic);
+}
+
+#ifdef CONFIG_PCI
+static int primary_phb_addr;
+#endif
+
+/*
+ * Setup the architecture
+ */
+#ifdef CONFIG_SMP
+void __init mpc85xx_smp_init(void);
+#endif
+
+void __init corenet_ds_setup_arch(void)
+{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+ struct pci_controller *hose;
+#endif
+ dma_addr_t max = 0xffffffff;
+
+#ifdef CONFIG_SMP
+ mpc85xx_smp_init();
+#endif
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,p4080-pcie") {
+ struct resource rsrc;
+ of_address_to_resource(np, 0, &rsrc);
+ if ((rsrc.start & 0xfffff) == primary_phb_addr)
+ fsl_add_bridge(np, 1);
+ else
+ fsl_add_bridge(np, 0);
+
+ hose = pci_find_hose_for_OF_device(np);
+ max = min(max, hose->dma_window_base_cur +
+ hose->dma_window_size);
+ }
+#endif
+
+#ifdef CONFIG_SWIOTLB
+ if (lmb_end_of_DRAM() > max) {
+ ppc_swiotlb_enable = 1;
+ set_pci_dma_ops(&swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+ }
+#endif
+ pr_info("%s board from Freescale Semiconductor\n", ppc_md.name);
+}
+
+static const struct of_device_id of_device_ids[] __devinitconst = {
+ {
+ .compatible = "simple-bus"
+ },
+ {
+ .compatible = "fsl,rapidio-delta",
+ },
+ {}
+};
+
+int __init corenet_ds_publish_devices(void)
+{
+ return of_platform_bus_probe(NULL, of_device_ids, NULL);
+}
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.h b/arch/powerpc/platforms/85xx/corenet_ds.h
new file mode 100644
index 0000000..ddd700b
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/corenet_ds.h
@@ -0,0 +1,19 @@
+/*
+ * Corenet based SoC DS Setup
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * 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.
+ *
+ */
+
+#ifndef CORENET_DS_H
+#define CORENET_DS_H
+
+extern void __init corenet_ds_pic_init(void);
+extern void __init corenet_ds_setup_arch(void);
+extern int __init corenet_ds_publish_devices(void);
+
+#endif
diff --git a/arch/powerpc/platforms/85xx/p4080_ds.c b/arch/powerpc/platforms/85xx/p4080_ds.c
new file mode 100644
index 0000000..8417046
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/p4080_ds.c
@@ -0,0 +1,74 @@
+/*
+ * P4080 DS Setup
+ *
+ * Maintained by Kumar Gala (see MAINTAINERS for contact information)
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+
+#include <asm/system.h>
+#include <asm/time.h>
+#include <asm/machdep.h>
+#include <asm/pci-bridge.h>
+#include <mm/mmu_decl.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+
+#include "corenet_ds.h"
+
+#ifdef CONFIG_PCI
+static int primary_phb_addr;
+#endif
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init p4080_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,P4080DS")) {
+#ifdef CONFIG_PCI
+ /* treat PCIe1 as primary,
+ * shouldn't matter as we have no ISA on the board
+ */
+ primary_phb_addr = 0x0000;
+#endif
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
+define_machine(p4080_ds) {
+ .name = "P4080 DS",
+ .probe = p4080_ds_probe,
+ .setup_arch = corenet_ds_setup_arch,
+ .init_IRQ = corenet_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_coreint_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
+
+machine_device_initcall(p4080_ds, corenet_ds_publish_devices);
+machine_arch_initcall(p4080_ds, swiotlb_setup_bus_notifier);
--
1.6.0.6
^ permalink raw reply related
* Re: [RFC PATCH 1/5] Rework OpenFirmware GPIO handling
From: Grant Likely @ 2009-11-20 21:12 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linuxppc-dev, devicetree-discuss, Paul Mackerras, David Brownell
In-Reply-To: <fa686aa40911201237y4a41dd63wee3fb4e0a5858e87@mail.gmail.com>
On Fri, Nov 20, 2009 at 1:37 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Tue, Nov 17, 2009 at 8:42 AM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> This patch improves OF GPIO bindings so, that most non-OF-specific gpio
>> controllers don't need to call any of OF binding function:
>>
>> 0) Move of_gpio_chip into main gpio_chip structure.
>> 1) Call of_gpio_init/destroy from gpiochip_add/remove.
>> 2) By default supply reasonable defaults for gpio_cells/xlate
>
> I think this change approaches the problem from the wrong way around.
> It is not appropriate to try and build OF hooks into gpiolib. gpiolib
> should be completely agnostic to any layers around them used to get
> data about how they are configured up. =A0If anything, OF helpers should
> wrap around the gpiolib functions so that drivers can use them if it
> is useful to do so.
Hmmm... okay, I didn't read your patch closely enough the first time
around. I understand what you're trying to do now. I appreciate
wanting to make GPIO binding transparent to GPIO providers. However,
I'm still leery of inserting OF hooks into gpiolib. I'm not convinced
that it is the correct approach. What *might* work is to add a
notifier API to GPIOLIB so that interested subsystems (like OF) can
register hooks to be told when GPIO pins are added and removed. That
keeps things all the OF implementation details abstracted away from
gpiolib.
Cheers,
g.
^ permalink raw reply
* Re: [RFC PATCH 1/5] Rework OpenFirmware GPIO handling
From: Grant Likely @ 2009-11-20 20:37 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: linuxppc-dev, devicetree-discuss, Paul Mackerras, David Brownell
In-Reply-To: <1258472546-31343-2-git-send-email-dbaryshkov@gmail.com>
On Tue, Nov 17, 2009 at 8:42 AM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> This patch improves OF GPIO bindings so, that most non-OF-specific gpio
> controllers don't need to call any of OF binding function:
>
> 0) Move of_gpio_chip into main gpio_chip structure.
> 1) Call of_gpio_init/destroy from gpiochip_add/remove.
> 2) By default supply reasonable defaults for gpio_cells/xlate
I think this change approaches the problem from the wrong way around.
It is not appropriate to try and build OF hooks into gpiolib. gpiolib
should be completely agnostic to any layers around them used to get
data about how they are configured up. If anything, OF helpers should
wrap around the gpiolib functions so that drivers can use them if it
is useful to do so.
g.
^ permalink raw reply
* Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB
From: Rex Feany @ 2009-11-20 20:28 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <1258712471-3104-1-git-send-email-Joakim.Tjernlund@transmode.se>
Thus spake Joakim Tjernlund (Joakim.Tjernlund@transmode.se):
> Yet again an iteration of the series.
> Rex & Scott, please test and signoff.
> Changes since last version:
> - Fix rlwimi insn(from Scott)
Hi Joakim,
Things look much better with this patch set, I see none
of the random crashes that I had with the earlier patches.
I'll leave it running on a few boards here over the weekend and
see if anything bad happens.
Since patch #1 fixes a regression in the current kernel
is there any way you can get that into .32? I know it is late,
but without that patch .32 doesn't work for 8xx boards.
On another note, how does your patch set affect performance?
Have you been able to do any testing? What is the advantage
of using dcbX in the kernel, besides keeping the code
similar to other ppc platforms? Maybe it is good to
catch/fixup userspace uses of dcbX, but why change the
kernel? How does it affect performance?
thanks!
/rex.
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Scott Wood @ 2009-11-20 17:38 UTC (permalink / raw)
To: Mahajan Vivek-B08308; +Cc: linuxppc-dev, Gala Kumar-B11780, Wood Scott-B07421
In-Reply-To: <F2F605B667B24B489C904986E0D60A08012221DF@zin33exm23.fsl.freescale.net>
On Thu, Nov 19, 2009 at 11:45:32PM -0700, Mahajan Vivek-B08308 wrote:
> > I really don't like setting the physical address this way,
> > can we not do this via the device tree?
>
> Cache-sram does not have any device tree entry since it is not a
> hardware as such. Putting it under chosen can be another option.
> I think, Scott (cc'ed) was of the opinion that since 32b base
> address support is missing; so there is no point in moving this
> address to the command line and .config should be okay for now
> for it.
I don't know what you mean by "32b base address support is missing". I have
no objection to putting it on the command line.
-Scott
^ permalink raw reply
* Re: [PATCH/RFC] Booting Xilinx ML510 board using SystemACE
From: Grant Likely @ 2009-11-20 17:25 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: John Linn, Alon Ziv, linuxppc-dev
In-Reply-To: <2ed32732-d2a2-42d3-89ef-80c5a25025ba@SG2EHSMHS007.ehs.local>
On Thu, Nov 19, 2009 at 10:32 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>> Of course, one obvious thing that must be done is move this code out
> of
>> arch/powerpc/platforms/44x/virtex.c and into (e.g.)
>> arch/powerpc/kernel/setup-common.c, and add some
>> "set_machine_restart_function" wrapper to access it more cleanly (also
>> defining this function as a null function when inapplicable). =A0If this
>> satisfies your standards, I can easily post an updated patch :)
>
> The driver isn't even powerpc specific, it could also be used on the
> microblaze,
> and I think you'll find alot of resistance to adding that kind of hook
> to an architecture
> that has just spent a bunch of time getting rid of alot of direct
> binding between
> platform code and drivers. =A0Grant, do you have a comment here?
Sorry for the delay, I was at a conference and got behind on email.
Yes, I've got comments.
First, the practical matter is that this is only applicable as a reset
mechanism for Xilinx PowerPC (440 or 405) and Microblaze platforms,
but the sysace device also appears on other boards, and is used to
reconfigure FPGA's that don't reset the whole system. One of the AMCC
boards for example.
So, you want the ability to have the driver reset the system, but you
cannot break other platforms. You also cannot call out to the driver
from platform code because the xsysace driver may get loaded as a
module.
The cleanest solution would be to call out to the xsysace driver from
platform code; but as already stated that isn't possible because the
xsysace driver may be loaded as a module. The only way I can think of
to do that cleanly would be to register a bus notifier from platform
code to wait for an xsysace device to get probed. But still not
exactly pretty.
For the time being, I don't think there is a good way to avoid
architecture specific hooks into the driver itself. I recommend
adding a new pair of functions to the driver (protected by #if
defined(CONFIG_PPC)) that looks for a 'xlnx,can-reset-system'
property. It the property is present, then simply replace the
ppc_md.restart hook in the machine definition. Make sure to also
restore it again when the driver is removed. Similar code would be
needed for Microblaze too, but someone else can write that.
It is important to trigger the behaviour on whether or not a property
like 'xlnx,can-restart-system' is present so that it can be chosen at
runtime whether or not the sysace should actually be used for restart
so that it doesn't break things for multiplatform.
Also, you need to add documentation about the new property to
Documentation/powerpc/dts-bindings/ before I will merge the change.
The documentation change can appear in the same patch.
It may not be the prettiest thing in the world, but in the absence of
a cross-architecture machine restart infrastructure I think it is the
best option. At the very least it contains the changes to the driver
itself.
Cheers,
g.
^ permalink raw reply
* Re: [patch 3/3] [v2] powerpc: make the CMM memory hotplug aware
From: Robert Jennings @ 2009-11-20 16:10 UTC (permalink / raw)
To: Andrew Morton
Cc: mel, geralds, linuxppc-dev, paulus, brking, mingo, schwidefsky,
kamezawa.hiroyu
In-Reply-To: <20091119161403.93bd5756.akpm@linux-foundation.org>
* Andrew Morton (akpm@linux-foundation.org) wrote:
> On Wed, 18 Nov 2009 12:59:08 -0600
> Robert Jennings <rcj@linux.vnet.ibm.com> wrote:
>
> > The Collaborative Memory Manager (CMM) module allocates individual pages
> > over time that are not migratable. On a long running system this can
> > severely impact the ability to find enough pages to support a hotplug
> > memory remove operation.
> >
> > This patch adds a memory isolation notifier and a memory hotplug notifier.
<snip>
> : @@ -563,6 +565,37 @@ static int cmm_mem_going_offline(void *a
> : }
> : pa_curr = pa_curr->next;
> : }
> : +
> : + /* Search for page list structures in the range to be offlined */
> : + pa_last = NULL;
> : + pa_curr = cmm_page_list;
> : + while (pa_curr) {
> : + if (((unsigned long)pa_curr >= start_page) &&
> : + ((unsigned long)pa_curr < end_page)) {
> : + npa = (struct cmm_page_array *)__get_free_page(
> : + GFP_NOIO | __GFP_NOWARN |
> : + __GFP_NORETRY | __GFP_NOMEMALLOC);
> : + if (!npa) {
> : + spin_unlock(&cmm_lock);
> : + cmm_dbg("Failed to allocate memory for list "
> : + "management. Memory hotplug "
> : + "failed.\n");
> : + return ENOMEM;
> : + }
> : + memcpy(npa, pa_curr, PAGE_SIZE);
> : + if (pa_curr == cmm_page_list)
> : + cmm_page_list = npa;
> : + if (pa_last)
> : + pa_last->next = npa;
> : + free_page((unsigned long) pa_curr);
> : + freed++;
> : + pa_curr = npa;
> : + }
> : +
> : + pa_last = pa_curr;
> : + pa_curr = pa_curr->next;
> : + }
> : +
> : spin_unlock(&cmm_lock);
> : cmm_dbg("Released %ld pages in the search range.\n", freed);
> :
>
> I'm wondering what is the maximum hold time of cmm_lock. Rounded to
> the nearest fortnight :)
I've optimized this for sub-fortnight performance, but the maximum
hold time is a function of the number of pages in the balloon and in the
infreqent case that we try to migrate a page array page it will attempt
a page allocation. I'm calling __get_free_pages with __GFP_NORETRY and
the offline fails quickly if we don't get the page. Additionally, the
cmm_lock could be held by either the balloon allocation or deallocation
functions when the hotplug handler is called; I've addressed this as well.
For the allocation path the locking granularity is quite good and
a hotplug event will cause the allocation function to exit early to
minimize memory pressure.
The balloon deallocation path was not altered, it will hold the lock
and free all of the pages it was attempting to free before releasing the
lock. The thought here is that by allowing it to complete we reduce
memory pressure and reduce the number of list entries we'll need to
search for each memory segment being offlined.
^ permalink raw reply
* [PATCH 4/4 v2] Include of_dynamic.h in pseries/reconfig.c
From: Nathan Fontenot @ 2009-11-20 15:09 UTC (permalink / raw)
To: devicetree-discuss, linuxppc-dev, microblaze-uclinux
In-Reply-To: <4B06AF33.1000400@austin.ibm.com>
Include the newly created linux/of_dynamic.h to pick up the
of_[attach,detach]_node declarations.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
arch/powerpc/platforms/pseries/reconfig.c | 1 +
1 file changed, 1 insertion(+)
Index: test-devicetree/arch/powerpc/platforms/pseries/reconfig.c
===================================================================
--- test-devicetree.orig/arch/powerpc/platforms/pseries/reconfig.c 2009-11-20 11:59:00.000000000 -0600
+++ test-devicetree/arch/powerpc/platforms/pseries/reconfig.c 2009-11-20 12:37:32.000000000 -0600
@@ -15,6 +15,7 @@
#include <linux/kref.h>
#include <linux/notifier.h>
#include <linux/proc_fs.h>
+#include <linux/of_dynamic.h>
#include <asm/prom.h>
#include <asm/machdep.h>
^ permalink raw reply
* [PATCH 3/4 v2] Makefile and Kconfig updates
From: Nathan Fontenot @ 2009-11-20 15:08 UTC (permalink / raw)
To: devicetree-discuss, linuxppc-dev, microblaze-uclinux
In-Reply-To: <4B06AF33.1000400@austin.ibm.com>
Update the Kconfig and Makefile files for drivers/of, powerpc and microblaze
to properly configure for CONFIG_OF_DYNAMIC to build the of_dynamic code.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
arch/microblaze/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
drivers/of/Kconfig | 4 ++++
drivers/of/Makefile | 1 +
4 files changed, 7 insertions(+)
Index: test-devicetree/arch/microblaze/Kconfig
===================================================================
--- test-devicetree.orig/arch/microblaze/Kconfig 2009-11-20 11:59:01.000000000 -0600
+++ test-devicetree/arch/microblaze/Kconfig 2009-11-20 12:35:41.000000000 -0600
@@ -112,6 +112,7 @@
config OF
def_bool y
select OF_FLATTREE
+ select OF_DYNAMIC
config PROC_DEVICETREE
bool "Support for device tree in /proc"
Index: test-devicetree/arch/powerpc/Kconfig
===================================================================
--- test-devicetree.orig/arch/powerpc/Kconfig 2009-11-20 11:59:01.000000000 -0600
+++ test-devicetree/arch/powerpc/Kconfig 2009-11-20 12:35:41.000000000 -0600
@@ -164,6 +164,7 @@
config OF
def_bool y
select OF_FLATTREE
+ select OF_DYNAMIC
config PPC_UDBG_16550
bool
Index: test-devicetree/drivers/of/Kconfig
===================================================================
--- test-devicetree.orig/drivers/of/Kconfig 2009-11-20 11:59:01.000000000 -0600
+++ test-devicetree/drivers/of/Kconfig 2009-11-20 12:35:41.000000000 -0600
@@ -2,6 +2,10 @@
bool
depends on OF
+config OF_DYNAMIC
+ bool
+ depends on OF
+
config OF_DEVICE
def_bool y
depends on OF && (SPARC || PPC_OF || MICROBLAZE)
Index: test-devicetree/drivers/of/Makefile
===================================================================
--- test-devicetree.orig/drivers/of/Makefile 2009-11-20 11:59:01.000000000 -0600
+++ test-devicetree/drivers/of/Makefile 2009-11-20 12:35:41.000000000 -0600
@@ -1,5 +1,6 @@
obj-y = base.o
obj-$(CONFIG_OF_FLATTREE) += fdt.o
+obj-$(CONFIG_OF_DYNAMIC) += of_dynamic.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
obj-$(CONFIG_OF_GPIO) += gpio.o
obj-$(CONFIG_OF_I2C) += of_i2c.o
^ permalink raw reply
* [PATCH 2/4 v2] Merge of_detach_node
From: Nathan Fontenot @ 2009-11-20 15:06 UTC (permalink / raw)
To: devicetree-discuss, linuxppc-dev, microblaze-uclinux
In-Reply-To: <4B06AF33.1000400@austin.ibm.com>
Merge the common of_detach_node() from powerpc and microblaze into the common
drivers/of/of_dynamic.c
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
arch/microblaze/include/asm/prom.h | 3 --
arch/microblaze/kernel/prom.c | 44 -------------------------------------
arch/powerpc/include/asm/prom.h | 3 --
arch/powerpc/kernel/prom.c | 44 -------------------------------------
drivers/of/of_dynamic.c | 43 ++++++++++++++++++++++++++++++++++++
include/linux/of_dynamic.h | 1
6 files changed, 44 insertions(+), 94 deletions(-)
Index: test-devicetree/arch/microblaze/kernel/prom.c
===================================================================
--- test-devicetree.orig/arch/microblaze/kernel/prom.c 2009-11-20 11:59:03.000000000 -0600
+++ test-devicetree/arch/microblaze/kernel/prom.c 2009-11-20 12:28:33.000000000 -0600
@@ -482,50 +482,6 @@
}
EXPORT_SYMBOL(of_node_put);
-/*
- * "Unplug" a node from the device tree. The caller must hold
- * a reference to the node. The memory associated with the node
- * is not freed until its refcount goes to zero.
- */
-void of_detach_node(struct device_node *np)
-{
- struct device_node *parent;
- unsigned long flags;
-
- write_lock_irqsave(&devtree_lock, flags);
-
- parent = np->parent;
- if (!parent)
- goto out_unlock;
-
- if (allnodes == np)
- allnodes = np->allnext;
- else {
- struct device_node *prev;
- for (prev = allnodes;
- prev->allnext != np;
- prev = prev->allnext)
- ;
- prev->allnext = np->allnext;
- }
-
- if (parent->child == np)
- parent->child = np->sibling;
- else {
- struct device_node *prevsib;
- for (prevsib = np->parent->child;
- prevsib->sibling != np;
- prevsib = prevsib->sibling)
- ;
- prevsib->sibling = np->sibling;
- }
-
- of_node_set_flag(np, OF_DETACHED);
-
-out_unlock:
- write_unlock_irqrestore(&devtree_lock, flags);
-}
-
#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
static struct debugfs_blob_wrapper flat_dt_blob;
Index: test-devicetree/arch/powerpc/kernel/prom.c
===================================================================
--- test-devicetree.orig/arch/powerpc/kernel/prom.c 2009-11-20 11:59:03.000000000 -0600
+++ test-devicetree/arch/powerpc/kernel/prom.c 2009-11-20 12:28:33.000000000 -0600
@@ -935,50 +935,6 @@
}
EXPORT_SYMBOL(of_node_put);
-/*
- * "Unplug" a node from the device tree. The caller must hold
- * a reference to the node. The memory associated with the node
- * is not freed until its refcount goes to zero.
- */
-void of_detach_node(struct device_node *np)
-{
- struct device_node *parent;
- unsigned long flags;
-
- write_lock_irqsave(&devtree_lock, flags);
-
- parent = np->parent;
- if (!parent)
- goto out_unlock;
-
- if (allnodes == np)
- allnodes = np->allnext;
- else {
- struct device_node *prev;
- for (prev = allnodes;
- prev->allnext != np;
- prev = prev->allnext)
- ;
- prev->allnext = np->allnext;
- }
-
- if (parent->child == np)
- parent->child = np->sibling;
- else {
- struct device_node *prevsib;
- for (prevsib = np->parent->child;
- prevsib->sibling != np;
- prevsib = prevsib->sibling)
- ;
- prevsib->sibling = np->sibling;
- }
-
- of_node_set_flag(np, OF_DETACHED);
-
-out_unlock:
- write_unlock_irqrestore(&devtree_lock, flags);
-}
-
#ifdef CONFIG_PPC_PSERIES
/*
* Fix up the uninitialized fields in a new device node:
Index: test-devicetree/drivers/of/of_dynamic.c
===================================================================
--- test-devicetree.orig/drivers/of/of_dynamic.c 2009-11-20 12:27:24.000000000 -0600
+++ test-devicetree/drivers/of/of_dynamic.c 2009-11-20 12:28:33.000000000 -0600
@@ -30,3 +30,46 @@
write_unlock_irqrestore(&devtree_lock, flags);
}
+/*
+ * "Unplug" a node from the device tree. The caller must hold
+ * a reference to the node. The memory associated with the node
+ * is not freed until its refcount goes to zero.
+ */
+void of_detach_node(struct device_node *np)
+{
+ struct device_node *parent;
+ unsigned long flags;
+
+ write_lock_irqsave(&devtree_lock, flags);
+
+ parent = np->parent;
+ if (!parent)
+ goto out_unlock;
+
+ if (allnodes == np)
+ allnodes = np->allnext;
+ else {
+ struct device_node *prev;
+ for (prev = allnodes;
+ prev->allnext != np;
+ prev = prev->allnext)
+ ;
+ prev->allnext = np->allnext;
+ }
+
+ if (parent->child == np)
+ parent->child = np->sibling;
+ else {
+ struct device_node *prevsib;
+ for (prevsib = np->parent->child;
+ prevsib->sibling != np;
+ prevsib = prevsib->sibling)
+ ;
+ prevsib->sibling = np->sibling;
+ }
+
+ of_node_set_flag(np, OF_DETACHED);
+
+out_unlock:
+ write_unlock_irqrestore(&devtree_lock, flags);
+}
Index: test-devicetree/arch/microblaze/include/asm/prom.h
===================================================================
--- test-devicetree.orig/arch/microblaze/include/asm/prom.h 2009-11-20 12:24:47.000000000 -0600
+++ test-devicetree/arch/microblaze/include/asm/prom.h 2009-11-20 12:30:33.000000000 -0600
@@ -39,9 +39,6 @@
extern rwlock_t devtree_lock; /* temporary while merging */
-/* For updating the device tree at runtime */
-extern void of_detach_node(struct device_node *);
-
/* Other Prototypes */
extern int early_uartlite_console(void);
Index: test-devicetree/arch/powerpc/include/asm/prom.h
===================================================================
--- test-devicetree.orig/arch/powerpc/include/asm/prom.h 2009-11-20 12:24:07.000000000 -0600
+++ test-devicetree/arch/powerpc/include/asm/prom.h 2009-11-20 12:30:41.000000000 -0600
@@ -34,9 +34,6 @@
#define HAVE_ARCH_DEVTREE_FIXUPS
-/* For updating the device tree at runtime */
-extern void of_detach_node(struct device_node *);
-
#ifdef CONFIG_PPC32
/*
* PCI <-> OF matching functions
Index: test-devicetree/include/linux/of_dynamic.h
===================================================================
--- test-devicetree.orig/include/linux/of_dynamic.h 2009-11-20 12:27:09.000000000 -0600
+++ test-devicetree/include/linux/of_dynamic.h 2009-11-20 12:30:22.000000000 -0600
@@ -23,4 +23,5 @@
extern rwlock_t devtree_lock;
extern void of_attach_node(struct device_node *);
+extern void of_detach_node(struct device_node *);
#endif
^ 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