* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Domen Puncer @ 2007-10-24 19:12 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20071024182308.21194.69416.stgit@trillian.cg.shawcable.net>
On 24/10/07 12:24 -0600, Grant Likely wrote:
> Domen,
>
> Here's a real solution to the problem. I've somewhat tested this on
> the lite5200b. Can you give it a spin on efika and see if SPI still
> works for you?
My test case was lite5200b too, I don't think I ever tried SPI on
efika.
(Are even the right pins on irda connector, or is a necessary line
missing?)
Domen
>
> Thanks,
> g.
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* RE: Ocotea board?
From: Charlie Ashton @ 2007-10-24 18:55 UTC (permalink / raw)
To: Jeff Mock, linuxppc-dev, linuxppc-embedded
In-Reply-To: <471F7C67.6080809@mock.com>
The AMCC 440GX processor is by no means obsolete. There are more
customers for this processor every month. There is a new, comprehensive
evaluation kit called "Taishan"
(http://www.amcc.com/Embedded/evalkits/440GX_PB_1_04.pdf), which AMCC
provides to customers and partners. "Ocotea" is a board that was
originally designed and used for processor validation purposes.
Regards,
Charlie
-----Original Message-----
From: linuxppc-embedded-bounces+cashton=3Damcc.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+cashton=3Damcc.com@ozlabs.org] On =
Behalf
Of Jeff Mock
Sent: Wednesday, October 24, 2007 12:10 PM
To: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: Ocotea board?
Thanks for all of the replies, it's nice to hear that the 440GX isn't=20
obsolete yet... A relatively arbitrary decision, but I'm going to send
the Ocotea board to Josh.
jeff
Jeff Mock wrote:
> Is the Ocotea board (the original 440GX eval board) still interesting?
> I'm wrapping up a project using the 440GX, I started out hacking on=20
> the Ocotea board to get started, but we moved off Ocotea long ago onto
> our own hardware.
>=20
> I'm cleaning up the lab now that the project is nearly finished and I=20
> would like to give the board to someone that will put it to good use.
> I've sponged off this mailing list quite a lot, it's about time I give
> a little something back.
>=20
> The board has been hacked a little bit but still works fine. I just=20
> powered it up and it happily booted Linux via TFTP. The boot ROM now=20
> has u-boot, the original PIBs (or whatever) is long gone. All I ask is
> that you're self-sufficient and don't bug me too much about it...
>=20
> Can someone recommend a good home? Otherwise it will wind up in=20
> storeroom purgatory.
>=20
> jeff
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains =
information that is confidential and proprietary to Applied Micro =
Circuits Corporation or its subsidiaries. It is to be used solely for =
the purpose of furthering the parties' business relationship. All =
unauthorized review, use, disclosure or distribution is prohibited. If =
you are not the intended recipient, please contact the sender by reply =
e-mail and destroy all copies of the original message.
^ permalink raw reply
* [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Grant Likely @ 2007-10-24 18:24 UTC (permalink / raw)
To: domen.puncer, linuxppc-dev
Domen,
Here's a real solution to the problem. I've somewhat tested this on
the lite5200b. Can you give it a spin on efika and see if SPI still
works for you?
Thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 2/2] mpc5200: psc-spi driver must not touch port_config or cdm registers
From: Grant Likely @ 2007-10-24 18:24 UTC (permalink / raw)
To: domen.puncer, linuxppc-dev
In-Reply-To: <20071024182308.21194.69416.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
port_config and the cdm are the responsibility of firmware; and if
firmware doesn't set it up correctly, it should be fixed up by
platform code on a per-board basis because it's a property of the
board.
Drivers should never touch these registers.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/spi/mpc52xx_psc_spi.c | 84 ++++-------------------------------------
1 files changed, 8 insertions(+), 76 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 7051e6c..44d1110 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -328,77 +328,15 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device *spi)
kfree(spi->controller_state);
}
-static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
+static int mpc52xx_psc_spi_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
- struct mpc52xx_cdm __iomem *cdm;
- struct mpc52xx_gpio __iomem *gpio;
struct mpc52xx_psc __iomem *psc = mps->psc;
- u32 ul;
- u32 mclken_div;
- int ret = 0;
+ int rc;
-#if defined(CONFIG_PPC_MERGE)
- cdm = mpc52xx_find_and_map("mpc5200-cdm");
- gpio = mpc52xx_find_and_map("mpc5200-gpio");
-#else
- cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
- gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
-#endif
- if (!cdm || !gpio) {
- printk(KERN_ERR "Error mapping CDM/GPIO\n");
- ret = -EFAULT;
- goto unmap_regs;
- }
-
- /* default sysclk is 512MHz */
- mclken_div = 0x8000 |
- (((mps->sysclk ? mps->sysclk : 512000000) / MCLK) & 0x1FF);
-
- switch (psc_id) {
- case 1:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFFFFFFF8;
- ul |= 0x00000006;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc1, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x00000020;
- out_be32(&cdm->clk_enables, ul);
- break;
- case 2:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFFFFFF8F;
- ul |= 0x00000060;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc2, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x00000040;
- out_be32(&cdm->clk_enables, ul);
- break;
- case 3:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFFFFF0FF;
- ul |= 0x00000600;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc3, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x00000080;
- out_be32(&cdm->clk_enables, ul);
- break;
- case 6:
- ul = in_be32(&gpio->port_config);
- ul &= 0xFF8FFFFF;
- ul |= 0x00700000;
- out_be32(&gpio->port_config, ul);
- out_be16(&cdm->mclken_div_psc6, mclken_div);
- ul = in_be32(&cdm->clk_enables);
- ul |= 0x00000010;
- out_be32(&cdm->clk_enables, ul);
- break;
- default:
- ret = -EINVAL;
- goto unmap_regs;
- }
+ /* Setup a desirable MCLK */
+ rc = mpc52xx_cdm_set_psc_clk(psc_id, MCLK);
+ if (rc)
+ return rc;
/* Reset the PSC into a known state */
out_8(&psc->command, MPC52xx_PSC_RST_RX);
@@ -422,13 +360,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
mps->bits_per_word = 8;
-unmap_regs:
- if (cdm)
- iounmap(cdm);
- if (gpio)
- iounmap(gpio);
-
- return ret;
+ return 0;
}
static irqreturn_t mpc52xx_psc_spi_isr(int irq, void *dev_id)
@@ -493,7 +425,7 @@ static int __init mpc52xx_psc_spi_do_probe(struct device *dev, u32 regaddr,
if (ret)
goto free_master;
- ret = mpc52xx_psc_spi_port_config(master->bus_num, mps);
+ ret = mpc52xx_psc_spi_config(master->bus_num-1, mps);
if (ret < 0)
goto free_irq;
^ permalink raw reply related
* [PATCH 1/2] mpc52xx: add cdm (clock module) helper function for PSCs
From: Grant Likely @ 2007-10-24 18:24 UTC (permalink / raw)
To: domen.puncer, linuxppc-dev
In-Reply-To: <20071024182308.21194.69416.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
Device drivers should not access the CDM registers directly to modify
the clocking. Instead, provide a helper function for setting the MCLK
value so that the registers can be properly protected from concurent
access.
---
arch/powerpc/platforms/52xx/efika.c | 2
arch/powerpc/platforms/52xx/lite5200.c | 1
arch/powerpc/platforms/52xx/mpc52xx_common.c | 112 +++++++++++++++++++++++---
include/asm-powerpc/mpc52xx.h | 7 ++
4 files changed, 107 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c b/arch/powerpc/platforms/52xx/efika.c
index a0da70c..0e3b1ac 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -180,6 +180,8 @@ static void __init efika_setup_arch(void)
{
rtas_initialize();
+ mpc52xx_setup_clocks();
+
efika_pcisetup();
#ifdef CONFIG_PM
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 25d2bfa..7665e60 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -143,6 +143,7 @@ static void __init lite5200_setup_arch(void)
lite5200_fix_port_config();
/* Some mpc5200 & mpc5200b related configuration */
+ mpc5200_setup_clocks();
mpc5200_setup_xlb_arbiter();
/* Map wdt for mpc52xx_restart() */
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 9850685..ced046b 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#include <linux/of_platform.h>
+#include <linux/spinlock.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/mpc52xx.h>
@@ -26,6 +27,20 @@
*/
static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
+/*
+ * Location of clock distibution module. The device regs are mapped at
+ * board init time to eliminate runtime lookups. All access to these
+ * registers is protected with the mpc52xx_cdm_lock spinlock
+ */
+static void __iomem *mpc52xx_cdm_regs = NULL;
+static spinlock_t mpc52xx_cdm_lock = SPIN_LOCK_UNLOCKED;
+
+/*
+ * Cached clock values
+ */
+static unsigned int mpc52xx_system_freq;
+static unsigned int mpc52xx_ipb_freq;
+
static void __iomem *
mpc52xx_map_node(struct device_node *ofn)
{
@@ -74,26 +89,92 @@ EXPORT_SYMBOL(mpc52xx_find_and_map_path);
unsigned int
mpc52xx_find_ipb_freq(struct device_node *node)
{
- struct device_node *np;
- const unsigned int *p_ipb_freq = NULL;
+ return mpc52xx_ipb_freq;
+}
+EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
- of_node_get(node);
- while (node) {
- p_ipb_freq = of_get_property(node, "bus-frequency", NULL);
- if (p_ipb_freq)
- break;
+/*
+ * Clock support for PSCs
+ */
+struct mpc52xx_cdm_psc_clk_params {
+ int div_reg;
+ int enable;
+};
- np = of_get_parent(node);
- of_node_put(node);
- node = np;
- }
- if (node)
- of_node_put(node);
+static struct mpc52xx_cdm_psc_clk_params mpc52xx_cdm_psc_clk_params[] = {
+ [0] = { .div_reg = MPC52xx_CDM_MCLKEN_DIV_PSC1_OFF, .enable = 0x20 },
+ [1] = { .div_reg = MPC52xx_CDM_MCLKEN_DIV_PSC2_OFF, .enable = 0x40 },
+ [2] = { .div_reg = MPC52xx_CDM_MCLKEN_DIV_PSC3_OFF, .enable = 0x80 },
+ [5] = { .div_reg = MPC52xx_CDM_MCLKEN_DIV_PSC6_OFF, .enable = 0x10 },
+};
+
+/**
+ * mpc52xx_cdm_set_psc_clk: Set input MCLK for a PSC
+ * @psc: id of PSC, based at 0
+ * @freq_hz: desired frequency
+ */
+int mpc52xx_cdm_set_psc_clk(int psc, u32 freq_hz)
+{
+ struct mpc52xx_cdm_psc_clk_params *params;
+ unsigned long flags;
+ u16 mclken_div;
+ u32 reg;
+
+ if (!mpc52xx_cdm_regs)
+ return -ENODEV;
- return p_ipb_freq ? *p_ipb_freq : 0;
+ /* Calculate the parameters */
+ params = &mpc52xx_cdm_psc_clk_params[psc];
+ mclken_div = 0x8000 | (((mpc52xx_system_freq / freq_hz) - 1) & 0x1FF);
+
+ spin_lock_irqsave(&mpc52xx_cdm_lock, flags);
+
+ /* disable the clock before modifying frequency */
+ reg = in_be32(mpc52xx_cdm_regs + MPC52xx_CDM_CLK_ENABLES_OFF);
+ reg &= ~params->enable;
+
+ /* Set the new speed */
+ out_be16(mpc52xx_cdm_regs + params->div_reg, mclken_div);
+
+ /* Set the enable bit */
+ reg |= params->enable;
+ out_be32(mpc52xx_cdm_regs + MPC52xx_CDM_CLK_ENABLES_OFF, reg);
+
+ spin_unlock_irqrestore(&mpc52xx_cdm_lock, flags);
+
+ return 0;
}
-EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
+EXPORT_SYMBOL_GPL(mpc52xx_cdm_set_psc_clk);
+/**
+ * mpc5200_setup_clocks: called by platform code to setup clock frequencies
+ */
+void mpc5200_setup_clocks(void)
+{
+ struct device_node *node;
+ const unsigned int *prop = NULL;
+
+ node = of_find_compatible_node(NULL, NULL, "fsl,mpc5200");
+ if (!node)
+ node = of_find_compatible_node(NULL, NULL, "mpc5200");
+ if (!node) {
+ printk(KERN_ERR"mpc5200_setup_clocks: could not find soc node\n");
+ return;
+ }
+
+ prop = of_get_property(node, "system-frequency", NULL);
+ if (prop)
+ mpc52xx_system_freq = *prop;
+
+ prop = of_get_property(node, "bus-frequency", NULL);
+ if (prop)
+ mpc52xx_ipb_freq = *prop;
+ of_node_put(node);
+
+ mpc52xx_cdm_regs = mpc52xx_find_and_map("fsl,mpc5200-cdm");
+ if (!mpc52xx_cdm_regs)
+ mpc52xx_cdm_regs = mpc52xx_find_and_map("mpc5200-cdm");
+}
/*
* Configure the XLB arbiter settings to match what Linux expects.
@@ -176,3 +257,4 @@ mpc52xx_restart(char *cmd)
while (1);
}
+
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index fcb2ebb..08eb714 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -208,6 +208,7 @@ struct mpc52xx_cdm {
u16 fd_counters; /* CDM + 0x12 reg4 byte2,3 */
u32 clk_enables; /* CDM + 0x14 reg5 */
+#define MPC52xx_CDM_CLK_ENABLES_OFF 0x14
u8 osc_disable; /* CDM + 0x18 reg6 byte0 */
u8 reserved0[3]; /* CDM + 0x19 reg6 byte1,2,3 */
@@ -228,15 +229,19 @@ struct mpc52xx_cdm {
u16 reserved4; /* CDM + 0x28 reg10 byte0,1 */
u16 mclken_div_psc1; /* CDM + 0x2a reg10 byte2,3 */
+#define MPC52xx_CDM_MCLKEN_DIV_PSC1_OFF 0x2a
u16 reserved5; /* CDM + 0x2c reg11 byte0,1 */
u16 mclken_div_psc2; /* CDM + 0x2e reg11 byte2,3 */
+#define MPC52xx_CDM_MCLKEN_DIV_PSC2_OFF 0x2e
u16 reserved6; /* CDM + 0x30 reg12 byte0,1 */
u16 mclken_div_psc3; /* CDM + 0x32 reg12 byte2,3 */
+#define MPC52xx_CDM_MCLKEN_DIV_PSC3_OFF 0x32
u16 reserved7; /* CDM + 0x34 reg13 byte0,1 */
u16 mclken_div_psc6; /* CDM + 0x36 reg13 byte2,3 */
+#define MPC52xx_CDM_MCLKEN_DIV_PSC6_OFF 0x36
};
#endif /* __ASSEMBLY__ */
@@ -251,6 +256,8 @@ struct mpc52xx_cdm {
extern void __iomem * mpc52xx_find_and_map(const char *);
extern void __iomem * mpc52xx_find_and_map_path(const char *path);
extern unsigned int mpc52xx_find_ipb_freq(struct device_node *node);
+extern int mpc52xx_cdm_set_psc_clk(int psc, u32 freq_hz);
+extern void mpc5200_setup_clocks(void);
extern void mpc5200_setup_xlb_arbiter(void);
extern void mpc52xx_declare_of_platform_devices(void);
^ permalink raw reply related
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 17:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710241001g165e7aeatdc92096544fbeb60@mail.gmail.com>
Jon Smirl wrote:
> Calling it directly from the platform code is an option, but where
> does the fabric driver code live? It doesn't make a lot of sense to
> put ALSA code into arch/powerpc/platforms/52xx. I could make a
> function call from arch/powerpc/platforms/52xx over to
> sound/soc/powerpc but that's not very pretty.
sound/soc/fsl is where the non-codec ASoC drivers for Freescale parts should go.
> The codec drivers in asoc are completely agnostic. The same codec
> driver works on x86, arm, powerpc, etc.
Well, in theory at least. I never tried my cs4270 driver on anything but PowerPC.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 17:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710241001g165e7aeatdc92096544fbeb60@mail.gmail.com>
On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Heh, I'm one of the folks who objected to it; here's what was written:
> >
> > > > >
> > > > > pseudo-sound@0 { // use to trigger loading platform specific fabric driver
> > > > > device_type = "pseudo-sound"
> > > > > };
> > > >
> > > > I don't think this is a good idea. The device tree is for describing
> > > > your hardware; so the layout should reflect that. Make the platform
> > > > code do the right thing with the real nodes.
> >
> > What I objected to was that the pseudo-sound node didn't contain any
> > real information. It was just being a hook to trigger calling a probe
> > function. If you're going to do that then you might as well just call
> > it directly from platform code.
>
> Calling it directly from the platform code is an option, but where
> does the fabric driver code live? It doesn't make a lot of sense to
> put ALSA code into arch/powerpc/platforms/52xx. I could make a
> function call from arch/powerpc/platforms/52xx over to
> sound/soc/powerpc but that's not very pretty.
>
> Another option is to make the fabric driver a "struct platform_driver"
> instead of a "struct of_platform_driver". "struct platform_driver" is
> not being probed in the current mpc5200 code. This option makes senses
> to me, "struct platform_driver" will load without a device tree node.
> The driver will still need to check and see if it is on the right
> platform when more than one is compiled in.
Yes, this is a good approach.
> > It would be possible and reasonable for a single fabric driver to work
> > with many different circuit layouts as long as it has the information
> > needed to adapt each instance.
>
> That is how the Apple driver is implemented. There is a single fabric
> driver that uses layout-id to set everything up to match the physical
> PCB.
> sound/aoa/fabrics/snd-aoa-fabric-layout.c
>
> But Apple put the layout id down inside the a sound node:
> /proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound:
> name "sound"
> device_type "soundchip"
> compatible "AOAbase"
> built-in
> layout-id 00000046 (70)
> object-model-version 00000002
> vendor-id 0000106b (4203)
> platform-tas-codec-ref ff98cba8
> linux,phandle ff985d48
Yes, this is the same idea. I don't think benh and segher were
particularly fond of it though. I think Segher in particular had a
preference for the platform code probing approach.
> > Now is probably a good time to mention that there is *nothing* in the
> > device tree that enforces a 1:1 relationship between device tree nodes
> > and driver instances. Sure, it make sense to register the i2s and
> > codec drivers from probing on the i2s and codec nodes. However, there
> > is nothing that prevents the codec driver from *also* registering a
> > fabric driver based on a property in the codec node or the board-level
> > compatible property.
>
> But there is something in the kernel that enforces it. I haven't
> checked the powerpc code, but the PCI code won't probe anymore drivers
> once one has attached to a device. The rule of one driver per device
> is a good one. Places where that rule has been broken have caused a
> lot of problems (fbdev vs DRM).
heh; there's isn't a 1:1 relationship between device tree nodes and
device objects either. You create the device objects that you need;
either on the platform bus or the of_platform bus.
The probe of an of_platform device can trigger the creation of a
plaform_device node for *another* driver. This approach is safe.
>
> > Fabric drivers are codec specific anyway. It's not all that
> > unrealistic for the device tree binding for a codec to have a list of
> > fabric drivers that it can register.
>
> The codec drivers in asoc are completely agnostic. The same codec
> driver works on x86, arm, powerpc, etc.
Yes the *driver* is agnostic; but the *binding* doesn't have to be. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Ocotea board?
From: Jeff Mock @ 2007-10-24 17:09 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
In-Reply-To: <471E39E0.5070106@mock.com>
Thanks for all of the replies, it's nice to hear that the 440GX isn't
obsolete yet... A relatively arbitrary decision, but I'm going to send
the Ocotea board to Josh.
jeff
Jeff Mock wrote:
> Is the Ocotea board (the original 440GX eval board) still interesting?
> I'm wrapping up a project using the 440GX, I started out hacking on the
> Ocotea board to get started, but we moved off Ocotea long ago onto our
> own hardware.
>
> I'm cleaning up the lab now that the project is nearly finished and I
> would like to give the board to someone that will put it to good use.
> I've sponged off this mailing list quite a lot, it's about time I give a
> little something back.
>
> The board has been hacked a little bit but still works fine. I just
> powered it up and it happily booted Linux via TFTP. The boot ROM now
> has u-boot, the original PIBs (or whatever) is long gone. All I ask is
> that you're self-sufficient and don't bug me too much about it...
>
> Can someone recommend a good home? Otherwise it will wind up in
> storeroom purgatory.
>
> jeff
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 17:01 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240938l5b8c30b9qe538cc641df5e61b@mail.gmail.com>
On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> Heh, I'm one of the folks who objected to it; here's what was written:
>
> > > >
> > > > pseudo-sound@0 { // use to trigger loading platform specific fabric driver
> > > > device_type = "pseudo-sound"
> > > > };
> > >
> > > I don't think this is a good idea. The device tree is for describing
> > > your hardware; so the layout should reflect that. Make the platform
> > > code do the right thing with the real nodes.
>
> What I objected to was that the pseudo-sound node didn't contain any
> real information. It was just being a hook to trigger calling a probe
> function. If you're going to do that then you might as well just call
> it directly from platform code.
Calling it directly from the platform code is an option, but where
does the fabric driver code live? It doesn't make a lot of sense to
put ALSA code into arch/powerpc/platforms/52xx. I could make a
function call from arch/powerpc/platforms/52xx over to
sound/soc/powerpc but that's not very pretty.
Another option is to make the fabric driver a "struct platform_driver"
instead of a "struct of_platform_driver". "struct platform_driver" is
not being probed in the current mpc5200 code. This option makes senses
to me, "struct platform_driver" will load without a device tree node.
The driver will still need to check and see if it is on the right
platform when more than one is compiled in.
>
> > > For example:
> > > sound@0 {
> > > compatible = "<mfg>,<board>,sound" // The board might have
> > > more than one sound i/f which could be wired differently
> > > codec-handle = <&codec0>;
> > > };
>
> The difference here is that the node provides real information about
> the board. It has a compatible field which tells you *exactly* what
> sound circuit is present on the board. It can have additional
> information that does make sense to encode into the device tree (ie.
> the codec that is used). It's not addressable (no registers or
> anything), but it does describe the board.
>
> It would be possible and reasonable for a single fabric driver to work
> with many different circuit layouts as long as it has the information
> needed to adapt each instance.
That is how the Apple driver is implemented. There is a single fabric
driver that uses layout-id to set everything up to match the physical
PCB.
sound/aoa/fabrics/snd-aoa-fabric-layout.c
But Apple put the layout id down inside the a sound node:
/proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound:
name "sound"
device_type "soundchip"
compatible "AOAbase"
built-in
layout-id 00000046 (70)
object-model-version 00000002
vendor-id 0000106b (4203)
platform-tas-codec-ref ff98cba8
linux,phandle ff985d48
>
> >
> > Do you even need the parameters, how about simply this?
> >
> > sound-fabric {
> > };
>
> But this goes back to having nodes that don't provide any information.
> You don't want that.
>
> >
> > That will trigger loading all of the sound-fabric drivers built into
> > the kernel. In their probe functions they can look in the device tree
> > and extract the machine name and then decide to stay loaded or fail
> > the probe.
> >
>
> ...
>
> Now is probably a good time to mention that there is *nothing* in the
> device tree that enforces a 1:1 relationship between device tree nodes
> and driver instances. Sure, it make sense to register the i2s and
> codec drivers from probing on the i2s and codec nodes. However, there
> is nothing that prevents the codec driver from *also* registering a
> fabric driver based on a property in the codec node or the board-level
> compatible property.
But there is something in the kernel that enforces it. I haven't
checked the powerpc code, but the PCI code won't probe anymore drivers
once one has attached to a device. The rule of one driver per device
is a good one. Places where that rule has been broken have caused a
lot of problems (fbdev vs DRM).
> Fabric drivers are codec specific anyway. It's not all that
> unrealistic for the device tree binding for a codec to have a list of
> fabric drivers that it can register.
The codec drivers in asoc are completely agnostic. The same codec
driver works on x86, arm, powerpc, etc.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] wrapper: Revert ps3 binary flag usage, and remove .bin suffix.
From: Scott Wood @ 2007-10-24 16:56 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, geert
The ps3 target produces two images, and the binary one is not the
"primary" image that corresponds to the -o flag; thus, it no longer
uses the generic binary flag.
On platforms which do use the binary flag, it no longer produces a
.bin suffix, so that the output file matches what was passed to the -o flag.
This should fix the zImage ln problems for the ps3 target.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/wrapper | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 39b27e5..ece6f49 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -149,7 +149,6 @@ cuboot*)
ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
lds=$object/zImage.ps3.lds
- binary=y
gzip=
ext=bin
objflags="-O binary --set-section-flags=.bss=contents,alloc,load,data"
@@ -233,7 +232,7 @@ entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
if [ -n "$binary" ]; then
mv "$ofile" "$ofile".elf
- ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
+ ${CROSS}objcopy -O binary "$ofile".elf "$ofile"
fi
# post-processing needed for some platforms
@@ -246,9 +245,9 @@ coff)
$object/hack-coff "$ofile"
;;
cuboot*)
- gzip -f -9 "$ofile".bin
+ gzip -f -9 "$ofile"
mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
- $uboot_version -d "$ofile".bin.gz "$ofile"
+ $uboot_version -d "$ofile".gz "$ofile"
;;
treeboot*)
mv "$ofile" "$ofile.elf"
@@ -269,11 +268,11 @@ ps3)
# then copied to offset 0x100. At runtime the bootwrapper program
# copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
- system_reset_overlay=0x`${CROSS}nm "$ofile".elf \
+ system_reset_overlay=0x`${CROSS}nm "$ofile" \
| grep ' __system_reset_overlay$' \
| cut -d' ' -f1`
system_reset_overlay=`printf "%d" $system_reset_overlay`
- system_reset_kernel=0x`${CROSS}nm "$ofile".elf \
+ system_reset_kernel=0x`${CROSS}nm "$ofile" \
| grep ' __system_reset_kernel$' \
| cut -d' ' -f1`
system_reset_kernel=`printf "%d" $system_reset_kernel`
@@ -282,6 +281,8 @@ ps3)
rm -f "$object/otheros.bld"
+ ${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
+
msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
skip=$overlay_dest seek=$system_reset_kernel \
count=$overlay_size bs=1 2>&1)
--
1.5.3.4
^ permalink raw reply related
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 16:52 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F75A1.1000909@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > Now is probably a good time to mention that there is *nothing* in the
> > device tree that enforces a 1:1 relationship between device tree nodes
> > and driver instances. Sure, it make sense to register the i2s and
> > codec drivers from probing on the i2s and codec nodes. However, there
> > is nothing that prevents the codec driver from *also* registering a
> > fabric driver based on a property in the codec node or the board-level
> > compatible property.
>
> Wouldn't it make more sense for the fabric driver to register the codec driver?
> The fabric driver is the "master" of the other drivers, should it needs to
> load and run first.
It doesn't really matter. There doesn't need to be a 1:1 relationship
between driver instances and device nodes. A probe on one device node
can cause the instantiation of both a fabric driver and a codec driver
(just put the appropriate calls in the of_platform_bus probe hook).
>
> > Fabric drivers are codec specific anyway.
>
> Yes and no. They're really platform-specific, but they should be able to scan
> the device tree, determine which codecs are actually on the system, and then
> link in the appropriate codec driver.
My point is; most likely if you change the codec, you need to change
the fabric driver too.
There will be many fabric drivers using a single codec,
but there will not be many codec drivers using a single fabric.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 16:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F75CD.6080606@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > If you need to scan the tree, don't do it when the driver registers,
> > do it in the platform code instead. Otherwise you unconditionally
> > incur the penalty of scanning the whole device tree on every system
> > that loads the driver, regardless of whether or not the device is
> > present.
>
> So your saying that the fabric driver should be embedded in the platform driver?
No; that's not what I mean.
But the scanning of the device tree to decide whether or not to
instantiate the driver should be called from platform code. The
device tree should not be scanned on driver loading.
In other words: populate either a platform_device or an
of_platform_device that the driver can bind against.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 16:41 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40710240939p408d3e5bj5daae8afcb5ab77f@mail.gmail.com>
Grant Likely wrote:
> If you need to scan the tree, don't do it when the driver registers,
> do it in the platform code instead. Otherwise you unconditionally
> incur the penalty of scanning the whole device tree on every system
> that loads the driver, regardless of whether or not the device is
> present.
So your saying that the fabric driver should be embedded in the platform driver?
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 16:41 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40710240938l5b8c30b9qe538cc641df5e61b@mail.gmail.com>
Grant Likely wrote:
> Now is probably a good time to mention that there is *nothing* in the
> device tree that enforces a 1:1 relationship between device tree nodes
> and driver instances. Sure, it make sense to register the i2s and
> codec drivers from probing on the i2s and codec nodes. However, there
> is nothing that prevents the codec driver from *also* registering a
> fabric driver based on a property in the codec node or the board-level
> compatible property.
Wouldn't it make more sense for the fabric driver to register the codec driver?
The fabric driver is the "master" of the other drivers, should it needs to
load and run first.
> Fabric drivers are codec specific anyway.
Yes and no. They're really platform-specific, but they should be able to scan
the device tree, determine which codecs are actually on the system, and then
link in the appropriate codec driver.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 16:39 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F6C3F.10003@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > It makes sense to me, there needs to be some way to trigger loading
> > the fabric driver.
>
> Well, you only really two have choices:
>
> 1) Probe on the AC97/SSI nodes
> 2) When the driver initializes, just scan all the nodes in the device tree (no
> probing).
>
> I think option #2 makes the most sense, because option #1 says that your fabric
> driver is really an AC97 driver, which it isn't.
If you need to scan the tree, don't do it when the driver registers,
do it in the platform code instead. Otherwise you unconditionally
incur the penalty of scanning the whole device tree on every system
that loads the driver, regardless of whether or not the device is
present.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 16:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710240854y6ac115b6i5e0400eb369fcf7@mail.gmail.com>
On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > Do you want to pick one and add it to the device tree documentation
> > > with an example for i2s and ac97? I'll use which ever one is picked.
> >
> > Sure, I'll draft something up and post it for review.
> >
> > On the device probing front; what about this method:
> >
> > Rather than trying to figure things out from the board model, or the
> > combination of the codec and i2s bus; add another node to represent
> > the sound circuit. All that node would need is a unique compatible
> > property and a phandle to either the i2s bus or the codec (depending
> > on which binding approach is used). It could have additional
> > properties to represent optional features, etc.
>
> That's the pseudo-sound node proposal that other people objected to.
>
Heh, I'm one of the folks who objected to it; here's what was written:
> > >
> > > pseudo-sound@0 { // use to trigger loading platform specific fabric driver
> > > device_type = "pseudo-sound"
> > > };
> >
> > I don't think this is a good idea. The device tree is for describing
> > your hardware; so the layout should reflect that. Make the platform
> > code do the right thing with the real nodes.
What I objected to was that the pseudo-sound node didn't contain any
real information. It was just being a hook to trigger calling a probe
function. If you're going to do that then you might as well just call
it directly from platform code.
> > For example:
> > sound@0 {
> > compatible = "<mfg>,<board>,sound" // The board might have
> > more than one sound i/f which could be wired differently
> > codec-handle = <&codec0>;
> > };
The difference here is that the node provides real information about
the board. It has a compatible field which tells you *exactly* what
sound circuit is present on the board. It can have additional
information that does make sense to encode into the device tree (ie.
the codec that is used). It's not addressable (no registers or
anything), but it does describe the board.
It would be possible and reasonable for a single fabric driver to work
with many different circuit layouts as long as it has the information
needed to adapt each instance.
>
> Do you even need the parameters, how about simply this?
>
> sound-fabric {
> };
But this goes back to having nodes that don't provide any information.
You don't want that.
>
> That will trigger loading all of the sound-fabric drivers built into
> the kernel. In their probe functions they can look in the device tree
> and extract the machine name and then decide to stay loaded or fail
> the probe.
>
...
Now is probably a good time to mention that there is *nothing* in the
device tree that enforces a 1:1 relationship between device tree nodes
and driver instances. Sure, it make sense to register the i2s and
codec drivers from probing on the i2s and codec nodes. However, there
is nothing that prevents the codec driver from *also* registering a
fabric driver based on a property in the codec node or the board-level
compatible property.
Fabric drivers are codec specific anyway. It's not all that
unrealistic for the device tree binding for a codec to have a list of
fabric drivers that it can register.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 2/2] PowerPC: Update USB OHCI DTS entires for new bindings
From: Valentine Barshak @ 2007-10-24 16:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tnt, linux-usb-devel
In-Reply-To: <20071024162223.GA17649@ru.mvista.com>
Adjust mpc52xx DTS entries to support reworked ohci-ppc-of driver.
Use compatible "usb-ohci" and an empty big-endian property for
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO support.
This also adds OHCI DTS entry for Sequoia PowerPC 440EPx board.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/dts/lite5200.dts | 5 +++--
arch/powerpc/boot/dts/lite5200b.dts | 5 +++--
arch/powerpc/boot/dts/sequoia.dts | 8 ++++++++
3 files changed, 14 insertions(+), 4 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/lite5200b.dts linux-2.6/arch/powerpc/boot/dts/lite5200b.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/lite5200b.dts 2007-10-24 18:44:00.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/lite5200b.dts 2007-10-24 19:20:31.000000000 +0400
@@ -183,8 +183,9 @@
};
usb@1000 {
- device_type = "usb-ohci-be";
- compatible = "mpc5200b-ohci","mpc5200-ohci","ohci-be";
+ device_type = "usb-ohci";
+ compatible = "mpc5200b-usb-ohci","mpc5200-usb-ohci","usb-ohci";
+ big-endian;
reg = <1000 ff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/lite5200.dts linux-2.6/arch/powerpc/boot/dts/lite5200.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/lite5200.dts 2007-10-24 18:44:00.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/lite5200.dts 2007-10-24 19:21:57.000000000 +0400
@@ -183,8 +183,9 @@
};
usb@1000 {
- device_type = "usb-ohci-be";
- compatible = "mpc5200-ohci","ohci-be";
+ device_type = "usb-ohci";
+ compatible = "mpc5200-usb-ohci","usb-ohci";
+ big-endian;
reg = <1000 ff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-10-24 18:44:00.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-10-24 19:30:36.000000000 +0400
@@ -122,6 +122,14 @@
interrupt-map-mask = <ffffffff>;
};
+ USB1: usb@e0000400 {
+ compatible = "usb-ohci-440epx", "usb-ohci";
+ reg = <0 e0000400 60>;
+ big-endian;
+ interrupt-parent = <&UIC0>;
+ interrupts = <15 8>;
+ };
+
POB0: opb {
compatible = "ibm,opb-440epx", "ibm,opb";
#address-cells = <1>;
^ permalink raw reply
* [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-10-24 16:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tnt, linux-usb-devel
In-Reply-To: <20071024162223.GA17649@ru.mvista.com>
Rework ohci-ppc-of driver to use big-endian property instead of
ohci-be/ohci-le compatible strings. Also remove unnecessary
user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/usb/host/Kconfig | 17 +++--------------
drivers/usb/host/ohci-ppc-of.c | 38 ++++++--------------------------------
2 files changed, 9 insertions(+), 46 deletions(-)
diff -pruN linux-2.6.orig/drivers/usb/host/Kconfig linux-2.6/drivers/usb/host/Kconfig
--- linux-2.6.orig/drivers/usb/host/Kconfig 2007-10-24 18:44:25.000000000 +0400
+++ linux-2.6/drivers/usb/host/Kconfig 2007-10-24 19:37:18.000000000 +0400
@@ -128,23 +128,12 @@ config USB_OHCI_HCD_PPC_OF
bool "OHCI support for PPC USB controller on OF platform bus"
depends on USB_OHCI_HCD && PPC_OF
default y
+ select USB_OHCI_BIG_ENDIAN_DESC
+ select USB_OHCI_BIG_ENDIAN_MMIO
---help---
Enables support for the USB controller PowerPC present on the
OpenFirmware platform bus.
-config USB_OHCI_HCD_PPC_OF_BE
- bool "Support big endian HC"
- depends on USB_OHCI_HCD_PPC_OF
- default y
- select USB_OHCI_BIG_ENDIAN_DESC
- select USB_OHCI_BIG_ENDIAN_MMIO
-
-config USB_OHCI_HCD_PPC_OF_LE
- bool "Support little endian HC"
- depends on USB_OHCI_HCD_PPC_OF
- default n
- select USB_OHCI_LITTLE_ENDIAN
-
config USB_OHCI_HCD_PCI
bool "OHCI support for PCI-bus USB controllers"
depends on USB_OHCI_HCD && PCI && (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF)
@@ -180,7 +169,7 @@ config USB_OHCI_BIG_ENDIAN_MMIO
config USB_OHCI_LITTLE_ENDIAN
bool
depends on USB_OHCI_HCD
- default n if STB03xxx || PPC_MPC52xx
+ default n if STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF
default y
config USB_UHCI_HCD
diff -pruN linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c linux-2.6/drivers/usb/host/ohci-ppc-of.c
--- linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c 2007-10-24 18:44:25.000000000 +0400
+++ linux-2.6/drivers/usb/host/ohci-ppc-of.c 2007-10-24 19:32:21.000000000 +0400
@@ -15,8 +15,8 @@
#include <linux/signal.h>
-#include <asm/of_platform.h>
-#include <asm/prom.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
static int __devinit
@@ -91,15 +91,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
int irq;
int rv;
- int is_bigendian;
if (usb_disabled())
return -ENODEV;
- is_bigendian =
- of_device_is_compatible(dn, "ohci-bigendian") ||
- of_device_is_compatible(dn, "ohci-be");
-
dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
rv = of_address_to_resource(dn, 0, &res);
@@ -134,9 +129,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
}
ohci = hcd_to_ohci(hcd);
- if (is_bigendian) {
+
+ if (of_get_property(dn, "big-endian", NULL)) {
ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
- if (of_device_is_compatible(dn, "mpc5200-ohci"))
+ if (of_device_is_compatible(dn, "mpc5200-usb-ohci"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
}
@@ -187,35 +183,13 @@ static int ohci_hcd_ppc_of_shutdown(stru
static struct of_device_id ohci_hcd_ppc_of_match[] = {
-#ifdef CONFIG_USB_OHCI_HCD_PPC_OF_BE
- {
- .name = "usb",
- .compatible = "ohci-bigendian",
- },
- {
- .name = "usb",
- .compatible = "ohci-be",
- },
-#endif
-#ifdef CONFIG_USB_OHCI_HCD_PPC_OF_LE
- {
- .name = "usb",
- .compatible = "ohci-littledian",
- },
{
- .name = "usb",
- .compatible = "ohci-le",
+ .compatible = "usb-ohci",
},
-#endif
{},
};
MODULE_DEVICE_TABLE(of, ohci_hcd_ppc_of_match);
-#if !defined(CONFIG_USB_OHCI_HCD_PPC_OF_BE) && \
- !defined(CONFIG_USB_OHCI_HCD_PPC_OF_LE)
-#error "No endianess selected for ppc-of-ohci"
-#endif
-
static struct of_platform_driver ohci_hcd_ppc_of_driver = {
.name = "ppc-of-ohci",
^ permalink raw reply
* [PATCH 0/2] USB: Rework OHCI PPC OF driver to support new bindings
From: Valentine Barshak @ 2007-10-24 16:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tnt, linux-usb-devel
These patches update ohci-ppc-of and the dts files for the new bindings.
The "compatible" is set to "usb-ohci" and the "big-endian" quirkiness is
expressed by a property, not by the "compatible" name.
Also user-selectable USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE config
options are removed, since the USB_OHCI_BIG_ENDIAN/USB_OHCI_LITTLE_ENDIAN
selection is made by default for PPC/PCI OHCI controllers.
^ permalink raw reply
* Re: linux-2.6.git: cannot build PS3 image
From: Geert Uytterhoeven @ 2007-10-24 16:26 UTC (permalink / raw)
To: Scott Wood; +Cc: Linux/PPC Development
In-Reply-To: <47162BC4.2090907@freescale.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1929 bytes --]
On Wed, 17 Oct 2007, Scott Wood wrote:
> Geert Uytterhoeven wrote:
> >> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> >> index 39b27e5..795f988 100755
> >> --- a/arch/powerpc/boot/wrapper
> >> +++ b/arch/powerpc/boot/wrapper
> >> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
> >> entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
> >>
> >> if [ -n "$binary" ]; then
> >> - mv "$ofile" "$ofile".elf
> >> + cp "$ofile" "$ofile".elf
> >> ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
> >> fi
> >
> > No comments?
>
> That'd work in this case, though it'd probably be better to make the
> $ofile be the end result that will boot on the ps3, and leave a suffix
> on the intermediate files.
The $ofile is the end result to boot using kboot (2nd stage kernel).
otheros.bld is the end result to write to FLASH ROM (1st stage kernel).
The funny thing is that we pass `-o arch/powerpc/boot/zImage.ps3' to the
wrapper script (which indicates the _output_ file, i.e. $ofile, as per the
documentation at the top of the wrapper script), while this output file is
no longer created by the wrapper script!
Instead it creates arch/powerpc/boot/zImage.ps3.elf.
So I do think your change broke the expected and obvious behavior.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 16:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710240854y6ac115b6i5e0400eb369fcf7@mail.gmail.com>
Jon Smirl wrote:
> It makes sense to me, there needs to be some way to trigger loading
> the fabric driver.
Well, you only really two have choices:
1) Probe on the AC97/SSI nodes
2) When the driver initializes, just scan all the nodes in the device tree (no
probing).
I think option #2 makes the most sense, because option #1 says that your fabric
driver is really an AC97 driver, which it isn't.
You can try to make the fabric driver into a bus driver, but I think that just
complicates things.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 15:54 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240843r5271c749m33bce043702603b7@mail.gmail.com>
On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Do you want to pick one and add it to the device tree documentation
> > with an example for i2s and ac97? I'll use which ever one is picked.
>
> Sure, I'll draft something up and post it for review.
>
> On the device probing front; what about this method:
>
> Rather than trying to figure things out from the board model, or the
> combination of the codec and i2s bus; add another node to represent
> the sound circuit. All that node would need is a unique compatible
> property and a phandle to either the i2s bus or the codec (depending
> on which binding approach is used). It could have additional
> properties to represent optional features, etc.
That's the pseudo-sound node proposal that other people objected to.
It makes sense to me, there needs to be some way to trigger loading
the fabric driver.
>
> For example:
> sound@0 {
> compatible = "<mfg>,<board>,sound" // The board might have
> more than one sound i/f which could be wired differently
> codec-handle = <&codec0>;
> };
Do you even need the parameters, how about simply this?
sound-fabric {
};
That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.
> This would give your fabric driver something unique to probe on; but
> the i2c, i2s and codec nodes which actually describe interconnects
> will still be present.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:54 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F6761.3030405@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > I see your point about putting the child node onto the control bus.
> > ac97 is both a control and data bus. For the i2s case the child should
> > go onto the i2c bus.
>
> I know AC97 is *also* a control bus, but treating I2S and AC97 differently is
> bad, IMHO. If you're going to put the child node in the AC97 node, you should
> also put it in the I2S node.
They *are* different. The choice you're making is whether or not you
keep them similar in the control path or the data path; but you still
have to choose.
>
> The 8610 has an SSI that can operate as either AC97 or I2S. If I want to switch
> from AC97 to I2S, I should not have to move the child node out of the AC97 node.
> I should instead just add an I2C node and point to it.
But you need a different codec node regardless. The board/system will
in the vast majority of cases designed to only use AC97 or only use
I2S. It's not moving a node. It's deleting an ac97 codec node and
adding an i2s codec node.
Besides; correctness is more important that how many device tree
changes need to be made to go from one board design to another.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [patch v3] Cell: Wrap master run control bit
From: Geert Uytterhoeven @ 2007-10-24 15:53 UTC (permalink / raw)
To: Jeremy Kerr
Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Arnd Bergmann,
Cell Broadband Engine OSS Development
In-Reply-To: <46F6D188.7090201@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 9828 bytes --]
On Sun, 23 Sep 2007, Geoff Levand wrote:
> Subject: Cell: Wrap master run control bit
>
> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>
> Add platform specific SPU run control routines to the spufs. The current
> spufs implementation uses the SPU master run control bit (MFC_SR1[S]) to
> control SPE execution, but the PS3 hypervisor does not support the use of
> this feature.
>
> This change adds the run control wrapper routies spu_enable_spu() and
> spu_disable_spu(). The bare metal routines use the master run control
> bit, and the PS3 specific routines use the priv2 run control register.
>
> An outstanding enhancement for the PS3 would be to add a guard to check
> for incorrect access to the spu problem state when the spu context is
> disabled. This check could be implemented with a flag added to the spu
> context that would inhibit mapping problem state pages, and a routine
> to unmap spu problem state pages. When the spu is enabled with
> ps3_enable_spu() the flag would be set allowing pages to be mapped,
> and when the spu is disabled with ps3_disable_spu() the flag would be
> cleared and mapped problem state pages would be unmapped.
>
> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
>
> Jeremy,
>
> Here is an updated version for 2.6.24. Noguchi-san will
As 2.6.24-rc1 is out and Geoff is offline: what's the status of this patch?
> work on the LS unmapping feature for 2.6.25.
>
> -Geoff
>
> v2:
> o Added comments about unmapping PS pages when disabled.
> v3:
> o Changed routines to return void instead of int.
> o Rebased to apply to Jeremy's 2.6.23-rc work-around.
>
> arch/powerpc/platforms/cell/spu_manage.c | 13 +++++++++++
> arch/powerpc/platforms/cell/spufs/backing_ops.c | 6 +++++
> arch/powerpc/platforms/cell/spufs/hw_ops.c | 10 ++++++++
> arch/powerpc/platforms/cell/spufs/run.c | 4 +--
> arch/powerpc/platforms/cell/spufs/spufs.h | 1
> arch/powerpc/platforms/ps3/spu.c | 27 ++++++++++++++++++++++--
> include/asm-powerpc/spu_priv1.h | 15 +++++++++++++
> 7 files changed, 72 insertions(+), 4 deletions(-)
>
> --- a/arch/powerpc/platforms/cell/spu_manage.c
> +++ b/arch/powerpc/platforms/cell/spu_manage.c
> @@ -35,6 +35,7 @@
> #include <asm/firmware.h>
> #include <asm/prom.h>
>
> +#include "spufs/spufs.h"
> #include "interrupt.h"
>
> struct device_node *spu_devnode(struct spu *spu)
> @@ -369,6 +370,16 @@ static int of_destroy_spu(struct spu *sp
> return 0;
> }
>
> +static void enable_spu_by_master_run(struct spu_context *ctx)
> +{
> + ctx->ops->master_start(ctx);
> +}
> +
> +static void disable_spu_by_master_run(struct spu_context *ctx)
> +{
> + ctx->ops->master_stop(ctx);
> +}
> +
> /* 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 };
> @@ -535,5 +546,7 @@ const struct spu_management_ops spu_mana
> .enumerate_spus = of_enumerate_spus,
> .create_spu = of_create_spu,
> .destroy_spu = of_destroy_spu,
> + .enable_spu = enable_spu_by_master_run,
> + .disable_spu = disable_spu_by_master_run,
> .init_affinity = init_affinity,
> };
> --- a/arch/powerpc/platforms/cell/spufs/backing_ops.c
> +++ b/arch/powerpc/platforms/cell/spufs/backing_ops.c
> @@ -285,6 +285,11 @@ static void spu_backing_runcntl_write(st
> spin_unlock(&ctx->csa.register_lock);
> }
>
> +static void spu_backing_runcntl_stop(struct spu_context *ctx)
> +{
> + spu_backing_runcntl_write(ctx, SPU_RUNCNTL_STOP);
> +}
> +
> static void spu_backing_master_start(struct spu_context *ctx)
> {
> struct spu_state *csa = &ctx->csa;
> @@ -381,6 +386,7 @@ struct spu_context_ops spu_backing_ops =
> .get_ls = spu_backing_get_ls,
> .runcntl_read = spu_backing_runcntl_read,
> .runcntl_write = spu_backing_runcntl_write,
> + .runcntl_stop = spu_backing_runcntl_stop,
> .master_start = spu_backing_master_start,
> .master_stop = spu_backing_master_stop,
> .set_mfc_query = spu_backing_set_mfc_query,
> --- a/arch/powerpc/platforms/cell/spufs/hw_ops.c
> +++ b/arch/powerpc/platforms/cell/spufs/hw_ops.c
> @@ -220,6 +220,15 @@ static void spu_hw_runcntl_write(struct
> spin_unlock_irq(&ctx->spu->register_lock);
> }
>
> +static void spu_hw_runcntl_stop(struct spu_context *ctx)
> +{
> + spin_lock_irq(&ctx->spu->register_lock);
> + out_be32(&ctx->spu->problem->spu_runcntl_RW, SPU_RUNCNTL_STOP);
> + while (in_be32(&ctx->spu->problem->spu_status_R) & SPU_STATUS_RUNNING)
> + cpu_relax();
> + spin_unlock_irq(&ctx->spu->register_lock);
> +}
> +
> static void spu_hw_master_start(struct spu_context *ctx)
> {
> struct spu *spu = ctx->spu;
> @@ -321,6 +330,7 @@ struct spu_context_ops spu_hw_ops = {
> .get_ls = spu_hw_get_ls,
> .runcntl_read = spu_hw_runcntl_read,
> .runcntl_write = spu_hw_runcntl_write,
> + .runcntl_stop = spu_hw_runcntl_stop,
> .master_start = spu_hw_master_start,
> .master_stop = spu_hw_master_stop,
> .set_mfc_query = spu_hw_set_mfc_query,
> --- a/arch/powerpc/platforms/cell/spufs/run.c
> +++ b/arch/powerpc/platforms/cell/spufs/run.c
> @@ -302,7 +302,7 @@ long spufs_run_spu(struct spu_context *c
> if (mutex_lock_interruptible(&ctx->run_mutex))
> return -ERESTARTSYS;
>
> - ctx->ops->master_start(ctx);
> + spu_enable_spu(ctx);
> ctx->event_return = 0;
>
> spu_acquire(ctx);
> @@ -376,7 +376,7 @@ long spufs_run_spu(struct spu_context *c
> ctx->stats.libassist++;
>
>
> - ctx->ops->master_stop(ctx);
> + spu_disable_spu(ctx);
> ret = spu_run_fini(ctx, npc, &status);
> spu_yield(ctx);
>
> --- a/arch/powerpc/platforms/cell/spufs/spufs.h
> +++ b/arch/powerpc/platforms/cell/spufs/spufs.h
> @@ -170,6 +170,7 @@ struct spu_context_ops {
> char*(*get_ls) (struct spu_context * ctx);
> u32 (*runcntl_read) (struct spu_context * ctx);
> void (*runcntl_write) (struct spu_context * ctx, u32 data);
> + void (*runcntl_stop) (struct spu_context * ctx);
> void (*master_start) (struct spu_context * ctx);
> void (*master_stop) (struct spu_context * ctx);
> int (*set_mfc_query)(struct spu_context * ctx, u32 mask, u32 mode);
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -28,6 +28,7 @@
> #include <asm/spu_priv1.h>
> #include <asm/lv1call.h>
>
> +#include "../cell/spufs/spufs.h"
> #include "platform.h"
>
> /* spu_management_ops */
> @@ -419,10 +420,34 @@ static int ps3_init_affinity(void)
> return 0;
> }
>
> +/**
> + * ps3_enable_spu - Enable SPU run control.
> + *
> + * An outstanding enhancement for the PS3 would be to add a guard to check
> + * for incorrect access to the spu problem state when the spu context is
> + * disabled. This check could be implemented with a flag added to the spu
> + * context that would inhibit mapping problem state pages, and a routine
> + * to unmap spu problem state pages. When the spu is enabled with
> + * ps3_enable_spu() the flag would be set allowing pages to be mapped,
> + * and when the spu is disabled with ps3_disable_spu() the flag would be
> + * cleared and the mapped problem state pages would be unmapped.
> + */
> +
> +static void ps3_enable_spu(struct spu_context *ctx)
> +{
> +}
> +
> +static void ps3_disable_spu(struct spu_context *ctx)
> +{
> + ctx->ops->runcntl_stop(ctx);
> +}
> +
> const struct spu_management_ops spu_management_ps3_ops = {
> .enumerate_spus = ps3_enumerate_spus,
> .create_spu = ps3_create_spu,
> .destroy_spu = ps3_destroy_spu,
> + .enable_spu = ps3_enable_spu,
> + .disable_spu = ps3_disable_spu,
> .init_affinity = ps3_init_affinity,
> };
>
> @@ -505,8 +530,6 @@ static void mfc_sr1_set(struct spu *spu,
> static const u64 allowed = ~(MFC_STATE1_LOCAL_STORAGE_DECODE_MASK
> | MFC_STATE1_PROBLEM_STATE_MASK);
>
> - sr1 |= MFC_STATE1_MASTER_RUN_CONTROL_MASK;
> -
> BUG_ON((sr1 & allowed) != (spu_pdata(spu)->cache.sr1 & allowed));
>
> spu_pdata(spu)->cache.sr1 = sr1;
> --- a/include/asm-powerpc/spu_priv1.h
> +++ b/include/asm-powerpc/spu_priv1.h
> @@ -24,6 +24,7 @@
> #include <linux/types.h>
>
> struct spu;
> +struct spu_context;
>
> /* access to priv1 registers */
>
> @@ -178,6 +179,8 @@ 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);
> + void (*enable_spu)(struct spu_context *ctx);
> + void (*disable_spu)(struct spu_context *ctx);
> int (*init_affinity)(void);
> };
>
> @@ -207,6 +210,18 @@ spu_init_affinity (void)
> return spu_management_ops->init_affinity();
> }
>
> +static inline void
> +spu_enable_spu (struct spu_context *ctx)
> +{
> + spu_management_ops->enable_spu(ctx);
> +}
> +
> +static inline void
> +spu_disable_spu (struct spu_context *ctx)
> +{
> + spu_management_ops->disable_spu(ctx);
> +}
> +
> /*
> * The declarations folowing are put here for convenience
> * and only intended to be used by the platform setup code.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710240828x412f598dy7fc4a75faa76358d@mail.gmail.com>
On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > Two valid methods have been proposed
> > > 1. a codec-
> >
> > oops
> >
> > 1. a codec-handle property in the i2s node
> > 2. an i2s-handle property in the codec node
> >
> > Either are reasonable. I prefer putting the handle in the i2s node;
> > but I'm looking at it from the way that ethernet phys are being
> > described currently. The other is also perfectly valid.
> >
> > I suppose it depends on what point of view you see the system from; either:
> > a. the codec is supported by the i2s bus, in which case use the
> > i2s-handle property
> > b. the i2s bus is supported by the codec; in which case use the
> > codec-handle property.
>
> Do you want to pick one and add it to the device tree documentation
> with an example for i2s and ac97? I'll use which ever one is picked.
Sure, I'll draft something up and post it for review.
On the device probing front; what about this method:
Rather than trying to figure things out from the board model, or the
combination of the codec and i2s bus; add another node to represent
the sound circuit. All that node would need is a unique compatible
property and a phandle to either the i2s bus or the codec (depending
on which binding approach is used). It could have additional
properties to represent optional features, etc.
For example:
sound@0 {
compatible = "<mfg>,<board>,sound" // The board might have
more than one sound i/f which could be wired differently
codec-handle = <&codec0>;
};
This would give your fabric driver something unique to probe on; but
the i2c, i2s and codec nodes which actually describe interconnects
will still be present.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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