Re: [PATCH 4/4] [POWERPC] CPM1: implement GPIO API
Hi Anton, Jochen, I kept your Signed-off-by, though this isn't your original patch. Hope you're okay with it. I also hope you'll test it. ;-) that's OK. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH POWERPC] i2c: adds support for i2c bus on Frescale CPM1/CPM2 controllers
Hi Vitaly, I had an attempt a while ago to do this but haven't had enough time to get it completed, so I am glad to see it finally picked up. There was some sort of discussion that time, you seem to have some of those points addressed but something not, please check: http://lkml.org/lkml/2007/5/8/45 (for instance, cpm_i2c_shutdown() and i2c_cpm_del_bus() are void because they cant' fail) I'll resend a fixed patch. Also, why this was directed to Scott? This is lm-sensors stuff and is Jean Delvare [EMAIL PROTECTED] material.. Scott reviewed this driver last time and i hope to get some further comments from him. But thanks for adding Jean as well. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Yet more patches added to for-2.6.25/master branches
http://patchwork.ozlabs.org/linuxppc/patch?id=15192 ? -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] [POWERPC] CPM1: implement GPIO API
Hi Anton,
I also hope you'll test it. ;-)
yes.
+int cpm_init_par_io(void)
+{
+ struct device_node *np;
+ const u32 *num_ports;
+
+ np = of_find_node_by_name(NULL, fsl,cpm1-pario);
+ if (!np)
+ return -ENOENT;
+
I guess this should be:
np = of_find_compatible_node(NULL, NULL, fsl,cpm1-pario);
With this modification it works OK for me :)
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] [POWERPC] CPM1: implement GPIO API
On Sat, Dec 22, 2007 at 05:08:14PM +0100, Jochen Friedrich wrote:
Hi Anton,
I also hope you'll test it. ;-)
yes.
+int cpm_init_par_io(void)
+{
+ struct device_node *np;
+ const u32 *num_ports;
+
+ np = of_find_node_by_name(NULL, fsl,cpm1-pario);
+ if (!np)
+ return -ENOENT;
+
I guess this should be:
np = of_find_compatible_node(NULL, NULL, fsl,cpm1-pario);
With this modification it works OK for me :)
Fixed, thanks!
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC] powerpc: DBox2 Board Support
This patch adds device tree source, default config and setup code for
DBox2 devices.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/dbox2.dts | 263
arch/powerpc/configs/dbox2_defconfig | 1042 ++
arch/powerpc/platforms/8xx/Kconfig |7 +
arch/powerpc/platforms/8xx/Makefile |1 +
arch/powerpc/platforms/8xx/dbox2.h | 32 +
arch/powerpc/platforms/8xx/dbox2_setup.c | 225 +++
include/asm-powerpc/mpc8xx.h |4 +
7 files changed, 1574 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/dbox2.dts
create mode 100644 arch/powerpc/configs/dbox2_defconfig
create mode 100644 arch/powerpc/platforms/8xx/dbox2.h
create mode 100644 arch/powerpc/platforms/8xx/dbox2_setup.c
diff --git a/arch/powerpc/boot/dts/dbox2.dts b/arch/powerpc/boot/dts/dbox2.dts
new file mode 100644
index 000..8d91510
--- /dev/null
+++ b/arch/powerpc/boot/dts/dbox2.dts
@@ -0,0 +1,263 @@
+/*
+ * DBOX2 Device Tree Source
+ *
+ * Copyright 2007 Jochen Friedrich [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/ {
+ model = Dbox2;
+ compatible = betaresearch,dbox2;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = d#16;
+ i-cache-line-size = d#16;
+ d-cache-size = d#1024;
+ i-cache-size = d#2048;
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ interrupts = f 2; // decrementer interrupt
+ interrupt-parent = PIC;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 200;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = betaresearch,dbox2-localbus;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 800 1800;
+
+ ranges = 0 800 1800;
+
+ [EMAIL PROTECTED] {
+ compatible = c-cube,enx;
+ reg = 0 3400 100 20;
+ interrupts = 2 2;
+ interrupt-parent = PIC;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = c-cube,gtx;
+ reg = 40 3000 0 20;
+ interrupts = 2 2;
+ interrupt-parent = PIC;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = betaresearch,dbox2-fp;
+ interrupts = 4 2;
+ interrupt-parent = PIC;
+ gpios = 0 e;
+ gpio-parent = CPM1_PIO;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = betaresearch,dbox2-fe;
+ interrupts = e 2;
+ interrupt-parent = PIC;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = c-cube,avia;
+ reg = 200 200;
+ interrupts = 8 2;
+ interrupt-parent = PIC;
+ };
+ [EMAIL PROTECTED] {
+ compatible = betaresearch,dbox2-cam;
+ reg = 400 2;
+ interrupts = 6 2;
+ interrupt-parent = PIC;
+ gpios = 1 1c 1 1d 1 1e 1 1f;
+ gpio-parent = CPM1_PIO;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = betaresearch,dbox2-cam;
+ reg = 404 2;
+ interrupts = 6 2;
+ interrupt-parent = PIC;
+ gpios = 1 1c 1 1d 1 1e 1 1f;
+ gpio-parent = CPM1_PIO;
+ };
+
+ [EMAIL PROTECTED] {
+ // Flash also has info about model needed by setup
+ compatible = cfi-flash,
+betaresearch,dbox2-config;
+ reg = 800 80;
+ bank-width = 4;
+ device-width = 1;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = BR
Re: Time for cell code reshuffle?
On Fri, 2007-12-21 at 09:23 -0800, Geoff Levand wrote: It seems platforms/cell should have the shared and/or generic code, and the other stuff moved into a new platform directory, but is it worth the effort? No, platforms/xxx isn't supposed to be shared code. That's was syslib is for. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Time for cell code reshuffle?
On Fri, 2007-12-21 at 20:15 +0100, Arnd Bergmann wrote: It seems platforms/cell should have the shared and/or generic code, and the other stuff moved into a new platform directory, but is it worth the effort? There is very little code in platforms/cell that can not be generic, so I think it's not worth splitting it. The only IBM blade specific files are cbe_cpufreq_pmi.c and parts of setup.c and pervasive.c. Everything else could be shared by about any generic implementation without a hypervisor. Another option is to have: platforms/celleb - platforms/beat and withing platforms/cell, rename blade specific files to something (can't find what, works on CAB too) and add celleb bare metal files. A platform directly doesn't have to deal with one platform. For example, platforms/44x contains a lot of board support. Now, one question is how far can we merge celleb support with the common blade/CAB code... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Time for cell code reshuffle?
On Sun, 23 Dec 2007 07:58:02 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Fri, 2007-12-21 at 09:23 -0800, Geoff Levand wrote: It seems platforms/cell should have the shared and/or generic code, and the other stuff moved into a new platform directory, but is it worth the effort? No, platforms/xxx isn't supposed to be shared code. That's was syslib is for. I think you mean sysdev? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] (Resend part #1) Add the RapidIO support to powerpc architecture with memory mapping support.
Hi,
This is a very large patch. It may be easier to review if it could be
split on some logical way, that is at all possible (I don't know either
way). This is just a quick note about some more trivial things.
On Fri, 21 Dec 2007 17:58:43 +0800 Zhang Wei [EMAIL PROTECTED] wrote:
+struct rio_priv {
+ volatile void __iomem *regs_win;
+ volatile struct rio_atmu_regs __iomem *atmu_regs;
+ volatile struct rio_atmu_regs __iomem *maint_atmu_regs;
+ volatile struct rio_atmu_regs __iomem *dbell_atmu_regs;
+ volatile void __iomem *dbell_win;
+ volatile void __iomem *maint_win;
+ volatile struct rio_msg_regs __iomem *msg_regs;
Paulus has said that any pointer marked __iomem does not need to be
volatile ...
+static int of_cells_get(struct device_node *np, const char *str)
+{
+ struct device_node *tmp = NULL;
+ const int *var = NULL;
These initializations are unnecessary.
+ var = of_get_property(np, str, NULL);
+ tmp = of_get_parent(np);
+
+ while (!var tmp) {
+ var = (int *)of_get_property(tmp, str, NULL);
While I applaud the number of casts remove by this patch, this one is an
unnecessary addition.
+ of_node_put(tmp);
+ tmp = of_get_parent(np);
You should do the above two line in the opposite order. Also do you
really want to keep getting the parent of the same node over and over
(i.e. you never change np)?
+ }
You probably want a final of_node_put(tmp).
+ INFO(Phy type: );
+ switch (phy_type) {
+ case RIO_PHY_SERIAL:
+ printk(serial\n);
+ break;
+ case RIO_PHY_PARALLEL:
+ printk(parallel);
Missing \n
+ port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
+ if (!port) {
+ ERR(Can't alloc memory for 'port'\n);
+ rc = -ENOMEM;
+ goto err;
+ }
port-id = 0;
port-index = 0;
These two could go as you just allocated zeroed memory.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpcLzQ9KmxBG.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
On Fri, 21 Dec 2007 23:23:09 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote:
+static struct of_device_id mpc836x_rdk_ids[] = {
Please make this __initdata.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp6hCLGmk8wd.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [POWERPC] FSL UPM: routines to manage FSL UPMs
On Fri, 21 Dec 2007 23:39:25 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote:
+int fsl_upm_get_for(struct device_node *node, const char *name,
+ struct fsl_upm *upm)
+{
+ int ret;
+ struct device_node *lbus;
+ struct resource lbc_res;
+ ptrdiff_t mxmr_offs;
+
+ lbus = of_get_parent(node);
+ if (!lbus) {
+ pr_err(FSL UPM: can't get parent local bus node\n);
+ return -ENOENT;
+ }
+
+ ret = of_address_to_resource(lbus, 0, lbc_res);
of_node_put(lbus) as of_get_parent() gets a reference.
+static inline void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
+{
+ spin_lock_irqsave(upm_lock, upm_lock_flags);
I may be wrong, but don't we need the flags argument to
spin_lock_irqsave to be on the stack? And the save and restore to be in
the same function?
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpDoSMdZwLeT.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC][NAND] FSL UPM NAND driver
On Fri, 21 Dec 2007 23:41:30 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote:
+static int __devinit upm_chip_probe(struct of_device *ofdev,
+ const struct of_device_id *ofid)
+{
+ struct upm_data *ud;
+ struct resource io_res;
+ const u32 *prop;
+ int ret;
+ int size;
+
+ ud = kzalloc(sizeof(*ud), GFP_KERNEL);
+ if (!ud)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(ofdev-node, 0, io_res);
+ if (ret) {
+ dev_err(ofdev-dev, can't get IO base\n);
+ goto err;
+ }
+
+ prop = of_get_property(ofdev-node, width, size);
+ if (!prop || size != sizeof(u32)) {
+ dev_err(ofdev-dev, can't get chip width\n);
+ goto err;
Here ret is 0, is that the correct return code?
+ ud-rnb_gpio = of_get_gpio(ofdev-node, 0);
+ if (ud-rnb_gpio = 0) {
+ ret = gpio_request(ud-rnb_gpio, ofdev-dev.bus_id);
+ if (ret) {
+ dev_err(ofdev-dev, can't request RNB gpio\n);
+ goto err;
+ }
+ gpio_direction_input(ud-rnb_gpio);
+ } else if (ud-rnb_gpio == -EINVAL) {
+ dev_err(ofdev-dev, specified RNB gpio is invalid\n);
+ goto err;
Again ret is 0 here.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp5WbcxRuGTQ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] PowerPC: implement GPIO API
OF device tree GPIOs bindings are similar to IRQs:
But GPIOs are a very different thing. Most importantly, the number
of a GPIO is completely local to the GPIO controller.
pario0: [EMAIL PROTECTED] {
#gpio-cells = 2;
Your Linux code doesn't actually use this. Why is it needed, anyway?
You should be able to encode a GPIO identifier in a single 32-bit word,
for any possible GPIO controller.
num-ports = 7;
What is this? What is a port? This doesn't belong in a generic GPIO
binding.
[EMAIL PROTECTED] {
gpios = bank pin bank pin bank pin;
gpio-parent = pario0;
Not every GPIO controller has banks. Not every device uses GPIOs
on a single GPIO controller. It is inconvenient to force all bindings
to use the same name (gpios) for its property that shows the GPIOs
(and for it to have only one such property).
So I recommend:
-- Advise (in the generic GPIO binding) people to use
phandle-of-gpio-controller gpio-id-on-that-controller
to refer to a GPIO from some device node;
-- And either:
-- Define (in the generic GPIO binding) that a gpio-id is a single
32-bit cell;
or
-- Define (in the generic GPIO binding) that a gpio-id is a number
of 32-bit cells, and that that number of cells is encoded as a
32-bit
integer in the #gpio-cells property in the device node of the
respective GPIO controller.
(I like the first option better, unless someone can think of some
reasonable
situation where some specific GPIO controller binding needs more than
32 bits
to encode GPIO #).
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] Implement GPIO API embryo
+int __of_parse_gpio_bank_pin(struct device_node *np, int index,
+ int bank_width, int max_bank)
+{
+ int bank;
+ int pin;
+ const u32 *gpios;
+
+ /*
+ * We can get there only if of_get_gpio() succeeded, thus
+ * no need checking for gpios existence.
+ */
+ gpios = of_get_property(np, gpios, NULL);
+ bank = gpios[index * 2];
+ pin = gpios[index * 2 + 1];
If you stick with the #gpio-cells plan, here is where you should use it.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Scott Wood wrote: None of the SOC nodes in any DTS have a compatible entry. Not quite true; ep88xc, mpc8272ads, and pq2fads have them. Ah ok. So what should the compatible entry for 8641 be? compatible = fsl,mpc8641 That looks a lot like what a compatible entry for the CPU should be. How are we differentiating between the compatible cores and compatible SOCs? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Lee Revell wrote: Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of 0x. No prob. But did you see this comment: /* * NOTE: do not use the below macros in new code and do not add new definitions * here. * * Instead, just open-code DMA_BIT_MASK(n) within your driver */ So I guess I should use DMA_BIT_MASK(32) instead. I've personally fixed a heisenbug in an ALSA driver caused by incorrectly typed DMA mask... Can you explain to me what all of this does? Is it okay to use a static u64 variable? Why do so many drivers do it that way? I don't even know if 0x is the right number for my platform. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
Anton Vorontsov wrote: 2. QE SCCs (slow UCCs, used as an UARTs) I a posted a driver that provides this support, I'm just waiting for Kumar to apply it. What revision of the 8360 does this board use? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
Anton Vorontsov wrote:
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,qe;
+ ranges = 0 0xe010 0x0010;
+ reg = 0xe010 0x480;
+ /* filled by u-boot */
+ brg-frequency = 0;
You need bus-frequency here too
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add information on enabling sound on the MPC8641 HPCN
Add a comment to the DTS file for the MPC8641 HPCN describing a wiring change needed to get sound working on this board. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- For a two-line comment, I thought the DTS would be the best place to put this information. arch/powerpc/boot/dts/mpc8641_hpcn.dts |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts index 86fc228..08f78a6 100644 --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts @@ -7,6 +7,9 @@ * 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. + * + * On some revisions of this board, C29 of the Uli M1575 must be connected + * to ground (e.g. ground of resistor R353) in order to enable sound. */ -- 1.5.2.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] PowerPC: implement GPIO API
On Sun, Dec 23, 2007 at 03:47:50AM +0100, Segher Boessenkool wrote:
OF device tree GPIOs bindings are similar to IRQs:
But GPIOs are a very different thing. Most importantly, the number
of a GPIO is completely local to the GPIO controller.
Yes... just as interrupt specifiers are local to their interrupt
domain.
pario0: [EMAIL PROTECTED] {
#gpio-cells = 2;
Your Linux code doesn't actually use this. Why is it needed, anyway?
You should be able to encode a GPIO identifier in a single 32-bit word,
for any possible GPIO controller.
num-ports = 7;
What is this? What is a port? This doesn't belong in a generic GPIO
binding.
[EMAIL PROTECTED] {
gpios = bank pin bank pin bank pin;
gpio-parent = pario0;
Not every GPIO controller has banks.
That's just bad terminology in the example. bank pin means an
arbitrary format gpio specifier.
Not every device uses GPIOs
on a single GPIO controller. It is inconvenient to force all bindings
to use the same name (gpios) for its property that shows the GPIOs
(and for it to have only one such property).
So I recommend:
-- Advise (in the generic GPIO binding) people to use
phandle-of-gpio-controller gpio-id-on-that-controller
to refer to a GPIO from some device node;
Ah, yes, that's a good point. Given the ugly workarounds we need to
deal with devices which have interrupts from multiple domains, we
don't want to copy that limitation to the GPIO scheme.
-- And either:
-- Define (in the generic GPIO binding) that a gpio-id is a single
32-bit cell;
or
-- Define (in the generic GPIO binding) that a gpio-id is a number
of 32-bit cells, and that that number of cells is encoded as a
32-bit
integer in the #gpio-cells property in the device node of the
respective GPIO controller.
This option was the idea; the bank pin information has a format
local to the gpio controller. I agree the terminology needs to change
to gpio specifier by analogy with the interrupt tree, though.
(I like the first option better, unless someone can think of some
reasonable
situation where some specific GPIO controller binding needs more than
32 bits
to encode GPIO #).
I can't think of a situation where it would be strictly speaking
necessary, but I can think of several where it would be more
convenient. GPIO controllers that do have a bank/pin arrangement is
one. GPIO controllers than have a pin number, plus some sort of
direction or level information is another.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] Implement GPIO API embryo
On Sun, Dec 23, 2007 at 03:49:30AM +0100, Segher Boessenkool wrote:
+int __of_parse_gpio_bank_pin(struct device_node *np, int index,
+int bank_width, int max_bank)
+{
+ int bank;
+ int pin;
+ const u32 *gpios;
+
+ /*
+* We can get there only if of_get_gpio() succeeded, thus
+* no need checking for gpios existence.
+*/
+ gpios = of_get_property(np, gpios, NULL);
+ bank = gpios[index * 2];
+ pin = gpios[index * 2 + 1];
If you stick with the #gpio-cells plan, here is where you should use it.
I think part of what's happening here is due to the patch's history.
The bank pin information was always of a format local to the
controller, but originally the size wasn't explicitly stated in the
tree - it was just implicit in the type of gpio controller. I
suggested that #gpio-cells be added, which it has been, but it looks
like the code hasn't been updated to use it everywhere. Obviously a
driver for a particular gpio controller would generally need to assert
that the controller's #gpio-cells has the correct value for this
controller type, after which code like the above would be acceptable.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 17/21] [POWERPC] Base support for 440SPe Katmai eval board
On Fri, 21 Dec 2007 19:48:28 -0600 Josh Boyer [EMAIL PROTECTED] wrote:
On Sat, 22 Dec 2007 11:21:05 +1100
Stephen Rothwell [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 15:39:34 +1100 Benjamin Herrenschmidt [EMAIL
PROTECTED] wrote:
+++ linux-merge/arch/powerpc/platforms/44x/katmai.c 2007-12-21
14:34:33.0 +1100
+
+static struct of_device_id katmai_of_bus[] = {
__initdata (preferably) or const, please.
I'll fix this with a separate commit. The same comment applies for all
the 4xx platforms already in the kernel.
Fine by me.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpcPqkDRkivY.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] Time for cell code reshuffle?
Hi all,
To the question, where what it should go, I'd leave the decision to
Jeremy, but my current idea would be:
arch/powerpc/platforms/cell/spufs - arch/powerpc/spufs
I'd suggest arch/powerpc/sysdev/spufs to keep arch/powerpc clean.
However, this may also depend on the (intended) structure of SPURSEngine
support, which may mean that fs/spufs might be a better place. It would
suck to have to move things twice, so maybe someone from Tosihba could
provide some input? Would the powerpc spufs code be suitable for
SPURSEngine?
As thers have posted earlier, i gthink that arch/powerpc/sysdev/cell
would be good for the generic cell support, then we could have
arch/powerpc/platforms/{cell,ps3,beat} containing only the individual
platform code.
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v2] PS3: Fix printing of os-area magic numbers
On 12/20/2007 08:44 PM, Paul Mackerras wrote:
Geoff Levand writes:
Fix a bug in the printing of the os-area magic numbers which assumed that
magic numbers were zero terminated strings. The magic numbers are
represented
in memory as integers. If the os-area sections are not initialized correctly
they could contained random data that would be printed to the display.
+u8 str[sizeof(h-magic_num) + 1];
+u8 *s, *d;
+
+for(s = h-magic_num, d = str; s h-magic_num + sizeof(h-magic_num);
+s++, d++) {
+*d = isprint(*s) ? *s : '.';
+}
+d[sizeof(h-magic_num)] = 0;
This last statement is wrong, because d has been incremented to point
to the last byte of str already by this stage.
It would be nicer if you pulled out the two instances of the for loop
into a little helper function.
OK.
+for(s = (u8*)db-magic_num, d = str;
Why do you need the (u8*) cast in this case but not the other?
The types are different. The header magic is an array of u8, the db magic
is a u32.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch v3] PS3: Fix printing of os-area magic numbers
Fix a bug in the printing of the os-area magic numbers which assumed that
magic numbers were zero terminated strings. The magic numbers are represented
in memory as integers. If the os-area sections are not initialized correctly
they could contained random data that would be printed to the display.
Also unify the handling of header and db magic numbers and make both
of type array of u8.
CC: Geert Uytterhoeven [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
v2: o handle unprintable chars.
v3: o breakout string dump into helper dump_field()
o unify handling of header and db magic numbers
arch/powerpc/platforms/ps3/os-area.c | 40 ++-
1 file changed, 30 insertions(+), 10 deletions(-)
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -23,6 +23,7 @@
#include linux/workqueue.h
#include linux/fs.h
#include linux/syscalls.h
+#include linux/ctype.h
#include asm/lmb.h
@@ -37,6 +38,8 @@ enum os_area_ldr_format {
HEADER_LDR_FORMAT_GZIP = 1,
};
+#define OS_AREA_HEADER_MAGIC_NUM cell_ext_os_area
+
/**
* struct os_area_header - os area header segment.
* @magic_num: Always 'cell_ext_os_area'.
@@ -114,13 +117,11 @@ struct os_area_params {
u8 _reserved_5[8];
};
-enum {
- OS_AREA_DB_MAGIC_NUM = 0x2d64622dU,
-};
+#define OS_AREA_DB_MAGIC_NUM -db-
/**
* struct os_area_db - Shared flash memory database.
- * @magic_num: Always '-db-' = 0x2d64622d.
+ * @magic_num: Always '-db-'.
* @version: os_area_db format version number.
* @index_64: byte offset of the database id index for 64 bit variables.
* @count_64: number of usable 64 bit index entries
@@ -135,7 +136,7 @@ enum {
*/
struct os_area_db {
- u32 magic_num;
+ u8 magic_num[4];
u16 version;
u16 _reserved_1;
u16 index_64;
@@ -265,12 +266,26 @@ static void __init os_area_get_property(
prop-name);
}
+static void dump_field(char *s, const u8 *f, unsigned int size)
+{
+#if defined(DEBUG)
+ unsigned int i;
+
+ for (i = 0; i size; i++)
+ s[i] = isprint(f[i]) ? f[i] : '.';
+ s[i] = 0;
+#endif
+}
+
#define dump_header(_a) _dump_header(_a, __func__, __LINE__)
static void _dump_header(const struct os_area_header *h, const char *func,
int line)
{
+ char str[sizeof(h-magic_num) + 1];
+
+ dump_field(str, h-magic_num, sizeof(h-magic_num));
pr_debug(%s:%d: h.magic_num: '%s'\n, func, line,
- h-magic_num);
+ str);
pr_debug(%s:%d: h.hdr_version: %u\n, func, line,
h-hdr_version);
pr_debug(%s:%d: h.db_area_offset: %u\n, func, line,
@@ -311,7 +326,8 @@ static void _dump_params(const struct os
static int verify_header(const struct os_area_header *header)
{
- if (memcmp(header-magic_num, cell_ext_os_area, 16)) {
+ if (memcmp(header-magic_num, OS_AREA_HEADER_MAGIC_NUM,
+ sizeof(header-magic_num))) {
pr_debug(%s:%d magic_num failed\n, __func__, __LINE__);
return -1;
}
@@ -331,7 +347,8 @@ static int verify_header(const struct os
static int db_verify(const struct os_area_db *db)
{
- if (db-magic_num != OS_AREA_DB_MAGIC_NUM) {
+ if (memcmp(db-magic_num, OS_AREA_DB_MAGIC_NUM,
+ sizeof(db-magic_num))) {
pr_debug(%s:%d magic_num failed\n, __func__, __LINE__);
return -1;
}
@@ -484,8 +501,11 @@ static int db_get_rtc_diff(const struct
static void _dump_db(const struct os_area_db *db, const char *func,
int line)
{
+ char str[sizeof(db-magic_num) + 1];
+
+ dump_field(str, db-magic_num, sizeof(db-magic_num));
pr_debug(%s:%d: db.magic_num: '%s'\n, func, line,
- (const char*)db-magic_num);
+ str);
pr_debug(%s:%d: db.version: %u\n, func, line,
db-version);
pr_debug(%s:%d: db.index_64:%u\n, func, line,
@@ -516,7 +536,7 @@ static void os_area_db_init(struct os_ar
memset(db, 0, sizeof(struct os_area_db));
- db-magic_num = OS_AREA_DB_MAGIC_NUM;
+ memcpy(db-magic_num, OS_AREA_DB_MAGIC_NUM, sizeof(db-magic_num));
db-version = 1;
db-index_64 = HEADER_SIZE;
db-count_64 = VALUES_64_COUNT;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Yet more patches added to for-2.6.25/master branches
Paulus,
Can you take the crash shutdown hook patches as well for 2.6.25?
http://patchwork.ozlabs.org/linuxppc/patch?person=414id=15546
http://patchwork.ozlabs.org/linuxppc/patch?person=414id=15547
Mikey
In message [EMAIL PROTECTED] you wrote:
Aegis Lin (1):
[POWERPC] spufs: Use separate timer for /proc/spu_loadavg calculation
Andre Detsch (1):
[POWERPC] spufs: DMA Restart after SIGSEGV
Arnd Bergmann (1):
[POWERPC] spufs: block fault handlers in spu_acquire_runnable
Benjamin Herrenschmidt (2):
[POWERPC] Fix for via-pmu based backlight control
[POWERPC] Fix possible NULL deref in ppc32 PCI
Christoph Hellwig (2):
[POWERPC] spufs: add enchanced simple attr macros
[POWERPC] spufs: make state_mutex interruptible
Emil Medve (1):
[POWERPC] Optimize counting distinct entries in the relocation sections
Jeremy Kerr (5):
[POWERPC] spufs: move fault, lscsa_alloc and switch code to spufs modul
e
[POWERPC] spufs: fix incorrect interrupt status clearing in backing mbo
x stat poll
[POWERPC] spufs: use #defines for SPU class [012] exception status
[POWERPC] spufs: rework class 0 and 1 interrupt handling
[POWERPC] spufs: Don't leak kernel stack through an empty {i,m}box_info
read
Julio M. Merino Vidal (1):
[POWERPC] spufs: fix typos in sched.c comments
Luke Browning (4):
[POWERPC] spufs: add backing ops for privcntl register
[POWERPC] spufs: reorganize spu_run_init
[POWERPC] spufs: spu_find_victim may choose wrong victim
[POWERPC] spufs: decouple spu scheduler from spufs_spu_run (asynchronou
s scheduling)
Masato Noguchi (2):
[POWERPC] cell: wrap master run control bit
[POWERPC] spufs: don't set reserved bits in spu interrupt status
Scott Wood (1):
[POWERPC] Implement arch disable/enable irq hooks.
Stephen Rothwell (5):
[POWERPC] Add EHEA and EHCA as modules in the ppc64_defconfig
[POWERPC] The builtin matches for ibmebus.c can be __initdata
[POWERPC] Constify the of_device_id passed to of_platform_bus_probe
[POWERPC] Pointers marked as __iomem do not need to be volatile
[POWERPC] Make non-PCI build work again
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
