* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: Scott Wood @ 2007-12-17 17:03 UTC (permalink / raw)
To: Anton Vorontsov, Kumar Gala, Stephen Rothwell, linuxppc-dev,
Kim Phillips
In-Reply-To: <20071217051403.GB3477@localhost.localdomain>
On Mon, Dec 17, 2007 at 04:14:03PM +1100, David Gibson wrote:
> > + crypto@30000 {
> > + device_type = "crypto";
> > + model = "SEC2";
> > + compatible = "talitos";
>
> This device_type/compatible/model stuff is also crap, although I
> suspect it needs to be fixed in the driver, as gianfar (finally) was.
The driver doesn't seem to be in-tree... Kim, what do(es) the external
driver(s) look like? Do they use OF at all yet?
> > + ranges = <0 0xe0100000 0x00100000>;
> > + reg = <0xe0100000 0x480>;
> > + /* filled by u-boot */
> > + brg-frequency = <0>;
> > + bus-frequency = <0>;
>
> This should probably be clock-frequency, not bus-frequency. After
> all, it's a bus node, what other sort of frequency would it be.
Actually, it should probably be dropped altogether.
> > + muram@10000 {
> > + device_type = "muram";
>
> And this device_type needs to go, too.
Yes, replace it with compatible = "fsl,cpm-muram".
> > + ranges = <0 0x00010000 0x0000c000>;
> > +
> > + data-only@0 {
> > + reg = <0 0xc000>;
compatible = "fsl,cpm-muram-data".
> > + phy1: ethernet-phy@1 {
> > + reg = <1>;
> > + device_type = "ethernet-phy";
> > + };
>
> These phy nodes have basically no information in them. PHY nodes are
> optional -
If they are truly optional, then several Linux drivers (including ucc_geth,
which this board uses) are broken, as they'll error out if there's no
phy-handle (gianfar is even worse -- it looks like the fsl_soc code will
crash in that case). But what do you propose they do in the absence of a
phy-handle? Hope that probing only finds one phy?
> only include them if they actually have something useful to say (which
> would mean at least a compatible property).
They *do* have useful information -- reg and phandle. The type of phy can
be probed, but which phy corresponds to which ethernet can't.
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/3] 8xx: Analogue & Micro Adder875 board support.
From: Scott Wood @ 2007-12-17 15:15 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071217035706.GA3262@localhost.localdomain>
David Gibson wrote:
> On Wed, Dec 12, 2007 at 04:54:27PM -0600, Scott Wood wrote:
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
> [snip]
>> diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts b/arch/powerpc/boot/dts/adder875-redboot.dts
>> new file mode 100644
>> index 0000000..4d28220
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/adder875-redboot.dts
> [snip]
>> diff --git a/arch/powerpc/boot/dts/adder875-uboot.dts b/arch/powerpc/boot/dts/adder875-uboot.dts
>> new file mode 100644
>> index 0000000..33d198c
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/adder875-uboot.dts
>
> Having two different device trees for the different firmwares is
> pretty yucky, and could be a pain in the bum for synchronization of
> fixes.
Yes, that's why we need some sort of macro/template facility in dtc. :-)
> Can't you have a common tree, and just poke the places that
> are differently configured by the two firmwares from the bootwrapper.
Enh. That can get icky as well, and the bootwrapper isn't necessarily
even used for u-boot, and I'd rather not require it be used just for this.
-Scott
^ permalink raw reply
* [RFC] ehea: kdump support - rework
From: Thomas Klein @ 2007-12-17 15:52 UTC (permalink / raw)
To: Paul Mackerras
Cc: Michael Neuling, Jan-Bernd Themann, netdev, linux-kernel,
linux-ppc, Christoph Raisch, Marcus Eder, Stefan Roscher
This patch adds kdump support using the new PPC crash shutdown hook to the
ehea driver.
The reworked implementation follows the feedback I got. The crash handler
now just iterates over two simple arrays instead of handling linked lists.
Further feedback will be appreciated.
ehea kdump support RFC #1:
http://lkml.org/lkml/2007/12/12/241
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp -X dontdiff linux-2.6.24-rc5/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.24-rc5/drivers/net/ehea/ehea.h 2007-12-11 04:48:43.000000000 +0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2007-12-17 16:18:49.000000000 +0100
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0083"
+#define DRV_VERSION "EHEA_0085"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -386,6 +386,13 @@ struct ehea_port_res {
#define EHEA_MAX_PORTS 16
+
+#define EHEA_NUM_PORTRES_FW_HANDLES 6 /* QP handle, SendCQ handle,
+ RecvCQ handle, EQ handle,
+ SendMR handle, RecvMR handle */
+#define EHEA_NUM_PORT_FW_HANDLES 1 /* EQ handle */
+#define EHEA_NUM_ADAPTER_FW_HANDLES 2 /* MR handle, NEQ handle */
+
struct ehea_adapter {
u64 handle;
struct of_device *ofdev;
@@ -405,6 +412,31 @@ struct ehea_mc_list {
u64 macaddr;
};
+/* kdump support */
+struct ehea_fw_handle_entry {
+ u64 adh; /* Adapter Handle */
+ u64 fwh; /* Firmware Handle */
+};
+
+struct ehea_fw_handle_array {
+ struct ehea_fw_handle_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
+struct ehea_bcmc_reg_entry {
+ u64 adh; /* Adapter Handle */
+ u32 port_id; /* Logical Port Id */
+ u8 reg_type; /* Registration Type */
+ u64 macaddr;
+};
+
+struct ehea_bcmc_reg_array {
+ struct ehea_bcmc_reg_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
#define EHEA_PHY_LINK_UP 1
diff -Nurp -X dontdiff linux-2.6.24-rc5/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.24-rc5/drivers/net/ehea/ehea_main.c 2007-12-11 04:48:43.000000000 +0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-12-17 16:18:49.000000000 +0100
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <asm/kexec.h>
#include <net/ip.h>
@@ -98,8 +99,10 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
-
struct semaphore dlpar_mem_lock;
+struct ehea_fw_handle_array ehea_fw_handles;
+struct ehea_bcmc_reg_array ehea_bcmc_regs;
+
static int __devinit ehea_probe_adapter(struct of_device *dev,
const struct of_device_id *id);
@@ -131,6 +134,160 @@ void ehea_dump(void *adr, int len, char
}
}
+static void ehea_update_firmware_handles(void)
+{
+ struct ehea_fw_handle_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ int num_adapters = 0;
+ int num_ports = 0;
+ int num_portres = 0;
+ int i = 0;
+ int num_fw_handles, k, l;
+
+ /* Determine number of handles */
+ list_for_each_entry(adapter, &adapter_list, list) {
+ num_adapters++;
+
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_ports++;
+ num_portres += port->num_def_qps + port->num_add_tx_qps;
+ }
+ }
+
+ num_fw_handles = num_adapters * EHEA_NUM_ADAPTER_FW_HANDLES +
+ num_ports * EHEA_NUM_PORT_FW_HANDLES +
+ num_portres * EHEA_NUM_PORTRES_FW_HANDLES;
+
+ if (num_fw_handles) {
+ arr = kzalloc(num_fw_handles * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ for (l = 0;
+ l < port->num_def_qps + port->num_add_tx_qps;
+ l++) {
+ struct ehea_port_res *pr = &port->port_res[l];
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->qp->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->eq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_mr.handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_mr.handle;
+ }
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = port->qp_eq->fw_handle;
+ }
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->neq->fw_handle;
+
+ if (adapter->mr.handle) {
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->mr.handle;
+ }
+ }
+
+out_update:
+ kfree(ehea_fw_handles.arr);
+ ehea_fw_handles.arr = arr;
+ ehea_fw_handles.num_entries = i;
+}
+
+static void ehea_update_bcmc_registrations(void)
+{
+ struct ehea_bcmc_reg_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ struct ehea_mc_list *mc_entry;
+ int num_registrations = 0;
+ int i = 0;
+ int k;
+
+ /* Determine number of registrations */
+ list_for_each_entry(adapter, &adapter_list, list)
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_registrations += 2; /* Broadcast registrations */
+
+ list_for_each_entry(mc_entry, &port->mc_list->list,list)
+ num_registrations += 2;
+ }
+
+ if (num_registrations) {
+ arr = kzalloc(num_registrations * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = port->mac_addr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = port->mac_addr;
+
+ list_for_each_entry(mc_entry,
+ &port->mc_list->list, list) {
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = mc_entry->macaddr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = mc_entry->macaddr;
+ }
+ }
+ }
+
+out_update:
+ kfree(ehea_bcmc_regs.arr);
+ ehea_bcmc_regs.arr = arr;
+ ehea_bcmc_regs.num_entries = i;
+}
+
static struct net_device_stats *ehea_get_stats(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
@@ -1595,19 +1752,25 @@ static int ehea_set_mac_addr(struct net_
memcpy(dev->dev_addr, mac_addr->sa_data, dev->addr_len);
+ down(&ehea_bcmc_regs.lock);
+
/* Deregister old MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
port->mac_addr = cb0->port_mac_addr << 16;
/* Register new MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
ret = 0;
+
+out_upregs:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
out_free:
kfree(cb0);
out:
@@ -1769,9 +1932,11 @@ static void ehea_set_multicast_list(stru
}
ehea_promiscuous(dev, 0);
+ down(&ehea_bcmc_regs.lock);
+
if (dev->flags & IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
- return;
+ goto out;
}
ehea_allmulti(dev, 0);
@@ -1798,6 +1963,8 @@ static void ehea_set_multicast_list(stru
}
}
out:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
return;
}
@@ -2280,6 +2447,8 @@ static int ehea_up(struct net_device *de
if (port->state == EHEA_PORT_UP)
return 0;
+ down(&ehea_fw_handles.lock);
+
ret = ehea_port_res_setup(port, port->num_def_qps,
port->num_add_tx_qps);
if (ret) {
@@ -2316,8 +2485,17 @@ static int ehea_up(struct net_device *de
}
}
- ret = 0;
+ down(&ehea_bcmc_regs.lock);
+
+ ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
+ if (ret) {
+ ret = -EIO;
+ goto out_free_irqs;
+ }
+
port->state = EHEA_PORT_UP;
+
+ ret = 0;
goto out;
out_free_irqs:
@@ -2329,6 +2507,12 @@ out:
if (ret)
ehea_info("Failed starting %s. ret=%i", dev->name, ret);
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2377,16 +2561,27 @@ static int ehea_down(struct net_device *
if (port->state == EHEA_PORT_DOWN)
return 0;
+ down(&ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
+ ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
+
ehea_free_interrupts(dev);
+ down(&ehea_fw_handles.lock);
+
port->state = EHEA_PORT_DOWN;
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
ret = ehea_clean_all_portres(port);
if (ret)
ehea_info("Failed freeing resources for %s. ret=%i",
dev->name, ret);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2952,19 +3147,12 @@ struct ehea_port *ehea_setup_single_port
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
INIT_WORK(&port->reset_task, ehea_reset_port);
-
- ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
- if (ret) {
- ret = -EIO;
- goto out_unreg_port;
- }
-
ehea_set_ethtool_ops(dev);
ret = register_netdev(dev);
if (ret) {
ehea_error("register_netdev failed. ret=%d", ret);
- goto out_dereg_bc;
+ goto out_unreg_port;
}
port->lro_max_aggr = lro_max_aggr;
@@ -2981,9 +3169,6 @@ struct ehea_port *ehea_setup_single_port
return port;
-out_dereg_bc:
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
-
out_unreg_port:
ehea_unregister_port(port);
@@ -3003,7 +3188,6 @@ static void ehea_shutdown_single_port(st
{
unregister_netdev(port->netdev);
ehea_unregister_port(port);
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
kfree(port->mc_list);
free_netdev(port->netdev);
port->adapter->active_ports--;
@@ -3046,7 +3230,6 @@ static int ehea_setup_ports(struct ehea_
i++;
};
-
return 0;
}
@@ -3191,6 +3374,7 @@ static int __devinit ehea_probe_adapter(
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
+ down(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3271,7 +3455,10 @@ out_kill_eq:
out_free_ad:
kfree(adapter);
+
out:
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
return ret;
}
@@ -3290,18 +3477,41 @@ static int __devexit ehea_remove(struct
flush_scheduled_work();
+ down(&ehea_fw_handles.lock);
+
ibmebus_free_irq(adapter->neq->attr.ist1, adapter);
tasklet_kill(&adapter->neq_tasklet);
ehea_destroy_eq(adapter->neq);
ehea_remove_adapter_mr(adapter);
list_del(&adapter->list);
-
kfree(adapter);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return 0;
}
+void ehea_crash_handler(void)
+{
+ int i;
+
+ if (ehea_fw_handles.arr)
+ for (i = 0; i < ehea_fw_handles.num_entries; i++)
+ ehea_h_free_resource(ehea_fw_handles.arr[i].adh,
+ ehea_fw_handles.arr[i].fwh,
+ FORCE_FREE);
+
+ if (ehea_bcmc_regs.arr)
+ for (i = 0; i < ehea_bcmc_regs.num_entries; i++)
+ ehea_h_reg_dereg_bcmc(ehea_bcmc_regs.arr[i].adh,
+ ehea_bcmc_regs.arr[i].port_id,
+ ehea_bcmc_regs.arr[i].reg_type,
+ ehea_bcmc_regs.arr[i].macaddr,
+ 0, H_DEREG_BCMC);
+}
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3362,7 +3572,12 @@ int __init ehea_module_init(void)
INIT_WORK(&ehea_rereg_mr_task, ehea_rereg_mrs);
+ memset(&ehea_fw_handles, 0, sizeof(ehea_fw_handles));
+ memset(&ehea_bcmc_regs, 0, sizeof(ehea_bcmc_regs));
+
sema_init(&dlpar_mem_lock, 1);
+ sema_init(&ehea_fw_handles.lock, 1);
+ sema_init(&ehea_bcmc_regs.lock, 1);
ret = check_module_parm();
if (ret)
@@ -3373,6 +3588,9 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ret = crash_shutdown_register(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed registering crash handler");
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3386,6 +3604,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ crash_shutdown_unregister(&ehea_crash_handler);
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,10 +3615,17 @@ out:
static void __exit ehea_module_exit(void)
{
+ int ret;
+
flush_scheduled_work();
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ret = crash_shutdown_unregister(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed unregistering crash handler");
+ kfree(ehea_fw_handles.arr);
+ kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
}
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Grant Likely @ 2007-12-17 15:27 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, simekm2
In-Reply-To: <87d4t5a5zj.fsf@macbook.be.48ers.dk>
On 12/17/07, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
>
> Hi,
>
> >> > 3) Uartlite requires a port-number property for the console to work.
> >>
> >> Why? In general we try to avoid magical sequence numbers - cell-index
> >> should *only* be used when it's needed to index or program some shared
> >> register.
>
> Grant> Aliases is probably the correct construct for this.
> Grant> port-number was a bad idea and I never should have gone that
> Grant> direction.
>
> Perhaps it would make more sense to add a _find_match_or_unused(port)
> like 8250.c and make the initialization order define the index instead
> of explicitly setting it?
aliases I think is the better approach as it is an already established
convention.
enumeration based on init order is fragile and there is no guarantee
that order will not change in the future.
>
> Now we're at it - Why isn't the uartlite of glue handled by of_serial.c?
The of_serial.c glue is IMHO too complex for the uartlite case. I saw
no advantage provided by the added complexity. (ulite_of_probe() is
all of 12 lines of code).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: USB configuration
From: Scott Wood @ 2007-12-17 15:21 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <14370084.post@talk.nabble.com>
Misbah khan wrote:
> I have configured for mass storage device still i am not getting the debug
> msg that the kernel has detected the pen drive (after i connect the pen
> drive ).
>
> " Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> "
Did you get any output indicating that the USB controller was found and
initialized? This *is* a PCI-based OHCI controller you're trying to
use, and not the CPM USB, right? Do other PCI devices work?
-Scott
^ permalink raw reply
* Re: [PATCH v2 2/3] mpc82xx: Embedded Planet EP8248E support
From: Scott Wood @ 2007-12-17 15:18 UTC (permalink / raw)
To: Scott Wood, galak, linuxppc-dev
In-Reply-To: <20071217035912.GB3262@localhost.localdomain>
David Gibson wrote:
> As I think I said about another tree, this mdio-under-bcsr arrangement
> is pretty strange. What's going on here.
As I answered then, it's just the way the hardware is. I didn't design
it. :-P
>> + soc@f0000000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>
> Ditch the device_type.
No, it's used by the bootwrapper. I'll get rid of it if you want to
write a find_node_by_compatible() function. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Grant Likely @ 2007-12-17 15:19 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, David Gibson, simekm2
In-Reply-To: <20071213234151.D0B3DE80061@mail20-sin.bigfish.com>
On 12/13/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> This now better describes what the UBoot device tree generator actually does. In particular:
>
> 1) Nodes have a label derived from the device name, and a node name
> derived from the device type.
> 2) Usage of compound nodes (representing more than one device in the same IP) which actually works. This requires having a valid compatible node, and all the other things that a bus normally has. I've chosen 'xlnx,compound' as the bus name to describe these compound nodes.
> 3) Uartlite requires a port-number property for the console to work.
>
> In addition, I've clarified some of the language relating to how mhs
> nodes should be represent in the device tree.
Thanks for the updates. Comments below.
> ---
> Documentation/powerpc/booting-without-of.txt | 61 +++++++++++++++-----------
> 1 files changed, 36 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..5e2b85a 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2276,7 +2276,7 @@ platforms are moved over to use the flattened-device-tree model.
> properties of the device node. In general, device nodes for IP-cores
> will take the following form:
>
> - (name)@(base-address) {
> + (name): (ip-core-name)@(base-address) {
(name): (generic-name)@(base-address) {
> compatible = "xlnx,(ip-core-name)-(HW_VER)"
> [, (list of compatible devices), ...];
> reg = <(baseaddr) (size)>;
> @@ -2294,9 +2294,9 @@ platforms are moved over to use the flattened-device-tree model.
> dropped from the parameter name, the name is converted
> to lowercase and all underscore '_' characters are
> converted to dashes '-'.
> - (baseaddr): the C_BASEADDR parameter.
> + (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
> (HW_VER): from the HW_VER parameter.
> - (size): equals C_HIGHADDR - C_BASEADDR + 1
> + (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
Ah, yes. Good clarification.
>
> Typically, the compatible list will include the exact IP core version
> followed by an older IP core version which implements the same
> @@ -2326,12 +2326,13 @@ platforms are moved over to use the flattened-device-tree model.
>
> becomes the following device tree node:
>
> - opb-uartlite-0@ec100000 {
> + opb_uartlite_0: serial@ec100000 {
> device_type = "serial";
> compatible = "xlnx,opb-uartlite-1.00.b";
> reg = <ec100000 10000>;
> - interrupt-parent = <&opb-intc>;
> + interrupt-parent = <&opb_intc_0>;
> interrupts = <1 0>; // got this from the opb_intc parameters
> + port-number = <0>;
> current-speed = <d#115200>; // standard serial device prop
> clock-frequency = <d#50000000>; // standard serial device prop
> xlnx,data-bits = <8>;
> @@ -2339,16 +2340,19 @@ platforms are moved over to use the flattened-device-tree model.
> xlnx,use-parity = <0>;
> };
>
> - Some IP cores actually implement 2 or more logical devices. In this case,
> - the device should still describe the whole IP core with a single node
> - and add a child node for each logical device. The ranges property can
> - be used to translate from parent IP-core to the registers of each device.
> - (Note: this makes the assumption that both logical devices have the same
> - bus binding. If this is not true, then separate nodes should be used for
> - each logical device). The 'cell-index' property can be used to enumerate
> - logical devices within an IP core. For example, the following is the
> - system.mhs entry for the dual ps2 controller found on the ml403 reference
> - design.
> + Some IP cores actually implement 2 or more logical devices. In
> + this case, the device should still describe the whole IP core with
> + a single node and add a child node for each logical device. The
> + ranges property can be used to translate from parent IP-core to the
> + registers of each device. In addition, the parent node should be
> + compatible with the bus type 'xlnx,compound', and should contain
> + #address-cells and #size-cells, as with any other bus. (Note: this
> + makes the assumption that both logical devices have the same bus
> + binding. If this is not true, then separate nodes should be used
> + for each logical device). The 'cell-index' property can be used to
> + enumerate logical devices within an IP core. For example, the
> + following is the system.mhs entry for the dual ps2 controller found
> + on the ml403 reference design.
>
> BEGIN opb_ps2_dual_ref
> PARAMETER INSTANCE = opb_ps2_dual_ref_0
> @@ -2370,21 +2374,24 @@ platforms are moved over to use the flattened-device-tree model.
>
> It would result in the following device tree nodes:
>
> - opb_ps2_dual_ref_0@a9000000 {
> + opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "xlnx,compound";
> ranges = <0 a9000000 2000>;
> // If this device had extra parameters, then they would
> // go here.
> - ps2@0 {
> + opb-ps2-dual-ref@0 {
According to the generic names recommendation, this should be either
"keyboard@0" or "mouse@0", but of course the two interfaces are
identical and EDK doesn't have any information about how they are
used. Perhaps the node name should be: "ps2@0". David, thoughts?
> compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
> reg = <0 40>;
> - interrupt-parent = <&opb-intc>;
> + interrupt-parent = <&opb_intc_0>;
> interrupts = <3 0>;
> cell-index = <0>;
> };
> - ps2@1000 {
> + opb-ps2-dual-ref@1000 {
> compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
> reg = <1000 40>;
> - interrupt-parent = <&opb-intc>;
> + interrupt-parent = <&opb_intc_0>;
> interrupts = <3 0>;
> cell-index = <0>;
> };
> @@ -2447,17 +2454,18 @@ platforms are moved over to use the flattened-device-tree model.
>
> Gives this device tree (some properties removed for clarity):
>
> - plb-v34-0 {
> + plb_v34 {
Steve, when I wrote this I was lazy and I didn't add the bus address.
However, if we don't have the base address I think we'll end up with
name collisions (especially in the MPMC case). So, based on generic
names convention, this should probably simply be "plb@<baseaddr>".
> #address-cells = <1>;
> #size-cells = <1>;
> + compatible = "xlnx,plb-v34-1.02.a";
> device_type = "ibm,plb";
> ranges; // 1:1 translation
>
> - plb-bram-if-cntrl-0@ffff0000 {
> + plb_bram_if_cntrl_0: plb-bram-if-cntrl@ffff0000 {
Node name should probably just be "bram@ffff0000" here.
> reg = <ffff0000 10000>;
> }
>
> - opb-v20-0 {
> + opb_v20 {
opb@<baseaddr>
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <20000000 20000000 20000000
> @@ -2465,11 +2473,11 @@ platforms are moved over to use the flattened-device-tree model.
> 80000000 80000000 40000000
> c0000000 c0000000 20000000>;
>
> - opb-uart16550-0@a0000000 {
> + opb_uart16550_0: opb-uart16550@a0000000 {
serial@a0000000
> reg = <a00000000 2000>;
> };
>
> - opb-intc-0@d1000fc0 {
> + opb_intc_0: opb-intc@d1000fc0 {
interrupt-controller@d1000fc0
> reg = <d1000fc0 20>;
> };
> };
> @@ -2513,6 +2521,9 @@ platforms are moved over to use the flattened-device-tree model.
>
> Requred properties:
> - current-speed : Baud rate of uartlite
> + Optional properties:
> + - port-number : unique ordinal index of the device. This
> + property is required for a console on uartlite.
And has already been discussed, drop the port-number property. I'll
rework the uartlite driver to use aliases instead.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Various DTC Patches Applied
From: Jon Loeliger @ 2007-12-17 13:53 UTC (permalink / raw)
To: linuxppc-dev
Folks,
Tese patches have all been applied to the DTC repo and pushed out:
* [master] dtc: Don't build tests as part of "all"
* [master^] libfdt: Add more documentation (patch the seventh)
* [master~2] libfdt: Add more documentation (patch the sixth)
* [master~3] dtc: Fix silly typo in dtc-checkfails.sh
* [master~4] dtc: Allow gcc format warnings for check_msg()
* [master~5] dtc: Make dtc-checfails.sh script catch deaths-by-signal
* [master~6] dtc: Reinstate full old-style reference-to-path for v0 dts files
* [master~7] dtc: Convert check for obsolete /chosen property
* [master~8] dtc: Convert #address-cells and #size-cells related checks
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add aliases node to 4xx dts files
From: Jon Loeliger @ 2007-12-17 13:46 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071216223342.GD26307@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> On Sun, Dec 16, 2007 at 07:10:02PM +0100, Segher Boessenkool wrote:
> >
> > Hopefully some version that stores path strings in the properties
> > in /aliases, and not phandles.
Yes.
> > Or does that current version of DTC
> > do that correctly already, and just has an inconvenient source
> > syntax?
Feh. If there is an "inconvenient source syntax", or any other
annoying irregularity, please, by all means, suggest improvements
and offer patches!
> I don't think anyone's actually gone and generated phandles in
> /aliases, although it was suggested early on. The syntax is
> foo = < &bar >;
> to generate a phandle and
> foo = &bar;
> to generate a path.
>
> I was a bit worried about confusion between these forms, but at least
> Kumar and myself came up with this syntax independently, which
> suggests it's not too surprising to most people, and no-one had any
> other suggestions.
To be a bit more complete, Kumar and I discussed this as well.
jdl
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC] Xilinx: Update booting-without-of.
From: Peter Korsgaard @ 2007-12-17 11:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, simekm2
In-Reply-To: <fa686aa40712162030q6f0e6d87j5e6e5379cbd0d54e@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> > 3) Uartlite requires a port-number property for the console to work.
>>
>> Why? In general we try to avoid magical sequence numbers - cell-index
>> should *only* be used when it's needed to index or program some shared
>> register.
Grant> Aliases is probably the correct construct for this.
Grant> port-number was a bad idea and I never should have gone that
Grant> direction.
Perhaps it would make more sense to add a _find_match_or_unused(port)
like 8250.c and make the initialization order define the index instead
of explicitly setting it?
Now we're at it - Why isn't the uartlite of glue handled by of_serial.c?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH] [NET][POWERPC] ucc_geth: really fix section mismatch
From: Anton Vorontsov @ 2007-12-17 11:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Li Yang, linuxppc-dev
Commit ed7e63a51d46e835422d89c687b8a3e419a4212a has tried to fix
section mismatch:
WARNING: vmlinux.o(.init.text+0x17278): Section mismatch: reference to
.exit.text:uec_mdio_exit (between 'ucc_geth_init' and 'uec_mdio_init')
But that mismatch still happens.
This patch actually fixing section mismatch by removing __exit from
the header file.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth_mii.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth_mii.h b/drivers/net/ucc_geth_mii.h
index d834370..1e45b20 100644
--- a/drivers/net/ucc_geth_mii.h
+++ b/drivers/net/ucc_geth_mii.h
@@ -96,5 +96,5 @@ enum enet_tbi_mii_reg {
int uec_mdio_read(struct mii_bus *bus, int mii_id, int regnum);
int uec_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
int __init uec_mdio_init(void);
-void __exit uec_mdio_exit(void);
+void uec_mdio_exit(void);
#endif /* __UEC_MII_H */
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Implement pci_set_dma_mask() in terms of the dma_ops
From: Christoph Hellwig @ 2007-12-17 10:02 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <a3b033f72681dd15badb0218b505512ce1c3a9c8.1197873226.git.michael@ellerman.id.au>
On Mon, Dec 17, 2007 at 05:35:53PM +1100, Michael Ellerman wrote:
> To save adding a hook to the dma mapping ops, pci-set_consistent_dma_mask()
> simply calls the dma_set_mask() hook and then copies the new mask into
> dev.coherenet_dma_mask.
How is this supposed to work? There are various devices around that
want different mask for coherent vs streaming dma mappings, and we need
to tell the iommu that we're setting it for either the former or the
latter.
^ permalink raw reply
* Re: [PATCH] OProfile: remove dependency on spufs module
From: Jeremy Kerr @ 2007-12-17 9:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, David Woodhouse, Bob Nelson
In-Reply-To: <200712141527.31893.arnd@arndb.de>
> Jeremy, please ack the spufs changes if you are ok with the patch.
Yep, fine by me.
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Cheers,
Jeremy
^ permalink raw reply
* RE: USB configuration
From: Pedro Luis D. L. @ 2007-12-17 8:29 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14370084.post@talk.nabble.com>
MIsbah wrote:
> I have configured for mass storage device still i am not getting the debu=
g
> msg that the kernel has detected the pen drive (after i connect the pen
> drive ).
>=20
> " Initializing USB Mass Storage driver...
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.=20
> "
As long as you enabled the USB Mass storage and all usb-related modules, if=
you don't get any output, maybe the usb hardware is not working properly. =
I don't work with that board, so I feel like I can not help further more, s=
orry.
Hope you find a solution!
Regards,
Pedro L.
> ----misbah=20
>=20
>=20
> Pedro Luis D. L. wrote:
>>=20
>>=20
>>> From: misbah_khan@engineer.com
>>> To: linuxppc-embedded@ozlabs.org
>>> Subject: RE: USB configuration
>>>=20
>>>=20
>>> I have inserted a USB card reader, and the following dmesg it shows ...=
..
>>>=20
>>> -----------------------------------------------------------------------=
--------
>>> mpc8272ads: Init
>>> PCI: Probing PCI hardware
>>> PCI: Cannot allocate resource region 0 of device 0000:00:00.0
>>> PCI: Cannot allocate resource region 1 of device 0000:00:00.0
>>> SCSI subsystem initialized
>>> Linux Kernel Card Services
>>> options: [pci] [cardbus]
>>> usbcore: registered new driver usbfs
>>> usbcore: registered new driver hub
>>> Serial: CPM driver $Revision: 0.01 $
>>> ttyCPM0 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
>>> ttyCPM1 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART
>>> io scheduler noop registered
>>> io scheduler anticipatory registered
>>> io scheduler deadline registered
>>> io scheduler cfq registered
>>> loop: loaded (max 8 devices)
>>> fs_enet.c:v1.0 (Aug 8, 2005)
>>> fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
>>> fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
>>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>>> ide: Assuming 33MHz system bus speed for PIO modes; override with
>>> idebus=3Dxx
>>> st: Version 20041025, fixed bufsize 32768, s/g segs 256
>>> osst :I: Tape driver with OnStream support version 0.99.1
>>> osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $
>>> ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI=
)
>>> ohci_hcd: block sizes: ed 64 td 64
>>> drivers/usb/serial/usb-serial.c: USB Serial support registered for
>>> Generic
>>> usbcore: registered new driver usbserial_generic
>>> usbcore: registered new driver usbserial
>>> drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
>>> NET: Registered protocol family 2
>>> IP: routing cache hash table of 512 buckets, 4Kbytes
>>> TCP: Hash tables configured (established 4096 bind 8192)
>>> NET: Registered protocol family 1
>>> NET: Registered protocol family 17
>>> IP-Config: Complete:
>>> device=3Deth1, addr=3D192.168.33.136, mask=3D255.255.248.0,
>>> gw=3D192.168.32.47,
>>> host=3Dcashel, domain=3D, nis-domain=3D(none),
>>> bootserver=3D192.168.33.96, rootserver=3D192.168.33.96, rootpath=
=3D
>>> Looking up port of RPC 100003/2 on 192.168.33.96
>>> Looking up port of RPC 100005/1 on 192.168.33.96
>>> VFS: Mounted root (nfs filesystem).
>>> Freeing unused kernel memory: 104k init
>>> -----------------------------------------------------------------------=
---------------
>>>=20
>>=20
>> It looks like it is well configured, because the usbfs and hub are loade=
d.
>> You could check in your kernel configuration that you enabled USB Mass
>> storage driver and attached a pen drive as I suggested before.
>> Another possibility is to insert a card in the USB card reader. Then you
>> should be able to see with dmesg if it is recognized.
>>=20
>> Pedro.
>>=20
>>> This doesent gives me the clear explaination of whether USB is working
>>> properly....
>>>=20
>>> I would appreciate if you could share with me the basic steps to be
>>> followed
>>> to confirm that the USB support that i had configured is being tested i=
n
>>> all
>>> aspects.
>>>=20
>>> Misbah
>>>=20
>>> Pedro Luis D. L. wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> Date: Thu, 6 Dec 2007 05:27:14 -0800
>>>>> From: misbah_khan@engineer.com
>>>>> To: linuxppc-embedded@ozlabs.org
>>>>> Subject: USB configuration
>>>>>=20
>>>>>=20
>>>>> HI all ...
>>>>=20
>>>> Hi,
>>>>=20
>>>>> I have configured the Montavista Kernel for USB support and for
>>>>> PPC8272-ADS
>>>>> board I need to know that how could i test that my USB is working ???=
?
>>>>>=20
>>>>=20
>>>> Try to attach an USB device, like a pendrive, to an USB port. Then
>>>> type:=20
>>>> dmesg | tail
>>>>=20
>>>> If the USB support is working properly, you should see some output
>>>> saying
>>>> which device have you attached and where is it mapped.
>>>> If you plug a memory stick, you can try to mount it and check that the
>>>> filesystem is correct.
>>>>=20
>>>> Pedro.
>>>>=20
>>>>> Its creating the directory :- /proc/bus/usb/ but doesent contain any
>>>>> file
>>>>> under it ????
>>>>>=20
>>>>>=20
>>>>> its also creating the directory :- /sys/bus/usb/ but doesent contai=
n
>>>>> any
>>>>> file under it ????
>>>>>=20
>>>>>=20
>>>>> Please let me know the procedure to test whether my USB configuration
>>>>> is
>>>>> all
>>>>> right ????
>>>>>=20
>>>>> Thank u=20
>>>>> Misbah <><
>>>>> --=20
>>>>> View this message in context:
>>>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14192347
>>>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>>>=20
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>=20
>>>> _________________________________________________________________
>>>> Tecnolog=EDa, moda, motor, viajes,=85suscr=EDbete a nuestros boletines=
para
>>>> estar a la =FAltima
>>>> http://newsletters.msn.com/hm/maintenanceeses.asp?L=3DES&C=3DES&P=3DWC=
Maintenance&Brand=3DWL&RU=3Dhttp%3a%2f%2fmail.live.com
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>=20
>>>>=20
>>>=20
>>> --=20
>>> View this message in context:
>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14206951
>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>=20
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>=20
>> _________________________________________________________________
>> MSN Video.=20
>> http://video.msn.com/?mkt=3Des-es
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>=20
>>=20
>=20
> --=20
> View this message in context: http://www.nabble.com/USB-configuration-tp1=
4192347p14370084.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
MSN Video.=20
http://video.msn.com/?mkt=3Des-es=
^ permalink raw reply
* [PATCH] Implement pci_set_dma_mask() in terms of the dma_ops
From: Michael Ellerman @ 2007-12-17 6:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Powerpc currently doesn't implement pci_set_dma_mask(), which means drivers
calling it will get the generic version in drivers/pci/pci.c.
The Powerpc dma mapping ops include a dma_set_mask() hook, which luckily is
not implemented by anyone - so there is no bug in the fact that the hook
is currently never called.
However in future we'll add implementation(s) of dma_set_mask(), and so we
need pci_set_dma_mask() to call the hook.
To save adding a hook to the dma mapping ops, pci-set_consistent_dma_mask()
simply calls the dma_set_mask() hook and then copies the new mask into
dev.coherenet_dma_mask.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/pci_64.c | 16 ++++++++++++++++
include/asm-powerpc/dma-mapping.h | 3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index bf06926..f5c4628 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -69,6 +69,22 @@ struct dma_mapping_ops *get_pci_dma_ops(void)
}
EXPORT_SYMBOL(get_pci_dma_ops);
+
+int pci_set_dma_mask(struct pci_dev *dev, u64 mask)
+{
+ return dma_set_mask(&dev->dev, mask);
+}
+
+int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask)
+{
+ int rc;
+
+ rc = dma_set_mask(&dev->dev, mask);
+ dev->dev.coherent_dma_mask = dev->dma_mask;
+
+ return rc;
+}
+
static void fixup_broken_pcnet32(struct pci_dev* dev)
{
if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index ff52013..e974876 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -87,6 +87,9 @@ static inline int dma_supported(struct device *dev, u64 mask)
return dma_ops->dma_supported(dev, mask);
}
+/* We have our own implementation of pci_set_dma_mask() */
+#define HAVE_ARCH_PCI_SET_DMA_MASK
+
static inline int dma_set_mask(struct device *dev, u64 dma_mask)
{
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* RE: Device Tree updates for xilinx.
From: Stephen Neuendorffer @ 2007-12-17 6:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071217052101.GC3477@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
Thanks, I've updated the generator to reflect this.
Steve
-----Original Message-----
From: David Gibson [mailto:david@gibson.dropbear.id.au]
Sent: Sun 12/16/2007 9:21 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Michal Simek; git
Subject: Re: Device Tree updates for xilinx.
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
>
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference? For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version. So for the
> microblaze, I'd prefer something like:
>
> xlnx,microblaze-6.00.b
Sounds reasonable.
> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.
Well, we could list both forms, but PowerPC,405 should be included
since it's an established name. There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.
With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s). In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files. So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.
In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.
--
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
[-- Attachment #2: Type: text/html, Size: 3105 bytes --]
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-12-17 6:00 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some bugfixes and defconfig updates for powerpc.
Thanks,
Paul.
arch/powerpc/configs/mpc8272_ads_defconfig | 6 +++---
arch/powerpc/configs/pq2fads_defconfig | 6 +++---
arch/powerpc/configs/ps3_defconfig | 2 +-
arch/powerpc/kernel/ppc_ksyms.c | 12 ------------
arch/powerpc/math-emu/op-2.h | 3 ++-
arch/powerpc/platforms/iseries/lpevents.c | 17 +++++++++++++++--
arch/powerpc/platforms/ps3/Kconfig | 2 +-
arch/powerpc/sysdev/cpm2_common.c | 3 +--
drivers/net/fs_enet/mac-scc.c | 2 +-
include/asm-powerpc/commproc.h | 3 ---
10 files changed, 27 insertions(+), 29 deletions(-)
Jochen Friedrich (2):
[POWERPC] Fix typo #ifdef -> #ifndef
[POWERPC] Kill non-existent symbols from ksyms and commproc.h
Liu Yu (1):
[POWERPC] Fix rounding bug in emulation for double float operating
Michael Ellerman (1):
[POWERPC] Make PS3_SYS_MANAGER default y, not m
Scott Wood (2):
[POWRPC] CPM2: Eliminate section mismatch warning in cpm2_reset().
[POWERPC] 82xx: mpc8272ads, pq2fads: Update defconfig with CONFIG_FS_ENET_MDIO_FCC
Stephen Rothwell (1):
[POWERPC] iSeries: don't printk with HV spinlock held
^ permalink raw reply
* RE: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Aggrwal Poonam @ 2007-12-17 5:54 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Barkowski Michael, netdev, Gala Kumar, linux-kernel, rubini,
linuxppc-dev, Kalra Ashish, Cutler Richard
In-Reply-To: <20071211111855.dc5276a2.sfr@canb.auug.org.au>
Thanks Stephen for your comments.
I have gone through them.
Shall incorporate them and repost the patch.
Sorry for late reply as I was on leave for the last week.=20
With Regards
Poonam=20
=20
=20
-----Original Message-----
From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]=20
Sent: Tuesday, December 11, 2007 5:49 AM
To: Aggrwal Poonam
Cc: rubini@vision.unipv.it; linux-kernel@vger.kernel.org;
netdev@vger.kernel.org; Gala Kumar; linuxppc-dev@ozlabs.org; Barkowski
Michael; Cutler Richard; Kalra Ashish
Subject: Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for
MPC8323ERDB.Also includes related QE changes.
On Mon, 10 Dec 2007 17:39:22 +0530 (IST) Poonam_Aggrwal-b10812
<b10812@freescale.com> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -149,22 +149,116 @@ EXPORT_SYMBOL(qe_issue_cmd);
> */
> static unsigned int brg_clk =3D 0;
> =20
> -unsigned int get_brg_clk(void)
> +u32 get_brg_clk(enum qe_clock brgclk, enum qe_clock *brg_source)
> {
> - struct device_node *qe;
> - if (brg_clk)
> - return brg_clk;
> + struct device_node *qe, *brg, *clocks;
> + enum qe_clock brg_src;
> + u32 brg_input_freq =3D 0;
> + u32 brg_num;
> + const unsigned int *prop;
> =20
> - qe =3D of_find_node_by_type(NULL, "qe");
> - if (qe) {
> + *brg_source =3D 0;
> +
> + brg_num =3D brgclk - QE_BRG1;
> + brg =3D of_find_compatible_node(NULL, NULL, "fsl,cpm-brg");
> + if (brg) {
> unsigned int size;
> - const u32 *prop =3D of_get_property(qe, "brg-frequency",
&size);
> - brg_clk =3D *prop;
> - of_node_put(qe);
> - };
> + prop =3D of_get_property(brg,
> + "fsl,brg-sources", &size);
> +
> + brg_src =3D *(prop + brg_num);
You should probably sanity check that prop is not NULL and points to
something large enough.
You don't use brg after here, so the "of_node_put(brg)" could go here to
save putting it in multiple places later. Also, currently there are
paths through the following code that do not do the of_node_put(brg).
> + if (brg_src =3D=3D 0) {
> + *brg_source =3D 0;
> + if (brg_clk > 0) {
> + of_node_put(brg);
> + return brg_clk;
> + }
> + qe =3D of_find_node_by_type(NULL, "qe");
> + if (qe) {
> + unsigned int size;
> + prop =3D of_get_property
> + (qe, "brg-frequency",
&size);
> + of_node_put(qe);
> + of_node_put(brg);
> + return *prop;
NULL check here (yes, I know that the old code didn't check).
> + }
> + } else {
> + *brg_source =3D brg_src + QE_CLK1 - 1;
> + clocks =3D of_find_compatible_node(NULL, NULL,
> +
"fsl,cpm-clocks");
> + prop =3D of_get_property(clocks,
> + "#clock-cells", &size);
> + /*
> + * clock-cells =3D 1 only supported right now.
> + */
> + if (*prop !=3D 1)
Again check for NULL (and possibly size).
> + return 0;
> + prop =3D of_get_property(clocks,
> + "clock-frequency",
&size);
> +
> + brg_input_freq =3D *(prop+(brg_src - 1));
And again.
> + of_node_put(clocks);
> + of_node_put(brg);
> + return brg_input_freq;
> + }
> + }
> return brg_clk;
> }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: [PATCH 2/2] wrapper: Treat NULL as root node in devp_offset; add devp_offset_find().
From: David Gibson @ 2007-12-17 5:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071211212305.GB3661@loki.buserror.net>
On Tue, Dec 11, 2007 at 03:23:05PM -0600, Scott Wood wrote:
> Many operations, as currently used in the wrapper, assume they can
> pass NULL and have it be treated as the root node. However, libfdt-wrapper
> converts NULL to -1, which is only appropriate when searching for nodes,
> and will cause an error otherwise.
Hrm. AFAICT "many" in this case, means three (being calls to
create_node() in devtree.c, main.c and planetcore.c).
Still I guess this patch is ok for now. I futgure I'd like to shrink
the wrapper down and make the general interface be as close as
possible to the native libfdt interface.
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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
^ permalink raw reply
* Re: [PATCH 2/3] arch/ : Platform changes for UCC TDM driver for MPC8323ERDB.Also includes related QE changes.
From: Poonam Aggrwal @ 2007-12-17 5:40 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Poonam_Aggrwal-b10812
In-Reply-To: <475D89E1.4040107@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
Thanx Tabi for your comments.
Sorry I was on leave for the last week, so could not reply in time.
Shall make the changes you suggested and repost the patch.
Regards
Poonam
On 12/11/07, Timur Tabi <timur@freescale.com> wrote:
>
> Poonam_Aggrwal-b10812 wrote:
>
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (qe) {
> > + unsigned int size;
> > + prop = of_get_property
> > + (qe, "brg-frequency",
> &size);
> > + of_node_put(qe);
> > + of_node_put(brg);
> > + return *prop;
> > + }
>
> Only very recent versions of U-Boot set the brg-frequency property, so you
> need
> to check for situations where "*prop" is 0. If it is, then you need to
> take the
> QE's bus-frequency property and divide it by two. See my ucc_uart driver
> for an
> example.
>
> And PowerPC-specific patches should not be cross-posted to linux-kernel.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 3099 bytes --]
^ permalink raw reply
* dtc: Don't build tests as part of "all"
From: David Gibson @ 2007-12-17 5:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently "make all" for dtc will build (but not run) the testcase
binaries. This is a problem for cross compiles, because building the
tests will attempt to run the dumptrees utility on the host system,
which won't work if it's cross-compiled of course.
Although it would be possible to separately build host binaries,
there's not a lot of value in doing so since we don't have a facility
for cross-executing the testsuite anyway.
Therefore, remove the tests from the "all" target. It will still, of
course, be build as a prerequisite to "make check" which will run the
testsuite.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-12-17 16:34:48.000000000 +1100
+++ dtc/Makefile 2007-12-17 16:34:57.000000000 +1100
@@ -46,7 +46,7 @@ else
DEPTARGETS = $(filter-out $(NODEPTARGETS),$(MAKECMDGOALS))
endif
-all: dtc ftdump libfdt tests
+all: dtc ftdump libfdt
install: all
@$(VECHO) INSTALL
--
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
^ permalink raw reply
* Re: [DTC][PATCH] Fix cross-compile building
From: David Gibson @ 2007-12-17 5:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jon Loeliger, stuarth
In-Reply-To: <A388C2C2-2452-4E70-A5DA-F61B0E3A2B22@kernel.crashing.org>
On Thu, Dec 13, 2007 at 11:57:48PM -0600, Kumar Gala wrote:
>
> On Dec 7, 2007, at 6:36 PM, David Gibson wrote:
>
> > On Fri, Dec 07, 2007 at 12:28:20PM -0600, Kumar Gala wrote:
> >> From: Stuart Hughes <stuarth@freescale.com>
> >>
> >> This patch allows you to build the DTC source without making the
> >> tests directory. This is necessary when cross compiling as the
> >> dumptest (and other) files cannot be run/used on the host system.
> >> To use this use: 'make TESTS='
> >
> > I think this is a silly way of doing this. Instead create a new
> > target which builds everything but the tests.
> >
> > Say,
> >
> > all: cross tests
> >
> > cross: dtc ftdump libfdt
>
> shouldn't we do this the other way around, it seems odd to build the
> tests always or at least as part of the all target.
Hrm. Yeah, I guess so.
The idea was to encourage the tests to be used as much as possible,
but I guess there's not all that much value to building them without
running them.
Patch forthcoming.
--
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
^ permalink raw reply
* RE: USB configuration
From: Misbah khan @ 2007-12-17 5:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BLU106-W35DC430E02A0A1798D8B95CA650@phx.gbl>
I have configured for mass storage device still i am not getting the debug
msg that the kernel has detected the pen drive (after i connect the pen
drive ).
" Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.=20
"
----misbah=20
Pedro Luis D. L. wrote:
>=20
>=20
>> From: misbah_khan@engineer.com
>> To: linuxppc-embedded@ozlabs.org
>> Subject: RE: USB configuration
>>=20
>>=20
>> I have inserted a USB card reader, and the following dmesg it shows ....=
.
>>=20
>> ------------------------------------------------------------------------=
-------
>> mpc8272ads: Init
>> PCI: Probing PCI hardware
>> PCI: Cannot allocate resource region 0 of device 0000:00:00.0
>> PCI: Cannot allocate resource region 1 of device 0000:00:00.0
>> SCSI subsystem initialized
>> Linux Kernel Card Services
>> options: [pci] [cardbus]
>> usbcore: registered new driver usbfs
>> usbcore: registered new driver hub
>> Serial: CPM driver $Revision: 0.01 $
>> ttyCPM0 at MMIO 0xf0011a00 (irq =3D 40) is a CPM UART
>> ttyCPM1 at MMIO 0xf0011a60 (irq =3D 43) is a CPM UART
>> io scheduler noop registered
>> io scheduler anticipatory registered
>> io scheduler deadline registered
>> io scheduler cfq registered
>> loop: loaded (max 8 devices)
>> fs_enet.c:v1.0 (Aug 8, 2005)
>> fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
>> fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>> ide: Assuming 33MHz system bus speed for PIO modes; override with
>> idebus=3Dxx
>> st: Version 20041025, fixed bufsize 32768, s/g segs 256
>> osst :I: Tape driver with OnStream support version 0.99.1
>> osst :I: $Id: osst.c,v 1.70 2003/12/23 14:22:12 wriede Exp $
>> ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
>> ohci_hcd: block sizes: ed 64 td 64
>> drivers/usb/serial/usb-serial.c: USB Serial support registered for
>> Generic
>> usbcore: registered new driver usbserial_generic
>> usbcore: registered new driver usbserial
>> drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
>> NET: Registered protocol family 2
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP: Hash tables configured (established 4096 bind 8192)
>> NET: Registered protocol family 1
>> NET: Registered protocol family 17
>> IP-Config: Complete:
>> device=3Deth1, addr=3D192.168.33.136, mask=3D255.255.248.0,
>> gw=3D192.168.32.47,
>> host=3Dcashel, domain=3D, nis-domain=3D(none),
>> bootserver=3D192.168.33.96, rootserver=3D192.168.33.96, rootpath=3D
>> Looking up port of RPC 100003/2 on 192.168.33.96
>> Looking up port of RPC 100005/1 on 192.168.33.96
>> VFS: Mounted root (nfs filesystem).
>> Freeing unused kernel memory: 104k init
>> ------------------------------------------------------------------------=
--------------
>>=20
>=20
> It looks like it is well configured, because the usbfs and hub are loaded=
.
> You could check in your kernel configuration that you enabled USB Mass
> storage driver and attached a pen drive as I suggested before.
> Another possibility is to insert a card in the USB card reader. Then you
> should be able to see with dmesg if it is recognized.
>=20
> Pedro.
>=20
>> This doesent gives me the clear explaination of whether USB is working
>> properly....
>>=20
>> I would appreciate if you could share with me the basic steps to be
>> followed
>> to confirm that the USB support that i had configured is being tested in
>> all
>> aspects.
>>=20
>> Misbah
>>=20
>> Pedro Luis D. L. wrote:
>>>=20
>>>=20
>>>=20
>>>> Date: Thu, 6 Dec 2007 05:27:14 -0800
>>>> From: misbah_khan@engineer.com
>>>> To: linuxppc-embedded@ozlabs.org
>>>> Subject: USB configuration
>>>>=20
>>>>=20
>>>> HI all ...
>>>=20
>>> Hi,
>>>=20
>>>> I have configured the Montavista Kernel for USB support and for
>>>> PPC8272-ADS
>>>> board I need to know that how could i test that my USB is working ????
>>>>=20
>>>=20
>>> Try to attach an USB device, like a pendrive, to an USB port. Then
>>> type:=20
>>> dmesg | tail
>>>=20
>>> If the USB support is working properly, you should see some output
>>> saying
>>> which device have you attached and where is it mapped.
>>> If you plug a memory stick, you can try to mount it and check that the
>>> filesystem is correct.
>>>=20
>>> Pedro.
>>>=20
>>>> Its creating the directory :- /proc/bus/usb/ but doesent contain any
>>>> file
>>>> under it ????
>>>>=20
>>>>=20
>>>> its also creating the directory :- /sys/bus/usb/ but doesent contain
>>>> any
>>>> file under it ????
>>>>=20
>>>>=20
>>>> Please let me know the procedure to test whether my USB configuration
>>>> is
>>>> all
>>>> right ????
>>>>=20
>>>> Thank u=20
>>>> Misbah <><
>>>> --=20
>>>> View this message in context:
>>>> http://www.nabble.com/USB-configuration-tf4956061.html#a14192347
>>>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>>>=20
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>=20
>>> _________________________________________________________________
>>> Tecnolog=C3=ADa, moda, motor, viajes,=E2=80=A6suscr=C3=ADbete a nuestro=
s boletines para
>>> estar a la =C3=BAltima
>>> http://newsletters.msn.com/hm/maintenanceeses.asp?L=3DES&C=3DES&P=3DWCM=
aintenance&Brand=3DWL&RU=3Dhttp%3a%2f%2fmail.live.com
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>=20
>>>=20
>>=20
>> --=20
>> View this message in context:
>> http://www.nabble.com/USB-configuration-tf4956061.html#a14206951
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>=20
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
> _________________________________________________________________
> MSN Video.=20
> http://video.msn.com/?mkt=3Des-es
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
--=20
View this message in context: http://www.nabble.com/USB-configuration-tp141=
92347p14370084.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Device Tree updates for xilinx.
From: David Gibson @ 2007-12-17 5:21 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, Michal Simek, git
In-Reply-To: <20071217045726.DD1881298046@mail127-sin.bigfish.com>
On Sun, Dec 16, 2007 at 08:58:18PM -0800, Stephen Neuendorffer wrote:
>
> Since there don't seem to be any examples of this in the tree: do
> you have a format preference? For the rest of the compatible lists,
> I'm using something like: xlnx,ipname-version. So for the
> microblaze, I'd prefer something like:
>
> xlnx,microblaze-6.00.b
Sounds reasonable.
> For the powerpc, either ibm,ppc405 or ibm.ppc-405 would seem to be
> more in character than PowerPC,405.
Well, we could list both forms, but PowerPC,405 should be included
since it's an established name. There's some history behind this:
before the generic names convention, the node name was used to encode
the most specific register interface for the device, and "compatible"
was used to describe any other interfaces it was also compatible with.
With the generic names convention, the name came to represent the
general type of device, and "compatible" alone was used to describe
the programming interface(s). In Apple and IBM device trees, while
most things reflect the generic names convention, it seems the cpu
nodes were left using the old convention - which is why that approach
was copied and is currently used in all the dts files. So when
converting nodes to the generic names convention, the old content of
the node name should go into "compatible" verbatim as the first entry.
In practice of course, I don't think anything looks at either the name
or the compatible property for cpu nodes (nor do I think they should)
- they'll just use the PVR.
--
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
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] MPC8360E-RDK: Device tree and board file
From: David Gibson @ 2007-12-17 5:14 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071215162331.GA24999@localhost.localdomain>
On Sat, Dec 15, 2007 at 07:23:31PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 11, 2007 at 12:42:18PM -0600, Kumar Gala wrote:
[snip]
> + soc8360@e0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <0 0xe0000000 0x00100000>;
> + reg = <0xe0000000 0x00000200>;
> + /* filled by u-boot */
> + bus-frequency = <0>;
> +
> + wdt@200 {
> + device_type = "watchdog";
Drop this device_type.
> + compatible = "mpc83xx_wdt";
> + reg = <0x200 0x100>;
> + };
> +
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "i2c";
And this one.
[snip]
> + crypto@30000 {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
This device_type/compatible/model stuff is also crap, although I
suspect it needs to be fixed in the driver, as gianfar (finally) was.
[snip]
> + ipic: pic@700 {
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + reg = <0x700 0x100>;
> + device_type = "ipic";
And drop this device_type.
[snip]
> + qe@e0100000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "qe";
And this one.
This node needs a "compatible" too.
> + model = "QE";
> + ranges = <0 0xe0100000 0x00100000>;
> + reg = <0xe0100000 0x480>;
> + /* filled by u-boot */
> + brg-frequency = <0>;
> + bus-frequency = <0>;
This should probably be clock-frequency, not bus-frequency. After
all, it's a bus node, what other sort of frequency would it be.
> + muram@10000 {
> + device_type = "muram";
And this device_type needs to go, too.
> + ranges = <0 0x00010000 0x0000c000>;
> +
> + data-only@0 {
> + reg = <0 0xc000>;
> + };
> + };
> +
> + spi@4c0 {
> + device_type = "spi";
And this one.
[snip]
> + usb@6c0 {
> + device_type = "usb";
And this one.
> + compatible = "qe_udc";
> + reg = <0x6c0 0x40 0x8b00 0x100>;
> + interrupts = <11>;
> + interrupt-parent = <&qeic>;
> + mode = "slave";
> + };
[snip]
> + mdio@2120 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x2120 0x18>;
> + device_type = "mdio";
And this one.
> + compatible = "ucc_geth_phy";
> +
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
These phy nodes have basically no information in them. PHY nodes are
optional - only include them if they actually have something useful to
say (which would mean at least a compatible property).
[snip]
> + qeic: qeic@80 {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + device_type = "qeic";
Drop this device_type, too.
And this node, too, needs a "compatible" property. Oh, and the node
name should be "interrupt-controller@80" by the generic names
convention.
> + reg = <0x80 0x80>;
> + big-endian;
> + interrupts = <32 8 33 8>;
> + interrupt-parent = <&ipic>;
> + };
> + };
> +};
--
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
^ 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