* Freescale RapidIO controller shortcomings, memory access and DMA support
From: Alex Dubov @ 2010-01-20 14:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: zw
Greetings.=0A=0AI'm currently involved in a project which aims to use a Rap=
idIO fabric as,=0Aessentially, a cluster interconnect. That is, our system =
contains a=0Amultitude of processing elements, rather than a host + some du=
mb=0Aperipherals.=0A=0AUnfortunately, it appears that Freescale's rapidio c=
ontroller is not well=0Asuited for this kind of use and the situation doesn=
't seem to get any=0Abetter in new chips. Just for the sake of general rant=
, I shall mention=0Athe missing functionality:=0A=0A1. Support for sending/=
receiving raw RIO packets - could be used to emulate=0Aall the necessary fe=
atures in software, if it was available.=0A=0A2. Support for indirect descr=
iptors in inbound message queue, akin to the=0Aone in outbound. It will all=
ow not to waste tons of space in the incoming=0Amessage buffer, and, even m=
ore important, will allow for Source ID based=0Amessage dispatch. Frankly, =
I don't understand what RIO core designers were=0Athinking - piling of prot=
ocol layers on top of RIO messages is not a good=0Aidea (and piling the who=
le Ethernet + friends protocol stack over there is=0Aeven worse).=0A=0A3. P=
roper IO TLB would be nice, but even without it there are accepted ways=0At=
o manage DMA from peripherals without reverting to overly complex hw=0Asche=
mes. After all, it won't be a big deal for a controller to support=0Aout-of=
-memory interrupt event, which would allow managing of DMA transfers=0Ain c=
oncurrent fashion, leading to a true zero-copy IO.=0A=0A4. Related to the p=
revious point, there's no control, nor indication about=0Awhich message siz=
es are actually used for outbound window originated=0Atransactions. Sending=
16 bytes of actual phy data for each 4 processor=0Abytes can be a little b=
it wasteful (I hope, that there's some buffering=0Agoing on, but absence of=
control is depressing).=0A=0A--- end of the rant ---=0A=0AI understand, th=
at Zhang Wei and Li Yang did some work in the direction=0Aof memory mapped =
RIO access. Therefore, I wonder: what is the final fate=0Aof their submissi=
on? Is there some sort of summary, what functionality=0Ahad been added and =
how was it envisaged to be used from user space?=0A=0AI'm currently working=
on a fork of rapidio subsystem, which I intend to=0Abring to a feature com=
pleteness as far as possible (given the shortcoming=0Aabove) and use it as =
a cluster interconnect. I don't want to step on other=0Apeople's rakes and =
I would like a good cluster functionality support=0Amerged eventually into =
the mainline kernel, so any feedback is very=0Amuch appreciated.=0A=0A=0A=
=0A __________________________________________________________________=
________________=0ASee what's on at the movies in your area. Find out now: =
http://au.movies.yahoo.com/session-times/
^ permalink raw reply
* [PATCH] powerpc/4xx: Add pcix type 1 transactions
From: Stef van Os @ 2010-01-20 13:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stef van Os, felix, fkan, Stef van Os, sr
U29tZSBvZiB0aGUgbmV3ZXIgNHh4IHBjaSBjb3JlcyBkb24ndCBzZW5kIFBDSSB0eXBlIDEgdHJh
bnNhY3Rpb25zLg0KVGhpcyBwYXRjaCBlbmFibGVzIHR5cGUgMSB0cmFuc2F0aW9ucyBmb3IgcGNp
eCBub2RlcywgdGh1cyBlbmFibGluZw0KZGV2aWNlcyBiZWhpbmQgUENJIGJyaWRnZXMuDQoNClNp
Z25lZC1vZmYtYnk6IFN0ZWYgdmFuIE9zIDxzdGVmLnZhbi5vc0BnbWFpbC5jb20+DQotLS0NCiBh
cmNoL3Bvd2VycGMvc3lzZGV2L3BwYzR4eF9wY2kuYyB8ICAgIDMgKystDQogMSBmaWxlcyBjaGFu
Z2VkLCAyIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9hcmNo
L3Bvd2VycGMvc3lzZGV2L3BwYzR4eF9wY2kuYyBiL2FyY2gvcG93ZXJwYy9zeXNkZXYvcHBjNHh4
X3BjaS5jDQppbmRleCA2ZmY5ZDcxLi44YWEzMzAyIDEwMDY0NA0KLS0tIGEvYXJjaC9wb3dlcnBj
L3N5c2Rldi9wcGM0eHhfcGNpLmMNCisrKyBiL2FyY2gvcG93ZXJwYy9zeXNkZXYvcHBjNHh4X3Bj
aS5jDQpAQCAtNTY5LDcgKzU2OSw4IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcGM0eHhfcHJvYmVf
cGNpeF9icmlkZ2Uoc3RydWN0IGRldmljZV9ub2RlICpucCkNCiAJaG9zZS0+bGFzdF9idXNubyA9
IGJ1c19yYW5nZSA/IGJ1c19yYW5nZVsxXSA6IDB4ZmY7DQogDQogCS8qIFNldHVwIGNvbmZpZyBz
cGFjZSAqLw0KLQlzZXR1cF9pbmRpcmVjdF9wY2koaG9zZSwgcnNyY19jZmcuc3RhcnQsIHJzcmNf
Y2ZnLnN0YXJ0ICsgMHg0LCAwKTsNCisJc2V0dXBfaW5kaXJlY3RfcGNpKGhvc2UsIHJzcmNfY2Zn
LnN0YXJ0LCByc3JjX2NmZy5zdGFydCArIDB4NCwNCisJCQkJCVBQQ19JTkRJUkVDVF9UWVBFX1NF
VF9DRkdfVFlQRSk7DQogDQogCS8qIERpc2FibGUgYWxsIHdpbmRvd3MgKi8NCiAJd3JpdGVsKDAs
IHJlZyArIFBDSVgwX1BPTTBTQSk7DQotLSANCjEuNi42LjI2Ny5nNWIxNTkNCg0KDQpEaXNjbGFp
bWVyOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZW1haWwsIGluY2x1ZGluZyBh
bnkgYXR0YWNobWVudHMgaXMgDQpjb25maWRlbnRpYWwgYW5kIGlzIGZvciB0aGUgc29sZSB1c2Ug
b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHVuYXV0aG9yaXplZCANCnJldmlldywg
dXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJl
IG5vdCB0aGUgaW50ZW5kZWQgDQpyZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp
bW1lZGlhdGVseSBieSByZXBseWluZyB0byB0aGlzIG1lc3NhZ2UgYW5kIA0KZGVzdHJveSBhbGwg
Y29waWVzIG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzLg==
^ permalink raw reply
* Re: linux-next: kvm tree build warning
From: Stephen Rothwell @ 2010-01-20 13:01 UTC (permalink / raw)
To: Alexander Graf
Cc: Marcelo Tosatti, ppc-dev, linux-next, Avi Kivity, linux-kernel
In-Reply-To: <3727B46C-0197-47A4-AF41-023517C15752@suse.de>
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
Hi Alex,
On Wed, 20 Jan 2010 11:42:28 +0100 Alexander Graf <agraf@suse.de> wrote:
>
> This is odd. The same function saves and restores ext_bkp.vrsave under a common condition:
>
> So there can't be a case where ext_bkp.vrsave is read, but not written to before, which is what this warning implies, right?
Right.
> Also, why doesn't gcc complain about vscr too then? They're both used in the very same if statement.
I have no idea how gcc makes these decisions. :-(
> Additionally, while compiling locally I looked for warnings and didn't spot any. So apparently our compiler versions / options don't match. Which version of gcc are you using? I assume a gcc bug.
>
> $ gcc --version
> gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
I use a 4.4.0 cross compiler (I should update it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Marco Stornelli @ 2010-01-20 11:54 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
Johnny Hung, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100120102145.GV16182@darwin>
2010/1/20 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Wed, Jan 20, 2010 at 08:57:44AM +0100 Marco Stornelli ha dit:
>
>> 2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
>> > 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
>> >> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>> >>
>> > I consider to use ramdisk as rootfs because worry about wrong
>> > operation in rootfs (is use jffs2 rootfs) and it will cause system
>> > boot up failed.
>> > Another query, does the syslogd/klogd log files also store in jffs2
>> > rootfs? Write to jffs2 frequently will reduce flash life cycle.
>> >
>> > BRs, H. Johnny
>> >>
>> >> --
>>
>> In general a good splitting for rootfs could be: squashfs for rootfs,
>> tmpfs for volatile data (/tmp), ubifs (with a flash partition) for
>> "strong" permanent data (/etc, ....) and pramfs for "light" permanent
>> data (/var/log, .....).
>
> if ubifs is a good choice depends on the size of the partition, iirc
> it has a significant overhead for very small partitions.
>
> once using ubi it could be interesting to set up the read-only rootfs
> partition upon ubi in order to spread the wear out over a maximum of blocks.
>
I don't know the size constraints of Johnny, so it can be useful to use jffs2.
Marco
^ permalink raw reply
* Re: [PATCH 03/11] powerpc/mpc5121: Add machine restart support
From: Wolfram Sang @ 2010-01-20 11:28 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, wd, dzu, Piotr Ziecik
In-Reply-To: <1263932653-3634-4-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 4776 bytes --]
On Tue, Jan 19, 2010 at 09:24:05PM +0100, Anatolij Gustschin wrote:
> Add reset module registers representation and
> machine restart callback for mpc5121 platform.
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
Looks good to me. Minor nits below.
> ---
> arch/powerpc/include/asm/mpc5xxx.h | 14 +++++++++-
> arch/powerpc/platforms/512x/mpc5121_ads.c | 1 +
> arch/powerpc/platforms/512x/mpc5121_generic.c | 1 +
> arch/powerpc/platforms/512x/mpc512x.h | 1 +
> arch/powerpc/platforms/512x/mpc512x_shared.c | 35 +++++++++++++++++++++++++
> 5 files changed, 51 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc5xxx.h b/arch/powerpc/include/asm/mpc5xxx.h
> index 5ce9c5f..0004986 100644
> --- a/arch/powerpc/include/asm/mpc5xxx.h
> +++ b/arch/powerpc/include/asm/mpc5xxx.h
> @@ -18,5 +18,17 @@
>
> extern unsigned long mpc5xxx_get_bus_frequency(struct device_node *node);
>
> -#endif /* __ASM_POWERPC_MPC5xxx_H__ */
> +/* MPC512x Reset module registers */
> +struct mpc512x_reset_module {
> + u32 rcwlr; /* Reset Configuration Word Low Register */
> + u32 rcwhr; /* Reset Configuration Word High Register */
> + u32 reserved1;
> + u32 reserved2;
> + u32 rsr; /* Reset Status Register */
> + u32 rmr; /* Reset Mode Register */
> + u32 rpr; /* Reset Protection Register */
> + u32 rcr; /* Reset Control Register */
> + u32 rcer; /* Reset Control Enable Register */
> +};
>
> +#endif /* __ASM_POWERPC_MPC5xxx_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c b/arch/powerpc/platforms/512x/mpc5121_ads.c
> index 441abc4..2f40404 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_ads.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
> @@ -68,4 +68,5 @@ define_machine(mpc5121_ads) {
> .init_IRQ = mpc5121_ads_init_IRQ,
> .get_irq = ipic_get_irq,
> .calibrate_decr = generic_calibrate_decr,
> + .restart = mpc512x_restart,
> };
> diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c b/arch/powerpc/platforms/512x/mpc5121_generic.c
> index 2479de9..de4c3f7 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_generic.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
> @@ -55,4 +55,5 @@ define_machine(mpc5121_generic) {
> .init_IRQ = mpc512x_init_IRQ,
> .get_irq = ipic_get_irq,
> .calibrate_decr = generic_calibrate_decr,
> + .restart = mpc512x_restart,
> };
> diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
> index 22a5352..c38875c 100644
> --- a/arch/powerpc/platforms/512x/mpc512x.h
> +++ b/arch/powerpc/platforms/512x/mpc512x.h
> @@ -12,5 +12,6 @@
> #ifndef __MPC512X_H__
> #define __MPC512X_H__
> extern void __init mpc512x_init_IRQ(void);
> +extern void mpc512x_restart(char *cmd);
> void __init mpc512x_declare_of_platform_devices(void);
> #endif /* __MPC512X_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
> index 434d683..8a0d577 100644
> --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> @@ -21,9 +21,44 @@
> #include <asm/ipic.h>
> #include <asm/prom.h>
> #include <asm/time.h>
> +#include <asm/mpc5xxx.h>
>
> #include "mpc512x.h"
>
> +static void __iomem *reset_module_base;
type here also?
> +
> +static int __init mpc512x_restart_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-reset");
> + if (!np)
> + return -1;
> +
> + reset_module_base = of_iomap(np, 0);
> + of_node_put(np);
> +
> + return 0;
> +}
> +
Drop this empty line?
> +arch_initcall(mpc512x_restart_init);
> +
> +void mpc512x_restart(char *cmd)
> +{
> + struct mpc512x_reset_module *rm = reset_module_base;
> +
> + if (rm) {
> + /* Enable software reset "RSTE" */
> + out_be32(&rm->rpr, 0x52535445);
> + /* Set software hard reset */
> + out_be32(&rm->rcr, 0x2);
> + } else {
> + printk(KERN_ERR ": Restart module not mapped.\n");
The colon is a leftover?
> + }
> + for (;;)
> + ;
> +}
> +
> void __init mpc512x_init_IRQ(void)
> {
> struct device_node *np;
> --
> 1.5.6.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/11] Update support for MPC512x
From: Wolfram Sang @ 2010-01-20 11:22 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: wd, dzu, netdev, linux-usb, linuxppc-dev, linux-mtd, linux-i2c,
rtc-linux, Dan Williams
In-Reply-To: <1263932653-3634-1-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
> The patches are based on v2.6.33-rc4 and cover the following
> items:
The USB-patch needs two patches from linux-next. For convenience, don't you
have a git-tree somewhere? :)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Felix Radensky @ 2010-01-20 11:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <1263941873.724.524.camel@pasglop>
Hi, Stef
Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-20 at 00:52 +0200, Felix Radensky wrote:
>
>> 405XX - no
>> 440EP - no
>> 440GR - no
>> 440EPx/440GRx - no
>>
>> 440GP - yes
>> 440GX - yes
>> 440SP - yes
>> 440SPe - yes
>> 460XX - yes
>>
>> The distinction between these groups is pretty clear in the device trees.
>> The members of the first group all have "ibm,plb-pci" property, and all
>> members of second group have "ibm,plb-pcix" property.
>>
>> So only ppc4xx_probe_pcix_bridge() routine should be fixed.
>>
>
> Ah cool, I hadn't noticed that it matched the cell type.
>
>
Can you please send an updated patch.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: [PATCH 01/11] fs_enet: Add support for MPC512x to fs_enet driver
From: Anatolij Gustschin @ 2010-01-20 11:20 UTC (permalink / raw)
To: Scott Wood; +Cc: Piotr Ziecik, dzu, netdev, linuxppc-dev, John Rigby, wd
In-Reply-To: <4B561AA3.7040506@freescale.com>
Scott Wood <scottwood@freescale.com> wrote:
> > + void __iomem *fec_fun_code;
> > + void __iomem *fec_r_hash;
> > + void __iomem *fec_x_cntrl;
> > + void __iomem *fec_dma_control;
> > +};
>
> Why void and not the specific type?
Ok, I will fix it for using u32 __iomem *.
> > static void set_promiscuous_mode(struct net_device *dev)
> > {
> > struct fs_enet_private *fep = netdev_priv(dev);
> > - fec_t __iomem *fecp = fep->fec.fecp;
> > + struct reg_tbl *fecp = fep->fec.rtbl;
>
> Hmm, having something called "fecp" that is a different type than other
> "fecp"s could be confusing.
Ok, I will use 'regp' instead of 'fecp' then.
> > @@ -134,6 +143,20 @@ static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
> > if (!fec->fecp)
> > goto out_fec;
> >
> > + if (of_device_is_compatible(ofdev->node, "fsl,mpc5121-fec-mdio")) {
>
> You can put a data pointer in the of_platform match struct, instead of
> re-checking the compatible.
.data pointer in 'fs_enet_mdio_fec_match' is already used for
mpc5xxx_get_bus_frequency(). Setting .data to some sort of FEC ID in
match struct for "fsl,pq1-fec-mdio" would be confusing to.
Would a simple
if (!strncmp(match->compatible, "fsl,mpc5121-fec-mdio",
sizeof(match->compatible))) {
suffice here?
Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH 05/11] rtc: Add MPC5121 Real time clock driver
From: Wolfram Sang @ 2010-01-20 11:01 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Piotr Ziecik, dzu, rtc-linux, linuxppc-dev, John Rigby, wd
In-Reply-To: <1263932653-3634-6-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
On Tue, Jan 19, 2010 at 09:24:07PM +0100, Anatolij Gustschin wrote:
> From: John Rigby <jrigby@freescale.com>
>
> Based on Domen Puncer's rtc driver for 5200 posted to
> the ppclinux mailing list:
> http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11675
> but never commited anywhere.
>
> Changes to Domen's original:
>
> Changed filenames/routine names from mpc5200* to mpc5121*
> Changed match to only care about compatible and use "fsl,"
> convention for compatible.
>
> Make alarms more sane by dealing with lack of second alarm resolution.
>
> Deal with the fact that most of the 5121 rtc registers are not persistent
> across a reset even with a battery attached:
>
> Use actual_time register for time keeping
> and target_time register as an offset to linux time
>
> The target_time register would normally be used for hibernation
> but hibernation does not work on current silicon
Last time, we discussed if it makes sense to rename it to mpc5xxx, as the rtc
is quite similar to the mpc5200 one. I then checked and parts of the
differences include that it is not possible on a 5200 to use the tricks to keep
the RTC persistent across resets. Thus, I think the patch is okay with not
supporting the 5200. Its rtc seems pretty useless.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 06/11] mtd: Add MPC5121 NAND Flash Controller driver
From: Wolfram Sang @ 2010-01-20 10:49 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, linux-mtd, wd, dzu, Piotr Ziecik
In-Reply-To: <1263932653-3634-7-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Tue, Jan 19, 2010 at 09:24:08PM +0100, Anatolij Gustschin wrote:
> From: Piotr Ziecik <kosmo@semihalf.com>
>
> Adds NAND Flash Controller driver for MPC5121 Revision 2.
> All device features, except hardware ECC and power management,
> are supported.
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: <linux-mtd@lists.infradead.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
Please include a logfile with changes since the last version. This really
helps.
> +static int __init mpc5121_nfc_probe(struct of_device *op,
> + const struct of_device_id *match)
[...]
> +{
> + /* Support external chip-select logic on ADS5121 board */
> + rootnode = of_find_node_by_path("/");
> + if (of_device_is_compatible(rootnode, "fsl,mpc5121ads")) {
> + retval = ads5121_chipselect_init(mtd);
> + if (retval) {
> + dev_err(dev, "Chipselect init error!\n");
> + of_node_put(rootnode);
> + return retval;
> + }
> +
> + chip->select_chip = ads5121_select_chip;
> + }
> + of_node_put(rootnode);
If we have to live with the platform-stuff being in the driver, maybe a table
having the compatible-string and an init-function pointer per entry will make
it scale better with the number of boards?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: kvm tree build warning
From: Alexander Graf @ 2010-01-20 10:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Marcelo Tosatti, ppc-dev, linux-next, Avi Kivity, linux-kernel
In-Reply-To: <20100120174814.43195995.sfr@canb.auug.org.au>
On 20.01.2010, at 07:48, Stephen Rothwell wrote:
> [Not sure what happened to the previous versions To/CC lists, sorry]
>=20
> Hi all,
>=20
> Today's linux-next build (powerpc allyesconfig) produced this warning:
>=20
> arch/powerpc/kvm/book3s.c: In function '__kvmppc_vcpu_run':
> arch/powerpc/kvm/book3s.c:1102: warning: 'ext_bkp.vrsave' may be used =
uninitialized in this function
>=20
> Introduced by commit 2609c1d06b6a7952273fb33b33ad32aff0628146 ("KVM: =
PPC:
> Add support for FPU/Altivec/VSX"). This *may* be a false positive but
> will be a problem for normal builds where warnings are treated as =
errors
> in arch/powerpc.
This is odd. The same function saves and restores ext_bkp.vrsave under a =
common condition:
if (save_vec) {
if (current->thread.regs->msr & MSR_VEC)
giveup_altivec(current);
memcpy(ext_bkp.vr, current->thread.vr, =
sizeof(ext_bkp.vr));
ext_bkp.vscr =3D current->thread.vscr;
ext_bkp.vrsave =3D current->thread.vrsave;
}
[...]
if (save_vec && current->thread.used_vr) {
memcpy(current->thread.vr, ext_bkp.vr, =
sizeof(ext_bkp.vr));
current->thread.vscr =3D ext_bkp.vscr;
current->thread.vrsave =3D ext_bkp.vrsave;
}
So there can't be a case where ext_bkp.vrsave is read, but not written =
to before, which is what this warning implies, right?
Also, why doesn't gcc complain about vscr too then? They're both used in =
the very same if statement.
Additionally, while compiling locally I looked for warnings and didn't =
spot any. So apparently our compiler versions / options don't match. =
Which version of gcc are you using? I assume a gcc bug.
$ gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Alex=
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-20 10:21 UTC (permalink / raw)
To: Marco Stornelli
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
Johnny Hung, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2ea1731b1001192357r72d627e2gb36d71f23fd69b2e@mail.gmail.com>
El Wed, Jan 20, 2010 at 08:57:44AM +0100 Marco Stornelli ha dit:
> 2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
> > 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> >> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> >>
> > I consider to use ramdisk as rootfs because worry about wrong
> > operation in rootfs (is use jffs2 rootfs) and it will cause system
> > boot up failed.
> > Another query, does the syslogd/klogd log files also store in jffs2
> > rootfs? Write to jffs2 frequently will reduce flash life cycle.
> >
> > BRs, H. Johnny
> >>
> >> --
>
> In general a good splitting for rootfs could be: squashfs for rootfs,
> tmpfs for volatile data (/tmp), ubifs (with a flash partition) for
> "strong" permanent data (/etc, ....) and pramfs for "light" permanent
> data (/var/log, .....).
if ubifs is a good choice depends on the size of the partition, iirc
it has a significant overhead for very small partitions.
once using ubi it could be interesting to set up the read-only rootfs
partition upon ubi in order to spread the wear out over a maximum of blocks.
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
You can chain me, you can torture me, you can even
destroy this body, but you will never imprison my mind
(Mahatma Gandhi)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: [PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
From: Wolfram Sang @ 2010-01-20 10:22 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Piotr Ziecik, dzu, netdev, linuxppc-dev, John Rigby, wd
In-Reply-To: <1263932653-3634-3-git-send-email-agust@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index 909b78d..a391219 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -587,6 +587,33 @@ void fs_cleanup_bds(struct net_device *dev)
>
> /**********************************************************************************/
>
> +static struct sk_buff *tx_skb_align_workaround(struct net_device *dev,
> + struct sk_buff *skb)
> +{
> + struct sk_buff *new_skb;
> +
> + /* Alloc new skb */
> + new_skb = dev_alloc_skb(ENET_RX_FRSIZE + 32);
> + if (!new_skb) {
> + printk(KERN_WARNING DRV_MODULE_NAME
> + ": %s Memory squeeze, dropping tx packet.\n",
> + dev->name);
I understand this type of printk fits to the rest of the code, I just wonder if
new (and patched) printouts shouldn't be converted to dev_*? Might be one line
then, and more consistent to what other drivers produce.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Marco Stornelli @ 2010-01-20 7:57 UTC (permalink / raw)
To: Johnny Hung
Cc: Ricard Wanderlof, linux-embedded@vger.kernel.org, kernelnewbies,
linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cb9ecdfa1001191832k28961740qa825a8c8d5e631f2@mail.gmail.com>
2010/1/20 Johnny Hung <johnny.hacking@gmail.com>:
> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
>> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>>
> I consider to use ramdisk as rootfs because worry about wrong
> operation in rootfs (is use jffs2 rootfs) and it will cause system
> boot up failed.
> Another query, does the syslogd/klogd log files also store in jffs2
> rootfs? Write to jffs2 frequently will reduce flash life cycle.
>
> BRs, H. Johnny
>>
>> --
In general a good splitting for rootfs could be: squashfs for rootfs,
tmpfs for volatile data (/tmp), ubifs (with a flash partition) for
"strong" permanent data (/etc, ....) and pramfs for "light" permanent
data (/var/log, .....).
I think you should "split" your rootfs. Ramdisk is an old approach
with some drawbacks.
Marco
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-20 7:17 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Johnny Hung, kernelnewbies, linux-mtd@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <Pine.LNX.4.64.1001200809550.32263@lnxricardw.se.axis.com>
El Wed, Jan 20, 2010 at 08:15:01AM +0100 Ricard Wanderlof ha dit:
> On Wed, 20 Jan 2010, Johnny Hung wrote:
>
>>> i'd also recommend you to consider if you really need the
>>> ramdisk. when using a ram disk its entire content is loaded to the RAM
>>> occupying space, even if you don't use certain files (or part of
>>> them). other filesystems are more efficient in this aspect.
>>> if the main purpose is to have a read only rootfs, i'd suggest a look
>>> at squashfs.
>>
>> I consider to use ramdisk as rootfs because worry about wrong
>> operation in rootfs (is use jffs2 rootfs) and it will cause system
>> boot up failed.
>
> You have a point, however, you could do two things to help:
>
> a) Mount the root file system as read-only. That way you can never write
> to it, unless you remount it read-write. But you can still reflash that
> partition if you need to upgrade.
>
> b) Register the mtd partition holding the root file system as read-only.
> This is even more seecure as remounting the file system won't permit
> writes. However, it also means you can't write to it for upgrading. (I
> don't think the mtd core permits changing an already registered mtd
> partition from readonly to writable, but I could be wrong.)
AFAIK the mtd core doesn't permit changing a partition from ro to
rw. but if you happen to need to reflash the partition anyway, you can
load a tiny kernel modules that changes the flag indicating if a
partition is writable.
i once had to recurr to this solution and it works ;)
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
Tant qu'il y aura sur terre des hommes pour qui existe un concept
d' 'honneur national', la menace d'une nouvelle guerre subsistera
(B. Traven)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Matthias Kaehlcke @ 2010-01-20 7:12 UTC (permalink / raw)
To: Johnny Hung
Cc: kernelnewbies, linux-mtd@lists.infradead.org, Ricard Wanderlof,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <cb9ecdfa1001191832k28961740qa825a8c8d5e631f2@mail.gmail.com>
El Wed, Jan 20, 2010 at 10:32:15AM +0800 Johnny Hung ha dit:
> 2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> > El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
> >
> >> On Tue, 19 Jan 2010, Johnny Hung wrote:
> >>
> >>> Okay, I think the steps is below if my rootfs is ramdisk and configure
> >>> files in jffs2,
> >>>
> >>> 1. cp /etc/* /mnt/mtd/etc/ (/mnt/mtd is my jffs2 fs)
> >>> 2. rm -rf /etc/*
> >>> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
> >>> 4. remake ramdisk rootfs
> >>>
> >>> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
> >>> and try to modify these files is effective after reboot.
> >>> But is this a common way in embedded linux ?
> >>
>
> Thanks, I understand.
>
> >> In principle, but it is easier (and cleaner) to make a symbolic link from
> >> (say) /etc -> /mnt/mtd/etc without linking every individual file and
> >> directory.
> >
> > i totally agree with ricard when you want to move the entire directory
> > to jffs2 and not only some selected files
> >
> >> You could also use a jffs2 file system in flash for your rootfs, that way
> >> you wouldn't need a ramdisk at all.
> >
> > i'd also recommend you to consider if you really need the
> > ramdisk. when using a ram disk its entire content is loaded to the RAM
> > occupying space, even if you don't use certain files (or part of
> > them). other filesystems are more efficient in this aspect.
> > if the main purpose is to have a read only rootfs, i'd suggest a look
> > at squashfs.
>
> I consider to use ramdisk as rootfs because worry about wrong
> operation in rootfs (is use jffs2 rootfs) and it will cause system
> boot up failed.
you could set up a rootfs partition with a read-only file system
(squashfs, jffs2 mounted ro) and a second partition that's writable.
> Another query, does the syslogd/klogd log files also store in jffs2
> rootfs? Write to jffs2 frequently will reduce flash life cycle.
by default the log files will be written to /var/log, if this
directory happens to be on a jffs2 partition writes will go there and
produce wear out. to avoid this you could set up a small tmpfs (in
RAM) and mount it on /var
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
We can't solve problems by using the same kind
of thinking we used when we created them
(Albert Einstein)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Ricard Wanderlof @ 2010-01-20 7:15 UTC (permalink / raw)
To: Johnny Hung
Cc: Ricard Wanderlöf, linux-embedded@vger.kernel.org,
kernelnewbies, linux-mtd@lists.infradead.org, Matthias Kaehlcke,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cb9ecdfa1001191832k28961740qa825a8c8d5e631f2@mail.gmail.com>
On Wed, 20 Jan 2010, Johnny Hung wrote:
>> i'd also recommend you to consider if you really need the
>> ramdisk. when using a ram disk its entire content is loaded to the RAM
>> occupying space, even if you don't use certain files (or part of
>> them). other filesystems are more efficient in this aspect.
>> if the main purpose is to have a read only rootfs, i'd suggest a look
>> at squashfs.
>
> I consider to use ramdisk as rootfs because worry about wrong
> operation in rootfs (is use jffs2 rootfs) and it will cause system
> boot up failed.
You have a point, however, you could do two things to help:
a) Mount the root file system as read-only. That way you can never write=20
to it, unless you remount it read-write. But you can still reflash that=20
partition if you need to upgrade.
b) Register the mtd partition holding the root file system as read-only.
This is even more seecure as remounting the file system won't permit=20
writes. However, it also means you can't write to it for upgrading. (I
don't think the mtd core permits changing an already registered mtd=20
partition from readonly to writable, but I could be wrong.)
> Another query, does the syslogd/klogd log files also store in jffs2
> rootfs? Write to jffs2 frequently will reduce flash life cycle.
I think it is fairly common to have a combination of devices:
/ (root) is a readonly flash device (mtd partition)
/etc is a writable flash device (mtd partition)
/tmp and /var are ramdisks (tmpfs), so they are writable, but lost when
power is cycled.
/Ricard
--=20
Ricard Wolf Wanderl=F6f ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
^ permalink raw reply
* linux-next: kvm tree build warning
From: Stephen Rothwell @ 2010-01-20 6:48 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: linux-next, ppc-dev, linux-kernel, Alexander Graf
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
[Not sure what happened to the previous versions To/CC lists, sorry]
Hi all,
Today's linux-next build (powerpc allyesconfig) produced this warning:
arch/powerpc/kvm/book3s.c: In function '__kvmppc_vcpu_run':
arch/powerpc/kvm/book3s.c:1102: warning: 'ext_bkp.vrsave' may be used uninitialized in this function
Introduced by commit 2609c1d06b6a7952273fb33b33ad32aff0628146 ("KVM: PPC:
Add support for FPU/Altivec/VSX"). This *may* be a false positive but
will be a problem for normal builds where warnings are treated as errors
in arch/powerpc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
From: David Miller @ 2010-01-20 4:04 UTC (permalink / raw)
To: sfr; +Cc: kosmo, jrigby, netdev, linuxppc-dev, agust, dzu, wd
In-Reply-To: <20100120104225.3361e6c4.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 20 Jan 2010 10:42:25 +1100
> On Tue, 19 Jan 2010 12:37:06 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>>
>> Well... where are the other 9 patches?
>
> I think the other 9 are not network related, just PowerPC related.
Ok, but that's very confusing.
If it's meant to go into two different trees split the
patches up into two different series.
^ permalink raw reply
* Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
From: Johnny Hung @ 2010-01-20 2:32 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: kernelnewbies, linux-mtd@lists.infradead.org, Ricard Wanderlof,
linuxppc-dev@lists.ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <20100119140600.GH16182@darwin>
2010/1/19 Matthias Kaehlcke <matthias@kaehlcke.net>:
> El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit:
>
>> On Tue, 19 Jan 2010, Johnny Hung wrote:
>>
>>> Okay, I think the steps is below if my rootfs is ramdisk and configure
>>> files in jffs2,
>>>
>>> 1. cp /etc/* /mnt/mtd/etc/ =A0 =A0(/mnt/mtd is my jffs2 fs)
>>> 2. rm -rf /etc/*
>>> 3. make symbolic links from all /etc/xx to /mnt/mtd/etc/xxx
>>> 4. remake ramdisk rootfs
>>>
>>> It seems all files in ramdisk rootfs /etc all links to /mnt/mtd/etc/
>>> and try to modify these files is effective after reboot.
>>> But is this a common way in embedded linux ?
>>
Thanks, I understand.
>> In principle, but it is easier (and cleaner) to make a symbolic link fro=
m
>> (say) /etc -> /mnt/mtd/etc without linking every individual file and
>> directory.
>
> i totally agree with ricard when you want to move the entire directory
> to jffs2 and not only some selected files
>
>> You could also use a jffs2 file system in flash for your rootfs, that wa=
y
>> you wouldn't need a ramdisk at all.
>
> i'd also recommend you to consider if you really need the
> ramdisk. when using a ram disk its entire content is loaded to the RAM
> occupying space, even if you don't use certain files (or part of
> them). other filesystems are more efficient in this aspect.
> if the main purpose is to have a read only rootfs, i'd suggest a look
> at squashfs.
I consider to use ramdisk as rootfs because worry about wrong
operation in rootfs (is use jffs2 rootfs) and it will cause system
boot up failed.
Another query, does the syslogd/klogd log files also store in jffs2
rootfs? Write to jffs2 frequently will reduce flash life cycle.
BRs, H. Johnny
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0La posibilidad de realizar un suenyo es lo
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 que hace que la vida sea interesante
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .''`.
> =A0 =A0using free software / Debian GNU/Linux | http://debian.org =A0: :'=
=A0:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0`. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0`-
>
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Alex Dubov @ 2010-01-20 1:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <DC402F23-C6B5-4F7E-B66D-F0AFCC298CEA@kernel.crashing.org>
> =0A> > So, the obvious question is, what is the current=0A> status of lar=
ge physical=0A> > address support on e500? Is it a problem in current=0A> g=
it version or is it=0A> > not ready yet?=0A> > =0A> > Thanks.=0A> =0A> Its =
possible that we've broken module/vmalloc support with=0A> "Large physical =
addressing".=A0 Its not something I've=0A> tried in a while.=A0 What kernel=
/git SHA are you using.=0A> =0A=0AI'm just pulling in from the main kernel =
tree git.=0AMy current version is 2.6.33-rc4-00193-gd1e4922-dirty,=0Abut it=
had not changed since 2.6.33-rc2=0A=0AI started from 2.6.32, but I don't r=
emember if I had a large PA=0Asupport enabled there.=0A=0A=0A=0A=0A __=
___________________________________________________________________________=
_____=0ASee what's on at the movies in your area. Find out now: http://au.m=
ovies.yahoo.com/session-times/
^ permalink raw reply
* Re: [PATCH 02/11] fs_enet: Add FEC TX Alignment workaround for MPC5121
From: Stephen Rothwell @ 2010-01-19 23:42 UTC (permalink / raw)
To: David Miller; +Cc: kosmo, jrigby, netdev, linuxppc-dev, agust, dzu, wd
In-Reply-To: <20100119.123706.12493208.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 320 bytes --]
Hi Dave,
On Tue, 19 Jan 2010 12:37:06 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Well... where are the other 9 patches?
I think the other 9 are not network related, just PowerPC related.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Benjamin Herrenschmidt @ 2010-01-19 22:57 UTC (permalink / raw)
To: Felix Radensky; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <4B5637A6.5070600@embedded-sol.com>
On Wed, 2010-01-20 at 00:52 +0200, Felix Radensky wrote:
>
> 405XX - no
> 440EP - no
> 440GR - no
> 440EPx/440GRx - no
>
> 440GP - yes
> 440GX - yes
> 440SP - yes
> 440SPe - yes
> 460XX - yes
>
> The distinction between these groups is pretty clear in the device trees.
> The members of the first group all have "ibm,plb-pci" property, and all
> members of second group have "ibm,plb-pcix" property.
>
> So only ppc4xx_probe_pcix_bridge() routine should be fixed.
Ah cool, I hadn't noticed that it matched the cell type.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Felix Radensky @ 2010-01-19 22:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <1263444961.724.343.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-13 at 10:18 +1100, Benjamin Herrenschmidt wrote:
>
>> On Tue, 2010-01-12 at 15:09 +0100, Stef van Os wrote:
>>
>>> This patch adds type 1 PCI transactions to 4xx PCI code, enabling the
>>> discovery of
>>> devices behind a PCI bridge.
>>>
>> Your patch appears word wrapped and whitespace damaged...
>>
>> I'll fix it up manually this time around but please check your mailer
>> setup :-)
>>
>
> Allright, it's not quite that.
>
> I've looked at my docs, and it looks like older parts such as the 440EP
> do -not- take the config type in the low bit.
>
> More interestingly, they only generate config 0 cycles if you pass a bus
> number of 0 :-)
>
> So we'll need do do something a little bit different here. We probably
> need to indicate in the device-tree what kind of SoC we have (whether
> it supports the explicit bit to choose between type 0 and type 1 or
> not).
>
> If not, we should then set the "self_busno" field of the bridge to 0,
> causing indirect_pci to always use bus number 0 when trying to talk
> to the bus segment behind the bridge, whatever the linux bus number
> for it actually is.
>
> Now, we need to make a precise list here of what SoC uses what. 460xx
> seem to all support the explicit bit. 440EP doesn't. What else ?
>
> Somebody from AMCC can dbl check that ?
>
I've checked what platforms take configuration type in the lower bit:
405XX - no
440EP - no
440GR - no
440EPx/440GRx - no
440GP - yes
440GX - yes
440SP - yes
440SPe - yes
460XX - yes
The distinction between these groups is pretty clear in the device trees.
The members of the first group all have "ibm,plb-pci" property, and all
members of second group have "ibm,plb-pcix" property.
So only ppc4xx_probe_pcix_bridge() routine should be fixed.
Felix.
^ permalink raw reply
* Re: [RFC] [PATCH] watchdog_info separation and constify
From: Mark Brown @ 2010-01-19 22:16 UTC (permalink / raw)
To: Joe Perches
Cc: LKML, linuxppc-dev, Wim Van Sebroeck, uclinux-dist-devel,
Russell King, Andrew Morton, linux-omap, Florian Fainelli,
Alan Cox
In-Reply-To: <1263937351.18117.69.camel@Joe-Laptop.home>
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> Maybe a standard #define WATCHDOG_NAME <foo>
> .identity = WATCHGOD_NAME
I don't really see that the indrection via the #define would buy us
anything?
^ 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