* Re: [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Takashi Iwai @ 2011-02-21 8:37 UTC (permalink / raw)
To: Linux User #330250; +Cc: Johannes Berg, linuxppc-dev
In-Reply-To: <201102202238.28517.linuxuser330250@gmx.net>
At Sun, 20 Feb 2011 22:38:28 +0100,
Linux User #330250 wrote:
>
> Hello again!
>
> Sorry for sending the patch three times. (This is the fourth...)
>
> About the sign-off: I use the name I've been using since I started
> participating. The document $LINUX/Documentation/SubmittingPatches clearly
> states that one has to use real names. I'm breaking this rule, but I'm not
> ready to reveal my real name here or at any other place at this time. Sorry.
> If this patch is not accepted due to this, well… that's life. BTW my real
> given name is Andreas.
Well, we need really the full name for sign-off.
In general, it's not acceptable with the proper sign-off...
Takashi
>
>
> So, here's the patch, this time with a (pseudonym) sign-off:
>
> This patch makes the snd-aoa ALSA sound module support the TAS3001C codec of
> my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also work
> for the "Quicksilver 2002", since both identify as PowerMac3,5.
>
> The patch also changes a few comments to name the exact Power Mac model more
> accurately in sound/aoa/fabrics/layout.c.
>
> Signed-off-by: Andreas aka Linux User #330250 <linuxuser330250@gmx.net>
>
> ---
>
> diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
> --- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:19.000000000 +0100
> +++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 2011-02-17 18:43:26.000000000 +0100
> @@ -111,6 +111,7 @@
> MODULE_ALIAS("sound-layout-100");
>
> MODULE_ALIAS("aoa-device-id-14");
> +MODULE_ALIAS("aoa-device-id-21");
> MODULE_ALIAS("aoa-device-id-22");
> MODULE_ALIAS("aoa-device-id-35");
>
> @@ -333,14 +334,14 @@
> .connections = topaz_input,
> },
> },
> - /* Quad PowerMac (analog in, analog/digital out) */
> + /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital out) */
> { .layout_id = 68,
> .codecs[0] = {
> .name = "onyx",
> .connections = onyx_connections_nomic,
> },
> },
> - /* Quad PowerMac (digital in) */
> + /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
> { .layout_id = 69,
> .codecs[0] = {
> .name = "topaz",
> @@ -521,14 +522,21 @@
> .connections = onyx_connections_noheadphones,
> },
> },---
> - /* PowerMac3,4 */
> + /* PowerMac3,4 (Digital Audio) */
> { .device_id = 14,
> .codecs[0] = {
> .name = "tas",
> .connections = tas_connections_noline,
> },
> },
> - /* PowerMac3,6 */
> + /* PowerMac3,5 (Quicksilver) */
> + { .device_id = 21,
> + .codecs[0] = {
> + .name = "tas",
> + .connections = tas_connections_noline,
> + },
> + },
> + /* PowerMac3,6 (Mirrored Drive Doors) */
> { .device_id = 22,
> .codecs[0] = {
> .name = "tas",
> diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
> --- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-05 01:50:19.000000000 +0100
> +++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c 2011-02-17 18:44:36.000000000 +0100
> @@ -200,7 +200,7 @@
> * We probably cannot handle all device-id machines,
> * so restrict to those we do handle for now.
> */
> - if (id && (*id == 22 || *id == 14 || *id == 35)) {
> + if (id && (*id == 22 || *id == 21 || *id == 14 || *id == 35)) {
> snprintf(dev->sound.modalias, 32,
> "aoa-device-id-%d", *id);
> ok = 1;
>
^ permalink raw reply
* [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
From: Prabhakar Kushwaha @ 2011-02-21 3:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Prabhakar Kushwaha
RX_WATER_MARK sets the number of locations in Rx FIFO that can be used before
the transport layer instructs the link layer to transmit HOLDS. Note that it
can take some time for the HOLDs to get to the other end, and that in the
interim there must be enough room in the FIFO to absorb all data that could
arrive.
Update the new recommended value to 16.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch master)
drivers/ata/sata_fsl.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 895771c..29d2f29 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -186,6 +186,11 @@ enum {
COMMANDSTAT = 0x20,
};
+/* TRANSCFG (transport-layer) configuration control */
+enum {
+ TRANSCFG_RX_WATER_MARK = (1 << 4),
+};
+
/* PHY (link-layer) configuration control */
enum {
PHY_BIST_ENABLE = 0x01,
@@ -1305,6 +1310,7 @@ static int sata_fsl_probe(struct platform_device *ofdev,
struct sata_fsl_host_priv *host_priv = NULL;
int irq;
struct ata_host *host;
+ u32 temp;
struct ata_port_info pi = sata_fsl_port_info[0];
const struct ata_port_info *ppi[] = { &pi, NULL };
@@ -1319,6 +1325,12 @@ static int sata_fsl_probe(struct platform_device *ofdev,
ssr_base = hcr_base + 0x100;
csr_base = hcr_base + 0x140;
+ if (!of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc8315-sata")) {
+ temp = ioread32(csr_base + TRANSCFG);
+ temp = temp & 0xffffffe0;
+ iowrite32(temp | TRANSCFG_RX_WATER_MARK, csr_base + TRANSCFG);
+ }
+
DPRINTK("@reset i/o = 0x%x\n", ioread32(csr_base + TRANSCFG));
DPRINTK("sizeof(cmd_desc) = %d\n", sizeof(struct command_desc));
DPRINTK("sizeof(#define cmd_desc) = %d\n", SATA_FSL_CMD_DESC_SIZE);
--
1.7.3
^ permalink raw reply related
* [PATCH][v1] driver/FSL SATA:Fix wrong Device Error Register usage
From: Prabhakar Kushwaha @ 2011-02-21 3:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Ashish Kalra, Prabhakar Kushwaha
When a single device error is detected, the device under the error is indicated
by the error bit set in the DER. There is a one to one mapping between register
bit and devices on Port multiplier(PMP) i.e. bit 0 represents PMP device 0 and
bit 1 represents PMP device 1 etc.
Current implementation treats Device error register value as device number not
set of bits representing multiple device on PMP. It is changed to consider bit
level.
No need to check for each set bit as all command is going to be aborted.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Ashish Kalra <B00888@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch master)
Changes for v1: Incorporated David Laight's comment
- Single usage of ffs()
drivers/ata/sata_fsl.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index b0214d0..895771c 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1040,12 +1040,14 @@ static void sata_fsl_error_intr(struct ata_port *ap)
/* find out the offending link and qc */
if (ap->nr_pmp_links) {
+ int dev_num;
dereg = ioread32(hcr_base + DE);
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
- if (dereg < ap->nr_pmp_links) {
- link = &ap->pmp_link[dereg];
+ dev_num = ffs(dereg)-1;
+ if (dev_num < ap->nr_pmp_links) {
+ link = &ap->pmp_link[dev_num];
ehi = &link->eh_info;
qc = ata_qc_from_tag(ap, link->active_tag);
/*
--
1.7.3
^ permalink raw reply related
* Re: Per process DSCR + somefixes (try#3)
From: Alexey Kardashevskiy @ 2011-02-21 2:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4D5B62F2.3020709@au1.ibm.com>
RHEL6 problem was that it crashed when doing
echo 3 > /sys/devices/system/cpu/dscr_default
because access methods for SYSDEV_ATTR and SYSDEV_CLASS_ATTR have
different number of parameters in RHEL6. It was not correct for 2.6.36
either but the parameters number is the same for both SYSDEV_ATTR and
SYSDEV_CLASS_ATTR and 2.6.36 simply forgave me.
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-20 21:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Takashi Iwai, Johannes Berg
Hello again!
Sorry for sending the patch three times. (This is the fourth...)
About the sign-off: I use the name I've been using since I started
participating. The document $LINUX/Documentation/SubmittingPatches clearly
states that one has to use real names. I'm breaking this rule, but I'm not
ready to reveal my real name here or at any other place at this time. Sorry.
If this patch is not accepted due to this, well=E2=80=A6 that's life. BTW m=
y real
given name is Andreas.
So, here's the patch, this time with a (pseudonym) sign-off:
This patch makes the snd-aoa ALSA sound module support the TAS3001C codec o=
f=20
my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also wo=
rk=20
for the "Quicksilver 2002", since both identify as PowerMac3,5.
The patch also changes a few comments to name the exact Power Mac model mor=
e=20
accurately in sound/aoa/fabrics/layout.c.
Signed-off-by: Andreas aka Linux User #330250 <linuxuser330250@gmx.net>
=2D--
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc=
5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:=
19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 201=
1-02-17 18:43:26.000000000 +0100
@@ -111,6 +111,7 @@
MODULE_ALIAS("sound-layout-100");
=20
MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-21");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
=20
@@ -333,14 +334,14 @@
.connections =3D topaz_input,
},
},
=2D /* Quad PowerMac (analog in, analog/digital out) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital =
out) */
{ .layout_id =3D 68,
.codecs[0] =3D {
.name =3D "onyx",
.connections =3D onyx_connections_nomic,
},
},
=2D /* Quad PowerMac (digital in) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
{ .layout_id =3D 69,
.codecs[0] =3D {
.name =3D "topaz",
@@ -521,14 +522,21 @@
.connections =3D onyx_connections_noheadphones,
},
},---
=2D /* PowerMac3,4 */
+ /* PowerMac3,4 (Digital Audio) */
{ .device_id =3D 14,
.codecs[0] =3D {
.name =3D "tas",
.connections =3D tas_connections_noline,
},
},
=2D /* PowerMac3,6 */
+ /* PowerMac3,5 (Quicksilver) */
+ { .device_id =3D 21,
+ .codecs[0] =3D {
+ .name =3D "tas",
+ .connections =3D tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 (Mirrored Drive Doors) */
{ .device_id =3D 22,
.codecs[0] =3D {
.name =3D "tas",
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6=
=2E38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-0=
5 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c =
2011-02-17 18:44:36.000000000 +0100
@@ -200,7 +200,7 @@
* We probably cannot handle all device-id machines,
* so restrict to those we do handle for now.
*/
=2D if (id && (*id =3D=3D 22 || *id =3D=3D 14 || *id =
=3D=3D 35)) {
+ if (id && (*id =3D=3D 22 || *id =3D=3D 21 || *id =
=3D=3D 14 || *id =3D=3D 35)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok =3D 1;
^ permalink raw reply
* Re: Info : Using a PowerMac G5 as a server
From: Benjamin Herrenschmidt @ 2011-02-20 21:36 UTC (permalink / raw)
To: Romain Goyet; +Cc: Tony Breeds, linuxppc-dev
In-Reply-To: <1298232300.8833.20.camel@pasglop>
On Mon, 2011-02-21 at 07:05 +1100, Benjamin Herrenschmidt wrote:
> Yes, there is. We reverse engineered that a while back and somebody even
> wrote a little tool to control it, though I don't remember where that
> can be found... If necessary, we can try to dig again, the RE wasn't
> that hard.
a quick look seems to indicate that a bunch of the necessary command
definitions are present in smu.h already. Search for SMU_POWER_EVENTS
and below.
You probably need to send a SMU_CMD_POWER_EVENTS_COMMAND with
SET_POWERUP_EVENTS and SMU_PWR_WAKEUP_AC_INSERT as arguments.
You can find examples of how to send SMU commands there:
http://gate.crashing.org/~benh/smu_wink.c
Fell free to submit your resulting new utility to powerpc-utils :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Info : Using a PowerMac G5 as a server
From: Benjamin Herrenschmidt @ 2011-02-20 20:05 UTC (permalink / raw)
To: Romain Goyet; +Cc: Tony Breeds, linuxppc-dev
In-Reply-To: <AANLkTi=bkvv0E6VhHtq9vEvADhPxWfQROkfUMaBqZq4f@mail.gmail.com>
> Surprisingly, the Linux kernel does a very good job on this machine in
> terms of hardware support and stability : everything works perfectly.
> But the global OS fails pathetically in the two said points.
> Here are my findings so far, I hope it will help people in the same situation :
>
> 1/ Booting a PowerMac G5 headless
>
> This hasn't so much to do with Linux per se, but rather with Yaboot
> which seems to be the de-facto standard bootloader on the OpenFirmware
> platform.
> For some reason, at some point in the booting process, yaboot relies
> on a screen being present. If no screen is attached, it will hang. So
> much for headless booting.
> Now I've figured out several workarounds :
> -> Fake a screen by plugging in a resistor into your VGA port (or to
> your DVI port using an adapter). This sure works, but it's rather
> redneck
> -> For some reason, the part of yaboot that actually depends on the
> script is the "ofboot.b" forth script. This scripts' purpose is to
> give you an option of booting off of a CD. I really don't get it since
> OpenFirmware itself lets you boot off of a CD just by pressing "C" on
> boot. So basically if you skip ofboot.b, you're good to go. When
> installing yaboot with ybin, ybin sets the "boot-device" variable in
> OpenFirmware to point to ofboot.b. So if you point boot-device
> straight to the yaboo binary, you should be able to boot headless
> without any issue. Here are several ways to do it :
You may want to Tony Breeds. I'm not sure what happen when ofboot.b
tries to "fixup" the input/output devices, but we could certainly make
it easier for ofboot.b to be optional.
> - Go to the OpenFirmware prompt (Command-Option-O-F on boot),
> and type "setenv boot-device=hd:2,yaboot" (modify the hd:2
> accordingly), then "boot"
> - You might be able to achieve the same effect using the
> "nvram" tool straight from linux
> - I think simply removing the "magicboot" line off of
> yaboot.conf might fix it as well
>
> IOW, it _is_ possible to boot a PowerMac G5 headless on Linux without
> any hardware modification.
Yeah but I think OF gets into all kind of funny state if you try to open
the graphics device with nothing connected, and that's an OF bug, it
shouldn't happen.
> 2/ Rebooting automagically after a power failure
>
> Now this is less fun : I still don't have any solution to offer. To
> understand the situation, you should know that this has to be set in
> the power-management chip.
> Previous PowerMacs used a "PMU" chip, which was fully supported. All
> you had to do was to echo "server_mode=1" to /proc/pmu/options.
>
> Thing is, G5's use a new chip, named "SMU". And AFAIK, there's no such
> option for those machines…
Yes, there is. We reverse engineered that a while back and somebody even
wrote a little tool to control it, though I don't remember where that
can be found... If necessary, we can try to dig again, the RE wasn't
that hard.
Cheers,
Ben.
> So if anyone ever knows any element of answer on this, I'd be really
> interested !
>
> Kind regards,
>
> - Romain
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Info : Using a PowerMac G5 as a server
From: Romain Goyet @ 2011-02-20 11:59 UTC (permalink / raw)
To: linuxppc-dev
Hi everyone,
I've this PowerMac G5 machine I'd like to use as a server. It makes
perfect sense to install Linux on it for several reasons :
- OS X isn't maintained on this hardware anymore
- Those machine are still reasonnably fast. They sure aren't the
latest and greatest, but they still do a decent job.
- Support of those in other OSes (NetBSD or FreeBSD for instance) is
pretty bad (no fan control for example).
To make a decent server though, there are two things that are pretty
important IMHO :
- Being able to boot headless (w/o a screen attached)
- Being able to reboot automagically after a power failure
Surprisingly, the Linux kernel does a very good job on this machine in
terms of hardware support and stability : everything works perfectly.
But the global OS fails pathetically in the two said points.
Here are my findings so far, I hope it will help people in the same situati=
on :
1/ Booting a PowerMac G5 headless
This hasn't so much to do with Linux per se, but rather with Yaboot
which seems to be the de-facto standard bootloader on the OpenFirmware
platform.
For some reason, at some point in the booting process, yaboot relies
on a screen being present. If no screen is attached, it will hang. So
much for headless booting.
Now I've figured out several workarounds :
-> Fake a screen by plugging in a resistor into your VGA port (or to
your DVI port using an adapter). This sure works, but it's rather
redneck
-> For some reason, the part of yaboot that actually depends on the
script is the "ofboot.b" forth script. This scripts' purpose is to
give you an option of booting off of a CD. I really don't get it since
OpenFirmware itself lets you boot off of a CD just by pressing "C" on
boot. So basically if you skip ofboot.b, you're good to go. When
installing yaboot with ybin, ybin sets the "boot-device" variable in
OpenFirmware to point to ofboot.b. So if you point boot-device
straight to the yaboo binary, you should be able to boot headless
without any issue. Here are several ways to do it :
- Go to the OpenFirmware prompt (Command-Option-O-F on boot),
and type "setenv boot-device=3Dhd:2,yaboot" (modify the hd:2
accordingly), then "boot"
- You might be able to achieve the same effect using the
"nvram" tool straight from linux
- I think simply removing the "magicboot" line off of
yaboot.conf might fix it as well
IOW, it _is_ possible to boot a PowerMac G5 headless on Linux without
any hardware modification.
2/ Rebooting automagically after a power failure
Now this is less fun : I still don't have any solution to offer. To
understand the situation, you should know that this has to be set in
the power-management chip.
Previous PowerMacs used a "PMU" chip, which was fully supported. All
you had to do was to echo "server_mode=3D1" to /proc/pmu/options.
Thing is, G5's use a new chip, named "SMU". And AFAIK, there's no such
option for those machines=E2=80=A6
So if anyone ever knows any element of answer on this, I'd be really
interested !
Kind regards,
- Romain
^ permalink raw reply
* Re: [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Takashi Iwai @ 2011-02-20 9:13 UTC (permalink / raw)
To: Linux User #330250; +Cc: Johannes Berg, linuxppc-dev
In-Reply-To: <201102191553.46708.linuxuser330250@gmx.net>
At Sat, 19 Feb 2011 15:53:46 +0100,
Linux User #330250 wrote:
>
> Hello!
>
> About two years ago Johannes Berg wrote support for the PowerMac3,6 aka G4 MDD
> which I was using as a desktop computer then. Johannes wrote all the code, and
> I tested it.
>
> I now have a PowerMac3,5 – yes, an earlier model.
>
> This patch makes the snd-aoa ALSA sound module support the TAS3001C codec of
> my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also work
> for the "Quicksilver 2002", since both identify as PowerMac3,5.
>
> The patch also changes a few comments to name the exact Power Mac model more
> accurately in sound/aoa/fabrics/layout.c.
>
> This is my first contribution to the linux kernel ever, so I hope you will be
> kind to me. I am not a programmer, but adding already supported devices was a
> task even I could accomplish.
Thanks for the patch. The changes look good to me.
The only missing piece is your sign-off. Could you give it?
See $LINUX/Documentation/SubmittingPatches section "Sign your work"
for details.
Takashi
>
> Thanks,
> Andreas aka Linux User #330250
>
> ---
>
> diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
> --- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:19.000000000 +0100
> +++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 2011-02-17 18:43:26.000000000 +0100
> @@ -111,6 +111,7 @@
> MODULE_ALIAS("sound-layout-100");
>
> MODULE_ALIAS("aoa-device-id-14");
> +MODULE_ALIAS("aoa-device-id-21");
> MODULE_ALIAS("aoa-device-id-22");
> MODULE_ALIAS("aoa-device-id-35");
>
> @@ -333,14 +334,14 @@
> .connections = topaz_input,
> },
> },
> - /* Quad PowerMac (analog in, analog/digital out) */
> + /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital out) */
> { .layout_id = 68,
> .codecs[0] = {
> .name = "onyx",
> .connections = onyx_connections_nomic,
> },
> },
> - /* Quad PowerMac (digital in) */
> + /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
> { .layout_id = 69,
> .codecs[0] = {
> .name = "topaz",
> @@ -521,14 +522,21 @@
> .connections = onyx_connections_noheadphones,
> },
> },---
> - /* PowerMac3,4 */
> + /* PowerMac3,4 (Digital Audio) */
> { .device_id = 14,
> .codecs[0] = {
> .name = "tas",
> .connections = tas_connections_noline,
> },
> },
> - /* PowerMac3,6 */
> + /* PowerMac3,5 (Quicksilver) */
> + { .device_id = 21,
> + .codecs[0] = {
> + .name = "tas",
> + .connections = tas_connections_noline,
> + },
> + },
> + /* PowerMac3,6 (Mirrored Drive Doors) */
> { .device_id = 22,
> .codecs[0] = {
> .name = "tas",
> diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
> --- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-05 01:50:19.000000000 +0100
> +++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c 2011-02-17 18:44:36.000000000 +0100
> @@ -200,7 +200,7 @@
> * We probably cannot handle all device-id machines,
> * so restrict to those we do handle for now.
> */
> - if (id && (*id == 22 || *id == 14 || *id == 35)) {
> + if (id && (*id == 22 || *id == 21 || *id == 14 || *id == 35)) {
> snprintf(dev->sound.modalias, 32,
> "aoa-device-id-%d", *id);
> ok = 1;
>
^ permalink raw reply
* Re: fsl_udc_core not initializing properly?
From: Matthew L. Creech @ 2011-02-19 18:01 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20110219095253.39540a57@wker>
On Sat, Feb 19, 2011 at 3:52 AM, Anatolij Gustschin <agust@denx.de> wrote:
>
> Look at the USB node in the device tree for your board. Does it
> contain the "dr_mode" property? For USB gadget the value of this
> property should be "peripheral".
> The device tree for MPC8313 ERDB in mainline tree doesn't specify
> this property, so the host mode is the default operation mode here.
> Therefore the platform device "fsl-usb2-udc" won't be created
> while booting and since there is no appropriate platform device,
> the probing is not done. This might be the case on your board,
> too. Try with dr_mode = "peripheral"; in the usb node in your
> device tree.
>
Yes, it's there. Here's the DTS entry in case anything else sticks out:
usb@23000 {
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
phy_type = "utmi_wide";
dr_mode = "peripheral";
sleep = <&pmc 0x00300000>;
};
I think dr_mode was required in past kernel versions as well (since I
seem to recall bumping in to the problem you describe a long time ago
when we first tried to get device-mode USB working). :)
Thanks
--
Matthew L. Creech
^ permalink raw reply
* [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-19 14:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Takashi Iwai, Johannes Berg
Hello!
About two years ago Johannes Berg wrote support for the PowerMac3,6 aka G4 =
MDD=20
which I was using as a desktop computer then. Johannes wrote all the code, =
and=20
I tested it.
I now have a PowerMac3,5 =E2=80=93 yes, an earlier model.
This patch makes the snd-aoa ALSA sound module support the TAS3001C codec o=
f=20
my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also wo=
rk=20
for the "Quicksilver 2002", since both identify as PowerMac3,5.
The patch also changes a few comments to name the exact Power Mac model mor=
e=20
accurately in sound/aoa/fabrics/layout.c.
This is my first contribution to the linux kernel ever, so I hope you will =
be=20
kind to me. I am not a programmer, but adding already supported devices was=
a=20
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
=2D--
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc=
5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:=
19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 201=
1-02-17 18:43:26.000000000 +0100
@@ -111,6 +111,7 @@
MODULE_ALIAS("sound-layout-100");
=20
MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-21");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
=20
@@ -333,14 +334,14 @@
.connections =3D topaz_input,
},
},
=2D /* Quad PowerMac (analog in, analog/digital out) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital =
out) */
{ .layout_id =3D 68,
.codecs[0] =3D {
.name =3D "onyx",
.connections =3D onyx_connections_nomic,
},
},
=2D /* Quad PowerMac (digital in) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
{ .layout_id =3D 69,
.codecs[0] =3D {
.name =3D "topaz",
@@ -521,14 +522,21 @@
.connections =3D onyx_connections_noheadphones,
},
},---
=2D /* PowerMac3,4 */
+ /* PowerMac3,4 (Digital Audio) */
{ .device_id =3D 14,
.codecs[0] =3D {
.name =3D "tas",
.connections =3D tas_connections_noline,
},
},
=2D /* PowerMac3,6 */
+ /* PowerMac3,5 (Quicksilver) */
+ { .device_id =3D 21,
+ .codecs[0] =3D {
+ .name =3D "tas",
+ .connections =3D tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 (Mirrored Drive Doors) */
{ .device_id =3D 22,
.codecs[0] =3D {
.name =3D "tas",
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6=
=2E38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-0=
5 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c =
2011-02-17 18:44:36.000000000 +0100
@@ -200,7 +200,7 @@
* We probably cannot handle all device-id machines,
* so restrict to those we do handle for now.
*/
=2D if (id && (*id =3D=3D 22 || *id =3D=3D 14 || *id =
=3D=3D 35)) {
+ if (id && (*id =3D=3D 22 || *id =3D=3D 21 || *id =
=3D=3D 14 || *id =3D=3D 35)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok =3D 1;
^ permalink raw reply
* Re: fsl_udc_core not initializing properly?
From: Anatolij Gustschin @ 2011-02-19 8:52 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikaH6=8JgX6wfqLu0fCFBO0A1hHDTpw7Xb64uKS@mail.gmail.com>
Hi,
On Fri, 18 Feb 2011 17:03:12 -0500
"Matthew L. Creech" <mlcreech@gmail.com> wrote:
...
> I'm upgrading from 2.6.36 to 2.6.37 on a MPC8313 ERDB-like board. On
> the new kernel, it seems like the USB gadget driver (fsl_usb2_udc) is
> never initialized, so USB no longer works.
>
> Adding some printks to the code shows that udc_init() is being run,
> which calls platform_driver_probe(). However, fsl_udc_probe() is
> never actually called afterward. As a result, 'udc_controller' is
> left NULL, and the subsequent call to usb_gadget_probe_driver()
> returns -ENODEV.
Look at the USB node in the device tree for your board. Does it
contain the "dr_mode" property? For USB gadget the value of this
property should be "peripheral".
The device tree for MPC8313 ERDB in mainline tree doesn't specify
this property, so the host mode is the default operation mode here.
Therefore the platform device "fsl-usb2-udc" won't be created
while booting and since there is no appropriate platform device,
the probing is not done. This might be the case on your board,
too. Try with dr_mode = "peripheral"; in the usb node in your
device tree.
Anatolij
^ permalink raw reply
* fsl_udc_core not initializing properly?
From: Matthew L. Creech @ 2011-02-18 22:03 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm upgrading from 2.6.36 to 2.6.37 on a MPC8313 ERDB-like board. On
the new kernel, it seems like the USB gadget driver (fsl_usb2_udc) is
never initialized, so USB no longer works.
Adding some printks to the code shows that udc_init() is being run,
which calls platform_driver_probe(). However, fsl_udc_probe() is
never actually called afterward. As a result, 'udc_controller' is
left NULL, and the subsequent call to usb_gadget_probe_driver()
returns -ENODEV.
I'm not familiar with the USB driver model, and tracing backward
through the call chains didn't reveal much, so I was hoping someone
here would have a better idea what could've changed between 2.6.36 and
2.6.37 that broke fsl_udc_core/fsl_usb2_udc. Thanks!
--
Matthew L. Creech
^ permalink raw reply
* MPC866, Help, SPI blocked at startup
From: LEROY Christophe @ 2011-02-18 15:26 UTC (permalink / raw)
To: spi-devel-general, LinuxPPC-dev
Hello,
Sometimes (but rather often) I get SPI tasks hanging.
I get the following trace, as if both tasks where blocking each other,
or they are waiting for a third task ?
Can someone help or tell what I should look at ?
[ 240.939898] INFO: task ff000a80.spi:197 blocked for more than 120 seconds.
[ 240.946495] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 240.954416] ff000a80.spi D 00000000 0 197 2 0x00000000
[ 240.960474] Call Trace:
[ 240.962816] [c1961d20] [c009cd80] d_free+0x68/0x7c (unreliable)
[ 240.968668] [c1961de0] [c00076fc] __switch_to+0x54/0x70
[ 240.974175] [c1961df0] [c0235c8c] schedule+0x42c/0x4d4
[ 240.979058] [c1961e40] [c0235fb8] schedule_timeout+0x30/0x1cc
[ 240.984759] [c1961e80] [c0235714] wait_for_common+0xe0/0x18c
[ 240.990392] [c1961ec0] [c017a480] mpc8xxx_spi_bufs+0x3d0/0x4c8
[ 240.996365] [c1961ee0] [c017a6a8] mpc8xxx_spi_work+0x130/0x290
[ 241.001987] [c1961f50] [c0035240] worker_thread+0x14c/0x200
[ 241.007713] [c1961fb0] [c003960c] kthread+0x7c/0x80
[ 241.012755] [c1961ff0] [c000e660] kernel_thread+0x4c/0x68
[ 241.017947] INFO: task firmware/mcr300:244 blocked for more than 120
seconds.
[ 241.025131] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 241.032846] firmware/mcr3 D 00000000 0 244 2 0x00000000
[ 241.038833] Call Trace:
[ 241.041462] [c198fd90] [0000000f] 0xf (unreliable)
[ 241.046043] [c198fe50] [c00076fc] __switch_to+0x54/0x70
[ 241.051198] [c198fe60] [c0235c8c] schedule+0x42c/0x4d4
[ 241.056253] [c198feb0] [c0235fb8] schedule_timeout+0x30/0x1cc
[ 241.061957] [c198fef0] [c0235714] wait_for_common+0xe0/0x18c
[ 241.067797] [c198ff30] [c0178f7c] spi_sync+0x8c/0xb4
[ 241.072586] [c198ff70] [c0185704] fpga_fw_load+0x15c/0x3b8
[ 241.077968] [c198ff90] [c015da9c] request_firmware_work_func+0x58/0x84
[ 241.084434] [c198ffb0] [c003960c] kthread+0x7c/0x80
[ 241.089228] [c198fff0] [c000e660] kernel_thread+0x4c/0x68
Regards
C. Leroy
^ permalink raw reply
* RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
From: Kushwaha Prabhakar-B32579 @ 2011-02-18 10:17 UTC (permalink / raw)
To: David Laight, linuxppc-dev@lists.ozlabs.org; +Cc: Kalra Ashish-B00888
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC57@saturn3.aculab.com>
Thanks David for review comments!!
Please find my reply in-lined
> -----Original Message-----
> From: David Laight [mailto:David.Laight@ACULAB.COM]
> Sent: Friday, February 18, 2011 2:12 PM
> To: Kushwaha Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> Cc: Kalra Ashish-B00888
> Subject: RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register=20
> usage
>=20
>=20
> > + if ((ffs(dereg)-1) < ap->nr_pmp_links) {
> > + /* array start from 0 */
> > + link =3D &ap->pmp_link[ffs(dereg)-1];
>=20
> I'd only call ffs() once - it could be a slow library function.
This function is called during error handling. So it won't matter.=20
Anyway, I will update the patch for singe usage of ffs().=20
> Any comment should note that ffs() returns 0 when no bits are set -=20
> rather than anything about array indexes.
>=20
sata_fsl_error_intr() is called during device error.
The mentioned scenario will never comes. It can be observed via code:-
if (cereg) { --> cereg is set on command error. Means there is at least =
1 device present.
abort =3D 1;
---
---
---
/* find out the offending link and qc */
if (ap->nr_pmp_links) { --> if Port multiplier=20
---
---
if ((ffs(dereg)-1) < ap->nr_pmp_links) {
---
---
} else { --> Single device
dereg =3D ioread32(hcr_base + DE);
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
^ permalink raw reply
* RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
From: Kushwaha Prabhakar-B32579 @ 2011-02-18 9:59 UTC (permalink / raw)
To: David Laight; +Cc: Kalra Ashish-B00888, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC57@saturn3.aculab.com>
Thanks David for review comments!!
Please find my reply in-lined
> -----Original Message-----
> From: David Laight [mailto:David.Laight@ACULAB.COM]
> Sent: Friday, February 18, 2011 2:12 PM
> To: Kushwaha Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> Cc: Kalra Ashish-B00888
> Subject: RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register
> usage
>=20
>=20
> > + if ((ffs(dereg)-1) < ap->nr_pmp_links) {
> > + /* array start from 0 */
> > + link =3D &ap->pmp_link[ffs(dereg)-1];
>=20
> I'd only call ffs() once - it could be a slow library function.
This function is called during error handling. So it won't matter.=20
Anyway, I will update the patch for singe usage of ffs().=20
> Any comment should note that ffs() returns 0 when no bits are set -
> rather than anything about array indexes.
>=20
sata_fsl_error_intr() is called during device error.
The mentioned scenario will never comes. It can be observed via code:-
if (cereg) { --> cereg is set on command error. Means there is at least =
1 device present.
abort =3D 1;
---
---
---
/* find out the offending link and qc */
if (ap->nr_pmp_links) { --> if Port multiplier=20
---
---
if ((ffs(dereg)-1) < ap->nr_pmp_links) {
---
---
} else { --> Single device
dereg =3D ioread32(hcr_base + DE);
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
^ permalink raw reply
* RE: [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
From: David Laight @ 2011-02-18 8:41 UTC (permalink / raw)
To: Prabhakar Kushwaha, linuxppc-dev; +Cc: Ashish Kalra
In-Reply-To: <1298007298-12511-1-git-send-email-prabhakar@freescale.com>
=20
> + if ((ffs(dereg)-1) < ap->nr_pmp_links) {
> + /* array start from 0 */
> + link =3D &ap->pmp_link[ffs(dereg)-1];
I'd only call ffs() once - it could be a slow library function.
Any comment should note that ffs() returns 0 when no bits
are set - rather than anything about array indexes.
David
^ permalink raw reply
* [PATCH] driver/FSL SATA:Fix wrong Device Error Register usage
From: Prabhakar Kushwaha @ 2011-02-18 5:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ashish Kalra, Prabhakar Kushwaha
When a single device error is detected, the device under the error is indicated
by the error bit set in the DER. There is a one to one mapping between register
bit and devices on Port multiplier(PMP) i.e. bit 0 represents PMP device 0 and
bit 1 represents PMP device 1 etc.
Current implementation treats Device error register value as device number not
set of bits representing multiple device on PMP. It is changed to consider bit
level.
No need to check for each set bit as all command is going to be aborted.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Ashish Kalra <B00888@freescale.com>
---
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch master)
drivers/ata/sata_fsl.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 2546f38..8ad335f 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1047,8 +1047,9 @@ static void sata_fsl_error_intr(struct ata_port *ap)
iowrite32(dereg, hcr_base + DE);
iowrite32(cereg, hcr_base + CE);
- if (dereg < ap->nr_pmp_links) {
- link = &ap->pmp_link[dereg];
+ if ((ffs(dereg)-1) < ap->nr_pmp_links) {
+ /* array start from 0 */
+ link = &ap->pmp_link[ffs(dereg)-1];
ehi = &link->eh_info;
qc = ata_qc_from_tag(ap, link->active_tag);
/*
--
1.7.3
^ permalink raw reply related
* [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-17 20:53 UTC (permalink / raw)
To: linuxppc-dev
Hello!
About two years ago Johannes Berg wrote support for the PowerMac3,6 aka G4 =
MDD=20
which I was using as a desktop computer then. Johannes wrote all the code, =
and=20
I tested it.
I now have a PowerMac3,5 =E2=80=93 yes, an earlier model.
This patch makes the snd-aoa ALSA sound module support the TAS3001C codec o=
f=20
my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also wo=
rk=20
for the "Quicksilver 2002", since both identify as PowerMac3,5.
The patch also changes a few comments to name the exact Power Mac model mor=
e=20
accurately in sound/aoa/fabrics/layout.c.
This is my first contribution to the linux kernel ever, so I hope you will =
be=20
kind to me. I am not a programmer, but adding already supported devices was=
a=20
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
=2D--
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc=
5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:=
19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 201=
1-02-17 18:43:26.000000000 +0100
@@ -111,6 +111,7 @@
MODULE_ALIAS("sound-layout-100");
=20
MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-21");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
=20
@@ -333,14 +334,14 @@
.connections =3D topaz_input,
},
},
=2D /* Quad PowerMac (analog in, analog/digital out) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital =
out) */
{ .layout_id =3D 68,
.codecs[0] =3D {
.name =3D "onyx",
.connections =3D onyx_connections_nomic,
},
},
=2D /* Quad PowerMac (digital in) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
{ .layout_id =3D 69,
.codecs[0] =3D {
.name =3D "topaz",
@@ -521,14 +522,21 @@
.connections =3D onyx_connections_noheadphones,
},
},---
=2D /* PowerMac3,4 */
+ /* PowerMac3,4 (Digital Audio) */
{ .device_id =3D 14,
.codecs[0] =3D {
.name =3D "tas",
.connections =3D tas_connections_noline,
},
},
=2D /* PowerMac3,6 */
+ /* PowerMac3,5 (Quicksilver) */
+ { .device_id =3D 21,
+ .codecs[0] =3D {
+ .name =3D "tas",
+ .connections =3D tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 (Mirrored Drive Doors) */
{ .device_id =3D 22,
.codecs[0] =3D {
.name =3D "tas",
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6=
=2E38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
=2D-- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-0=
5 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c =
2011-02-17 18:44:36.000000000 +0100
@@ -200,7 +200,7 @@
* We probably cannot handle all device-id machines,
* so restrict to those we do handle for now.
*/
=2D if (id && (*id =3D=3D 22 || *id =3D=3D 14 || *id =
=3D=3D 35)) {
+ if (id && (*id =3D=3D 22 || *id =3D=3D 21 || *id =
=3D=3D 14 || *id =3D=3D 35)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok =3D 1;
^ permalink raw reply
* [PATCH] Add support for PowerMac3,5 in snd-aoa ALSA sound module
From: Linux User #330250 @ 2011-02-17 20:17 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: Text/Plain, Size: 831 bytes --]
Hello!
About two years ago Johannes Berg wrote support for the PowerMac3,6 aka G4 MDD
which I was using as a desktop computer then. Johannes wrote all the code, and
I tested it.
I now have a PowerMac3,5 – yes, an earlier model.
This patch makes the snd-aoa ALSA sound module support the TAS3001C codec of
my Apple Power Mac G4 "Quicksilver" (2001 model). I suppose it will also work
for the "Quicksilver 2002", since both identify as PowerMac3,5.
The patch also changes a few comments to name the exact Power Mac model more
accurately in sound/aoa/fabrics/layout.c.
This is my first contribution to the linux kernel ever, so I hope you will be
kind to me. I am not a programmer, but adding already supported devices was a
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
[-- Attachment #2: Quicksilver-aoa.patch --]
[-- Type: text/x-patch, Size: 2692 bytes --]
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c
--- linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c 2011-01-05 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/fabrics/layout.c 2011-02-17 18:43:26.000000000 +0100
@@ -111,6 +111,7 @@
MODULE_ALIAS("sound-layout-100");
MODULE_ALIAS("aoa-device-id-14");
+MODULE_ALIAS("aoa-device-id-21");
MODULE_ALIAS("aoa-device-id-22");
MODULE_ALIAS("aoa-device-id-35");
@@ -333,14 +334,14 @@
.connections = topaz_input,
},
},
- /* Quad PowerMac (analog in, analog/digital out) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (analog in, analog/digital out) */
{ .layout_id = 68,
.codecs[0] = {
.name = "onyx",
.connections = onyx_connections_nomic,
},
},
- /* Quad PowerMac (digital in) */
+ /* PowerMac11,2 (G5 Dual-Core and Quad) (digital in) */
{ .layout_id = 69,
.codecs[0] = {
.name = "topaz",
@@ -521,14 +522,21 @@
.connections = onyx_connections_noheadphones,
},
},
- /* PowerMac3,4 */
+ /* PowerMac3,4 (Digital Audio) */
{ .device_id = 14,
.codecs[0] = {
.name = "tas",
.connections = tas_connections_noline,
},
},
- /* PowerMac3,6 */
+ /* PowerMac3,5 (Quicksilver) */
+ { .device_id = 21,
+ .codecs[0] = {
+ .name = "tas",
+ .connections = tas_connections_noline,
+ },
+ },
+ /* PowerMac3,6 (Mirrored Drive Doors) */
{ .device_id = 22,
.codecs[0] = {
.name = "tas",
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c
--- linux-2.6.38-rc5-git2/sound/aoa/soundbus/i2sbus/core.c 2011-01-05 01:50:19.000000000 +0100
+++ linux-2.6.38-rc5-git2-aoa-PowerMac3,5/sound/aoa/soundbus/i2sbus/core.c 2011-02-17 18:44:36.000000000 +0100
@@ -200,7 +200,7 @@
* We probably cannot handle all device-id machines,
* so restrict to those we do handle for now.
*/
- if (id && (*id == 22 || *id == 14 || *id == 35)) {
+ if (id && (*id == 22 || *id == 21 || *id == 14 || *id == 35)) {
snprintf(dev->sound.modalias, 32,
"aoa-device-id-%d", *id);
ok = 1;
^ permalink raw reply
* Re: [PATCH OF 07/14] of: move of_irq_map_pci() into generic code
From: Michal Simek @ 2011-02-17 7:49 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss, x86,
linux-kernel, sodaville, Sebastian Andrzej Siewior, linuxppc-dev,
Sebastian Andrzej Siewior
In-Reply-To: <AANLkTimE=mB_yWsOeD3zw+b4cHFx591h-605tK4yWAJr@mail.gmail.com>
Grant Likely wrote:
> On Sun, Jan 23, 2011 at 9:28 PM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>>
>> There is a tiny difference between PPC32 and PPC64. Microblaze uses the
>> PPC32 variant.
>>
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
> I've got this one in my devicetree/next branch which is pulled into
> linux-next. I've not received an ack from Ben yet. Michal, is this
> okay by you?
yep. No problem. I don't have pci hw for testing but compilation is fine.
If you like:
Acked-by: Michal Simek <monstr@monstr.eu>
Thanks,
Michal
>
> http://git.secretlab.ca/?p=linux-2.6.git;a=commit;h=04bea68b2f0eeebb089ecc67b618795925268b4a
>
> g.
>
>> ---
>> arch/microblaze/include/asm/pci-bridge.h | 12 ++++
>> arch/microblaze/include/asm/prom.h | 15 -----
>> arch/microblaze/kernel/prom_parse.c | 77 ---------------------------
>> arch/microblaze/pci/pci-common.c | 1 +
>> arch/powerpc/include/asm/pci-bridge.h | 10 ++++
>> arch/powerpc/include/asm/prom.h | 15 -----
>> arch/powerpc/kernel/pci-common.c | 1 +
>> arch/powerpc/kernel/prom_parse.c | 84 ------------------------------
>> drivers/of/Kconfig | 6 ++
>> drivers/of/Makefile | 1 +
>> drivers/of/of_pci.c | 80 ++++++++++++++++++++++++++++
>> include/linux/of_pci.h | 20 +++++++
>> 12 files changed, 131 insertions(+), 191 deletions(-)
>> create mode 100644 drivers/of/of_pci.c
>> create mode 100644 include/linux/of_pci.h
>>
>> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/include/asm/pci-bridge.h
>> index 0c68764..c2a40a4 100644
>> --- a/arch/microblaze/include/asm/pci-bridge.h
>> +++ b/arch/microblaze/include/asm/pci-bridge.h
>> @@ -104,11 +104,22 @@ struct pci_controller {
>> int global_number; /* PCI domain number */
>> };
>>
>> +#ifdef CONFIG_PCI
>> static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
>> {
>> return bus->sysdata;
>> }
>>
>> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
>> +{
>> + struct pci_controller *host;
>> +
>> + if (bus->self)
>> + return pci_device_to_OF_node(bus->self);
>> + host = pci_bus_to_host(bus);
>> + return host ? host->dn : NULL;
>> +}
>> +
>> static inline int isa_vaddr_is_ioport(void __iomem *address)
>> {
>> /* No specific ISA handling on ppc32 at this stage, it
>> @@ -116,6 +127,7 @@ static inline int isa_vaddr_is_ioport(void __iomem *address)
>> */
>> return 0;
>> }
>> +#endif
>>
>> /* These are used for config access before all the PCI probing
>> has been done. */
>> diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h
>> index 2e72af0..d0890d3 100644
>> --- a/arch/microblaze/include/asm/prom.h
>> +++ b/arch/microblaze/include/asm/prom.h
>> @@ -64,21 +64,6 @@ extern void kdump_move_device_tree(void);
>> /* CPU OF node matching */
>> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
>>
>> -/**
>> - * of_irq_map_pci - Resolve the interrupt for a PCI device
>> - * @pdev: the device whose interrupt is to be resolved
>> - * @out_irq: structure of_irq filled by this function
>> - *
>> - * This function resolves the PCI interrupt for a given PCI device. If a
>> - * device-node exists for a given pci_dev, it will use normal OF tree
>> - * walking. If not, it will implement standard swizzling and walk up the
>> - * PCI tree until an device-node is found, at which point it will finish
>> - * resolving using the OF tree walking.
>> - */
>> -struct pci_dev;
>> -struct of_irq;
>> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
>> -
>> #endif /* __ASSEMBLY__ */
>> #endif /* __KERNEL__ */
>>
>> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel/prom_parse.c
>> index 9ae24f4..47187cc 100644
>> --- a/arch/microblaze/kernel/prom_parse.c
>> +++ b/arch/microblaze/kernel/prom_parse.c
>> @@ -2,88 +2,11 @@
>>
>> #include <linux/kernel.h>
>> #include <linux/string.h>
>> -#include <linux/pci_regs.h>
>> #include <linux/module.h>
>> #include <linux/ioport.h>
>> #include <linux/etherdevice.h>
>> #include <linux/of_address.h>
>> #include <asm/prom.h>
>> -#include <asm/pci-bridge.h>
>> -
>> -#ifdef CONFIG_PCI
>> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
>> -{
>> - struct device_node *dn, *ppnode;
>> - struct pci_dev *ppdev;
>> - u32 lspec;
>> - u32 laddr[3];
>> - u8 pin;
>> - int rc;
>> -
>> - /* Check if we have a device node, if yes, fallback to standard OF
>> - * parsing
>> - */
>> - dn = pci_device_to_OF_node(pdev);
>> - if (dn)
>> - return of_irq_map_one(dn, 0, out_irq);
>> -
>> - /* Ok, we don't, time to have fun. Let's start by building up an
>> - * interrupt spec. we assume #interrupt-cells is 1, which is standard
>> - * for PCI. If you do different, then don't use that routine.
>> - */
>> - rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>> - if (rc != 0)
>> - return rc;
>> - /* No pin, exit */
>> - if (pin == 0)
>> - return -ENODEV;
>> -
>> - /* Now we walk up the PCI tree */
>> - lspec = pin;
>> - for (;;) {
>> - /* Get the pci_dev of our parent */
>> - ppdev = pdev->bus->self;
>> -
>> - /* Ouch, it's a host bridge... */
>> - if (ppdev == NULL) {
>> - struct pci_controller *host;
>> - host = pci_bus_to_host(pdev->bus);
>> - ppnode = host ? host->dn : NULL;
>> - /* No node for host bridge ? give up */
>> - if (ppnode == NULL)
>> - return -EINVAL;
>> - } else
>> - /* We found a P2P bridge, check if it has a node */
>> - ppnode = pci_device_to_OF_node(ppdev);
>> -
>> - /* Ok, we have found a parent with a device-node, hand over to
>> - * the OF parsing code.
>> - * We build a unit address from the linux device to be used for
>> - * resolution. Note that we use the linux bus number which may
>> - * not match your firmware bus numbering.
>> - * Fortunately, in most cases, interrupt-map-mask doesn't
>> - * include the bus number as part of the matching.
>> - * You should still be careful about that though if you intend
>> - * to rely on this function (you ship a firmware that doesn't
>> - * create device nodes for all PCI devices).
>> - */
>> - if (ppnode)
>> - break;
>> -
>> - /* We can only get here if we hit a P2P bridge with no node,
>> - * let's do standard swizzling and try again
>> - */
>> - lspec = pci_swizzle_interrupt_pin(pdev, lspec);
>> - pdev = ppdev;
>> - }
>> -
>> - laddr[0] = (pdev->bus->number << 16)
>> - | (pdev->devfn << 8);
>> - laddr[1] = laddr[2] = 0;
>> - return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
>> -}
>> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
>> -#endif /* CONFIG_PCI */
>>
>> void of_parse_dma_window(struct device_node *dn, const void *dma_window_prop,
>> unsigned long *busno, unsigned long *phys, unsigned long *size)
>> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
>> index e363615..1e01a12 100644
>> --- a/arch/microblaze/pci/pci-common.c
>> +++ b/arch/microblaze/pci/pci-common.c
>> @@ -29,6 +29,7 @@
>> #include <linux/slab.h>
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>> +#include <linux/of_pci.h>
>>
>> #include <asm/processor.h>
>> #include <asm/io.h>
>> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
>> index 51e9e6f..edeb80f 100644
>> --- a/arch/powerpc/include/asm/pci-bridge.h
>> +++ b/arch/powerpc/include/asm/pci-bridge.h
>> @@ -171,6 +171,16 @@ static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
>> return bus->sysdata;
>> }
>>
>> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
>> +{
>> + struct pci_controller *host;
>> +
>> + if (bus->self)
>> + return pci_device_to_OF_node(bus->self);
>> + host = pci_bus_to_host(bus);
>> + return host ? host->dn : NULL;
>> +}
>> +
>> static inline int isa_vaddr_is_ioport(void __iomem *address)
>> {
>> /* No specific ISA handling on ppc32 at this stage, it
>> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
>> index d727575..c189aa5 100644
>> --- a/arch/powerpc/include/asm/prom.h
>> +++ b/arch/powerpc/include/asm/prom.h
>> @@ -70,21 +70,6 @@ static inline int of_node_to_nid(struct device_node *device) { return 0; }
>> #endif
>> #define of_node_to_nid of_node_to_nid
>>
>> -/**
>> - * of_irq_map_pci - Resolve the interrupt for a PCI device
>> - * @pdev: the device whose interrupt is to be resolved
>> - * @out_irq: structure of_irq filled by this function
>> - *
>> - * This function resolves the PCI interrupt for a given PCI device. If a
>> - * device-node exists for a given pci_dev, it will use normal OF tree
>> - * walking. If not, it will implement standard swizzling and walk up the
>> - * PCI tree until an device-node is found, at which point it will finish
>> - * resolving using the OF tree walking.
>> - */
>> -struct pci_dev;
>> -struct of_irq;
>> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
>> -
>> extern void of_instantiate_rtc(void);
>>
>> /* These includes are put at the bottom because they may contain things
>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>> index 10a44e6..eb341be 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -22,6 +22,7 @@
>> #include <linux/init.h>
>> #include <linux/bootmem.h>
>> #include <linux/of_address.h>
>> +#include <linux/of_pci.h>
>> #include <linux/mm.h>
>> #include <linux/list.h>
>> #include <linux/syscalls.h>
>> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
>> index c2b7a07..47187cc 100644
>> --- a/arch/powerpc/kernel/prom_parse.c
>> +++ b/arch/powerpc/kernel/prom_parse.c
>> @@ -2,95 +2,11 @@
>>
>> #include <linux/kernel.h>
>> #include <linux/string.h>
>> -#include <linux/pci_regs.h>
>> #include <linux/module.h>
>> #include <linux/ioport.h>
>> #include <linux/etherdevice.h>
>> #include <linux/of_address.h>
>> #include <asm/prom.h>
>> -#include <asm/pci-bridge.h>
>> -
>> -#ifdef CONFIG_PCI
>> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
>> -{
>> - struct device_node *dn, *ppnode;
>> - struct pci_dev *ppdev;
>> - u32 lspec;
>> - u32 laddr[3];
>> - u8 pin;
>> - int rc;
>> -
>> - /* Check if we have a device node, if yes, fallback to standard OF
>> - * parsing
>> - */
>> - dn = pci_device_to_OF_node(pdev);
>> - if (dn) {
>> - rc = of_irq_map_one(dn, 0, out_irq);
>> - if (!rc)
>> - return rc;
>> - }
>> -
>> - /* Ok, we don't, time to have fun. Let's start by building up an
>> - * interrupt spec. we assume #interrupt-cells is 1, which is standard
>> - * for PCI. If you do different, then don't use that routine.
>> - */
>> - rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>> - if (rc != 0)
>> - return rc;
>> - /* No pin, exit */
>> - if (pin == 0)
>> - return -ENODEV;
>> -
>> - /* Now we walk up the PCI tree */
>> - lspec = pin;
>> - for (;;) {
>> - /* Get the pci_dev of our parent */
>> - ppdev = pdev->bus->self;
>> -
>> - /* Ouch, it's a host bridge... */
>> - if (ppdev == NULL) {
>> -#ifdef CONFIG_PPC64
>> - ppnode = pci_bus_to_OF_node(pdev->bus);
>> -#else
>> - struct pci_controller *host;
>> - host = pci_bus_to_host(pdev->bus);
>> - ppnode = host ? host->dn : NULL;
>> -#endif
>> - /* No node for host bridge ? give up */
>> - if (ppnode == NULL)
>> - return -EINVAL;
>> - } else
>> - /* We found a P2P bridge, check if it has a node */
>> - ppnode = pci_device_to_OF_node(ppdev);
>> -
>> - /* Ok, we have found a parent with a device-node, hand over to
>> - * the OF parsing code.
>> - * We build a unit address from the linux device to be used for
>> - * resolution. Note that we use the linux bus number which may
>> - * not match your firmware bus numbering.
>> - * Fortunately, in most cases, interrupt-map-mask doesn't include
>> - * the bus number as part of the matching.
>> - * You should still be careful about that though if you intend
>> - * to rely on this function (you ship a firmware that doesn't
>> - * create device nodes for all PCI devices).
>> - */
>> - if (ppnode)
>> - break;
>> -
>> - /* We can only get here if we hit a P2P bridge with no node,
>> - * let's do standard swizzling and try again
>> - */
>> - lspec = pci_swizzle_interrupt_pin(pdev, lspec);
>> - pdev = ppdev;
>> - }
>> -
>> - laddr[0] = (pdev->bus->number << 16)
>> - | (pdev->devfn << 8);
>> - laddr[1] = laddr[2] = 0;
>> - return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
>> -}
>> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
>> -#endif /* CONFIG_PCI */
>>
>> void of_parse_dma_window(struct device_node *dn, const void *dma_window_prop,
>> unsigned long *busno, unsigned long *phys, unsigned long *size)
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index 3c6e100..c71cff1 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -69,4 +69,10 @@ config OF_MDIO
>> help
>> OpenFirmware MDIO bus (Ethernet PHY) accessors
>>
>> +config OF_PCI
>> + def_tristate PCI
>> + depends on PCI && !SPARC
>> + help
>> + OpenFirmware PCI bus accessors
>> +
>> endmenu # OF
>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>> index 3ab21a0..f7861ed 100644
>> --- a/drivers/of/Makefile
>> +++ b/drivers/of/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_I2C) += of_i2c.o
>> obj-$(CONFIG_OF_NET) += of_net.o
>> obj-$(CONFIG_OF_SPI) += of_spi.o
>> obj-$(CONFIG_OF_MDIO) += of_mdio.o
>> +obj-$(CONFIG_OF_PCI) += of_pci.o
>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>> new file mode 100644
>> index 0000000..dd862d2
>> --- /dev/null
>> +++ b/drivers/of/of_pci.c
>> @@ -0,0 +1,80 @@
>> +#include <linux/kernel.h>
>> +#include <linux/of_pci.h>
>> +#include <asm/prom.h>
>> +
>> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
>> +{
>> + struct device_node *dn, *ppnode;
>> + struct pci_dev *ppdev;
>> + u32 lspec;
>> + __be32 lspec_be;
>> + __be32 laddr[3];
>> + u8 pin;
>> + int rc;
>> +
>> + /* Check if we have a device node, if yes, fallback to standard OF
>> + * parsing
>> + */
>> + dn = pci_device_to_OF_node(pdev);
>> + if (dn) {
>> + rc = of_irq_map_one(dn, 0, out_irq);
>> + if (!rc)
>> + return rc;
>> + }
>> +
>> + /* Ok, we don't, time to have fun. Let's start by building up an
>> + * interrupt spec. we assume #interrupt-cells is 1, which is standard
>> + * for PCI. If you do different, then don't use that routine.
>> + */
>> + rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>> + if (rc != 0)
>> + return rc;
>> + /* No pin, exit */
>> + if (pin == 0)
>> + return -ENODEV;
>> +
>> + /* Now we walk up the PCI tree */
>> + lspec = pin;
>> + for (;;) {
>> + /* Get the pci_dev of our parent */
>> + ppdev = pdev->bus->self;
>> +
>> + /* Ouch, it's a host bridge... */
>> + if (ppdev == NULL) {
>> + ppnode = pci_bus_to_OF_node(pdev->bus);
>> +
>> + /* No node for host bridge ? give up */
>> + if (ppnode == NULL)
>> + return -EINVAL;
>> + } else {
>> + /* We found a P2P bridge, check if it has a node */
>> + ppnode = pci_device_to_OF_node(ppdev);
>> + }
>> +
>> + /* Ok, we have found a parent with a device-node, hand over to
>> + * the OF parsing code.
>> + * We build a unit address from the linux device to be used for
>> + * resolution. Note that we use the linux bus number which may
>> + * not match your firmware bus numbering.
>> + * Fortunately, in most cases, interrupt-map-mask doesn't
>> + * include the bus number as part of the matching.
>> + * You should still be careful about that though if you intend
>> + * to rely on this function (you ship a firmware that doesn't
>> + * create device nodes for all PCI devices).
>> + */
>> + if (ppnode)
>> + break;
>> +
>> + /* We can only get here if we hit a P2P bridge with no node,
>> + * let's do standard swizzling and try again
>> + */
>> + lspec = pci_swizzle_interrupt_pin(pdev, lspec);
>> + pdev = ppdev;
>> + }
>> +
>> + lspec_be = cpu_to_be32(lspec);
>> + laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
>> + laddr[1] = laddr[2] = cpu_to_be32(0);
>> + return of_irq_map_raw(ppnode, &lspec_be, 1, laddr, out_irq);
>> +}
>> +EXPORT_SYMBOL_GPL(of_irq_map_pci);
>> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
>> new file mode 100644
>> index 0000000..9b0ba67
>> --- /dev/null
>> +++ b/include/linux/of_pci.h
>> @@ -0,0 +1,20 @@
>> +#ifndef __OF_PCI_H
>> +#define __OF_PCI_H
>> +
>> +#include <linux/pci.h>
>> +
>> +/**
>> + * of_irq_map_pci - Resolve the interrupt for a PCI device
>> + * @pdev: the device whose interrupt is to be resolved
>> + * @out_irq: structure of_irq filled by this function
>> + *
>> + * This function resolves the PCI interrupt for a given PCI device. If a
>> + * device-node exists for a given pci_dev, it will use normal OF tree
>> + * walking. If not, it will implement standard swizzling and walk up the
>> + * PCI tree until an device-node is found, at which point it will finish
>> + * resolving using the OF tree walking.
>> + */
>> +struct pci_dev;
>> +struct of_irq;
>> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
>> +#endif
>> --
>> 1.7.3.2
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>
>
>
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [RFC] Inter-processor Mailboxes Drivers
From: Linus Walleij @ 2011-02-16 21:54 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: Inge, Meador, openmcapi-dev, Hiroshi DOYU, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FAADB@na3-mail.mgc.mentorg.com>
2011/2/15 Blanchard, Hollis <Hollis_Blanchard@mentor.com>:
> OpenMCAPI (http://openmcapi.org) implements the MCAPI specification,
> which is a simple application-level communication API that uses shared
> memory. The API could be layered over any protocol, but was more or less
> designed for simple shared-memory systems, e.g. fixed topology, no
> retransmission, etc.
Cool...
> Currently, we implement almost all of this as a shared library, plus a
> very small kernel driver. The only requirements on the kernel are to
> allow userspace to map the shared memory area, and provide an IPI
> mechanism (and allow the process to sleep while waiting). Applications
> sync with each other using normal atomic memory operations.
Can't this real small kernel driver take care of the mailbox
business as well?
It seems a bit backward if you have say /dev/mcapi0, /dev/mcapi1
etc (or however you expose this to userspace) and /dev/mailbox0
/dev/mailbox1 etc on top of that. One device node per communication
channel instead of this would certainly be nicer? Then you would
have some ioctl() on the /dev/mcapi0 etc node to trigger the
transport and need not worry that it's a mailbox doing the sync.
What I'm after is that whatever datapath you have should include
the control mechanism, now it's like you're opening two interfaces
into the kernel, one for mapping in data pages, one for synchronizing
the transfers, or am I getting things wrong?
I think nominally all mailbox users would be in-kernel like the
MCAPI driver, so they don't need a userspace interface, to me
it feels like say /dev/mutex0, /dev/mutex1 for some other
shared memory opening into the kernel (such as the framebuffer),
and that would look a bit funny.
> I'll add that we haven't done serious optimization yet, but the numbers
> we do have seem reasonable. What are the "efficiency" issues you're
> worried about?
For huge data flows I think you may get into trouble, needing things
like queueing, descriptor pools etc. But if you're convinced this will
work, do go ahead.
Linus Walleij
^ permalink raw reply
* Re: [PATCH OF 07/14] of: move of_irq_map_pci() into generic code
From: Grant Likely @ 2011-02-16 21:53 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss, x86,
linux-kernel, sodaville, Sebastian Andrzej Siewior, linuxppc-dev
In-Reply-To: <1295843342-1122-8-git-send-email-bigeasy@linutronix.de>
On Sun, Jan 23, 2011 at 9:28 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
> There is a tiny difference between PPC32 and PPC64. Microblaze uses the
> PPC32 variant.
>
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
I've got this one in my devicetree/next branch which is pulled into
linux-next. I've not received an ack from Ben yet. Michal, is this
okay by you?
http://git.secretlab.ca/?p=3Dlinux-2.6.git;a=3Dcommit;h=3D04bea68b2f0eeebb0=
89ecc67b618795925268b4a
g.
> ---
> =A0arch/microblaze/include/asm/pci-bridge.h | =A0 12 ++++
> =A0arch/microblaze/include/asm/prom.h =A0 =A0 =A0 | =A0 15 -----
> =A0arch/microblaze/kernel/prom_parse.c =A0 =A0 =A0| =A0 77 --------------=
-------------
> =A0arch/microblaze/pci/pci-common.c =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/include/asm/pci-bridge.h =A0 =A0| =A0 10 ++++
> =A0arch/powerpc/include/asm/prom.h =A0 =A0 =A0 =A0 =A0| =A0 15 -----
> =A0arch/powerpc/kernel/pci-common.c =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/kernel/prom_parse.c =A0 =A0 =A0 =A0 | =A0 84 ------------=
------------------
> =A0drivers/of/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =
=A06 ++
> =A0drivers/of/Makefile =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =
=A01 +
> =A0drivers/of/of_pci.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 8=
0 ++++++++++++++++++++++++++++
> =A0include/linux/of_pci.h =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 20 ++=
+++++
> =A012 files changed, 131 insertions(+), 191 deletions(-)
> =A0create mode 100644 drivers/of/of_pci.c
> =A0create mode 100644 include/linux/of_pci.h
>
> diff --git a/arch/microblaze/include/asm/pci-bridge.h b/arch/microblaze/i=
nclude/asm/pci-bridge.h
> index 0c68764..c2a40a4 100644
> --- a/arch/microblaze/include/asm/pci-bridge.h
> +++ b/arch/microblaze/include/asm/pci-bridge.h
> @@ -104,11 +104,22 @@ struct pci_controller {
> =A0 =A0 =A0 =A0int global_number; =A0 =A0 =A0/* PCI domain number */
> =A0};
>
> +#ifdef CONFIG_PCI
> =A0static inline struct pci_controller *pci_bus_to_host(const struct pci_=
bus *bus)
> =A0{
> =A0 =A0 =A0 =A0return bus->sysdata;
> =A0}
>
> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus=
)
> +{
> + =A0 =A0 =A0 struct pci_controller *host;
> +
> + =A0 =A0 =A0 if (bus->self)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return pci_device_to_OF_node(bus->self);
> + =A0 =A0 =A0 host =3D pci_bus_to_host(bus);
> + =A0 =A0 =A0 return host ? host->dn : NULL;
> +}
> +
> =A0static inline int isa_vaddr_is_ioport(void __iomem *address)
> =A0{
> =A0 =A0 =A0 =A0/* No specific ISA handling on ppc32 at this stage, it
> @@ -116,6 +127,7 @@ static inline int isa_vaddr_is_ioport(void __iomem *a=
ddress)
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0return 0;
> =A0}
> +#endif
>
> =A0/* These are used for config access before all the PCI probing
> =A0 =A0has been done. */
> diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include=
/asm/prom.h
> index 2e72af0..d0890d3 100644
> --- a/arch/microblaze/include/asm/prom.h
> +++ b/arch/microblaze/include/asm/prom.h
> @@ -64,21 +64,6 @@ extern void kdump_move_device_tree(void);
> =A0/* CPU OF node matching */
> =A0struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
>
> -/**
> - * of_irq_map_pci - Resolve the interrupt for a PCI device
> - * @pdev: =A0 =A0 =A0the device whose interrupt is to be resolved
> - * @out_irq: =A0 structure of_irq filled by this function
> - *
> - * This function resolves the PCI interrupt for a given PCI device. If a
> - * device-node exists for a given pci_dev, it will use normal OF tree
> - * walking. If not, it will implement standard swizzling and walk up the
> - * PCI tree until an device-node is found, at which point it will finish
> - * resolving using the OF tree walking.
> - */
> -struct pci_dev;
> -struct of_irq;
> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> -
> =A0#endif /* __ASSEMBLY__ */
> =A0#endif /* __KERNEL__ */
>
> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel=
/prom_parse.c
> index 9ae24f4..47187cc 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -2,88 +2,11 @@
>
> =A0#include <linux/kernel.h>
> =A0#include <linux/string.h>
> -#include <linux/pci_regs.h>
> =A0#include <linux/module.h>
> =A0#include <linux/ioport.h>
> =A0#include <linux/etherdevice.h>
> =A0#include <linux/of_address.h>
> =A0#include <asm/prom.h>
> -#include <asm/pci-bridge.h>
> -
> -#ifdef CONFIG_PCI
> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
> -{
> - =A0 =A0 =A0 struct device_node *dn, *ppnode;
> - =A0 =A0 =A0 struct pci_dev *ppdev;
> - =A0 =A0 =A0 u32 lspec;
> - =A0 =A0 =A0 u32 laddr[3];
> - =A0 =A0 =A0 u8 pin;
> - =A0 =A0 =A0 int rc;
> -
> - =A0 =A0 =A0 /* Check if we have a device node, if yes, fallback to stan=
dard OF
> - =A0 =A0 =A0 =A0* parsing
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 dn =3D pci_device_to_OF_node(pdev);
> - =A0 =A0 =A0 if (dn)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return of_irq_map_one(dn, 0, out_irq);
> -
> - =A0 =A0 =A0 /* Ok, we don't, time to have fun. Let's start by building =
up an
> - =A0 =A0 =A0 =A0* interrupt spec. =A0we assume #interrupt-cells is 1, wh=
ich is standard
> - =A0 =A0 =A0 =A0* for PCI. If you do different, then don't use that rout=
ine.
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 rc =3D pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> - =A0 =A0 =A0 if (rc !=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> - =A0 =A0 =A0 /* No pin, exit */
> - =A0 =A0 =A0 if (pin =3D=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> -
> - =A0 =A0 =A0 /* Now we walk up the PCI tree */
> - =A0 =A0 =A0 lspec =3D pin;
> - =A0 =A0 =A0 for (;;) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Get the pci_dev of our parent */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppdev =3D pdev->bus->self;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ouch, it's a host bridge... */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppdev =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pci_controller *host=
;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host =3D pci_bus_to_host(pd=
ev->bus);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D host ? host->dn =
: NULL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* No node for host bridge =
? give up */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode =3D=3D NULL)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EIN=
VAL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We found a P2P bridge, c=
heck if it has a node */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_device_to_OF=
_node(ppdev);
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ok, we have found a parent with a device=
-node, hand over to
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the OF parsing code.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We build a unit address from the linux=
device to be used for
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* resolution. Note that we use the linux=
bus number which may
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* not match your firmware bus numbering.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fortunately, in most cases, interrupt-=
map-mask doesn't
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* include the bus number as part of the =
matching.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* You should still be careful about that=
though if you intend
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to rely on this function (you ship =A0=
a firmware that doesn't
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* create device nodes for all PCI device=
s).
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We can only get here if we hit a P2P bri=
dge with no node,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* let's do standard swizzling and try ag=
ain
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 lspec =3D pci_swizzle_interrupt_pin(pdev, l=
spec);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdev =3D ppdev;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 laddr[0] =3D (pdev->bus->number << 16)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (pdev->devfn << 8);
> - =A0 =A0 =A0 laddr[1] =A0=3D laddr[2] =3D 0;
> - =A0 =A0 =A0 return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
> -}
> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
> -#endif /* CONFIG_PCI */
>
> =A0void of_parse_dma_window(struct device_node *dn, const void *dma_windo=
w_prop,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *busno, unsigned long *phys,=
unsigned long *size)
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-c=
ommon.c
> index e363615..1e01a12 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -29,6 +29,7 @@
> =A0#include <linux/slab.h>
> =A0#include <linux/of.h>
> =A0#include <linux/of_address.h>
> +#include <linux/of_pci.h>
>
> =A0#include <asm/processor.h>
> =A0#include <asm/io.h>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include=
/asm/pci-bridge.h
> index 51e9e6f..edeb80f 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -171,6 +171,16 @@ static inline struct pci_controller *pci_bus_to_host=
(const struct pci_bus *bus)
> =A0 =A0 =A0 =A0return bus->sysdata;
> =A0}
>
> +static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus=
)
> +{
> + =A0 =A0 =A0 struct pci_controller *host;
> +
> + =A0 =A0 =A0 if (bus->self)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return pci_device_to_OF_node(bus->self);
> + =A0 =A0 =A0 host =3D pci_bus_to_host(bus);
> + =A0 =A0 =A0 return host ? host->dn : NULL;
> +}
> +
> =A0static inline int isa_vaddr_is_ioport(void __iomem *address)
> =A0{
> =A0 =A0 =A0 =A0/* No specific ISA handling on ppc32 at this stage, it
> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/p=
rom.h
> index d727575..c189aa5 100644
> --- a/arch/powerpc/include/asm/prom.h
> +++ b/arch/powerpc/include/asm/prom.h
> @@ -70,21 +70,6 @@ static inline int of_node_to_nid(struct device_node *d=
evice) { return 0; }
> =A0#endif
> =A0#define of_node_to_nid of_node_to_nid
>
> -/**
> - * of_irq_map_pci - Resolve the interrupt for a PCI device
> - * @pdev: =A0 =A0 =A0the device whose interrupt is to be resolved
> - * @out_irq: =A0 structure of_irq filled by this function
> - *
> - * This function resolves the PCI interrupt for a given PCI device. If a
> - * device-node exists for a given pci_dev, it will use normal OF tree
> - * walking. If not, it will implement standard swizzling and walk up the
> - * PCI tree until an device-node is found, at which point it will finish
> - * resolving using the OF tree walking.
> - */
> -struct pci_dev;
> -struct of_irq;
> -extern int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> -
> =A0extern void of_instantiate_rtc(void);
>
> =A0/* These includes are put at the bottom because they may contain thing=
s
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-c=
ommon.c
> index 10a44e6..eb341be 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -22,6 +22,7 @@
> =A0#include <linux/init.h>
> =A0#include <linux/bootmem.h>
> =A0#include <linux/of_address.h>
> +#include <linux/of_pci.h>
> =A0#include <linux/mm.h>
> =A0#include <linux/list.h>
> =A0#include <linux/syscalls.h>
> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_=
parse.c
> index c2b7a07..47187cc 100644
> --- a/arch/powerpc/kernel/prom_parse.c
> +++ b/arch/powerpc/kernel/prom_parse.c
> @@ -2,95 +2,11 @@
>
> =A0#include <linux/kernel.h>
> =A0#include <linux/string.h>
> -#include <linux/pci_regs.h>
> =A0#include <linux/module.h>
> =A0#include <linux/ioport.h>
> =A0#include <linux/etherdevice.h>
> =A0#include <linux/of_address.h>
> =A0#include <asm/prom.h>
> -#include <asm/pci-bridge.h>
> -
> -#ifdef CONFIG_PCI
> -int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
> -{
> - =A0 =A0 =A0 struct device_node *dn, *ppnode;
> - =A0 =A0 =A0 struct pci_dev *ppdev;
> - =A0 =A0 =A0 u32 lspec;
> - =A0 =A0 =A0 u32 laddr[3];
> - =A0 =A0 =A0 u8 pin;
> - =A0 =A0 =A0 int rc;
> -
> - =A0 =A0 =A0 /* Check if we have a device node, if yes, fallback to stan=
dard OF
> - =A0 =A0 =A0 =A0* parsing
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 dn =3D pci_device_to_OF_node(pdev);
> - =A0 =A0 =A0 if (dn) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D of_irq_map_one(dn, 0, out_irq);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!rc)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 /* Ok, we don't, time to have fun. Let's start by building =
up an
> - =A0 =A0 =A0 =A0* interrupt spec. =A0we assume #interrupt-cells is 1, wh=
ich is standard
> - =A0 =A0 =A0 =A0* for PCI. If you do different, then don't use that rout=
ine.
> - =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 rc =3D pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> - =A0 =A0 =A0 if (rc !=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> - =A0 =A0 =A0 /* No pin, exit */
> - =A0 =A0 =A0 if (pin =3D=3D 0)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> -
> - =A0 =A0 =A0 /* Now we walk up the PCI tree */
> - =A0 =A0 =A0 lspec =3D pin;
> - =A0 =A0 =A0 for (;;) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Get the pci_dev of our parent */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppdev =3D pdev->bus->self;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ouch, it's a host bridge... */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppdev =3D=3D NULL) {
> -#ifdef CONFIG_PPC64
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_bus_to_OF_no=
de(pdev->bus);
> -#else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pci_controller *host=
;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 host =3D pci_bus_to_host(pd=
ev->bus);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D host ? host->dn =
: NULL;
> -#endif
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* No node for host bridge =
? give up */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode =3D=3D NULL)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EIN=
VAL;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We found a P2P bridge, c=
heck if it has a node */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_device_to_OF=
_node(ppdev);
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ok, we have found a parent with a device=
-node, hand over to
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the OF parsing code.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We build a unit address from the linux=
device to be used for
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* resolution. Note that we use the linux=
bus number which may
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* not match your firmware bus numbering.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fortunately, in most cases, interrupt-=
map-mask doesn't include
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the bus number as part of the matching=
.
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* You should still be careful about that=
though if you intend
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to rely on this function (you ship =A0=
a firmware that doesn't
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* create device nodes for all PCI device=
s).
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> -
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We can only get here if we hit a P2P bri=
dge with no node,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* let's do standard swizzling and try ag=
ain
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 lspec =3D pci_swizzle_interrupt_pin(pdev, l=
spec);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdev =3D ppdev;
> - =A0 =A0 =A0 }
> -
> - =A0 =A0 =A0 laddr[0] =3D (pdev->bus->number << 16)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (pdev->devfn << 8);
> - =A0 =A0 =A0 laddr[1] =A0=3D laddr[2] =3D 0;
> - =A0 =A0 =A0 return of_irq_map_raw(ppnode, &lspec, 1, laddr, out_irq);
> -}
> -EXPORT_SYMBOL_GPL(of_irq_map_pci);
> -#endif /* CONFIG_PCI */
>
> =A0void of_parse_dma_window(struct device_node *dn, const void *dma_windo=
w_prop,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *busno, unsigned long *phys,=
unsigned long *size)
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 3c6e100..c71cff1 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -69,4 +69,10 @@ config OF_MDIO
> =A0 =A0 =A0 =A0help
> =A0 =A0 =A0 =A0 =A0OpenFirmware MDIO bus (Ethernet PHY) accessors
>
> +config OF_PCI
> + =A0 =A0 =A0 def_tristate PCI
> + =A0 =A0 =A0 depends on PCI && !SPARC
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 OpenFirmware PCI bus accessors
> +
> =A0endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 3ab21a0..f7861ed 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_OF_I2C) =A0 =A0+=3D of_i2c.o
> =A0obj-$(CONFIG_OF_NET) =A0 +=3D of_net.o
> =A0obj-$(CONFIG_OF_SPI) =A0 +=3D of_spi.o
> =A0obj-$(CONFIG_OF_MDIO) =A0+=3D of_mdio.o
> +obj-$(CONFIG_OF_PCI) =A0 +=3D of_pci.o
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> new file mode 100644
> index 0000000..dd862d2
> --- /dev/null
> +++ b/drivers/of/of_pci.c
> @@ -0,0 +1,80 @@
> +#include <linux/kernel.h>
> +#include <linux/of_pci.h>
> +#include <asm/prom.h>
> +
> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
> +{
> + =A0 =A0 =A0 struct device_node *dn, *ppnode;
> + =A0 =A0 =A0 struct pci_dev *ppdev;
> + =A0 =A0 =A0 u32 lspec;
> + =A0 =A0 =A0 __be32 lspec_be;
> + =A0 =A0 =A0 __be32 laddr[3];
> + =A0 =A0 =A0 u8 pin;
> + =A0 =A0 =A0 int rc;
> +
> + =A0 =A0 =A0 /* Check if we have a device node, if yes, fallback to stan=
dard OF
> + =A0 =A0 =A0 =A0* parsing
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 dn =3D pci_device_to_OF_node(pdev);
> + =A0 =A0 =A0 if (dn) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D of_irq_map_one(dn, 0, out_irq);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!rc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* Ok, we don't, time to have fun. Let's start by building =
up an
> + =A0 =A0 =A0 =A0* interrupt spec. =A0we assume #interrupt-cells is 1, wh=
ich is standard
> + =A0 =A0 =A0 =A0* for PCI. If you do different, then don't use that rout=
ine.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 rc =3D pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
> + =A0 =A0 =A0 if (rc !=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return rc;
> + =A0 =A0 =A0 /* No pin, exit */
> + =A0 =A0 =A0 if (pin =3D=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
> +
> + =A0 =A0 =A0 /* Now we walk up the PCI tree */
> + =A0 =A0 =A0 lspec =3D pin;
> + =A0 =A0 =A0 for (;;) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Get the pci_dev of our parent */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppdev =3D pdev->bus->self;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ouch, it's a host bridge... */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppdev =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_bus_to_OF_no=
de(pdev->bus);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* No node for host bridge =
? give up */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EIN=
VAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We found a P2P bridge, c=
heck if it has a node */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ppnode =3D pci_device_to_OF=
_node(ppdev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Ok, we have found a parent with a device=
-node, hand over to
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the OF parsing code.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We build a unit address from the linux=
device to be used for
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* resolution. Note that we use the linux=
bus number which may
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* not match your firmware bus numbering.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fortunately, in most cases, interrupt-=
map-mask doesn't
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* include the bus number as part of the =
matching.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* You should still be careful about that=
though if you intend
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* to rely on this function (you ship =A0=
a firmware that doesn't
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* create device nodes for all PCI device=
s).
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ppnode)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* We can only get here if we hit a P2P bri=
dge with no node,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* let's do standard swizzling and try ag=
ain
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 lspec =3D pci_swizzle_interrupt_pin(pdev, l=
spec);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdev =3D ppdev;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 lspec_be =3D cpu_to_be32(lspec);
> + =A0 =A0 =A0 laddr[0] =3D cpu_to_be32((pdev->bus->number << 16) | (pdev-=
>devfn << 8));
> + =A0 =A0 =A0 laddr[1] =A0=3D laddr[2] =3D cpu_to_be32(0);
> + =A0 =A0 =A0 return of_irq_map_raw(ppnode, &lspec_be, 1, laddr, out_irq)=
;
> +}
> +EXPORT_SYMBOL_GPL(of_irq_map_pci);
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> new file mode 100644
> index 0000000..9b0ba67
> --- /dev/null
> +++ b/include/linux/of_pci.h
> @@ -0,0 +1,20 @@
> +#ifndef __OF_PCI_H
> +#define __OF_PCI_H
> +
> +#include <linux/pci.h>
> +
> +/**
> + * of_irq_map_pci - Resolve the interrupt for a PCI device
> + * @pdev: =A0 =A0 =A0 the device whose interrupt is to be resolved
> + * @out_irq: =A0 =A0structure of_irq filled by this function
> + *
> + * This function resolves the PCI interrupt for a given PCI device. If a
> + * device-node exists for a given pci_dev, it will use normal OF tree
> + * walking. If not, it will implement standard swizzling and walk up the
> + * PCI tree until an device-node is found, at which point it will finish
> + * resolving using the OF tree walking.
> + */
> +struct pci_dev;
> +struct of_irq;
> +int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq);
> +#endif
> --
> 1.7.3.2
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [openmcapi-dev] Re: [RFC] Inter-processor Mailboxes Drivers
From: Blanchard, Hollis @ 2011-02-16 20:22 UTC (permalink / raw)
To: Hiroshi DOYU
Cc: Inge, Meador, jamie, linuxppc-dev, openmcapi-dev,
linux-arm-kernel
In-Reply-To: <20110216.082228.814509512977216497.Hiroshi.DOYU@nokia.com>
On 02/15/2011 10:22 PM, Hiroshi DOYU wrote:
> From: "ext Blanchard, Hollis"<Hollis_Blanchard@mentor.com>
> Subject: Re: [RFC] Inter-processor Mailboxes Drivers
> Date: Tue, 15 Feb 2011 15:38:25 -0800
>
>> On 02/15/2011 01:58 PM, Meador Inge wrote:
>>> On 02/14/2011 04:01 AM, Jamie Iles wrote:
>>>> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>>>>> 1. Hardware specific bits somewhere under '.../arch/*'. =
Drivers
>>>>> for the MPIC message registers on Power and OMAP4 =
mailboxes,
>>>>> for
>>>>> example.
>>>>> 2. A higher level driver under '.../drivers/mailbox/*'. =
That the
>>>>> pieces in (1) would register with. This piece would =
expose the
>>>>> main kernel API.
>>>>> 3. Userspace interfaces for accessing the mailboxes. A
>>>>> '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for =
example.
>>>> How about using virtio for all of this and having the mailbox as a
>>>> notification/message passing driver for the virtio backend? There =
are
>>>> already virtio console and network drivers that could be useful for =
the
>>>> userspace part of it. drivers/virtio/virtio_ring.c might be a good
>>>> starting point if you thought there was some mileage in this =
approach.
>>> To be honest, I am not that familiar with 'virtio', but I will take =
a
>>> look. Thanks for the pointer. Maybe Hollis can speak to this idea =
more.
>> My opinion is that virtio is (over?) complicated.
> Considering the case of omap mailbox H/W, it is just a simple one way
> 4 slot x 32bit H/W FIFO, I also may think that this may be a bit too
> much...
I think the proposal is to implement a virtio link using the OMAP=20
mailboxes as the interrupt mechanism, and shared memory to carry the=20
data and descriptor rings.
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: Using CONFIG_PHYSICAL_START
From: Meador Inge @ 2011-02-16 20:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110216132403.3466a83e@schlenkerla>
On 02/16/2011 01:24 PM, Scott Wood wrote:
> On Wed, 16 Feb 2011 12:00:25 -0600
> Meador Inge<meador_inge@mentor.com> wrote:
>
>> Hi Kumar,
>>
>> Quick question about the support for booting at a non-zero base address
>> (as committed here:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=37dd2badcfcec35f5e21a0926968d77a404f03c3).
>> Is booting from a non-zero address as simple as changing
>> "CONFIG_PHYSICAL_START" (assuming it meets the alignment constraints, of
>> course)?
>
> Another option is to turn on CONFIG_RELOCATABLE. Note that you'll still
> have the same alignment constraints; it doesn't generate a truly relocatable
> binary (the effective addresses are fixed). But you don't have to specify
> the physical address at compile-time. This allows you to use the same
> kernel image for multiple AMP partitions.
>
>> For example, I want to boot from a non-zero address on the P1022DS. I
>> should just be able to change "CONFIG_PHYSICAL_START" to, say,
>> 0x08000000, and it should work, right? Any other bits that need to be
>> done (i.e. U-Boot or device tree magic)?
>
> You'll want the memory node adjusted for your restricted address range
> (I'm assuming that this is why you want to start at non-zero, and that
> you're not trying to have the kernel be located in the middle of its
> partition).
>
> There are some special u-boot variables (bootm_low/bootm_size) that govern
> placement of the kernel, fdt, etc.
Thanks Scott. I should have looked in the u-boot docs. There are very
clear instructions on how to setup an AMP environment in
'.../doc/README.mpc8572ds'
(http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=doc/README.mpc8572ds;h=06dab596bea52ab8d8c2ba89d86f793cc4881ccb;hb=HEAD).
> -Scott
>
>
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ 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