* Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Kumar Gala @ 2007-10-18 19:58 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071018180104.GB16748@localhost.localdomain>
On Oct 18, 2007, at 1:01 PM, Anton Vorontsov wrote:
> MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8568mds.dts | 34 +++++++++++++++++++++++
> ++++++++++-
> 1 files changed, 33 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/
> boot/dts/mpc8568mds.dts
> index be8d512..758ada4 100644
> --- a/arch/powerpc/boot/dts/mpc8568mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8568mds.dts
> @@ -47,12 +47,44 @@
> #size-cells = <1>;
> compatible = "fsl,mpc8568-localbus";
> reg = <e0005000 d8>;
> - ranges = <1 0 f8000000 0008000>;
> + ranges = <1 0 f8000000 0008000
> + 0 0 fe000000 2000000>;
>
> bcsr@1,0 {
> device_type = "board-control";
> reg = <1 0 8000>;
> };
> +
> + flash@0,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
> + reg = <0 0 2000000>;
> + bank-width = <2>;
> + device-width = <1>;
> +
Are you basing the partition map on something or making it up?
Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
rootfs?
> + hrcw@0 {
> + label = "hrcw";
> + reg = <0 20000>;
> + read-only;
> + };
> +
> + kernel@20000 {
> + label = "kernel";
> + reg = <20000 200000>;
> + };
> +
> + rootfs@220000 {
> + label = "rootfs";
> + reg = <220000 1d60000>;
> + };
> +
> + uboot@1f80000 {
> + label = "u-boot";
> + reg = <1f80000 80000>;
> + read-only;
> + };
> + };
> };
>
> soc8568@e0000000 {
> --
> 1.5.0.6
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: qe: add ability to upload QE firmware
From: Anton Vorontsov @ 2007-10-18 19:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4717ADCE.9070807@freescale.com>
On Thu, Oct 18, 2007 at 02:02:38PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>>> + if (firmware->length == (length + sizeof(u32))) {
>>> + /* Length is valid, and there's a CRC */
>>> + crc = be32_to_cpu(*((__be32 *) ((void *) firmware + length)));
>> Spaces are not needed after "(__be32 *)" and "(void *)". The whole
>> construction isn't easy to parse, thus spaces are only distracting.
>
> I have to disagree. I added the spaces to make it easier to read.
>
>>> + /* If there's only one microcode, then we assume it's common for all
>>> + RISCs, so we set the CERCR.CIR bit to share the IRAM with all RISCs.
>>> + This should be safe even on SOCs with only one RISC.
>>> +
>>> + If there are multiple 'microcode' structures, but each one points
>>> + to the same microcode binary (ignoring offsets), then we also assume
>>> + that we want share RAM.
>>> + */
>> Comment style is unorthodox.
>
> Should I prefix each line with a "*"?
Yup.
Heh... well, ideal multiline comment is:
/*
* Multiline comment here.
*/
But this doesn't matter much, the salt is in "*"s. ;-)
>>> + code = (void *) firmware + be32_to_cpu(ucode->code_offset);
>> space after (void *).
>
> Really? This:
>
> code = (void *)firmware + be32_to_cpu(ucode->code_offset);
>
> is harder to read. Without the space, it looks like *)firmware is one
> word.
:-) I'm not about to argue, this is each own preference.
But to complete my point: I don't care what style exactly is used, what
I care about is consistency across the code I'm looking in. 100%
consistency is not affordable, of course. But we're all trying, aren't we?
(type *)variable is orthodox style, and when I see unusual style, my eyes
are itching, and this code is hard to read (to me). So, if everybody will
switch to "(type *) variable" style -- I'll just follow.
And again: this is all of minor importance, just my $0.02 for the code
consistency.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] trivial - QUICC UCC driver - remove buggy and unused vdbg macro
From: Joe Perches @ 2007-10-18 19:24 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, linuxppc-dev
remove buggy and unused vdbg macro
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index df884f0..a4b481c 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -46,13 +46,6 @@
#include "ucc_geth_mii.h"
#include "ucc_geth.h"
-#define DEBUG
-#ifdef DEBUG
-#define vdbg(format, arg...) printk(KERN_DEBUG , format "\n" , ## arg)
-#else
-#define vdbg(format, arg...) do {} while(0)
-#endif
-
#define MII_DRV_DESC "QE UCC Ethernet Controller MII Bus"
#define MII_DRV_NAME "fsl-uec_mdio"
^ permalink raw reply related
* Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
From: Jeff Garzik @ 2007-10-18 19:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, netdev, Domen Puncer
In-Reply-To: <fa686aa40710180715u23d81adfy83ff65837725fb80@mail.gmail.com>
Grant Likely wrote:
> On 10/15/07, Jeff Garzik <jgarzik@pobox.com> wrote:
>> Domen Puncer wrote:
>>> Hello!
>>>
>>> If there are no objections, I would like to get this merged
>>> when bestcomm goes in (any time now?).
>>>
>>> It's split into four parts:
>>> 1 - device tree
>>> 2 - small bestcomm change
>>> 3 - the actual driver
>>> 4 - phy part of the driver
>> patches #3 and #4 need to be combined together.
>>
>> Are the arch people OK with patches #1 and #2?
>
> Jeff,
>
> The bestcomm patches and patch 1 & 2 from this series are now in
> Linus' tree. That clears the way for the FEC driver when Domen
> reposts it. (In other words; there is nothing left in arch land
> blocking this driver)
>
except a resend combining patches 3 and 4 as requested :)
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Linas Vepstas @ 2007-10-18 19:09 UTC (permalink / raw)
To: Michael Ellerman
Cc: sparclinux, Stephen Rothwell, Paul Mackerras, David S. Miller,
linuxppc-dev
In-Reply-To: <1192670843.6681.10.camel@concordia>
On Thu, Oct 18, 2007 at 11:27:23AM +1000, Michael Ellerman wrote:
>
> It does what pci_device_to_OF_node() does, but in the right way.
>
> The plan is to remove pci_device_to_OF_node() once all the callers have
> been converted to properly handle the refcounting.
Oh. Yes. well, of course, then. Excellent reason. I didn't get
that from the patch commit comments. So, FWIW:
Ack'ed-by: Linas Vepstas <linas@austin.ibm.com>
--linas
^ permalink raw reply
* RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-18 19:04 UTC (permalink / raw)
To: Grant Likely
Cc: Leonid, Arnd Bergmann, microblaze-uclinux, linuxppc-dev,
Wolfgang Reissnegger
In-Reply-To: <fa686aa40710181112pbe37a18xb21b7c5bcbe973b6@mail.gmail.com>
=20
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Thursday, October 18, 2007 11:13 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;=20
> microblaze-uclinux@itee.uq.edu.au; Josh Boyer; Arnd Bergmann
> Subject: Re: [PATCH v3] Device tree bindings for Xilinx devices
>=20
> On 10/18/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > > -----Original Message-----
> > > From: Grant Likely [mailto:grant.likely@secretlab.ca]
> > > Sent: Thursday, October 18, 2007 10:23 AM
> > > To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang
> > > Reissnegger; Leonid; microblaze-uclinux@itee.uq.edu.au; Josh
> > > Boyer; Arnd Bergmann
> > > Subject: [PATCH v3] Device tree bindings for Xilinx devices
> > >
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > Acked-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> >
> > This is good enough for the moment, and it reflects the=20
> best we can do
> > right now... But:
> >
> > > + (parameter#): C_* parameters from system.mhs. The C_
> > > prefix is
> > > + dropped from the parameter name, the
> > > name is converted
> > > + to lowercase and all underscore '_'
> > > characters are
> > > + converted to dashes '-'.
> >
> > Unfortunately, xparameters don't follow this exactly,=20
> particularly for
> > the 'multiple logical devices' case... Maybe it's worth adding
> > something like: "For simple devices, the parameter name can=20
> be formed
> > by:"
>=20
> What specific parts of this are you concerned about? Examples?
Imagine if the ps2 adapter had a parameter "FOO" for each logical
device, In the core, one would be named C_PORT_0_FOO and another
C_PORT_1_FOO. But, of course, you would want the FOO parameters to be
unmangled in the correct way for each port (as your hierarchical example
shows, but without any parameters). In the xparameters, this unmangling
has been done, and the xparameters would look something like
XPAR_PS2_0_FOO and XPAR_PS2_1_FOO.
In other cases, xparameters for one core might be extracted from another
core that it is connected to, and in fact might reflect how the two are
connected. This is how some cores under development will work (in EDK
9.2).
In short, I think its better to think about this all relative to
xparameters, rather than relative to the .mhs file. In all current
cases, this is (I think) the same, but in the (very near future) it
won't be.
> > In any event, this should essentially document what the=20
> mechanism for
> > generating the device trees actually does... Have you updated
> > gen_mhs_devtree.py to reflect all this?
>=20
> No; I'm looking at this as a line in the sand that we can use as a
> starting point and discuss the issues.
OK... Well, as far as I'm concerned it looks good enough that we should
try it out... :) I'll hack up gen_mhs_devtree and see how far we get.
> > > + Typically, the compatible list will include the exact IP
> > > core version
> > > + followed by an older IP core version which implements the same
> > > + interface or any other device with the same interface.
> >
> > This seems to be awkward, since it means that the tree=20
> *and* the driver
> > will likely have long lists of compatible types. In the=20
> driver, this is
> > hard to maintain, and in the device tree we don't have an=20
> easy way of
> > knowing exactly what is compatible and what isn't anyway...=20
> It seems
> > better to me to have the
> > compatible list include the exact type (e.g.=20
> xilinx,opb-uartlite-1.00.b)
> > and
> > a generic compatibility class (e.g. xilinx,uartlite), and for the
> > drivers
> > to essentially define the gross compatibility classes. =20
> Then the driver
> > only has an of_match with:
> >
> > .compatible =3D "xilinx,uartlite"
>=20
> The problem with this is how do you define what "xilinx,uartlite" is?
> For example; there have been 3 major versions of the plb_temac, and
> IIRC v2 and v3 are *not* compatible. Which one is xilinx,temac?
>=20
> However, this does not need to result in a long list. Basically, the
> list should include the exact version of the device plus the first
> version that implemented that interface. (hence it is "compatible"
> with the earlier version of the device). If there are no prior
> devices implementing the same device, then the compatible list has
> exactly one instance. This document should probably include a list of
> the well-known compatible values for each of the xilinx devices.
>=20
> I used to try and come up with generic values for compatible, but it
> just ends up causing problems in the long run. The concept of what is
> generic changes over time, but a specific version is a known quantity.
OK... I'll buy it... :) I missed the emphasis on the 'sparseness'...
And I agree about the versions being really canonical: we just need to
make sure that the actual versions that are critical get back in at some
point.
Steve
^ permalink raw reply
* Re: [PATCH v2 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Marian Balakowicz @ 2007-10-18 19:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710181153w7bb794ceve38e7802d603ad42@mail.gmail.com>
Grant Likely wrote:
> On 10/18/07, Marian Balakowicz <m8@semihalf.com> wrote:
>> Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
>>
>> This patch relies on Sascha Hauer's patch published in:
>> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> By 'relies', do you mean "depends on" or "was derived from"?
Initial version was derived from, and since then it slightly evolved.
m.
^ permalink raw reply
* Re: qe: add ability to upload QE firmware
From: Timur Tabi @ 2007-10-18 19:02 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071018185738.GA16782@localhost.localdomain>
Anton Vorontsov wrote:
>> + if (firmware->length == (length + sizeof(u32))) {
>> + /* Length is valid, and there's a CRC */
>> + crc = be32_to_cpu(*((__be32 *) ((void *) firmware + length)));
>
> Spaces are not needed after "(__be32 *)" and "(void *)". The whole
> construction isn't easy to parse, thus spaces are only distracting.
I have to disagree. I added the spaces to make it easier to read.
>> + /* If there's only one microcode, then we assume it's common for all
>> + RISCs, so we set the CERCR.CIR bit to share the IRAM with all RISCs.
>> + This should be safe even on SOCs with only one RISC.
>> +
>> + If there are multiple 'microcode' structures, but each one points
>> + to the same microcode binary (ignoring offsets), then we also assume
>> + that we want share RAM.
>> + */
>
> Comment style is unorthodox.
Should I prefix each line with a "*"?
>> + code = (void *) firmware + be32_to_cpu(ucode->code_offset);
>
> space after (void *).
Really? This:
code = (void *)firmware + be32_to_cpu(ucode->code_offset);
is harder to read. Without the space, it looks like *)firmware is one word.
I shall apply the other changes. Thanks.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: qe: add ability to upload QE firmware
From: Anton Vorontsov @ 2007-10-18 18:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <11927201051427-git-send-email-timur@freescale.com>
On Thu, Oct 18, 2007 at 10:08:25AM -0500, Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and instructions
> on how to upload it. Add function qe_upload_microcode() to parse the blob
> and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
> include the actual RISC Special Registers.
[...]
> I need to add a few fields to the structure, but I would still appreciate
> comments on the structure and the corresponding code.
It seems I'm too lazy to go deep inside the code, but it's okay... because
I believe it is works fine. ;-)
Thus sorry, only fluffy cosmetic notes.
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
[...]
> + if (firmware->length == (length + sizeof(u32))) {
> + /* Length is valid, and there's a CRC */
> + crc = be32_to_cpu(*((__be32 *) ((void *) firmware + length)));
Spaces are not needed after "(__be32 *)" and "(void *)". The whole
construction isn't easy to parse, thus spaces are only distracting.
> + if (crc != crc32(0, firmware, length)) {
> + printk(KERN_ERR "QE: firmware CRC is invalid\n");
> + return -EIO;
> + }
> + } else if (firmware->length != length) {
> + printk(KERN_ERR "QE: invalid length(s) in firware structure\n");
> + return -EPERM;
> + }
> +
> + /* If there's only one microcode, then we assume it's common for all
> + RISCs, so we set the CERCR.CIR bit to share the IRAM with all RISCs.
> + This should be safe even on SOCs with only one RISC.
> +
> + If there are multiple 'microcode' structures, but each one points
> + to the same microcode binary (ignoring offsets), then we also assume
> + that we want share RAM.
> + */
Comment style is unorthodox.
> + if (firmware->count == 1)
> + setbits16(&qe_immr->cp.cercr, cpu_to_be16(0x800));
> + else {
I'd place braces for the first 'if'. No lines added, more good looking.
The CodingStyle also suggest this.
> + for (i = 1; i < firmware->count; i++)
I'd place braces here too. No rationale though, just better looking.
> + if (firmware->microcode[i].code_offset !=
> + firmware->microcode[0].code_offset)
> + break;
> +
> + if (i == firmware->count)
> + setbits16(&qe_immr->cp.cercr, cpu_to_be16(0x800));
0x800? Desires proper #define.
> + }
> +
> + if (firmware->soc.model)
> + printk(KERN_INFO "QE: uploading microcode '%s' for %u V%u.%u\n",
> + firmware->id, be16_to_cpu(firmware->soc.model),
> + firmware->soc.rev_h, firmware->soc.rev_l);
> + else
> + printk(KERN_INFO "QE: uploading microcode '%s'\n",
> + firmware->id);
> +
> + for (i = 0; i < firmware->count; i++) {
> + const struct qe_microcode *ucode = &firmware->microcode[i];
> +
> + code = (void *) firmware + be32_to_cpu(ucode->code_offset);
space after (void *).
> + /* Use auto-increment */
> + out_be32(&qe_immr->iram.iadd, cpu_to_be32(0x80080000 |
magic number.
> + be32_to_cpu(ucode->iram_offset)));
> +
> + for (j = 0; j < ucode->count; j++)
> + out_be32(&qe_immr->iram.idata, be32_to_cpu(code[j]));
> +
> + /* Program the traps. We program both RISCs, even on platforms
> + that only have one. This *should* be safe. */
> + for (j = 0; j < 16; j++)
> + if (ucode->traps[j]) {
> + u32 trap = be32_to_cpu(ucode->traps[j]);
> + out_be32(&qe_immr->rsp[0].tibcr[j], trap);
Empty line needed after variable declaration.
> + out_be32(&qe_immr->rsp[1].tibcr[j], trap);
> + }
> + }
> +
> + /* Enable the traps for both RISCs. Again, on a single-RISC system,
> + this should be safe. */
Comment.
> + out_be32(&qe_immr->rsp[0].eccr, cpu_to_be32(0x20800000));
> + out_be32(&qe_immr->rsp[1].eccr, cpu_to_be32(0x20800000));
magic numbers.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v2 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Grant Likely @ 2007-10-18 18:53 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071018184433.3584.77107.stgit@hekate.izotz.org>
On 10/18/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
By 'relies', do you mean "depends on" or "was derived from"?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH v2 4/4] [POWERPC] Enable restart support for lite5200 board
From: Marian Balakowicz @ 2007-10-18 18:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071018184407.3584.3513.stgit@hekate.izotz.org>
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
arch/powerpc/platforms/52xx/lite5200.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 65b7ae4..25d2bfa 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -145,6 +145,9 @@ static void __init lite5200_setup_arch(void)
/* Some mpc5200 & mpc5200b related configuration */
mpc5200_setup_xlb_arbiter();
+ /* Map wdt for mpc52xx_restart() */
+ mpc52xx_map_wdt();
+
#ifdef CONFIG_PM
mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
mpc52xx_suspend.board_resume_finish = lite5200_resume_finish;
@@ -183,5 +186,6 @@ define_machine(lite5200) {
.init = mpc52xx_declare_of_platform_devices,
.init_IRQ = mpc52xx_init_irq,
.get_irq = mpc52xx_get_irq,
+ .restart = mpc52xx_restart,
.calibrate_decr = generic_calibrate_decr,
};
^ permalink raw reply related
* [PATCH v2 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Marian Balakowicz @ 2007-10-18 18:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071018184407.3584.3513.stgit@hekate.izotz.org>
Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
This patch relies on Sascha Hauer's patch published in:
http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 50 ++++++++++++++++++++++++++
include/asm-powerpc/mpc52xx.h | 3 ++
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 74b4b41..9850685 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -18,6 +18,13 @@
#include <asm/prom.h>
#include <asm/mpc52xx.h>
+/*
+ * This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
+ * Permanent mapping is required because mpc52xx_restart() can be called
+ * from interrupt context while node mapping (which calls ioremap())
+ * cannot be used at such point.
+ */
+static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
static void __iomem *
mpc52xx_map_node(struct device_node *ofn)
@@ -126,3 +133,46 @@ mpc52xx_declare_of_platform_devices(void)
"Error while probing of_platform bus\n");
}
+void __init
+mpc52xx_map_wdt(void)
+{
+ const void *has_wdt;
+ 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.
+ */
+ for_each_compatible_node(np, NULL, "fsl,mpc5200-gpt") {
+ has_wdt = of_get_property(np, "fsl,has-wdt", NULL);
+ if (has_wdt) {
+ mpc52xx_wdt = mpc52xx_map_node(np);
+ return;
+ }
+ }
+ for_each_compatible_node(np, NULL, "mpc5200-gpt") {
+ has_wdt = of_get_property(np, "has-wdt", NULL);
+ if (has_wdt) {
+ mpc52xx_wdt = mpc52xx_map_node(np);
+ return;
+ }
+ }
+}
+
+void
+mpc52xx_restart(char *cmd)
+{
+ local_irq_disable();
+
+ /* Turn on the watchdog and wait for it to expire.
+ * It effectively does a reset. */
+ if (mpc52xx_wdt) {
+ out_be32(&mpc52xx_wdt->mode, 0x00000000);
+ out_be32(&mpc52xx_wdt->count, 0x000000ff);
+ out_be32(&mpc52xx_wdt->mode, 0x00009004);
+ } else
+ printk("mpc52xx_restart: Can't access wdt. "
+ "Restart impossible, system halted.\n");
+
+ while (1);
+}
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 9cf05f9..39f619f 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -252,6 +252,9 @@ extern unsigned int mpc52xx_get_irq(void);
extern int __init mpc52xx_add_bridge(struct device_node *node);
+extern void __init mpc52xx_map_wdt(void);
+extern void mpc52xx_restart(char *cmd);
+
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_PM
^ permalink raw reply related
* [PATCH v2 2/4] [POWERPC] Update device tree binding for mpc5200 gpt
From: Marian Balakowicz @ 2007-10-18 18:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071018184407.3584.3513.stgit@hekate.izotz.org>
Add 'fsl,' prefix to 'compatible' property for gpt nodes.
Add 'fsl,' prefix to empty, GPT0 specific 'has-wdt' property.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
---
.../powerpc/mpc52xx-device-tree-bindings.txt | 4 ++-
arch/powerpc/boot/dts/lite5200.dts | 26 +++++++-------------
arch/powerpc/boot/dts/lite5200b.dts | 26 +++++++-------------
drivers/char/watchdog/mpc5200_wdt.c | 3 ++
4 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index e59fcbb..fedf7ef 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -185,7 +185,7 @@ bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires
Recommended soc5200 child nodes; populate as needed for your board
name device_type compatible Description
---- ----------- ---------- -----------
-gpt@<addr> gpt mpc5200-gpt General purpose timers
+gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
rtc@<addr> rtc mpc5200-rtc Real time clock
mscan@<addr> mscan mpc5200-mscan CAN bus controller
pci@<addr> pci mpc5200-pci PCI bridge
@@ -213,7 +213,7 @@ cell-index int When multiple devices are present, is the
5) General Purpose Timer nodes (child of soc5200 node)
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
design supports the internal wdt, then the device node for GPT0 should
-include the empty property 'has-wdt'.
+include the empty property 'fsl,has-wdt'.
6) PSC nodes (child of soc5200 node)
PSC nodes can define the optional 'port-number' property to force assignment
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index bc45f5f..6731763 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -70,18 +70,16 @@
};
gpt@600 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <0>;
reg = <600 10>;
interrupts = <1 9 0>;
interrupt-parent = <&mpc5200_pic>;
- has-wdt;
+ fsl,has-wdt;
};
gpt@610 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <1>;
reg = <610 10>;
interrupts = <1 a 0>;
@@ -89,8 +87,7 @@
};
gpt@620 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <2>;
reg = <620 10>;
interrupts = <1 b 0>;
@@ -98,8 +95,7 @@
};
gpt@630 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <3>;
reg = <630 10>;
interrupts = <1 c 0>;
@@ -107,8 +103,7 @@
};
gpt@640 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <4>;
reg = <640 10>;
interrupts = <1 d 0>;
@@ -116,8 +111,7 @@
};
gpt@650 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <5>;
reg = <650 10>;
interrupts = <1 e 0>;
@@ -125,8 +119,7 @@
};
gpt@660 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <6>;
reg = <660 10>;
interrupts = <1 f 0>;
@@ -134,8 +127,7 @@
};
gpt@670 { // General Purpose Timer
- compatible = "mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200-gpt";
cell-index = <7>;
reg = <670 10>;
interrupts = <1 10 0>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 6582c9a..b540388 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -70,18 +70,16 @@
};
gpt@600 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <0>;
reg = <600 10>;
interrupts = <1 9 0>;
interrupt-parent = <&mpc5200_pic>;
- has-wdt;
+ fsl,has-wdt;
};
gpt@610 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <1>;
reg = <610 10>;
interrupts = <1 a 0>;
@@ -89,8 +87,7 @@
};
gpt@620 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <2>;
reg = <620 10>;
interrupts = <1 b 0>;
@@ -98,8 +95,7 @@
};
gpt@630 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <3>;
reg = <630 10>;
interrupts = <1 c 0>;
@@ -107,8 +103,7 @@
};
gpt@640 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <4>;
reg = <640 10>;
interrupts = <1 d 0>;
@@ -116,8 +111,7 @@
};
gpt@650 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <5>;
reg = <650 10>;
interrupts = <1 e 0>;
@@ -125,8 +119,7 @@
};
gpt@660 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <6>;
reg = <660 10>;
interrupts = <1 f 0>;
@@ -134,8 +127,7 @@
};
gpt@670 { // General Purpose Timer
- compatible = "mpc5200b-gpt","mpc5200-gpt";
- device_type = "gpt";
+ compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <7>;
reg = <670 10>;
interrupts = <1 10 0>;
diff --git a/drivers/char/watchdog/mpc5200_wdt.c b/drivers/char/watchdog/mpc5200_wdt.c
index 9cfb975..11f6a11 100644
--- a/drivers/char/watchdog/mpc5200_wdt.c
+++ b/drivers/char/watchdog/mpc5200_wdt.c
@@ -176,6 +176,8 @@ static int mpc5200_wdt_probe(struct of_device *op, const struct of_device_id *ma
has_wdt = of_get_property(op->node, "has-wdt", NULL);
if (!has_wdt)
+ has_wdt = of_get_property(op->node, "fsl,has-wdt", NULL);
+ if (!has_wdt)
return -ENODEV;
wdt = kzalloc(sizeof(*wdt), GFP_KERNEL);
@@ -254,6 +256,7 @@ static int mpc5200_wdt_shutdown(struct of_device *op)
static struct of_device_id mpc5200_wdt_match[] = {
{ .compatible = "mpc5200-gpt", },
+ { .compatible = "fsl,mpc5200-gpt", },
{},
};
static struct of_platform_driver mpc5200_wdt_driver = {
^ permalink raw reply related
* [PATCH v2 1/4] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
From: Marian Balakowicz @ 2007-10-18 18:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071018184407.3584.3513.stgit@hekate.izotz.org>
Add helper routine mpc52xx_find_and_map_path(). Extract common code to
mpc52xx_map_node() and refactor mpc52xx_find_and_map().
Signed-off-by: Jan Wrobel <wrr@semihalf.com>
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/platforms/52xx/mpc52xx_common.c | 21 +++++++++++++++++----
include/asm-powerpc/mpc52xx.h | 1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 3bc201e..74b4b41 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -19,14 +19,12 @@
#include <asm/mpc52xx.h>
-void __iomem *
-mpc52xx_find_and_map(const char *compatible)
+static void __iomem *
+mpc52xx_map_node(struct device_node *ofn)
{
- struct device_node *ofn;
const u32 *regaddr_p;
u64 regaddr64, size64;
- ofn = of_find_compatible_node(NULL, NULL, compatible);
if (!ofn)
return NULL;
@@ -42,8 +40,23 @@ mpc52xx_find_and_map(const char *compatible)
return ioremap((u32)regaddr64, (u32)size64);
}
+
+void __iomem *
+mpc52xx_find_and_map(const char *compatible)
+{
+ return mpc52xx_map_node(
+ of_find_compatible_node(NULL, NULL, compatible));
+}
+
EXPORT_SYMBOL(mpc52xx_find_and_map);
+void __iomem *
+mpc52xx_find_and_map_path(const char *path)
+{
+ return mpc52xx_map_node(of_find_node_by_path(path));
+}
+
+EXPORT_SYMBOL(mpc52xx_find_and_map_path);
/**
* mpc52xx_find_ipb_freq - Find the IPB bus frequency for a device
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 24751df..9cf05f9 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -242,6 +242,7 @@ struct mpc52xx_cdm {
#ifndef __ASSEMBLY__
extern void __iomem * mpc52xx_find_and_map(const char *);
+extern void __iomem * mpc52xx_find_and_map_path(const char *path);
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);
^ permalink raw reply related
* [PATCH v2 0/4] [POWERPC] MPC5200: update gpt binding, add restart support
From: Marian Balakowicz @ 2007-10-18 18:44 UTC (permalink / raw)
To: linuxppc-dev
Here's the second version of MPC5200 patches, please review. Thanks!
[POWERPC] Enable restart support for lite5200 board
[POWERPC] Add restart support for mpc52xx based platforms
[POWERPC] Update device tree binding for mpc5200 gpt
[POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
Cheers,
m.
^ permalink raw reply
* Re: [PATCH v3] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-18 18:12 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Leonid, Arnd Bergmann, microblaze-uclinux, linuxppc-dev,
Wolfgang Reissnegger
In-Reply-To: <20071018174956.05D7A1AA008D@mail197-blu.bigfish.com>
On 10/18/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > -----Original Message-----
> > From: Grant Likely [mailto:grant.likely@secretlab.ca]
> > Sent: Thursday, October 18, 2007 10:23 AM
> > To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang
> > Reissnegger; Leonid; microblaze-uclinux@itee.uq.edu.au; Josh
> > Boyer; Arnd Bergmann
> > Subject: [PATCH v3] Device tree bindings for Xilinx devices
> >
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> This is good enough for the moment, and it reflects the best we can do
> right now... But:
>
> > + (parameter#): C_* parameters from system.mhs. The C_
> > prefix is
> > + dropped from the parameter name, the
> > name is converted
> > + to lowercase and all underscore '_'
> > characters are
> > + converted to dashes '-'.
>
> Unfortunately, xparameters don't follow this exactly, particularly for
> the 'multiple logical devices' case... Maybe it's worth adding
> something like: "For simple devices, the parameter name can be formed
> by:"
What specific parts of this are you concerned about? Examples?
>
> In any event, this should essentially document what the mechanism for
> generating the device trees actually does... Have you updated
> gen_mhs_devtree.py to reflect all this?
No; I'm looking at this as a line in the sand that we can use as a
starting point and discuss the issues.
>
> > + Typically, the compatible list will include the exact IP
> > core version
> > + followed by an older IP core version which implements the same
> > + interface or any other device with the same interface.
>
> This seems to be awkward, since it means that the tree *and* the driver
> will likely have long lists of compatible types. In the driver, this is
> hard to maintain, and in the device tree we don't have an easy way of
> knowing exactly what is compatible and what isn't anyway... It seems
> better to me to have the
> compatible list include the exact type (e.g. xilinx,opb-uartlite-1.00.b)
> and
> a generic compatibility class (e.g. xilinx,uartlite), and for the
> drivers
> to essentially define the gross compatibility classes. Then the driver
> only has an of_match with:
>
> .compatible = "xilinx,uartlite"
The problem with this is how do you define what "xilinx,uartlite" is?
For example; there have been 3 major versions of the plb_temac, and
IIRC v2 and v3 are *not* compatible. Which one is xilinx,temac?
However, this does not need to result in a long list. Basically, the
list should include the exact version of the device plus the first
version that implemented that interface. (hence it is "compatible"
with the earlier version of the device). If there are no prior
devices implementing the same device, then the compatible list has
exactly one instance. This document should probably include a list of
the well-known compatible values for each of the xilinx devices.
I used to try and come up with generic values for compatible, but it
just ends up causing problems in the long run. The concept of what is
generic changes over time, but a specific version is a known quantity.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Anton Vorontsov @ 2007-10-18 18:01 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <2eed9d85d53305b2b0d6e8f8287148f7a600ad19.1192730268.git.avorontsov@ru.mvista.com>
MPC8568E-MDS have 1 32MB Spansion x16 CFI flash chip. Let's use it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index be8d512..758ada4 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -47,12 +47,44 @@
#size-cells = <1>;
compatible = "fsl,mpc8568-localbus";
reg = <e0005000 d8>;
- ranges = <1 0 f8000000 0008000>;
+ ranges = <1 0 f8000000 0008000
+ 0 0 fe000000 2000000>;
bcsr@1,0 {
device_type = "board-control";
reg = <1 0 8000>;
};
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
+ reg = <0 0 2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ hrcw@0 {
+ label = "hrcw";
+ reg = <0 20000>;
+ read-only;
+ };
+
+ kernel@20000 {
+ label = "kernel";
+ reg = <20000 200000>;
+ };
+
+ rootfs@220000 {
+ label = "rootfs";
+ reg = <220000 1d60000>;
+ };
+
+ uboot@1f80000 {
+ label = "u-boot";
+ reg = <1f80000 80000>;
+ read-only;
+ };
+ };
};
soc8568@e0000000 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH v3 1/2] [POWERPC] MPC8568E-MDS: create localbus node
From: Anton Vorontsov @ 2007-10-18 18:00 UTC (permalink / raw)
To: linuxppc-dev
This patch creates localbus node, moves bcsr into it, and adds
localbus to the probe path.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 14 +++++++++++---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..be8d512 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -42,9 +42,17 @@
reg = <00000000 10000000>;
};
- bcsr@f8000000 {
- device_type = "board-control";
- reg = <f8000000 8000>;
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8568-localbus";
+ reg = <e0005000 d8>;
+ ranges = <1 0 f8000000 0008000>;
+
+ bcsr@1,0 {
+ device_type = "board-control";
+ reg = <1 0 8000>;
+ };
};
soc8568@e0000000 {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 61b3eed..45ffca4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -139,6 +139,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "qe", },
+ { .compatible = "fsl,mpc8568-localbus", },
{},
};
--
1.5.0.6
^ permalink raw reply related
* RE: [PATCH v3] Device tree bindings for Xilinx devices
From: Stephen Neuendorffer @ 2007-10-18 17:49 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Wolfgang Reissnegger, Leonid,
microblaze-uclinux, Josh Boyer, Arnd Bergmann
In-Reply-To: <20071018172259.14948.74736.stgit@trillian.cg.shawcable.net>
=20
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]=20
> Sent: Thursday, October 18, 2007 10:23 AM
> To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang=20
> Reissnegger; Leonid; microblaze-uclinux@itee.uq.edu.au; Josh=20
> Boyer; Arnd Bergmann
> Subject: [PATCH v3] Device tree bindings for Xilinx devices
>=20
> From: Grant Likely <grant.likely@secretlab.ca>
>=20
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
This is good enough for the moment, and it reflects the best we can do
right now... But:
> + (parameter#): C_* parameters from system.mhs. The C_=20
> prefix is
> + dropped from the parameter name, the=20
> name is converted
> + to lowercase and all underscore '_'=20
> characters are
> + converted to dashes '-'.
Unfortunately, xparameters don't follow this exactly, particularly for
the 'multiple logical devices' case... Maybe it's worth adding
something like: "For simple devices, the parameter name can be formed
by:"
In any event, this should essentially document what the mechanism for
generating the device trees actually does... Have you updated
gen_mhs_devtree.py to reflect all this?
> + Typically, the compatible list will include the exact IP=20
> core version
> + followed by an older IP core version which implements the same
> + interface or any other device with the same interface.
This seems to be awkward, since it means that the tree *and* the driver
will likely have long lists of compatible types. In the driver, this is
hard to maintain, and in the device tree we don't have an easy way of
knowing exactly what is compatible and what isn't anyway... It seems
better to me to have the
compatible list include the exact type (e.g. xilinx,opb-uartlite-1.00.b)
and
a generic compatibility class (e.g. xilinx,uartlite), and for the
drivers
to essentially define the gross compatibility classes. Then the driver
only has an of_match with:
.compatible =3D "xilinx,uartlite"
Steve
^ permalink raw reply
* Re: Merge dtc
From: Milton Miller @ 2007-10-18 17:49 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras, Sam Ravnborg
On Tue Oct 16 15:02:17 EST 2007, David Gibson wrote:
> This very large patch incorporates a copy of dtc into the kernel
> source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> longer an external dependency to build kernels with configurations
> which need a dtb file.
>
> Signed-off-by: David Gibson <david at gibson.dropbear.id.au>
>
> Too big for the list, full patch at
> http://ozlabs.org/~dgibson/home/merge-dtc.patch+
So split it up. The obvious one is "here is the unique content, then
copy these files from dtc git" would have been better.
I finally went and looked at the url. The Kbuild integration is wrong.
It should build dtc in dtc-src and run the binary from there, and the
rules should be in a Kconfig as a normal host-target in that directory.
(I don't have a problem with that Kbuild including Makefie.dtc).
things like the dependancy on scripts_basic in the top level Makefile.
milton
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Grant Likely @ 2007-10-18 17:29 UTC (permalink / raw)
To: Milton Miller
Cc: linuxppc-dev, Paul Mackerras, Rob Landley, Christoph Hellwig
In-Reply-To: <440d60abf1ef533839cf5d9beb0584c9@bga.com>
On 10/18/07, Milton Miller <miltonm@bga.com> wrote:
> On Oct 18, 2007, at 4:59 AM, Matt Sealey wrote:
> > Which begs the question; why cloning?
> >
> > Why can't development be MOVED to in-kernel?
>
> Because we don't put userspace testsuites there for one.
>
> And its a stand alone tool and should have its own packaging for a
> second (ie the kernel provides the kernel and modules, but not random
> user space utilities, in its tarbal).
>
> If we say only some boards or ports are special and need to build then
> I would vote for shipping asm files. If we think we need to build any
> random embedded platform without installing dtc then we should merge
> dtc.
I don't think we do. It's looking like there are going to be out of
tree users of dtc also (The are some patches floating around for
u-boot to use the device tree for it's own initialization). I don't
think it's unreasonable to install dtc for embedded development.
I like the idea of shipping asm files to support the qemu target; at
least until qemu gets better firmware.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH v3] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-18 17:22 UTC (permalink / raw)
To: linuxppc-dev, Stephen Neuendorffer, Wolfgang Reissnegger, Leonid,
microblaze-uclinux, Josh Boyer, Arnd Bergmann
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Documentation/powerpc/booting-without-of.txt | 264 ++++++++++++++++++++++++++
1 files changed, 264 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index a96e853..d4dedf4 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -52,6 +52,7 @@ Table of Contents
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
+ l) Xilinx IP cores
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2242,6 +2243,269 @@ platforms are moved over to use the flattened-device-tree model.
available.
For Axon: 0x0000012a
+ l) Xilinx IP cores
+
+ The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
+ in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
+ of standard device types (network, serial, etc.) and miscellanious
+ devices (gpio, LCD, spi, etc). Also, since these devices are
+ implemented within the fpga fabric every instance of the device can be
+ synthesised with different options that change the behaviour.
+
+ Each IP-core has a set of parameters which the FPGA designer can use to
+ control how the core is synthesized. Historically, the EDK tool would
+ extract the device parameters relevant to device drivers and copy them
+ into an 'xparameters.h' in the form of #define symbols. This tells the
+ device drivers how the IP cores are configured, but it requres the kernel
+ to be recompiled every time the FPGA bitstream is resynthesized.
+
+ The new approach is to export the parameters into the device tree and
+ generate a new device tree each time the FPGA bitstream changes. The
+ parameters which used to be exported as #defines will now become
+ properties of the device node. In general, device nodes for IP-cores
+ will take the following form:
+
+ (name)@(base-address) {
+ compatible = "xilinx,(ip-core-name)-(HW_VER)"
+ [, (list of compatible devices), ...];
+ reg = <(baseaddr) (size)>;
+ interrupt-parent = <&interrupt-controller-phandle>;
+ interrupts = < ... >;
+ xilinx,(parameter1) = "(string-value)";
+ xilinx,(parameter2) = <(int-value)>;
+ };
+
+ (ip-core-name): the name of the ip block (given after the BEGIN
+ directive in system.mhs). Should be in lowercase
+ and all underscores '_' converted to dashes '-'.
+ (name): is derived from the "PARAMETER INSTANCE" value.
+ (parameter#): C_* parameters from system.mhs. The C_ prefix is
+ dropped from the parameter name, the name is converted
+ to lowercase and all underscore '_' characters are
+ converted to dashes '-'.
+ (baseaddr): the C_BASEADDR parameter.
+ (HW_VER): from the HW_VER parameter.
+ (size): equals C_HIGHADDR - C_BASEADDR + 1
+
+ Typically, the compatible list will include the exact IP core version
+ followed by an older IP core version which implements the same
+ interface or any other device with the same interface.
+
+ 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
+
+ For example, the following block from system.mhs:
+
+ BEGIN opb_uartlite
+ PARAMETER INSTANCE = opb_uartlite_0
+ PARAMETER HW_VER = 1.00.b
+ PARAMETER C_BAUDRATE = 115200
+ PARAMETER C_DATA_BITS = 8
+ PARAMETER C_ODD_PARITY = 0
+ PARAMETER C_USE_PARITY = 0
+ PARAMETER C_CLK_FREQ = 50000000
+ PARAMETER C_BASEADDR = 0xEC100000
+ PARAMETER C_HIGHADDR = 0xEC10FFFF
+ BUS_INTERFACE SOPB = opb_7
+ PORT OPB_Clk = CLK_50MHz
+ PORT Interrupt = opb_uartlite_0_Interrupt
+ PORT RX = opb_uartlite_0_RX
+ PORT TX = opb_uartlite_0_TX
+ PORT OPB_Rst = sys_bus_reset_0
+ END
+
+ becomes the following device tree node:
+
+ opb-uartlite-0@ec100000 {
+ device_type = "serial";
+ compatible = "xilinx,opb-uartlite-1.00.b";
+ reg = <ec100000 10000>;
+ interrupt-parent = <&opb-intc>;
+ interrupts = <1 0>; // got this from the opb_intc parameters
+ current-speed = <d#115200>; // standard serial device prop
+ clock-frequency = <d#50000000>; // standard serial device prop
+ xilinx,data-bits = <8>;
+ xilinx,odd-parity = <0>;
+ xilinx,use-parity = <0>;
+ };
+
+ Some IP cores actually implement 2 or more logical devices. In this case,
+ the device should still describe the whole IP core with a single node
+ and add a child node for each logical device. The ranges property can
+ be used to translate from parent IP-core to the registers of each device.
+ (Note: this makes the assumption that both logical devices have the same
+ bus binding. If this is not true, then separate nodes should be used for
+ each logical device). The 'cell-index' property can be used to enumerate
+ logical devices within an IP core. For example, the following is the
+ system.mhs entry for the dual ps2 controller found on the ml403 reference
+ design.
+
+ BEGIN opb_ps2_dual_ref
+ PARAMETER INSTANCE = opb_ps2_dual_ref_0
+ PARAMETER HW_VER = 1.00.a
+ PARAMETER C_BASEADDR = 0xA9000000
+ PARAMETER C_HIGHADDR = 0xA9001FFF
+ BUS_INTERFACE SOPB = opb_v20_0
+ PORT Sys_Intr1 = ps2_1_intr
+ PORT Sys_Intr2 = ps2_2_intr
+ PORT Clkin1 = ps2_clk_rx_1
+ PORT Clkin2 = ps2_clk_rx_2
+ PORT Clkpd1 = ps2_clk_tx_1
+ PORT Clkpd2 = ps2_clk_tx_2
+ PORT Rx1 = ps2_d_rx_1
+ PORT Rx2 = ps2_d_rx_2
+ PORT Txpd1 = ps2_d_tx_1
+ PORT Txpd2 = ps2_d_tx_2
+ END
+
+ It would result in the following device tree nodes:
+
+ opb_ps2_dual_ref_0@a9000000 {
+ ranges = <0 a9000000 2000>;
+ // If this device had extra parameters, then they would
+ // go here.
+ ps2@0 {
+ compatible = "xilinx,opb-ps2-dual-ref-1.00.a";
+ reg = <0 40>;
+ interrupt-parent = <&opb-intc>;
+ interrupts = <3 0>;
+ cell-index = <0>;
+ };
+ ps2@1000 {
+ compatible = "xilinx,opb-ps2-dual-ref-1.00.a";
+ reg = <1000 40>;
+ interrupt-parent = <&opb-intc>;
+ interrupts = <3 0>;
+ cell-index = <0>;
+ };
+ };
+
+ Also, the system.mhs file defines bus attachments from the processor
+ to the devices. The device tree structure should reflect the bus
+ attachments. Again an example; this system.mhs fragment:
+
+ BEGIN ppc405_virtex4
+ PARAMETER INSTANCE = ppc405_0
+ PARAMETER HW_VER = 1.01.a
+ BUS_INTERFACE DPLB = plb_v34_0
+ BUS_INTERFACE IPLB = plb_v34_0
+ END
+
+ BEGIN opb_intc
+ PARAMETER INSTANCE = opb_intc_0
+ PARAMETER HW_VER = 1.00.c
+ PARAMETER C_BASEADDR = 0xD1000FC0
+ PARAMETER C_HIGHADDR = 0xD1000FDF
+ BUS_INTERFACE SOPB = opb_v20_0
+ END
+
+ BEGIN opb_uart16550
+ PARAMETER INSTANCE = opb_uart16550_0
+ PARAMETER HW_VER = 1.00.d
+ PARAMETER C_BASEADDR = 0xa0000000
+ PARAMETER C_HIGHADDR = 0xa0001FFF
+ BUS_INTERFACE SOPB = opb_v20_0
+ END
+
+ BEGIN plb_v34
+ PARAMETER INSTANCE = plb_v34_0
+ PARAMETER HW_VER = 1.02.a
+ END
+
+ BEGIN plb_bram_if_cntlr
+ PARAMETER INSTANCE = plb_bram_if_cntlr_0
+ PARAMETER HW_VER = 1.00.b
+ PARAMETER C_BASEADDR = 0xFFFF0000
+ PARAMETER C_HIGHADDR = 0xFFFFFFFF
+ BUS_INTERFACE SPLB = plb_v34_0
+ END
+
+ BEGIN plb2opb_bridge
+ PARAMETER INSTANCE = plb2opb_bridge_0
+ PARAMETER HW_VER = 1.01.a
+ PARAMETER C_RNG0_BASEADDR = 0x20000000
+ PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
+ PARAMETER C_RNG1_BASEADDR = 0x60000000
+ PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
+ PARAMETER C_RNG2_BASEADDR = 0x80000000
+ PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
+ PARAMETER C_RNG3_BASEADDR = 0xC0000000
+ PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
+ BUS_INTERFACE SPLB = plb_v34_0
+ BUS_INTERFACE MOPB = opb_v20_0
+ END
+
+ Gives this device tree (some properties removed for clarity):
+
+ plb-v34-0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "ibm,plb";
+ ranges; // 1:1 translation
+
+ plb-bram-if-cntrl-0@ffff0000 {
+ reg = <ffff0000 10000>;
+ }
+
+ opb-v20-0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <20000000 20000000 20000000
+ 60000000 60000000 20000000
+ 80000000 80000000 40000000
+ c0000000 c0000000 20000000>;
+
+ opb-uart16550-0@a0000000 {
+ reg = <a00000000 2000>;
+ };
+
+ opb-intc-0@d1000fc0 {
+ reg = <d1000fc0 20>;
+ };
+ };
+ };
+
+ That covers the general approach to binding xilinx IP cores into the
+ device tree. The following are bindings for specific devices:
+
+ i) Xilinx ML300 Framebuffer
+
+ Simple framebuffer device from the ML300 reference design (also on the
+ ML403 reference design as well as others).
+
+ Optional properties:
+ - resolution : <xres yres> pixel resolution of framebuffer. Some
+ implementations use a different resolution. Default
+ is <d#640 d#480>
+ - virt-resolution : <xvirt yvirt> Size of framebuffer in memory.
+ Default is <d#1024 d#480>.
+ - rotate-display (empty) : rotate display 180 degrees.
+
+ ii) Xilinx SystemACE
+
+ The Xilinx SystemACE device is used to program FPGAs from an FPGA
+ bitstream stored on a CF card. It can also be used as a generic CF
+ interface device.
+
+ Required properties:
+ - compatible : Should include "xilinx,sysace" in the list
+
+ Optional properties:
+ - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
+
+ iii) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. In addition to general xilinx properties
+ listed above, nodes for these devices should include a phy-handle
+ property, and may include other common network device properties
+ like local-mac-address.
+
+ iv) Xilinx Uartlite
+
+ Xilinx uartlite devices are simple fixed speed serial ports.
+
+ Requred properties:
+ - current-speed : Baud rate of uartlite
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
^ permalink raw reply related
* Re: [PATCH 1/2] qemu platform, v2
From: Milton Miller @ 2007-10-18 17:19 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras, Rob Landley, Christoph Hellwig
In-Reply-To: <47172E80.6090902@genesi-usa.com>
On Oct 18, 2007, at 4:59 AM, Matt Sealey wrote:
> Grant Likely wrote:
>> On 9/30/07, David Gibson <david@gibson.dropbear.id.au> wrote:
>>> On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote:
>>>
>>> I'm working on merging dtc into the kernel tree instead.
>> I'm kind of late to this party; but I have to say I disagree. Most of
>> us are doing just fine installing the dtc tool (and mkimage tool for
>> that matter). Cloning it in the kernel tree is just asking for
>> divergence.
>
> Which begs the question; why cloning?
>
> Why can't development be MOVED to in-kernel?
Because we don't put userspace testsuites there for one.
And its a stand alone tool and should have its own packaging for a
second (ie the kernel provides the kernel and modules, but not random
user space utilities, in its tarbal).
If we say only some boards or ports are special and need to build then
I would vote for shipping asm files. If we think we need to build any
random embedded platform without installing dtc then we should merge
dtc.
PS the proposed kbuild integration is wrong; it should build it in the
subdirectory.
milton
^ permalink raw reply
* Re: qe: add ability to upload QE firmware
From: Timur Tabi @ 2007-10-18 16:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <11927201051427-git-send-email-timur@freescale.com>
Timur Tabi wrote:
> Define the layout of a binary blob that contains a QE firmware and instructions
> on how to upload it. Add function qe_upload_microcode() to parse the blob
> and perform the actual upload. Fully define 'struct rsp' in immap_qe.h to
> include the actual RISC Special Registers.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
I need to add a few fields to the structure, but I would still appreciate
comments on the structure and the corresponding code.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH v6 2/9] ipic: add new interrupts introduced by new chip
From: Kumar Gala @ 2007-10-18 16:16 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, paulus
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5BD8@zch01exm26.fsl.freescale.net>
On Oct 18, 2007, at 10:29 AM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, October 18, 2007 10:57 PM
>> To: Li Yang-r58472
>> Cc: paulus@samba.org; linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH v6 2/9] ipic: add new interrupts
>> introduced by new chip
>>
>>
>> On Oct 18, 2007, at 10:04 AM, Li Yang wrote:
>>
>>> These interrupts are introduced by the latest Freescale SoC such as
>>> MPC837x. The patch also adds comment to interrupts.
>>>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/ipic.c | 224 +++++++++++++++++++++++++++++++++
>>> +----------
>>> arch/powerpc/sysdev/ipic.h | 7 +-
>>> include/asm-powerpc/ipic.h | 12 ++-
>>> 3 files changed, 186 insertions(+), 57 deletions(-)
>>
>> see comments:
>>
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044636.html
>
> But you didn't answer to my feedback
> http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044711.html
sorry missed this.
> If you are so persistent on thinking it's harmful rather than useful,
> please at least attempt to persuade me.
The MPC5121e users the IPIC and has different interrupt assignment.
I suggest that the UMs be updated to more useful not the code.
- 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