dtc: Add python source code output
This commit adds an output format, which produces python
code. When run, the python produces a data structure that
can then be inspected in order to do various things.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
I'm not sure if this is generally useful (or sane) but it was for me so
I thought I'd post it.
I have a dts that I want to use to configure a simulator, and this
seemed like the nicest way to get there. dtc spits out the pythonised
device tree, and then I have a 10 line python script that does the
configuring.
cheers
Makefile.dtc |1 +
dtc.c|3 +
dtc.h|1 +
python.c | 129 ++
4 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 python.c
diff --git a/Makefile.dtc b/Makefile.dtc
index bece49b..92164de 100644
--- a/Makefile.dtc
+++ b/Makefile.dtc
@@ -12,6 +12,7 @@ DTC_SRCS = \
livetree.c \
srcpos.c \
treesource.c \
+ python.c \
util.c
DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.c
diff --git a/dtc.c b/dtc.c
index 84bee2d..496aebf 100644
--- a/dtc.c
+++ b/dtc.c
@@ -92,6 +92,7 @@ static void __attribute__ ((noreturn)) usage(void)
fprintf(stderr, "\t\t\tdts - device tree source text\n");
fprintf(stderr, "\t\t\tdtb - device tree blob\n");
fprintf(stderr, "\t\t\tasm - assembler source\n");
+ fprintf(stderr, "\t\t\tpy - python source\n");
fprintf(stderr, "\t-V \n");
fprintf(stderr, "\t\tBlob version to produce, defaults to %d (relevant
for dtb\n\t\tand asm output only)\n", DEFAULT_FDT_VERSION);
fprintf(stderr, "\t-R \n");
@@ -219,6 +220,8 @@ int main(int argc, char *argv[])
dt_to_blob(outf, bi, outversion);
} else if (streq(outform, "asm")) {
dt_to_asm(outf, bi, outversion);
+ } else if (streq(outform, "py")) {
+ dt_to_python(outf, bi, outversion);
} else if (streq(outform, "null")) {
/* do nothing */
} else {
diff --git a/dtc.h b/dtc.h
index 5cb9f58..45252fe 100644
--- a/dtc.h
+++ b/dtc.h
@@ -237,6 +237,7 @@ void process_checks(int force, struct boot_info *bi);
void dt_to_blob(FILE *f, struct boot_info *bi, int version);
void dt_to_asm(FILE *f, struct boot_info *bi, int version);
+void dt_to_python(FILE *f, struct boot_info *bi, int version);
struct boot_info *dt_from_blob(const char *fname);
diff --git a/python.c b/python.c
new file mode 100644
index 000..8ad0433
--- /dev/null
+++ b/python.c
@@ -0,0 +1,129 @@
+/*
+ * (C) Copyright David Gibson <[EMAIL PROTECTED]>, IBM Corporation. 2005.
+ * (C) Copyright Michael Ellerman, IBM Corporation. 2008.
+ *
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+
+#include "dtc.h"
+#include "srcpos.h"
+
+
+static void write_propval_cells(FILE *f, struct property *prop)
+{
+ cell_t *cp = (cell_t *)prop->val.val;
+ int i;
+
+ fprintf(f, "p = Property('%s', [", prop->name);
+
+ for (i = 0; i < prop->val.len / sizeof(cell_t); i++)
+ fprintf(f, "0x%x, ", fdt32_to_cpu(cp[i]));
+
+ fprintf(f, "])\n");
+}
+
+static int isstring(char c)
+{
+ return (isprint(c)
+ || (c == '\0')
+ || strchr("\a\b\t\n\v\f\r", c));
+}
+
+static void write_property(FILE *f, struct property *prop)
+{
+ const char *p = prop->val.val;
+ int i, strtype, len = prop->val.len;
+
+ if (len == 0) {
+ fprintf(f, "p = Property('%s', None)\n", prop->name);
+ goto out;
+ }
+
+ strtype = 1;
+ for (i = 0; i < len; i++) {
+ if (!isstring(p[i])) {
+ strtype = 0;
+ break;
+ }
+ }
+
+ if (strtype)
+ fprintf(f, "p = Property('%s', '%s')\n", prop->name,
+ prop->val.val);
+ else if (len == 4)
+ fprintf(f, "p = Property('%s', 0x%x)\n", prop->name,
+ fdt32_to_cpu(*(const cell_t *)p));
+ else
+ write_propval_cells(f, prop);
+
+out:
+ fprintf(f, "n.properties.append(p)\n");
+}
+
+static void write_tree
Re: [PATCH V4] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
This patch is a workaround for bug #364 found in the MPC52xx processor.
The errata document can be found under
http://www.freescale.com/files/32bit/doc/errata/MPC5200E.pdf?fpsp=1&WT_TYPE=Errata&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
When a device with a low baudrate is connected to the serial port, but
the processor "listens" on a higher baudrate, it might falsely receive
breaks from the controller. During a break, the serial controller may
not be reset. The appended patch provides a workaround for that
situation by lowering the baudrate without resetting the controller and
waiting until no break is received anymore.
This is v4 if the patch, just reformatted to fit the linux kernel coding
style without functional changes.
Wolfram Sang schrieb:
Hi René,
On Tue, Nov 04, 2008 at 08:40:09PM +0100, René Bürgel wrote
But there's still one thing, that bothers me a bit - if there is REALLY
a break on the line, closing the driver may take until it's gone. I
don't know whether this is really satisfying, but i think it's better
than the alternative: no serial connection until the next reboot.
I think we should CC linux-serial to get some opinions about this. At
least, if it stays like this, it should be mentioned in the source.
What's the opinion from the linux-serial folks about this issue?
--
René Bürgel
Software Engineer
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 19
Fax: 03 72 06/ 88 73 - 60
E-Mail: [EMAIL PROTECTED]
Internet: www.unicontrol.de
Unicontrol Systemtechnik GmbH
Geschäftsführer: Dipl.-Ing. Siegfried Heinze
Sitz der Gesellschaft: Frankenberg
Registergericht: Amtsgericht Chemnitz, HRB 15 475
Wichtiger Hinweis: Diese E-Mail und etwaige Anlagen können Betriebs- und Geschäftsgeheimnisse, dem Anwaltsgeheimnis unterliegende oder sonstige vertrauliche Informationen
enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen der Status dieser E-Mail bekannt. Bitte benachrichtigen Sie uns in diesem Falle sofort durch
Antwort-Mail und löschen Sie diese E-Mail nebst etwaigen Anlagen aus Ihrem System. Ebenso dürfen Sie diese E-Mail oder ihre Anlagen nicht kopieren oder an Dritte
weitergeben. Vielen Dank!
Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure.
If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this e-mail and any attachment from your
system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank
you.
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 6117d3d..ae539b5 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -496,6 +496,74 @@ mpc52xx_uart_break_ctl(struct uart_port *port, int ctl)
spin_unlock_irqrestore(&port->lock, flags);
}
+/*
+ * This is a workaround for processor bug #364
+ * described in MPC5200 (L25R) Errata.
+ * The bug is still present in MPC5200B,
+ * but currently not listed in its errata sheet.
+ *
+ * The workaround resets the baudrate to the slowest possible,
+ * waits for a stable state and resets break state repeatedly if necessary.
+ * Optionally it can release the lock while waiting.
+ *
+ * That baudrate is roughly port->uartclk / (1000 * 1000)
+ * The minimum wait time for the first try has to include
+ * the time to wait for stop-bits and a character.
+ * We wait for 2 chars to be sure.
+ * Consecutive waits must just receive one character.
+ */
+
+#ifdef CONFIG_PPC_MPC52xx
+static void reset_errors_and_wait(struct uart_port *port, bool unlock,
+ unsigned long flags, unsigned int delay)
+{
+ struct mpc52xx_psc __iomem *psc = PSC(port);
+ out_8(&psc->command, MPC52xx_PSC_RST_ERR_STAT);
+ if (unlock) {
+ disable_irq(port->irq);
+ spin_unlock_irqrestore(&port->lock, flags);
+ }
+ mdelay(delay);
+ if (unlock) {
+ spin_lock_irqsave(&port->lock, flags);
+ enable_irq(port->irq);
+ }
+}
+#endif
+
+static void mpc52xx_uart_reset_rx(struct uart_port *port, bool unlock,
+ unsigned long flags)
+{
+#ifdef CONFIG_PPC_MPC52xx
+ struct mpc52xx_psc __iomem *psc = PSC(port);
+
+ /*
+* One character on the serial port may consist of up to 12 bits.
+* So the time to receive one char is
+* 12 / (port->uartclk / (1000 * 1000) ) * 1000,
+* (bits) (MHz -> Hz) (s -> ms)
+*/
+ unsigned int one_char_receive_duration =
+ (12 * 1000) / (port->uartclk / (1000 * 1000));
+
+ /*
+* CT=0x sets the serial line to the
Re: [PATCH] Fix msr check in compat_sys_swapcontext
Paul Mackerras <[EMAIL PROTECTED]> writes: > we need to use get_user, not __get_user, since we haven't done an > access_ok() check on the address. The address is always ok since its a compat pointer, see do_setcontext. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix msr check in compat_sys_swapcontext
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Andreas Schwab writes:
>
>> Paul Mackerras <[EMAIL PROTECTED]> writes:
>>
>> > we need to use get_user, not __get_user, since we haven't done an
>> > access_ok() check on the address.
>>
>> The address is always ok since its a compat pointer, see do_setcontext.
>
> OK, since it's inside a CONFIG_PPC64 block. I'll add a paragraph to
> the patch description pointing that out.
How about this:
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index a6a4310..b13abf3 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -941,9 +941,21 @@ long sys_swapcontext(struct ucontext __user *old_ctx,
#ifdef CONFIG_PPC64
unsigned long new_msr = 0;
- if (new_ctx &&
- get_user(new_msr, &new_ctx->uc_mcontext.mc_gregs[PT_MSR]))
- return -EFAULT;
+ if (new_ctx) {
+ struct mcontext __user *mcp;
+ u32 cmcp;
+
+ /*
+* Get pointer to the real mcontext. No need for
+* access_ok since we are dealing with compat
+* pointers.
+*/
+ if (__get_user(cmcp, &new_ctx->uc_regs))
+ return -EFAULT;
+ mcp = (struct mcontext __user *)(u64)cmcp;
+ if (__get_user(new_msr, &mcp->mc_gregs[PT_MSR]))
+ return -EFAULT;
+ }
/*
* Check that the context is not smaller than the original
* size (with VMX but without VSX)
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Basic GPIO support for GE Fanuc SBC610
Basic support for the GPIO available on the SBC610 VPX Single Board Computer
from GE Fanuc (PowerPC MPC8641D).
This patch adds basic support for the GPIO in the devices I/O FPGA, the GPIO
functionality is exposed through the AFIX pins on the backplane, unless used
by an AFIX card.
This code currently does not support switching between totem-pole and
open-drain outputs (when used as outputs, GPIOs default to totem-pole).
The interrupt capabilites of the GPIO lines is also not currently supported.
Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/gef_sbc610.dts |6 +
arch/powerpc/platforms/86xx/Kconfig|2
arch/powerpc/platforms/86xx/Makefile |3 -
arch/powerpc/platforms/86xx/gef_gpio.c | 185
arch/powerpc/platforms/86xx/gef_gpio.h | 10 ++
5 files changed, 205 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6ed6083..963dd5b 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -98,6 +98,12 @@
interrupt-parent = <&mpic>;
};
+ gef_gpio: [EMAIL PROTECTED],14000 {
+ #gpio-cells = <1>;
+ compatible = "gef,fpga-gpio";
+ reg = <0x7 0x14000 0x24>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 77dd797..8e56939 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -34,6 +34,8 @@ config MPC8610_HPCD
config GEF_SBC610
bool "GE Fanuc SBC610"
select DEFAULT_UIMAGE
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
help
This option enables support for GE Fanuc's SBC610.
diff --git a/arch/powerpc/platforms/86xx/Makefile
b/arch/powerpc/platforms/86xx/Makefile
index 4a56ff6..31e540c 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_SMP) += mpc86xx_smp.o
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
obj-$(CONFIG_SBC8641D) += sbc8641d.o
obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
-obj-$(CONFIG_GEF_SBC610) += gef_sbc610.o gef_pic.o
+gef-gpio-$(CONFIG_GPIOLIB) += gef_gpio.o
+obj-$(CONFIG_GEF_SBC610) += gef_sbc610.o gef_pic.o $(gef-gpio-y)
diff --git a/arch/powerpc/platforms/86xx/gef_gpio.c
b/arch/powerpc/platforms/86xx/gef_gpio.c
new file mode 100644
index 000..2c935b6
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/gef_gpio.c
@@ -0,0 +1,185 @@
+/*
+ * Driver for GE Fanuc's FPGA based GPIO pins
+ *
+ * Author: Martyn Welch <[EMAIL PROTECTED]>
+ *
+ * 2008 (c) GE Fanuc Intelligent Platforms Embedded Systems, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/* TODO
+ *
+ * Configuration of output modes (totem-pole/open-drain)
+ * Interrupt configuration - interrupts are always generated the FPGA relies on
+ * the I/O interrupt controllers mask to stop them propergating
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "gef_gpio.h"
+
+#define DEBUG
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(fmt...) do { printk(KERN_DEBUG "gef_gpio: " fmt); } while (0)
+#else
+#define DBG(fmt...) do { } while (0)
+#endif
+
+#define NUM_GPIO 19
+
+/* Let's create a common inlined function to commonise the code and so we don't
+ * have to resolve the chip structure multiple times.
+ */
+inline void _gef_gpio_set(void __iomem *reg, unsigned int offset, int value)
+{
+ unsigned int data;
+
+ data = ioread32be(reg);
+ /* value: 0=low; 1=high */
+ DBG("Output Set, Pre:0x%8.8x, ", data);
+ if (value & 0x1) {
+ data = data | (0x1 << offset);
+ DBG("OR Mask:0x%8.8x, Post:0x%8.8x\n", (0x1 << offset), data);
+ } else {
+ data = data & ~(0x1 << offset);
+ DBG("AND Mask:0x%8.8x, Post:0x%8.8x\n", ~(0x1 << offset), data);
+ }
+ iowrite32be(data, reg);
+}
+
+
+static int gef_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+ struct of_mm_gpio_chip *mmchip;
+ unsigned int data;
+
+ /* Find memory mapped gpio chip structure from gpio_chip, this contains
+* the mapped location of the GPIO controller */
+ mmchip = to_of_mm_gpio_chip(chip);
+
+ data = ioread32be(mmchip->regs + GEF_GPIO_DIRECT);
+ DBG("Direction In, Pre:0x%8.8x, ", data);
+ data = data | (0x1 << offset);
+ DBG("OR Mask:0x%8.8x, Post:0x%8.8x\n", (0x1 << offset), data);
+ iowrite32be(data, mmchip->regs + GEF_GPIO_DI
[PATCH v2] powerpc: Basic GPIO support for GE Fanuc SBC610
Basic support for the GPIO available on the SBC610 VPX Single Board Computer
from GE Fanuc (PowerPC MPC8641D).
This patch adds basic support for the GPIO in the devices I/O FPGA, the GPIO
functionality is exposed through the AFIX pins on the backplane, unless used
by an AFIX card.
This code currently does not support switching between totem-pole and
open-drain outputs (when used as outputs, GPIOs default to totem-pole).
The interrupt capabilites of the GPIO lines is also not currently supported.
Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---
Sorry for the quick jump to version 2 - A stray "i" crept in to the previous
version as I was editing the email for submission.
arch/powerpc/boot/dts/gef_sbc610.dts |6 +
arch/powerpc/platforms/86xx/Kconfig|2
arch/powerpc/platforms/86xx/Makefile |3 -
arch/powerpc/platforms/86xx/gef_gpio.c | 185
arch/powerpc/platforms/86xx/gef_gpio.h | 10 ++
5 files changed, 205 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6ed6083..963dd5b 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -98,6 +98,12 @@
interrupt-parent = <&mpic>;
};
+ gef_gpio: [EMAIL PROTECTED],14000 {
+ #gpio-cells = <1>;
+ compatible = "gef,fpga-gpio";
+ reg = <0x7 0x14000 0x24>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 77dd797..8e56939 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -34,6 +34,8 @@ config MPC8610_HPCD
config GEF_SBC610
bool "GE Fanuc SBC610"
select DEFAULT_UIMAGE
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
help
This option enables support for GE Fanuc's SBC610.
diff --git a/arch/powerpc/platforms/86xx/Makefile
b/arch/powerpc/platforms/86xx/Makefile
index 4a56ff6..31e540c 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_SMP) += mpc86xx_smp.o
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
obj-$(CONFIG_SBC8641D) += sbc8641d.o
obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
-obj-$(CONFIG_GEF_SBC610) += gef_sbc610.o gef_pic.o
+gef-gpio-$(CONFIG_GPIOLIB) += gef_gpio.o
+obj-$(CONFIG_GEF_SBC610) += gef_sbc610.o gef_pic.o $(gef-gpio-y)
diff --git a/arch/powerpc/platforms/86xx/gef_gpio.c
b/arch/powerpc/platforms/86xx/gef_gpio.c
new file mode 100644
index 000..aafff1b
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/gef_gpio.c
@@ -0,0 +1,185 @@
+/*
+ * Driver for GE Fanuc's FPGA based GPIO pins
+ *
+ * Author: Martyn Welch <[EMAIL PROTECTED]>
+ *
+ * 2008 (c) GE Fanuc Intelligent Platforms Embedded Systems, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/* TODO
+ *
+ * Configuration of output modes (totem-pole/open-drain)
+ * Interrupt configuration - interrupts are always generated the FPGA relies on
+ * the I/O interrupt controllers mask to stop them propergating
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "gef_gpio.h"
+
+#define DEBUG
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(fmt...) do { printk(KERN_DEBUG "gef_gpio: " fmt); } while (0)
+#else
+#define DBG(fmt...) do { } while (0)
+#endif
+
+#define NUM_GPIO 19
+
+/* Let's create a common inlined function to commonise the code and so we don't
+ * have to resolve the chip structure multiple times.
+ */
+inline void _gef_gpio_set(void __iomem *reg, unsigned int offset, int value)
+{
+ unsigned int data;
+
+ data = ioread32be(reg);
+ /* value: 0=low; 1=high */
+ DBG("Output Set, Pre:0x%8.8x, ", data);
+ if (value & 0x1) {
+ data = data | (0x1 << offset);
+ DBG("OR Mask:0x%8.8x, Post:0x%8.8x\n", (0x1 << offset), data);
+ } else {
+ data = data & ~(0x1 << offset);
+ DBG("AND Mask:0x%8.8x, Post:0x%8.8x\n", ~(0x1 << offset), data);
+ }
+ iowrite32be(data, reg);
+}
+
+
+static int gef_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+ struct of_mm_gpio_chip *mmchip;
+ unsigned int data;
+
+ /* Find memory mapped gpio chip structure from gpio_chip, this contains
+* the mapped location of the GPIO controller */
+ mmchip = to_of_mm_gpio_chip(chip);
+
+ data = ioread32be(mmchip->regs + GEF_GPIO_DIRECT);
+ DBG("Direction In, Pre:0x%8.8x, ", data);
+ data = data | (0x1 << of
Patch to fix problem? was: PCI Express between MPC8572 & PLX8616
Sorry for such a wide query...but I did some searching of the linux trees... and I am at a loss to find what the below email refers to in terms of a fix for pci expressand I am having a hard time finding it in all of the commits? any pointers to the right tree and/or the specific fix would be greatly appreciated! ==> a friend respond to the original subjectline.. > Has anybody every used this chip in their design?? No, but I have 2 other PLX PCI-E switches that would not behave. > FYI, we have a custom board that I am bringing up right now > that has a > MPC8572E that has its PCIE1 connected to the subject line PLX8616 > PCI Express Switch... So you have the cpu as root-complex attached to the PLX upstream port and the PLX downstream ports going somewhere else. > As part of the boot, we successfully discover config the > internal bridge > (its in root complex mode) inside the MPC8572E, and from 'many' > view points (hardware LED's and status registers) - there seems to > be 4 lanes in between the Switch and the CPU... Are you doing this by using a PCI-E analyzer, or by what you see U-boot doing. BTW, in my case, the LEDs always worked but nothing else did. So the lane good LEDs would light up, but the whole interface was hopelessly broken. > But, at the first external config cycle - something goes very wrong - > the response (or lack of that è 0x) is returned, as well as > and the associated CCSR's PCIE1 interface is completely > reset (we implement and attempt to recover this interface > via Freescale's CPU Errata #4) - but beyond that - it > never recovers and re-sync's these 4 lanes up By external configuration cycle, do you mean when the cpu goes out to configure the items on the secondary bus side of the plx switch? or the secondary side of the internal pci-e bridge. In either case, this could be the same problem I just went through. A workaround was recently (like maybe 2 weeks ago) put into the kernel to address this on powerpc systems, so you might try pulling down a recent kernel via git and see if that helps. I would have copied the mailing list, but for some reason it is rejecting my mail at the moment. I can say that I tested this fix and it definately fixed all the secondary ports on my system. I used a pci-e analyzer so it was a little easier to see what was going on, but in the end it was clear that there was something wrong in the powerpc ports, b/c I did not see this with the same parts on an x86 host. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix msr check in compat_sys_swapcontext
Andreas Schwab writes: > Paul Mackerras <[EMAIL PROTECTED]> writes: > > > we need to use get_user, not __get_user, since we haven't done an > > access_ok() check on the address. > > The address is always ok since its a compat pointer, see do_setcontext. OK, since it's inside a CONFIG_PPC64 block. I'll add a paragraph to the patch description pointing that out. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Add flexibility for I2C clock frequency and filter.
Mike Ditto schrieb: > This patch adds the ability to enable the digital filter in the device > tree (with the "clock-filter" boolean property) and automates the > predivider selection according to the clock-frequency and clock-filter > properties. This allows use of a wider range of I2C bus frequencies. > > Signed-off-by: Mike Ditto <[EMAIL PROTECTED]> Acked-by: Jochen Friedrich <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Basic GPIO support for GE Fanuc SBC610
On Thu, Nov 06, 2008 at 12:10:33PM +, Martyn Welch wrote:
> Basic support for the GPIO available on the SBC610 VPX Single Board Computer
> from GE Fanuc (PowerPC MPC8641D).
>
> This patch adds basic support for the GPIO in the devices I/O FPGA, the GPIO
> functionality is exposed through the AFIX pins on the backplane, unless used
> by an AFIX card.
>
> This code currently does not support switching between totem-pole and
> open-drain outputs (when used as outputs, GPIOs default to totem-pole).
> The interrupt capabilites of the GPIO lines is also not currently supported.
>
> Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
> ---
Mostly looks good. Few comments below.
> Sorry for the quick jump to version 2 - A stray "i" crept in to the previous
> version as I was editing the email for submission.
>
> arch/powerpc/boot/dts/gef_sbc610.dts |6 +
> arch/powerpc/platforms/86xx/Kconfig|2
> arch/powerpc/platforms/86xx/Makefile |3 -
> arch/powerpc/platforms/86xx/gef_gpio.c | 185
>
> arch/powerpc/platforms/86xx/gef_gpio.h | 10 ++
> 5 files changed, 205 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
> b/arch/powerpc/boot/dts/gef_sbc610.dts
> index 6ed6083..963dd5b 100644
> --- a/arch/powerpc/boot/dts/gef_sbc610.dts
> +++ b/arch/powerpc/boot/dts/gef_sbc610.dts
> @@ -98,6 +98,12 @@
> interrupt-parent = <&mpic>;
>
> };
> + gef_gpio: [EMAIL PROTECTED],14000 {
> + #gpio-cells = <1>;
Don't use one-cell scheme. Two cells are convenient for GPIO flags
(active-low GPIO, for example).
> + compatible = "gef,fpga-gpio";
> + reg = <0x7 0x14000 0x24>;
> + gpio-controller;
> + };
> };
>
> [EMAIL PROTECTED] {
> diff --git a/arch/powerpc/platforms/86xx/Kconfig
> b/arch/powerpc/platforms/86xx/Kconfig
> index 77dd797..8e56939 100644
> --- a/arch/powerpc/platforms/86xx/Kconfig
> +++ b/arch/powerpc/platforms/86xx/Kconfig
> @@ -34,6 +34,8 @@ config MPC8610_HPCD
> config GEF_SBC610
> bool "GE Fanuc SBC610"
> select DEFAULT_UIMAGE
> + select GENERIC_GPIO
> + select ARCH_REQUIRE_GPIOLIB
> select HAS_RAPIDIO
> help
> This option enables support for GE Fanuc's SBC610.
> diff --git a/arch/powerpc/platforms/86xx/Makefile
> b/arch/powerpc/platforms/86xx/Makefile
> index 4a56ff6..31e540c 100644
> --- a/arch/powerpc/platforms/86xx/Makefile
> +++ b/arch/powerpc/platforms/86xx/Makefile
> @@ -7,4 +7,5 @@ obj-$(CONFIG_SMP) += mpc86xx_smp.o
> obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
> obj-$(CONFIG_SBC8641D) += sbc8641d.o
> obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
> -obj-$(CONFIG_GEF_SBC610) += gef_sbc610.o gef_pic.o
> +gef-gpio-$(CONFIG_GPIOLIB) += gef_gpio.o
> +obj-$(CONFIG_GEF_SBC610) += gef_sbc610.o gef_pic.o $(gef-gpio-y)
> diff --git a/arch/powerpc/platforms/86xx/gef_gpio.c
> b/arch/powerpc/platforms/86xx/gef_gpio.c
> new file mode 100644
> index 000..aafff1b
> --- /dev/null
> +++ b/arch/powerpc/platforms/86xx/gef_gpio.c
> @@ -0,0 +1,185 @@
> +/*
> + * Driver for GE Fanuc's FPGA based GPIO pins
> + *
> + * Author: Martyn Welch <[EMAIL PROTECTED]>
> + *
> + * 2008 (c) GE Fanuc Intelligent Platforms Embedded Systems, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/* TODO
> + *
> + * Configuration of output modes (totem-pole/open-drain)
> + * Interrupt configuration - interrupts are always generated the FPGA relies
> on
> + * the I/O interrupt controllers mask to stop them propergating
> + */
#include for __iomem
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "gef_gpio.h"
> +
> +#define DEBUG
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(fmt...) do { printk(KERN_DEBUG "gef_gpio: " fmt); } while (0)
> +#else
> +#define DBG(fmt...) do { } while (0)
> +#endif
There is pr_debug() function exists.
> +#define NUM_GPIO 19
> +
> +/* Let's create a common inlined function to commonise the code and so we
> don't
> + * have to resolve the chip structure multiple times.
> + */
> +inline void _gef_gpio_set(void __iomem *reg, unsigned int offset, int value)
'static' missing. + No need for inline, gcc can decide if inlined
function better or not.
> +{
> + unsigned int data;
> +
> + data = ioread32be(reg);
> + /* value: 0=low; 1=high */
> + DBG("Output Set, Pre:0x%8.8x, ", data);
> + if (value & 0x1) {
> + data = data | (0x1 << offset);
> + DBG("OR Mask:0x%8.8x, Post:0x%8.8x\n", (0x1 << offset), data);
> + } else {
> + data = data & ~(0x1 << offset);
> + DBG("AND Mask:0x%8.
Re: [PATCH v2] powerpc: Basic GPIO support for GE Fanuc SBC610
On Thu, Nov 06, 2008 at 06:17:23PM +0300, Anton Vorontsov wrote: [...] > There is point in doing the of_platform_driver for this GPIO Please read as 'There is no point..' ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3] powerpc: Fix Book-E watchdog timer interval setting
Matthias Fuchs wrote: > This patch fixes the setting of the Book-E watchdog timer interval setup > on initialization and by ioctl(). > > On initialization the period bits have to be masked before setting > a new period. > > In WDIOC_SETTIMEOUT ioctl we have to use the correct mask. > > Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]> Acked-by: Timur Tabi <[EMAIL PROTECTED]> -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
Matt Sealey schrieb:
René Bürgel wrote:
But as the serial driver is also used for the MPC5121, we may have to
distinguish anyway. Does anyone have the possibility to test if the
bug in still present on MPC5121?
Tell us what to do to get it to occur and what we're looking for and we
have a bunch of boards at Genesi, someone will find the time to test it
(if not them, then me :)
Right now I'm having a hell of a time getting a 2.6.27.x kernel running
on it though, some driver support is still missing from mainline making
it just that little bit extra frustrating to work with.. (if you're
using the system over a serial console, how are you supposed to test
serial port operation? USB doesn't work in >2.6.24 so I guess I have to
hope netconsole works :)
Hi, Matt
Thanks for your offer. I'm using telnet to debug the serial port. I'll
append a testcase for you, which is just opening a serial port, trying
to receive for a second, switching the baudrate and doing it receiving
again. Just run it and connect a slow device to the serial port sending
data continuously. I'm using a GPS mouse here, working at 9600baud. The
higher the rate you are receiving at, the higher the chance to falsely
receive a break. When the serial port is switch off in that moment (the
filedescriptor is closed), the serial won't receive anything from that
time, if the bug is present
Alternativly, if you have more control over your serial device, just
send breaks continuously, open and close the serial port. Open it again
and receiving data fails, if the bug is present.
Just btw: if USB is not working, did you miss the initialisation of the
USB-controller in your bootloader? I had similar problems getting from
2.6.22 to 2.6.25 with my mpc5200.
--
René Bürgel
Software Engineer
Unicontrol Systemtechnik GmbH
OT Dittersbach
Sachsenburger Weg 34
09669 Frankenberg
Tel.: 03 72 06/ 88 73 - 19
Fax: 03 72 06/ 88 73 - 60
E-Mail: [EMAIL PROTECTED]
Internet: www.unicontrol.de
Unicontrol Systemtechnik GmbH
Geschäftsführer: Dipl.-Ing. Siegfried Heinze
Sitz der Gesellschaft: Frankenberg
Registergericht: Amtsgericht Chemnitz, HRB 15 475
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define DEV_UART "/dev/tts/0"
void initUart(int uart, struct pollfd* pfd, speed_t speed, struct
serial_icounter_struct* last_icounter)
{
struct termios options;
tcgetattr( uart, &options );
cfmakeraw( &options );
cfsetispeed( &options, speed );
cfsetospeed( &options, speed );
options.c_cflag &= ~CSIZE;//clear charsize-bits
options.c_cflag |= CS8;
options.c_iflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_iflag &= ~IGNPAR; // do not ignore framing and parity errors
tcsetattr( uart, TCSANOW, &options );
tcflush( uart, TCIOFLUSH );
//read garbage
if (poll( pfd, 1, 1000 ) > 0)
{
usleep( 500 /*ms*/ * 1000 /*us*/ );
unsigned char buffer[16384 + 1];
read( uart, buffer, sizeof( buffer ) );
ioctl( uart, TIOCGICOUNT, last_icounter );
}
}
void readUart(int uart, struct pollfd* pfd, struct serial_icounter_struct*
last_icounter)
{
int retval = poll( pfd, 1, 1000 );
if ( retval > 0 )
{
if ( pfd->revents & POLLIN )
{
// etwas warten, damit nicht ständig einzelne Zeichen von der Seriellen
geholt werden
// TODO: für z.B. A/D-Probe ggf. reduzieren (Template-Argument?)
usleep( 2 /*ms*/ * 1000 /*us*/ );
unsigned buffer[16384 + 1];
int countBytes = read( uart, buffer, sizeof( buffer ) );
printf("received something: ");
{
int i = 0;
for (; i < countBytes; ++i)
printf("%x ", (unsigned short) buffer[i]);
}
printf("\n");
struct serial_icounter_struct icounter;
ioctl( uart, TIOCGICOUNT, &icounter );
if (icounter.brk != last_icounter->brk) printf("Break ");
if (icounter.frame != last_icounter->frame ) printf("Framing Error ");
if (icounter.parity != last_icounter->parity ) printf("Parity Error ");
if (icounter.overrun != last_icounter->overrun) printf("Overrun");
printf("\n");
*last_icounter = icounter;
}
else
{
printf("received nothing\n");
}
}
else
{
int error = errno;
printf("error while waiting for data on serial port: %s\n", strerror(
error ) );
}
}
speed_t getNextSpeed(speed_t curSpeed)
{
switch (curSpeed)
{
case B4800: return B9600;
case B9600: return B19200;
case B19200: return B38400;
case B38400: return B57600;
case B57600: return B115200;
case B115200: return B4800;
}
return B4800;
}
int main()
{
struct pollfd pfd;
pfd.events = POLLIN;
speed_t cur_speed=B4800;
struct serial_icounter_struct last_icounter;
while(1)
{
pfd.fd = open( DEV_UART, O_RDWR | O_NONBLOCK );
Re: Passing I2C platform_data from device tree to i2c driver
On Mon, Nov 03, 2008 at 05:54:46PM -0600, Nate Case wrote: > Of course, I could put some code in my board specific file to parse the > device tree properties and set pdata accordingly, but this hardly seems > ideal. After all, the device tree bindings -> pdata translation itself > does not have to be board-specific. > > Basically, I think we need to have some common code somewhere that does > the task of populating platform_data for a specific I2C chip based on a > device tree node -- similarly to how we register the I2C devices > already. Is anyone working on this? Did anyone have anything else in > mind? It should be fairly straightforward to add an optional function pointer to the i2c device table that turns the device tree properties into platform data. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] irq: Maintain user set affinity
On Tue, 4 Nov 2008 10:31:05 -0600 (CST) Kumar Gala <[EMAIL PROTECTED]> wrote: > >From 819ad3ed4660f4238e053728a8b5aa93d22b13d7 Mon Sep 17 00:00:00 2001 > From: Kumar Gala <[EMAIL PROTECTED]> > Date: Tue, 4 Nov 2008 10:13:53 -0600 > Subject: [PATCH 1/1] irq: Maintain user set affinity > > This addresses a regression in that if a user specified an affinity > for an interrupt that affinity information would get reset between > a request_irq(), free_irq() and request_irq() for the same irq. > > On example of this is bringing up an ethernet interface, taking > it down and bringing it back up again. > > Instead of always using the irq_default_affinity we use the > previous setting of the IRQs affinity with the assumption that > at boot the IRQs affinity will be set to irq_default_affinity. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > kernel/irq/manage.c |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c > index c498a1b..ea7d11b 100644 > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -115,9 +115,12 @@ int irq_select_affinity(unsigned int irq) > if (!irq_can_set_affinity(irq)) > return 0; > > - cpus_and(mask, cpu_online_map, irq_default_affinity); > - > desc = irq_to_desc(irq); > + > + mask = desc->affinity; > + > + cpus_and(mask, cpu_online_map, mask); > + > desc->affinity = mask; > desc->chip->set_affinity(irq, mask); > Are you able to identify when this regression occurred? It isn't immediately obvious to me. If the regression is present in 2.6.27 or earlier, do you think we should backport the fix? If so, a different patch would be needed due to the presence of commit 08678b0841267c1d00d771fe01548d86043d065e Author: Yinghai Lu <[EMAIL PROTECTED]> Date: Tue Aug 19 20:50:05 2008 -0700 generic: sparse irqs: use irq_desc() together with dyn_array, instead of irq_desc[] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
René Bürgel wrote: Matt Sealey schrieb: Alternativly, if you have more control over your serial device, just send breaks continuously, open and close the serial port. Open it again and receiving data fails, if the bug is present. Well I have a couple systems I can write data from here, a little app to send data really isn't that hard to come up with. Just btw: if USB is not working, did you miss the initialisation of the USB-controller in your bootloader? I had similar problems getting from 2.6.22 to 2.6.25 with my mpc5200. Actually it's more to do with the fact that the patches to get USB working (along with On The Go support) in the LTIB are quite intrusive, and written for 2.6.24 - since then the USB cores seem to have been reshuffled so it is far from a clean patch. Someday I will get bored and port it to 2.6.28 :) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] irq: Maintain user set affinity
On Nov 6, 2008, at 3:35 PM, Andrew Morton wrote: On Tue, 4 Nov 2008 10:31:05 -0600 (CST) Kumar Gala <[EMAIL PROTECTED]> wrote: From 819ad3ed4660f4238e053728a8b5aa93d22b13d7 Mon Sep 17 00:00:00 2001 From: Kumar Gala <[EMAIL PROTECTED]> Date: Tue, 4 Nov 2008 10:13:53 -0600 Subject: [PATCH 1/1] irq: Maintain user set affinity This addresses a regression in that if a user specified an affinity for an interrupt that affinity information would get reset between a request_irq(), free_irq() and request_irq() for the same irq. On example of this is bringing up an ethernet interface, taking it down and bringing it back up again. Instead of always using the irq_default_affinity we use the previous setting of the IRQs affinity with the assumption that at boot the IRQs affinity will be set to irq_default_affinity. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- kernel/irq/manage.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index c498a1b..ea7d11b 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -115,9 +115,12 @@ int irq_select_affinity(unsigned int irq) if (!irq_can_set_affinity(irq)) return 0; - cpus_and(mask, cpu_online_map, irq_default_affinity); - desc = irq_to_desc(irq); + + mask = desc->affinity; + + cpus_and(mask, cpu_online_map, mask); + desc->affinity = mask; desc->chip->set_affinity(irq, mask); Are you able to identify when this regression occurred? It isn't immediately obvious to me. If the regression is present in 2.6.27 or earlier, do you think we should backport the fix? If so, a different patch would be needed due to the presence of commit 08678b0841267c1d00d771fe01548d86043d065e Author: Yinghai Lu <[EMAIL PROTECTED]> Date: Tue Aug 19 20:50:05 2008 -0700 generic: sparse irqs: use irq_desc() together with dyn_array, instead of irq_desc[] It didn't creep in during 2.6.27. I will back port a patch to 2.6.27. Thomas has provided me a better patch that handles a few critical issues that mine doesn't. I'll be testing it this evening and will backport to 2.6.27 if it works out. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
Fix the BSR driver to allow small BSR devices, which are limited to a
single 4k space, on a 64k page kernel. Previously the driver would
reject the mmap since the size was smaller than PAGESIZE (or because
the size was greater than the size of the device). Now, we check for
this case use remap_4k_pfn(). Also, take out code to set vm_flags,
as the remap_pfn functions will do this for us.
Signed-off-by: Sonny Rao <[EMAIL PROTECTED]>
Index: common/drivers/char/bsr.c
===
--- common.orig/drivers/char/bsr.c 2008-11-06 16:43:58.0 -0600
+++ common/drivers/char/bsr.c 2008-11-06 18:30:41.0 -0600
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
/*
@@ -115,15 +116,23 @@
{
unsigned long size = vma->vm_end - vma->vm_start;
struct bsr_dev *dev = filp->private_data;
+ int ret;
- if (size > dev->bsr_len || (size & (PAGE_SIZE-1)))
- return -EINVAL;
+ /* This is legal where we have a BSR on a 4k page but a 64k kernel */
+ if (size > dev->bsr_len)
+ size = dev->bsr_len;
- vma->vm_flags |= (VM_IO | VM_DONTEXPAND);
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
- if (io_remap_pfn_range(vma, vma->vm_start, dev->bsr_addr >> PAGE_SHIFT,
- size, vma->vm_page_prot))
+ if (dev->bsr_len < PAGE_SIZE)
+ ret = remap_4k_pfn(vma, vma->vm_start, dev->bsr_addr >> 12,
+ vma->vm_page_prot);
+ else
+ ret = io_remap_pfn_range(vma, vma->vm_start,
+dev->bsr_addr >> PAGE_SHIFT,
+size, vma->vm_page_prot);
+
+ if (ret)
return -EAGAIN;
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Check return value from fwrite()
There's one place in flattree.c where we currently ignore the return
value from fwrite(). On some gcc/glibc versions, where fwrite() is
declared with attribute warn_unused_result, this causes a warning.
This patch fixes the warning, by checking the fwrite() result.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/flattree.c
===
--- dtc.orig/flattree.c 2008-11-07 11:40:02.0 +1100
+++ dtc/flattree.c 2008-11-07 11:40:30.0 +1100
@@ -413,10 +413,13 @@ void dt_to_blob(FILE *f, struct boot_inf
if (padlen > 0)
blob = data_append_zeroes(blob, padlen);
- fwrite(blob.val, blob.len, 1, f);
-
- if (ferror(f))
- die("Error writing device tree blob: %s\n", strerror(errno));
+ if (fwrite(blob.val, blob.len, 1, f) != 1) {
+ if (ferror(f))
+ die("Error writing device tree blob: %s\n",
+ strerror(errno));
+ else
+ die("Short write on device tree blob\n");
+ }
/*
* data_merge() frees the right-hand element so only the blob
--
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
dtc: Use noinput flex option for convert-dtsv0 to remove warning
The convert-dtsv0 lexer doesn't use lex's input() macro/function. This can result in "defined but not used" warnings. This patch uses flex's noinput option to prevent this warning (as we already do for dtc-lexer.l). Signed-off-by: David Gibson <[EMAIL PROTECTED]> Index: dtc/convert-dtsv0-lexer.l === --- dtc.orig/convert-dtsv0-lexer.l 2008-11-07 11:43:05.0 +1100 +++ dtc/convert-dtsv0-lexer.l 2008-11-07 11:43:20.0 +1100 @@ -17,7 +17,7 @@ * USA */ -%option noyywrap nounput +%option noyywrap nounput noinput %x INCLUDE %x BYTESTRING -- 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: dtc: Add python source code output
On Thu, Nov 06, 2008 at 06:55:44PM +1100, Michael Ellerman wrote:
> This commit adds an output format, which produces python
> code. When run, the python produces a data structure that
> can then be inspected in order to do various things.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
>
> I'm not sure if this is generally useful (or sane) but it was for me so
> I thought I'd post it.
Hrm, well the idea of langauge source output seems reasonable. But
the actual data structure emitted, and the method of construction in
Python both seem a bit odd to me.
> I have a dts that I want to use to configure a simulator, and this
> seemed like the nicest way to get there. dtc spits out the pythonised
> device tree, and then I have a 10 line python script that does the
> configuring.
[snip]
> diff --git a/python.c b/python.c
> new file mode 100644
> index 000..8ad0433
> --- /dev/null
> +++ b/python.c
AFAICT this is based roughly on the output side of treesource.c. It
would be kind of nice if the two could be combined, with the same
basic structure looping over the device tree, and different emitters
for either python or dts source. This would be similar to what we do
in flattree.c to emit either binary or asm versions of the flat tree.
> @@ -0,0 +1,129 @@
> +/*
> + * (C) Copyright David Gibson <[EMAIL PROTECTED]>, IBM Corporation. 2005.
> + * (C) Copyright Michael Ellerman, IBM Corporation. 2008.
> + *
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> + * USA
> + */
> +
> +#include "dtc.h"
> +#include "srcpos.h"
> +
> +
> +static void write_propval_cells(FILE *f, struct property *prop)
> +{
> + cell_t *cp = (cell_t *)prop->val.val;
> + int i;
> +
> + fprintf(f, "p = Property('%s', [", prop->name);
> +
> + for (i = 0; i < prop->val.len / sizeof(cell_t); i++)
> + fprintf(f, "0x%x, ", fdt32_to_cpu(cp[i]));
> +
> + fprintf(f, "])\n");
> +}
> +
> +static int isstring(char c)
> +{
> + return (isprint(c)
> + || (c == '\0')
> + || strchr("\a\b\t\n\v\f\r", c));
> +}
> +
> +static void write_property(FILE *f, struct property *prop)
> +{
> + const char *p = prop->val.val;
> + int i, strtype, len = prop->val.len;
> +
> + if (len == 0) {
> + fprintf(f, "p = Property('%s', None)\n", prop->name);
> + goto out;
> + }
> +
> + strtype = 1;
> + for (i = 0; i < len; i++) {
> + if (!isstring(p[i])) {
> + strtype = 0;
> + break;
> + }
> + }
> +
> + if (strtype)
> + fprintf(f, "p = Property('%s', '%s')\n", prop->name,
> + prop->val.val);
This isn't correct. The property value could contain \0s or other
control characters which won't be preserved properly if emitted
directly into the python source. You'd need to escape the string, as
write_propval_string() does in treesource.c.
Uh.. there's also an interesting ambiguity here. In OF and flat
trees, strings are NUL-terminated and the final '\0' is included as
part of the property length. Python strings are not NUL-terminated,
they're bytestrings that know their own length. I think making sure
all the conversions correctly preserve the presence/lack of a terminal
NUL, requires a bit more care here..
> + else if (len == 4)
> + fprintf(f, "p = Property('%s', 0x%x)\n", prop->name,
> + fdt32_to_cpu(*(const cell_t *)p));
There's a propval_cell() function in livetree.c you can use to
simplify this.
> + else
> + write_propval_cells(f, prop);
Uh.. this branch could be called in the case where prop is not a
string, but also doesn't have length a multiple of 4, which
write_propval_cells() won't correctly deal with.
These branches also result in the value having different Python types
depending on the context. That's not necessarily a bad thing, but
since which Python type is chosen depends on a heuristic only, it
certainly needs some care. You certainly need to be certain that you
can always deduce the exact, byte-for-byte correct version of the
property value from whatever you put into the Python data structure.
> +
Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
Sonny Rao writes: > Fix the BSR driver to allow small BSR devices, which are limited to a > single 4k space, on a 64k page kernel. Previously the driver would > reject the mmap since the size was smaller than PAGESIZE (or because > the size was greater than the size of the device). Now, we check for > this case use remap_4k_pfn(). Also, take out code to set vm_flags, > as the remap_pfn functions will do this for us. Thanks. Do we know that the BSR size will always be 4k if it's not a multiple of 64k? Is it possible that we could get 8k, 16k or 32k or BSRs? If it is possible, what does the user need to be able to do? Do they just want to map 4k, or might then want to map the whole thing? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
