Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Hello Scott,
Scott Wood wrote:
On Wed, Jan 09, 2008 at 01:58:49PM +0100, Heiko Schocher wrote:
@@ -1312,6 +1312,9 @@ static int __devinit fs_enet_probe(struct of_device
*ofdev,
ndev-dev_addr[0], ndev-dev_addr[1], ndev-dev_addr[2],
ndev-dev_addr[3], ndev-dev_addr[4], ndev-dev_addr[5]);
+/* to initialize the fep-cur_rx,... */
+/* not doing this, will cause a crash in fs_enet_rx_napi */
+fs_init_bds(ndev);
return 0;
We don't want to allocate ring buffers for network interfaces that are never
opened, especially given the small amount of memory on some boards that use
this driver.
Instead, we should probably not be calling napi_enable() until the link is
up and init_bds() has been called.
Ah, okay. I actually tried calling fs_init_bds(ndev); in fs_enet_open() after
napi_enable, and this also works fine. I think there is the better place for
it. Thanks.
@@ -1342,9 +1345,13 @@ static int fs_enet_remove(struct of_device *ofdev)
}
static struct of_device_id fs_enet_match[] = {
-#ifdef CONFIG_FS_ENET_HAS_SCC
+#if defined(CONFIG_FS_ENET_HAS_SCC)
{
+#if defined(CONFIG_CPM1)
.compatible = fsl,cpm1-scc-enet,
+#else
+.compatible = fsl,cpm2-scc-enet,
+#endif
I know there are already ifdefs of this sort, and that multiplatform
cpm1/cpm2 is very unlikely to ever happen, but can we try to avoid
introducing more such ifdefs?
We can have both match entries present at the same time.
OK, fix this.
.data = (void *)fs_scc_ops,
},
#endif
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 48f2f30..3b5ca76 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -50,6 +50,7 @@
#include fs_enet.h
/*/
+#define SCC_EB ((u_char)0x10) /* Set big endian byte order */
This is already defined in asm-powerpc/commproc.h, and thus will cause a
duplicate definition when building for 8xx. Please add this definition to
asm-powerpc/cpm2.h.
OK, will fix it.
+#if defined(CONFIG_CPM1)
W16(cpmp, cp_cpcr, fpi-cp_command | CPM_CR_FLG | (op 8));
for (i = 0; i MAX_CR_CMD_LOOPS; i++)
if ((R16(cpmp, cp_cpcr) CPM_CR_FLG) == 0)
return 0;
+#else
+W32(cpmp, cp_cpcr, fpi-cp_command | CPM_CR_FLG | op);
+for (i = 0; i MAX_CR_CMD_LOOPS; i++)
+if ((R32(cpmp, cp_cpcr) CPM_CR_FLG) == 0)
+return 0;
+
+#endif
Commit 362f9b6fa8c9670cc5496390845021c2865d049b in Paul's tree makes this
unnecessary.
Tried this patch, works fine for me :-)
@@ -306,8 +317,15 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifdef CONFIG_CPM2
+/* from oldstyle driver in arch/ppc */
+/* seems necessary */
+W8(ep, sen_genscc.scc_rfcr, SCC_EB | 0x20);
+W8(ep, sen_genscc.scc_tfcr, SCC_EB | 0x20);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
Please define 0x20 as SCC_GBL (Snooping Enabled) in cpm2.h, and
conditionalize this on #ifndef CONFIG_NOT_COHERENT_CACHE.
You can remove the comment; it's really necessary, not just seems so. :-)
OK, fix it.
Will resend this fixed patch.
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Hello Scott,
Heiko Schocher wrote:
Hello Scott,
[...]
Will resend this fixed patch.
Here it is:
[POWERPC] Fix Ethernet over SCC on a CPM2,
also Fix crash in fs_enet_rx_napi()
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..f432a18 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev)
if (fep-fpi-use_napi)
napi_enable(fep-napi);
+ /* to initialize the fep-cur_rx,... */
+ /* not doing this, will cause a crash in fs_enet_rx_napi */
+ fs_init_bds(fep-ndev);
+
/* Install our interrupt handler. */
r = fs_request_irq(dev, fep-interrupt, fs_enet-mac,
fs_enet_interrupt);
if (r != 0) {
@@ -982,6 +986,7 @@ static struct net_device *fs_init_instance(struct device
*dev,
fep = netdev_priv(ndev);
fep-dev = dev;
+ fep-ndev = ndev;
dev_set_drvdata(dev, ndev);
fep-fpi = fpi;
if (fpi-init_ioports)
@@ -1085,7 +1090,6 @@ static struct net_device *fs_init_instance(struct device
*dev,
}
registered = 1;
-
return ndev;
err:
@@ -1347,6 +1351,10 @@ static struct of_device_id fs_enet_match[] = {
.compatible = fsl,cpm1-scc-enet,
.data = (void *)fs_scc_ops,
},
+ {
+ .compatible = fsl,cpm2-scc-enet,
+ .data = (void *)fs_scc_ops,
+ },
#endif
#ifdef CONFIG_FS_ENET_HAS_FCC
{
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index fe3d8a6..3889271 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -50,7 +50,6 @@
#include fs_enet.h
/*/
-
#if defined(CONFIG_CPM1)
/* for a 8xx __raw_xxx's are sufficient */
#define __fs_out32(addr, x)__raw_writel(x, addr)
@@ -65,6 +64,8 @@
#define __fs_out16(addr, x)out_be16(addr, x)
#define __fs_in32(addr)in_be32(addr)
#define __fs_in16(addr)in_be16(addr)
+#define __fs_out8(addr, x) out_8(addr, x)
+#define __fs_in8(addr) in_8(addr)
#endif
/* write, read, set bits, clear bits */
@@ -297,8 +298,13 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifndef CONFIG_NOT_COHERENT_CACHE
+ W8(ep, sen_genscc.scc_rfcr, SCC_EB | SCC_GBL);
+ W8(ep, sen_genscc.scc_tfcr, SCC_EB | SCC_GBL);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
/* Set maximum bytes per receive buffer.
* This appears to be an Ethernet frame size, not the buffer
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index f1112c1..14c6496 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -375,6 +375,11 @@ typedef struct scc_param {
uintscc_tcrc; /* Internal */
} sccp_t;
+/* Function code bits.
+*/
+#define SCC_EB ((u_char) 0x10) /* Set big endian byte order */
+#define SCC_GBL((u_char) 0x20) /* Snooping enabled */
+
/* CPM Ethernet through SCC1.
*/
typedef struct scc_enet {
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote: David Woodhouse writes: It would be much better if the kernel would 'just work'. The ideal way of achieving that is for the firmware to be fixed -- but that's been promised for a long time now, and we just don't believe you any more. So working round it in the kernel seems to be the next best option. Does the efika use a boot wrapper? If so then putting the fixup in the boot wrapper might be better. No, it doesn't (at least for Fedora) -- we use yaboot. Perhaps we could make yaboot run the fixups? -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 4/4 v3] PS3: Add logical performance monitor driver support
On Wed, 9 Jan 2008, Geoff Levand wrote: --- /dev/null +++ b/drivers/ps3/ps3-lpm.c + * @node_id: The node id of a BE prosessor whos performance monitor this whose 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: [EMAIL PROTECTED] 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___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote: ASOC v2 is sitting on a Wolfson server out of tree. I have been using it for several months without problem. The pace of it being merged could probably be sped up. I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] add phy-handle property for fec_mpc52xx
On Wed, Jan 09, Grant Likely wrote: From: Olaf Hering [EMAIL PROTECTED] The new network driver fec_mpc52xx will not work on efika because the firmware does not provide all required properties. http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to create more properties. But only the phy stuff is required to get a working network. This should go into the kernel because its appearently impossible to boot the script via tftp and then load the real boot binary (yaboot or zimage). (Olaf's s-o-b line needs to go here) Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Olaf Hering [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
What is the review status of this series, should I post it again? On 12/19/07, Jon Smirl [EMAIL PROTECTED] wrote: Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed. Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in. The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading. The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing. -- Jon Smirl [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] Look for include files in the directory of the including file.
So, like, the other day David Gibson mumbled: The doubly-linked list is intended to make it easier to construct search path lists one-at-a-time from arguments in the proper order, without needing to reverse the list at the end. We've already got that problem with a bunch of the lists we create during parsing (we have several ugly add-to-end-of-singly-linked-list functions). Going to doubly-linked lists might not be a bad idea, but we should do it across the board, probably using the kernel's list.h or something like it. I would be happy to accept a kernel's-list.h-based refactoring for doubly linked lists after the imminent 1.1 release! jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC PATCH 2/2] Preserve scanner state when /include/ing.
So, like, the other day Scott Wood mumbled: This allows /include/s to work when in non-default states, such as PROPNODECHAR. We may want to use state stacks to get rid of BEGIN_DEFAULT() altogether... Signed-off-by: Scott Wood [EMAIL PROTECTED] Hmmm.. With this applied, I get the usual warning: CHK version_gen.h CC dtc-lexer.lex.o dtc-lexer.lex.c:1901: warning: 'yy_top_state' defined but not used *grumble* Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How complete should the DTS be?
On Thu, 10 Jan 2008 17:50:49 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote: On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote: David Gibson wrote: Hrm... I'd say this is not something which has a firm convention yet. It's going to become more of an issue once we get a macros system for dtc, so the 440EP macro would have all the devices, even if some are not connected on a given board. I'm contemplating suggesting that we adopt the status property from IEEE1275 to cover this. When I am laying out the dts, leaving out what isn't used makes the dts file cleaner, at least in my view. It doesn't hurt to have the second i2c bus there, but it also doesn't help and leaving it out points out that it is not used. When we get a macro system I assume the second i2c bus will be there but hidden by a macro. It will still be clean and shouldn't cause grief. Right, but if it is there we'll want to mark it as unused in some way so that the kernel doesn't waste resources attempting to drive it. Sure but I don't want to make it mandatory for people to put unused devices in. If the macro system brings them in, then yes, it's good to have a way to properly mark them unused. But people hand crafting DTS shouldn't have to bloat them. There is -one- case where you may want to put unused devices, is if you do some kind of resource management on that specific bus (like need to be able to dynamically allocate space on the bus). In this case, you want to know everything that's there and potentially decodes addresses to avoid collisions. There are other uses too. E.g. pin sharing between devices based on DIP switch settings. You'd want to enumerate all the devices, and then add 'status = failed-not-connected' to the ones that don't have pins. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3] [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
On 1/10/08, Stephen Rothwell [EMAIL PROTECTED] wrote:
Hi Grant,
On Wed, 09 Jan 2008 22:26:30 -0700 Grant Likely [EMAIL PROTECTED] wrote:
+mpc52xx_map_common_devices(void)
{
+ /* Clock Distribution Module, used by PSC clock setting function */
+ np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
What happens if we find no node?
Both of_iomap and of_put fail gracefully if np is NULL. IIRC that was
done on purpose so this exact thing could be done.
Users of mpc52xx_cdm (and the others done in this style) all check for
mpc52xx_cdm being NULL before dereferencing.
+ mpc52xx_cdm = of_iomap(np, 0);
+ of_node_put(np);
}
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTC v1.1.0-rc1 tagged!
Folks, I have tagged DTC v1.1.0-rc1 and pushed it out. Please verify that this is going to be a viable 1.1 release! Consider this the last call for features and first call for bug fixes for the 1.1 release. :-) Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 2/2] mpc52xx_psc_spi device driver must not touch port_config and cdm
Acked-by: Dragos Carp [EMAIL PROTECTED]
On Mon, 2008-01-07 at 12:07 -0700, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
It is dangerous for an mpc52xx device driver to modify the port_config
register. If the driver is probed incorrectly, it will change the pin
IO configuration in ways which may not be compatible with the board.
port_config should be set up by the bootloader, or failing that, in
the platform setup code in arch/powerpc/platforms/52xx.
Also, modifying CDM registers directly can cause a race condition with
other drivers. Instead call a common routine to modify CDM settings.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
drivers/spi/mpc52xx_psc_spi.c | 77
+
1 files changed, 2 insertions(+), 75 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index a3ebc63..253ed56 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -330,80 +330,13 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device
*spi)
static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi
*mps)
{
- struct device_node *np;
- 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;
-#if defined(CONFIG_PPC_MERGE)
- np = of_find_compatible_node(NULL, NULL, mpc5200-cdm);
- cdm = of_iomap(np, 0);
- of_node_put(np);
- np = of_find_compatible_node(NULL, NULL, mpc5200-gpio);
- gpio = of_iomap(np, 0);
- of_node_put(np);
-#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 : 51200) / MCLK) 0x1FF);
-
- switch (psc_id) {
- case 1:
- ul = in_be32(gpio-port_config);
- ul = 0xFFF8;
- ul |= 0x0006;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc1, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0020;
- out_be32(cdm-clk_enables, ul);
- break;
- case 2:
- ul = in_be32(gpio-port_config);
- ul = 0xFF8F;
- ul |= 0x0060;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc2, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0040;
- out_be32(cdm-clk_enables, ul);
- break;
- case 3:
- ul = in_be32(gpio-port_config);
- ul = 0xF0FF;
- ul |= 0x0600;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc3, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0080;
- out_be32(cdm-clk_enables, ul);
- break;
- case 6:
- ul = in_be32(gpio-port_config);
- ul = 0xFF8F;
- ul |= 0x0070;
- out_be32(gpio-port_config, ul);
- out_be16(cdm-mclken_div_psc6, mclken_div);
- ul = in_be32(cdm-clk_enables);
- ul |= 0x0010;
- out_be32(cdm-clk_enables, ul);
- break;
- default:
- ret = -EINVAL;
- goto unmap_regs;
- }
+ mclken_div = (mps-sysclk ? mps-sysclk : 51200) / MCLK;
+ mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
/* Reset the PSC into a known state */
out_8(psc-command, MPC52xx_PSC_RST_RX);
@@ -427,12 +360,6 @@ 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;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Platform matching style (was:: [RFC] add phy-handle property for fec_mpc52xx)
On 1/9/08, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: As much as I despise having to work around firmware bugs, it looks indeed like this one has been broken for way too long to the point where users are being hurt, distros are being hurt, and telling people to whack things in nvramrc is just plain gross, so let's merge it. Tangent question: The Efika has device_type = chrp in the root node, but in Linux Efika support does not use CHRP, it uses arch/powerpc/platforms/52xx/efika.c. However, if CHRP support is compiled in then it will see the chrp device_type and bind to it before efika.c has a chance to probe. I see three reasonable solutions to this: 1. Apply a device tree fixup to change device_type from chrp to efika (the current solution) 2. Modify chrp_probe() to check specifically for the Efika when probing 3. Modify the link order so that Efika is probed before CHRP. All three of these solutions will work, but I'd like to get opinions on which is stylistically the best approach (or if there is another approach I'm missing). In general, I'm trying to reduce the Efika fixups down to only what is absolutely necessary and as much as possible work with the provided device tree. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Liam Girdwood wrote: I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay? I want to get it into 2.6.25. Keep in mind: 1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 PowerPC driver 100% correct. 2) The CS4270 driver does not support I2C nodes in the device tree, so there's not point in adding any to the 8610 DTS. 3) Liam and I are working on porting this driver to ASoC V2 and resolving all open PPC issue, but that won't be done in time for 2.6.25. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Platform matching style (was:: [RFC] add phy-handle property for fec_mpc52xx)
On Thu, Jan 10, 2008 at 08:31:18AM -0700, Grant Likely wrote: 1. Apply a device tree fixup to change device_type from chrp to efika (the current solution) 2. Modify chrp_probe() to check specifically for the Efika when probing 3. Modify the link order so that Efika is probed before CHRP. All three of these solutions will work, but I'd like to get opinions on which is stylistically the best approach (or if there is another approach I'm missing). In general, I'm trying to reduce the Efika fixups down to only what is absolutely necessary and as much as possible work with the provided device tree. (3) sounds fragile to me. There's already code in the kernel that does (2): pSeries_probe checks to make sure it's not running on a cell blade. That has the benefit of presenting something closer to the real device tree to the user through /proc/device-tree, not that I'm sure it has all that much value. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layerfunctionality
On Sat, Dec 29, 2007 at 06:13:08PM +0100, Joakim Tjernlund wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] abs.org] On Behalf Of Vitaly Bordug Sent: den 6 december 2007 23:51 To: Paul Mackerras Cc: [EMAIL PROTECTED]; linuxppc-dev Subject: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layerfunctionality With that patch fixed.c now fully emulates MDIO bus, thus no need to duplicate PHY layer functionality. That, in turn, drastically simplifies the code, and drops down line count. As an additional bonus, now there is no need to register MDIO bus for each PHY, all emulated PHYs placed on the platform fixed MDIO bus. There is also no more need to pre-allocate PHYs via .config option, this is all now handled dynamically. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Signed-off-by: Vitaly Bordug [EMAIL PROTECTED] Acked-by: Jeff Garzik [EMAIL PROTECTED] What happened to this patch set? Is it sitting in a tree somewhere waiting for 2.4.25 or does it need more work? ^ we're too late then. ;-) Patches already began to fuzz at the fsl_soc.c, yet more time and they'll reject to apply. So.. Paul, Kumar can we get this in for 2.6.25? I believe afterward this one will need some attention too: http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048473.html Thanks in advance, p.s. I just noticed that fsl_soc: add support for gianfar for fixed-link .. patch could be cosmetically improved (removing casts, adding checks for size after the of_get_property), but I hope we can do this on top of already applied patches. Thanks again, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote: Liam Girdwood wrote: I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay? I want to get it into 2.6.25. Keep in mind: 1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 PowerPC driver 100% correct. The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences. However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term. So, I'm okay with merging the driver *minus* the .dts and booting-without-of.txt changes. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull linux-2.6-mpc52xx for-2.6.24
Paul, Can you please pull this tree to get an Efika boot fix into 2.6.24. Without this fix, Ethernet on the Efika will not work without the user jumping through all kinds of hoops. Thanks, g. The following changes since commit fd0b45dfd1858c6b49d06355a460bcf36d654c06: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net-2.6 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.24 Olaf Hering (1): [POWERPC] efika: add phy-handle property for fec_mpc52xx arch/powerpc/kernel/prom_init.c | 39 +++ 1 files changed, 39 insertions(+), 0 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote: On 09/01/2008, Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote: Heh. That's the elbow-grease of this thing. The easy part is to get the core function working. The hard part is to test these various configs, and when they don't work, figure out what went wrong. That will take perseverence and brains. This just sounds like a whole lot of extra work to get a feature that already exists. Well, no. kexec is horribly ill-behaved with respect to PCI. The kexec kernel starts running with PCI devices in some random state; maybe they're DMA'ing or who knows what. kexec tries real hard to whack a few needed pci devices into submission but it has been hit-n-miss, and the source of 90% of the kexec headaches and debugging effort. Its not pretty. It surprises me that this hasn't been possible to resolve with less than architecting a completely new interface, given that the platform has all this fancy support for isolating and resetting adapters. After all, the exact same thing has to be done by the hypervisor before rebooting the partition. If all pci-host bridges could shut-down or settle the bus, and raise the #RST line high, and then if all BIOS'es supported this, you'd be right. But they can't This argument doesn't hold. We're not talking about some generic PC with a crappy BIOS here, we're specifically talking about POWER6 PHYP. It certainly already has ways to reset adapters in it, or EEH wouldn't work. Actually, the whole phyp dump feature wouldn't work either, since it's exactly what the firmware has to do under the covers as well. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On 10/01/2008, Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote: On 09/01/2008, Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote: Heh. That's the elbow-grease of this thing. The easy part is to get the core function working. The hard part is to test these various configs, and when they don't work, figure out what went wrong. That will take perseverence and brains. This just sounds like a whole lot of extra work to get a feature that already exists. Well, no. kexec is horribly ill-behaved with respect to PCI. The kexec kernel starts running with PCI devices in some random state; maybe they're DMA'ing or who knows what. kexec tries real hard to whack a few needed pci devices into submission but it has been hit-n-miss, and the source of 90% of the kexec headaches and debugging effort. Its not pretty. It surprises me that this hasn't been possible to resolve with less than architecting a completely new interface, given that the platform has all this fancy support for isolating and resetting adapters. After all, the exact same thing has to be done by the hypervisor before rebooting the partition. OK, point taken. -- The phyp interfaces are there for AIX, which I guess must not have kexec-like ability. So this is a case of Linux leveraging a feature architected for AIX. -- There's also this idea, somewhat weak, that the crash may have corrupted the ram where the kexec kernel sits. For someone who is used to seeing crashes due to null pointer deref's, this seems fairly unlikely. But perhaps crashes in production systems are more mind-bending. (we did have a case where a USB stick used for boot continued to scribble on memory long after it was supposed to be quiet and unused. This resulted in a very hard to debug crash.) A solution to a corrupted kexec kernel would be to disable memory access to where kexec sits, e.g un-mapping or making r/o the pages where it lies. This begs the questions of who unhides the kexec kernel, and what if this 'who' gets corrupted? In short, the kexec kernel does not boot exactly the same as a cold boot, and so this opens a can of worms about well, what's different, how do we minimize these differences, etc. and I think that lead AIX to punt, and say lets just use one single, well-known boot loader/ boot sequence instead of inventing a new one, thus leading to the phyp design. But that's just my guess.. :-) --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] Update MPC8610 HPCD to support audio drivers
On 1/7/08, Timur Tabi [EMAIL PROTECTED] wrote: Update the MPC8610 HPCD files to support the audio driver. Update booting-without-of.txt with information on the SSI device. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- Updated based on comments from mailing lists. Split the patch into two parts. This patch applies on top of git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git. Documentation/powerpc/booting-without-of.txt | 40 ++ arch/powerpc/boot/dts/mpc8610_hpcd.dts | 110 - arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 +- arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 18 +++ 4 files changed, 335 insertions(+), 4 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index e9a3cb1..826af91 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -53,6 +53,7 @@ Table of Contents j) CFI or JEDEC memory-mapped NOR flash k) Global Utilities Block l) Xilinx IP cores + p) Freescale Synchronous Serial Interface VII - Specifying interrupt information for devices 1) interrupts property @@ -2514,6 +2515,45 @@ platforms are moved over to use the flattened-device-tree model. Requred properties: - current-speed : Baud rate of uartlite +p) Freescale Synchronous Serial Interface + + The SSI is a serial device that communicates with audio codecs. It can + be programmed in AC97, I2S, left-justified, or right-justified modes. + + Required properties: + - compatible : compatible list, containing fsl,ssi + - cell-index : the SSI, 0 = SSI1, 1 = SSI2, and so on + - reg : offset and length of the register set for the device + - interrupts : a b where a is the interrupt number and b is a +field that represents an encoding of the sense and + level information for the interrupt. This should be + encoded based on the information in section 2) + depending on the type of interrupt controller you + have. + - interrupt-parent : the phandle for the interrupt controller that +services interrupts for this device. + - fsl,mode: the operating mode for the SSI interface + i2s-slave - I2S mode, SSI is clock slave + i2s-master - I2S mode, SSI is clock master + lj-slave - left-justified mode, SSI is clock slave + lj-master - l.j. mode, SSI is clock master + rj-slave - right-justified mode, SSI is clock slave + rj-master - r.j., SSI is clock master + ac97-slave - AC97 mode, SSI is clock slave + ac97-master - AC97 mode, SSI is clock master + + Optional properties: + - codec : child node that defines an audio codec connected + to this SSI + + Child 'codec' node required properties: + - compatible : compatible list, contains the name of the codec + + Child 'codec' node optional properties: + - bus-frequency : The frequency of the input clock, which typically +comes from an on-board dedicated oscillator. + + More devices will be defined as this spec matures. VII - Specifying interrupt information for devices diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts index 966edf1..fda0ace 100644 --- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts +++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts @@ -1,7 +1,7 @@ /* * MPC8610 HPCD Device Tree Source * - * Copyright 2007 Freescale Semiconductor Inc. + * Copyright 2007-2008 Freescale Semiconductor Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License Version 2 as published @@ -42,6 +42,7 @@ #size-cells = 1; #interrupt-cells = 2; device_type = soc; + compatible = fsl,mpc8610; Something like fsl,mpc8610-immr might be a better choice here. This node doesn't actually describe the entire chip (for example, the PPC cores are in the cpus node); but it does describe the internally memory mapped registers. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
On Thu, 10 Jan 2008 09:14:26 -0500, Jon Smirl wrote: What is the review status of this series, should I post it again? No please! /o\ I'll go through your numerous past posts now, stay tuned. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] Return a non-zero exit code if an error occurs during dts parsing.
David Gibson wrote: On Sun, Jan 06, 2008 at 04:55:09PM -0600, Scott Wood wrote: On Fri, Jan 04, 2008 at 03:30:33PM +1100, David Gibson wrote: This is unequivocally wrong. boot_info should have information about the contents of the blob, not state information like the error. This blob is invalid *is* information about the contents of the blob. If you're going to use an ugly global, then use it everywhere. Why go out of our way to make the code even less library-able/thread-safe? It doesn't make it any less thread-safe. A global variable used some places is just as bad as a global variable used everywhere from that point of view, and is more complicated. But the knowledge of the fact that the boot_info struct is a global is isolated to the treesource code. I don't see any reason to add another global at the *interface* level, much less that not doing so is unequivocally wrong. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
Kumar Gala wrote:
On Jan 9, 2008, at 1:52 PM, Scott Wood wrote:
Kumar Gala wrote:
I'm thinking I'll add something like:
if (addr total_lowmem)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(lmb.reserved,
i));
+ else if (lmb.reserved.region[i].base total_lowmem) {
less than, surely?
damn, why didn't I see your email before a spent 20 minutes debugging
this ;)
Because, as happens all too often lately, Freescale's mail servers
needed to chew on it for an hour and a half before sending it on. :-P
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Heiko Schocher wrote: diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c index f2a4d39..f432a18 100644 --- a/drivers/net/fs_enet/fs_enet-main.c +++ b/drivers/net/fs_enet/fs_enet-main.c @@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev) if (fep-fpi-use_napi) napi_enable(fep-napi); + /* to initialize the fep-cur_rx,... */ + /* not doing this, will cause a crash in fs_enet_rx_napi */ + fs_init_bds(fep-ndev); We should do this just before napi_enable() rather than just after, to eliminate any chance of a race window. Looks good otherwise. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ibm4xx_quiesce_eth?
On Thu, 10 Jan 2008 13:38:12 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: What exactly does this function do? /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't * do this for us */ On the taco, with the 440EP, it doesn't seem to make any difference if I call this or not. Since I am using u-boot, is it not needed? There are firmwares that do not reset the EMAC and MAL before passing control to the client program (Linux in our case). This can cause weird things to happen, like spurious interrupts or DMAs from the hardware overwriting kernel memory. So we quiesce the hardware really early on those. I don't believe U-Boot has that problem. If it does, it should be fixed :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
Hello Scott,
Scott Wood wrote:
Heiko Schocher wrote:
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..f432a18 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev)
if (fep-fpi-use_napi)
napi_enable(fep-napi);
+/* to initialize the fep-cur_rx,... */
+/* not doing this, will cause a crash in fs_enet_rx_napi */
+fs_init_bds(fep-ndev);
We should do this just before napi_enable() rather than just after, to
eliminate any chance of a race window.
Yes, you are right.
Here is the new patch:
From 3b8db4261199f0115d8e0188b6bffbc9f5e7673d Mon Sep 17 00:00:00 2001
From: Heiko Schocher [EMAIL PROTECTED]
Date: Thu, 10 Jan 2008 19:28:18 +0100
Subject: [PATCH] [POWERPC] Fix Ethernet over SCC on a CPM2,
also Fix crash in fs_enet_rx_napi()
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
drivers/net/fs_enet/fs_enet-main.c | 10 +-
drivers/net/fs_enet/mac-scc.c |8 +++-
include/asm-powerpc/cpm2.h |5 +
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..70a0319 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -807,6 +807,10 @@ static int fs_enet_open(struct net_device *dev)
int r;
int err;
+ /* to initialize the fep-cur_rx,... */
+ /* not doing this, will cause a crash in fs_enet_rx_napi */
+ fs_init_bds(fep-ndev);
+
if (fep-fpi-use_napi)
napi_enable(fep-napi);
@@ -982,6 +986,7 @@ static struct net_device *fs_init_instance(struct device
*dev,
fep = netdev_priv(ndev);
fep-dev = dev;
+ fep-ndev = ndev;
dev_set_drvdata(dev, ndev);
fep-fpi = fpi;
if (fpi-init_ioports)
@@ -1085,7 +1090,6 @@ static struct net_device *fs_init_instance(struct device
*dev,
}
registered = 1;
-
return ndev;
err:
@@ -1347,6 +1351,10 @@ static struct of_device_id fs_enet_match[] = {
.compatible = fsl,cpm1-scc-enet,
.data = (void *)fs_scc_ops,
},
+ {
+ .compatible = fsl,cpm2-scc-enet,
+ .data = (void *)fs_scc_ops,
+ },
#endif
#ifdef CONFIG_FS_ENET_HAS_FCC
{
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index fe3d8a6..3889271 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -50,7 +50,6 @@
#include fs_enet.h
/*/
-
#if defined(CONFIG_CPM1)
/* for a 8xx __raw_xxx's are sufficient */
#define __fs_out32(addr, x)__raw_writel(x, addr)
@@ -65,6 +64,8 @@
#define __fs_out16(addr, x)out_be16(addr, x)
#define __fs_in32(addr)in_be32(addr)
#define __fs_in16(addr)in_be16(addr)
+#define __fs_out8(addr, x) out_8(addr, x)
+#define __fs_in8(addr) in_8(addr)
#endif
/* write, read, set bits, clear bits */
@@ -297,8 +298,13 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifndef CONFIG_NOT_COHERENT_CACHE
+ W8(ep, sen_genscc.scc_rfcr, SCC_EB | SCC_GBL);
+ W8(ep, sen_genscc.scc_tfcr, SCC_EB | SCC_GBL);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
/* Set maximum bytes per receive buffer.
* This appears to be an Ethernet frame size, not the buffer
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index f1112c1..14c6496 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -375,6 +375,11 @@ typedef struct scc_param {
uintscc_tcrc; /* Internal */
} sccp_t;
+/* Function code bits.
+*/
+#define SCC_EB ((u_char) 0x10) /* Set big endian byte order */
+#define SCC_GBL((u_char) 0x20) /* Snooping enabled */
+
/* CPM Ethernet through SCC1.
*/
typedef struct scc_enet {
--
1.5.2.2
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood The tree looks OK. The checkstop may be from erratum SIU18; I had this issue on the ep8248e board. Try clearing BCR[PLDP]. Not sure what was wrong. We took a step back, and redid some stuff, and now we have serial output from the boot-wrapper. THe checkstop came from the wrapper grying to access the bcsr and doing the chip select fixup. We don';t have a bcsr on our board, and the cs layout is different. Now our problem is that the kernel doesn't want to output anything to hte serial port. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote: Not sure what was wrong. We took a step back, and redid some stuff, and now we have serial output from the boot-wrapper. THe checkstop came from the wrapper grying to access the bcsr and doing the chip select fixup. We don';t have a bcsr on our board, and the cs layout is different. There's no bcsr access in the upstream bootwrapper (the mention of bcsr in cuboot-pq2.c is just one reason why some boards require us to do the CS programming), and the CS programming is chip-level, not board-level (it just requires that the device tree have a correct localbus node for the board). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences. However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term. I agree. Correct me if I'm wrong, but I think the only device tree issue is the definition of the 'codec' node under the SSI node. If so, I'm not sure what other changes need to be mode. Isn't your codec is i2c controlled? Where does the main node for the code live, i2c bus or ssi bus? What does the link between the buses look like for pointing to the codec entry? What about fsl,ssi being too generic for a compatible type? -- Timur Tabi Linux kernel developer at Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
The CS4270 driver is old style, which means it probes all possible I2C
addresses until it finds a hit, and then stops. This has all the obvious
drawbacks, but I'm stuck with that design for now.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
Nit: node name should be either [EMAIL PROTECTED] (the mode that it is in), or
[EMAIL PROTECTED] (if you feel that this node encapsulates the concept of a
sound device enough).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
The CS4270 driver is old style, which means it probes all possible I2C
addresses until it finds a hit, and then stops. This has all the obvious
drawbacks, but I'm stuck with that design for now.
So the codec is controlled from the i2c bus and SSI is used to supply
it with data. Based on what has been said on this list, the device
tree node for the codec should be on the i2c bus with a link from the
ssi bus to it.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
--
Timur Tabi
Linux kernel developer at Freescale
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Jon Smirl wrote: So the codec is controlled from the i2c bus and SSI is used to supply it with data. Based on what has been said on this list, the device tree node for the codec should be on the i2c bus with a link from the ssi bus to it. I'm working on that now. I'll have a new patch with this exact change this afternoon. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: Nit: node name should be either [EMAIL PROTECTED] (the mode that it is in), or [EMAIL PROTECTED] (if you feel that this node encapsulates the concept of a sound device enough). Well, SSI stands for Synchronous Serial Interface (although it's capable of asynchronous communication as well). From the manual: The SSI is a full-duplex, serial port that allows the chip to communicate with a variety of serial devices. These serial devices can be standard CODer-DECoder (CODECs), Digital Signal Processors (DSPs), microprocessors, peripherals, and popular industry audio CODECs that implement the inter-IC sound bus standard (I2S) and Intel AC97 standard. It might an I2S device in this case, but it could be an AC97 device in some other case. It all depends on how the board is wired. Do we really want to change the name of an SOC device based on what it's connected to? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
Linas Vepstas wrote: On 10/01/2008, Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 10:12:13PM -0600, Linas Vepstas wrote: On 09/01/2008, Olof Johansson [EMAIL PROTECTED] wrote: On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote: Heh. That's the elbow-grease of this thing. The easy part is to get the core function working. The hard part is to test these various configs, and when they don't work, figure out what went wrong. That will take perseverence and brains. This just sounds like a whole lot of extra work to get a feature that already exists. Well, no. kexec is horribly ill-behaved with respect to PCI. The kexec kernel starts running with PCI devices in some random state; maybe they're DMA'ing or who knows what. kexec tries real hard to whack a few needed pci devices into submission but it has been hit-n-miss, and the source of 90% of the kexec headaches and debugging effort. Its not pretty. It surprises me that this hasn't been possible to resolve with less than architecting a completely new interface, given that the platform has all this fancy support for isolating and resetting adapters. After all, the exact same thing has to be done by the hypervisor before rebooting the partition. OK, point taken. -- The phyp interfaces are there for AIX, which I guess must not have kexec-like ability. So this is a case of Linux leveraging a feature architected for AIX. Certainly AIX was in a more difficult position at the time, because they don't have a kexec equivalent, and thus were collecting dump data with a potentially faulty kernel. It makes sense to have something outside the partition collect or maintain the data; ideally, some kind of service partition would extract dump data from a failed partition, but giving one partition total access to the memory of another is clearly risky. Both the PHYP-assistance method and the kexec method are ways to simulate that without the risk. At the risk of repeating what others have already said, the PHYP-assistance method provides some advantages that the kexec method cannot: - Availability of the system for production use before the dump data is collected. As was mentioned before, some production systems may choose not to operate with the limited memory initially available after the reboot, but it sure is nice to provide the option. - Ensuring that the devices are in a good state. PHYP doesn't expose a method to force adapters into a frozen state, (which I agree would be useful), and I don't know of any plans to do so. What we are starting to see is that some drivers need modifications in order to work correctly with kdump [1]. Supporting PHYP-assisted dump would eliminate those issues. - The small possibility that the kexec area could have been munged by the failing kernel, preventing it from being able to collect a dump. The NUMA issues are daunting, but not insurmountable. Release early, release often, n'est-ce pas? Mike [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045663.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] ASoC drivers for the Freescale MPC8610 SoC
These patches add ALSA SoC device drivers for the Freescale MPC8610 SoC and the MPC8610-HPCD reference board. The first patch updates some files in arch/powerpc and booting-without-of.txt. The second patch adds the new audio driver files to sound/soc. Both must be applied in order to avoid a build break. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] [POWERPC] Update MPC8610 HPCD to support audio drivers
Update the MPC8610 HPCD files to support the audio driver. Update
booting-without-of.txt with information on the SSI device.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Updated the DTS based comments on the list.
This patch applies on top of
git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git.
Documentation/powerpc/booting-without-of.txt | 41 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 113 +-
arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 15 +++
4 files changed, 336 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..8ddcf0b 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -53,6 +53,7 @@ Table of Contents
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
l) Xilinx IP cores
+ p) Freescale Synchronous Serial Interface
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2514,6 +2515,46 @@ platforms are moved over to use the
flattened-device-tree model.
Requred properties:
- current-speed : Baud rate of uartlite
+p) Freescale Synchronous Serial Interface
+
+ The SSI is a serial device that communicates with audio codecs. It can
+ be programmed in AC97, I2S, left-justified, or right-justified modes.
+
+ Required properties:
+ - compatible : compatible list, containing fsl,ssi
+ - cell-index : the SSI, 0 = SSI1, 1 = SSI2, and so on
+ - reg : offset and length of the register set for the device
+ - interrupts : a b where a is the interrupt number and b is a
+field that represents an encoding of the sense and
+ level information for the interrupt. This should be
+ encoded based on the information in section 2)
+ depending on the type of interrupt controller you
+ have.
+ - interrupt-parent : the phandle for the interrupt controller that
+services interrupts for this device.
+ - fsl,mode: the operating mode for the SSI interface
+ i2s-slave - I2S mode, SSI is clock slave
+ i2s-master - I2S mode, SSI is clock master
+ lj-slave - left-justified mode, SSI is clock slave
+ lj-master - l.j. mode, SSI is clock master
+ rj-slave - right-justified mode, SSI is clock
slave
+ rj-master - r.j., SSI is clock master
+ ac97-slave - AC97 mode, SSI is clock slave
+ ac97-master - AC97 mode, SSI is clock master
+
+ Optional properties:
+ - codec-handle: phandle to a 'codec' node that defines an audio
+ codec connected to this SSI. This node is typically
+ a child of an I2C or other control node.
+
+ Child 'codec' node required properties:
+ - compatible : compatible list, contains the name of the codec
+
+ Child 'codec' node optional properties:
+ - clock-frequency : The frequency of the input clock, which typically
+comes from an on-board dedicated oscillator.
+
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 966edf1..4c91890 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -1,7 +1,7 @@
/*
* MPC8610 HPCD Device Tree Source
*
- * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2007-2008 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License Version 2 as published
@@ -42,6 +42,7 @@
#size-cells = 1;
#interrupt-cells = 2;
device_type = soc;
+ compatible = fsl,mpc8610-immr, simple-bus;
ranges = 0 e000 0010;
reg = e000 1000;
bus-frequency = 0;
@@ -55,6 +56,13 @@
interrupts = 2b 2;
interrupt-parent = mpic;
dfsrr;
+
+cs4270:[EMAIL PROTECTED] {
+ compatible = cirrus,cs4270;
+reg = 4f;
+ /* MCLK source is a stand-alone oscillator */
+ clock-frequency = bb8000;
+};
};
Re: [PATCH 2/5] Warp Base Platform - dts
New version with recommended changes. Device types removed. FPGA moved to
correct bus.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/dts/warp.dts 2008-01-10 13:04:49.0 -0500
@@ -0,0 +1,230 @@
+/*
+ * Device Tree Source for PIKA Warp
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = pika,warp;
+ compatible = pika,warp;
+ dcr-parent = /cpus/[EMAIL PROTECTED];
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,440EP;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by zImage */
+ timebase-frequency = 0; /* Filled in by zImage */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 8000;
+ d-cache-size = 8000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440ep;
+ dcr-reg = 00e 002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440ep;
+ dcr-reg = 00c 002;
+ };
+
+ plb {
+ compatible = ibm,plb-440ep, ibm,plb-440gp, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-440ep, ibm,sdram-405gp;
+ dcr-reg = 010 2;
+ };
+
+ DMA0: dma {
+ compatible = ibm,dma-440ep, ibm,dma-440gp;
+ dcr-reg = 100 027;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-440ep, ibm,mcmal-440gp,
ibm,mcmal;
+ dcr-reg = 180 62;
+ num-tx-chans = 4;
+ num-rx-chans = 2;
+ interrupt-parent = MAL0;
+ interrupts = 0 1 2 3 4;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = /*TXEOB*/ 0 UIC0 a 4
+ /*RXEOB*/ 1 UIC0 b 4
+ /*SERR*/ 2 UIC1 0 4
+ /*TXDE*/ 3 UIC1 1 4
+ /*RXDE*/ 4 UIC1 2 4;
+ };
+
+ POB0: opb {
+ compatible = ibm,opb-440ep, ibm,opb-440gp,
ibm,opb;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 8000
+ 8000 0 8000 8000;
+ interrupt-parent = UIC1;
+ interrupts = 7 4;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = ibm,ebc-440ep, ibm,ebc-440gp,
ibm,ebc;
+ dcr-reg = 012 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ clock-frequency = 0; /* Filled in by zImage */
+ interrupts = 5 1;
+ interrupt-parent = UIC1;
+
+ [EMAIL PROTECTED],0
Re: [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Add the ASoC drivers for the Freescale MPC8610 SoC and the MPC8610 HPCD
reference board.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
This is a very big patch, but I'm going to keep my nose out of the
ALSA stuff. I've got no problem against it being merged, but I do
have a concern about access to shared registers (see below)
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
new file mode 100644
index 000..f26c4b2
--- /dev/null
+++ b/sound/soc/fsl/mpc8610_hpcd.c
+/**
+ * mpc8610_hpcd_probe: OF probe function for the fabric driver
+ *
+ * This function gets called when an SSI node is found in the device tree.
+ *
+ * Although this is a fabric driver, the SSI node is the master node with
+ * respect to audio hardware connections. Therefore, we create a new ASoC
+ * device for each new SSI node that has a codec attached.
+ *
+ * FIXME: Currently, we only support one DMA controller, so if there are
+ * multiple SSI nodes with codecs, only the first will be supported.
+ *
+ * FIXME: Even if we did support multiple DMA controllers, we have no
+ * mechanism for assigning DMA controllers and channels to the individual
+ * SSI devices. We also probably aren't compatible with the generic Elo DMA
+ * device driver.
+ */
+static int mpc8610_hpcd_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
snip
+ /* Map the global utilities registers. */
+ guts_np = of_find_compatible_node(NULL, NULL, fsl,mpc8610-guts);
+ if (!guts_np) {
+ dev_err(ofdev-dev, could not obtain address of GUTS\n);
+ ret = -EINVAL;
+ goto error;
+ }
This...
+ /* Find the DMA channels to use. For now, we always use the first DMA
+ controller. */
+ for_each_compatible_node(dma_np, NULL, fsl,mpc8610-dma) {
+ iprop = of_get_property(dma_np, cell-index, NULL);
+ if (iprop (*iprop == 0)) {
+ of_node_put(dma_np);
+ break;
+ }
+ }
and this...
Does the driver access the DMA and GUTS registers directly? If so,
what do you have to protect against race conditions of other drivers
accessing them also.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] Warp Base Platform
David Gibson wrote:
Fold all this into cuboot-warp.c, unless you actually anticipate
adding another wrapper for another firmware which will also use the
functions in warp.c.
Done.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool PCI support if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x !CPM2 !8xx !PPC_83xx \
!PPC_85xx !PPC_86xx
default PCI_PERMEDIA if !4xx !CPM2 !8xx
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..cd83c4f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c
holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-warp.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_WARP) += cuImage.warp
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/cuboot-warp.c 2008-01-10 15:28:30.0 -0500
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include 4xx.h
+#include cuboot.h
+
+#define TARGET_44x
+#include ppcboot.h
+
+static bd_t bd;
+
+static void warp_fixups(void)
+{
+ unsigned long sysclk = 6600;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+ ibm4xx_sdram_fixup_memsize();
+ dt_fixup_mac_addresses(bd.bi_enetaddr);
+}
+
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+
+ platform_ops.fixups = warp_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: Does the driver access the DMA and GUTS registers directly? If so, what do you have to protect against race conditions of other drivers accessing them also. I don't have any more protection than any other driver that accesses SOC registers directly. Last I heard, Zhang's DMA driver was in limbo, and that driver would be the best place to arbitrate DMA register access. I was planning on adding arbitration support to that driver after both drivers were applied. As for the GUTS driver, well, I just program a few registers at startup, and I don't think any other driver touches them. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: Does the driver access the DMA and GUTS registers directly? If so, what do you have to protect against race conditions of other drivers accessing them also. I don't have any more protection than any other driver that accesses SOC registers directly. Last I heard, Zhang's DMA driver was in limbo, and that driver would be the best place to arbitrate DMA register access. I was planning on adding arbitration support to that driver after both drivers were applied. That sounds appropriate As for the GUTS driver, well, I just program a few registers at startup, and I don't think any other driver touches them. Okay; at some point in the future they'll need to be accessed from a common routine too. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: As for the GUTS driver, well, I just program a few registers at startup, and I don't think any other driver touches them. Okay; at some point in the future they'll need to be accessed from a common routine too. I'll add that to my to-do list. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/4 v4] PS3: Add logical performance monitor driver support
From: Takashi Yamamoto [EMAIL PROTECTED] Add PS3 logical performance monitor (lpm) device driver. The PS3's LV1 hypervisor provides a Logical Performance Monitor that abstracts the Cell processor's performance monitor features for use by guest operating systems. Signed-off-by: Takashi Yamamoto [EMAIL PROTECTED] Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- v2: o Correct Yamamoto-san's mail addr. o Text cleanups. o Added more comments explaining lpm operation. o Split SRPN_BKMK into separate patch. o Use get_hard_smp_processor_id() in ps3_get_hw_thread_id(). o Split ps3_copy_trace_buffer() into ps3_lpm_copy_tb() and ps3_lpm_copy_tb_to_user(). o Replace mutex with atomic_t in ps3_lpm_open()/ps3_lpm_close(). o General cleanup of ps3_lpm_open()/ps3_lpm_close(). v3: o Add BE node_id to struct lpm_priv. o Change some dev_err() to dev_dbg(). o Fix kzalloc() bug. o Text fix s/lost/loss/. o Use lpm_priv-node_id with lv1_construct_lpm(). v4: o Text fix s/whos/whose/. arch/powerpc/platforms/ps3/Kconfig | 13 drivers/ps3/Makefile |1 drivers/ps3/ps3-lpm.c | 1248 + include/asm-powerpc/ps3.h | 62 + 4 files changed, 1324 insertions(+) create mode 100644 arch/powerpc/platforms/ps3/ps3-lpm.c --- a/arch/powerpc/platforms/ps3/Kconfig +++ b/arch/powerpc/platforms/ps3/Kconfig @@ -138,4 +138,17 @@ config PS3_FLASH be disabled on the kernel command line using ps3flash=off, to not allocate this fixed buffer. +config PS3_LPM + tristate PS3 Logical Performance Monitor support + depends on PPC_PS3 + help + Include support for the PS3 Logical Performance Monitor. + + This support is required to use the logical performance monitor + of the PS3's LV1 hypervisor. + + If you intend to use the advanced performance monitoring and + profiling support of the Cell processor with programs like + oprofile and perfmon2, then say Y or M, otherwise say N. + endmenu --- a/drivers/ps3/Makefile +++ b/drivers/ps3/Makefile @@ -4,3 +4,4 @@ ps3av_mod-objs += ps3av.o ps3av_cmd.o obj-$(CONFIG_PPC_PS3) += sys-manager-core.o obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o +obj-$(CONFIG_PS3_LPM) += ps3-lpm.o --- /dev/null +++ b/drivers/ps3/ps3-lpm.c @@ -0,0 +1,1248 @@ +/* + * PS3 Logical Performance Monitor. + * + * Copyright (C) 2007 Sony Computer Entertainment Inc. + * Copyright 2007 Sony Corp. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/uaccess.h +#include asm/ps3.h +#include asm/lv1call.h +#include asm/cell-pmu.h + + +/* BOOKMARK tag macros */ +#define PS3_PM_BOOKMARK_START0x8000ULL +#define PS3_PM_BOOKMARK_STOP 0x4000ULL +#define PS3_PM_BOOKMARK_TAG_KERNEL 0x1000ULL +#define PS3_PM_BOOKMARK_TAG_USER 0x3000ULL +#define PS3_PM_BOOKMARK_TAG_MASK_HI 0xF000ULL +#define PS3_PM_BOOKMARK_TAG_MASK_LO 0x0F00ULL + +/* CBE PM CONTROL register macros */ +#define PS3_PM_CONTROL_PPU_TH0_BOOKMARK 0x1000 +#define PS3_PM_CONTROL_PPU_TH1_BOOKMARK 0x0800 +#define PS3_PM_CONTROL_PPU_COUNT_MODE_MASK 0x000C +#define PS3_PM_CONTROL_PPU_COUNT_MODE_PROBLEM0x0008 +#define PS3_WRITE_PM_MASK0xULL + +/* CBE PM START STOP register macros */ +#define PS3_PM_START_STOP_PPU_TH0_BOOKMARK_START 0x0200 +#define PS3_PM_START_STOP_PPU_TH1_BOOKMARK_START 0x0100 +#define PS3_PM_START_STOP_PPU_TH0_BOOKMARK_STOP 0x0002 +#define PS3_PM_START_STOP_PPU_TH1_BOOKMARK_STOP 0x0001 +#define PS3_PM_START_STOP_START_MASK 0xFF00 +#define PS3_PM_START_STOP_STOP_MASK 0x00FF + +/* CBE PM COUNTER register macres */ +#define PS3_PM_COUNTER_MASK_HI 0xULL +#define PS3_PM_COUNTER_MASK_LO 0xULL + +/* BASE SIGNAL GROUP NUMBER macros */ +#define PM_ISLAND2_BASE_SIGNAL_GROUP_NUMBER 0 +#define PM_ISLAND2_SIGNAL_GROUP_NUMBER1 6
Re: [PATCH V3] [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
On Thu, 10 Jan 2008 08:01:09 -0700 Grant Likely [EMAIL PROTECTED] wrote:
On 1/10/08, Stephen Rothwell [EMAIL PROTECTED] wrote:
Hi Grant,
On Wed, 09 Jan 2008 22:26:30 -0700 Grant Likely [EMAIL PROTECTED] wrote:
+mpc52xx_map_common_devices(void)
{
+ /* Clock Distribution Module, used by PSC clock setting function */
+ np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
What happens if we find no node?
Both of_iomap and of_put fail gracefully if np is NULL. IIRC that was
done on purpose so this exact thing could be done.
Users of mpc52xx_cdm (and the others done in this style) all check for
mpc52xx_cdm being NULL before dereferencing.
Excellent, thanks.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgppT1sZb0Jam.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] [POWERPC] Update MPC8610 HPCD to support audio drivers
Grant Likely wrote:
+[EMAIL PROTECTED] {
+#address-cells = 1;
+#size-cells = 1;
+compatible = fsl,mpc8610-dma, fsl,eloplus-dma;
+cell-index = 0;
+reg = 21300 4; /* DMA general status register */
+ranges = 0 21100 200;
+
+[EMAIL PROTECTED] {
+ compatible = fsl,mpc8610-dma-channel,
+ fsl,eloplus-dma-channel;
Nit: you probably don't need the compatible property for these channel
nodes since they are 100% dependent on the parent for describing the
behaviour.
The compatible property in the child nodes gives the driver the option
of matching the channel rather than the whole thing.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix CPU hotplug when using the SLB shadow buffer
Before we register the SLB shadow buffer, we need to invalidate the
entries in the buffer otherwise we can end up stale entries from when we
offlined the CPU.
This patch does this invalidate as well as unregistering the buffer with
PHYP before we offline the cpu. Tested and fixes crashes seen on 970MP
(thanks to tonyb) and POWER5.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Updates for offline comments from paulus
arch/powerpc/mm/slb.c|8
arch/powerpc/platforms/pseries/hotplug-cpu.c |2 ++
arch/powerpc/platforms/pseries/lpar.c|1 +
include/asm-powerpc/mmu-hash64.h |1 +
4 files changed, 12 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -82,6 +82,14 @@ static inline void slb_shadow_clear(unsi
get_slb_shadow()-save_area[entry].esid = 0;
}
+void slb_shadow_clear_all(void)
+{
+ int i;
+
+ for (i = 0; i SLB_NUM_BOLTED; i++)
+ slb_shadow_clear(i);
+}
+
static inline void create_shadowed_slbe(unsigned long ea, int ssize,
unsigned long flags,
unsigned long entry)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -29,6 +29,7 @@
#include asm/vdso_datapage.h
#include asm/pSeries_reconfig.h
#include xics.h
+#include plpar_wrappers.h
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void)
local_irq_disable();
idle_task_exit();
xics_teardown_cpu(0);
+ unregister_slb_shadow(smp_processor_id(), __pa(get_slb_shadow()));
rtas_stop_self();
/* Should never get here... */
BUG();
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -272,6 +272,7 @@ void vpa_init(int cpu)
*/
addr = __pa(slb_shadow[cpu]);
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ slb_shadow_clear_all();
ret = register_slb_shadow(hwcpu, addr);
if (ret)
printk(KERN_ERR
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -286,6 +286,7 @@ extern void hpte_init_iSeries(void);
extern void hpte_init_beat(void);
extern void hpte_init_beat_v3(void);
+extern void slb_shadow_clear_all(void);
extern void stabs_alloc(void);
extern void slb_initialize(void);
extern void slb_flush_and_rebolt(void);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix CPU hotplug when using the SLB shadow buffer
Michael Neuling wrote: @@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void) local_irq_disable(); idle_task_exit(); xics_teardown_cpu(0); + unregister_slb_shadow(smp_processor_id(), __pa(get_slb_shadow())); ^ Should that not be hard_smp_processor_id()? (sorry for not commenting earlier) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
Mike Strosaker wrote: At the risk of repeating what others have already said, the PHYP-assistance method provides some advantages that the kexec method cannot: - Availability of the system for production use before the dump data is collected. As was mentioned before, some production systems may choose not to operate with the limited memory initially available after the reboot, but it sure is nice to provide the option. I'm more concerned that this design encourages the user to resume a workload *which is almost certainly known to result in a system crash* before collection of crash data is complete. Maybe the gamble will pay off most of the time, but I wouldn't want to be working support when it doesn't. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix CPU hotplug when using the SLB shadow buffer
Before we register the SLB shadow buffer, we need to invalidate the
entries in the buffer otherwise we can end up stale entries from when we
offlined the CPU.
This patch does this invalidate as well as unregistering the buffer with
PHYP before we offline the cpu. Tested and fixes crashes seen on 970MP
(thanks to tonyb) and POWER5.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Updated based on comment from ntl
arch/powerpc/mm/slb.c|8
arch/powerpc/platforms/pseries/hotplug-cpu.c |2 ++
arch/powerpc/platforms/pseries/lpar.c|1 +
include/asm-powerpc/mmu-hash64.h |1 +
4 files changed, 12 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -82,6 +82,14 @@ static inline void slb_shadow_clear(unsi
get_slb_shadow()-save_area[entry].esid = 0;
}
+void slb_shadow_clear_all(void)
+{
+ int i;
+
+ for (i = 0; i SLB_NUM_BOLTED; i++)
+ slb_shadow_clear(i);
+}
+
static inline void create_shadowed_slbe(unsigned long ea, int ssize,
unsigned long flags,
unsigned long entry)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -29,6 +29,7 @@
#include asm/vdso_datapage.h
#include asm/pSeries_reconfig.h
#include xics.h
+#include plpar_wrappers.h
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void)
local_irq_disable();
idle_task_exit();
xics_teardown_cpu(0);
+ unregister_slb_shadow(hard_smp_processor_id(), __pa(get_slb_shadow()));
rtas_stop_self();
/* Should never get here... */
BUG();
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -272,6 +272,7 @@ void vpa_init(int cpu)
*/
addr = __pa(slb_shadow[cpu]);
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ slb_shadow_clear_all();
ret = register_slb_shadow(hwcpu, addr);
if (ret)
printk(KERN_ERR
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -286,6 +286,7 @@ extern void hpte_init_iSeries(void);
extern void hpte_init_beat(void);
extern void hpte_init_beat_v3(void);
+extern void slb_shadow_clear_all(void);
extern void stabs_alloc(void);
extern void slb_initialize(void);
extern void slb_flush_and_rebolt(void);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Enable RTC for Ebony and Walnut (v2)
This patch extends the Ebony and Walnut platform code to instantiate
the existing ds1742 RTC class driver for the DS1743 RTC/NVRAM chip
found on both those boards. The patch uses a helper function to scan
the device tree and instantiate the appropriate platform_device based
on it, so it should be easy to extend for other boards which have mmio
mapped RTC chips.
Along with this, the device tree binding for the ds1743 chips is
tweaked, based on the existing DS1385 OF binding found at:
http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-it.txt
Although that document covers the NVRAM portion of the chip, whereas
here we're interested in the RTC portion, so it's not entirely clear
if that's a good model.
This implements only RTC class driver support - that is /dev/rtc0, not
/dev/rtc, and the low-level get/set time callbacks remain
unimplemented. That means in order to get at the clock you will
either need a modified version of hwclock which will look at
/dev/rtc0, or you'll need to configure udev to symlink rtc0 to rtc.
Signed-off-by: David Gibson [EMAIL PROTECTED]
---
Updated for kernel changes and feedback.
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts2008-01-11
11:45:27.0 +1100
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2008-01-11 14:17:03.0
+1100
@@ -158,9 +158,10 @@
};
};
- [EMAIL PROTECTED],0 {
+ [EMAIL PROTECTED],0 {
/* NVRAM RTC */
- compatible = ds1743;
+ compatible = ds1743-nvram;
+ #bytes = 2000;
reg = 1 0 2000;
};
Index: working-2.6/arch/powerpc/platforms/44x/ebony.c
===
--- working-2.6.orig/arch/powerpc/platforms/44x/ebony.c 2008-01-11
11:45:27.0 +1100
+++ working-2.6/arch/powerpc/platforms/44x/ebony.c 2008-01-11
14:17:03.0 +1100
@@ -18,6 +18,7 @@
#include linux/init.h
#include linux/of_platform.h
+#include linux/rtc.h
#include asm/machdep.h
#include asm/prom.h
@@ -38,6 +39,7 @@ static __initdata struct of_device_id eb
static int __init ebony_device_probe(void)
{
of_platform_bus_probe(NULL, ebony_of_bus, NULL);
+ of_instantiate_rtc();
return 0;
}
Index: working-2.6/arch/powerpc/platforms/Kconfig
===
--- working-2.6.orig/arch/powerpc/platforms/Kconfig 2007-12-10
10:52:44.0 +1100
+++ working-2.6/arch/powerpc/platforms/Kconfig 2008-01-11 14:17:03.0
+1100
@@ -315,6 +315,12 @@ config FSL_ULI1575
config CPM
bool
+config OF_RTC
+ bool
+ help
+ Uses information from the OF or flattened device tree to instatiate
+ platform devices for direct mapped RTC chips like the DS1742 or
DS1743.
+
source arch/powerpc/sysdev/bestcomm/Kconfig
endmenu
Index: working-2.6/arch/powerpc/sysdev/Makefile
===
--- working-2.6.orig/arch/powerpc/sysdev/Makefile 2008-01-11
11:45:27.0 +1100
+++ working-2.6/arch/powerpc/sysdev/Makefile2008-01-11 14:17:03.0
+1100
@@ -27,6 +27,7 @@ obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
+obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
Index: working-2.6/arch/powerpc/sysdev/of_rtc.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ working-2.6/arch/powerpc/sysdev/of_rtc.c2008-01-11 14:17:03.0
+1100
@@ -0,0 +1,59 @@
+/*
+ * Instantiate mmio-mapped RTC chips based on device tree information
+ *
+ * Copyright 2007 David Gibson [EMAIL PROTECTED], IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include linux/kernel.h
+#include linux/of.h
+#include linux/init.h
+#include linux/of_platform.h
+
+static __initdata struct {
+ const char *compatible;
+ char *plat_name;
+} of_rtc_table[] = {
+ { ds1743-nvram, rtc-ds1742 },
+};
+
+void __init of_instantiate_rtc(void)
+{
+ struct device_node *node;
+ int err;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(of_rtc_table);
libfdt: Add fdt_set_name() function
This patch adds an fdt_set_name() function to libfdt, mirroring
fdt_get_name(). This is a r/w function which alters the name of a
given device tree node.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2007-12-19 10:52:12.0 +1100
+++ dtc/libfdt/libfdt.h 2008-01-11 14:53:27.0 +1100
@@ -846,6 +846,32 @@ int fdt_add_mem_rsv(void *fdt, uint64_t
int fdt_del_mem_rsv(void *fdt, int n);
/**
+ * fdt_set_name - change the name of a given node
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: structure block offset of a node
+ * @name: name to give the node
+ *
+ * fdt_set_name() replaces the name (including unit address, if any)
+ * of the given node with the given string. NOTE: this function can't
+ * efficiently check if the new name is unique amongst the given
+ * node's siblings; results are undefined if this function is invoked
+ * with a name equal to one of the given node's siblings.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob
+ * to contain the new name
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE, standard meanings
+ */
+int fdt_set_name(void *fdt, int nodeoffset, const char *name);
+
+/**
* fdt_setprop - create or change a property
* @fdt: pointer to the device tree blob
* @nodeoffset: offset of the node whose property to change
Index: dtc/libfdt/fdt_rw.c
===
--- dtc.orig/libfdt/fdt_rw.c2007-12-19 10:52:12.0 +1100
+++ dtc/libfdt/fdt_rw.c 2008-01-11 14:45:27.0 +1100
@@ -252,6 +252,30 @@ static int _add_property(void *fdt, int
return 0;
}
+int fdt_set_name(void *fdt, int nodeoffset, const char *name)
+{
+ char *namep;
+ int oldlen, newlen;
+ int err;
+
+ if ((err = rw_check_header(fdt)))
+ return err;
+
+ namep = (char *)fdt_get_name(fdt, nodeoffset, oldlen);
+ if (!namep)
+ return oldlen;
+
+ newlen = strlen(name);
+
+ err = _blob_splice_struct(fdt, namep, ALIGN(oldlen+1, FDT_TAGSIZE),
+ ALIGN(newlen+1, FDT_TAGSIZE));
+ if (err)
+ return err;
+
+ memcpy(namep, name, newlen+1);
+ return 0;
+}
+
int fdt_setprop(void *fdt, int nodeoffset, const char *name,
const void *val, int len)
{
Index: dtc/tests/Makefile.tests
===
--- dtc.orig/tests/Makefile.tests 2007-12-19 16:50:09.0 +1100
+++ dtc/tests/Makefile.tests2008-01-11 14:34:11.0 +1100
@@ -8,7 +8,7 @@ LIB_TESTS_L = get_mem_rsv \
setprop_inplace nop_property nop_node \
sw_tree1 \
move_and_save mangle-layout \
- open_pack rw_tree1 setprop del_property del_node \
+ open_pack rw_tree1 set_name setprop del_property del_node \
string_escapes references path-references \
dtbs_equal_ordered
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
Index: dtc/tests/set_name.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/set_name.c2008-01-11 14:52:17.0 +1100
@@ -0,0 +1,91 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_set_name()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include stdint.h
+
+#include fdt.h
+#include libfdt.h
+
+#include tests.h
+#include testdata.h
+
+void check_set_name(void *fdt, const char *path, const char *newname)
+{
+ int offset;
+ const char *getname, *oldname;
+ int len, err;
+
+ oldname = strrchr(path, '/');
+ if (!oldname)
+ TEST_BUG();
+ oldname += 1;
+
+ offset = fdt_path_offset(fdt, path);
+
[PATCH] ps3: vuart: semaphore to mutex
This probe_mutex conforms to the new struct mutex type.
This patch converts it from the old semaphore to the new struct mutex.
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
---
drivers/ps3/ps3-vuart.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Index: linux-2.6.23/drivers/ps3/ps3-vuart.c
===
--- linux-2.6.23.orig/drivers/ps3/ps3-vuart.c
+++ linux-2.6.23/drivers/ps3/ps3-vuart.c
@@ -23,6 +23,7 @@
#include linux/interrupt.h
#include linux/workqueue.h
#include linux/bitops.h
+#include linux/mutex.h
#include asm/ps3.h
#include asm/firmware.h
@@ -877,7 +878,7 @@ static int ps3_vuart_handle_port_interru
struct vuart_bus_priv {
struct ports_bmp *bmp;
unsigned int virq;
- struct semaphore probe_mutex;
+ struct mutex probe_mutex;
int use_count;
struct ps3_system_bus_device *devices[PORT_COUNT];
} static vuart_bus_priv;
@@ -1015,7 +1016,7 @@ static int ps3_vuart_probe(struct ps3_sy
return -EINVAL;
}
- down(vuart_bus_priv.probe_mutex);
+ mutex_lock(vuart_bus_priv.probe_mutex);
result = ps3_vuart_bus_interrupt_get();
@@ -1075,7 +1076,7 @@ static int ps3_vuart_probe(struct ps3_sy
goto fail_probe;
}
- up(vuart_bus_priv.probe_mutex);
+ mutex_unlock(vuart_bus_priv.probe_mutex);
return result;
@@ -1088,7 +1089,7 @@ fail_dev_malloc:
fail_busy:
ps3_vuart_bus_interrupt_put();
fail_setup_interrupt:
- up(vuart_bus_priv.probe_mutex);
+ mutex_unlock(vuart_bus_priv.probe_mutex);
dev_dbg(dev-core, %s:%d: failed\n, __func__, __LINE__);
return result;
}
@@ -1127,7 +1128,7 @@ static int ps3_vuart_remove(struct ps3_s
BUG_ON(!dev);
- down(vuart_bus_priv.probe_mutex);
+ mutex_lock(vuart_bus_priv.probe_mutex);
dev_dbg(dev-core, - %s:%d: match_id %d\n, __func__, __LINE__,
dev-match_id);
@@ -1135,7 +1136,7 @@ static int ps3_vuart_remove(struct ps3_s
if (!dev-core.driver) {
dev_dbg(dev-core, %s:%d: no driver bound\n, __func__,
__LINE__);
- up(vuart_bus_priv.probe_mutex);
+ mutex_unlock(vuart_bus_priv.probe_mutex);
return 0;
}
@@ -1158,7 +1159,7 @@ static int ps3_vuart_remove(struct ps3_s
priv = NULL;
dev_dbg(dev-core, - %s:%d\n, __func__, __LINE__);
- up(vuart_bus_priv.probe_mutex);
+ mutex_unlock(vuart_bus_priv.probe_mutex);
return 0;
}
@@ -1178,7 +1179,7 @@ static int ps3_vuart_shutdown(struct ps3
BUG_ON(!dev);
- down(vuart_bus_priv.probe_mutex);
+ mutex_lock(vuart_bus_priv.probe_mutex);
dev_dbg(dev-core, - %s:%d: match_id %d\n, __func__, __LINE__,
dev-match_id);
@@ -1186,7 +1187,7 @@ static int ps3_vuart_shutdown(struct ps3
if (!dev-core.driver) {
dev_dbg(dev-core, %s:%d: no driver bound\n, __func__,
__LINE__);
- up(vuart_bus_priv.probe_mutex);
+ mutex_unlock(vuart_bus_priv.probe_mutex);
return 0;
}
@@ -1210,7 +1211,7 @@ static int ps3_vuart_shutdown(struct ps3
dev_dbg(dev-core, - %s:%d\n, __func__, __LINE__);
- up(vuart_bus_priv.probe_mutex);
+ mutex_unlock(vuart_bus_priv.probe_mutex);
return 0;
}
@@ -1221,7 +1222,7 @@ static int __init ps3_vuart_bus_init(voi
if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
return -ENODEV;
- init_MUTEX(vuart_bus_priv.probe_mutex);
+ mutex_init(vuart_bus_priv.probe_mutex);
return 0;
}
--
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
Hello All I am waiting for more feedback on the patches. If there are no objections please consider them for 2.6.25. With Regards Poonam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aggrwal Poonam Sent: Monday, December 10, 2007 5:23 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Gala Kumar Cc: Barkowski Michael; Phillips Kim; Kalra Ashish; Cutler Richard Subject: [PATCH 0/3] UCC TDM driver for MPC83xx platforms There are three patches [PATCH 1/3] drivers/misc : UCC TDM driver for mpc83xx platforms. This driver is usable in VoIP iind of applications to interface with SLIC kind of devices to exchange TDM voice samples. [PATCH 2/3] arch/ : Platform changes - device tree entries for UCC TDM driver for MPC8323ERDB platform. - QE changes related to TDM , like, 1) Modified ucc_fast_init so that it can be used by fast UCC based TDM driver. Mainly changes have been made to configure TDM clocks and Fsyncs. 2) Modified get_brg_clk so that it can return the input frequncy and input source of any BRG by reading the corresponding entries from device tree. 3) Added new nodes brg and clocks in the device tree which represent input clocks for different BRGs. 4) Modified qe_setbrg accordingly. - new device tree entries added for clocks and brg [PATCH 3/3] Documentation - Modified Documentation to explain the device tree entries related to UCC TDM driver and the new nodes added(clocks and brg) The patch applies over a merge of galak's for-2.6.25 plus for-2.6.24 plus of_doc_update branches. In brief the steps were git clone git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-galak git checkout -b for-2.6.25 origin/for-2.6.25 git checkout -b for-2.6.24 origin/for-2.6.24 git checkout -b of_doc_update origin/of_doc_update git pull . for-2.6.24# merge the other two git pull . for-2.6.25 git checkout -b tdm # clean slate for tdm rebase work Also after applying the patches changes have to be made corresponding to Tabi's patch qe: add function qe_clock_source. The driver has been tested with a VoIP stack and application on MPC8323ERDB. With Regards Poonam -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
David Gibson wrote:
On Thu, Jan 10, 2008 at 06:59:03PM -0500, Sean MacLennan wrote:
New version with recommended changes. Device types removed. FPGA
moved to correct bus.
[snip]
+[EMAIL PROTECTED],0 {
+compatible = pika,fpga;
+reg = 0 8000 2200;
Your reg property doesn't match your node name here...
Is the following correct?
[EMAIL PROTECTED],0 {
compatible = pika,fpga;
reg = 2 8000 2200;
interrupts = 18 8;
interrupt-parent = UIC0;
};
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
On Fri, Jan 11, 2008 at 12:21:20AM -0500, Sean MacLennan wrote:
David Gibson wrote:
On Thu, Jan 10, 2008 at 06:59:03PM -0500, Sean MacLennan wrote:
New version with recommended changes. Device types removed. FPGA
moved to correct bus.
[snip]
+ [EMAIL PROTECTED],0 {
+ compatible = pika,fpga;
+ reg = 0 8000 2200;
Your reg property doesn't match your node name here...
Is the following correct?
[EMAIL PROTECTED],0 {
compatible = pika,fpga;
reg = 2 8000 2200;
interrupts = 18 8;
interrupt-parent = UIC0;
};
No. You'd need
[EMAIL PROTECTED],8000 {
reg = 2 8000 2200;
...
};
If, indeed, the fpga really has 32 bit address lines and requires the
high one to be 1...
Or possibly what you actually want is:
[EMAIL PROTECTED],0 {
reg = 2 0 2200;
...
};
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ibm4xx_quiesce_eth?
On Thursday 10 January 2008, Josh Boyer wrote: On Thu, 10 Jan 2008 13:38:12 -0500 Sean MacLennan [EMAIL PROTECTED] wrote: What exactly does this function do? /* Quiesce the MAL and EMAC(s) since PIBS/OpenBIOS don't * do this for us */ On the taco, with the 440EP, it doesn't seem to make any difference if I call this or not. Since I am using u-boot, is it not needed? There are firmwares that do not reset the EMAC and MAL before passing control to the client program (Linux in our case). This can cause weird things to happen, like spurious interrupts or DMAs from the hardware overwriting kernel memory. So we quiesce the hardware really early on those. I don't believe U-Boot has that problem. If it does, it should be fixed :) No, U-Boot doesn't have this problem. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
David Gibson wrote:
Or possibly what you actually want is:
[EMAIL PROTECTED],0 {
reg = 2 0 2200;
...
};
That is what I want. I was missing a call to
ibm4xx_fixup_ebc_ranges(/plb/opb/ebc); (see updated patch3/5 to follow.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/dts/warp.dts 2008-01-11 00:57:34.0 -0500
@@ -0,0 +1,229 @@
+/*
+ * Device Tree Source for PIKA Warp
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = pika,warp;
+ compatible = pika,warp;
+ dcr-parent = /cpus/[EMAIL PROTECTED];
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,440EP;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by zImage */
+ timebase-frequency = 0; /* Filled in by zImage */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 8000;
+ d-cache-size = 8000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440ep,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440ep;
+ dcr-reg = 00e 002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440ep;
+ dcr-reg = 00c 002;
+ };
+
+ plb {
+ compatible = ibm,plb-440ep, ibm,plb-440gp, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-440ep, ibm,sdram-405gp;
+ dcr-reg = 010 2;
+ };
+
+ DMA0: dma {
+ compatible = ibm,dma-440ep, ibm,dma-440gp;
+ dcr-reg = 100 027;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-440ep, ibm,mcmal-440gp,
ibm,mcmal;
+ dcr-reg = 180 62;
+ num-tx-chans = 4;
+ num-rx-chans = 2;
+ interrupt-parent = MAL0;
+ interrupts = 0 1 2 3 4;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = /*TXEOB*/ 0 UIC0 a 4
+ /*RXEOB*/ 1 UIC0 b 4
+ /*SERR*/ 2 UIC1 0 4
+ /*TXDE*/ 3 UIC1 1 4
+ /*RXDE*/ 4 UIC1 2 4;
+ };
+
+ POB0: opb {
+ compatible = ibm,opb-440ep, ibm,opb-440gp,
ibm,opb;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 8000
+ 8000 0 8000 8000;
+ interrupt-parent = UIC1;
+ interrupts = 7 4;
+ clock-frequency = 0; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = ibm,ebc-440ep, ibm,ebc-440gp,
ibm,ebc;
+ dcr-reg = 012 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ clock-frequency = 0; /*
Re: [PATCH 3/5] Warp Base Platform
Update based on fixes to warp.dts.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..cd83c4f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c
holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-warp.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_WARP) += cuImage.warp
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/cuboot-warp.c 2008-01-11 01:08:54.0 -0500
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include 4xx.h
+#include cuboot.h
+
+#define TARGET_44x
+#include ppcboot.h
+
+static bd_t bd;
+
+static void warp_fixups(void)
+{
+ unsigned long sysclk = 6600;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_fixup_ebc_ranges(/plb/opb/ebc);
+ dt_fixup_mac_addresses(bd.bi_enetaddr);
+}
+
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+
+ platform_ops.fixups = warp_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ibm4xx_quiesce_eth?
Stefan Roese wrote: There are firmwares that do not reset the EMAC and MAL before passing control to the client program (Linux in our case). This can cause weird things to happen, like spurious interrupts or DMAs from the hardware overwriting kernel memory. So we quiesce the hardware really early on those. I don't believe U-Boot has that problem. If it does, it should be fixed :) No, U-Boot doesn't have this problem. Best regards, Stefan Thanks for the confirmation! One less thing to worry about. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
No comments? I really thought I would get raked over the coals for this one. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Enable RTC for Ebony and Walnut (v2)
On Fri, 11 Jan 2008 14:25:34 +1100 David Gibson [EMAIL PROTECTED] wrote:
+++ working-2.6/arch/powerpc/sysdev/of_rtc.c 2008-01-11 14:17:03.0
+1100
+static __initdata struct {
+ const char *compatible;
If you make this an array, then the string will become __initdata as well.
+ char *plat_name;
+} of_rtc_table[] = {
+ { ds1743-nvram, rtc-ds1742 },
+};
+ platform_device_register_simple(plat_name, -1, res, 1);
Do we care if this fails?
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp2IKpcmusmF.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
I have split up the patches slightly differently based on Josh's comments.
The first patch is basically the platform/44x files.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
No comments? I really thought I would get raked over the coals for this one.
Ah ha! A challenge! :-)
+++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.0 -0500
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if(gpio_base == NULL) {
^
space, please
+ if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
and again. Also split the assignment from the test.
+ printk(ERROR: Unable to remap GPIO base.\n);
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
space
+ case 0: leds = ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
again
+ case 0: leds = ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
no externs in C code - put it in a header file.
+
+ while(!kthread_should_stop()) {
space
+static int __devinit warp_fpga_init(void)
+{
+ struct device_node *np;
+ void *fpga;
+ int irq;
+ struct resource res;
+ struct task_struct *dtm_thread;
+
+ if((np = of_find_compatible_node(NULL, NULL, pika,fpga)) == NULL) {
space and split the assignment from the test.
+ printk(KERN_ERR __FILE__ : Unable to find fpga\n);
+ return -ENOENT;
+ }
+
+ if((irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
again
+ printk(KERN_ERR __FILE__ : irq_of_parse_and_map failed\n);
+ return -EBUSY;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ if(of_address_to_resource(np, 0, res) ||
+(fpga = ioremap(res.start, 0x24)) == NULL) {
and again
+ printk(KERN_ERR __FILE__ : Unable to map FPGA\n);
+ return -ENOENT;
+ }
+
+ /* Turn off the line LEDs */
+ out_be32(fpga + 8, 0);
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, pika-dtm);
+
+ if(IS_ERR(dtm_thread)) {
space
enough? :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpFpiSuuBHmo.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Warp Base Platform
Stephen Rothwell wrote:
On Wed, 09 Jan 2008 15:19:13 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
I have split up the patches slightly differently based on Josh's comments.
The first patch is basically the platform/44x files.
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
No comments? I really thought I would get raked over the coals for this one.
Ah ha! A challenge! :-)
I hoped somebody would respond to that ;)
+static int pika_dtm_thread(void *fpga)
+{
+extern int ad7414_get_temp(int index);
no externs in C code - put it in a header file.
I didn't know where to put this extern. It is fairly specific to this
driver, although a generic function... if that makes sense. It returns
the exact contents of the register rather than doing any conversion.
Any recommendations for a location gladly accepted.
And if anybody is wondering, the NAND code *does* work. It is commented
out because it requires u-boot 1.3.0 and most of the tacos have an
earlier u-boot. This is just a short term hack while we switch everybody
over to the new kernel.
And below has all the above mentioned fixes, except the extern.
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool PCI support if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x !CPM2 !8xx !PPC_83xx \
!PPC_85xx !PPC_86xx
default PCI_PERMEDIA if !4xx !CPM2 !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool PIKA Warp
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus
VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the PIKA for Computer
+ Telephony Developers link for more information.
+
#config LUAN
# bool Luan
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..c1733c0 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-11 02:08:20.0 -0500
@@ -0,0 +1,244 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include linux/init.h
+#include linux/of_platform.h
+#include linux/kthread.h
+
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/time.h
+#include asm/uic.h
+
+#include 44x.h
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = ibm,plb4, },
+ { .compatible = ibm,opb, },
+ { .compatible = ibm,ebc, },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, pika,warp))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = Warp,
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static
