* Re: [PATCH 7/9] powerpc: add MPC837x RDB platform support
From: Stephen Rothwell @ 2008-02-04 13:41 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, D'Abbraccio, Joe
In-Reply-To: <20080124204711.02ba14f0.kim.phillips@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi Kim,
Again, a bit late but a couple of comments.
On Thu, 24 Jan 2008 20:47:11 -0600 Kim Phillips <kim.phillips@freescale.com> wrote:
>
> +static struct of_device_id mpc837x_ids[] = {
Make this __initdata, please.
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
You need an of_node_put(np) here.
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc8377rdb") ||
> + of_flat_dt_is_compatible(root, "fsl,mpc8378rdb") ||
> + of_flat_dt_is_compatible(root, "fsl,mpc8379rdb");
You need to include asm/prom.h to use the flattened device tree accessors.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] powerpc: fold the mpc8313 platform into the mpc831x platform
From: Stephen Rothwell @ 2008-02-04 13:29 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20080124204551.10cea5fd.kim.phillips@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
Hi Kim,
I know this is late, but just a trivial comment.
On Thu, 24 Jan 2008 20:45:51 -0600 Kim Phillips <kim.phillips@freescale.com> wrote:
>
> --- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
> +++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
> @@ -1,7 +1,7 @@
> /*
> - * arch/powerpc/platforms/83xx/mpc8313_rdb.c
> + * arch/powerpc/platforms/83xx/mpc831x_rdb.c
Just remove the file name from the comment.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* patches "using mii-bitbang on different processor ports"
From: Sergej Stepanov @ 2008-02-04 13:20 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
Hello!
I am about this two patches.
http://www.spinics.net/lists/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
They was not applied. Could they be picked?
Thank you
Sergej.
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-02-04 13:19 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <200802031317.43858.david-b@pacbell.net>
On Sun, Feb 03, 2008 at 01:17:43PM -0800, David Brownell wrote:
> On Sunday 03 February 2008, Anton Vorontsov wrote:
> > This patch implements support for the GPIO LIB API. Two calls
> > unimplemented though: irq_to_gpio and gpio_to_irq.
>
> Also gpio_cansleep().
>
>
> > +Example of two SOC GPIO banks defined as gpio-controller nodes:
> > +
> > + qe_pio_a: gpio-controller@1400 {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank";
> > + reg = <0x1400 0x18>;
> > + gpio-controller;
> > + };
> > +
> > + qe_pio_e: gpio-controller@1460 {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank";
> > + reg = <0x1460 0x18>;
> > + gpio-controller;
> > + };
>
> Let me suggest another example to provide: an I2C GPIO expander
> such as a pcf8574 or pca9354 (both eight bit expanders). The SOC
> case is probably the easiest to cover.
I2C expander will be easy to support via device tree too, something
like:
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 8>;
interrupt-parent = <&ipic>;
dfsrr;
pcf_pio: gpio-controller@27 {
#gpio-cells = <2>;
compatible = "ti,pcf8574";
reg = <0x27>;
gpio-controller;
};
};
Of course, to support this, pcf857x driver needs OF bindings.
> > +#define ARCH_OF_GPIOS_PER_CHIP 32
>
> Well, ARCH_OF_* is clearly not the now-removed ARCH_GPIOS_PER_CHIP,
> but I still suggest moving away from that concept.
Yes, I noticed that ARCH_GPIOS_PER_CHIP is removed from the
gpiolib. But I solely use it to assign gpio_bases to the chips:
static int of_get_gpiochip_base(struct device_node *np)
{
struct device_node *gc = NULL;
int gpiochip_base = 0;
while ((gc = of_find_all_nodes(gc))) {
if (!of_get_property(gc, "gpio-controller", NULL))
continue;
if (gc != np) {
gpiochip_base += ARCH_OF_GPIOS_PER_CHIP;
continue;
}
of_node_put(gc);
if (gpiochip_base >= ARCH_OF_GPIOS_END)
return -ENOSPC;
return gpiochip_base;
}
return -ENOENT;
}
This function walks the device tree and assigns gpio_base 0 to
the first encountered gpio-controller, ARCH_OF_GPIOS_PER_CHIP * N
to the Nth controller...
Technically, I can replace
if (gc != np) {
gpiochip_base += ARCH_OF_GPIOS_PER_CHIP;
continue;
}
With
if (gc != np) {
struct gpio_chip *chip = gc->data;
if (chip)
gpiochip_base += chip->ngpio;
continue;
}
Here we're getting next available GPIO base. But then this code can't
handle gpio chip removal. So, we need smart "dynamic GPIO base
allocator" as described asm-generic/gpio.h, gpio_find_base(ngpios)
that will find free gpio base suitable for ngpios to place. Until
that allocator implemented, we use simple allocator with
OF_GPIOS_PER_CHIP...
> > +static inline int gpio_get_value(unsigned int gpio)
> > +{
> > + return __gpio_get_value(gpio);
> > +}
> > +
> > +static inline void gpio_set_value(unsigned int gpio, int value)
> > +{
> > + __gpio_set_value(gpio, value);
> > +}
>
> static inline int gpio_cansleep(unsigned int gpio)
> {
> return __gpio_cansleep(gpio);
> }
Will fix.
> > +static inline int irq_to_gpio(unsigned int irq)
> > +{
> > + return -ENOSYS;
>
> Minor nit: "-EINVAL" would be better here, since the argument
> is constrained to have been returned from gpio_to_irq(), and
> as you wrote that call there can be no such values.
Will change.
Thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model
From: Stephen Rothwell @ 2008-02-04 13:13 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080124153959.GA23246@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
Hi Anton,
I know this is late, but a couple of comments anyway.
On Thu, 24 Jan 2008 18:39:59 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -65,17 +65,22 @@ static phys_addr_t qebase = -1;
> phys_addr_t get_qe_base(void)
> {
> struct device_node *qe;
> + unsigned int size;
> + const void *prop;
>
> if (qebase != -1)
> return qebase;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> - unsigned int size;
> - const void *prop = of_get_property(qe, "reg", &size);
> - qebase = of_translate_address(qe, prop);
> - of_node_put(qe);
> - };
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!qe) {
> + qe = of_find_node_by_type(NULL, "qe");
> + if (!qe)
> + return qebase;
> + }
> +
> + prop = of_get_property(qe, "reg", &size);
> + qebase = of_translate_address(qe, prop);
If you don't care about the returned length (argument three to
of_get_property), you can just pass NULL (and dispense with "size").
Also, what happens if prop is NULL?
> @@ -153,16 +158,26 @@ static unsigned int brg_clk = 0;
> unsigned int get_brg_clk(void)
> {
> struct device_node *qe;
> + unsigned int size;
> + const u32 *prop;
> +
> if (brg_clk)
> return brg_clk;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> - unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!qe) {
> + qe = of_find_node_by_type(NULL, "qe");
> + if (!qe)
> + return brg_clk;
> + }
> +
> + prop = of_get_property(qe, "brg-frequency", &size);
> + if (!prop || size != sizeof(*prop))
> + return brg_clk;
You need an of_node_put(qe) before the return ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] ehea: add memory remove hotplug support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
Add memory remove hotplug support
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Comment: This patch depends on the following patch that
exports the symbols
register_memory_notifier()
unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
drivers/net/ehea/ehea_main.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 21af674..b75afcc 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <linux/memory.h>
#include <asm/kexec.h>
#include <net/ip.h>
@@ -3480,6 +3481,24 @@ void ehea_crash_handler(void)
0, H_DEREG_BCMC);
}
+static int ehea_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ switch (action) {
+ case MEM_OFFLINE:
+ ehea_info("memory has been removed");
+ ehea_rereg_mrs(NULL);
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ehea_mem_nb = {
+ .notifier_call = ehea_mem_notifier,
+};
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
if (ret)
ehea_info("failed registering reboot notifier");
+ ret = register_memory_notifier(&ehea_mem_nb);
+ if (ret)
+ ehea_info("failed registering memory remove notifier");
+
ret = crash_shutdown_register(&ehea_crash_handler);
if (ret)
ehea_info("failed registering crash handler");
@@ -3582,6 +3605,7 @@ int __init ehea_module_init(void)
out3:
ibmebus_unregister_driver(&ehea_driver);
out2:
+ unregister_memory_notifier(&ehea_mem_nb);
unregister_reboot_notifier(&ehea_reboot_nb);
crash_shutdown_unregister(&ehea_crash_handler);
out:
@@ -3599,6 +3623,7 @@ static void __exit ehea_module_exit(void)
ret = crash_shutdown_unregister(&ehea_crash_handler);
if (ret)
ehea_info("failed unregistering crash handler");
+ unregister_memory_notifier(&ehea_mem_nb);
kfree(ehea_fw_handles.arr);
kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
--
1.5.2
^ permalink raw reply related
* [PATCH 1/2] ehea: kdump support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch adds kdump support to the ehea driver. As the firmware doesn't free
resource handles automatically, the driver has to run an as simple as possible
free resource function in case of a crash shutdown. The function iterates over
two arrays freeing all resource handles which are stored there. The arrays are
kept up-to-date during normal runtime. The crash handler fn is triggered by the
recently introduced PPC crash shutdown reg/unreg functions.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 34 +++++-
drivers/net/ehea/ehea_main.c | 281 ++++++++++++++++++++++++++++++++++++++----
2 files changed, 290 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 88fb53e..7c4ead3 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0083"
+#define DRV_VERSION "EHEA_0087"
/* 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 --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c051c7e..21af674 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -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;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags;
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);
@@ -132,6 +135,160 @@ void ehea_dump(void *adr, int len, char *msg)
}
}
+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);
@@ -1601,19 +1758,25 @@ static int ehea_set_mac_addr(struct net_device *dev, void *sa)
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:
@@ -1775,9 +1938,11 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
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);
@@ -1803,6 +1968,8 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
out:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
return;
}
@@ -2285,6 +2452,8 @@ static int ehea_up(struct net_device *dev)
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) {
@@ -2321,8 +2490,17 @@ static int ehea_up(struct net_device *dev)
}
}
- 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:
@@ -2334,6 +2512,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;
}
@@ -2382,16 +2566,27 @@ static int ehea_down(struct net_device *dev)
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;
}
@@ -2920,19 +3115,12 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
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;
@@ -2949,9 +3137,6 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
return port;
-out_dereg_bc:
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
-
out_unreg_port:
ehea_unregister_port(port);
@@ -2971,7 +3156,6 @@ static void ehea_shutdown_single_port(struct ehea_port *port)
{
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--;
@@ -3014,7 +3198,6 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
i++;
};
-
return 0;
}
@@ -3159,6 +3342,7 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
+ down(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3239,7 +3423,10 @@ out_kill_eq:
out_free_ad:
kfree(adapter);
+
out:
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
return ret;
}
@@ -3258,18 +3445,41 @@ static int __devexit ehea_remove(struct of_device *dev)
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)
{
@@ -3330,7 +3540,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)
@@ -3340,12 +3555,18 @@ int __init ehea_module_init(void)
if (ret)
goto out;
- register_reboot_notifier(&ehea_reboot_nb);
+ ret = register_reboot_notifier(&ehea_reboot_nb);
+ if (ret)
+ ehea_info("failed registering reboot notifier");
+
+ ret = crash_shutdown_register(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed registering crash handler");
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
ehea_error("failed registering eHEA device driver on ebus");
- goto out;
+ goto out2;
}
ret = driver_create_file(&ehea_driver.driver,
@@ -3353,21 +3574,33 @@ int __init ehea_module_init(void)
if (ret) {
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
- unregister_reboot_notifier(&ehea_reboot_nb);
- ibmebus_unregister_driver(&ehea_driver);
- goto out;
+ goto out3;
}
+ return ret;
+
+out3:
+ ibmebus_unregister_driver(&ehea_driver);
+out2:
+ unregister_reboot_notifier(&ehea_reboot_nb);
+ crash_shutdown_unregister(&ehea_crash_handler);
out:
return ret;
}
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();
}
--
1.5.2
^ permalink raw reply related
* [PATCH 0/2] ehea: kdump & memory remove support
From: Jan-Bernd Themann @ 2008-02-04 13:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch set adds support for kdump and hotplug memory remove
to the eHEA driver.=20
The "memory remove" patch depends on the following patch that
has been posted a few days ago. That patch exports the symbols
=A0- register_memory_notifier()
=A0- unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
Regards,
Jan-Bernd
^ permalink raw reply
* Re: Commit for mm/page_alloc.c breaks boot process on my machine
From: Mel Gorman @ 2008-02-04 10:42 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080201210656.174030@gmx.net>
On (01/02/08 22:06), Gerhard Pircher didst pronounce:
>
> -------- Original-Nachricht --------
> > Datum: Fri, 1 Feb 2008 20:25:18 +0000
> > Von: Mel Gorman <mel@csn.ul.ie>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > CC: linux-kernel@vger.kernel.org
> > Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine
>
> > I meant uninitialised memory but I also wonder could something like this
> > happen if you are trying to use memory that doesn't exist. i.e. you are
> > trying to access more memory than you really have but you indicate later
> > that this is not the case.
>
> Good question. The memory is in the physical address range from 0x00000000
> to 0x60000000 (1536MB).
>
> > > > 2. Any chance of seeing a dmesg log?
> > > That's a little bit of a problem. The kernel log in memory doesn't show
> > > any kernel oops, but is also fragmented (small fragments seem to have
> > > been overwritten with 0x0).
> >
> > err, that doesn't sound very healthy.
>
> Yeah, I know. But the platform code hasn't changed much when porting it
> from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this
> case. :-)
>
I'm at a bit of a loss to guess what might have changed in powerpc code
that would explain this. I've added the linuxppc-dev mailing list in
case they can make a guess.
I think you are also going to need to start bisecting searching
specifically for the patch that causes these overwrites.
> > > Well, I can't answer this question. The kernel currently locks up when
> > > loading the INIT program. But that is another problem (I still have to
> > > bisect it) and doesn't seem to be related to this problem.
> >
> > INIT would be the first MOVABLE allocation so it would be using memory
> > at the end of the physical adddress range. i.e. the crash happens when
> > memory towards the end and the only difference between the patch applied
> > and reverted is when it happens.
> Oh, that sounds interesting!
>
> > Could you try booting with 16MB less memory using mem=?
> I started the kernel with 512MB RAM (mem=496) and 1.5GB (mem=1520). The
> kernel oopes in both cases with a "Unable to handle kernel paging request
> for data address 0xbffff000", followed by a "Oops: kernel access of bad
> area, sig 11" message. The end of the stack trace shows the start_here()
> function.
> I'm not a PowerPC expert, but if 0xbffff000 is a virtual address, then
> it would be in the user program address space, right? If it is a physical
> address, then it is somewhere in the unallocated PCI address space.
>
It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-02-04 10:26 UTC (permalink / raw)
To: Sven Luther; +Cc: debian-powerpc, paulus, linuxppc-dev
In-Reply-To: <20080204095121.GA18167@powerlinux.fr>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
On Monday 04 February 2008 10:51, Sven Luther wrote:
> On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> > Dear linux powerpc Maintainers and Users,
> >
> > recently I have tried to compile a new kernel on a Debian sarge ppc
> > system (PowerBook5,6 MacRISC3 Power Macintosh).
>
> This is a G4 based system.
Yes.
> > The build system bailed out with
> > BOOTCC arch/powerpc/boot/4xx.o
> > cc1: error: bad value (440) for -mcpu= switch
> > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
> >
> > I have tracked this a few steps and the attached patch made the compile
> > for me as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> > cannot produce code for 4xx it seems.
>
> You should normally not need to build the 4xx bootloader part. Make sure
> that, i don't know why this happens. Can you look into
> arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> and make sure it is disabled in the main config ?
I have tried to do this, but it looks like it is just hardcoded into the
Makefile as you can see from the patch. There is probably more that I do not
understand - thus my report with on the workaround.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Build failure with 2.6.24-mm1
From: Andrew Morton @ 2008-02-04 10:19 UTC (permalink / raw)
To: balbir; +Cc: linuxppc-dev, Shaohua, Zhang Yanmin, Greg KH, Li
In-Reply-To: <20080204100743.GA4445@balbir.in.ibm.com>
On Mon, 4 Feb 2008 15:37:43 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> * Balbir Singh <balbir@linux.vnet.ibm.com> [2008-02-04 15:35:09]:
>
> I just saw the following build failure on a power machine.
>
> In file included from include/acpi/platform/acenv.h:140,
> from include/acpi/acpi.h:54,
> from include/acpi/acpi_bus.h:31,
> from drivers/pci/pcie/aspm.c:20:
> include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory
> In file included from include/acpi/platform/aclinux.h:120,
> from include/acpi/platform/acenv.h:140,
> from include/acpi/acpi.h:54,
> from include/acpi/acpi_bus.h:31,
> from drivers/pci/pcie/aspm.c:20:
> include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'UINT64'
> include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'INT64'
> include/acpi/actypes.h:753: error: expected ')' before '*' token
> include/acpi/actypes.h:756: error: expected ')' before '*' token
> In file included from include/acpi/acpi.h:61,
> from include/acpi/acpi_bus.h:31,
> from drivers/pci/pcie/aspm.c:20:
> include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...'
> before 'acpi_osd_handler'
> include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...'
> before 'acpi_osd_handler'
> include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...'
> before 'acpi_osd_exec_callback'
> make[3]: *** [drivers/pci/pcie/aspm.o] Error 1
> make[2]: *** [drivers/pci/pcie] Error 2
> make[2]: *** Waiting for unfinished jobs....
> CC drivers/ps3/ps3-vuart.o
> CC net/netlink/attr.o
> make[1]: *** [drivers/pci] Error 2
> make[1]: *** Waiting for unfinished jobs..
>
> The following config option is responsible for the build failure
>
> config PCIEASPM
> bool "PCI Express ASPM support(Experimental)"
> depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> default y
> help
> This enables PCI Express ASPM (Active State Power Management) and
> Clock Power Management. ASPM supports state L0/L0s/L1.
>
> When in doubt, say N.
>
> Here's a probable fix for the problem.
>
>
> Make the build of drivers/pci/pcie/aspm.c depend on ACPI.
>
> NOTE, the patch has not been tested. The dependency on ACPI might be wrong,
> but setting it to default "y" caused the build on my powerpc box to break.
>
> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> ---
>
> drivers/pci/pcie/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig
> --- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 15:30:29.000000000 +0530
> +++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig 2008-02-04 15:33:45.000000000 +0530
> @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
> #
> config PCIEASPM
> bool "PCI Express ASPM support(Experimental)"
> - depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> + depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI
> default y
> help
> This enables PCI Express ASPM (Active State Power Management) and
Thanks. I think Greg is going to revert PCIEASPM altogether?
^ permalink raw reply
* Build failure with 2.6.24-mm1
From: Balbir Singh @ 2008-02-04 10:07 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev; +Cc: Shaohua Li, Zhang Yanmin
In-Reply-To: <47A6E355.8040404@linux.vnet.ibm.com>
* Balbir Singh <balbir@linux.vnet.ibm.com> [2008-02-04 15:35:09]:
I just saw the following build failure on a power machine.
In file included from include/acpi/platform/acenv.h:140,
from include/acpi/acpi.h:54,
from include/acpi/acpi_bus.h:31,
from drivers/pci/pcie/aspm.c:20:
include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory
In file included from include/acpi/platform/aclinux.h:120,
from include/acpi/platform/acenv.h:140,
from include/acpi/acpi.h:54,
from include/acpi/acpi_bus.h:31,
from drivers/pci/pcie/aspm.c:20:
include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'UINT64'
include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'INT64'
include/acpi/actypes.h:753: error: expected ')' before '*' token
include/acpi/actypes.h:756: error: expected ')' before '*' token
In file included from include/acpi/acpi.h:61,
from include/acpi/acpi_bus.h:31,
from drivers/pci/pcie/aspm.c:20:
include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...'
before 'acpi_osd_handler'
include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...'
before 'acpi_osd_handler'
include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...'
before 'acpi_osd_exec_callback'
make[3]: *** [drivers/pci/pcie/aspm.o] Error 1
make[2]: *** [drivers/pci/pcie] Error 2
make[2]: *** Waiting for unfinished jobs....
CC drivers/ps3/ps3-vuart.o
CC net/netlink/attr.o
make[1]: *** [drivers/pci] Error 2
make[1]: *** Waiting for unfinished jobs..
The following config option is responsible for the build failure
config PCIEASPM
bool "PCI Express ASPM support(Experimental)"
depends on PCI && EXPERIMENTAL && PCIEPORTBUS
default y
help
This enables PCI Express ASPM (Active State Power Management) and
Clock Power Management. ASPM supports state L0/L0s/L1.
When in doubt, say N.
Here's a probable fix for the problem.
Make the build of drivers/pci/pcie/aspm.c depend on ACPI.
NOTE, the patch has not been tested. The dependency on ACPI might be wrong,
but setting it to default "y" caused the build on my powerpc box to break.
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---
drivers/pci/pcie/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig
--- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 15:30:29.000000000 +0530
+++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig 2008-02-04 15:33:45.000000000 +0530
@@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
#
config PCIEASPM
bool "PCI Express ASPM support(Experimental)"
- depends on PCI && EXPERIMENTAL && PCIEPORTBUS
+ depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI
default y
help
This enables PCI Express ASPM (Active State Power Management) and
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Sven Luther @ 2008-02-04 9:51 UTC (permalink / raw)
To: Bernhard Reiter; +Cc: debian-powerpc, paulus, linuxppc-dev
In-Reply-To: <200802031729.12069.bernhard@intevation.de>
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
> Dear linux powerpc Maintainers and Users,
>
> recently I have tried to compile a new kernel on a Debian sarge ppc
> system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
> The build system bailed out with
> BOOTCC arch/powerpc/boot/4xx.o
> cc1: error: bad value (440) for -mcpu= switch
> make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
>
> I have tracked this a few steps and the attached patch made the compile for me
> as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
> cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
Please bounce this message to debian-powerpc, as debian believes in
censorship instead of trying to solve inimity by discussion.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Aneesh Kumar K.V @ 2008-02-04 9:29 UTC (permalink / raw)
To: Heiko Carstens
Cc: linux-s390, Bastian Blank, Linux Kernel Development,
Linux/PPC Development, Geert Uytterhoeven, Andrew Morton,
linux-ext4
In-Reply-To: <20080204092436.GB7530@osiris.boeblingen.de.ibm.com>
On Mon, Feb 04, 2008 at 10:24:36AM +0100, Heiko Carstens wrote:
> > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
> > > > >
> > > > > The s390 specific bitops uses parts of the generic implementation.
> > > > > Include the correct header.
> > > >
> > > > That doesn't work:
> > > >
> > > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
> > > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
> > > >
> > > > This still needs generic_find_next_le_bit which comes
> > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > > don't set GENERIC_FIND_NEXT_BIT.
> > > > Currently we have the lengthly patch below queued.
> > >
> > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > > impression the ext4 people don't (compile) test on big endian machines?
> > >
> > > Gr{oetje,eeting}s,
> > >
> >
> > I have sent this patches to linux-arch expecting a review from
> > different arch people. It is true that the patches are tested only on
> > powerpc, x86-64, x86. That's the primary reason of me sending the
> > patches to linux-arch.
>
> Is there anything special I need to do so the ext4 code actually uses
> ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
> test if the s390 implementation is ok.
With the latest linus kernel in git you can test it by mounting ext4
mount -t ext4dev <device> <mntpoint>
-aneesh
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Heiko Carstens @ 2008-02-04 9:24 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-s390, Bastian Blank, Linux Kernel Development,
Linux/PPC Development, Geert Uytterhoeven, Andrew Morton,
linux-ext4
In-Reply-To: <20080204045025.GA7494@skywalker>
> > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
> > > >
> > > > The s390 specific bitops uses parts of the generic implementation.
> > > > Include the correct header.
> > >
> > > That doesn't work:
> > >
> > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
> > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
> > >
> > > This still needs generic_find_next_le_bit which comes
> > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > don't set GENERIC_FIND_NEXT_BIT.
> > > Currently we have the lengthly patch below queued.
> >
> > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > impression the ext4 people don't (compile) test on big endian machines?
> >
> > Gr{oetje,eeting}s,
> >
>
> I have sent this patches to linux-arch expecting a review from
> different arch people. It is true that the patches are tested only on
> powerpc, x86-64, x86. That's the primary reason of me sending the
> patches to linux-arch.
Is there anything special I need to do so the ext4 code actually uses
ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
test if the s390 implementation is ok.
^ permalink raw reply
* Moving from 2.6.14 (ppc) to 2.6.20 (powerpc): problems with PCI-PCI bridge
From: Johan Borkhuis @ 2008-02-04 9:13 UTC (permalink / raw)
To: Linuxppc-dev, Linuxppc-embedded
Hello,
I was using kernel version 2.6.14 (ppc) on a MVME3100 board (MPC8540
processor). We are planning to move to 2.6.20 (powerpc), but I have some
problems with the initialization of a PCI-PCI bridge.
Connected to the MVME3100 board is a PCI-PCI bridge (HiNT, PCI6150,
3388:0022). When using the 2.6.14 kernel this bridge is initialized
correctly: it is setup as bus-master, memory and IO are configured, and
the memory allocation on the PCI-bus is correct.
When I use 2.6.20 (powerpc) the device is not configured correctly:
bus-master, memory and IO are not set, and the memory space of the
bridge on the PCI bus is set to the minimum value (0xfffff).
I can correct these settings by modifying the PCI_COMMAND register to
set the bus-master, memory and IO. I change the size of the memory space
in pci_32.c, by forcing the size to the required setting in
pci_relocate_bridge_resource. But to be honest, I don't like this very
much: modifying registers like this should not be needed, so I guess
there is something wrong in my configuration or setup.
How can I fix this problem in a better way? What could be wrong with my
configuration?
Below is some output from lspci:
bash-3.00# lspci -t
-[0000:00]-+-01.0
+-02.0-[0000:01]--
+-03.0-[0000:02-03]--+-00.0
| +-00.1
| +-00.2
| \-04.0-[0000:03]--+-02.0
| \-03.0
\-04.0
bash-3.00# lspci -vs 02:04.0
02:04.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04)
(prog-if 00 [Normal decode])
Flags: bus master, medium devsel, latency 0
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00011000-00011fff
Memory behind bridge: 87f00000-87ffffff
Prefetchable memory behind bridge: 0000000087e00000-0000000087e00000
Capabilities: [dc] Power Management version 1
Capabilities: [e4] #06 [0094]
Capabilities: [e8] Vital Product Data
After the modifications to the PCI COMMAND register and memory map:
bash-3.00# lspci -vs 02:04.0
02:04.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04)
(prog-if 00 [Normal decode])
Flags: stepping, medium devsel
Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00011000-00011fff
Memory behind bridge: 82000000-87ffffff
Prefetchable memory behind bridge: 0000000000000000-0000000000000000
Capabilities: [dc] Power Management version 1
Capabilities: [e4] #06 [0094]
Capabilities: [e8] Vital Product Data
Kind regards,
Johan Borkhuis
--
Johan Borkhuis Dutch Space BV
email: j.borkhuis@dutchspace.nl Newtonweg 1
phone: 071-5245788 Leiden
fax: 071-5245499 The Netherlands
^ permalink raw reply
* Fwd: [RFC/PATCH v2] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-04 7:05 UTC (permalink / raw)
To: David Woodhouse, linuxppc-dev
In-Reply-To: <20080201000706.18869.36903.stgit@trillian.secretlab.ca>
David, can you please take a look at this patch? It makes two changes
which will have an impact on distributions.
First, it changes the ps3 target from zImage.ps3 to zImage.dtb.ps3.
The change was made to simplify the build dependancies in
arch/powerpc/boot/Makefile so that each target that embeds a device
tree into the zImage doesn't need to clone a new makefile rule (which
affects 5 platforms at the moment).
Second, I've eliminated the BOOTIMAGE environmental variable. I don't
think it's used anywhere, but it's possible that distros make use of
it.
Let me know if either of these pose a serious problem.
Thanks,
g.
---------- Forwarded message ----------
From: Grant Likely <grant.likely@secretlab.ca>
Date: Jan 31, 2008 5:07 PM
Subject: [RFC/PATCH v2] [POWERPC] bootwrapper: build multiple cuImages
To: jwboyer@gmail.com, linuxppc-dev@ozlabs.org,
scotwood@freescale.com, galak@kernel.crashing.org,
stephen.neuendorffer@xilinx.com, jochen@scram.de,
geoffrey.levand@am.sony.com
From: Grant Likely <grant.likely@secretlab.ca>
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts file out of the kernel
config and into the bootwrapper makefile. The makefile chooses which
images to build based on the kernel config and the dts source file
name is taken directly from the image name. For example "cuImage.ebony"
will use "ebony.dts" as the device tree source file.
In addition, this patch allows a specific image to be requested from the
command line by adding "cuImage.%" and "treeImage.%" targets to the list
of valid built targets in arch/powerpc/Makefile. This allows the default
dts selection to be overridden.
Another advantage to this change is it allows a single defconfig to be
supplied for all boards using the same chip family and only differing in
the device tree.
Important note: This patch adds two new zImage targets; zImage.dtb.% and
zImage.dtb.initrd.% for zImages with embedded dtb files. Currently
there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
adder875-redboot and ep8248e. This patch *changes the zImage filenames*
for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.
This new zImage.dtb targets were added so that the .dts file could be
part of the dependancies list for building them.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Please review and comment. I have not exhaustively tested this patch
and I'm sure to have missed some boards. However, I think the concept
is sound and will be a good change.
This version fixes some bugs and adds new zImage.dtb and zImage.initrd.dtb
targets.
g.
---
arch/powerpc/Kconfig | 19 -----
arch/powerpc/Makefile | 9 +-
arch/powerpc/boot/Makefile | 132 ++++++++++++++++++++------------
arch/powerpc/boot/cuboot-hpc2.c | 48 ------------
arch/powerpc/boot/cuboot-mpc7448hpc2.c | 48 ++++++++++++
arch/powerpc/boot/wrapper | 23 ++++++
6 files changed, 157 insertions(+), 122 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2bf2f3f..4903796 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -415,25 +415,6 @@ config WANT_DEVICE_TREE
bool
default n
-config DEVICE_TREE
- string "Static device tree source file"
- depends on WANT_DEVICE_TREE
- help
- This specifies the device tree source (.dts) file to be
- compiled and included when building the bootwrapper. If a
- relative filename is given, then it will be relative to
- arch/powerpc/boot/dts. If you are not using the bootwrapper,
- or do not need to build a dts into the bootwrapper, this
- field is ignored.
-
- For example, this is required when building a cuImage target
- for an older U-Boot, which cannot pass a device tree itself.
- Such a kernel will not work with a newer U-Boot that tries to
- pass a device tree (unless you tell it not to). If your U-Boot
- does not mention a device tree in "help bootm", then use the
- cuImage target and specify a device tree here. Otherwise, use
- the uImage target and leave this field blank.
-
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6845482 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,14 +151,11 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 122a270..bd2b98d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -60,8 +60,9 @@ src-wlib := string.S crt0.S stdio.c main.c \
src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c
cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
+ cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
+ fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -123,6 +124,8 @@ targets += $(patsubst
$(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds
$(obj)/zImage.ps3.lds
+dtstree := $(srctree)/$(src)/dts
+
wrapper :=$(srctree)/$(src)/wrapper
wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff
mktree dtc) \
$(wrapper) FORCE
@@ -181,7 +184,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage.ps3
+image-$(CONFIG_PPC_PS3) += zImage.dtb.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -191,33 +194,73 @@ image-$(CONFIG_PPC_PRPMC2800) +=
zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
-ifneq ($(CONFIG_DEVICE_TREE),"")
-image-$(CONFIG_PPC_8xx) += cuImage.8xx
-image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
-image-$(CONFIG_EP405) += zImage.ep405
-image-$(CONFIG_8260) += cuImage.pq2
-image-$(CONFIG_EP8248E) += zImage.ep8248e
-image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
-image-$(CONFIG_STORCENTER) += cuImage.824x
-image-$(CONFIG_PPC_83xx) += cuImage.83xx
-image-$(CONFIG_PPC_85xx) += cuImage.85xx
-ifeq ($(CONFIG_CPM2),y)
-image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
-endif
-image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
+#
+# Targets which embed a device tree blob
+#
+# Theses are default targets to build images which embed device tree blobs.
+# They are only required on boards which do not have FDT support in firmware.
+# Boards with newish u-boot firmare can use the uImage target above
+#
+
+# Board ports in arch/powerpc/platform/40x/Kconfig
+image-$(CONFIG_EP405) += zImage.dtb.ep405
+image-$(CONFIG_WALNUT) += treeImage.walnut
+
+# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_RAINIER) += cuImage.rainier
-image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-endif
-ifneq ($(CONFIG_REDBOOT),"")
-image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
-endif
+# Board ports in arch/powerpc/platform/8xx/Kconfig
+image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
+image-$(CONFIG_PPC_MPC885ADS) += zImage.dtb.mpc885ads
+image-$(CONFIG_PPC_EP88XC) += zImage.dtb.ep88xc
+image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
+ zImage.dtb.adder875-redboot
+
+# Board ports in arch/powerpc/platform/52xx/Kconfig
+image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
+
+# Board ports in arch/powerpc/platform/82xx/Kconfig
+image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
+image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
+image-$(CONFIG_EP8248E) += zImage.dtb.ep8248e
+
+# Board ports in arch/powerpc/platform/83xx/Kconfig
+image-$(CONFIG_MPC8313_RDB) += cuImage.mpc8313erdb
+image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
+image-$(CONFIG_MPC832x_RDB) += cuImage.mpc832x_rdb
+image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \
+ cuImage.mpc8349emitxgp
+image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds
+image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds
+image-$(CONFIG_MPC837x_MDS) += cuImage.mpc8377_mds \
+ cuImage.mpc8378_mds \
+ cuImage.mpc8379_mds
+
+# Board ports in arch/powerpc/platform/85xx/Kconfig
+image-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
+image-$(CONFIG_MPC8560_ADS) += cuImage.mpc8560ads
+image-$(CONFIG_MPC85xx_CDS) += cuImage.mpc8541cds \
+ cuImage.mpc8548cds \
+ cuImage.mpc8555cds
+image-$(CONFIG_MPC85xx_MDS) += cuImage.mpc8568mds
+image-$(CONFIG_MPC85xx_DS) += cuImage.mpc8544ds \
+ cuImage.mpc8572ds
+image-$(CONFIG_TQM8540) += cuImage.tqm8540
+image-$(CONFIG_TQM8541) += cuImage.tqm8541
+image-$(CONFIG_TQM8555) += cuImage.tqm8555
+image-$(CONFIG_TQM8560) += cuImage.tqm8560
+image-$(CONFIG_SBC8548) += cuImage.tqm8548
+image-$(CONFIG_SBC8560) += cuImage.tqm8560
+
+# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
+image-$(CONFIG_STORCENTER) += cuImage.storcenter
+image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
@@ -233,24 +276,20 @@ targets += $(image-y) $(initrd-y)
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
-# If CONFIG_WANT_DEVICE_TREE is set and CONFIG_DEVICE_TREE isn't an
-# empty string, define 'dts' to be path to the dts
-# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
-ifeq ($(CONFIG_WANT_DEVICE_TREE),y)
-ifneq ($(CONFIG_DEVICE_TREE),"")
-dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
- ,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
-endif
-endif
-
# Don't put the ramdisk on the pattern rule; when its missing make will try
# the pattern rule with less dependencies that also matches (even with the
# hard dependency listed).
-$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/zImage.initrd.dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts))
+$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
+
+$(obj)/zImage.dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts)
+
+$(obj)/zImage.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
# prefix
@@ -260,24 +299,17 @@ $(obj)/vmlinux.strip: vmlinux
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
-$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits)
$(srctree)/$(src)/dts/ps3.dts
- $(STRIP) -s -R .comment $< -o vmlinux.strip
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
-
-$(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits)
$(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
-
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
-$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,cuboot-$*,$(dts))
+$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
-$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
+$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
@@ -286,8 +318,10 @@ endif
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
+ @echo target images: $(image-y)
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
@rm -f $@; ln $< $@
+ @echo target images: $(initrd-y)
install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" $<
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
deleted file mode 100644
index 1b89532..0000000
--- a/arch/powerpc/boot/cuboot-hpc2.c
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: Roy Zang <tie-fei.zang@freescale.com>
- *
- * Description:
- * Old U-boot compatibility for mpc7448hpc2 board
- * Based on the code of Scott Wood <scottwood@freescale.com>
- * for 83xx and 85xx.
- *
- * This is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
-
-#include "ops.h"
-#include "stdio.h"
-#include "cuboot.h"
-
-#define TARGET_HAS_ETH1
-#include "ppcboot.h"
-
-static bd_t bd;
-extern char _dtb_start[], _dtb_end[];
-
-static void platform_fixups(void)
-{
- void *tsi;
-
- dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
- dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
- dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
- tsi = find_node_by_devtype(NULL, "tsi-bridge");
- if (tsi)
- setprop(tsi, "bus-frequency", &bd.bi_busfreq,
- sizeof(bd.bi_busfreq));
-}
-
-void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
- unsigned long r6, unsigned long r7)
-{
- CUBOOT_INIT();
- fdt_init(_dtb_start);
- serial_console_init();
- platform_ops.fixups = platform_fixups;
-}
diff --git a/arch/powerpc/boot/cuboot-mpc7448hpc2.c
b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
new file mode 100644
index 0000000..1b89532
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_HAS_ETH1
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ fdt_init(_dtb_start);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 763a0c4..c317815 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -158,6 +158,29 @@ miboot|uboot)
cuboot*)
binary=y
gzip=
+ case "$platform" in
+ *-mpc885ads|*-adder875*|*-ep88xc)
+ platformo=$object/cuboot-8xx.o
+ ;;
+ *5200*|*-motionpro)
+ platformo=$object/cuboot-52xx.o
+ ;;
+ *-pq2fads|*-ep8248e|*-mpc8272*|*-storcenter)
+ platformo=$object/cuboot-pq2.o
+ ;;
+ *-mpc824*)
+ platformo=$object/cuboot-824x.o
+ ;;
+ *-mpc83*)
+ platformo=$object/cuboot-83xx.o
+ ;;
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ platformo=$object/cuboot-85xx-cpm2.o
+ ;;
+ *-mpc85*)
+ platformo=$object/cuboot-85xx.o
+ ;;
+ esac
;;
ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: [PATCH] create modalias file in sysfs for bus vio
From: Stephen Rothwell @ 2008-02-04 6:39 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080125170914.GA29887@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
Hi Olaf,
[Sorry, been on vacation]
On Fri, 25 Jan 2008 18:09:14 +0100 Olaf Hering <olaf@aepfle.de> wrote:
>
> On Wed, Jan 23, Stephen Rothwell wrote:
>
> > It would be nice if we could factor out the "vio:T%sS%s" string as it is
> > also used in vio_hotplug().
>
> What exactly do you have in mind?
> Creating a tempstring seems to make things more complicated.
Yeah, but it would be nice if the format only had to be known/changed in
one place. Don't worry about it for now. Or maybe create a "static const
char []" or #define with the string.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ppc] Disparity between sys_clock_getres and vdso implementation
From: Tony Breeds @ 2008-02-04 6:08 UTC (permalink / raw)
To: Sripathi Kodi; +Cc: linuxppc-dev, paulus, linux-kernel, john stultz
In-Reply-To: <200801271932.59823.sripathik@in.ibm.com>
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> Hi Paul,
>
> On PPC, I see a disparity between clock_getres implementations in the
> vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> with CONFIG_HIGH_RES_TIMERS=y.
>
> clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> to be returning some pre-defined (incorrect) variables.
>
> Could you please let me know the reason for this? Is it something that
> should be fixed in vdso?
Almost certainly It's something I missed when I enabled highres timers
on powerpc.
I'll fix this tomorrow.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Aneesh Kumar K.V @ 2008-02-04 5:22 UTC (permalink / raw)
To: Bastian Blank, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080201200240.GA28566@wavehammer.waldi.eu.org>
On Fri, Feb 01, 2008 at 09:02:40PM +0100, Bastian Blank wrote:
> Fix ext4 bitops.
>
> Signed-off-by: Bastian Blank <waldi@debian.org>
>
> diff --git a/include/asm-powerpc/bitops.h b/include/asm-powerpc/bitops.h
> index 220d9a7..d0980df 100644
> --- a/include/asm-powerpc/bitops.h
> +++ b/include/asm-powerpc/bitops.h
> @@ -363,6 +363,8 @@ unsigned long generic_find_next_le_bit(const unsigned long *addr,
> unsigned long size, unsigned long offset);
> /* Bitmap functions for the ext2 filesystem */
>
> +#include <asm-generic/bitops/le.h>
> +
> #define ext2_set_bit(nr,addr) \
> __test_and_set_le_bit((nr), (unsigned long*)addr)
> #define ext2_clear_bit(nr, addr) \
I am not sure what the changes are for. Can you send me the build logs
with the compile error. I always test Ext4 on powerpc so not sure what
went wrong.
-aneesh
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Aneesh Kumar K.V @ 2008-02-04 4:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-s390, Heiko Carstens, Bastian Blank,
Linux Kernel Development, Linux/PPC Development, Andrew Morton,
linux-ext4
In-Reply-To: <Pine.LNX.4.64.0802031336240.28712@anakin>
On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote:
> On Sun, 3 Feb 2008, Heiko Carstens wrote:
> > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
> > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
> > > > On Fri, 1 Feb 2008 21:02:08 +0100
> > > > Bastian Blank <bastian@waldi.eu.org> wrote:
> > > >
> > > > > Fix ext4 bitops.
> > > >
> > > > This is incomplete. Please tell us what was "fixed".
> > > >
> > > > If it was a build error then please quote the compile error output in the
> > > > changelog, as well as the usual description of what the problem is, and how
> > > > it was fixed.
> > >
> > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
> > >
> > > The s390 specific bitops uses parts of the generic implementation.
> > > Include the correct header.
> >
> > That doesn't work:
> >
> > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
> > fs/built-in.o: In function `ext4_mb_init_cache':
> > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
> >
> > This still needs generic_find_next_le_bit which comes
> > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > don't set GENERIC_FIND_NEXT_BIT.
> > Currently we have the lengthly patch below queued.
>
> Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> impression the ext4 people don't (compile) test on big endian machines?
>
> Gr{oetje,eeting}s,
>
I have sent this patches to linux-arch expecting a review from
different arch people. It is true that the patches are tested only on
powerpc, x86-64, x86. That's the primary reason of me sending the
patches to linux-arch.
http://marc.info/?l=linux-arch&m=119503501127737&w=2
-aneesh
^ permalink raw reply
* Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
From: Anton Vorontsov @ 2008-02-03 23:32 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev
In-Reply-To: <200802031322.08600.david-b@pacbell.net>
On Sun, Feb 03, 2008 at 01:22:08PM -0800, David Brownell wrote:
[...]
> > One of the biggest things these conventions omit is pin multiplexing,
> > since this is highly chip-specific and nonportable.
> >
> > Let me counter: "chip-specific" is a weak argument, IMO.
>
> Then focus on "nonportable concepts" instead. :)
>
>
> Note that "pin" != "GPIO". There are platforms that let one GPIO
> be routed to any of several pins/balls; and let a given pin/ball
> be multiplexed to support any of several GPIOs. (Annoying because
> it's so error prone, but true. I'll call that the "OMAP1" pinmux
> issue, since that's where I first ran into it.)
>
> Likewise, not all pins with multiplexed functionality include GPIO
> as one of those functions.
>
> So when you assume that a GPIO number can uniquely specify a pin for
> use in function multiplexing ... you're stressing a "nonportable"
> aspect of this issue.
>
> Ditto when you assume that the multiplexing is on a per-pin basis,
> rather than affecting a defined group of pins. (More common, and
> less annoying, than the OMAP1 issue.)
>
> (And that doesn't even touch issues like configurable drive strength,
> pullups, pulldowns, and so on.)
This is all true, of course.
>
> > Imagine some
> > GPIO controller that can't do inputs, or outputs. First one will be
> > still suitable for gpio_leds, second one will be suitable for gpio_keys.
>
> The interface easily handles input-only and output-only GPIOs.
> Make the relevant gpio_direction_*() methods fail those requests.
The point was: GPIOs could be "input only" but you still have
"output" callback, and that doesn't troubles anybody. Not sure
why set_dedicated() such a big issue then, it could fail too! :-)
We're talking about General Purpose IOs, right? They're general
enough to support not only input/output stuff. And we want some
API for these General Purpose IOs. GPIO LIB is the best candidate
and we can implement such API at almost no cost, few lines of code.
> > Or... gpio_to_irq/irq_to_gpio. More than chip-specific, isn't it?
> > Some GPIO controllers might provide interrupt sources, some might
> > not.
>
> Right now there isn't a generic hookup between GPIOs and IRQs;
> that's all very platform-specific. For example, maybe it doesn't
> use the genirq framework ... and even if it does, there's a huge
> hole where "removing irq_chip and its irqs" fits.
>
> It's easy enough for most platforms to arrange that a particular
> range of GPIO numbers maps to a particular set of IRQ numbers
> through the IRQ chaining mechanism.
He-he. Actually, I have a patch that adds "to_irq" callback
to GPIO LIB. :-) But I just didn't find time yet to cleanup
the "user" of that addition (ARM-based "samcop" companion chip).
Briefly: gpio<->irq mapping there isn't "flat". It is messed
all around. GPIO 1 is IRQ 12, GPIO 2 if IRQ 45 and so on... no
common pattern. So, to support gpio_to_irq() we have to either:
1. change the mappings of the IRQs, to match GPIOs.
or
2. implement to_irq() callback (way easier).
> > Or let's put it completely different way: IRQs, they are
> > chip specific too, some of them can't do EDGE_FALLING or
> > EDGE_RISING. But these flags still exists for the IRQs,
> > and drivers use them.
>
> Sure; though as a rule, any driver that specifies trigger modes
> is platform-specific when it does so. Plus, very few would know
> what to do when they learn that the EDGE_FALLING mode they asked
> for is not supported by the underlying hardware.
Exactly. The question is how much "platforms" that driver could
support. When driver that using EDGE_* works for >= 2 platforms,
then this flag is worthwhile already.
> > The same for GPIO pin multiplexing: some drivers aren't aware of
> > GPIO multiplexing, but some are.
>
> And if they are aware, that's platform-specific code. So there can
> be no issue in requiring use of platform-specific calls for that.
>
> Example, when a given function can come out on either of two pins
> (like MMC0.CMD on some chips), and those pins vary between models
> of that SOC family ... the driver will either know highly nonportable
> details about each chip,
No. Driver don't have to know chip details. _Platform code_ is passing
these details to the driver (via platform data or OF device tree
properties). Then driver is using these details absolutely blindly,
without knowing their meaning.
> or will punt to external code that needs to
> accommodate both board-specific wiring choices and chip-specific
> differences in ballout. (In fact, that particular situation is
> mostly handled by board-specific setup code, not a driver.)
The point is that driver needs non-static GPIO configuration.
In some cases you can't just configure gpio's dedicated functions
at the start-up and use it for the whole driver's lifecycle. Driver
wants to switch between "pin as GPIO" and "pin as dedicated function".
I think GPIO LIB should provide this ability to do so. See below
though.
> > So, down below is the proposal patch: gpio_set_dedicated() routine.
> >
> > There are other options, tough. But I don't like them:
> >
> > ...
> >
> > - Another option?
>
> The way it's usually done: platform-specific code to handle those
> platform-specific pin configuration issues.
There is a problem. Driver could be cross-platform. For example,
we have platforms with "CPM1", "CPM2" and "QE" on-chip gpio
controllers.
One kernel could run on all these platforms (well, not now, but
there are some plans). Mostly, they share drivers (well, actually no,
but there are some plans :-), i.e. differences between CPM and QE
peripherals usually minor enough to write a driver which is able to
work on both.
At the same time, difference between CPM and QE gpio controllers
are drastic, so we can't use "qe_set_dedicated" for both (assuming
that we don't want "if (is_qe) ... else ..." scheme).
So, imagine driver X which is doing:
qe_set_dedicated(pin);
It will be tied to the "QE" platform. But if we'll do
gpio_set_dedicated(pin);
Then underlaying gpio controller would handle that call,
be it CPM or QE. See? GPIO LIB is a simple dispatcher.
And despite special _set_dedicated() function, this driver
actually does _use_ pins as GPIOs. And as dedicated functions.
And as GPIOs. The same pins, but at the different times.
Okay. FHCI is probably not the case of the cross-platform driver,
so for now we can forget about cross-platform usage. Ok, let's
imagine I'll not use GPIO LIB for these "special" pins. But there
are other pins, usual GPIOs. So, to use gpio api and some special
qe_set_dedicated() we want them to play nicely with each other,
locking e.t.c. Will you agree to export "chips" so we can write
GPIO LIB "platform extensions", like
qe_set_dedicated(unsigned int value_that_we_got_from_gpio_request)
{
qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
spin_lock_irqsave(&qe_chip->lock, flags);
...do qe-specific work...
}
?
> > +int gpio_set_dedicated(unsigned gpio, int func)
>
> It's not required that a pin/ball identifier have a one-to-one mapping
> to "gpio" numbers, or that all pins/balls have "gpio" as one of the
> possible functions. So if there were a cross-platform call like this,
> I'd want to see such it reference not a "gpio" but a "pin".
>
> And for that matter, "dedicated" is inaccurate. It's not uncommon
> that even after setting a pin function among the N options available
> for that pin on that platform, it still be usable as a GPIO input.
Yes. But again, there are lots of cases when GPIOs are special
just as IRQs being special. And we still want to use them through
single interface: genirq, gpiolib.
> Of course, the "function" codes are extremely chip-specific ... and
> some platforms would want to include things like pullups, pulldowns,
> and so forth as part of pin configuration.
>
> If you want to pursue this problem, don't couple it to GPIOs.
Um... couple it to what then?..
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* PATCH[1/1] 8xx: resubmit Add clock-frequency parameter to adder875 and mpc885ads dts configurations
From: Bryan O'Donoghue @ 2008-02-03 23:21 UTC (permalink / raw)
To: linuxppc-dev, scottwood
Previous patch submission contained tabs munged into whitespace.
This patch adds the clock-frequency parameter in decimal instead of hex.
Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
---
diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts b/arch/powerpc/boot/dts/adder875-redboot.dts
index 930bfb3..28e9cd3 100644
--- a/arch/powerpc/boot/dts/adder875-redboot.dts
+++ b/arch/powerpc/boot/dts/adder875-redboot.dts
@@ -151,6 +151,7 @@
compatible = "fsl,mpc875-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <50000000>;
reg = <0x9f0 0x10>;
};
diff --git a/arch/powerpc/boot/dts/adder875-uboot.dts b/arch/powerpc/boot/dts/adder875-uboot.dts
index 0197242..54fb60e 100644
--- a/arch/powerpc/boot/dts/adder875-uboot.dts
+++ b/arch/powerpc/boot/dts/adder875-uboot.dts
@@ -150,6 +150,7 @@
compatible = "fsl,mpc875-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <50000000>;
reg = <0x9f0 0x10>;
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts b/arch/powerpc/boot/dts/mpc885ads.dts
index 8848e63..d84a012 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -166,6 +166,7 @@
compatible = "fsl,mpc885-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0>;
reg = <9f0 10>;
};
^ permalink raw reply related
* Re: [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API
From: David Brownell @ 2008-02-03 21:17 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080203170951.GA28024@localhost.localdomain>
On Sunday 03 February 2008, Anton Vorontsov wrote:
> This patch implements support for the GPIO LIB API. Two calls
> unimplemented though: irq_to_gpio and gpio_to_irq.
Also gpio_cansleep().
> +Example of two SOC GPIO banks defined as gpio-controller nodes:
> +
> + qe_pio_a: gpio-controller@1400 {
> + #gpio-cells = <2>;
> + compatible = "fsl,qe-pario-bank";
> + reg = <0x1400 0x18>;
> + gpio-controller;
> + };
> +
> + qe_pio_e: gpio-controller@1460 {
> + #gpio-cells = <2>;
> + compatible = "fsl,qe-pario-bank";
> + reg = <0x1460 0x18>;
> + gpio-controller;
> + };
Let me suggest another example to provide: an I2C GPIO expander
such as a pcf8574 or pca9354 (both eight bit expanders). The SOC
case is probably the easiest to cover.
> +#define ARCH_OF_GPIOS_PER_CHIP 32
Well, ARCH_OF_* is clearly not the now-removed ARCH_GPIOS_PER_CHIP,
but I still suggest moving away from that concept.
> +static inline int gpio_get_value(unsigned int gpio)
> +{
> + return __gpio_get_value(gpio);
> +}
> +
> +static inline void gpio_set_value(unsigned int gpio, int value)
> +{
> + __gpio_set_value(gpio, value);
> +}
static inline int gpio_cansleep(unsigned int gpio)
{
return __gpio_cansleep(gpio);
}
> +static inline int irq_to_gpio(unsigned int irq)
> +{
> + return -ENOSYS;
Minor nit: "-EINVAL" would be better here, since the argument
is constrained to have been returned from gpio_to_irq(), and
as you wrote that call there can be no such values.
^ permalink raw reply
* Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
From: David Brownell @ 2008-02-03 21:22 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080203171006.GD28024@localhost.localdomain>
On Sunday 03 February 2008, Anton Vorontsov wrote:
> This routine sets dedicated functions of the GPIO pin.
>
> ---
>
> Hello David,
>
> Yes, I did read Documentation/gpio.txt's last chapter. :-)
>
> ...that says:
>
> One of the biggest things these conventions omit is pin multiplexing,
> since this is highly chip-specific and nonportable.
>
> Let me counter: "chip-specific" is a weak argument, IMO.
Then focus on "nonportable concepts" instead. :)
Note that "pin" != "GPIO". There are platforms that let one GPIO
be routed to any of several pins/balls; and let a given pin/ball
be multiplexed to support any of several GPIOs. (Annoying because
it's so error prone, but true. I'll call that the "OMAP1" pinmux
issue, since that's where I first ran into it.)
Likewise, not all pins with multiplexed functionality include GPIO
as one of those functions.
So when you assume that a GPIO number can uniquely specify a pin for
use in function multiplexing ... you're stressing a "nonportable"
aspect of this issue.
Ditto when you assume that the multiplexing is on a per-pin basis,
rather than affecting a defined group of pins. (More common, and
less annoying, than the OMAP1 issue.)
(And that doesn't even touch issues like configurable drive strength,
pullups, pulldowns, and so on.)
> Imagine some
> GPIO controller that can't do inputs, or outputs. First one will be
> still suitable for gpio_leds, second one will be suitable for gpio_keys.
The interface easily handles input-only and output-only GPIOs.
Make the relevant gpio_direction_*() methods fail those requests.
> Or... gpio_to_irq/irq_to_gpio. More than chip-specific, isn't it?
> Some GPIO controllers might provide interrupt sources, some might
> not.
Right now there isn't a generic hookup between GPIOs and IRQs;
that's all very platform-specific. For example, maybe it doesn't
use the genirq framework ... and even if it does, there's a huge
hole where "removing irq_chip and its irqs" fits.
It's easy enough for most platforms to arrange that a particular
range of GPIO numbers maps to a particular set of IRQ numbers
through the IRQ chaining mechanism.
> Or let's put it completely different way: IRQs, they are
> chip specific too, some of them can't do EDGE_FALLING or
> EDGE_RISING. But these flags still exists for the IRQs,
> and drivers use them.
Sure; though as a rule, any driver that specifies trigger modes
is platform-specific when it does so. Plus, very few would know
what to do when they learn that the EDGE_FALLING mode they asked
for is not supported by the underlying hardware.
> The same for GPIO pin multiplexing: some drivers aren't aware of
> GPIO multiplexing, but some are.
And if they are aware, that's platform-specific code. So there can
be no issue in requiring use of platform-specific calls for that.
Example, when a given function can come out on either of two pins
(like MMC0.CMD on some chips), and those pins vary between models
of that SOC family ... the driver will either know highly nonportable
details about each chip, or will punt to external code that needs to
accommodate both board-specific wiring choices and chip-specific
differences in ballout. (In fact, that particular situation is
mostly handled by board-specific setup code, not a driver.)
> So, down below is the proposal patch: gpio_set_dedicated() routine.
>
> There are other options, tough. But I don't like them:
>
> ...
>
> - Another option?
The way it's usually done: platform-specific code to handle those
platform-specific pin configuration issues.
> +int gpio_set_dedicated(unsigned gpio, int func)
It's not required that a pin/ball identifier have a one-to-one mapping
to "gpio" numbers, or that all pins/balls have "gpio" as one of the
possible functions. So if there were a cross-platform call like this,
I'd want to see such it reference not a "gpio" but a "pin".
And for that matter, "dedicated" is inaccurate. It's not uncommon
that even after setting a pin function among the N options available
for that pin on that platform, it still be usable as a GPIO input.
Of course, the "function" codes are extremely chip-specific ... and
some platforms would want to include things like pullups, pulldowns,
and so forth as part of pin configuration.
If you want to pursue this problem, don't couple it to GPIOs.
- Dave
> +{
> + struct gpio_chip *chip;
> +
> + might_sleep_if(extra_checks);
> + chip = gpio_to_chip(gpio);
> + if (chip->set_dedicated)
> + return chip->set_dedicated(chip, gpio - chip->base, func);
> +
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(gpio_set_dedicated);
^ 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