* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-13 9:10 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-mtd, David Woodhouse, Milton Miller
In-Reply-To: <20070613061152.GF16148@localhost.localdomain>
>> MTD does a lot of heuristic probing. It is pretty good,
>> but it would be nice if you could skip that and hand it
>> the exact values it needs. Also, this information should
>> be in the device tree no matter what, even if Linux
>> doesn't use it yet ;-)
>
> I agree. Of course, this means figuring out what the values actually
> are for Ebony. I presently have no idea, since the heuristic probing
> appears to work without problem.
Doesn't it show it in sysfs, or in the dmesg at least?
Maybe some other important stuff is there, too.
Segher
^ permalink raw reply
* Re: [patch 05/30] PS3: Use ioremap_flags
From: Arnd Bergmann @ 2007-06-13 9:10 UTC (permalink / raw)
To: Geoff Levand; +Cc: Masato Noguchi, linuxppc-dev, Geert Uytterhoeven, paulus
In-Reply-To: <466EE965.404@am.sony.com>
T24gVHVlc2RheSAxMiBKdW5lIDIwMDcsIEdlb2ZmIExldmFuZCB3cm90ZToKPiAtwqDCoMKgwqDC
oMKgwqBzcHUtPnByb2JsZW0gPSBpb3JlbWFwKHNwdS0+cHJvYmxlbV9waHlzLAo+IC3CoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBzaXplb2Yoc3RydWN0IHNwdV9wcm9ibGVtKSk7Cj4gK8Kg
wqDCoMKgwqDCoMKgc3B1LT5wcm9ibGVtID0gKF9fZm9yY2Ugdm9pZCAqKWlvcmVtYXBfZmxhZ3Mo
c3B1LT5wcm9ibGVtX3BoeXMsCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHNpemVv
ZihzdHJ1Y3Qgc3B1X3Byb2JsZW0pLCBfUEFHRV9OT19DQUNIRSk7Cj4gKwoKVW5saWtlIHRoZSBs
b2NhbF9zdG9yZSBtZW1iZXIsIG9mIHN0cnVjdCBzcHUsIC0+cHJvYmxlbSBhbmQgLT5wcml2Mgpt
ZW1iZXJzIGFyZSBfX2lvbWVtLCBzbyB5b3Ugc2hvdWxkIG5vdCBkbyBhIF9fZm9yY2UgY2FzdCBo
ZXJlLgoKT3RoZXIgdGhhbiB0aGF0LCB0aGUgcGF0Y2ggbG9va3MgZ29vZC4KCk5vdGUgdGhhdCBJ
IG1heSByZXBseSBmYXN0ZXIgaXMgeW91IHNlbmQgeW91ciBtZXNzYWdlcyB0byBhcm5kQGFybmRi
LmRlCmluc3RlYWQgb2YgYXJuZC5iZXJnbWFubkBkZS5pYm0uY29tLgoKCUFybmQgPD48Cg==
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-13 9:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070613061254.GG16148@localhost.localdomain>
> Hrm, ok. Between you and BenH you've convinced me. I'll try to come
> up with something. I think we'll still need to support the old
> properties as backwards compatibility thing.
Yes, of course.
I'm still not happy with creating nodes for application
flash partitions in the device tree; this isn't done
for disk partitions either, for analogue reasons (namely,
that info doesn't belong in the device tree, it is the
wrong abstraction).
How do non-device-tree MTD users handle this?
Segher
^ permalink raw reply
* Re: [PATCH v4]: Fix e500 v2 core reboot bug
From: Zang Roy-r61911 @ 2007-06-13 9:13 UTC (permalink / raw)
To: Segher Boessenkool, Paul Mackerras, Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4470838fec2256a98e512486f8486605@kernel.crashing.org>
From: Roy Zang <tie-fei.zang@freescale.com>
Fix the reset bug on 8548CDS board.
Begin from MPC8548 with e500 v2 core, a new reset
control register is added.
This register is used for the cpu reset.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
Pick up this one :-(
arch/powerpc/boot/dts/mpc8548cds.dts | 6 ++++++
arch/powerpc/platforms/85xx/misc.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index ad96381..0550a3c 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -177,6 +177,12 @@
interrupt-parent = <&mpic>;
};
+ global-utilities@e0000 { //global utilities reg
+ compatible = "fsl,mpc8548-guts";
+ reg = <e0000 1000>;
+ fsl,has-rstcr;
+ };
+
pci1: pci@8000 {
interrupt-map-mask = <1f800 0 0 7>;
interrupt-map = <
diff --git a/arch/powerpc/platforms/85xx/misc.c b/arch/powerpc/platforms/85xx/misc.c
index 3e62fcb..4ac0b20 100644
--- a/arch/powerpc/platforms/85xx/misc.c
+++ b/arch/powerpc/platforms/85xx/misc.c
@@ -13,11 +13,43 @@
#include <linux/irq.h>
#include <linux/module.h>
#include <asm/irq.h>
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <sysdev/fsl_soc.h>
+
+static __be32 __iomem *rstcr;
extern void abort(void);
+static int __init mpc85xx_rstcr(void)
+{
+ struct device_node *np;
+ np = of_find_node_by_name(NULL, "global-utilities");
+ if ((np && of_get_property(np, "fsl,has-rstcr", NULL))) {
+ const u32 *prop = of_get_property(np, "reg", NULL);
+ if (prop) {
+ /* map reset control register
+ * 0xE00B0 is offset of reset control register
+ */
+ rstcr = ioremap(get_immrbase() + *prop + 0xB0, 0xff);
+ if (!rstcr)
+ printk (KERN_EMERG "Error: reset control "
+ "register not mapped!\n");
+ }
+ } else
+ printk (KERN_INFO "rstcr compatible register does not exist!\n");
+ if (np)
+ of_node_put(np);
+ return 0;
+}
+
+arch_initcall(mpc85xx_rstcr);
+
void mpc85xx_restart(char *cmd)
{
local_irq_disable();
+ if (rstcr)
+ /* set reset control register */
+ out_be32(rstcr, 0x2); /* HRESET_REQ */
abort();
}
--
1.5.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Gibson @ 2007-06-13 9:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <bc98b5372977d171b0075074bfce7747@kernel.crashing.org>
On Wed, Jun 13, 2007 at 11:13:21AM +0200, Segher Boessenkool wrote:
> > Hrm, ok. Between you and BenH you've convinced me. I'll try to come
> > up with something. I think we'll still need to support the old
> > properties as backwards compatibility thing.
>
> Yes, of course.
>
> I'm still not happy with creating nodes for application
> flash partitions in the device tree; this isn't done
> for disk partitions either, for analogue reasons (namely,
> that info doesn't belong in the device tree, it is the
> wrong abstraction).
>
> How do non-device-tree MTD users handle this?
Invidual, board-specific map files with hardcoded partition tables.
See drivers/mtd/maps/ebony.c for example. Hence my view of the device
tree as a preferable option.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Segher Boessenkool @ 2007-06-13 9:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070613091904.GA30948@localhost.localdomain>
>> How do non-device-tree MTD users handle this?
>
> Invidual, board-specific map files with hardcoded partition tables.
That's what I was afraid of. Sigh.
> See drivers/mtd/maps/ebony.c for example.
[/me looks...] Oh horror.
> Hence my view of the device
> tree as a preferable option.
I think some binary partition table format that can be
used by _all_ MTD consumers should be defined. How
that table should be communicated to the kernel in the
device tree case we can discuss later, then. Maybe
something as simple as storing it in flash, and have a
"partition-table-offset" property or something like that.
This is something the MTD people will have to buy into
of course.
Segher
^ permalink raw reply
* RE: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei-r63237 @ 2007-06-13 9:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <59453d80f2f111b72e8f24e7b489c23e@kernel.crashing.org>
Hi, Segher,=20
>=20
> >>> + - device_type : Should be "rapidio"
> >>
> >> There is no OF binding, so no.
> >
> > So, we need to define it.
>=20
> If you want to. Until that has been done, don't use
> a "device_type". Linux won't use it, anyway.
Do you have another ideas about that? Only remove it?
>=20
> >>> + - compatible : Should be "fsl,rapidio-v0.0" or
> >> "fsl,rapidio-v1.0"
> >>> + and so on. The version number is got from IP Block Revision
> >>> + Register of RapidIO controller.
> >>
> >> It's better to use real device names, just like everyone
> >> else.
> >
> > Some silicons of Freescale processor are the same RapidIO=20
> controller,
> > such as mpc8540/mpc8560 are the same (v0.0), mpc8548/mpc8641 are the
> > same (v1.0). For v1.0 RapidIO controller, should we use mpc8548 or
> > mpc8641? Those will make people confused.
>=20
> Not at all. On an 8641 it could be
>=20
> compatible =3D "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";
>=20
> which states "this is the 8641 thing and it is compatible
> to the 8548 thing". Perfectly clear.
>=20
> > Using IP Block Revision is a
> > clear choice.
>=20
> I don't think so. For one thing, it describes a version of
> a cell design, not a version of an actual device. For another
> thing, if I hear "8641" I know what you're talking about (sort
> of, anyway), but I draw a blank stare if you say "v1.0". I'm
> sure I'm not the only one. Concrete names are good.
>=20
>From the different view ways, there are different results. Getting the
version from RapidIO IP revision register is clear to me. :)
> >>> + - #address-cells : Address representation for
> >> "rapidio" devices.
> >>> + This field represents the number of cells needed=20
> to represent
> >>> + the RapidIO address of the registers. For
> >> supporting more than
> >>> + 36-bits RapidIO address, this field should be <2>.
> >>
> >> More than 32 bit?
> >
> > Yes, RapidIO bus address width is 34 bits.
>=20
> You said "more than 36 bit", I tried to ask if that is a typo
> perhaps.
Ya, caught by you! I'll fix it in next version. :)
>=20
> >> No. The format of an "interrupts" entry is defined by
> >> the interrupt domain this device sits in, not by the
> >> device itself.
> >>
> > Do you misunderstand the meaning of 'interrupts'?
>=20
> Hahaha. No, I don't misunderstand what the "interrupts" property
> means. Perhaps you do?
>=20
> > These interrupts is
> > issued from the RapidIO controller to the pic controller for tx, rx,
> > err, doorbell and message.
>=20
> But the rapidio node doesn't know or care what the interrupts
> are connected to, and neither should it. That's what the
> interrupt mapping recommended practice is for.
>=20
There are no rapidio device in it. Doorbell, msg are all parts of
rapidio controller.
For example, 8641 rapidio controller have 2 msg unit: msg0 and msg1.
They are not rapidio devices. Each msg unit has the tx_irq and rx_irq.
> >>> For this sector, interrupts order should be
> >>> + <err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
> >>> + msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
> >>
> >> That's to be defined in the binding for your specific device,
> >> not in a more generic rapidio binding.
> >
> > These description is just for compatible=3D"fsl,rapidio-v*.*" =
rapidio
> > controller.
>=20
> Okay, good. Please make that way more obvious then :-)
>=20
> >>> + #address-cells =3D <2>;
> >>
> >> You want a #size-cells as well.
> >
> > The size is not used in this sector, so no defined.
>=20
> The size _is_ used; in the "ranges" property in this node,
> for example. It is also needed to describe the "reg" for
> any child node of this node.
>=20
> A non-existant "#size-cells" means 1, and "#address-cells"
> means 2, so in principle you could do without these
> properties; but Linux doesn't parse the tree correctly in
> that case (which reminds me, I have some more patches to
> send).
>=20
Ok, I'll add it in the next version for more religious.
Thanks!
Wei.
^ permalink raw reply
* Re: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-13 9:48 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C526DF5@zch01exm26.fsl.freescale.net>
>>>>> + - device_type : Should be "rapidio"
>>>>
>>>> There is no OF binding, so no.
>>>
>>> So, we need to define it.
>>
>> If you want to. Until that has been done, don't use
>> a "device_type". Linux won't use it, anyway.
>
> Do you have another ideas about that? Only remove it?
Yeah, remove it.
>>> Using IP Block Revision is a
>>> clear choice.
>>
>> I don't think so. For one thing, it describes a version of
>> a cell design, not a version of an actual device. For another
>> thing, if I hear "8641" I know what you're talking about (sort
>> of, anyway), but I draw a blank stare if you say "v1.0". I'm
>> sure I'm not the only one. Concrete names are good.
>>
>
>> From the different view ways, there are different results. Getting the
> version from RapidIO IP revision register is clear to me. :)
It's not in line with how all other "compatible" properties
are done though.
>> But the rapidio node doesn't know or care what the interrupts
>> are connected to, and neither should it. That's what the
>> interrupt mapping recommended practice is for.
>
> There are no rapidio device in it. Doorbell, msg are all parts of
> rapidio controller.
> For example, 8641 rapidio controller have 2 msg unit: msg0 and msg1.
> They are not rapidio devices. Each msg unit has the tx_irq and rx_irq.
Ah, I think I understand what you mean now. Yes, the binding
for this specific rapidio controller should define the _order_
of the interrupts in the "interrupts" property; but it cannot
define the format of the single entries, that is defined by
the interrupt controller node it is connected to already.
>>>> You want a #size-cells as well.
>>>
>>> The size is not used in this sector, so no defined.
>>
>> The size _is_ used; in the "ranges" property in this node,
>> for example. It is also needed to describe the "reg" for
>> any child node of this node.
>>
>> A non-existant "#size-cells" means 1, and "#address-cells"
>> means 2, so in principle you could do without these
>> properties; but Linux doesn't parse the tree correctly in
>> that case (which reminds me, I have some more patches to
>> send).
>
> Ok, I'll add it in the next version for more religious.
It's not religious; true OF believers say leave the node
out if its value would be 1. It's just that Linux doesn't
handle that properly yet, so you want to protect yourself :-)
Segher
^ permalink raw reply
* [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-13 10:19 UTC (permalink / raw)
To: linuxppc-dev list
Hello folks,
I'm currently working on a Linux 2.6.x port for a MCP7448 based board.
And I'm observing that some memory areas become corrupted on early
kernel startup. Namely some parts of kernel page table, that leads to
sudden kernel crashes. After some investigations I've managed to narrow
the problem down to a _set_L2CR() function that seems to not work for
this processor and the memory become corrupted after the cache is
flushed and re-enabled.
Note that I'm working with arch/ppc code. I've looked through
arch/powerpc sources and found some fixes for MPC7450 processors family
in l2cr_6xx.S. Then I've backported them to arch/ppc but it didn't help.
I read the MPC7450 reference manual and it describes a method to flush
the cache using L2 hardware flushing feature. The cache flushing
procedure consist of several steps and some of them are dictated by
MPC7448 errata (www.freescale.com/files/32bit/doc/errata/MPC7448CE.pdf,
Erratum no.3).
When I implemented that method in _set_L2CR() (patch included below)
following the MPC7450 reference manual, things worked fine. With these
changes the kernel works stable. The same result I get when I force a
boot loader to not enable the L2 cache before starting the kernel.
So, I have couple questions:
First, I'm looking for a help and advice why the current _set_L2CR()
implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
installed). Is it a bug in _set_L2CR() or a hardware problem. I've
mentioned above about MPC7450 hardware bug in L2 hardware flushing
mechanism. May it be applicable to common cache flushing procedure based
on sequence of lwz/dcbf instructions?
I'd like to note that I've had a hard time to find a root cause of the
problem in the current _set_L2CR() implementation. I changed a size of
memory used to fill and then flush the cache, tried to apply the
workaround for the MPC7448 hardware bug above and nothing helped except
the patch below.
Second, Is this patch acceptable?
Any feedback will be appreciated.
Thanks in advance,
Vlad.
---
arch/powerpc/kernel/l2cr_6xx.S | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/l2cr_6xx.S b/arch/powerpc/kernel/l2cr_6xx.S
index 858f28a..e6d96a6 100644
--- a/arch/powerpc/kernel/l2cr_6xx.S
+++ b/arch/powerpc/kernel/l2cr_6xx.S
@@ -156,6 +156,19 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
****/
BEGIN_FTR_SECTION
+ /* MPC7450 provides a L2 hardware flushing mechanism
+ * implemented through L2CR[L2HWF] bit. Refer to MPC7450
+ * reference manual p. 3-53 for details.
+ */
+
+ /* Set L2CR[L2IO], L2CR[L2DO] to lock the cache */
+ mfspr r4, SPRN_L2CR
+ oris r4, r4, 0x0011
+ sync
+ mtspr SPRN_L2CR, r4
+ sync
+ isync
+
/* Disable L2 prefetch on some 745x and try to ensure
* L2 prefetch engines are idle. As explained by errata
* text, we can't be sure they are, we just hope very hard
@@ -173,6 +186,31 @@ BEGIN_FTR_SECTION
dcbf 0,r4
dcbf 0,r4
dcbf 0,r4
+
+ /* Flush and invalidate L2:
+ * Set L2HWF and wait till it is cleared.
+ */
+ mfspr r4, SPRN_L2CR
+ ori r4, r4, 0x0800
+ sync
+ mtspr SPRN_L2CR, r4
+ sync
+ isync
+
+1: mfspr r4, SPRN_L2CR
+ rlwinm. r0,r4,0,20,20
+ bne 1b
+
+ /* Clear L2IO, L2DO to unlock the cache */
+ mfspr r4, SPRN_L2CR
+ rlwinm r4, r4, 0, 12, 10
+ rlwinm r4, r4, 0, 16, 14
+ sync
+ mtspr SPRN_L2CR, r4
+ sync
+ isync
+
+ b 2f
END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450)
/* TODO: use HW flush assist when available */
^ permalink raw reply related
* Re: [patch 29/30] PS3: Device tree source.
From: Olaf Hering @ 2007-06-13 11:24 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <0502b4de346bce374f98c49a99be50c1@kernel.crashing.org>
On Wed, Jun 13, Segher Boessenkool wrote:
> Please read up on what those properties mean exactly.
Yes, do that before the inital release.
currently name contains ''
currently compatible contains 'PS3PF'
currently model contains 'PLAYSTATION 3'
Now, do not break the userspace ABI.
If there is really an urge to break it, add the new device-tree to
2.6.22 and do not change the new values anymore.
^ permalink raw reply
* Enforcing built-in driver init order?
From: Matt Sealey @ 2007-06-13 11:28 UTC (permalink / raw)
To: ppc-dev
I'm trying to work out how to decouple the BestComm SRAM driver from the
BestComm DMA engine. SRAM is far more useful than just as a DMA buffer,
especially as it can stay active over deep sleep and SDRAM refresh turned
off, as a temporary place to put things. Even with a full set of tasks
there are still some kilobytes free. In future processors the SRAM will
only get larger meaning you can do more things with it, and it may be
used for more than DMA.
My simple problem is, if I split the two drivers apart, the SRAM platform
driver is not guaranteed to load before the DMA platform driver. If it
were a module I could have depmod handle it and load them in order but
this isn't possible since DMA is required on boot, and SRAM is required
for DMA.
Any clues or hints on how it can be EASILY enforced that the SRAM platform
driver is present (and can be checked for??) before the BestComm engine
is turned on and tasks are arbitrarily loaded?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-13 11:59 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070613112448.GA29239@aepfle.de>
>> Please read up on what those properties mean exactly.
>
> Yes, do that before the inital release.
>
> currently name contains ''
> currently compatible contains 'PS3PF'
> currently model contains 'PLAYSTATION 3'
>
> Now, do not break the userspace ABI.
The device tree is not a userspace ABI. Since
in this case it is built into the kernel image
(is it, actually?) there is no breakage between
firmware and kernel versions, either.
> If there is really an urge to break it,
Break what? It's just a bugfix.
> add the new device-tree to
> 2.6.22 and do not change the new values anymore.
If you require the device tree not ever to change,
you can just as well not have a device tree at all.
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Olaf Hering @ 2007-06-13 12:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <184b5119eca8beae9a28453096b6fe26@kernel.crashing.org>
On Wed, Jun 13, Segher Boessenkool wrote:
> The device tree is not a userspace ABI.
It is an userspace ABI. Simply because at some point the OS wants to know
which platform/boardtype/whatever it is running on.
^ permalink raw reply
* Re: [PATCH 6/6] [C67x00] Merge c67x00-hub.c into c67x00-hcd.c
From: Grant Likely @ 2007-06-13 12:54 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linux-usb-devel, linuxppc-embedded
In-Reply-To: <87645sieew.fsf@p4.be.48ers.dk>
On 6/12/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
> Grant> Rather than c67x00-hub.c being compiled seperately, the
> Grant> original code had c67x00-hub.c *included* by c67x00-hcd.c.
> Grant> This is a very bad idea. Simplest solution is to merge the
> Grant> two files into one and be done with it.
>
> Yeah, it isn't exactly pretty, but it's what the other hcd drivers do,
> E.G.:
>
> % grep -rs "include.*hub.c" *c
> ehci-hcd.c:#include "ehci-hub.c"
> ohci-hcd.c:#include "ohci-hub.c"
> uhci-hcd.c:#include "uhci-hub.c"
>
> I don't quite know why they do it like that though ..
True, but that doesn't mean that it's a good idea to follow the lead.
There are lots of other examples of ugly code in the kernel that is
tolerated just because nobody has cleaned it up yet, but is still
unacceptable for new code.
We know it's an ugly thing to do, and the fix is simple and easy.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Geert Uytterhoeven @ 2007-06-13 13:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <184b5119eca8beae9a28453096b6fe26@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1197 bytes --]
On Wed, 13 Jun 2007, Segher Boessenkool wrote:
> >> Please read up on what those properties mean exactly.
> > Yes, do that before the inital release.
> >
> > currently name contains ''
> > currently compatible contains 'PS3PF'
> > currently model contains 'PLAYSTATION 3'
> >
> > Now, do not break the userspace ABI.
>
> The device tree is not a userspace ABI. Since
> in this case it is built into the kernel image
> (is it, actually?) there is no breakage between
> firmware and kernel versions, either.
It is built-in for the kboot kernel.
It is passed from the bootstrap to the 2nd stage kernel.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1930 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 413.825.160 · RPR Brussels
Fortis Bank Londerzeel IBAN BE39 0013 8235 8619 GEBA-BE-BB
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-13 13:51 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070613122852.GA30524@aepfle.de>
>> The device tree is not a userspace ABI.
>
> It is an userspace ABI. Simply because at some point the OS wants to
> know
> which platform/boardtype/whatever it is running on.
What's wrong with uname -m or cat /proc/cpuinfo?
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-13 13:52 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <Pine.LNX.4.62.0706131542280.20109@pademelon.sonytel.be>
>> The device tree is not a userspace ABI. Since
>> in this case it is built into the kernel image
>> (is it, actually?) there is no breakage between
>> firmware and kernel versions, either.
>
> It is built-in for the kboot kernel.
> It is passed from the bootstrap to the 2nd stage kernel.
The 2nd stage kernel isn't userland.
Segher
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 6/6] [C67x00] Merge c67x00-hub.c into c67x00-hcd.c
From: phil culler @ 2007-06-13 13:59 UTC (permalink / raw)
To: Grant Likely; +Cc: Peter Korsgaard, linux-usb-devel, linuxppc-embedded
In-Reply-To: <fa686aa40706130554l36fefa13w4e2b1957a9fc5288@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
On 6/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> On 6/12/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> > >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
> >
> > Hi,
> >
> > Grant> Rather than c67x00-hub.c being compiled seperately, the
> > Grant> original code had c67x00-hub.c *included* by c67x00-hcd.c.
> > Grant> This is a very bad idea. Simplest solution is to merge the
> > Grant> two files into one and be done with it.
Hi Guys,
> I'm currently implementing the gadget API for the c67x00 (specifically
> CY7C63200) and have several questions.
>
> 1. Are you aware of any others working on the gadget API for this driver?
> 2. I'm doing this on an embedded device (Xilinix/PPC) with no hardware DMA
> and on top of MontaVista 4.01 (2.6.10-kernel). I'd prefer to develop on a
> current kernel using something like a PCI card. Can you recommend a
> reasonably-priced development platform for the c67x00?
> 3. Any suggestions about preventing additional ugly code? I'm adding the
> bulk of the API in c67x00-udc.c
>
> Many thanks,
> -Phil Culler
> phil@pliablerhino.com
>
[-- Attachment #2: Type: text/html, Size: 1848 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use long for 32-bit temp variables in spin lock ops
From: Olof Johansson @ 2007-06-13 14:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18031.29567.757635.864638@cargo.ozlabs.ibm.com>
On Wed, Jun 13, 2007 at 02:33:03PM +1000, Paul Mackerras wrote:
> > Note the cmpdi at ..78 when r9 was loaded with lwarx.
>
> That's OK; the lwarx is defined to zero-extend the value to 64 bits.
>
> Or are you implying that cmpdi is slower than cmpwi on some 64-bit
> processors? :)
Nope, it was just seemed inconsistent to me, especially since the
preceding (asm) comparison was 32-bit.
-Olof
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Geert Uytterhoeven @ 2007-06-13 14:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <b6fa43eadda7c64fe95ed99e78dcf277@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1095 bytes --]
On Wed, 13 Jun 2007, Segher Boessenkool wrote:
> >> The device tree is not a userspace ABI. Since
> >> in this case it is built into the kernel image
> >> (is it, actually?) there is no breakage between
> >> firmware and kernel versions, either.
> >
> > It is built-in for the kboot kernel.
> > It is passed from the bootstrap to the 2nd stage kernel.
>
> The 2nd stage kernel isn't userland.
If you consider the kboot kernel `firmware', there can be breakage between
firmware and kernel versions.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1930 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 413.825.160 · RPR Brussels
Fortis Bank Londerzeel IBAN BE39 0013 8235 8619 GEBA-BE-BB
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-13 14:18 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <Pine.LNX.4.62.0706131609190.20109@pademelon.sonytel.be>
>>> It is built-in for the kboot kernel.
>>> It is passed from the bootstrap to the 2nd stage kernel.
>>
>> The 2nd stage kernel isn't userland.
>
> If you consider the kboot kernel `firmware', there can be breakage
> between
> firmware and kernel versions.
Ah I see. Your first kernel is in flash, the second
on disk?
There's no reason not to have the second kernel
recognise the old device tree names, at least for
a while. Nothing special here. This is independent
from either or not correcting the device tree, and
correcting the kernel to look at the right properties
if possible (it can always fall back to the bad old
ways, if it cannot figure out what machine type it is
running on otherwise).
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Geert Uytterhoeven @ 2007-06-13 14:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <d13fe04437156ea27f697210f00aedf0@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 994 bytes --]
On Wed, 13 Jun 2007, Segher Boessenkool wrote:
> > > > It is built-in for the kboot kernel.
> > > > It is passed from the bootstrap to the 2nd stage kernel.
> > >
> > > The 2nd stage kernel isn't userland.
> >
> > If you consider the kboot kernel `firmware', there can be breakage between
> > firmware and kernel versions.
>
> Ah I see. Your first kernel is in flash, the second
> on disk?
Yes.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1930 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 413.825.160 · RPR Brussels
Fortis Bank Londerzeel IBAN BE39 0013 8235 8619 GEBA-BE-BB
^ permalink raw reply
* ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Joakim Tjernlund @ 2007-06-13 14:22 UTC (permalink / raw)
To: 'linuxppc-dev Development', Li Yang-r58472
Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
a Freescale 832x CPU gives me this:
ifconfig eth2 up
ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
eth2: Cannot configure net device, aborting.
SIOCSIFFLAGS: Cannot allocate memory
This worked in 2.6.20
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 6/6] [C67x00] Merge c67x00-hub.c into c67x00-hcd.c
From: Grant Likely @ 2007-06-13 14:33 UTC (permalink / raw)
To: phil culler; +Cc: Peter Korsgaard, linux-usb-devel, linuxppc-embedded
In-Reply-To: <a94a91430706130659v2ac10f82h355c0bbb4fd6f2cb@mail.gmail.com>
On 6/13/07, phil culler <phil.culler@gmail.com> wrote:
>
> On 6/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 6/12/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> > > >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca > writes:
> > >
> > > Hi,
> > >
> > > Grant> Rather than c67x00-hub.c being compiled seperately, the
> > > Grant> original code had c67x00-hub.c *included* by c67x00-hcd.c.
> > > Grant> This is a very bad idea. Simplest solution is to merge the
> > > Grant> two files into one and be done with it.
>
>
> > Hi Guys,
> > I'm currently implementing the gadget API for the c67x00 (specifically
> CY7C63200) and have several questions.
> >
> > 1. Are you aware of any others working on the gadget API for this driver?
Other than the skeleton that Peter wrote, No. However, Peter has done
much of the low level work that is shared between HCD and Gadget. You
need to look at his patchset.
http://thread.gmane.org/gmane.linux.usb.devel/53285
> > 2. I'm doing this on an embedded device (Xilinix/PPC) with no hardware DMA
> and on top of MontaVista 4.01 (2.6.10-kernel). I'd prefer to develop on a
> current kernel using something like a PCI card. Can you recommend a
> reasonably-priced development platform for the c67x00?
Hmm, I don't know. I don't know of any. I'm doing all my devel on an
ml403. Check with Cypress. I think they have an ARM based
development kit for the c67x00.
> > 3. Any suggestions about preventing additional ugly code? I'm adding the
> bulk of the API in c67x00-udc.c
Yes, post your patches to the list so so others can comment. That's
the best way to find out if you're taking a bad approach. Also,
follow the Linux kernel coding convention and run your code through
scripts/Lindent
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 6/6] [C67x00] Merge c67x00-hub.c into c67x00-hcd.c
From: Alan Stern @ 2007-06-13 14:37 UTC (permalink / raw)
To: Grant Likely; +Cc: Peter Korsgaard, linux-usb-devel, linuxppc-embedded
In-Reply-To: <fa686aa40706130554l36fefa13w4e2b1957a9fc5288@mail.gmail.com>
On Wed, 13 Jun 2007, Grant Likely wrote:
> On 6/12/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> > >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
> >
> > Hi,
> >
> > Grant> Rather than c67x00-hub.c being compiled seperately, the
> > Grant> original code had c67x00-hub.c *included* by c67x00-hcd.c.
> > Grant> This is a very bad idea.
What's so bad about it? It's an elegant solution to the problem of
breaking a very long driver up into smaller, more digestible pieces
without polluting the kernel's namespace with lots of extra global
symbols.
> > Simplest solution is to merge the
> > Grant> two files into one and be done with it.
> >
> > Yeah, it isn't exactly pretty, but it's what the other hcd drivers do,
> > E.G.:
> >
> > % grep -rs "include.*hub.c" *c
> > ehci-hcd.c:#include "ehci-hub.c"
> > ohci-hcd.c:#include "ohci-hub.c"
> > uhci-hcd.c:#include "uhci-hub.c"
> >
> > I don't quite know why they do it like that though ..
>
> True, but that doesn't mean that it's a good idea to follow the lead.
Why not?
> There are lots of other examples of ugly code in the kernel that is
> tolerated just because nobody has cleaned it up yet, but is still
> unacceptable for new code.
What's so ugly about breaking a driver up into pieces? Leaving it in
one giant piece would be much more ugly IMO.
> We know it's an ugly thing to do, and the fix is simple and easy.
As the Firesign Theater once said, Everything you know is wrong! :-)
Alan Stern
^ 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