* [RFC] Non-numbered ibm iic driver
From: Sean MacLennan @ 2008-06-29 3:20 UTC (permalink / raw)
To: linuxppc-dev
This is a patch to the ibm iic driver that uses the non-numbered
i2c call and therefore does not need an index. Instead, it registers the
ibm iic, then walks all the child nodes and adds them. This is required
for new style drivers, old style drivers "just work".
The warp has both a new style driver (ad7414) and old style (eeprom)
devices.
This patch is completely function but not a complete patch (the index
code is not needed for example). It is just for comment.
The warp.dts needed for this to work is, I believe, in Josh's next tree.
Cheers,
Sean
P.S. Do I need a signed-off-by for an RFC?
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 85dbf34..0ec6849 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -753,7 +753,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
*/
adap->nr = dev->idx >= 0 ? dev->idx : 0;
- if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
+ if ((ret = i2c_add_adapter(adap)) < 0) {
printk(KERN_ERR "ibm-iic%d: failed to register i2c adapter\n",
dev->idx);
goto fail;
@@ -874,6 +874,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
struct device_node *np = ofdev->node;
+ struct device_node *child;
struct ibm_iic_private *dev;
struct i2c_adapter *adap;
const u32 *indexp, *freq;
@@ -939,12 +940,33 @@ static int __devinit iic_probe(struct of_device *ofdev,
adap->timeout = 1;
adap->nr = dev->idx;
- ret = i2c_add_numbered_adapter(adap);
+ ret = i2c_add_adapter(adap);
if (ret < 0) {
dev_err(&ofdev->dev, "failed to register i2c adapter\n");
goto error_cleanup;
}
+ for_each_child_of_node(np, child) {
+ struct i2c_board_info info;
+ const u32 *reg;
+
+ reg = of_get_property(child, "reg", NULL);
+ if (!reg) {
+ printk(KERN_ERR "Could not find address for %s\n",
+ child->name);
+ continue;
+ }
+
+ memset(&info, 0, sizeof(info));
+ strlcpy(info.type, child->name, I2C_NAME_SIZE);
+ info.addr = *reg;
+
+ if (!i2c_new_device(adap, &info))
+ printk(KERN_ERR "Could not add i2c device %s.\n",
+ child->name);
+ }
+
+
dev_info(&ofdev->dev, "using %s mode\n",
dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
^ permalink raw reply related
* Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
From: Jon Smirl @ 2008-06-29 2:05 UTC (permalink / raw)
To: Jean Delvare, Grant Likely, Timur Tabi
Cc: linuxppc-dev list, Wolfram Sang, Linux I2C
In-Reply-To: <20080625155825.43d07d20@hyperion.delvare>
On 6/25/08, Jean Delvare <khali@linux-fr.org> wrote:
> >
> > i2c->adap = mpc_ops;
> > - i2c->adap.nr = pdev->id;
> > i2c_set_adapdata(&i2c->adap, i2c);
> > - i2c->adap.dev.parent = &pdev->dev;
> > - if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
> > + i2c->adap.dev.parent = &op->dev;
> > +
> > + result = i2c_add_adapter(&i2c->adap);
>
>
> The driver was previously using i2c_add_numbered_adapter(), giving MPC
> platform the possibility to use new-style i2c drivers:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44
> You're breaking this, I doubt it's on purpose?
Grant, what do you want here? You're the one who converted it to
i2c_add_numbered_adapter. But in other posts you've said that the
device tree should have nothing to do with bus numbering.
Once this driver is converted to an OF one it shouldn't need bus ids
since all of the i2c devices will be children of the bus node. We can
just let the i2c subsystem assign a bus number.
Timur has some issues with the i2c bus number in his ALSA driver. The
problem is locating the i2c device when the i2s driver loads. Parsing
the device tree to extract an i2c bus and device number is not a good
solution.
codec-handle should give you the i2c device node. But then we can't
use of_find_device_by_node because the i2c device is not an of_device,
it's a cross platform i2c_device. Should of_find_device_by_node()
return a 'struct device' instead of a 'struct of_device' and leave it
as a user exercise to cast up? It is used nine times in the kernel,
mostly sparc.
i2s@2000 { /* PSC1 in i2s mode */
device_type = "sound";
compatible = "mpc5200b-psc-i2s","fsl,mpc5200b-psc-i2s";
cell-index = <0>;
reg = <0x2000 0x100>;
interrupts = <0x2 0x2 0x0>;
interrupt-parent = <&mpc5200_pic>;
codec-handle = <&tas0>;
};
i2c@3d00 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <0x3d00 0x40>;
interrupts = <0x2 0xf 0x0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
tas0:codec@1b {
compatible = "ti,tas5504";
reg = <0x1b>;
};
};
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH v2] update crypto node definition and device tree instances
From: Segher Boessenkool @ 2008-06-28 23:37 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40806272229s795067d5he962c8a1750a260@mail.gmail.com>
> I'm really don't like "fsl,sec1.0" or any of the variants as a
> compatible property either because it can easily be abused (it's not
> anchored to a specific physical part so the meaning can shift over
> time); but that is another argument and it is well documented in other
> email threads
> (http://thread.gmane.org/gmane.linux.ports.ppc64.devel/38977/
> focus=39147)
Also, these made-up names make you do more work: you'll need to
write up a binding for them, explaining exactly what a 1.0 device
etc. is (or at least point to documentation for it). If you use
a name that refers to some device that people can easily google
for documentation, you can skip this (well, you might need to
write a binding anyway; but at least you won't have to explain
what the device _is_).
Using actual model names also reduces the namespace pollution
(hopefully Freescale will not create some other MPC8272 device
ever, so "fsl,mpc8272-whatever" will never be a nice name to
use for any other device; OTOH, it's likely that Freescale will
create some other device called "SEC" (there are only so many
TLAs, after all), so "fsl,sec-n.m" isn't as future-proof.
Segher
^ permalink raw reply
* Re: [PATCH 19/60] microblaze_v4: checksum support
From: Segher Boessenkool @ 2008-06-28 22:28 UTC (permalink / raw)
To: monstr
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev, alan,
hpa, drepper, john.williams, will.newton
In-Reply-To: <1214483429-32360-20-git-send-email-monstr@seznam.cz>
> +static inline unsigned int
> +csum_tcpudp_nofold(unsigned long saddr, unsigned long daddr, unsigned
> short len,
> + unsigned short proto, unsigned int sum)
> +{
> + __asm__("add %0, %4, %1\n\t"
> + "addc %0, %4, %2\n\t"
> + "addc %0, %4, %3\n\t"
> + "addc %0, %4, r0\n\t"
> + : "=d" (sum)
> + : "d" (saddr), "d" (daddr), "d" (len + proto),
> + "0"(sum));
"sum" should use an earlyclobber, i.e. "=&d"(sum) , since some
inputs are used after %0 is first written to.
Also, you can use "+" instead of "=" to say the argument is both
input and output, and get rid of %4, if you like.
Segher
^ permalink raw reply
* Re: FW: [PATCH] powerpc: Xilinx: adding virtex5 powerpc 440 support
From: Grant Likely @ 2008-06-28 21:59 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080628215615.GD10692@secretlab.ca>
Hi John.
Oops, you had also posted this patch to the list later, so I'm also
forwarding my comments to the list.
Cheers,
g.
On Sat, Jun 28, 2008 at 3:56 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Sorry for the late reply on this one, I had gotten rather busy.
>
> On Wed, Jun 18, 2008 at 03:09:39PM -0600, John Linn wrote:
>> 1. I'm not sure why we need to disable the interrupts in the
>> bootstrap loader?
>
> You don't. That's old zImage.raw stuff that you don't need.
>
>> 2. I see some SecetLab copyright in new files that might be just a
>> cut/paste type error?
>
> If it is mostly based on my code, then it is appropriate to preserve my
> copyright and add Xilinx's copyright above it. If it is really heavily
> modified, then the Secret lab copyright can be dropped.
>
>> 3. I don't see the cputable.c up to date with the 440?
>
>> Thanks,
>> John
>>
>> -----Original Message-----
>> From: John Linn [mailto:john.linn@xilinx.com]
>> Sent: Wednesday, June 18, 2008 2:58 PM
>> Cc: John Linn
>> Subject: [PATCH] powerpc: Xilinx: adding virtex5 powerpc 440 support
>>
>>
>>
>> The following files add support for Virtex5 with Powerpc 440.
>>
>>
>>
>> Device trees are currently handled differently than other embedded
>>
>> systems as there may not be a boot loader such that the device
>>
>> tree is compiled into the kernel or pulled from a BRAM.
>>
>>
>>
>> The UART 16550 has extra initialization in the bootstrap loader
>>
>> since a boot loader is not used many times.
>>
>
> Your mailer seems to have damaged the patch by wrapping lines and
> inserting extra blank lines. You'll need to resend. I've removed
> them below so I could make comments.
>
>>
>> Signed-off-by: John Linn <john.linn@xilinx.com>
>> ---
>> arch/powerpc/Kconfig | 75 +++
>> arch/powerpc/boot/Makefile | 24 +-
>> arch/powerpc/boot/dts/ml507.dts | 254 ++++++++
>> arch/powerpc/boot/io.h | 7 +
>> arch/powerpc/boot/virtex.c | 246 ++++++++
>> arch/powerpc/configs/44x/ml507_defconfig | 1010 ++++++++++++++++++++++++++++++
>> arch/powerpc/platforms/44x/Kconfig | 62 ++
>> arch/powerpc/platforms/44x/Makefile | 1 +
>> arch/powerpc/platforms/44x/virtex.c | 58 ++
>> arch/powerpc/platforms/Kconfig | 7 +
>> 10 files changed, 1739 insertions(+), 5 deletions(-)
>> create mode 100644 arch/powerpc/boot/dts/ml507.dts
>> create mode 100644 arch/powerpc/boot/virtex.c
>> create mode 100644 arch/powerpc/configs/44x/ml507_defconfig
>> create mode 100644 arch/powerpc/platforms/44x/virtex.c
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 3934e26..94adfe1 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -483,6 +483,81 @@ config SECCOMP
>>
>> If unsure, say Y. Only embedded should say N here.
>>
>> +config WANT_DEVICE_TREE
>> + bool
>> + default n
>
> This shouldn't be here.
>
>> +
>> +config BUILD_RAW_IMAGE
>> + bool "Build firmware-independent image"
>> + select WANT_DEVICE_TREE
>> + help
>> + If this is enabled, a firmware independent "raw" image will be
>> + built, as zImage.raw. This requires a completely filled-in
>> + device tree, with the following labels:
>> +
>> + mem_size_cells: on /#address-cells
>> + memsize: on the size portion of /memory/reg
>> + timebase: on the boot CPU's timebase property
>
> Obsolete stuff; replaced with simpleImage
>
>> +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.
>
> Obsolete
>
>> +config COMPRESSED_DEVICE_TREE
>> + bool "Use compressed device tree"
>> + depends on XILINX_VIRTEX
>> + depends on WANT_DEVICE_TREE
>> + help
>> + In Xilinx FPGAs, the hardware can change quite dramatically
>> while
>> + still running the same kernel. In this case and other similar
>> + ones, it is preferable to associate the device tree with a
>> + particular build of the hardware design. This configuration
>> + option assumes that the device tree blob has been compressed and
>> + stored in Block RAM in the FPGA design. Typically, such a block
>> + ram is available in order to provide a bootloop or other code
>> + close to the reset vector at the top of the address space. By
>> + default, the parameter options associated with this configuration
>> + assumes that exactly one block ram (2KB) of storage is available,
>> + which should be sufficient for most designs. If necessary in a
>> + particular design, due to boot code requirement or a large number
>> + of devices, this address (and the corresponding parameters in the
>> + EDK design) must be modified.
>> +
>> + Note that in some highly area constrained designs, no block rams
>> + may be available in the design, and some other mechanism may be
>> + used to hold the processor in reset while external memory is
>> + initialized with processor code. In such cases, that mechanism
>> + should also be used to load the device tree at an appropriate
>> + location, and the parameters associated with this configuration
>> + option should be modified to point to that location in external
>> + memory.
>
> This is a really interesting option and is probably useful for other
> platforms too. I'd like to see this split out into a separate patch and
> slightly reworked so that it is usable by non-xilinx targets.
>
>> +config COMPRESSED_DTB_START
>> + hex "Start of compressed device tree"
>> + depends on COMPRESSED_DEVICE_TREE
>> + default 0xfffff800
>> +
>> +config COMPRESSED_DTB_SIZE
>> + hex "Size of compressed device tree"
>> + depends on COMPRESSED_DEVICE_TREE
>> + default 0x800
>
> These probably shouldn't be config values. Either they should be
> provided in regsiters or memory at boot time, or a data file should be
> pulled in when linking the bootwrapper to determine where to look for the
> device tree compressed blob. The goal of this is to allow multiple
> images to be built (with different dtb locations) for a single kernel
> compile.
>
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index 1cee2f9..9de59fb 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -66,7 +66,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c
>> cuboot-83xx.c cuboot-85xx.c holly.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 cuboot-yosemite.c
>> simpleboot.c \
>> - virtex405-head.S
>> + virtex.c virtex405-head.S
>> src-boot := $(src-wlib) $(src-plat) empty.c
>>
>> src-boot := $(addprefix $(obj)/, $(src-boot))
>> @@ -197,6 +197,7 @@ image-$(CONFIG_PPC_HOLLY) += zImage.holly
>> image-$(CONFIG_PPC_PRPMC2800) += dtbImage.prpmc2800
>> image-$(CONFIG_PPC_ISERIES) += zImage.iseries
>> image-$(CONFIG_DEFAULT_UIMAGE) += uImage
>> +image-$(CONFIG_XILINX_VIRTEX) += zImage.virtex
>>
>> #
>> # Targets which embed a device tree blob
>> @@ -279,14 +280,24 @@ 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
>> +
>
> Obsolete stuff
>
>> # 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)
>> - $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
>> +$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
>> + $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
>
> Ditto
>
>>
>> -$(obj)/zImage.%: vmlinux $(wrapperbits)
>> - $(call if_changed,wrap,$*)
>> +$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
>> + $(call if_changed,wrap,$*,$(dts))
>
> Ditto
>
>> # dtbImage% - a dtbImage is a zImage with an embedded device tree blob
>> $(obj)/dtbImage.initrd.%: vmlinux $(wrapperbits) $(obj)/%.dtb
>> @@ -325,6 +336,9 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb
>> $(wrapperbits)
>> $(obj)/%.dtb: $(dtstree)/%.dts $(obj)/dtc
>> $(obj)/dtc -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS)
>> $(dtstree)/$*.dts
>>
>> +$(obj)/zImage.raw: vmlinux $(dts) $(wrapperbits)
>> + $(call if_changed,wrap,raw,$(dts))
>> +
>
> Ditto
>
>> # If there isn't a platform selected then just strip the vmlinux.
>> ifeq (,$(image-y))
>> image-y := vmlinux.strip
>> diff --git a/arch/powerpc/boot/dts/ml507.dts
>> b/arch/powerpc/boot/dts/ml507.dts
>> new file mode 100644
>> index 0000000..43d8535
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/ml507.dts
>> @@ -0,0 +1,254 @@
>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@monstr.eu>
>
> I don't think it is appropriate to have Michal's name here; this is a
> generated file, not a file that he wrote. (It is, of course, 100%
> appropriate for the tool that generated it to have his copyright)
>
> It *might* be appropriate for Xilinx to claim copyright on this file
> because it is the device tree for one of Xilinx's reference designs, but
> that ground isn't very stable.
>
>> + * 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
>
> These three paragraphs can be dropped; they are redundant.
>
>> + *
>> + * CAUTION: This file is automatically generated by libgen.
>> + * Version: Xilinx EDK 10.1.01 EDK_K_SP1.2
>
> This is a generated file and so it is debatable about whether or not it
> is appropriate for inclusion in the kernel. Personally, I lean toward
> including it as long as it is well documented as to what it is.
> Specifically, the comment block should state exactly what version of the
> reference design is being described here.
>
> <snipping the entire dts file>
>
> BTW, the dts file and defconfig should be submitted in separate patch
> files.
>
>> diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
>> index ccaedae..ec57ec9 100644
>> --- a/arch/powerpc/boot/io.h
>> +++ b/arch/powerpc/boot/io.h
>> @@ -99,4 +99,11 @@ static inline void barrier(void)
>> asm volatile("" : : : "memory");
>> }
>>
>> +static inline void disable_irq(void)
>> +{
>> + int dummy;
>> + asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0" :
>> + "=r" (dummy) : : "memory");
>> +}
>> +
>
> Drop this; it was part of the old zImage.raw stuff.
>
>> #endif /* _IO_H */
>> diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
>> new file mode 100644
>> index 0000000..5d807c6
>> --- /dev/null
>> +++ b/arch/powerpc/boot/virtex.c
>> @@ -0,0 +1,246 @@
>> +/*
>> + * Old U-boot compatibility for Walnut
>
> Not true! :-)
>
>> + * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> Probably not true either!
>
>> + *
>> + * Copyright 2007 IBM Corporation
>> + * Based on cuboot-83xx.c, which is:
>> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
>
> You should probably add Xilinx to this list.
>
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published
>> + * by the Free Software Foundation.
>
> This paragraph is redundant; remove.
>
>> + */
>> +
>> +#include <stddef.h>
>> +#include <stdio.h>
>> +#include "ops.h"
>> +#include "dcr.h"
>> +#include "4xx.h"
>> +#include "io.h"
>> +#include "reg.h"
>> +
>> +BSS_STACK(4096);
>> +
>> +#include "types.h"
>> +#include "gunzip_util.h"
>> +#include <libfdt.h>
>> +#include "../../../include/linux/autoconf.h"
>> +
>> +#define UART_DLL 0 /* Out: Divisor Latch Low */
>> +#define UART_DLM 1 /* Out: Divisor Latch High */
>> +#define UART_FCR 2 /* Out: FIFO Control Register */
>> +#define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */
>> +#define UART_FCR_CLEAR_XMIT 0x04 /* Clear the XMIT FIFO */
>> +#define UART_LCR 3 /* Out: Line Control Register */
>> +#define UART_MCR 4 /* Out: Modem Control Register */
>> +#define UART_MCR_RTS 0x02 /* RTS complement */
>> +#define UART_MCR_DTR 0x01 /* DTR complement */
>> +#define UART_LCR_DLAB 0x80 /* Divisor latch access bit */
>> +#define UART_LCR_WLEN8 0x03 /* Wordlength: 8 bits */
>> +
>> +/* This function is only needed when there is no boot loader to
>> + initialize the UART
>> +*/
>> +static int virtex_ns16550_console_init(void *devp)
>> +{
>> + int n;
>> + unsigned long reg_phys;
>> + unsigned char *regbase;
>> + u32 regshift, clk, spd;
>> + u16 divisor;
>> +
>> + n = getprop(devp, "virtual-reg", ®base, sizeof(regbase));
>> + if (n != sizeof(regbase)) {
>> + if (!dt_xlate_reg(devp, 0, ®_phys, NULL))
>> + return -1;
>> +
>> + regbase = (void *)reg_phys + 3;
>> + }
>> + regshift = 2;
>> +
>> + n = getprop(devp, "current-speed", (void *)&spd, sizeof(spd));
>> + if (n != sizeof(spd))
>> + spd = 9600;
>> +
>> + /* should there be a default clock rate?*/
>> + n = getprop(devp, "clock-frequency", (void *)&clk, sizeof(clk));
>> + if (n != sizeof(clk))
>> + return -1;
>> +
>> + divisor = clk / (16 * spd);
>> +
>> + /* Access baud rate */
>> + out_8(regbase + (UART_LCR << regshift), UART_LCR_DLAB);
>> +
>> + /* Baud rate based on input clock */
>> + out_8(regbase + (UART_DLL << regshift), divisor & 0xFF);
>> + out_8(regbase + (UART_DLM << regshift), divisor >> 8);
>> +
>> + /* 8 data, 1 stop, no parity */
>> + out_8(regbase + (UART_LCR << regshift), UART_LCR_WLEN8);
>> +
>> + /* RTS/DTR */
>> + out_8(regbase + (UART_MCR << regshift), UART_MCR_RTS | UART_MCR_DTR);
>> +
>> + /* Clear transmitter and receiver */
>> + out_8(regbase + (UART_FCR << regshift),
>> + UART_FCR_CLEAR_XMIT | UART_FCR_CLEAR_RCVR);
>> + return 0;
>> +}
>> +
>> +/* For virtex, the kernel may be loaded without using a bootloader and if so
>> + some UARTs need more setup than is provided in the normal console init
>> +*/
>> +static int virtex_serial_console_init(void)
>> +{
>> + void *devp;
>> + char devtype[MAX_PROP_LEN];
>> + char path[MAX_PATH_LEN];
>> +
>> + devp = finddevice("/chosen");
>> + if (devp == NULL)
>> + return -1;
>> +
>> + if (getprop(devp, "linux,stdout-path", path, MAX_PATH_LEN) > 0) {
>> + devp = finddevice(path);
>> + if (devp == NULL)
>> + return -1;
>> +
>> + if ((getprop(devp, "device_type", devtype, sizeof(devtype)) > 0)
>> + && !strcmp(devtype, "serial")
>> + && (dt_is_compatible(devp, "ns16550")))
>> + virtex_ns16550_console_init(devp);
>> + }
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_COMPRESSED_DEVICE_TREE
>> +static struct gunzip_state gzstate;
>> +#endif
>
> #ifdefs are forbidden in bootwrapper code. Use different zImage targets
> to enable/disable particular features.
>
>> +
>> +void platform_init(void)
>
> Wrong signature for platform_init(). Should be:
>
> void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> unsigned long r6, unsigned long r7)
>
>> +{
>> + u32 memreg[4];
>> + u64 start;
>> + u64 size = 0x2000000;
>> + int naddr, nsize, i;
>> + void *root, *memory;
>> + static const unsigned long line_size = 32;
>> + static const unsigned long congruence_classes = 256;
>> + unsigned long addr;
>> + unsigned long dccr;
>> +
>> +#ifdef CONFIG_COMPRESSED_DEVICE_TREE
>> + void *dtbz_start;
>> + u32 dtbz_size;
>> + void *dtb_addr;
>> + u32 dtb_size;
>> + struct fdt_header dtb_header;
>> + int len;
>> +#endif
>
> Ditto
>
>> +
>> + if((mfpvr() & 0xfffff000) == 0x20011000) {
>> + /* PPC errata 213: only for Virtex-4 FX */
>> + __asm__("mfccr0 0\n\t"
>> + "oris 0,0,0x50000000@h\n\t"
>> + "mtccr0 0"
>> + : : : "0");
>> + }
>> +
>> + /*
>> + * Invalidate the data cache if the data cache is turned off.
>> + * - The 405 core does not invalidate the data cache on power-up
>> + * or reset but does turn off the data cache. We cannot assume
>> + * that the cache contents are valid.
>> + * - If the data cache is turned on this must have been done by
>> + * a bootloader and we assume that the cache contents are
>> + * valid.
>> + */
>> + __asm__("mfdccr %0": "=r" (dccr));
>> + if (dccr == 0) {
>> + for (addr = 0;
>> + addr < (congruence_classes * line_size);
>> + addr += line_size) {
>> + __asm__("dccci 0,%0": :"b"(addr));
>> + }
>> + }
>
> Instead of duplicating this in C code, you should instead modify the
> wrapper script to also link in virtex405-head.o
>
>> +#if defined(CONFIG_XILINX_VIRTEX_5_FXT) && defined(CONFIG_MATH_EMULATION)
>> + /* Make sure the APU is disabled when using soft FPU emulation */
>> + mtdcr(5, 0);
>> +#endif
>
> Again; remove #ifdefs. Do stuff like this in the equivalent of
> virtex405-head.S
>
>> +
>> + disable_irq();
>> +
>> +#ifdef CONFIG_COMPRESSED_DEVICE_TREE
>> +
>> + /** FIXME: flatdevicetrees need the initializer allocated,
>> + libfdt will fix this. */
>> + dtbz_start = (void *)CONFIG_COMPRESSED_DTB_START;
>> + dtbz_size = CONFIG_COMPRESSED_DTB_SIZE;
>> + /** get the device tree */
>> + gunzip_start(&gzstate, dtbz_start, dtbz_size);
>> + gunzip_exactly(&gzstate, &dtb_header, sizeof(dtb_header));
>> +
>> + dtb_size = dtb_header.totalsize;
>> + // printf("Allocating 0x%lx bytes for dtb ...\n\r", dtb_size);
>
> remove c++ style comments
>
>> +
>> + dtb_addr = _end; // Should be allocated?
>> +
>> + gunzip_start(&gzstate, dtbz_start, dtbz_size);
>> + len = gunzip_finish(&gzstate, dtb_addr, dtb_size);
>> + if (len != dtb_size)
>> + fatal("ran out of data! only got 0x%x of 0x%lx bytes.\n\r",
>> + len, dtb_size);
>> + printf("done 0x%x bytes\n\r", len);
>> + simple_alloc_init(0x800000, size - (unsigned long)0x800000, 32, 64);
>> + fdt_init(dtb_addr);
>
> Address shouldn't be hard coded. Can you calculate the dtb_addr based on
> the _end addr and the size of the dtb?
>
>> +#else
>> + /** FIXME: flatdevicetrees need the initializer allocated,
>> + libfdt will fix this. */
>> + simple_alloc_init(_end, size - (unsigned long)_end, 32, 64);
>> + fdt_init(_dtb_start);
>> +#endif
>> +
>> + root = finddevice("/");
>> + if (getprop(root, "#address-cells", &naddr, sizeof(naddr)) < 0)
>> + naddr = 2;
>> + if (naddr < 1 || naddr > 2)
>> + fatal("Can't cope with #address-cells == %d in /\n\r", naddr);
>> +
>> + if (getprop(root, "#size-cells", &nsize, sizeof(nsize)) < 0)
>> + nsize = 1;
>> + if (nsize < 1 || nsize > 2)
>> + fatal("Can't cope with #size-cells == %d in /\n\r", nsize);
>> +
>> + memory = finddevice("/memory@0");
>> + if (! memory) {
>> + fatal("Need a memory@0 node!\n\r");
>> + }
>> + if (getprop(memory, "reg", memreg, sizeof(memreg)) < 0)
>> + fatal("Need a memory@0 node!\n\r");
>> +
>> + i = 0;
>> + start = memreg[i++];
>> + if(naddr == 2) {
>> + start = (start << 32) | memreg[i++];
>> + }
>> + size = memreg[i++];
>> + if (nsize == 2)
>> + size = (size << 32) | memreg[i++];
>> +
>> + // timebase_period_ns = 1000000000 / timebase;
>> + virtex_serial_console_init();
>> + serial_console_init();
>> + if (console_ops.open)
>> + console_ops.open();
>> +
>> +#ifdef CONFIG_COMPRESSED_DEVICE_TREE
>> + printf("Using compressed device tree at 0x%x\n\r",
>> CONFIG_COMPRESSED_DTB_START);
>> +#else
>> +#endif
>> + printf("booting virtex\n\r");
>> + printf("memstart=0x%llx\n\r", start);
>> + printf("memsize=0x%llx\n\r", size);
>> +}
>> diff --git a/arch/powerpc/platforms/44x/Kconfig
>> b/arch/powerpc/platforms/44x/Kconfig
>> index 6abe913..b90b33d 100644
>> --- a/arch/powerpc/platforms/44x/Kconfig
>> +++ b/arch/powerpc/platforms/44x/Kconfig
>> @@ -102,6 +102,58 @@ config YOSEMITE
>> # help
>> # This option enables support for the IBM PPC440GX evaluation board.
>>
>> +config XILINX_ML507
>> + bool "Xilinx ML507 Reference System"
>> + depends on 44x
>> + default n
>> + select XILINX_ML5XX
>> + select WANT_DEVICE_TREE
>> + help
>> + This option enables support for the Xilinx ML507 board.
>
> I don't think this is necessary. Follow the lead of virtex4 support and
> do something like config XILINX_VIRTEX_440_GENERIC_BOARD.
>
>> @@ -152,3 +204,13 @@ config 460EX
>> # 44x errata/workaround config symbols, selected by the CPU models
>> above
>> config IBM440EP_ERR42
>> bool
>> +
>> +# Xilinx specific config options.
>> +config XILINX_ML5XX
>> + bool
>> + select XILINX_VIRTEX
>
> I think you should drop this. Board specific stuff should be contained
> within the .dts files.
>
>> +config XILINX_VIRTEX_5_FXT
>> + bool
>> + depends on XILINX_ML507
>> + default y
>
> Drop the above two lines and may the generic board config option select
> XILINX_VIRTEX_5_FXT
>
>> diff --git a/arch/powerpc/platforms/44x/Makefile
>> b/arch/powerpc/platforms/44x/Makefile
>> index 774165f..e3a9337 100644
>> --- a/arch/powerpc/platforms/44x/Makefile
>> +++ b/arch/powerpc/platforms/44x/Makefile
>> @@ -4,6 +4,7 @@ obj-$(CONFIG_TAISHAN) += taishan.o
>> obj-$(CONFIG_BAMBOO) += bamboo.o
>> obj-$(CONFIG_YOSEMITE) += bamboo.o
>> obj-$(CONFIG_SEQUOIA) += sequoia.o
>> +obj-$(CONFIG_XILINX_ML507) += virtex.o
>> obj-$(CONFIG_KATMAI) += katmai.o
>> obj-$(CONFIG_RAINIER) += rainier.o
>> obj-$(CONFIG_WARP) += warp.o
>> diff --git a/arch/powerpc/platforms/44x/virtex.c
>> b/arch/powerpc/platforms/44x/virtex.c
>> new file mode 100644
>> index 0000000..42ca337
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/44x/virtex.c
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Xilinx Virtex 5FXT based board support
>> + *
>> + * Copyright 2007 Secret Lab Technologies Ltd.
>> + *
>> + * 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.
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/of_platform.h>
>> +#include <asm/machdep.h>
>> +#include <asm/prom.h>
>> +#include <asm/time.h>
>> +#include <asm/xilinx_intc.h>
>> +#include <asm/reg.h>
>> +#include <asm/ppc4xx.h>
>> +#include "44x.h"
>> +
>> +static struct of_device_id xilinx_of_bus_ids[] __initdata = {
>> + { .compatible = "simple-bus", },
>> + { .compatible = "xlnx,plb-v46-1.00.a", },
>> + { .compatible = "xlnx,plb-v46-1.02.a", },
>> + { .compatible = "xlnx,plb-v34-1.01.a", },
>> + { .compatible = "xlnx,plb-v34-1.02.a", },
>> + { .compatible = "xlnx,opb-v20-1.10.c", },
>> + { .compatible = "xlnx,dcr-v29-1.00.a", },
>
> Do you need this whole list if the device tree generator is now claiming
> "simple-bus" compatibility?
>
>> + { .compatible = "xlnx,compound", },
>> + {}
>> +};
>> +
>> +static int __init virtex_device_probe(void)
>> +{
>> + of_platform_bus_probe(NULL, xilinx_of_bus_ids, NULL);
>> +
>> + return 0;
>> +}
>> +machine_device_initcall(virtex, virtex_device_probe);
>> +
>> +static int __init virtex_probe(void)
>> +{
>> + unsigned long root = of_get_flat_dt_root();
>> +
>> + if (!of_flat_dt_is_compatible(root, "xlnx,virtex"))
>> + return 0;
>
> This is probably not good. Granted, it is impossible to build a 405+440
> multiplatform image, but the device tree generator should probably be
> modified to claim something like "xlnx,virtex5fxt" so it isn't confused
> with an older virtex part. (I realize that this is just following the
> lead from virtex2/4 support, but that should probably be changed too.)
>
>> +
>> + return 1;
>> +}
>> +
>> +define_machine(virtex) {
>> + .name = "Xilinx Virtex",
>> + .probe = virtex_probe,
>> + .init_IRQ = xilinx_intc_init_tree,
>> + .get_irq = xilinx_intc_get_irq,
>> + .calibrate_decr = generic_calibrate_decr,
>> + .restart = ppc4xx_reset_system,
>> +};
>> diff --git a/arch/powerpc/platforms/Kconfig
>> b/arch/powerpc/platforms/Kconfig
>> index 87454c5..523388b 100644
>> --- a/arch/powerpc/platforms/Kconfig
>> +++ b/arch/powerpc/platforms/Kconfig
>> @@ -313,6 +313,13 @@ config FSL_ULI1575
>> config CPM
>> bool
>>
>> +config XILINX_VIRTEX
>> + bool
>> + select PPC_DCR_MMIO
>> + select PPC_DCR_NATIVE
>> + help
>> + Support for Xilinx Virtex platforms.
>> +
>
> config XILINX_VIRTEX is already defined in
> arch/powerpc/platforms/40x/Kconfig. Moving it to this file should be
> done in a separate patch.
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
From: Grant Likely @ 2008-06-28 20:33 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git, dwg
In-Reply-To: <20080606161932.0650C1500054@mail96-sin.bigfish.com>
On Fri, Jun 6, 2008 at 10:16 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> legacy_serial identifies a valid ns16550 on a simple-bus, but the
> legacy_serial driver doesn't understand the shift and offset flags
> necessary to get it to work, which results in no console.
>
> I think the easiest solution is to change the Kconfig so that
> PPC_UDBG_16550 is only selected based on !XILINX_VIRTEX. I've done this
> in my tree, but I've been swamped with other things at the moment, so I
> haven't verified it.
This is an easy solution, but it is not a good one. Doing so would
break UDBG on other 405 boards when building multiplatform kernels.
It would be better to teach legacy serial about the shift and offset.
Alternately, add code to add_legacy_soc_port() to skip it if the
shift/offset properties are present.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Fix wrong 'no interrupt' handling in of_i2c
From: Grant Likely @ 2008-06-28 19:16 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20080628183141.15298.2758.stgit@octopus.labnet.pengutronix.de>
On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> If an I2C device node does not specify an interrupt, the .irq member of the
> board_info struct was set to -1. This caused crashes on following
> irq_dispose_mappings. Leave it NO_IRQ as returned from irq_of_parse_and_map.
> (Suggesting -1 as 'i2c-no-irq' used to be a bug in linux/i2c.h.)
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] Fix wrong 'no interrupt' handling in of_i2c
From: Wolfram Sang @ 2008-06-28 18:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfram Sang
If an I2C device node does not specify an interrupt, the .irq member of the
board_info struct was set to -1. This caused crashes on following
irq_dispose_mappings. Leave it NO_IRQ as returned from irq_of_parse_and_map.
(Suggesting -1 as 'i2c-no-irq' used to be a bug in linux/i2c.h.)
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/of/of_i2c.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..500cb1e 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -90,8 +90,6 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
}
info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
if (of_find_i2c_driver(node, &info) < 0) {
irq_dispose_mapping(info.irq);
^ permalink raw reply related
* Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings
From: Bart Van Assche @ 2008-06-28 15:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <08A80326-6E58-43BC-9AB1-3136A0285A84@kernel.crashing.org>
On Sat, Jun 28, 2008 at 5:07 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jun 28, 2008, at 1:51 AM, Bart Van Assche wrote:
>
>> When compiling kernel modules for ppc that include <linux/spinlock.h>, gcc
>> prints a warning message every time it encounters a function declaration
>> where
>> the inline keyword appears after the return type. The patch below makes
>> sure
>> that the order of the inline keyword and the return type is as gcc expects
>> it.
>> Additionally, the __inline__ keyword is replaced by inline, as checkpatch
>> expects.
>>
>> Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
>
> what version of gcc and what config are you building for?
The gcc details are as follows (openSUSE 10.3 PPC running on a PS3):
$ gcc -v
Using built-in specs.
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.2.1 --enable-ssp
--disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=default32 --enable-secureplt
--with-long-double-128 --host=powerpc64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)
Bart.
^ permalink raw reply
* Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings
From: Kumar Gala @ 2008-06-28 15:07 UTC (permalink / raw)
To: Bart Van Assche; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200806280851.35417.bart.vanassche@gmail.com>
On Jun 28, 2008, at 1:51 AM, Bart Van Assche wrote:
> When compiling kernel modules for ppc that include <linux/
> spinlock.h>, gcc
> prints a warning message every time it encounters a function
> declaration where
> the inline keyword appears after the return type. The patch below
> makes sure
> that the order of the inline keyword and the return type is as gcc
> expects it.
> Additionally, the __inline__ keyword is replaced by inline, as
> checkpatch
> expects.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
what version of gcc and what config are you building for?
- k
^ permalink raw reply
* Re: [PATCH 01/12] pata_mpc52xx: use linux/of_platform.h instead of asm
From: Stephen Rothwell @ 2008-06-28 7:34 UTC (permalink / raw)
To: Grant Likely; +Cc: ppc-dev, Tejun Heo, Jeff Garzik
In-Reply-To: <fa686aa40806272231s69a895afv61877729acbac7fb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On Fri, 27 Jun 2008 22:31:54 -0700 "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> On Thu, Jun 26, 2008 at 11:37 PM, Jeff Garzik <jeff@garzik.org> wrote:
> > Stephen Rothwell wrote:
> >>
> >> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >> ---
> >> drivers/ata/pata_mpc52xx.c | 2 +-
> >
> > ACK. send it via an arch tree
>
> I'll pick it up.
Thanks, Grant.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings
From: Bart Van Assche @ 2008-06-28 6:51 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
When compiling kernel modules for ppc that include <linux/spinlock.h>, gcc
prints a warning message every time it encounters a function declaration where
the inline keyword appears after the return type. The patch below makes sure
that the order of the inline keyword and the return type is as gcc expects it.
Additionally, the __inline__ keyword is replaced by inline, as checkpatch
expects.
Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
diff -uprN orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h linux-2.6.25.9/include/asm-powerpc/spinlock.h
--- orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h 2008-06-24 23:09:06.000000000 +0200
+++ linux-2.6.25.9/include/asm-powerpc/spinlock.h 2008-06-28 08:34:52.000000000 +0200
@@ -53,7 +53,7 @@
* This returns the old value in the lock, so we succeeded
* in getting the lock if the return value is 0.
*/
-static __inline__ unsigned long __spin_trylock(raw_spinlock_t *lock)
+static inline unsigned long __spin_trylock(raw_spinlock_t *lock)
{
unsigned long tmp, token;
@@ -72,7 +72,7 @@ static __inline__ unsigned long __spin_t
return tmp;
}
-static int __inline__ __raw_spin_trylock(raw_spinlock_t *lock)
+static inline int __raw_spin_trylock(raw_spinlock_t *lock)
{
CLEAR_IO_SYNC;
return __spin_trylock(lock) == 0;
@@ -103,7 +103,7 @@ extern void __rw_yield(raw_rwlock_t *loc
#define SHARED_PROCESSOR 0
#endif
-static void __inline__ __raw_spin_lock(raw_spinlock_t *lock)
+static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
CLEAR_IO_SYNC;
while (1) {
@@ -118,7 +118,8 @@ static void __inline__ __raw_spin_lock(r
}
}
-static void __inline__ __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned long flags)
+static inline
+void __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned long flags)
{
unsigned long flags_dis;
@@ -138,7 +139,7 @@ static void __inline__ __raw_spin_lock_f
}
}
-static __inline__ void __raw_spin_unlock(raw_spinlock_t *lock)
+static inline void __raw_spin_unlock(raw_spinlock_t *lock)
{
SYNC_IO;
__asm__ __volatile__("# __raw_spin_unlock\n\t"
@@ -179,7 +180,7 @@ extern void __raw_spin_unlock_wait(raw_s
* This returns the old value in the lock + 1,
* so we got a read lock if the return value is > 0.
*/
-static long __inline__ __read_trylock(raw_rwlock_t *rw)
+static inline long __read_trylock(raw_rwlock_t *rw)
{
long tmp;
@@ -203,7 +204,7 @@ static long __inline__ __read_trylock(ra
* This returns the old value in the lock,
* so we got the write lock if the return value is 0.
*/
-static __inline__ long __write_trylock(raw_rwlock_t *rw)
+static inline long __write_trylock(raw_rwlock_t *rw)
{
long tmp, token;
@@ -223,7 +224,7 @@ static __inline__ long __write_trylock(r
return tmp;
}
-static void __inline__ __raw_read_lock(raw_rwlock_t *rw)
+static inline void __raw_read_lock(raw_rwlock_t *rw)
{
while (1) {
if (likely(__read_trylock(rw) > 0))
@@ -237,7 +238,7 @@ static void __inline__ __raw_read_lock(r
}
}
-static void __inline__ __raw_write_lock(raw_rwlock_t *rw)
+static inline void __raw_write_lock(raw_rwlock_t *rw)
{
while (1) {
if (likely(__write_trylock(rw) == 0))
@@ -251,17 +252,17 @@ static void __inline__ __raw_write_lock(
}
}
-static int __inline__ __raw_read_trylock(raw_rwlock_t *rw)
+static inline int __raw_read_trylock(raw_rwlock_t *rw)
{
return __read_trylock(rw) > 0;
}
-static int __inline__ __raw_write_trylock(raw_rwlock_t *rw)
+static inline int __raw_write_trylock(raw_rwlock_t *rw)
{
return __write_trylock(rw) == 0;
}
-static void __inline__ __raw_read_unlock(raw_rwlock_t *rw)
+static inline void __raw_read_unlock(raw_rwlock_t *rw)
{
long tmp;
@@ -278,7 +279,7 @@ static void __inline__ __raw_read_unlock
: "cr0", "memory");
}
-static __inline__ void __raw_write_unlock(raw_rwlock_t *rw)
+static inline void __raw_write_unlock(raw_rwlock_t *rw)
{
__asm__ __volatile__("# write_unlock\n\t"
LWSYNC_ON_SMP: : :"memory");
^ permalink raw reply
* Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Grant Likely @ 2008-06-28 5:49 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-13-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/platform/generic/system.dts | 300 +++++++++++++++++++++++++++
> 1 files changed, 300 insertions(+), 0 deletions(-)
> create mode 100644 arch/microblaze/platform/generic/system.dts
Since this is a generated file, and entirely bitstream specific, does
it make sense to include it in the kernel tree? If it does, then is
it produced from one of the Xilinx reference designs? Can you add
documentation to the header that specifies exactly which design
version this .dts is for?
>
> diff --git a/arch/microblaze/platform/generic/system.dts b/arch/microblaze/platform/generic/system.dts
> new file mode 100644
> index 0000000..724a037
> --- /dev/null
> +++ b/arch/microblaze/platform/generic/system.dts
> @@ -0,0 +1,300 @@
> +/*
> + * (C) Copyright 2007-2008 Xilinx, Inc.
> + * (C) Copyright 2007-2008 Michal Simek
> + *
> + * Michal SIMEK <monstr@monstr.eu>
If this is a generated file, then is this copyright notice even appropriate?
> + *
> + * 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
I don't this whole large legal block is necessary. Unless specified
otherwise in the comment block, I believe GPL licencing is pretty much
assumed and so the above three copyrights should be redundant.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 01/12] pata_mpc52xx: use linux/of_platform.h instead of asm
From: Grant Likely @ 2008-06-28 5:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Stephen Rothwell, Tejun Heo, ppc-dev
In-Reply-To: <48648AA2.2020204@garzik.org>
On Thu, Jun 26, 2008 at 11:37 PM, Jeff Garzik <jeff@garzik.org> wrote:
> Stephen Rothwell wrote:
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> drivers/ata/pata_mpc52xx.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> I am not sure who wants to take this.
>>
>> diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
>> index bc79df6..a9e8273 100644
>> --- a/drivers/ata/pata_mpc52xx.c
>> +++ b/drivers/ata/pata_mpc52xx.c
>> @@ -16,10 +16,10 @@
>> #include <linux/slab.h>
>> #include <linux/delay.h>
>> #include <linux/libata.h>
>> +#include <linux/of_platform.h>
>> #include <asm/types.h>
>> #include <asm/prom.h>
>> -#include <asm/of_platform.h>
>> #include <asm/mpc52xx.h>
>
> ACK. send it via an arch tree
I'll pick it up.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] update crypto node definition and device tree instances
From: Grant Likely @ 2008-06-28 5:29 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20080627115243.d76e0814.kim.phillips@freescale.com>
On Fri, Jun 27, 2008 at 9:52 AM, Kim Phillips
<kim.phillips@freescale.com> wrote:
> delete obsolete device-type property, delete model property
> (use compatible property instead), prepend "fsl," to Freescale
> specific properties. Add nodes to device trees that are missing them,
> and fix broken property values in other trees.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Are there any drivers in mainline which use this node? Do these
changes break backwards compatibility with already deployed boards?
(I know; this patch doesn't change any code; but I'm asking whether
the driver will need to support both old and new bindings).
> ---
> diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts b/arch/powerpc/boot/dts/mpc8272ads.dts
> index 46e2da3..9a3881d 100644
> --- a/arch/powerpc/boot/dts/mpc8272ads.dts
> +++ b/arch/powerpc/boot/dts/mpc8272ads.dts
> @@ -226,22 +226,15 @@
> compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
> };
>
> -/* May need to remove if on a part without crypto engine */
> crypto@30000 {
> - device_type = "crypto";
> - model = "SEC2";
> - compatible = "fsl,mpc8272-talitos-sec2",
> - "fsl,talitos-sec2",
> - "fsl,talitos",
> - "talitos";
> + compatible = "fsl,sec1.0";
Should really be encoding the SoC model in the compatible property.
At the very least, compatible should be:
compatible = "fsl,mpc8272-sec", "fsl,sec1.0";
I'm really don't like "fsl,sec1.0" or any of the variants as a
compatible property either because it can easily be abused (it's not
anchored to a specific physical part so the meaning can shift over
time); but that is another argument and it is well documented in other
email threads (http://thread.gmane.org/gmane.linux.ports.ppc64.devel/38977/focus=39147)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 59/60] microblaze_v4: syscall_table.S and unistd.h
From: Paul Mundt @ 2008-06-28 5:10 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-60-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:30:28PM +0200, monstr@seznam.cz wrote:
> +#define __NR_semtimedop 325
> +#define __NR_timerfd_settime 326
> +#define __NR_timerfd_gettime 327
> +
> +#ifdef __KERNEL__
> +
> +#define __NR_syscalls 327
> +
Off-by-1 on __NR_syscalls, this should be 328.
^ permalink raw reply
* Re: [PATCH 30/60] microblaze_v4: support for a.out
From: Paul Mundt @ 2008-06-28 5:04 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-31-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:29:59PM +0200, monstr@seznam.cz wrote:
> From: Michal Simek <monstr@monstr.eu>
>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 include/asm-microblaze/a.out.h
>
a.out is going away for the users that don't care, so you may wish to
make sure all of your a.out references are also gone so you don't have to
patch this a second time.
^ permalink raw reply
* Re: [PATCH 29/60] microblaze_v4: traps support
From: Paul Mundt @ 2008-06-28 5:03 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-30-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:29:58PM +0200, monstr@seznam.cz wrote:
> +static int kstack_depth_to_print = 24;
> +
x86 has a sysctl for this. It may be worth making this non-static and
generalizing the ifdef case. Plenty of other architectures could benefit
from this also.
> +void show_trace(struct task_struct *task, unsigned long *stack)
> +{
> + unsigned long addr;
> +
> + if (!stack)
> + stack = (unsigned long *)&stack;
> +
> + printk(KERN_INFO "Call Trace: ");
> +#ifdef CONFIG_KALLSYMS
> + printk(KERN_INFO "\n");
> +#endif
> + while (!kstack_end(stack)) {
> + addr = *stack++;
> + if (__kernel_text_address(addr)) {
> + printk(KERN_INFO "[<%08lx>] ", addr);
> + print_symbol("%s\n", addr);
Use print_ip_sym() here for future-proofing.
> + }
> + }
> + printk(KERN_INFO "\n");
And here you can:
if (!tsk)
tsk = current;
debug_show_held_locks(tsk);
> +}
> +
for when you get around to implementing lockdep.
^ permalink raw reply
* [PATCH v2] powerpc/bootwrapper: Add documentation of boot wrapper targets
From: Grant Likely @ 2008-06-28 5:04 UTC (permalink / raw)
To: paulus, linuxppc-dev, john.linn, stephen.neuendorffer
From: Grant Likely <grant.likely@secretlab.ca>
There have been many questions on and off the mailing list about how
exactly the bootwrapper is used for embedded targets. Add some
documentation and help text to try and clarify the system.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Documentation/powerpc/bootwrapper.txt | 141 +++++++++++++++++++++++++++++++++
arch/powerpc/Makefile | 15 +++-
arch/powerpc/boot/wrapper | 4 +
3 files changed, 159 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/bootwrapper.txt b/Documentation/powerpc/bootwrapper.txt
new file mode 100644
index 0000000..a03d73c
--- /dev/null
+++ b/Documentation/powerpc/bootwrapper.txt
@@ -0,0 +1,141 @@
+The PowerPC boot wrapper
+------------------------
+Copyright (C) Secret Lab Technologies Ltd.
+
+PowerPC image targets compresses and wraps the kernel image (vmlinux) with
+a boot wrapper to make it usable by the system firmware. There is no
+standard PowerPC firmware interface, so the boot wrapper is designed to
+be adaptable for each kind of image that needs to be built.
+
+The boot wrapper can be found in the arch/powerpc/boot/ directory. The
+Makefile in that directory has targets for all the available image types.
+The different image types are used to support all of the various firmware
+interfaces found on PowerPC platforms. OpenFirmware is the most commonly
+used firmare type on general purpose PowerPC systems from Apple, IBM and
+others. U-Boot is typically found on embedded PowerPC hardware, but there
+are a handful of other firmware implementations which are also popular. Each
+firmware interface requires a different image format.
+
+The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
+it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
+image. The details of the build system is discussed in the next section.
+Currently, the following image format targets exist:
+
+ cuImage.%: Backwards compatible uImage for older version of
+ U-Boot (for versions that don't understand the device
+ tree). This image embeds a device tree blob inside
+ the image. The bootwrapper, kernel and device tree
+ are all embedded inside the U-Boot uImage file format
+ with bootwrapper code that extracts data from the old
+ bd_info structure and loads the data into the device
+ tree before jumping into the kernel.
+ Because of the series of #ifdefs found in the
+ bd_info structure used in the old U-Boot interfaces,
+ cuImages are platform specific. Each specific
+ U-Boot platform has a different platform init file
+ which populates the embedded device tree with data
+ from the platform specific bd_info file. The platform
+ specific cuImage platform init code can be found in
+ arch/powerpc/boot/cuboot.*.c. Selection of the correct
+ cuImage init code for a specific board can be found in
+ the wrapper structure.
+ dtbImage.%: Similar to zImage, except device tree blob is embedded
+ inside the image instead of provided by firmware. The
+ output image file can be either an elf file or a flat
+ binary depending on the platform.
+ dtbImages are used on systems which do not have an
+ interface for passing a device tree directly.
+ dtbImages are similar to simpleImages except that
+ dtbImages have platform specific code for extracting
+ data from the board firmware, but simpleImages do not
+ talk to the firmware at all.
+ PlayStation 3 support uses dtbImage. So do Embedded
+ Planet boards using the PlanetCore firmware. Board
+ specific initialization code is typically found in a
+ file named arch/powerpc/boot/<platform>.c; but this
+ can be overridden by the wrapper script.
+ simpleImage.%: Firmware independent compressed image that does not
+ depend on any particular firmware interface and embeds
+ a device tree blob. This image is a flat binary that
+ can be loaded to any location in RAM and jumped to.
+ Firmware cannot pass any configuration data to the
+ kernel with this image type and it depends entirely on
+ the embedded device tree for all information.
+ The simpleImage is useful for booting systems with
+ an unknown firmware interface or for booting from
+ a debugger when no firmware is present (such as on
+ the Xilinx Virtex platform). The only assumption that
+ simpleImage makes is that RAM is correctly initialized
+ and that the MMU is either off or has RAM mapped to
+ base address 0.
+ simpleImage also supports inserting special platform
+ specific initialization code to the start of the bootup
+ sequence. The virtex405 platform uses this feature to
+ ensure that the cache is invalidated before caching
+ is enabled. Platform specific initialization code is
+ added as part of the wrapper script and is keyed on
+ the image target name. For example, all
+ simpleImage.virtex405-* targets will add the
+ virtex405-head.S initialization code (This also means
+ that the dts file for virtex405 targets should be
+ named (virtex405-<board>.dts). Search the wrapper
+ script for 'virtex405' and see the file
+ arch/powerpc/boot/virtex405-head.S for details.
+ treeImage.%; Image format for used with OpenBIOS firmware found
+ on some ppc4xx hardware. This image embeds a device
+ tree blob inside the image.
+ uImage: Native image format used by U-Boot. The uImage target
+ does not add any boot code. It just wraps a compressed
+ vmlinux in the uImage data structure. This image
+ requires a version of U-Boot that is able to pass
+ a device tree to the kernel at boot. If using an older
+ version of U-Boot, then you need to use a cuImage
+ instead.
+ zImage.%: Image format which does not embed a device tree.
+ Used by OpenFirmware and other firmware interfaces
+ which are able to supply a device tree. This image
+ expects firmware to provide the device tree at boot.
+ Typically, if you have general purpose PowerPC
+ hardware then you want this image format.
+
+Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
+and cuImage) all generate the device tree blob from a file in the
+arch/powerpc/boot/dts/ directory. The Makefile selects the correct device
+tree source based on the name of the target. Therefore, if the kernel is
+built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
+build system will use arch/powerpc/boot/dts/walnut.dts to build
+treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
+the simpleImage.virtex405-ml403.
+
+Two special targets called 'zImage' and 'zImage.initrd' also exist. These
+targets build all the default images as selected by the kernel configuration.
+Default images are selected by the boot wrapper Makefile
+(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look
+at the Makefile to see which default image targets are available.
+
+How it is built
+---------------
+arch/powerpc is designed to support multiplatform kernels, which means
+that a single vmlinux image can be booted on many different target boards.
+It also means that the boot wrapper must be able to wrap for many kinds of
+images on a single build. The design decision was made to not use any
+conditional compilation code (#ifdef, etc) in the boot wrapper source code.
+All of the boot wrapper pieces are buildable at any time regardless of the
+kernel configuration. Building all the wrapper bits on every kernel build
+also ensures that obscure parts of the wrapper are at the very least compile
+tested in a large variety of environments.
+
+The wrapper is adapted for different image types at link time by linking in
+just the wrapper bits that are appropriate for the image type. The 'wrapper
+script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
+is responsible for selecting the correct wrapper bits for the image type.
+The arguments are well documented in the script's comment block, so they
+are not repeated here. However, it is worth mentioning that the script
+uses the -p (platform) argument as the main method of deciding which wrapper
+bits to compile in. Look for the large 'case "$platform" in' block in the
+middle of the script. This is also the place where platform specific fixups
+can be selected by changing the link order.
+
+In particular, care should be taken when working with cuImages. cuImage
+wrapper bits are very board specific and care should be taken to make sure
+the target you are trying to build is supported by the wrapper bits.
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b7d4c4c..754c7eb 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -169,12 +169,25 @@ bootwrapper_install %.dtb:
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
define archhelp
- @echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
+ @echo '* zImage - Build default images selected by kernel config'
+ @echo ' zImage.* - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)'
+ @echo ' uImage - U-Book native image format'
+ @echo ' cuImage.<dt> - Backwards compatible U-Boot image for older'
+ @echo ' versions which do not support device trees'
+ @echo ' dtbImage.<dt> - zImage with an embedded device tree blob'
+ @echo ' simpleImage.<dt> - Firmware independant image.'
+ @echo ' treeImage.<dt> - Support for older IBM 4xx firmware (not U-Boot)'
@echo ' install - Install kernel using'
@echo ' (your) ~/bin/installkernel or'
@echo ' (distribution) /sbin/installkernel or'
@echo ' install to $$(INSTALL_PATH) and run lilo'
@echo ' *_defconfig - Select default config from arch/$(ARCH)/configs'
+ @echo ''
+ @echo ' Targets with <dt> embed a device tree blob inside the image'
+ @echo ' These targets support board with firmware that does not'
+ @echo ' support passing a device tree directly. Replace <dt> with the'
+ @echo ' name of a dts file from the arch/$(ARCH)/boot/dts/ directory'
+ @echo ' (minus the .dts extension).'
endef
install:
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d6c96d9..7cd4182 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -203,6 +203,10 @@ simpleboot-virtex405-*)
platformo="$object/virtex405-head.o $object/simpleboot.o"
binary=y
;;
+simpleboot-*)
+ platformo="$object/simpleboot.o"
+ binary=y
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
^ permalink raw reply related
* Re: [PATCH 28/60] microblaze_v4: ptrace support
From: Paul Mundt @ 2008-06-28 4:59 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-29-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:29:57PM +0200, monstr@seznam.cz wrote:
> +long arch_ptrace(struct task_struct *child, long request, long addr, long data)
> +{
> + int rval;
> +
> + switch (request) {
> + unsigned long val, copied;
> +
> + case PTRACE_PEEKTEXT: /* read word at location addr. */
> + case PTRACE_PEEKDATA:
> + pr_debug("PEEKTEXT/PEEKDATA at %08lX\n", addr);
> + copied = access_process_vm(child, addr, &val, sizeof(val), 0);
> + rval = -EIO;
> + if (copied != sizeof(val))
> + break;
> + rval = put_user(val, (unsigned long *)data);
> + goto out;
> +
> + case PTRACE_POKETEXT: /* write the word at location addr. */
> + case PTRACE_POKEDATA:
> + pr_debug("POKETEXT/POKEDATA to %08lX\n", addr);
> + rval = 0;
> + if (access_process_vm(child, addr, &data, sizeof(data), 1)
> + == sizeof(data))
> + break;
> + rval = -EIO;
> + goto out;
> +
You can use generic_ptrace_peekdata()/generic_ptrace_pokedata() for
these. Or kill them off and let ptrace_request() handle it.
> + /* Continue and stop at next (return from) syscall */
> + case PTRACE_SYSCALL:
> + pr_debug("PTRACE_SYSCALL\n");
> + case PTRACE_SINGLESTEP:
> + pr_debug("PTRACE_SINGLESTEP\n");
> + /* Restart after a signal. */
> + case PTRACE_CONT:
> + pr_debug("PTRACE_CONT\n");
> + rval = -EIO;
> + if (!valid_signal(data))
> + break;
> +
> + if (request == PTRACE_SYSCALL)
> + set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
> + else
> + clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
> +
> + child->exit_code = data;
> + pr_debug("wakeup_process\n");
> + wake_up_process(child);
> + rval = 0;
> + break;
> +
This is a reimplementation of ptrace_resume(), you can kill all of these
off as well, as they are also handled generically these days.
> + /*
> + * make the child exit. Best I can do is send it a sigkill.
> + * perhaps it should be put in the status that it wants to
> + * exit.
> + */
> + case PTRACE_KILL:
> + pr_debug("PTRACE_KILL\n");
> + rval = 0;
> + if (child->exit_state == EXIT_ZOMBIE) /* already dead */
> + break;
> + child->exit_code = SIGKILL;
> + wake_up_process(child);
> + break;
> +
> + case PTRACE_DETACH: /* detach a process that was attached. */
> + pr_debug("PTRACE_DETACH\n");
> + rval = ptrace_detach(child, data);
> + break;
> +
> + default:
> + rval = -EIO;
> + goto out;
> + }
> + out:
> + return rval;
> +}
> +
Or rather, they would be, if you defaulted to ptrace_request() for the
unhandled cases.
^ permalink raw reply
* Re: [PATCH 25/60] microblaze_v4: process and init task function
From: Paul Mundt @ 2008-06-28 4:50 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-26-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:29:54PM +0200, monstr@seznam.cz wrote:
> +void (*pm_power_off)(void) = NULL;
> +EXPORT_SYMBOL(pm_power_off);
> +
> +void cpu_idle(void)
> +{
> + set_thread_flag(TIF_POLLING_NRFLAG);
> +
> + while (1) {
> + while (!need_resched())
> + cpu_relax();
> +
> + preempt_enable_no_resched();
> + schedule();
> + preempt_disable();
> + }
> +}
> +
A couple things to note here. You have a pm_power_off, but no pm_idle.
You set TIF_POLLING_NRFLAG but don't have any explicit clearing and
resetting of it if the CPU is sleeping. In the cpu_relax() case this is
ok, but if you have a cpu_sleep() you will want to use in the SMP case,
you will need to handle it explicitly.
Beyond that, you may also want to stub in the
tick_nohz_stop_sched_tick()/tick_nohz_restart_sched_tick() calls, then
when you implement the generic clockevents you will already have the
tickless bits in place.
check_pgt_cache() is also helpful here for quicklist trimming, though you
may not care if you never plan to have an MMU.
You can look at arch/sh/kernel/process_32.c for examples.
^ permalink raw reply
* Re: [PATCH 24/60] microblaze_v4: asm-offsets
From: Paul Mundt @ 2008-06-28 4:43 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-25-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:29:53PM +0200, monstr@seznam.cz wrote:
> +#include <linux/stddef.h>
> +#include <linux/sched.h>
> +#include <linux/kernel_stat.h>
> +#include <linux/ptrace.h>
> +#include <linux/hardirq.h>
> +#include <linux/thread_info.h>
> +
> +#define DEFINE(sym, val) asm volatile("\n->" #sym " %0 " #val : : "i" (val))
> +#define BLANK() asm volatile("\n->" : :)
> +
There are generic definitions for these these days, include linux/kbuild.h.
^ permalink raw reply
* Re: [PATCH 01/60] microblaze_v4: Kconfig patches
From: Paul Mundt @ 2008-06-28 4:38 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-2-git-send-email-monstr@seznam.cz>
On Thu, Jun 26, 2008 at 02:29:30PM +0200, monstr@seznam.cz wrote:
> +config HZ
> + int
> + default 100
> +
Consider using kernel/Kconfig.hz instead.
> +config DEFCONFIG_LIST
> + string
> + default "arch/$ARCH/defconfig"
> +
init/Kconfig already has quite a few reasonable defaults for this,
including the case you specify. You can kill this off.
> +source "init/Kconfig"
> +
> +source "arch/microblaze/platform/Kconfig.platform"
> +
> +menu "Processor type and features"
> +
> +config PREEMPT
> + bool "Preemptible Kernel"
> + help
> + This option reduces the latency of the kernel when reacting to
> + real-time or interactive events by allowing a low priority process to
> + be preempted even if it is in kernel mode executing a system call.
> + This allows applications to run more reliably even when the system is
> + under load.
> +
> + Say Y here if you are building a kernel for a desktop, embedded
> + or real-time system. Say N if you are unsure.
> +
kernel/Kconfig.preempt
> +config LARGE_ALLOCS
> + bool "Allow allocating large blocks (> 1MB) of memory"
> + help
> + Allow the slab memory allocator to keep chains for very large
> + memory sizes - up to 32MB. You may need this if your system has
> + a lot of RAM, and you need to able to allocate very large
> + contiguous chunks. If unsure, say N.
> +
Legacy bits, not used anywhere anymore.
> +comment "Boot options"
> +
> +config CMDLINE
> + string "Default kernel command string"
> + default ""
> + help
> + On some architectures there is currently no way for the boot loader
> + to pass arguments to the kernel. For these architectures, you should
> + supply some command-line options at build time by entering them
> + here.
> +
> +config CMDLINE_FORCE
> + bool "Force default kernel command string"
> + help
> + Set this to have arguments from the default kernel command string
> + override those passed by the boot loader.
> +
Consider CMDLINE_BOOL/CMDLINE for consistency with other architectures.
It doesn't make much sense to expose CMDLINE if you don't intend to use
it. Especially when people wonder why their CMDLINE changes are being
clobbered by the boot loader.
^ permalink raw reply
* Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets
From: Grant Likely @ 2008-06-28 4:22 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, Scott Wood, paulus, John Linn, petermendham
In-Reply-To: <20080626201643.D01221788058@mail223-wa4.bigfish.com>
On Thu, Jun 26, 2008 at 1:16 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Forgive my ignorance here, but what specifically does this imply? As
> far as I can tell, generally speaking, some of the board-specific
> information is passed into the boot wrapper, which then stuffs it into
> the device tree.
Yes, you are correct. I'll fill out the documentation more here.
>> uImage is for device-tree aware U-Boot versions
>
> And this differs from above because it gets a device tree passed in,
> which uboot has already stuffed correctly.
Correct.
>> dtbImage is used for boards that can take an ELF zImage, but still
> need
>> a dtb provided.
>>
>> simpleImage, not sure here.
>
> So both of these are elfs... but how do they differ? Is it only in how
> the right head.s file gets picked up?
simpleImage is not an elf. Its a raw position-independent binary
which can be loaded anywhere in RAM.
Some dtbImages are elfs; but there are a flat binaries. The main
difference is that all simpleImages assume that firmware provides
nothing interesting; but the flat dtbImages have custom code for
extracting a little bit of data out of the boards firmware.
It's all a bit of a confusing mess. It might be a good idea to rework
all the image names to stuff not so non-obvious, but I'm not sure the
best way to go about it. There is a lot of historical stuff in there
where the various 'zImage.*' targets grew and morphed over time in
ways that are hard to follow. It may make more sense to change the
flat-binary dtbImages to be simpleImages instead with overrides for
specific boards (just like is done for virtex405-*). ps3 is the other
major user of dtbImage. I created the whole dtbImage stuff in the
first place to eliminate overloaded makefile targets where some
zImage% target were providing a device tree and other zImage% targets
were not. Splitting dtb-provided from dtb-not-provided targets
clarified the Makefile quite a bit. dtbImage is not a fantastic name,
but I needed something different from zImage for images with an
embedded device tree.
Looking at the Makefile, dtbImage and simpleImage targets are
virtually identical. Perhaps it would be best to merge the targets
and deal with all the differences in the wrapper script (with the
default to just use simpleboot.S as the init code). Thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: dtc: Address an assortment of portability problems
From: David Gibson @ 2008-06-28 0:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Benno Rice
In-Reply-To: <4864FECF.3010304@freescale.com>
On Fri, Jun 27, 2008 at 09:53:03AM -0500, Scott Wood wrote:
> David Gibson wrote:
>> On Thu, Jun 26, 2008 at 10:25:28AM -0500, Scott Wood wrote:
>>> On Thu, Jun 26, 2008 at 11:03:49AM +1000, David Gibson wrote:
>>>> - the endian handling functions in libfdt_env.h, based on
>>>> endian.h and byteswap.h are replaced with some portable open-coded
>>>> versions. Unfortunately, these result in fairly crappy code when
>>>> compiled, but as far as I can determine there doesn't seem to be any
>>>> POSIX, SUS or de facto standard way of determining endianness at
>>>> compile time, nor standard names for byteswapping functions.
>>> Since device-tree and network byte order happen to be the same, we could use
>>> ntohl/htonl.
>>
>> Not for the 64-bit version.
>
> Why? They operate on uint32_t despite the "l" in the name, and there
> are no 64-bit fields in the device tree...
Yes there are. The memory reservations. We have and need
fdt64_to_cpu().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox