* Re: [PATCH 0/2] mpc52xx: stop drivers from accessing clock config directly
From: Grant Likely @ 2007-10-24 20:14 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev
In-Reply-To: <20071024191206.GD3369@nd47.coderock.org>
On 10/24/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> 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?)
Hmm, I guess that's right. Can you at least make sure it still boots
on Efika? Some of the clock detection stuff has changed so I want to
make sure it still boots.
Are you setup to do your SPI test easily on you lite5200b? When I say
"somewhat" tested; I mean I probed the driver and it didn't crash.
:-) I haven't tried to run traffic over it.
Can you check that on your system? If not, can you email me what
setup/programs you used for testing? I know very little about the SPI
infrastructure.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Olof Johansson @ 2007-10-24 20:19 UTC (permalink / raw)
To: Tony Breeds; +Cc: paulus, linuxppc-dev
In-Reply-To: <20071017060747.GF9814@bakeyournoodle.com>
On Wed, Oct 17, 2007 at 04:07:48PM +1000, Tony Breeds wrote:
> On Tue, Oct 16, 2007 at 03:25:25PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > Not sure when this started happening, but I wanted to report it. I'll
> > start bisecting in a day or two if noone else has gotten around to
> > looking at it:
> >
> > $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> > $ time ./a.out & sleep 2 ; killall a.out
> > real 0m2.008s
> > user 0m4.014s
> > sys 0m0.002s
> >
> > Seen on POWER5 and PA6T, haven't tried anything else yet.
>
> For what it's worth, this is my bug. I suspected it, and git bisect
> confirmed it.I have an ugly work around now, but hope to have something
> better out tomorrow.
Hi Tony,
Any news?
-Olof
^ permalink raw reply
* problems to boot 2.6.23 kernel on XILINX ppc with 8Mbytes of RAM
From: manu @ 2007-10-24 20:01 UTC (permalink / raw)
To: Linuxppc-embedded
Hello,
I work on a custom board based on a virtex 2 pro FPGA and 8Mbytes of SDRAM.
Untill now I used a 2.4.31 linux ppc kernel with John Williams patches
and uclinux distribution and everything worked perfectly.
I've decided to move to the latest 2.6 version from kernel.org
(2.6.23.1) with an initramfs containing a busybox.
My complete zImage including the initramfs has a size of 900Kbytes.
I made some tests with a ML300 board and I managed to get a shell easily.
When I migrated to the custom board, I had the "Now booting the kernel"
message and then nothing.
When I trace the code running on the ppc with the debugger, execution
seems to be stuck in some early initialization code.
I managed to reproduce the problem on the ML300 using "mem=8m" parameter
on the bootline.
With "mem=16m" the kernel boots correctly.
I'm really surprised by the amount of RAM required to boot the kernel.
Is there a way to make it boot with only 8Mbytes of RAM ?
Thanks for your help.
Manu
^ permalink raw reply
* Apparent kernel bug with GDB on ppc405
From: Matt Mackall @ 2007-10-24 19:46 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: gdb
I'm trying to debug a trivial statically-linked hello world program on
a Xilinx PPC 405 and I'm seeing the following behavior:
With direct gdb on target, I can set a breakpoint at main, run, and
the breakpoint is triggered.
With gdbserver and gdb with "target remote localhost:1234", the above
still works.
With gdb on target redirected to a PC and tunneled back
to the target, everything still works.
With gdb on a PC, execution continues past the breakpoint. Comparing
the gdb protocol streams here and and on the previous (working) case
are identical up to the point of hitting the breakpoint (which never
happens in the latter case).
Raising the load on the PC to 4 and running gdb under nice -n 19 makes
things work again. So this begins to look like a kernel cache or
timing bug rather than a problem with the PC tool. It appears that the
breakpoint written to the executable at continue time is not visible
to the CPU at execute time.
My first suspicion was a dcache/icache coherency issue in
copy_to_user_page, so I added flush_dcache_icache_page(page) here to
no avail. On closer inspection, it looks like both icache and dcache
are already being flushed by flush_icache_user_range().
Adding printk(".") (or any printk) in this function here fixes things
(serial console at 115k), while printk("") and udelay(100) do not.
Which still suggests an icache bug..?
Any suggestions?
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 19:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F9FE5.7040808@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > Why are you using a vendor named directory? I don't believe vendor
> > named directories are used anywhere in the kernel. The directories are
> > always named after the platform or architecture. Vendor directories
> > end up in a big mess if Freescale decides to sell a CPU to someone
> > else.
>
> Two reasons:
>
> 1) The sound/soc directory already has names like "at91" and "pxa", so I thought
> "fsl" is appropriate.
pxa is the processor family. Intel sold the pxa cpus to Marvell six months ago.
>
> 2) There may not be any directories named "fsl", but there are plenty of files
> with that name:
>
> ./arch/powerpc/boot/fsl-soc.c
> ./arch/powerpc/boot/fsl-soc.h
> ./arch/powerpc/boot/fsl-soc.o
> ./arch/powerpc/mm/fsl_booke_mmu.c
> ./arch/powerpc/platforms/fsl_uli1575.c
> ./arch/powerpc/sysdev/fsl_pci.c
> ./arch/powerpc/sysdev/fsl_pci.h
> ./arch/powerpc/sysdev/fsl_soc.c
> ./arch/powerpc/sysdev/fsl_soc.h
> ./arch/powerpc/sysdev/fsl_soc.o
> ./arch/ppc/mm/fsl_booke_mmu.c
> ./drivers/usb/gadget/fsl_usb2_udc.c
> ./drivers/usb/gadget/fsl_usb2_udc.h
> ./include/linux/fsl_devices.h
> ./include/config/fsl
>
> Having said all that, if you really think sound/soc/powerpc is better than
> sound/soc/fsl, I won't complain.
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 19:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710241231h9427223kbfcc23be2e111194@mail.gmail.com>
Jon Smirl wrote:
> Why are you using a vendor named directory? I don't believe vendor
> named directories are used anywhere in the kernel. The directories are
> always named after the platform or architecture. Vendor directories
> end up in a big mess if Freescale decides to sell a CPU to someone
> else.
Two reasons:
1) The sound/soc directory already has names like "at91" and "pxa", so I thought
"fsl" is appropriate.
2) There may not be any directories named "fsl", but there are plenty of files
with that name:
./arch/powerpc/boot/fsl-soc.c
./arch/powerpc/boot/fsl-soc.h
./arch/powerpc/boot/fsl-soc.o
./arch/powerpc/mm/fsl_booke_mmu.c
./arch/powerpc/platforms/fsl_uli1575.c
./arch/powerpc/sysdev/fsl_pci.c
./arch/powerpc/sysdev/fsl_pci.h
./arch/powerpc/sysdev/fsl_soc.c
./arch/powerpc/sysdev/fsl_soc.h
./arch/powerpc/sysdev/fsl_soc.o
./arch/ppc/mm/fsl_booke_mmu.c
./drivers/usb/gadget/fsl_usb2_udc.c
./drivers/usb/gadget/fsl_usb2_udc.h
./include/linux/fsl_devices.h
./include/config/fsl
Having said all that, if you really think sound/soc/powerpc is better than
sound/soc/fsl, I won't complain.
^ permalink raw reply
* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 19:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F7D28.6050107@freescale.com>
On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> 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.
Why are you using a vendor named directory? I don't believe vendor
named directories are used anywhere in the kernel. The directories are
always named after the platform or architecture. Vendor directories
end up in a big mess if Freescale decides to sell a CPU to someone
else.
>
> > 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.
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Valentine Barshak @ 2007-10-24 19:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese, jeff, netdev
In-Reply-To: <1193196718.2085.35.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-23 at 20:57 -0500, Valentine Barshak wrote:
>
>> +static int m88e1111_init(struct mii_phy *phy)
>> +{
>> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
>> + phy_write(phy, 0x14, 0x0ce3);
>> + phy_write(phy, 0x18, 0x4101);
>> + phy_write(phy, 0x09, 0x0e00);
>> + phy_write(phy, 0x04, 0x01e1);
>> + phy_write(phy, 0x00, 0x9140);
>> + phy_write(phy, 0x00, 0x1140);
>> +
>> + return 0;
>> +}
>
> Care to put a few comments on why the above is necessary and what it
> does ?
I think this set's up Marvell ext control (0x14) and led control (0x18)
registers with some default values, Also sets some bits in the
CTRL1000, ADVERTISE and basic mode control registers and resets the phy
for the changes to take effect. Unfortunately, I don't have a detailed
88E1111 description and can't tell anything about it. Looks like the
code was originally ported from u-boot and is needed to init the phy :)
Stefan, do you have any info on this?
Thanks,
Valentine.
>
> Thanks !
> Ben.
>
>> +static struct mii_phy_ops m88e1111_phy_ops = {
>> + .init = m88e1111_init,
>> + .setup_aneg = genmii_setup_aneg,
>> + .setup_forced = genmii_setup_forced,
>> + .poll_link = genmii_poll_link,
>> + .read_link = genmii_read_link
>> +};
>> +
>> +static struct mii_phy_def m88e1111_phy_def = {
>> +
>> + .phy_id = 0x01410CC0,
>> + .phy_id_mask = 0x0ffffff0,
>> + .name = "Marvell 88E1111 Ethernet",
>> + .ops = &m88e1111_phy_ops,
>> +};
>> +
>> static struct mii_phy_def *mii_phy_table[] = {
>> &cis8201_phy_def,
>> + &bcm5248_phy_def,
>> + &m88e1111_phy_def,
>> &genmii_phy_def,
>> NULL
>> };
>
^ permalink raw reply
* 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
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