* RE: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Yoder Stuart-B08248 @ 2007-08-03 21:55 UTC (permalink / raw)
To: Loeliger Jon-LOELIGER, David Gibson; +Cc: linuxppc-dev, Paul Mackerras
> > > > + MPIC: interrupt-controller@d {
> > > > + device_type =3D "open-pic";
> > > >=20
> > > > device_type =3D "interrupt-controller".
> >=20
> > Not according to the binding in booting-without-of.txt
>=20
> My understanding here, though possibly flawed, is that the current
> implementation has "open-pic" but _should_ have "interrupt-controller"
> as that is the officially correct name.
>=20
> I _think_ this means we need a transitional period where we update
> the code to look for "interrupt-controller", and obsoletedly, looks
> for the "open-pic", while we transition to the new, correct name.
"open-pic" is the correct value for the device_type property.
See the binding at:
http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps
That is the definition for open pic interrupt controllers (AFAIK).
I am not aware of any official binding with "interrupt-controller"=20
as the device_type.
However, the interrupt mapping spec says that all interrupt
controller (regardless of device_type) must have a=20
property named "interrupt-controller" to identify
the device node as an interrupt controller and root of
a interrupt tree.
See: http://playground.sun.com/1275/practice/imap/imap0_9d.html
Stuart
^ permalink raw reply
* Re: BusyBox passwd requires root privileges
From: Scott Wood @ 2007-08-03 21:55 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11991239.post@talk.nabble.com>
khollan wrote:
>
>
> Scott Wood-2 wrote:
>
>>
>>passwd needs to be setuid root.
>>
>>
>
> How do you do that?
Make sure it's owned by root, and chmod 4755 the binary. I'm not sure
how to go about telling busybox to drop suid when invoked as something
else. It'd probably be better to build two busyboxes, one with all suid
commands and the other with the rest.
-Scott
^ permalink raw reply
* Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
From: Morrison, Tom @ 2007-08-03 22:54 UTC (permalink / raw)
To: linuxppc-dev
All,
Connected to eth1 (etsec2) of my mpc8548 cpu is a 88E1145 and I=20
am trying to get the core functionality running with the device tree
paradigm - I know the sense of the 88E1145 is active-low for my=20
mpc8548 board and have it working with an older 2.6.11++ kernel. =20
I built this new kernel with the marvell driver - it seemingly=20
does all the same things we did in the 2.6.11 kernel in separate=20
spots...
Here is the appropriate parts of my device tree for this part of the
core...
>> mdio@24520 {
>> #address-cells =3D <1>;
>> #size-cells =3D <0>;
>> device_type =3D "mdio";
>> compatible =3D "gianfar";=09
>> reg =3D <24520 20>;
>> phy1: ethernet-phy@1 {
>> interrupt-parent =3D <&mpic>;
>> interrupts =3D <37 1>;
>> reg =3D <11>;
>> device_type =3D "ethernet-phy";
>> };
>> };=09
>> ethernet@25000 {
>> #address-cells =3D <1>;
>> #size-cells =3D <0>;
>> device_type =3D "network";
>> model =3D "eTSEC";
>> compatible =3D "gianfar";
>> reg =3D <25000 1000>;
>> local-mac-address =3D [ 00 00 00 00 00 00 ];
>> interrupts =3D <23 2 24 2 28 2>;
>> interrupt-parent =3D <&mpic>;
>> phy-handle =3D <&phy1>;
>> };
>> mpic: pic@40000 {
>> clock-frequency =3D <0>;
>> interrupt-controller;
>> #address-cells =3D <0>;
>> #interrupt-cells =3D <2>;
>> reg =3D <40000 40000>;
>> built-in;
>> compatible =3D "chrp,open-pic";
>> device_type =3D "open-pic";
>> big-endian;
>> };
The device tree seems to be parsed OK:
>> of_irq_map_one: dev=3D/soc8548@e0000000/mdio@24520/ethernet-phy@1,
index=3D0
>> intsize=3D2 intlen=3D2
>> of_irq_map_raw: =
par=3D/soc8548@e0000000/pic@40000,intspec=3D[0x00000037
>> 0x00000001...],ointsize=3D2
>> of_irq_map_raw: ipar=3D/soc8548@e0000000/pic@40000, size=3D2
>> mpic: xlate (2 cells: 0x00000037 0x00000001) to line 0x37 sense 0x8
Now, that looks OK! Those are what I would expect. And when the=20
mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7=20
(0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
and basically hangs the entire box up and eventually it panics!
I don't even have an external phy(SFP) connected to this 88e1148 phy..
I am at a lost - is there something I am missing in device tree?=20
Help mr. wizard (Kumar?)...
Tom
^ permalink raw reply
* [PATCH v2] cell: move SPU affinity init to spu_management_of_ops
From: Geoff Levand @ 2007-08-04 1:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: hch, linuxppc-dev, Paul Mackerras, Andre Detsch, cbe-oss-dev
In-Reply-To: <200707252342.50244.adetsch@br.ibm.com>
From: Andre Detsch <adetsch@br.ibm.com>
This patch moves affinity initialization code from spu_base.c to a
new spu_management_of_ops function (init_affinity), which is empty
in the case of PS3. This fixes a linking problem that was happening
when compiling for PS3.
Also, some small code style changes were made.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Arnd,
I rebased this to to Paul's powerpc git tree. This needs to go
in for 2.6.23, as it fixes build breakage for PS3-only configs.
Please check and ack.
-Geoff
arch/powerpc/platforms/cell/spu_base.c | 141 --------------------------
arch/powerpc/platforms/cell/spu_manage.c | 163 +++++++++++++++++++++++++++++++
arch/powerpc/platforms/ps3/spu.c | 6 +
include/asm-powerpc/spu_priv1.h | 7 +
4 files changed, 177 insertions(+), 140 deletions(-)
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -36,7 +36,6 @@
#include <asm/spu_priv1.h>
#include <asm/xmon.h>
#include <asm/prom.h>
-#include "spu_priv1_mmio.h"
const struct spu_management_ops *spu_management_ops;
EXPORT_SYMBOL_GPL(spu_management_ops);
@@ -636,138 +635,6 @@ static ssize_t spu_stat_show(struct sys_
static SYSDEV_ATTR(stat, 0644, spu_stat_show, NULL);
-/* Hardcoded affinity idxs for QS20 */
-#define SPES_PER_BE 8
-static int QS20_reg_idxs[SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
-static int QS20_reg_memory[SPES_PER_BE] = { 1, 1, 0, 0, 0, 0, 0, 0 };
-
-static struct spu *spu_lookup_reg(int node, u32 reg)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, &cbe_spu_info[node].spus, cbe_list) {
- if (*(u32 *)get_property(spu_devnode(spu), "reg", NULL) == reg)
- return spu;
- }
- return NULL;
-}
-
-static void init_aff_QS20_harcoded(void)
-{
- int node, i;
- struct spu *last_spu, *spu;
- u32 reg;
-
- for (node = 0; node < MAX_NUMNODES; node++) {
- last_spu = NULL;
- for (i = 0; i < SPES_PER_BE; i++) {
- reg = QS20_reg_idxs[i];
- spu = spu_lookup_reg(node, reg);
- if (!spu)
- continue;
- spu->has_mem_affinity = QS20_reg_memory[reg];
- if (last_spu)
- list_add_tail(&spu->aff_list,
- &last_spu->aff_list);
- last_spu = spu;
- }
- }
-}
-
-static int of_has_vicinity(void)
-{
- struct spu* spu;
-
- spu = list_entry(cbe_spu_info[0].spus.next, struct spu, cbe_list);
- return of_find_property(spu_devnode(spu), "vicinity", NULL) != NULL;
-}
-
-static struct spu *aff_devnode_spu(int cbe, struct device_node *dn)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list)
- if (spu_devnode(spu) == dn)
- return spu;
- return NULL;
-}
-
-static struct spu *
-aff_node_next_to(int cbe, struct device_node *target, struct device_node *avoid)
-{
- struct spu *spu;
- const phandle *vic_handles;
- int lenp, i;
-
- list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list) {
- if (spu_devnode(spu) == avoid)
- continue;
- vic_handles = get_property(spu_devnode(spu), "vicinity", &lenp);
- for (i=0; i < (lenp / sizeof(phandle)); i++) {
- if (vic_handles[i] == target->linux_phandle)
- return spu;
- }
- }
- return NULL;
-}
-
-static void init_aff_fw_vicinity_node(int cbe)
-{
- struct spu *spu, *last_spu;
- struct device_node *vic_dn, *last_spu_dn;
- phandle avoid_ph;
- const phandle *vic_handles;
- const char *name;
- int lenp, i, added, mem_aff;
-
- last_spu = list_entry(cbe_spu_info[cbe].spus.next, struct spu, cbe_list);
- avoid_ph = 0;
- for (added = 1; added < cbe_spu_info[cbe].n_spus; added++) {
- last_spu_dn = spu_devnode(last_spu);
- vic_handles = get_property(last_spu_dn, "vicinity", &lenp);
-
- for (i = 0; i < (lenp / sizeof(phandle)); i++) {
- if (vic_handles[i] == avoid_ph)
- continue;
-
- vic_dn = of_find_node_by_phandle(vic_handles[i]);
- if (!vic_dn)
- continue;
-
- name = get_property(vic_dn, "name", NULL);
- if (strcmp(name, "spe") == 0) {
- spu = aff_devnode_spu(cbe, vic_dn);
- avoid_ph = last_spu_dn->linux_phandle;
- }
- else {
- mem_aff = strcmp(name, "mic-tm") == 0;
- spu = aff_node_next_to(cbe, vic_dn, last_spu_dn);
- if (!spu)
- continue;
- if (mem_aff) {
- last_spu->has_mem_affinity = 1;
- spu->has_mem_affinity = 1;
- }
- avoid_ph = vic_dn->linux_phandle;
- }
- list_add_tail(&spu->aff_list, &last_spu->aff_list);
- last_spu = spu;
- break;
- }
- }
-}
-
-static void init_aff_fw_vicinity(void)
-{
- int cbe;
-
- /* sets has_mem_affinity for each spu, as long as the
- * spu->aff_list list, linking each spu to its neighbors
- */
- for (cbe = 0; cbe < MAX_NUMNODES; cbe++)
- init_aff_fw_vicinity_node(cbe);
-}
-
static int __init init_spu_base(void)
{
int i, ret = 0;
@@ -811,13 +678,7 @@ static int __init init_spu_base(void)
mutex_unlock(&spu_full_list_mutex);
spu_add_sysdev_attr(&attr_stat);
- if (of_has_vicinity()) {
- init_aff_fw_vicinity();
- } else {
- long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
- init_aff_QS20_harcoded();
- }
+ spu_init_affinity();
return 0;
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -361,8 +361,171 @@ static int of_destroy_spu(struct spu *sp
return 0;
}
+/* Hardcoded affinity idxs for qs20 */
+#define QS20_SPES_PER_BE 8
+static int qs20_reg_idxs[QS20_SPES_PER_BE] = { 0, 2, 4, 6, 7, 5, 3, 1 };
+static int qs20_reg_memory[QS20_SPES_PER_BE] = { 1, 1, 0, 0, 0, 0, 0, 0 };
+
+static struct spu *spu_lookup_reg(int node, u32 reg)
+{
+ struct spu *spu;
+ u32 *spu_reg;
+
+ list_for_each_entry(spu, &cbe_spu_info[node].spus, cbe_list) {
+ spu_reg = (u32*)of_get_property(spu_devnode(spu), "reg", NULL);
+ if (*spu_reg == reg)
+ return spu;
+ }
+ return NULL;
+}
+
+static void init_affinity_qs20_harcoded(void)
+{
+ int node, i;
+ struct spu *last_spu, *spu;
+ u32 reg;
+
+ for (node = 0; node < MAX_NUMNODES; node++) {
+ last_spu = NULL;
+ for (i = 0; i < QS20_SPES_PER_BE; i++) {
+ reg = qs20_reg_idxs[i];
+ spu = spu_lookup_reg(node, reg);
+ if (!spu)
+ continue;
+ spu->has_mem_affinity = qs20_reg_memory[reg];
+ if (last_spu)
+ list_add_tail(&spu->aff_list,
+ &last_spu->aff_list);
+ last_spu = spu;
+ }
+ }
+}
+
+static int of_has_vicinity(void)
+{
+ struct spu* spu;
+
+ spu = list_first_entry(&cbe_spu_info[0].spus, struct spu, cbe_list);
+ return of_find_property(spu_devnode(spu), "vicinity", NULL) != NULL;
+}
+
+static struct spu *devnode_spu(int cbe, struct device_node *dn)
+{
+ struct spu *spu;
+
+ list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list)
+ if (spu_devnode(spu) == dn)
+ return spu;
+ return NULL;
+}
+
+static struct spu *
+neighbour_spu(int cbe, struct device_node *target, struct device_node *avoid)
+{
+ struct spu *spu;
+ struct device_node *spu_dn;
+ const phandle *vic_handles;
+ int lenp, i;
+
+ list_for_each_entry(spu, &cbe_spu_info[cbe].spus, cbe_list) {
+ spu_dn = spu_devnode(spu);
+ if (spu_dn == avoid)
+ continue;
+ vic_handles = of_get_property(spu_dn, "vicinity", &lenp);
+ for (i=0; i < (lenp / sizeof(phandle)); i++) {
+ if (vic_handles[i] == target->linux_phandle)
+ return spu;
+ }
+ }
+ return NULL;
+}
+
+static void init_affinity_node(int cbe)
+{
+ struct spu *spu, *last_spu;
+ struct device_node *vic_dn, *last_spu_dn;
+ phandle avoid_ph;
+ const phandle *vic_handles;
+ const char *name;
+ int lenp, i, added;
+
+ last_spu = list_first_entry(&cbe_spu_info[cbe].spus, struct spu,
+ cbe_list);
+ avoid_ph = 0;
+ for (added = 1; added < cbe_spu_info[cbe].n_spus; added++) {
+ last_spu_dn = spu_devnode(last_spu);
+ vic_handles = of_get_property(last_spu_dn, "vicinity", &lenp);
+
+ /*
+ * Walk through each phandle in vicinity property of the spu
+ * (tipically two vicinity phandles per spe node)
+ */
+ for (i = 0; i < (lenp / sizeof(phandle)); i++) {
+ if (vic_handles[i] == avoid_ph)
+ continue;
+
+ vic_dn = of_find_node_by_phandle(vic_handles[i]);
+ if (!vic_dn)
+ continue;
+
+ /* a neighbour might be spe, mic-tm, or bif0 */
+ name = of_get_property(vic_dn, "name", NULL);
+ if (!name)
+ continue;
+
+ if (strcmp(name, "spe") == 0) {
+ spu = devnode_spu(cbe, vic_dn);
+ avoid_ph = last_spu_dn->linux_phandle;
+ } else {
+ /*
+ * "mic-tm" and "bif0" nodes do not have
+ * vicinity property. So we need to find the
+ * spe which has vic_dn as neighbour, but
+ * skipping the one we came from (last_spu_dn)
+ */
+ spu = neighbour_spu(cbe, vic_dn, last_spu_dn);
+ if (!spu)
+ continue;
+ if (!strcmp(name, "mic-tm")) {
+ last_spu->has_mem_affinity = 1;
+ spu->has_mem_affinity = 1;
+ }
+ avoid_ph = vic_dn->linux_phandle;
+ }
+
+ list_add_tail(&spu->aff_list, &last_spu->aff_list);
+ last_spu = spu;
+ break;
+ }
+ }
+}
+
+static void init_affinity_fw(void)
+{
+ int cbe;
+
+ for (cbe = 0; cbe < MAX_NUMNODES; cbe++)
+ init_affinity_node(cbe);
+}
+
+static int __init init_affinity(void)
+{
+ if (of_has_vicinity()) {
+ init_affinity_fw();
+ } else {
+ long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
+ init_affinity_qs20_harcoded();
+ else
+ printk("No affinity configuration found");
+ }
+
+ return 0;
+}
+
const struct spu_management_ops spu_management_of_ops = {
.enumerate_spus = of_enumerate_spus,
.create_spu = of_create_spu,
.destroy_spu = of_destroy_spu,
+ .init_affinity = init_affinity,
};
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -414,10 +414,16 @@ static int __init ps3_enumerate_spus(int
return num_resource_id;
}
+static int ps3_init_affinity(void)
+{
+ return 0;
+}
+
const struct spu_management_ops spu_management_ps3_ops = {
.enumerate_spus = ps3_enumerate_spus,
.create_spu = ps3_create_spu,
.destroy_spu = ps3_destroy_spu,
+ .init_affinity = ps3_init_affinity,
};
/* spu_priv1_ops */
--- a/include/asm-powerpc/spu_priv1.h
+++ b/include/asm-powerpc/spu_priv1.h
@@ -178,6 +178,7 @@ struct spu_management_ops {
int (*enumerate_spus)(int (*fn)(void *data));
int (*create_spu)(struct spu *spu, void *data);
int (*destroy_spu)(struct spu *spu);
+ int (*init_affinity)(void);
};
extern const struct spu_management_ops* spu_management_ops;
@@ -200,6 +201,12 @@ spu_destroy_spu (struct spu *spu)
return spu_management_ops->destroy_spu(spu);
}
+static inline int
+spu_init_affinity (void)
+{
+ return spu_management_ops->init_affinity();
+}
+
/*
* The declarations folowing are put here for convenience
* and only intended to be used by the platform setup code.
^ permalink raw reply
* Re: [patch 06/10] 40x decrementer fixes
From: Benjamin Herrenschmidt @ 2007-08-04 2:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B35C07.4090806@ru.mvista.com>
On Fri, 2007-08-03 at 20:47 +0400, Sergei Shtylyov wrote:
> Josh Boyer wrote:
>
> > Allow generic_calibrate_decr to work for 40x platforms. Given that the hardware
> > behavior is identical, this also changes the set_dec function to reload the PIT
> > on 40x to match the behavior 44x currently has.
>
> Why bother doing this?! This will only warrant you imprecise decrementer
> interrupts while it should be interrupting at the precise period currently (if
> you load PIT once)...
Because that's what the kernel timekeeping code expects ? The reference
time is the timebase and it doesn't drift.
The DEC/PIT is commonly used to trigger any timing, such as what is done
for lost interrupts on some platforms. Also, with dynticks, we'll most
certainly want variable reload values as well.
So I'm very happy to have Josh change the code that way. It makes things
more consistent accross the board and removes confusion.
Ben.
^ permalink raw reply
* Re: [patch 06/10] 40x decrementer fixes
From: Benjamin Herrenschmidt @ 2007-08-04 2:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B3617B.10509@ru.mvista.com>
On Fri, 2007-08-03 at 21:10 +0400, Sergei Shtylyov wrote:
> > Why bother doing this?! This will only warrant you imprecise decrementer
> > interrupts while it should be interrupting at the precise period currently (if
> > you load PIT once)...
>
> I.e. the error will only accumulate. NAK.
No, it won't since the timebase is always used as the reference.
Ben.
^ permalink raw reply
* Re: Page faults blowing up ... [was Re: [PATCH] Fix special PTE code for secondary hash bucket
From: Benjamin Herrenschmidt @ 2007-08-04 2:31 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, benh
In-Reply-To: <20070803193258.GA9613@austin.ibm.com>
On Fri, 2007-08-03 at 14:32 -0500, Linas Vepstas wrote:
> On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote:
> > The code for mapping special 4k pages on kernels using a 64kB base
> > page size was missing the code for doing the RPN (real page number)
> > manipulation when inserting the hardware PTE in the secondary hash
> > bucket. It needs the same code as has already been added to the
> > code that inserts the HPTE in the primary hash bucket. This adds it.
>
> So what are the symptoms of hitting this? Does this affect only
> recent kernels, or old ones too?
Paulus stuff is likely to be unrelated to your bug. Also, whatever blurb
you pasted in this email is totally incomprehensible due to total lack
of context.
Ben.
^ permalink raw reply
* Re: Trying to use Device Tree...and getting continuous interrupts from attached 88e1145
From: Benjamin Herrenschmidt @ 2007-08-04 2:33 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90108BE44C2@EMPBEDEX.empirix.com>
On Fri, 2007-08-03 at 18:54 -0400, Morrison, Tom wrote:
> Now, that looks OK! Those are what I would expect. And when the
> mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7
> (0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
> and basically hangs the entire box up and eventually it panics!
>
> I don't even have an external phy(SFP) connected to this 88e1148 phy..
>
> I am at a lost - is there something I am missing in device tree?
> Help mr. wizard (Kumar?)...
Double check you got the interrupt sense and polarity right.
Ben.
^ permalink raw reply
* Re: [PATCH v2] cell: move SPU affinity init to spu_management_of_ops
From: Arnd Bergmann @ 2007-08-04 7:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andre Detsch, Paul Mackerras, hch, cbe-oss-dev
In-Reply-To: <46B3DC2A.408@am.sony.com>
On Saturday 04 August 2007, Geoff Levand wrote:
>
> From: Andre Detsch <adetsch@br.ibm.com>
>
> This patch moves affinity initialization code from spu_base.c to a
> new spu_management_of_ops function (init_affinity), which is empty
> in the case of PS3. This fixes a linking problem that was happening
> when compiling for PS3.
> Also, some small code style changes were made.
>
> Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Kumar Gala @ 2007-08-04 16:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Alexandros Kostopoulos
In-Reply-To: <20070803201036.GA18229@ld0162-tx32.am.freescale.net>
On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:
> On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos
> wrote:
>> Hi all,
>> in the old arch/ppc tree, there was a function called
>> pq2ads_setup_pci()
>> that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering,
>> where
>> are these registers configured now in arch/powerpc? I can't seem
>> to find
>> these code now.
>
> It's done by the firmware or the bootwrapper.
>> Also, I can see that now bus 0, dev 0 (which I think represents
>> the host
>> bridge, right?) is now excluded using pq2_pci_exclude_device, but it
>> wasn't in older code. Why is that?
>
> The older code probably either excluded all host bridges by class, or
> just lived with the error message that gets printed on boot.
This will change in 2.6.24. I've fixed the reason we excluded the
host bridges on Freescale host bridges.
- k
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-04 17:30 UTC (permalink / raw)
To: Robert Hancock; +Cc: linuxppc-dev, Olaf Hering, stable, linux-kernel
In-Reply-To: <46B4B3DC.7020609@shaw.ca>
(Adding Cc: linuxppc-dev, olh)
Robert Hancock wrote:
> Stefan Richter wrote:
>> Date: Wed, 1 Aug 2007 20:30:36 +0200 (CEST)
>> From: Stefan Richter <stefanr@s5r6.in-berlin.de>
>> Subject: ieee1394: revert "sbp2: enforce 32bit DMA mapping"
>>
>> Revert commit 0555659d63c285ceb7ead3115532e1b71b0f27a7 from 2.6.22-rc1.
>> The dma_set_mask call somehow failed on a PowerMac G5, PPC64:
>> http://lkml.org/lkml/2007/8/1/344
>>
>> Should there ever occur a DMA mapping beyond the physical DMA range, a
>> proper SBP-2 firmware will report transport errors. So let's leave it
>> at that.
>
> Isn't this a rather poor workaround? All this means is that if we fail
> to set a 32-bit DMA mask, we're likely to blow up at runtime instead of
> at initialization time, when we get a DMA mapping over 4GB.
I generally agree with you. But since I actually never heard of
problems that could directly be related to sbp2's DMA areas exceeding
the OHCI-1394 physical DMA range (4GB in most OHCI-1394
implementations), I consider this simple reversion good enough for post
2.6.23-rc1 and especially for 2.6.22.y.
My original commit 0555659.. was a violation of "If it ain't (known)
broken, don't fix it".
> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> with the DMA implementation on that architecture. There are enough cards
> out there that only support 32-bit DMA that this really needs to work..
Yes, could the PPC folks please have a look at it? Thanks.
>> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
>> Tested-by: Olaf Hering <olh@suse.de>
>> ---
>> Same as commit a9c2f18800753c82c45fc13b27bdc148849bdbb2.
>>
>> drivers/ieee1394/sbp2.c | 5 -----
>> 1 file changed, 5 deletions(-)
>>
>> Index: linux-2.6.22/drivers/ieee1394/sbp2.c
>> ===================================================================
>> --- linux-2.6.22.orig/drivers/ieee1394/sbp2.c
>> +++ linux-2.6.22/drivers/ieee1394/sbp2.c
>> @@ -774,11 +774,6 @@ static struct sbp2_lu *sbp2_alloc_device
>> SBP2_ERR("failed to register lower 4GB address range");
>> goto failed_alloc;
>> }
>> -#else
>> - if (dma_set_mask(hi->host->device.parent, DMA_32BIT_MASK)) {
>> - SBP2_ERR("failed to set 4GB DMA mask");
>> - goto failed_alloc;
>> - }
>> #endif
>> }
>>
--
Stefan Richter
-=====-=-=== =--- --=--
http://arcgraph.de/sr/
^ permalink raw reply
* 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Guennadi Liakhovetski @ 2007-08-04 23:17 UTC (permalink / raw)
To: linux-serial; +Cc: linuxppc-dev
Hi,
I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
"16650A" compatible double UART built into the SoC. Using of_serial.c
causes the ports to be autoconfigured, and this fails. The loopback test
fails, because the MSR register on 824[15] doesn't implement the
UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
SOCs to skip the loopback test altogether? The latter is certainly easier
and affects much fewer systems, so, I'd go for that.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Arnd Bergmann @ 2007-08-04 23:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Guennadi Liakhovetski, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708050106270.4299@poirot.grange>
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
> "16650A" compatible double UART built into the SoC. Using of_serial.c
> causes the ports to be autoconfigured, and this fails. The loopback test
> fails, because the MSR register on 824[15] doesn't implement the
> UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
> without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
> SOCs to skip the loopback test altogether? The latter is certainly easier
> and affects much fewer systems, so, I'd go for that.
Yes, that sounds good. Just make sure you test the "compatible" property
in the device node for something appropriate. In of_platform_serial_probe(),
you can then do something like
if (of_device_is_compatible(ofdev, "mpc8241-serial"))
flags |= UPF_SKIP_TEST;
Arnd <><
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Benjamin Herrenschmidt @ 2007-08-05 0:15 UTC (permalink / raw)
To: Stefan Richter
Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B4B7C6.1040107@s5r6.in-berlin.de>
> > If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> > with the DMA implementation on that architecture. There are enough cards
> > out there that only support 32-bit DMA that this really needs to work..
>
> Yes, could the PPC folks please have a look at it? Thanks.
Smells like we may have a bug there. No worries though, all current PPC
machines have an iommu that will not give out addresses above 32 bits
anyway, but I'll double check what's up.
Do you see something in dmesg when that happens ?
Ben.
^ permalink raw reply
* "Badness at kernel/irq/resend.c:70" on boot - via-pmu?
From: Paul Collins @ 2007-08-05 3:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: paulus, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708032031480.5037@woody.linux-foundation.org>
Hi Linus,
I got the message below on boot with 2.6.23-rc2 on my PowerBook.
I've Cc'd some powerpc folks because via_pmu_interrupt is in the
Macintosh PMU driver.
Hmm, I just looked back in my logs and I also got that message with
commit 7a883eaf62f4b943ebec738ce3b0796c67ef5d32. Before that I used
6c8dca5d53f95009d4fff00195bf38f277dc4366 and there was no badness
message logged by that one. There's only about 480 commits between
those two, so I can bisect it if necessary.
The call traces differ, so here are both messages.
v2.6.23-rc2:
------------[ cut here ]------------
Badness at kernel/irq/resend.c:70
NIP: c0054ca4 LR: c0054c78 CTR: c00162b0
REGS: c0473d80 TRAP: 0700 Not tainted (2.6.23-rc2-g036acf4f)
MSR: 00021032 <ME,IR,DR> CR: 42000024 XER: 00000000
TASK = c04451e0[0] 'swapper' THREAD: c0472000
GPR00: 00000001 c0473e30 c04451e0 00000178 0000002f 00600000 c0480000 0000002f
GPR08: 000186a0 c0480000 0048002f 00000400 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 40900000 00d3bbc0 00000000
GPR24: c0444000 c0480000 c0480000 c043b81c 00000001 0000002f 00024408 c044b1bc
NIP [c0054ca4] check_irq_resend+0x5c/0xc0
LR [c0054c78] check_irq_resend+0x30/0xc0
Call Trace:
[c0473e30] [c0054c78] check_irq_resend+0x30/0xc0 (unreliable)
[c0473e50] [c00547d0] enable_irq+0x84/0xa8
[c0473e60] [c0220fec] via_pmu_interrupt+0x3d8/0xac0
[c0473e90] [c0053dfc] handle_IRQ_event+0x4c/0xa0
[c0473eb0] [c0055250] handle_fasteoi_irq+0xac/0x100
[c0473ec0] [c0006528] do_IRQ+0x68/0xa8
[c0473ed0] [c000ffe8] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x88/0xd0
LR = cpu_idle+0x88/0xd0
[c0473f90] [c00090bc] cpu_idle+0xcc/0xd0 (unreliable)
[c0473fa0] [c0351f9c] rest_init+0x58/0x68
[c0473fb0] [c04189a0] start_kernel+0x260/0x274
[c0473ff0] [00003860] 0x3860
Instruction dump:
4e800421 801f0000 3d20c005 57cb052a 39295030 2f0b0400 7f804800 419e0030
3d20c048 800994e4 7c000034 5400d97e <0f000000> 2f800000 41be0048 38000001
7a883eaf62f4b943ebec738ce3b0796c67ef5d32:
------------[ cut here ]------------
Badness at kernel/irq/resend.c:70
NIP: c0054bfc LR: c0054bd0 CTR: c00162b0
REGS: effc3e60 TRAP: 0700 Not tainted (2.6.23-rc1-g6cc0258f)
MSR: 00021032 <ME,IR,DR> CR: 48000084 XER: 20000000
TASK = effc17f0[1] 'swapper' THREAD: effc2000
GPR00: 00000001 effc3f10 effc17f0 00000178 0000002f 00000000 c0470000 0000002f
GPR08: 000186a0 c0470000 0048002f 00000000 82000022 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 40900000 00d3ad48 00000000
GPR24: c0443000 c0470000 effc2000 c043ef4c 00000001 0000002f 00024008 c044a1bc
NIP [c0054bfc] check_irq_resend+0x5c/0xc0
LR [c0054bd0] check_irq_resend+0x30/0xc0
Call Trace:
[effc3f10] [c0054bd0] check_irq_resend+0x30/0xc0 (unreliable)
[effc3f30] [c0054728] enable_irq+0x84/0xa8
[effc3f40] [c0220e74] via_pmu_interrupt+0x3d8/0xac0
[effc3f70] [c0430f28] via_pmu_start+0x168/0x190
[effc3f80] [c04171e4] kernel_init+0xc8/0x284
[effc3ff0] [c0010800] kernel_thread+0x44/0x60
Instruction dump:
4e800421 801f0000 3d20c005 57cb052a 39294f88 2f0b0400 7f804800 419e0030
3d20c047 800974e4 7c000034 5400d97e <0f000000> 2f800000 41be0048 38000001
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: "Badness at kernel/irq/resend.c:70" on boot - via-pmu?
From: Linus Torvalds @ 2007-08-05 4:41 UTC (permalink / raw)
To: Paul Collins, Ingo Molnar; +Cc: paulus, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <87sl6ypsx2.fsf@briny.wgtn.ondioline.org>
On Sun, 5 Aug 2007, Paul Collins wrote:
>
> I got the message below on boot with 2.6.23-rc2 on my PowerBook.
It's a debug message, I think we need to remove it. It's trying to figure
out what goes wrong with one particular machine, and I probably shouldn't
have merged it for mainline.
Ignore it, it will be gone soon enough, and it should happen just once per
boot.
Linus
^ permalink raw reply
* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-05 7:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <1186272926.938.8.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
>>> with the DMA implementation on that architecture. There are enough cards
>>> out there that only support 32-bit DMA that this really needs to work..
>> Yes, could the PPC folks please have a look at it? Thanks.
>
> Smells like we may have a bug there. No worries though, all current PPC
> machines have an iommu that will not give out addresses above 32 bits
> anyway, but I'll double check what's up.
>
> Do you see something in dmesg when that happens ?
There was nothing in Olaf's report, except for trouble in sbp2 _after_
the failure. http://lkml.org/lkml/2007/8/1/344 (I don't have a PMac.)
--
Stefan Richter
-=====-=-=== =--- --=-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: ML403 / ALSA driver for AC97 Controller
From: Joachim Förster @ 2007-08-05 8:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40707211317q47b12a38jbe05e4d2c89767f4@mail.gmail.com>
Hi Grant,
On Sat, 2007-07-21 at 14:17 -0600, Grant Likely wrote:
> A few initial comments:
> 1. You should post this code as a patch against the kernel tree.
> Links to tarballs are not the best way to get code reviewed. Post
> your patches to both the ALSA and linuxppc-dev mailing lists.
> 2. (get this out of the way quickly) Coding standard doesn't match the
> kernel (indent w/ tabs, keep lines < 80 chars, etc). You should run
> your code through 'scripts/Lindent' in the kernel tree. That will
> sort out many of the whitespace issues.
> 3. In the same vein, c++ style comments need to be scrubbed.
> 4. Do not directly include xparameters.h in your driver. The driver
> should get it's data from the platform bus registration (of the
> of_device registration when we move to arch/powerpc).
> 5. struct 'platform_device devices[]' needs to be moved to
> arch/ppc/sysdev/virtex_devices.c
About a week ago I finished work on the last four issues and in last
days I created several patches against different kernel trees. ATM I
have three patches, against:
tag v2.6.22 (Linus)
branch master (Linus)
branch virtex-dev (your v2.6.22 based branch)
I had to make different patches, because one version didn't apply
cleanly to the other branches, due to differences in a Kconfig file e.g.
and above all in the virtex_devices.c file.
Now, my question is: Which one should I post to the mailing list? (after
testing these patches - I haven't got a chance yet to test them on real
hardware - compilation is ok).
One more thing: I made two parts, one patch adds the driver and the
other one makes the registration with the platform bus. Is this ok? (I
saw this scheme in your virtex-dev branch.)
> 6. Have you looked into the new ALSA infrastructure which separates
> Codecs from controllers (in sound/soc)? It might be a good idea to go
> that route for this driver.
Meanwhile, I had a _very_ short look into ASoC ... and I don't really
know ... My driver already uses the AC97 Layer of ALSA, so in some way
the codec is already separated from the controller. Xilinx' AC97
Controller Reference does have some very bad impact on the codec which
forced me to implement codec register shadowing ... hmmmm, I have to
look at it (ASoC) again - as soon as there is more (free)time ...
Joachim
^ permalink raw reply
* my cpu is MPC860, kernel version is 2.6.20.14, the kernel start info in the mail. why does the kernel panic?
From: poorbeyond @ 2007-08-05 10:54 UTC (permalink / raw)
To: Linux-ppc mail list
[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]
^_^=>bootm 300000
## Booting image at 00300000 ...
Image Name: Linux-2.6.20.14
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1038351 Bytes = 1014 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x01D5DB10 => set upper limit to 0x00800000
No initrd
## Transferring control to Linux (at address 00000000) ...
bootm1
Linux version 2.6.20.14 (root@localhost.localdomain) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #1 PREEMPT Sun Aug 5 18:23:18 CST 2007
I2C/SPI/SMC1 microcode patch installed.
Zone PFN ranges:
DMA 0 -> 2048
Normal 2048 -> 2048
early_node_map[1] active PFN ranges
0: 0 -> 2048
Built 1 zonelists. Total pages: 2032
Kernel command line:
PID hash table entries: 32 (order: 5, 128 bytes)
Decrementer Frequency = 187500000/60
Warning: real time clock seems stuck!
cpm_uart: console: compat mode
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)in
Memory: 5732k available (1592k kernel code, 688k data, 92k init, 0k highmem)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
------------[ cut here ]------------
Badness at 00200880 [verbose debug info unavailable]
Call Trace:
[00285E60] [00008E24] (unreliable)
[00285E90] [000EBA14]
[00285EA0] [00003D88]
[00285ED0] [000030EC]
[00285F90] [00202E98]
[00285FA0] [000022DC]
[00285FF0] [00004BA0]
NET: Registered protocol family 16
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 256 (order: 0, 4096 bytes)
TCP bind hash table entries: 128 (order: -1, 2560 bytes)
TCP: Hash tables configured (established 256 bind 128)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(4160749566.303:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
io scheduler noop registered (default)
Serial: CPM driver $Revision: 0.02 $
cpm_uart: WARNING: no UART devices found on platform bus!
cpm_uart: the driver will guess configuration, but this mode is no longer supported.
ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
LXT970: Registered new driver
LXT971: Registered new driver
fs_enet.c:v1.0 (Aug 8, 2005)
------------[ cut here ]------------
Kernel BUG at 000056a4 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT
NIP: 000056A4 LR: 00005658 CTR: 00000000
REGS: 00285e90 TRAP: 0700 Not tainted (2.6.20.14)
MSR: 00029032 <EE,ME,IR,DR> CR: 44000042 XER: 2000107F
TASK = 00282bd0[1] 'swapper' THREAD: 00284000
GPR00: 00400165 00285F40 00282BD0 0025B104 00000000 00000BDA 00306FFC 00000000
GPR08: 001C1648 00000001 00401000 00400164 00000000 40000001 02000000 00000001
GPR16: 00000000 01FFFA54 FFFFFFFF 00000000 00800000 007FFF00 01FFAA14 00285F78
GPR24: 005FF000 001C0000 00000000 0025B0E0 00001000 00252000 002FF820 0025B0C0
Call Trace:
[00285F40] [00005628] (unreliable)
[00285F70] [0020AAB0]
[00285FA0] [000022DC]
[00285FF0] [00004BA0]
Instruction dump:
38631658 48186b4d 7fc3f378 48055c05 7fe3fb78 7f44d378 48045895 48000078
801d0000 5400066e 3160ffff 7d2b0110 <0f090000> 38000400 7d20f828 7d290378
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
poorbeyond
2007-08-05
[-- Attachment #2: Type: text/html, Size: 10595 bytes --]
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Guennadi Liakhovetski @ 2007-08-05 14:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <200708050135.07753.arnd@arndb.de>
On Sun, 5 Aug 2007, Arnd Bergmann wrote:
> On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> > I tried using of_serial.c on a (PPC) MPC8241 based system, which has a
> > "16650A" compatible double UART built into the SoC. Using of_serial.c
> > causes the ports to be autoconfigured, and this fails. The loopback test
> > fails, because the MSR register on 824[15] doesn't implement the
> > UART_MSR_DCD bit. Question: what's better, teach 8250.c to handle UARTs
> > without this bit, or set the UPF_SKIP_TEST bit in of_serial.c for these
> > SOCs to skip the loopback test altogether? The latter is certainly easier
> > and affects much fewer systems, so, I'd go for that.
>
> Yes, that sounds good. Just make sure you test the "compatible" property
> in the device node for something appropriate. In of_platform_serial_probe(),
> you can then do something like
>
> if (of_device_is_compatible(ofdev, "mpc8241-serial"))
> flags |= UPF_SKIP_TEST;
That would be a possibility, but that would mean all 8241/8245 have to
adjust their .dts. Ok, there are not so many of them in the mainline now
(in fact, hardly any apart from linkstation:-)), still. Cannot we use
something already available to just check if we're running on such a CPU?
Worst case - find and parse cpu node, or maybe using some cpu_feature?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [patch 06/10] 40x decrementer fixes
From: Sergei Shtylyov @ 2007-08-05 14:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1186194537.5733.4.camel@gruick>
Hello.
Benjamin Herrenschmidt wrote:
>>> Why bother doing this?! This will only warrant you imprecise decrementer
>>>interrupts while it should be interrupting at the precise period currently (if
>>>you load PIT once)...
>>
>> I.e. the error will only accumulate. NAK.
> No, it won't since the timebase is always used as the reference.
I meant the error in the interrupt period itself (I know that this gets
accounted for) but that was a thinko anyway...
> Ben.
WBR, Sergei
^ permalink raw reply
* Re: [patch 06/10] 40x decrementer fixes
From: Sergei Shtylyov @ 2007-08-05 14:19 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1186194491.5733.2.camel@gruick>
Benjamin Herrenschmidt wrote:
>>>Allow generic_calibrate_decr to work for 40x platforms. Given that the hardware
>>>behavior is identical, this also changes the set_dec function to reload the PIT
>>>on 40x to match the behavior 44x currently has.
>> Why bother doing this?! This will only warrant you imprecise decrementer
>>interrupts while it should be interrupting at the precise period currently (if
>>you load PIT once)...
> Because that's what the kernel timekeeping code expects ? The reference
> time is the timebase and it doesn't drift.
> The DEC/PIT is commonly used to trigger any timing, such as what is done
> for lost interrupts on some platforms. Also, with dynticks, we'll most
> certainly want variable reload values as well.
That's another matter. :-)
BTW, because of that mere return in set_dec() for the 40x case I had to
write to the PIT myself in the decrementer clockevent's set_next_event()
method -- while for classic PPC I was just calling set_dec(n-1)...
> So I'm very happy to have Josh change the code that way. It makes things
> more consistent accross the board and removes confusion.
Yeah, it's OK now that's my temporary confusion has passed.
Well, it wasn't only not only mine -- the set_dec() code was suggesting
auto-reload mode, and has been obviosuly copied from <asm-ppc/time.h>, so
arch/ppc/ was using the auto-reload mode indeed.
> Ben.
WBR, Sergei
^ permalink raw reply
* Re: ML403 / ALSA driver for AC97 Controller
From: Grant Likely @ 2007-08-05 14:19 UTC (permalink / raw)
To: Joachim Förster; +Cc: linuxppc-embedded
In-Reply-To: <1186300813.5534.33.camel@localhost>
On 8/5/07, Joachim F=F6rster <mls.JOFT@gmx.de> wrote:
> tag v2.6.22 (Linus)
> branch master (Linus)
> branch virtex-dev (your v2.6.22 based branch)
>
> I had to make different patches, because one version didn't apply
> cleanly to the other branches, due to differences in a Kconfig file e.g.
> and above all in the virtex_devices.c file.
>
> Now, my question is: Which one should I post to the mailing list? (after
> testing these patches - I haven't got a chance yet to test them on real
> hardware - compilation is ok).
Post the one against master, ultimately that's where the code needs to
go. I'll take care of any conflicts with my tree, and v2.6.22 is
irrelevant (at least as far as getting things into mainline is
concerned). :-)
>
> One more thing: I made two parts, one patch adds the driver and the
> other one makes the registration with the platform bus. Is this ok? (I
> saw this scheme in your virtex-dev branch.)
Absolutely! Splitting it up into logical changes is the right way to do it=
.
> Meanwhile, I had a _very_ short look into ASoC ... and I don't really
> know ... My driver already uses the AC97 Layer of ALSA, so in some way
> the codec is already separated from the controller. Xilinx' AC97
> Controller Reference does have some very bad impact on the codec which
> forced me to implement codec register shadowing ... hmmmm, I have to
> look at it (ASoC) again - as soon as there is more (free)time ...
Heh, okay. I haven't dug into ASoC either, so I can't make too many commen=
ts.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ML403 / ALSA driver for AC97 Controller
From: Grant Likely @ 2007-08-05 14:20 UTC (permalink / raw)
To: Joachim Förster; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708050719l2cfcb507y26e39b3e067e543c@mail.gmail.com>
On 8/5/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 8/5/07, Joachim F=F6rster <mls.JOFT@gmx.de> wrote:
> > tag v2.6.22 (Linus)
> > branch master (Linus)
> > branch virtex-dev (your v2.6.22 based branch)
> >
> > I had to make different patches, because one version didn't apply
> > cleanly to the other branches, due to differences in a Kconfig file e.g=
.
> > and above all in the virtex_devices.c file.
> >
> > Now, my question is: Which one should I post to the mailing list? (afte=
r
> > testing these patches - I haven't got a chance yet to test them on real
> > hardware - compilation is ok).
>
> Post the one against master, ultimately that's where the code needs to
> go. I'll take care of any conflicts with my tree, and v2.6.22 is
> irrelevant (at least as far as getting things into mainline is
> concerned). :-)
> >
> > One more thing: I made two parts, one patch adds the driver and the
> > other one makes the registration with the platform bus. Is this ok? (I
> > saw this scheme in your virtex-dev branch.)
>
> Absolutely! Splitting it up into logical changes is the right way to do =
it.
>
> > Meanwhile, I had a _very_ short look into ASoC ... and I don't really
> > know ... My driver already uses the AC97 Layer of ALSA, so in some way
> > the codec is already separated from the controller. Xilinx' AC97
> > Controller Reference does have some very bad impact on the codec which
> > forced me to implement codec register shadowing ... hmmmm, I have to
> > look at it (ASoC) again - as soon as there is more (free)time ...
>
> Heh, okay. I haven't dug into ASoC either, so I can't make too many comm=
ents.
One more thing; make sure you CC the ALSA list when you post.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: 8250.c::autoconfig() fails loopback test on MPC824[15]
From: Arnd Bergmann @ 2007-08-05 16:41 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708051600550.4120@poirot.grange>
On Sunday 05 August 2007, Guennadi Liakhovetski wrote:
> That would be a possibility, but that would mean all 8241/8245 have to
> adjust their .dts. Ok, there are not so many of them in the mainline now
> (in fact, hardly any apart from linkstation:-)), still. Cannot we use
> something already available to just check if we're running on such a CPU?
> Worst case - find and parse cpu node, or maybe using some cpu_feature?
It's fundamentally a property of the serial controller implementation,
not of the processor, so the cpu_features are the wrong place to put
this. There should at least be a generic way to define thsi in the device
tree so that _future_ trees can just mark the port as compatible with
one that has this bug.
If you want to work around existing systems that don't mention this
in the device_tree, you could perhaps use machine_is(foo) to test
for it.
Another option altogether would be to allow the device node to
specify the linux specific serial port flags in a separate property,
like "linux,uart-port-flags" that contains the same flags that
setserial can set from user space. That would also be useful
if you want to specify UPF_MAGIC_MULTIPLIER on certain high-speed
ports, because it cannot be autoprobed.
Arnd <><
^ 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