* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-05 3:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linuxppc-dev, alsa-devel
In-Reply-To: <477EED00.8070207@freescale.com>
On 1/4/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
> > Don't put
> > that burden on the dts author.
>
> As the DTS author in question, I hereby declare that such a requirement is not
> a burden in the slightest. Thank you.
Dude, you work for *Freescale*. The set of dts authors affected
include every engineer writing a device tree for a board that uses
this part. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [patch 2/3] PS3: Add logical performance monitor device support
From: Geoff Levand @ 2008-01-05 3:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080105003019.595703814@am.sony.com>
Add PS3 logical performance monitor (lpm) device support to the
PS3 system-bus and platform device registration routines.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/device-init.c | 95 ++++++++++++++++++++++++++++++-
arch/powerpc/platforms/ps3/system-bus.c | 5 +
include/asm-powerpc/ps3.h | 7 ++
3 files changed, 106 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/ps3/lpm.c
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -30,6 +30,97 @@
#include "platform.h"
+static int __init ps3_register_lpm_devices(void)
+{
+ int result;
+ unsigned int pu_count;
+ u64 tmp1;
+ u64 tmp2;
+ struct layout {
+ struct ps3_system_bus_device dev;
+ } *p;
+
+ pr_debug(" -> %s:%d\n", __func__, __LINE__);
+
+ p = kzalloc(sizeof(*p), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ p->dev.match_id = PS3_MATCH_ID_LPM;
+ p->dev.dev_type = PS3_DEVICE_TYPE_LPM;
+
+ result = ps3_repository_read_num_pu(&pu_count);
+
+ if (result) {
+ pr_debug("%s:%d: ps3_repository_read_num_pu failed \n",
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ /* The current lpm driver only supports a single BE processor. */
+
+ if (pu_count > 1) {
+ pr_info("%s:%d: found %u BE processors, only one supported\n",
+ __func__, __LINE__, pu_count);
+ }
+
+ result = ps3_repository_read_pu_id(0, &p->dev.lpm.pu_id);
+
+ if (result) {
+ pr_debug("%s:%d: ps3_repository_read_pu_id failed \n",
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ result = ps3_repository_read_lpm_privileges(0, &tmp1,
+ &p->dev.lpm.rights);
+
+ if (result) {
+ pr_debug("%s:%d: ps3_repository_read_lpm_privleges failed \n",
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ lv1_get_logical_partition_id(&tmp2);
+
+ if (tmp1 != tmp2) {
+ pr_debug("%s:%d: wrong lpar\n",
+ __func__, __LINE__);
+ result = -1;
+ goto fail_rights;
+ }
+
+ if (!(p->dev.lpm.rights & PS3_LPM_RIGHTS_USE_LPM)) {
+ pr_debug("%s:%d: don't have rights to use lpm\n",
+ __func__, __LINE__);
+ result = -1;
+ goto fail_rights;
+ }
+
+ pr_debug("%s:%d: pu_id %lu, rights %lu(%lxh)\n",
+ __func__, __LINE__, p->dev.lpm.pu_id, p->dev.lpm.rights,
+ p->dev.lpm.rights);
+
+ result = ps3_system_bus_device_register(&p->dev);
+
+ if (result) {
+ pr_debug("%s:%d ps3_system_bus_device_register failed\n",
+ __func__, __LINE__);
+ goto fail_register;
+ }
+
+ pr_debug(" <- %s:%d\n", __func__, __LINE__);
+ return 0;
+
+
+fail_register:
+fail_rights:
+fail_read_repo:
+ kfree(p);
+ pr_debug(" <- %s:%d: failed\n", __func__, __LINE__);
+ return result;
+}
+
/**
* ps3_setup_gelic_device - Setup and register a gelic device instance.
*
@@ -787,6 +878,8 @@ static int __init ps3_register_devices(v
ps3_register_sound_devices();
+ ps3_register_lpm_devices();
+
pr_debug(" <- %s:%d\n", __func__, __LINE__);
return 0;
}
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -715,6 +715,7 @@ int ps3_system_bus_device_register(struc
static unsigned int dev_ioc0_count;
static unsigned int dev_sb_count;
static unsigned int dev_vuart_count;
+ static unsigned int dev_lpm_count;
if (!dev->core.parent)
dev->core.parent = &ps3_system_bus;
@@ -737,6 +738,10 @@ int ps3_system_bus_device_register(struc
snprintf(dev->core.bus_id, sizeof(dev->core.bus_id),
"vuart_%02x", ++dev_vuart_count);
break;
+ case PS3_DEVICE_TYPE_LPM:
+ snprintf(dev->core.bus_id, sizeof(dev->core.bus_id),
+ "lpm_%02x", ++dev_lpm_count);
+ break;
default:
BUG();
};
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -317,6 +317,7 @@ enum ps3_match_id {
PS3_MATCH_ID_STOR_FLASH = 8,
PS3_MATCH_ID_SOUND = 9,
PS3_MATCH_ID_GRAPHICS = 10,
+ PS3_MATCH_ID_LPM = 11,
};
#define PS3_MODULE_ALIAS_EHCI "ps3:1"
@@ -329,11 +330,13 @@ enum ps3_match_id {
#define PS3_MODULE_ALIAS_STOR_FLASH "ps3:8"
#define PS3_MODULE_ALIAS_SOUND "ps3:9"
#define PS3_MODULE_ALIAS_GRAPHICS "ps3:10"
+#define PS3_MODULE_ALIAS_LPM "ps3:11"
enum ps3_system_bus_device_type {
PS3_DEVICE_TYPE_IOC0 = 1,
PS3_DEVICE_TYPE_SB,
PS3_DEVICE_TYPE_VUART,
+ PS3_DEVICE_TYPE_LPM,
};
/**
@@ -350,6 +353,10 @@ struct ps3_system_bus_device {
struct ps3_dma_region *d_region; /* SB, IOC0 */
struct ps3_mmio_region *m_region; /* SB, IOC0*/
unsigned int port_number; /* VUART */
+ struct { /* LPM */
+ u64 pu_id;
+ u64 rights;
+ } lpm;
/* struct iommu_table *iommu_table; -- waiting for BenH's cleanups */
struct device core;
--
^ permalink raw reply
* [patch 1/3] PS3: Add logical performance monitor repository routines
From: Geoff Levand @ 2008-01-05 3:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Takashi Yamamoto
In-Reply-To: <20080105003019.595703814@am.sony.com>
From: Takashi Yamamoto <Takashi02_Yamamoto@hq.scei.sony.co.jp>
Add repository routines for the PS3 Logical Performance Monitor (lpm).
Signed-off-by: Takashi Yamamoto <Takashi02_Yamamoto@hq.scei.sony.co.jp>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/platform.h | 7 ++++
arch/powerpc/platforms/ps3/repository.c | 48 ++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -189,7 +189,7 @@ int ps3_repository_read_stor_dev_region(
/* repository pu and memory info */
int ps3_repository_read_num_pu(unsigned int *num_pu);
-int ps3_repository_read_ppe_id(unsigned int *pu_index, unsigned int *ppe_id);
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id);
int ps3_repository_read_rm_base(unsigned int ppe_id, u64 *rm_base);
int ps3_repository_read_rm_size(unsigned int ppe_id, u64 *rm_size);
int ps3_repository_read_region_total(u64 *region_total);
@@ -203,6 +203,11 @@ int ps3_repository_read_be_node_id(unsig
int ps3_repository_read_tb_freq(u64 node_id, u64 *tb_freq);
int ps3_repository_read_be_tb_freq(unsigned int be_index, u64 *tb_freq);
+/* repository performance monitor info */
+
+int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
+ u64 *rights);
+
/* repository 'Other OS' area */
int ps3_repository_read_boot_dat_addr(u64 *lpar_addr);
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -902,6 +902,54 @@ int ps3_repository_read_be_tb_freq(unsig
: ps3_repository_read_tb_freq(node_id, tb_freq);
}
+int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
+ u64 *rights)
+{
+ int result;
+ u64 node_id;
+
+ *lpar = 0;
+ *rights = 0;
+ result = ps3_repository_read_be_node_id(be_index, &node_id);
+ return result ? result
+ : read_node(PS3_LPAR_ID_PME,
+ make_first_field("be", 0),
+ node_id,
+ make_field("lpm", 0),
+ make_field("priv", 0),
+ lpar, rights);
+}
+
+int ps3_repository_read_num_pu(unsigned int *num_pu)
+{
+ int result;
+ u64 v1;
+
+ v1 = 0;
+ result = read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field("bi", 0),
+ make_field("pun", 0),
+ 0, 0,
+ &v1, NULL);
+ *num_pu = v1;
+ return result;
+}
+
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id)
+{
+ int result;
+ u64 v1;
+
+ v1 = 0;
+ result = read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field("bi", 0),
+ make_field("pu", pu_index),
+ 0, 0,
+ &v1, NULL);
+ *pu_id = v1;
+ return result;
+}
+
#if defined(DEBUG)
int ps3_repository_dump_resource_info(const struct ps3_repository_device *repo)
--
^ permalink raw reply
* [patch 0/3] PS3 logical performance monitor patches for 2.6.25
From: Geoff Levand @ 2008-01-05 3:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
This is a small set of patches that adds support for the PS3's logical
performance monitor.
The logical performance monitor is a hypervisor abstraction that provides
access to the Cell processor's performance monitoring features needed by
profilers such as oprofile and perfmon.
Please apply for 2.6.25.
[1/3] PS3: Add logical performance monitor repository routines
[2/3] PS3: Add logical performance monitor device support
[3/3] PS3: Add logical performance monitor driver support
-Geoff
--
^ permalink raw reply
* [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-05 2:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
I converted the i2c-ibm_iic driver from an ocp driver to an of_platform
driver. Since this driver is in the kernel.org kernel, should I rename
it and keep the old one around? I notice this was done with the emac
network driver.
This driver is required for the taco platform.
Cheers,
Sean
[-- Attachment #2: i2c-patch --]
[-- Type: text/plain, Size: 7545 bytes --]
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c466c6c..e9e1493 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -241,7 +241,6 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 9b43ff7..838006f 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -3,6 +3,10 @@
*
* Support for the IIC peripheral on IBM PPC 4xx
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ * Converted to an of_platform_driver.
+ *
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
@@ -39,12 +43,11 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
-#include <asm/ocp.h>
-#include <asm/ibm4xx.h>
+#include <linux/of_platform.h>
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -660,50 +663,58 @@ static inline u8 iic_clckdiv(unsigned int opb)
/*
* Register single IIC interface
*/
-static int __devinit iic_probe(struct ocp_device *ocp){
-
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ static int index = 0;
+ struct device_node *np = ofdev->node;
struct ibm_iic_private* dev;
struct i2c_adapter* adap;
- struct ocp_func_iic_data* iic_data = ocp->def->additions;
+ const u32 *addrp, *freq;
+ u64 addr;
int ret;
-
- if (!iic_data)
- printk(KERN_WARNING"ibm-iic%d: missing additional data!\n",
- ocp->def->index);
if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
- printk(KERN_CRIT "ibm-iic%d: failed to allocate device data\n",
- ocp->def->index);
+ printk(KERN_CRIT "ibm-iic: failed to allocate device data\n");
return -ENOMEM;
}
- dev->idx = ocp->def->index;
- ocp_set_drvdata(ocp, dev);
-
- if (!request_mem_region(ocp->def->paddr, sizeof(struct iic_regs),
- "ibm_iic")) {
+ dev->idx = index++;
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ if((addrp = of_get_address(np, 0, NULL, NULL)) == NULL ||
+ (addr = of_translate_address(np, addrp)) == OF_BAD_ADDR) {
+ printk(KERN_CRIT "ibm-iic%d: Unable to get iic address\n",
+ dev->idx);
ret = -EBUSY;
goto fail1;
}
- if (!(dev->vaddr = ioremap(ocp->def->paddr, sizeof(struct iic_regs)))){
+ if (!(dev->vaddr = ioremap(addr, sizeof(struct iic_regs)))){
printk(KERN_CRIT "ibm-iic%d: failed to ioremap device registers\n",
dev->idx);
ret = -ENXIO;
- goto fail2;
+ goto fail1;
}
init_waitqueue_head(&dev->wq);
- dev->irq = iic_force_poll ? -1 : ocp->def->irq;
- if (dev->irq >= 0){
+ if(iic_force_poll)
+ dev->irq = -1;
+ else if((dev->irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+ dev->irq = -1;
+ }
+
+ if (dev->irq >= 0) {
/* Disable interrupts until we finish initialization,
assumes level-sensitive IRQ setup...
*/
iic_interrupt_mode(dev, 0);
- if (request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)){
+ if(request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)){
printk(KERN_ERR "ibm-iic%d: request_irq %d failed\n",
- dev->idx, dev->irq);
+ dev->idx, dev->irq);
/* Fallback to the polling mode */
dev->irq = -1;
}
@@ -711,23 +722,30 @@ static int __devinit iic_probe(struct ocp_device *ocp){
if (dev->irq < 0)
printk(KERN_WARNING "ibm-iic%d: using polling mode\n",
- dev->idx);
+ dev->idx);
/* Board specific settings */
- dev->fast_mode = iic_force_fast ? 1 : (iic_data ? iic_data->fast_mode : 0);
+ dev->fast_mode = iic_force_fast ? 1 : 0;
- /* clckdiv is the same for *all* IIC interfaces,
- * but I'd rather make a copy than introduce another global. --ebs
+ /* clckdiv is the same for *all* IIC interfaces, but I'd rather
+ * make a copy than introduce another global. --ebs
*/
- dev->clckdiv = iic_clckdiv(ocp_sys_info.opb_bus_freq);
+ if((freq = of_get_property(np, "clock-frequency", NULL)) == NULL &&
+ (freq = of_get_property(np->parent, "clock-frequency", NULL)) == NULL) {
+ printk(KERN_CRIT "ibm-iic%d: Unable to get bus frequency\n", dev->idx);
+ ret = -EBUSY;
+ goto fail;
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
DBG("%d: clckdiv = %d\n", dev->idx, dev->clckdiv);
-
+
/* Initialize IIC interface */
iic_dev_init(dev);
/* Register it with i2c layer */
adap = &dev->adap;
- adap->dev.parent = &ocp->dev;
+ adap->dev.parent = &ofdev->dev;
strcpy(adap->name, "IBM IIC");
i2c_set_adapdata(adap, dev);
adap->id = I2C_HW_OCP;
@@ -737,13 +755,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
adap->client_unregister = NULL;
adap->timeout = 1;
adap->retries = 1;
-
- /*
- * If "dev->idx" is negative we consider it as zero.
- * The reason to do so is to avoid sysfs names that only make
- * sense when there are multiple adapters.
- */
- adap->nr = dev->idx >= 0 ? dev->idx : 0;
+ adap->nr = dev->idx;
if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
printk(KERN_CRIT "ibm-iic%d: failed to register i2c adapter\n",
@@ -763,20 +775,19 @@ fail:
}
iounmap(dev->vaddr);
-fail2:
- release_mem_region(ocp->def->paddr, sizeof(struct iic_regs));
fail1:
- ocp_set_drvdata(ocp, NULL);
- kfree(dev);
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
return ret;
}
/*
* Cleanup initialized IIC interface
*/
-static void __devexit iic_remove(struct ocp_device *ocp)
+static int __devexit iic_remove(struct of_device *ofdev)
{
- struct ibm_iic_private* dev = (struct ibm_iic_private*)ocp_get_drvdata(ocp);
+ struct ibm_iic_private* dev = (struct ibm_iic_private*)dev_get_drvdata(&ofdev->dev);
+
BUG_ON(dev == NULL);
if (i2c_del_adapter(&dev->adap)){
printk(KERN_CRIT "ibm-iic%d: failed to delete i2c adapter :(\n",
@@ -793,41 +804,37 @@ static void __devexit iic_remove(struct ocp_device *ocp)
free_irq(dev->irq, dev);
}
iounmap(dev->vaddr);
- release_mem_region(ocp->def->paddr, sizeof(struct iic_regs));
kfree(dev);
}
+
+ return 0;
}
-static struct ocp_device_id ibm_iic_ids[] __devinitdata =
+
+static struct of_device_id ibm_iic_match[] =
{
- { .vendor = OCP_VENDOR_IBM, .function = OCP_FUNC_IIC },
- { .vendor = OCP_VENDOR_INVALID }
+ { .type = "i2c", .compatible = "ibm,iic", },
+ {}
};
-MODULE_DEVICE_TABLE(ocp, ibm_iic_ids);
-
-static struct ocp_driver ibm_iic_driver =
+static struct of_platform_driver ibm_iic_driver =
{
- .name = "iic",
- .id_table = ibm_iic_ids,
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+
.probe = iic_probe,
- .remove = __devexit_p(iic_remove),
-#if defined(CONFIG_PM)
- .suspend = NULL,
- .resume = NULL,
-#endif
+ .remove = iic_remove,
};
-static int __init iic_init(void)
+static int __init ibm_iic_init(void)
{
printk(KERN_INFO "IBM IIC driver v" DRIVER_VERSION "\n");
- return ocp_register_driver(&ibm_iic_driver);
+ return of_register_platform_driver(&ibm_iic_driver);
}
+module_init(ibm_iic_init);
-static void __exit iic_exit(void)
+static void __exit ibm_iic_exit(void)
{
- ocp_unregister_driver(&ibm_iic_driver);
+ of_unregister_platform_driver(&ibm_iic_driver);
}
-
-module_init(iic_init);
-module_exit(iic_exit);
+module_exit(ibm_iic_exit);
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-05 2:43 UTC (permalink / raw)
To: Jon Smirl, linuxppc-dev, alsa-devel
In-Reply-To: <20080103230004.GA18709@sirena.org.uk>
Mark Brown wrote:
> Each individual call to set_sysclk() only takes three parameters but it
> can be called repeatedly and some configurations are going to require
> this.
In other words, ...
clock1 = <0, bb8000>
clock2 = <1, 653230>
clock23 = <0, ab2372>
> and of course the ordering matters.
Ok, you got me there. But then, isn't this just another example where the
device tree is incapable of describing a complex configuration, and so we need
a platform driver?
> Indeed. Providing the device tree stuff doesn't get set in stone I'm
> not sure we need to nail this down perfectly for ASoC v1 when we're
> running into trouble working around it.
I definitely agree with that. I'll be the first to admit that this driver,
much like ASoC V1, is a prototype.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-05 2:39 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <20080103235156.GE12883@localhost.localdomain>
David Gibson wrote:
> And what distinction are you drawing between "first" and "second"
> here?
Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection,
but it will never work without an I2S connection.
> Why would the I2S need to scan for codecs? Wouldn't it be up to the
> codec driver to register with I2S?
Not in ASoC V1. The codec driver registers with ASoC, but the actual
connection to other devices (e.g. the I2S driver) is done either in the I2S
driver or in the fabric driver, depending on your mood. And that connection
is done via a pointer to a structure in the codec driver.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-05 2:35 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40801031113od68e2a3m6cb60b8fa6f26c17@mail.gmail.com>
Grant Likely wrote:
> On 1/3/08, Scott Wood <scottwood@freescale.com> wrote:
>> Grant Likely wrote:
>>> On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
>>>> Grant Likely wrote:
>>>>
>>>>> Why not be a child of the i2c bus with a phandle to the ssi bus?
>>>> Because when I probe the SSI node, I want to know what the attached codec is.
>>>> So if anything, I would need a pointer from the SSI bus *to* the respective
>>>> child on the I2C bus.
>>> That's fine too (it's what is done with Ethernet PHYs). My preference
>>> is the other way around, but it's not a big issue in this case.
>> I'd just link in both directions, and let software follow it in
>> whichever direction it prefers.
>
> Gah! Don't do that! Then you need to maintain both directions in the
> dts file.
So? What's wrong with that?
> Software is good at generating reverse mappings.
What software would that be? Currently, there is no software that will do
that? Or are you saying that you want my driver to search the entire device
tree until it finds the reverse mapping? I don't think *that* is a good idea.
> Don't put
> that burden on the dts author.
As the DTS author in question, I hereby declare that such a requirement is not
a burden in the slightest. Thank you.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* [PATCH] enable built-in networking for Sequoia defconfig
From: Hollis Blanchard @ 2008-01-04 23:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
Enable EMAC driver for Sequoia (and while we're in there, disable
Macintosh drivers for Sequoia and Bamboo).
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
diff --git a/arch/powerpc/configs/bamboo_defconfig b/arch/powerpc/configs/bamboo_defconfig
--- a/arch/powerpc/configs/bamboo_defconfig
+++ b/arch/powerpc/configs/bamboo_defconfig
@@ -372,9 +372,7 @@ CONFIG_MISC_DEVICES=y
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
-CONFIG_MACINTOSH_DRIVERS=y
-# CONFIG_MAC_EMUMOUSEBTN is not set
-# CONFIG_WINDFARM is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
diff --git a/arch/powerpc/configs/sequoia_defconfig b/arch/powerpc/configs/sequoia_defconfig
--- a/arch/powerpc/configs/sequoia_defconfig
+++ b/arch/powerpc/configs/sequoia_defconfig
@@ -446,9 +446,7 @@ CONFIG_MISC_DEVICES=y
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
-CONFIG_MACINTOSH_DRIVERS=y
-# CONFIG_MAC_EMUMOUSEBTN is not set
-# CONFIG_WINDFARM is not set
+# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
@@ -459,10 +457,28 @@ CONFIG_NETDEVICES=y
# CONFIG_VETH is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
-# CONFIG_NET_ETHERNET is not set
+# CONFIG_PHYLIB is not set
+CONFIG_NET_ETHERNET=y
+# CONFIG_MII is not set
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=128
+CONFIG_IBM_NEW_EMAC_TXB=64
+CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
+# CONFIG_IBM_NEW_EMAC_DEBUG is not set
CONFIG_IBM_NEW_EMAC_ZMII=y
CONFIG_IBM_NEW_EMAC_RGMII=y
+# CONFIG_IBM_NEW_EMAC_TAH is not set
CONFIG_IBM_NEW_EMAC_EMAC4=y
+# CONFIG_NET_PCI is not set
+# CONFIG_B44 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
^ permalink raw reply
* Re: [PATCh v3] powerpc: add hugepagesz boot-time parameter
From: Arnd Bergmann @ 2008-01-04 23:03 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jon Tollefson, Adam Litke, mel, David Gibson, Paul Mackerras,
csnook
In-Reply-To: <477E9073.1050900@linux.vnet.ibm.com>
On Friday 04 January 2008, Jon Tollefson wrote:
> Arnd Bergmann wrote:
> > We started discussing this in v1, but the discussion got sidetracked:
> > Is there a technical reason why you don't also allow 1M pages, which
> > may be useful in certain scenarios?
> > =A0=20
> No, it was mostly a matter of the time I have had and machines easily
> available to me for testing. =A0I don't know of a technical reason that
> would prevent supporting 1M huge pages, but would want the tests in the
> libhugetlbfs suite to pass, etc.
Ok. Do you think the kernel should be able to change the page size settings
in that case, or should we rely on whatever the firmware tells us it has
configured already?
Arnd <><
^ permalink raw reply
* [PATCH 3/3] Remove \n from yyerror() call.
From: Scott Wood @ 2008-01-04 21:10 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
The \n is provided by yyerror().
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
dtc-parser.y | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dtc-parser.y b/dtc-parser.y
index f50f2f0..3a24d14 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -332,7 +332,7 @@ subnodes:
}
| subnode propdef
{
- yyerror("syntax error: properties must precede subnodes\n");
+ yyerror("syntax error: properties must precede subnodes");
YYERROR;
}
;
--
1.5.3
^ permalink raw reply related
* [PATCH 1/3] Add support for binary includes.
From: Scott Wood @ 2008-01-04 21:10 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
A property's data can be populated with a file's contents
as follows:
node {
prop = /incbin/("path/to/data");
};
A subset of a file can be included by passing start and size parameters.
For example, to include bytes 8 through 23:
node {
prop = /incbin/("path/to/data", 8, 16);
};
As with /include/, non-absolute paths are looked for in the directory
of the source file that includes them.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Makefile | 2 +-
data.c | 37 ++++++++++++++++++++++++++++++++++++-
dtc-lexer.l | 7 +++++++
dtc-parser.y | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
dtc.h | 5 +++++
5 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 6e07862..578d8c1 100644
--- a/Makefile
+++ b/Makefile
@@ -16,7 +16,7 @@ LOCAL_VERSION =
CONFIG_LOCALVERSION =
CPPFLAGS = -I libfdt
-CFLAGS = -Wall -g -Os
+CFLAGS = -Wall -g -Os -D_FILE_OFFSET_BITS=64
BISON = bison
LEX = flex
diff --git a/data.c b/data.c
index a94718c..f9464bf 100644
--- a/data.c
+++ b/data.c
@@ -19,6 +19,7 @@
*/
#include "dtc.h"
+#include "srcpos.h"
void data_free(struct data d)
{
@@ -189,7 +190,41 @@ struct data data_copy_file(FILE *f, size_t len)
d = data_grow_for(empty_data, len);
d.len = len;
- fread(d.val, len, 1, f);
+ if (fread(d.val, len, 1, f) != 1) {
+ yyerrorf("Couldn't read %zu bytes from file: %s",
+ len, feof(f) ? "end-of-file" : strerror(errno));
+ return empty_data;
+ }
+
+ return d;
+}
+
+struct data data_copy_file_all(FILE *f)
+{
+ char buf[4096];
+ struct data d = empty_data;
+
+ while (1) {
+ size_t ret = fread(buf, 1, sizeof(buf), f);
+ if (ret == 0) {
+ if (!feof(f))
+ yyerrorf("Error reading file: %s", strerror(errno));
+
+ break;
+ }
+
+ assert(ret <= sizeof(buf));
+
+ d = data_grow_for(d, ret);
+ memcpy(d.val + d.len, buf, ret);
+
+ if (d.len + ret < d.len) {
+ yyerror("Binary include too large");
+ break;
+ }
+
+ d.len += ret;
+ }
return d;
}
diff --git a/dtc-lexer.l b/dtc-lexer.l
index bfb996e..7670aca 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -190,6 +190,13 @@ static int dts_version; /* = 0 */
return DT_PROPNODENAME;
}
+"/incbin/" {
+ yylloc.file = srcpos_file;
+ yylloc.first_line = yylineno;
+ DPRINT("Binary Include\n");
+ return DT_INCBIN;
+ }
+
<*>[[:space:]]+ /* eat whitespace */
<*>"/*"([^*]|\*+[^*/])*\*+"/" {
diff --git a/dtc-parser.y b/dtc-parser.y
index da7f6f5..f50f2f0 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -21,6 +21,8 @@
%locations
%{
+#include <stdio.h>
+
#include "dtc.h"
#include "srcpos.h"
@@ -47,6 +49,7 @@ extern int treesource_error;
struct node *node;
struct node *nodelist;
struct reserve_info *re;
+ struct range range;
}
%token DT_V1
@@ -59,6 +62,7 @@ extern int treesource_error;
%token <data> DT_STRING
%token <labelref> DT_LABEL
%token <labelref> DT_REF
+%token DT_INCBIN
%type <data> propdata
%type <data> propdataprefix
@@ -79,6 +83,7 @@ extern int treesource_error;
%type <node> subnode
%type <nodelist> subnodes
%type <labelref> label
+%type <range> mayberange
%%
@@ -197,12 +202,56 @@ propdata:
{
$$ = data_add_marker($1, REF_PATH, $2);
}
+ | propdataprefix DT_INCBIN '(' DT_STRING mayberange ')'
+ {
+ struct search_path path = { srcpos_file->dir, NULL, NULL };
+ struct dtc_file *file = dtc_open_file($4.val, &path);
+
+ if (!file) {
+ yyerrorf("Cannot open file \"%s\": %s",
+ $4.val, strerror(errno));
+ } else {
+ struct data d = empty_data;
+
+ if ($5.len >= 0) {
+ if (fseek(file->file, $5.start, SEEK_SET) == 0)
+ d = data_copy_file(file->file, $5.len);
+ else
+ yyerrorf("Couldn't seek to offset %llu in \"%s\": %s",
+ (unsigned long long)$5.start,
+ $4.val, strerror(errno));
+ } else {
+ d = data_copy_file_all(file->file);
+ }
+
+ $$ = data_merge($1, d);
+ dtc_close_file(file);
+ }
+ }
| propdata DT_LABEL
{
$$ = data_add_marker($1, LABEL, $2);
}
;
+mayberange:
+ /* empty */
+ {
+ $$.len = -1;
+ }
+ | ',' addr ',' addr
+ {
+ $$.start = $2;
+ $$.len = $4;
+
+ if ($$.len != $4) {
+ yyerrorf("Length %llu is too large",
+ (unsigned long long)$4);
+ $$.len = -1;
+ }
+ }
+ ;
+
propdataprefix:
/* empty */
{
diff --git a/dtc.h b/dtc.h
index cba9d28..509fbc9 100644
--- a/dtc.h
+++ b/dtc.h
@@ -122,6 +122,10 @@ struct data {
struct marker *markers;
};
+struct range {
+ off_t start;
+ int len;
+};
#define empty_data ((struct data){ /* all .members = 0 or NULL */ })
@@ -138,6 +142,7 @@ struct data data_grow_for(struct data d, int xlen);
struct data data_copy_mem(const char *mem, int len);
struct data data_copy_escape_string(const char *s, int len);
struct data data_copy_file(FILE *f, size_t len);
+struct data data_copy_file_all(FILE *f);
struct data data_append_data(struct data d, const void *p, int len);
struct data data_insert_at_marker(struct data d, struct marker *m,
--
1.5.3
^ permalink raw reply related
* [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.
From: Scott Wood @ 2008-01-04 21:10 UTC (permalink / raw)
To: jdl; +Cc: linuxppc-dev
Also, free file->dir when freeing file.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
srcpos.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/srcpos.c b/srcpos.c
index 7340c33..7a0c47e 100644
--- a/srcpos.c
+++ b/srcpos.c
@@ -86,6 +86,16 @@ struct dtc_file *dtc_open_file(const char *fname,
return file;
}
+ if (fname[0] == '/') {
+ file->file = fopen(fname, "r");
+
+ if (!file->file)
+ goto out;
+
+ file->name = strdup(fname);
+ return file;
+ }
+
if (!search)
search = &default_search;
@@ -100,6 +110,7 @@ struct dtc_file *dtc_open_file(const char *fname,
}
out:
+ free((void *)file->dir);
free(file);
return NULL;
}
@@ -109,5 +120,6 @@ void dtc_close_file(struct dtc_file *file)
if (fclose(file->file))
die("Error closing \"%s\": %s\n", file->name, strerror(errno));
+ free((void *)file->dir);
free(file);
}
--
1.5.3
^ permalink raw reply related
* Control not branching to the instruction present at resetvec i.e 0xfffffffc
From: ravi.rao @ 2008-01-04 20:58 UTC (permalink / raw)
To: linuxlink-help; +Cc: Miki.Groftisza, linuxppc-embedded
In-Reply-To: <14612548.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
Hi All,
We have a custom target board based on PPC-EP405. We just got the
board from the hardware team .I connected the board to BDI200 and powered
it on.
The control came to the resetvec address which is 0xfffffffc. I was able
to read and write to flash. So I erased the flash and burnt the bootloader
into flash from 0xfffc0000.
I verified that the instruction at 0xfffffffc is 4bfc2104 whicis actually
a branch to 0xfffc2100. Also a memory dump of 0xfffc2100 shows the correct
code. This proved that
the uboot bootloader was burnt properly.
Now when I reset the board the control never reaches 0xfffc2100 i.e for
some reason the code at the resetvec is not getting executed. Any help or
pointers to resolve this is greatly appreciated.
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
[-- Attachment #2: Type: text/html, Size: 2192 bytes --]
^ permalink raw reply
* Re: [PATCh v3] powerpc: add hugepagesz boot-time parameter
From: Jon Tollefson @ 2008-01-04 20:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Adam Litke, mel, David Gibson, linuxppc-dev, Paul Mackerras,
csnook
In-Reply-To: <200801040034.25329.arnd@arndb.de>
Arnd Bergmann wrote:
> We started discussing this in v1, but the discussion got sidetracked:
> Is there a technical reason why you don't also allow 1M pages, which
> may be useful in certain scenarios?
>
No, it was mostly a matter of the time I have had and machines easily
available to me for testing. I don't know of a technical reason that
would prevent supporting 1M huge pages, but would want the tests in the
libhugetlbfs suite to pass, etc.
> On the Cell/B.E. platforms (IBM/Mercury blades, Toshiba Celleb, PS3), the
> second large page size is an option that can be set in a HID SPR
> to either 64KB or 1MB. Unfortunately, we can't do these two simultaneously,
> but the firmware can change the default and put it into the device tree,
> or you could have the kernel override the firmware settings.
>
> Going a lot further, do you have plans for a fully dynamic hugepage size,
> e.g. using a mount option for hugetlbfs? I can see that as rather useful,
> but at the same time it's probably much more complicated than the boot time
> option.
>
Eventually we will want to support dynamic huge page sizes. This is
already being looked into. In the meantime we can have some flexibility
with a boot-time parameter though.
> Arnd <><
>
Jon
^ permalink raw reply
* Re: [PATCH 1/3] Add yyerrorf() for formatted error messages.
From: Scott Wood @ 2008-01-04 16:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JAnYr-0003hT-06@jdl.com>
On Fri, Jan 04, 2008 at 08:30:12AM -0600, Jon Loeliger wrote:
> All three applied (to DTC :-)).
>
> Will you follow up with a patch for /bininc/ or /bin-include/
> as well now? (I'm fine with either, and I forget where David's
> preference there landed.)
Yes, probably sometime today.
-Scott
^ permalink raw reply
* Re: Outstanding DTC patches?
From: Jon Loeliger @ 2008-01-04 14:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20080104024324.GA4326@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Ah, I think I sent it by private mail, so it won't be in patchwork.
> Here you are:
Ah, that explains it.
> dtc/libfdt: Add README clarifying licensing
>
> The fact the dtc are distributed together, but have different licenses
> can be a bit confusing. Several people have enquired as to what the
> deal is with the libfdt licensing, so this patch adds a README
> clarifying the situation with a rationale.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
After correcting the log-message English a bit, it was applied.
The fact that the dtc and libfdt are distributed together, but have
different licenses, can be a bit confusing. Several people have
enquired as to what the deal is with the libfdt licensing, so this
patch adds a README clarifying the situation with a rationale.
To be in agreement in the record, I too signed off on that patch.
Objections to either, please let me know!
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 1/3] Add yyerrorf() for formatted error messages.
From: Jon Loeliger @ 2008-01-04 14:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <477D73B6.1070108@freescale.com>
So, like, the other day Scott Wood mumbled:
>
> I forgot to tag them as such, but these are of course dtc patches and
> not Linux patches.
All three applied (to DTC :-)).
Will you follow up with a patch for /bininc/ or /bin-include/
as well now? (I'm fine with either, and I forget where David's
preference there landed.)
Thanks,
jdl
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Add EMAC support to Kilauea defconfig
From: Stefan Roese @ 2008-01-04 14:00 UTC (permalink / raw)
To: linuxppc-dev
Somehow the EMAC support was dropped (or never really added) to the
Kilauea defconfig file. This patch finally adds EMAC support.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/configs/kilauea_defconfig | 23 +++++++++++++++++++++--
1 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/configs/kilauea_defconfig b/arch/powerpc/configs/kilauea_defconfig
index c86e756..8dca3d4 100644
--- a/arch/powerpc/configs/kilauea_defconfig
+++ b/arch/powerpc/configs/kilauea_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc6
-# Mon Dec 24 11:18:12 2007
+# Thu Jan 3 14:21:31 2008
#
# CONFIG_PPC64 is not set
@@ -453,9 +453,28 @@ CONFIG_NETDEVICES=y
# CONFIG_VETH is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
-# CONFIG_NET_ETHERNET is not set
+# CONFIG_PHYLIB is not set
+CONFIG_NET_ETHERNET=y
+# CONFIG_MII is not set
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=256
+CONFIG_IBM_NEW_EMAC_TXB=256
+CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
+# CONFIG_IBM_NEW_EMAC_DEBUG is not set
+# CONFIG_IBM_NEW_EMAC_ZMII is not set
CONFIG_IBM_NEW_EMAC_RGMII=y
+# CONFIG_IBM_NEW_EMAC_TAH is not set
CONFIG_IBM_NEW_EMAC_EMAC4=y
+# CONFIG_NET_PCI is not set
+# CONFIG_B44 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
--
1.5.4.rc2
^ permalink raw reply related
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-04 13:39 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, alsa-devel
In-Reply-To: <20080103234725.GD12883@localhost.localdomain>
On Fri, Jan 04, 2008 at 10:47:25AM +1100, David Gibson wrote:
> On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:
> > I'm no expert on this, but I think from the PowerPC point-of-view,
> > the *ideal* situation would be if the ASoC fabric driver were
> > generic, maybe even part of ASoC itself, and everything it needed
> > could be obtained from the device tree.
> Nice idea in principle, and may be the way to go ultimately, but very
> tricky in practice. The whole reason the fabric driver concept exists
> (from other archs) is that there are an awful lot of variants on how
> to wire the sound components together. Devising a way of expressing
> those connections in the device tree that's sufficient will be very
> curly. Then we'd have to build the fabric driver that can parse and
> process them all.
Yes, there's an issue with complexity here. Some of the individual
components are going to have quite a lot of different things to
configure by themselves even for static use and the choices made may
depend on the usage at run time rather than being a static property of
the hardware. It's also more than just connections - many machine
drivers will provide control for components like analogue switches or
simple amplifiers controlled through GPIO lines or memory mapped
registers (these are generally specific to the board).
As a result I would expect that you will always have systems using
platform based drivers. I don't think that this is a bad thing -
something that can completely replace them would be able to do anything
that can be done in C in the kernel.
> And then, people will no doubt produce device trees
> with errors in the connection information, so we'll still need
> platform-specific workarounds.
The other concern with this is that it risks turning the interface to
the codec and controller drivers into an ABI which isn't expected at the
minute and might cause problems in the future. At the minute the
drivers export constants to their users defining the parameters they
can configure and (for things like source selection) the possible
values. These can currently be changed at will and there's no great
consistency in their values between drivers.
There would also be difficulties in writing the device tree - without
the symbolic names you're going to end up with strings of numeric
constants in the device tree which are not going to be terribly readable
and will be error prone.
> If we want sound working any time soon, we'll want to stick with the
> platform based fabric drivers for the time being.
Like I say, I would expect that you're always going to want to have
platform based drivers. Even if a given board can be represented in a
device tree some users will find it more straightforward or convenient
to write C code for their platform and have the device tree specify more
basic configuration options that correspond to the things they want to
vary between boards.
^ permalink raw reply
* RE: File system problem
From: mojtaba @ 2008-01-04 11:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <169c03cb0801031557r1efbd89fsd971533e04477daa@mail.gmail.com>
Hi,
Thank you all for your helps.
Today I tried to make the file system again using buildroot. This time I
included busybox to the packages for target system (Before that, I did =
not
include the busybox). Surprisingly the system boot correctly.
But, I do not want to use busybox. I already compiled coreutiles and I =
want
to put them on my target system. After building the root file system I =
tried
to replace those symbolic links to busybox(such as ls, cp, ...) with the
real commands from coreutiles but I got this error.
Freeing unused kernel memory: 76k init
missing file opeKernel panic - not syncing: Attempted to kill init!
rand
Try `/bin/Rebooting in 180 seconds..sh --help' for more information.
So, how can I use coreutils instead of busybox?
Regards,
Mojtaba
-----Original Message-----
From: jsamch@gmail.com [mailto:jsamch@gmail.com] On Behalf Of =
Jean-Samuel
Chenard
Sent: Friday, January 04, 2008 12:58 AM
To: linuxppc-embedded@ozlabs.org; kernelppc@gmail.com
Subject: RE: File system problem
> Message: 9
> Date: Thu, 3 Jan 2008 18:00:14 +0100
> From: "mojtaba"
>
> Actually, I removed the console and null created by buildroot and =
create
> them manually using make node. This time the system freezes at this =
point.
> "Freeing unused kernel memory: 76k init"
Hi Mojtaba,
I just want to comment on your observation that the file size in /dev
was zero. This is normal as the device files are 'special' since they
are a mean of abstracting the interface to the kernel. I had to read
the online book listed below before I could understand the inner
workings of those special files. If you plan on interfacing your FPGA
with the Linux Kernel, I suggest you read it too, as it is a very
insightful book:
http://lwn.net/Kernel/LDD3/
At this point, your system is not frozen, but your init script and
configuration files are probably not all correctly set. You might
need to read some documentation about buildroot to see what its init
scripts are trying to do.
You might be missing a library or symlink (I got that problem in my
attempt to build the BusyBox root filesystem from scratch). One way
to go at the problem is to pass the init=3D/bin/ash or something like
that to your kernel at the boot prompt (you could even make some
trivial 'hello world' program and pass it to the kernel as the init
process). This way, you can dive right into a shell or your program
and avoid init and its configuration.
After some copying of required libraries in /lib (I'm using uClibc)
and the creation of the required symbolic links, I got my Busybox root
filesystem working on my ML-310 board.
Good luck!
Regards,
Jean-Samuel
--=20
Ph.D. candidate
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* Re: MPC8260ADS and linux-2.6
From: suja Baburaj @ 2008-01-04 11:22 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Scott Wood, linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03D1682A@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
Hi,
The PQ2FADS support worked for MPC8260ADS.
Thanks to Rune and scott for the input.
-suja
> >
> > suja Baburaj wrote:
> > > I have an MPC8260ADS board with (eldk)linux-2.4.25 working
> > fine on it.
> > > Now i want to try linux-2.6.X on the board.
> >
> > There's no support for that specific board in mainstream 2.6
> > yet, but it
> > should be fairly simple to get it working using the
> > mpc8272ads support
> > as an example.
>
> There is support, but it is in arch/ppc not arch/powerpc
> (PQ2FADS support works for this board in arch/ppc)
>
[-- Attachment #2: Type: text/html, Size: 860 bytes --]
^ permalink raw reply
* Re: ioremap and outb
From: Arnd Bergmann @ 2008-01-04 10:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080104102037.GA31627@mail.gnudd.com>
On Friday 04 January 2008, Alessandro Rubini wrote:
> > =A0 =A0 =A0 =A0 =A0addr=3Dioremap(base_addr,size); =A0 =A0 =A0 =A0 =A0/=
/ Remap to Mem mapped
>=20
> Yes.
In newer drivers that are specific to powerpc, it's often easier
to use the of_iomap() function to map a device, so you don't
have to calculate the base address manually from the device tree.
> > =A0 =A0 =A0 =A0 =A0out_8(addr) and in_8(addr);=20
>=20
> It should be right, although __raw_readb() and __raw_writeb() may
> suffice for you.
Actually not. While they may work, the __raw_* functions do not have
a specific meaning in device drivers. Depending on the I/O model, they
may or may not work on a given platform. The {in,out}_{8,{be,le}{16,32,64}}
functions however are defined to operate on local (not PCI) ioremapped
mmio devices, and are usually more efficient than the {read,write}{b,w,l,q}
variant you'd use on PCI devices.
Arnd <><
^ permalink raw reply
* Re: ioremap and outb
From: Alessandro Rubini @ 2008-01-04 10:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14612559.post@talk.nabble.com>
Please don't change subject matter without changing subject line, and please
open a new thread when asking a new question.
> I am writing a driver in which device port is mapped to CPLD and 8 bit data
> bus is directly connected from processor to CPLD. Read write on CPLD memory
> mapped (buffer/register) is required to control the device. This is now IO
> mapped to processor.
This is typical. You'll find quite a lot of examples.
> addr=ioremap(base_addr,size); // Remap to Mem mapped
Yes.
> out_8(addr) and in_8(addr);
It should be right, although __raw_readb() and __raw_writeb() may
suffice for you. Please check the comments in <asm/io.h>.
It may also happen that you need to read/write 32 bits instead of 8,
but this depends on your specific hardware.
/alessandro
^ permalink raw reply
* Re: Drivers' probe function calling order
From: Misbah khan @ 2008-01-04 8:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080103215456.GA20691@mail.gnudd.com>
Hi Mr Rubini ...
I am writing a driver in which device port is mapped to CPLD and 8 bit data
bus is directly connected from processor to CPLD. Read write on CPLD memory
mapped (buffer/register) is required to control the device. This is now IO
mapped to processor.
I need to know whether i am right if i impliment like this :-
addr=ioremap(base_addr,size); // Remap to Mem mapped
address
out_8(addr) and in_8(addr);
Alessandro Rubini wrote:
>
>
>> how can I force the system to call
>> probe function of the spi driver first?
>
> You can declare their init functions at different initcall level. For
> example declaring the dataflash one as late_initcall(). Or declare
> the spi one as subsys_initcall() -- whatever makes more sense.
>
> There might be cleaner ways according to your setup, but this will
> surely work.
>
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Drivers%27-probe-function-calling-order-tp14601099p14612559.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox