* Re: Please pull linux-2.6-mpc52xx.git
From: Richard Purdie @ 2008-03-18 16:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803180747u532f6a0bq1e64e01662bdb6bd@mail.gmail.com>
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> > Grant,
> >
> > Yes, the Motion-PRO LED driver has been reworked and posted:
> > http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>
> Okay, I've taken another look at the driver and I've figured out what
> has been bothering me about it. It seems to me that the motion pro
> led driver is just the first of many that we will see (seeing as some
> many people find the blinking lights rather soothing) and it's a non
> trivial amount of code.
>
> (Note: I'm not actually opposed to this driver if Richard is okay with
> it; but I do think that in the long term we should move towards a more
> generic approach)
>
> In essence, this driver sets up two GPIO pins to drive LEDs. A pretty
> common approach for putting LEDs on a board. In this case each GPIO
> bank only contains 1 pin; but I imagine that on other boards there
> will be multiple pins in a GPIO bank, only some of which actually used
> for blinking LEDs.
>
> I've started thinking that it would be better to split things up in
> the device tree to have one node for each GPIO block and a single LED
> node that maps LEDs to gpio pins. That would allow a common driver to
> be written for all GPIO driven LEDs with a single block of device tree
> parsing code. Plus, it allows other devices to use GPIO pins within
> the same block (not an issue for the motion pro board; but when other
> boards start coming on-line it would allow us to reduce the amount of
> board specific code). Finally, it means that the timer pin GPIO
> driver can be used for more than just flashing an attached LED.
I don't mind having a specific driver but I don't know anything about
the hardware its creating the interface for so I need the community's
help with that part. There is drivers/leds/leds-gpio.c if that would
work better.
Regards,
Richard
^ permalink raw reply
* Re: simple MPC5200B system
From: Andre Schwarz @ 2008-03-18 16:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-ppc list
In-Reply-To: <fa686aa40803180921l654d6336udd285cf13e4138b5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4010 bytes --]
Grant Likely schrieb:
> On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz
> <andre.schwarz@matrix-vision.de> wrote:
>
>> I've read some discussions about the "interrupt-map" attribute of the pci
>> node. I tried to follow Ben and David in their explanations - obviously I
>> didn't really get it.
>> Looks like there are a lot of people outside who need some enlightenment
>> ... including me, of course.
>>
>> Maybe you can clarify this ?
>>
>> Taken from motionpro.dts ...
>>
>>
>
> First, you also need to look at interrupt-map-mask to interpret these
> values; from motionpro.dts:
>
> interrupt-map-mask = <f800 0 0 7>;
>
> which is applied to the unit interrupt specifier to figure out how to
> map onto the interrupt controller. The /size/ of this field is
> obtained by adding #address-cells with #interrupt-cells. (3+1=4).
>
> 'f8' refers to the upper 5 bits of the interrupt identifier which is a
> number from 0-31 which relates to the IDSEL line as you guessed. The
> '7' covers the lower 3 bits of the interrupt specifier which can be 1,
> 2, 3 or 4.
>
> The 120 bits in the middle are irrelevant, so interrupt-map-mask
> leaves them as zeros.
>
>
ok.
>> interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
>> c000 0 0 2 &mpc5200_pic 1 1 3
>> c000 0 0 3 &mpc5200_pic 1 2 3
>> c000 0 0 4 &mpc5200_pic 1 3 3
>>
>> c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
>> c800 0 0 2 &mpc5200_pic 1 2 3
>> c800 0 0 3 &mpc5200_pic 1 3 3
>> c800 0 0 4 &mpc5200_pic 0 0 3>;
>>
>>
>> First parameter seems to be the slot number, i.e. IDSEL line of the PCI
>> device.
>> How is this value coded ? Are these the bits 15..11 of the configuration
>> address ?
>>
>
> I don't remember how this is encoded. On the lite5200, idsel is wired
> to d0 and d1 for slots 1 and 2 respectively, yet these values suggest
> slots 24 and 25. I'll need to look at this again later.
>
>
"pci info" from u-boot shows both devices (e1000 NIC + FPGA)
00 0a 4d56 1000 ff00 03 -> bus "0" , slot "0a", "irq 3"
00 0b 8086 1078 0200 02 -> bus "0" , slot "0b", "irq 2"
IDSEL mapping of MPC5200 is "0b0_1011" for slot 0xb and "0b0_1010" for
slot 0xa.
Using those 5 bits <<= 3 for the first cell gives "5800" and "5000"
>> 2nd + 3rd paramter : no clue ! can you explain ?
>>
>
> first 3 cells are the unit address and is #address-cells large. Only
> the first cell contains real data.
>
>
ok.
>> 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only
>> INT_A. Do we need 4 entries in any case ?
>>
>
> you only need entries for irq lines that are wired up. If your board
> does not wire up _B, _C and _D, then don't have an entry for them.
> However, if they are wired up then you should describe them.
>
>
ok. I only have INT_A.
>> 5th : ok - parent pic
>>
>
> Correct.
>
>
>> 6th ... 8th : IRQ representation of the parent pic, which gives :
>>
>> 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins
>> 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have
>> number 1..3 inside MAIN level.
>> 8th : should be 3 = "level low" which is default for PCI.
>>
>
> Correct.
>
> There is also some good information here:
> http://playground.sun.com/1275/practice/imap/imap0_9d.pdf
>
> Cheers,
> g.
>
>
using the following "interrupt-map" give me two working PCI devices with
working interrupts ... :-)
interrupt-map = <5800 0 0 1 &mpc5200_pic 1 2 3 // e1000
5000 0 0 1 &mpc5200_pic 1 3 3>;// FPGA
Thanks for your explanations !
regards,
Andre
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
[-- Attachment #2: Type: text/html, Size: 5899 bytes --]
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-03-18 16:53 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev
In-Reply-To: <1205858510.7500.35.camel@dax.rpnet.com>
On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
>
> On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote:
> I don't mind having a specific driver but I don't know anything about
> the hardware its creating the interface for so I need the community's
> help with that part. There is drivers/leds/leds-gpio.c if that would
> work better.
Yes, I think that would be the right approach. We would need to add
the binding code to translate from the OF device tree to the leds-gpio
driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Scott Wood @ 2008-03-18 16:56 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Stephen Rothwell, Heiko Schocher, linuxppc-dev
In-Reply-To: <20080318161957.766A124349@gemini.denx.de>
Wolfgang Denk wrote:
> Dear Scott,
>
> in message <20080318151132.GA17402@ld0162-tx32.am.freescale.net> you wrote:
>> Well, the device tree is a mechanism for communicating from the firmware
>> to the kernel, and if we could control the firmware better we'd just make
>> it set the pins properly to begin with. :-)
>
> Is this just a comment, or do you oppose Heiko's suggestion?
It was intended more as a gentle nudge to set up the pins in firmware
when not constrained by existing firmwares in the field that must be
supported.
> Other uses of the device tree seem possible and reasonable, too. For
> example, we can use the device tree to configure the firmware (U-Boot
> in this case).
>
> Using the device tree to describe the pin configuration of the
> hardware sounds easier to me than hard-coding it in some source (or
> header) file - no matter if this is in the kernel and/or in the
> firmware.
>
> What do you think?
I'm fine with putting it in the device tree for firmware's benefit,
though I'm not sure I fully agree with the "easier" bit until we get
support for expressions and named constants in dts, so that the flags
would be less opaque.
-Scott
^ permalink raw reply
* Re: [PATCH v2] Make 83xx perfmon support selectable
From: Scott Wood @ 2008-03-18 17:05 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204934343-5235-1-git-send-email-afleming@freescale.com>
On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote:
> Not all e300 cores support the performance monitors, and the ones
> that don't will be confused by the mf/mtpmr instructions. This
> allows the support to be optional, so the 8349 can turn it off
> while the 8379 can turn it on. Sadly, those aren't config options,
> so it will be left to the defconfigs and the users to make that
> determination.
So does this mean we can't do multiplatform of something with perfmon and
something without perfmon? Seems like this should come from the device
tree, or PVR, or some other runtime check.
-Scott
^ permalink raw reply
* [PATCH][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely @ 2008-03-18 17:07 UTC (permalink / raw)
To: linuxppc-dev, john.linn, jwboyer, stephen.neuendorffer, scottwood
From: Grant Likely <grant.likely@secretlab.ca>
This target produces a flat binary rather than an ELF file,
fixes the entry point at the beginning of the image, and takes
a complete device tree with no fixups needed.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This has been tested on a Xilinx Virtex 4 target with the image loaded into
RAM via JTAG.
arch/powerpc/boot/Makefile | 9 +++-
arch/powerpc/boot/simpleboot.c | 84 ++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/virtex405-head.S | 30 +++++++++++++
arch/powerpc/boot/wrapper | 4 ++
4 files changed, 126 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..f6605fe 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,6 +40,7 @@ $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
+$(obj)/virtex405-head.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
@@ -64,7 +65,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c
+ cuboot-warp.c cuboot-85xx-cpm2.c simpleboot.c virtex405-head.S
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -305,6 +306,12 @@ $(obj)/uImage: vmlinux $(wrapperbits)
$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
+$(obj)/simpleImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
+
+$(obj)/simpleImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts)
+
$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
diff --git a/arch/powerpc/boot/simpleboot.c b/arch/powerpc/boot/simpleboot.c
new file mode 100644
index 0000000..86cd285
--- /dev/null
+++ b/arch/powerpc/boot/simpleboot.c
@@ -0,0 +1,84 @@
+/*
+ * The simple platform -- for booting when firmware doesn't supply a device
+ * tree or any platform configuration information.
+ * All data is extracted from an embedded device tree
+ * blob.
+ *
+ * Authors: Scott Wood <scottwood@freescale.com>
+ * Grant Likely <grant.likely@secretlab.ca>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008 Secret Lab Technologies Ltd.
+ *
+ * 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.
+ */
+
+#include "ops.h"
+#include "types.h"
+#include "io.h"
+#include "stdio.h"
+#include "libfdt/libfdt.h"
+
+BSS_STACK(4*1024);
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ const u32 *na, *ns, *reg, *timebase;
+ u64 memsize64;
+ int node, size, i;
+
+ /* Make sure FDT blob is sane */
+ if (fdt_check_header(_dtb_start) != 0)
+ fatal("Invalid device tree blob\n");
+
+ /* Find the #address-cells and #size-cells properties */
+ node = fdt_path_offset(_dtb_start, "/");
+ if (node < 0)
+ fatal("Cannot find root node\n");
+ na = fdt_getprop(_dtb_start, node, "#address-cells", &size);
+ if (!na || (size != 4))
+ fatal("Cannot find #address-cells property");
+ ns = fdt_getprop(_dtb_start, node, "#size-cells", &size);
+ if (!ns || (size != 4))
+ fatal("Cannot find #size-cells property");
+
+ /* Find the memory range */
+ node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
+ "memory", sizeof("memory"));
+ if (node < 0)
+ fatal("Cannot find memory node\n");
+ reg = fdt_getprop(_dtb_start, node, "reg", &size);
+ if (size < (*na+*ns) * sizeof(u32))
+ fatal("cannot get memory range\n");
+
+ /* Only interested in memory based at 0 */
+ for (i = 0; i < *na; i++)
+ if (*reg++ != 0)
+ fatal("Memory range is not based at address 0\n");
+
+ /* get the memsize and trucate it to under 4G on 32 bit machines */
+ memsize64 = 0;
+ for (i = 0; i < *ns; i++)
+ memsize64 = (memsize64 << 32) | *reg++;
+ if (sizeof(void *) == 4 && memsize64 >= 0x100000000ULL)
+ memsize64 = 0xffffffff;
+
+ /* finally, setup the timebase */
+ node = fdt_node_offset_by_prop_value(_dtb_start, -1, "device_type",
+ "cpu", sizeof("cpu"));
+ if (!node)
+ fatal("Cannot find cpu node\n");
+ timebase = fdt_getprop(_dtb_start, node, "timebase-frequency", &size);
+ if (timebase && (size == 4))
+ timebase_period_ns = 1000000000 / *timebase;
+
+ /* Now we have the memory size; initialize the heap */
+ simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32, 64);
+
+ /* prepare the device tree and find the console */
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
diff --git a/arch/powerpc/boot/virtex405-head.S b/arch/powerpc/boot/virtex405-head.S
new file mode 100644
index 0000000..3edb13f
--- /dev/null
+++ b/arch/powerpc/boot/virtex405-head.S
@@ -0,0 +1,30 @@
+#include "ppc_asm.h"
+
+ .text
+ .global _zimage_start
+_zimage_start:
+
+ /* PPC errata 213: needed by Virtex-4 FX */
+ mfccr0 0
+ oris 0,0,0x50000000@h
+ mtccr0 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.
+ */
+ mfdccr r9
+ cmplwi r9,0
+ bne 2f
+ lis r9,0
+ li r8,256
+ mtctr r8
+1: dccci r0,r9
+ addi r9,r9,0x20
+ bdnz 1b
+2: b _zimage_start_lib
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d50e498..c9e092b 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -199,6 +199,10 @@ adder875-redboot)
platformo="$object/fixed-head.o $object/redboot-8xx.o"
binary=y
;;
+simpleboot-virtex405-*)
+ platformo="$object/virtex405-head.o $object/simpleboot.o"
+ binary=y
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
^ permalink raw reply related
* RE: Kernel stack overflow in process xxxx
From: Nicholas Mc Guire @ 2008-03-18 18:12 UTC (permalink / raw)
To: jay_chen; +Cc: linuxppc-embedded
In-Reply-To: <018401c887ff$087fc2a0$016ffea9@alphajay>
> By the way, is there any skill/tool to avoid/detect/check this kind of
> problem?
>
did you try:
Kernel hacking --->
...
[*] Kernel debugging
...
[*] Check for stack overflows
[*] Stack utilization instrumentation
the last one depends on SysRq though.
In any case it would be interesting to know if these tools can help find
problems of this kind - so if it does not help - pleas let me/us know.
hofrat
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-03-18 17:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080311172429.GF7727@localhost.localdomain>
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
> + Required properties:
> + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> + GTMs).
> + - reg : should contain gtm registers location and length (0x40).
> + - interrupts : should contain four interrupts.
> + - interrupt-parent : interrupt source phandle.
interrupt-parent isn't required; it's perfectly valid to specify that in the
parent node instead.
> + Example:
> +
> + gtm@500 {
> + compatible = "fsl,gtm";
> + reg = <0x500 0x40>;
> + interrupts = <90 8 78 8 84 8 72 8>;
> + interrupt-parent = <&ipic>;
> + };
> +
> + gtm@440 {
> + compatible = "fsl,qe-gtm", "fsl,gtm";
> + reg = <0x440 0x40>;
> + interrupts = <12 13 14 15>;
> + interrupt-parent = <&qeic>;
> + };
"timer" would be a better node name than "gtm".
> +static int __init gtm_init_gtm(void)
Name seems rather redundant... what's wrong with gtm_init()?
> +/*
> + * For now we just fixing up the clock -- it's brg-frequency for QE
> + * chips, generic code does not and should not know these details.
> + *
> + * Later we might want to set up BRGs, when QE will actually use
> + * them (there are TIMERCS bits in the CMXGCR register, but today
> + * these bits seem to be no-ops.
> + */
> +static int __init qe_init_gtm(void)
> +{
> + struct device_node *np;
> +
> + for_each_compatible_node(np, NULL, "fsl,qe-gtm") {
> + struct gtm *gtm = np->data;
> +
> + if (!gtm) {
> + /* fsl,qe-gtm without fsl,gtm compatible? */
> + WARN_ON(1);
> + continue;
> + }
> +
> + gtm->clock = qe_get_brg_clk();
> + }
> +
> + return 0;
> +}
> +arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(), then np->data will not be set.
If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
do we need qe_init_gtm() at all?
> +/**
> + * gtm_get_timer - request GTM timer for use with the rest of GTM API
> + * @width: timer width (only 16 bits wide timers implemented so far)
> + *
> + * This function reserves GTM timer for later use. It returns gtm_timer
> + * structure to use with the rest of GTM API, you should use timer->irq
> + * to manage timer interrupt.
> + */
> +extern struct gtm_timer *gtm_get_timer(int width);
To support using the GTM as a wakeup from deep sleep on 831x (which I've had
a patch pending for quite a while now), we'll need some way of reserving a
specific timer (only GTM1, timer 4 is supported).
> +/**
> + * gtm_put_timer - release GTM timer
> + * @width: timer width (only 16 bits wide timers implemented so far)
> + *
> + * This function releases GTM timer sp others might request it.
> + */
> +extern void gtm_put_timer(struct gtm_timer *tmr);
> +
> +/**
> + * gtm_reset_ref_timer_16 - (re)set single (16 bits) timer in reference mode
> + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> + * @hz: timer rate in Hz
> + * @ref: refernce value
How about "period" or "expiry"? And it'd be better to let the caller
request a time in some real unit (e.g. microseconds), and let the gtm driver
figure out how to divide that between prescaler and reference value,
especially in the absence of a way to ask for the allowable hz ranges.
> + * @ffr: free run flag
Could we call it something more intuitive such as "freerun"?
> + * Thus function (re)sets GTM timer so it counts up to the reference value and
> + * fires the interrupt when the value is reached. If ffr flag is set, timer
> + * will also reset itself upon reference value, otherwise it continues to
> + * increment.
> + */
> +extern int gtm_reset_ref_timer_16(struct gtm_timer *tmr, unsigned int hz,
> + u16 ref, bool ffr);
> +
> +/**
> + * gtm_ack_ref_timer_16 - acknowledge timer event (free-run timers only)
> + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> + *
> + * Thus function used to acknowledge timer interrupt event, use it inside the
> + * interrupt handler.
> + */
> +static inline void gtm_ack_ref_timer_16(struct gtm_timer *tmr)
What does the "ref" mean in these names?
How about "gtm_arm_timer16" and "gtm_ack_timer16"?
> +{
> + out_be16(tmr->gtevr, 0xFFFF);
> +}
You need to include <asm/io.h> for this.
Don't blindly clear all events, just the events that have been acted upon.
Either take the events as an argument, or make the ack function specific to
REF, and only set that bit.
-Scott
^ permalink raw reply
* Re: [PATCH 3/8] [POWERPC] qe_lib: implement qe_muram_offset
From: Scott Wood @ 2008-03-18 17:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080311172413.GC7727@localhost.localdomain>
On Tue, Mar 11, 2008 at 08:24:13PM +0300, Anton Vorontsov wrote:
> qe_muram_offset is the reverse of the qe_muram_addr, will be
> used for the Freescale QE USB Host Controller driver.
>
> This patch also moves qe_muram_addr into the qe.h header, plus
> adds __iomem hints to use with sparse.
We should really switch QE over to using the muram code in cpm_common.c...
-Scott
^ permalink raw reply
* Re: Hi,friends, the question about the u-boot and device tree?
From: Scott Wood @ 2008-03-18 18:28 UTC (permalink / raw)
To: 郭劲; +Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <405422271.18508@tsinghua.org.cn>
On Thu, Mar 13, 2008 at 11:31:11PM +0800, 郭劲 wrote:
> I make all the frequency(timebase-frequency;bus-frequency;clock-frequency) value
> on device tree file equal to zero, I think those frequency will filled by u-boot
> during bootm, but in fact, the u-boot did not fill any frequency. after bootm,
> crashed. Why?
What board? Are you using a device-tree-aware u-boot and the three-argument
form of bootm? What sort of crash? How do you know it's not filling in the
frequencies?
> Why so many document point out that the zero value will be filled by u-boot?
Because it does. :-)
If it's not doing so on your board, that needs to be fixed.
-Scott
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-03-18 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080318174329.GB4099@loki.buserror.net>
On Tue, Mar 18, 2008 at 12:43:29PM -0500, Scott Wood wrote:
> On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
> > + Required properties:
> > + - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
> > + GTMs).
> > + - reg : should contain gtm registers location and length (0x40).
> > + - interrupts : should contain four interrupts.
> > + - interrupt-parent : interrupt source phandle.
>
> interrupt-parent isn't required; it's perfectly valid to specify that in the
> parent node instead.
Ok
>
> > + Example:
> > +
> > + gtm@500 {
> > + compatible = "fsl,gtm";
> > + reg = <0x500 0x40>;
> > + interrupts = <90 8 78 8 84 8 72 8>;
> > + interrupt-parent = <&ipic>;
> > + };
> > +
> > + gtm@440 {
> > + compatible = "fsl,qe-gtm", "fsl,gtm";
> > + reg = <0x440 0x40>;
> > + interrupts = <12 13 14 15>;
> > + interrupt-parent = <&qeic>;
> > + };
>
> "timer" would be a better node name than "gtm".
Ok
> > +static int __init gtm_init_gtm(void)
>
> Name seems rather redundant... what's wrong with gtm_init()?
Probably :%s/// effect. Will fix.
> > +/*
> > + * For now we just fixing up the clock -- it's brg-frequency for QE
> > + * chips, generic code does not and should not know these details.
> > + *
> > + * Later we might want to set up BRGs, when QE will actually use
> > + * them (there are TIMERCS bits in the CMXGCR register, but today
> > + * these bits seem to be no-ops.
> > + */
> > +static int __init qe_init_gtm(void)
> > +{
> > + struct device_node *np;
> > +
> > + for_each_compatible_node(np, NULL, "fsl,qe-gtm") {
> > + struct gtm *gtm = np->data;
> > +
> > + if (!gtm) {
> > + /* fsl,qe-gtm without fsl,gtm compatible? */
> > + WARN_ON(1);
> > + continue;
> > + }
> > +
> > + gtm->clock = qe_get_brg_clk();
> > + }
> > +
> > + return 0;
> > +}
> > +arch_initcall(qe_init_gtm);
>
> If this happens before the gtm_init_gtm(),
"If" isn't possible, order is guaranteed.
> then np->data will not be set.
It's a bug in the device tree or in the Linux code then.
> If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
> gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
> do we need qe_init_gtm() at all?
Because for the QE clock-frequency != brg-frequency.
> > +/**
> > + * gtm_get_timer - request GTM timer for use with the rest of GTM API
> > + * @width: timer width (only 16 bits wide timers implemented so far)
> > + *
> > + * This function reserves GTM timer for later use. It returns gtm_timer
> > + * structure to use with the rest of GTM API, you should use timer->irq
> > + * to manage timer interrupt.
> > + */
> > +extern struct gtm_timer *gtm_get_timer(int width);
>
> To support using the GTM as a wakeup from deep sleep on 831x (which I've had
> a patch pending for quite a while now), we'll need some way of reserving a
> specific timer (only GTM1, timer 4 is supported).
You can add reserve function either in the PM driver (if any), or
you can do something in the device tree (wakeup-timer = <..>). I don't
see any problems if you want to implement it.
> > +/**
> > + * gtm_put_timer - release GTM timer
> > + * @width: timer width (only 16 bits wide timers implemented so far)
> > + *
> > + * This function releases GTM timer sp others might request it.
> > + */
> > +extern void gtm_put_timer(struct gtm_timer *tmr);
> > +
> > +/**
> > + * gtm_reset_ref_timer_16 - (re)set single (16 bits) timer in reference mode
> > + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> > + * @hz: timer rate in Hz
> > + * @ref: refernce value
>
> How about "period" or "expiry"? And it'd be better to let the caller
> request a time in some real unit (e.g. microseconds), and let the gtm driver
> figure out how to divide that between prescaler and reference value,
> especially in the absence of a way to ask for the allowable hz ranges.
Will think about it.
> > + * @ffr: free run flag
>
> Could we call it something more intuitive such as "freerun"?
Easy.
> > + * Thus function (re)sets GTM timer so it counts up to the reference value and
> > + * fires the interrupt when the value is reached. If ffr flag is set, timer
> > + * will also reset itself upon reference value, otherwise it continues to
> > + * increment.
> > + */
> > +extern int gtm_reset_ref_timer_16(struct gtm_timer *tmr, unsigned int hz,
> > + u16 ref, bool ffr);
> > +
> > +/**
> > + * gtm_ack_ref_timer_16 - acknowledge timer event (free-run timers only)
> > + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
> > + *
> > + * Thus function used to acknowledge timer interrupt event, use it inside the
> > + * interrupt handler.
> > + */
> > +static inline void gtm_ack_ref_timer_16(struct gtm_timer *tmr)
>
> What does the "ref" mean in these names?
>
> How about "gtm_arm_timer16" and "gtm_ack_timer16"?
Ok.
>
> > +{
> > + out_be16(tmr->gtevr, 0xFFFF);
> > +}
>
> You need to include <asm/io.h> for this.
Ok.
> Don't blindly clear all events, just the events that have been acted upon.
> Either take the events as an argument, or make the ack function specifi
Ok.
Thanks,
--
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-03-18 19:55 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080318192152.GA26493@localhost.localdomain>
Anton Vorontsov wrote:
>>> +arch_initcall(qe_init_gtm);
>> If this happens before the gtm_init_gtm(),
>
> "If" isn't possible, order is guaranteed.
You use arch_initcall for both, so you're relying on link order. I
think this at least merits a comment.
>> then np->data will not be set.
>
> It's a bug in the device tree or in the Linux code then.
Hmm? It's set by gtm_init_gtm(). If this code runs before
gtm_init_gtm(), what are you expecting to initialize np->data?
>> If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
>> gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
>> do we need qe_init_gtm() at all?
>
> Because for the QE clock-frequency != brg-frequency.
Sorry, I missed that you were getting clock-frequency from the parent,
rather than the gtm node. If you do the latter, then you can just stick
the relevant frequency in the gtm node and not worry about where it
comes from. This would be analogous to how UART clocks are specified.
Also, what if some arch_initcall runs between gtm_init_gtm and
qe_init_gtm, that registers itself as a client of the gtm driver, and
uses the wrong clock value?
>>> +extern struct gtm_timer *gtm_get_timer(int width);
>> To support using the GTM as a wakeup from deep sleep on 831x (which I've had
>> a patch pending for quite a while now), we'll need some way of reserving a
>> specific timer (only GTM1, timer 4 is supported).
>
> You can add reserve function either in the PM driver (if any), or
What I meant was that there needs to be some way of telling this driver
not to hand the reserved timer out to some other client.
> you can do something in the device tree (wakeup-timer = <..>). I don't
> see any problems if you want to implement it.
How about simply having optional arguments to gtm_get_timer() to specify
the GTM device and timer number, which will fail if it's already in use?
Then, the PM driver simply needs to run early enough to grab the timer
it needs.
-Scott
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Anton Vorontsov @ 2008-03-18 20:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47E01E22.9000807@freescale.com>
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
> >>>+arch_initcall(qe_init_gtm);
> >>If this happens before the gtm_init_gtm(),
> >
> >"If" isn't possible, order is guaranteed.
>
> You use arch_initcall for both, so you're relying on link order. I
> think this at least merits a comment.
> >>then np->data will not be set.
> >
> >It's a bug in the device tree or in the Linux code then.
>
> Hmm? It's set by gtm_init_gtm(). If this code runs before
> gtm_init_gtm(), what are you expecting to initialize np->data?
What code exactly?
> >>If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
> >>gtm_get_clock(), if there's no clock-frequency -- and if there is, then
> >>why
> >>do we need qe_init_gtm() at all?
> >
> >Because for the QE clock-frequency != brg-frequency.
>
> Sorry, I missed that you were getting clock-frequency from the parent,
> rather than the gtm node. If you do the latter, then you can just stick
> the relevant frequency in the gtm node and not worry about where it
> comes from. This would be analogous to how UART clocks are specified.
Ok.
> Also, what if some arch_initcall runs between gtm_init_gtm and
> qe_init_gtm, that registers itself as a client of the gtm driver, and
> uses the wrong clock value?
Again, what code exactly? If it is a driver (for what this API is
created for), it hardly will run earlier than arch/ code. If this is
platform code (arch/powerpc/platform/), then it is hardly will run
earlier than arch/sysdev/. Inside the arch/sysdev/ fsl_gtm.c is
guaranteed to run earlier than qe_lib/gtm.c. So, where is the problem?
Since I'll implement clock-frequency inside the timer node, this
isn't relevant anymore...
> >>>+extern struct gtm_timer *gtm_get_timer(int width);
> >>To support using the GTM as a wakeup from deep sleep on 831x (which I've
> >>had
> >>a patch pending for quite a while now), we'll need some way of reserving a
> >>specific timer (only GTM1, timer 4 is supported).
> >
> >You can add reserve function either in the PM driver (if any), or
>
> What I meant was that there needs to be some way of telling this driver
> not to hand the reserved timer out to some other client.
>
> >you can do something in the device tree (wakeup-timer = <..>). I don't
> >see any problems if you want to implement it.
>
> How about simply having optional arguments to gtm_get_timer() to specify
> the GTM device and timer number, which will fail if it's already in use?
> Then, the PM driver simply needs to run early enough to grab the timer
> it needs.
Ah. You need specific timer. No problem. I don't like idea of new arguments
to the gtm_get_timer() function (complicates things), but we can just
implement another one. gtm_get_timer_<name>, choice the name please.
_specific, _2, _for, __gtm_get_timer, ...
--
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Benjamin Herrenschmidt @ 2008-03-18 20:31 UTC (permalink / raw)
To: Nathan Lynch
Cc: Olof Johansson, LinuxPPC-dev, Jan-Bernd Themann, Paul Mackerras,
Stephen Rothwell
In-Reply-To: <20080318144511.GQ4712@localdomain>
On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote:
> > > On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote:
> > > > Currently HEA requires 4K pages for IO resources. Just set the pages size to
> > > > IO to 4K.
> > >
> > > Well, that's too bad. Why penalize all platforms for it?
> > >
> > > I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to
> > > waste tlb and erat space.
> >
> > We would have to make that pSeries specific for now I suppose...
> >
> > We don't have a way to know that there "can" be an EHEA right ? It may
> > not be in the device-tree at boot and dynamically added to the
> > partition...
>
> The ibm,drc-names property of the root node should have "HEA" strings
> in it on systems where EHEA can potentially be present.
Ah good, I didn't know. That will force us to stick an ugly wart
somewhere to test it though, maybe we can just force mmu_ci_restrictions
to 1 ? Paul what do you think ?
Ben.
^ permalink raw reply
* Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
From: Scott Wood @ 2008-03-18 20:48 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080318202717.GA1030@localhost.localdomain>
Anton Vorontsov wrote:
> On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>>>> +arch_initcall(qe_init_gtm);
>>>> If this happens before the gtm_init_gtm(),
>>> "If" isn't possible, order is guaranteed.
>> You use arch_initcall for both, so you're relying on link order. I
>> think this at least merits a comment.
>>>> then np->data will not be set.
>>> It's a bug in the device tree or in the Linux code then.
>> Hmm? It's set by gtm_init_gtm(). If this code runs before
>> gtm_init_gtm(), what are you expecting to initialize np->data?
>
> What code exactly?
Sorry, "this code" == qe_init_gtm(). Obviously, if you assume that
gtm_init_gtm() will always be linked earlier, then it's not an issue.
>> Also, what if some arch_initcall runs between gtm_init_gtm and
>> qe_init_gtm, that registers itself as a client of the gtm driver, and
>> uses the wrong clock value?
>
> Again, what code exactly? If it is a driver (for what this API is
> created for), it hardly will run earlier than arch/ code. If this is
> platform code (arch/powerpc/platform/), then it is hardly will run
> earlier than arch/sysdev/. Inside the arch/sysdev/ fsl_gtm.c is
> guaranteed to run earlier than qe_lib/gtm.c. So, where is the problem?
That's a lot of implicit, undocumented dependency on link order...
Things can be moved around, and driver-ish code can pop up in surprising
places. All I meant was that having the gtm driver present itself as
ready when it isn't, in a way which isn't readily apparent if it
happens, is worrysome.
> Since I'll implement clock-frequency inside the timer node, this
> isn't relevant anymore...
OK, good.
> Ah. You need specific timer. No problem. I don't like idea of new arguments
> to the gtm_get_timer() function (complicates things), but we can just
> implement another one. gtm_get_timer_<name>, choice the name please.
> _specific, _2, _for, __gtm_get_timer, ...
How about:
struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer,
int width);
...with np->data used by the caller to figure out which gtm pointer to
pass in.
-Scott
^ permalink raw reply
* Re: [PATCH v2] Force 4K pages for IO addresses.
From: Tony Breeds @ 2008-03-18 21:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Jan-Bernd Themann, LinuxPPC-dev, Nathan Lynch,
Olof Johansson, Paul Mackerras
In-Reply-To: <1205872285.26869.251.camel@pasglop>
On Wed, Mar 19, 2008 at 07:31:25AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote:
> > The ibm,drc-names property of the root node should have "HEA" strings
> > in it on systems where EHEA can potentially be present.
>
> Ah good, I didn't know. That will force us to stick an ugly wart
> somewhere to test it though, maybe we can just force mmu_ci_restrictions
> to 1 ? Paul what do you think ?
That's not enough, mmu_io_psize also needs to be 4K. I'll poke at doing
something platform specific today.
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: Segher Boessenkool @ 2008-03-18 22:40 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847466-17854-1-git-send-email-sr@denx.de>
> + L2C0: l2c@30 {
> + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> + dcr-reg = <20 8 /* Internal SRAM DCR's */
> + 30 8>; /* L2 cache DCR's */
The unit address is based on the _first_ entry in "reg". No2 this
is "dcr-reg", but you don't really want to be more incompatible than
necessary...
Segher
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: David Gibson @ 2008-03-18 23:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847466-17854-1-git-send-email-sr@denx.de>
On Tue, Mar 18, 2008 at 02:37:46PM +0100, Stefan Roese wrote:
> This patch adds the L2 cache node to the Taishan 440GX dts file.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> arch/powerpc/boot/dts/taishan.dts | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
> index 8278068..d0bff33 100644
> --- a/arch/powerpc/boot/dts/taishan.dts
> +++ b/arch/powerpc/boot/dts/taishan.dts
> @@ -104,6 +104,16 @@
> // FIXME: anything else?
> };
>
> + L2C0: l2c@30 {
A node with no reg property shouldn't have a unit address.
> + compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
> + dcr-reg = <20 8 /* Internal SRAM DCR's */
> + 30 8>; /* L2 cache DCR's */
> + cache-line-size = <20>; /* 32 bytes */
> + cache-size = <40000>; /* L2, 256K */
> + interrupt-parent = <&UIC2>;
> + interrupts = <17 1>;
> + };
Now.. usually cache nodes are given as descendents of the CPU node.
In this case you have the DCR control registers though, so I guess
this is representing a control interface rather than the cache
itself. Hrm.. not really sure how to do this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Hi,friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-19 1:22 UTC (permalink / raw)
To: Scott Wood; +Cc: u-boot-users, linuxppc-embedded
Hi,Scott
My board is MPC8360EMDS, my bootm command is "bootm uImage ramdisk_ppc
mpc836x_mds.dtb", I used the MPC8360E_PB_K26_20071012-LTIB.iso to generate above
uImage, ramdisk_ppc,mpc836x_mds.dtb.
If I fill the frequency to zero on mpc836x_mds.dts, then the linux-2.6.22 is
crashed, the output of serial is nothing. if I fill the right frequency value same
as the HRCW on mpc836x_mds.dts, the linux is normal. So I think if the frequency
is zero on mpc836x_mds.dts, the u-boot did not pass the right frequency value to
dtb.
I think maybe that we need to define some on u-boot, then the u-boot can pass the
parameter to linux dtb?
I also has another question, I modified the HRCW to config the cpu as 660/330/400
MHZ during power on, I used the "clocks" command on u-boot to see that the clock
is real 660/330/400 MHZ, then I changed the frequency value on dts to 660/330/400,
after the bootm command, the linux was not carshed after serial configuration, but
the output is random.
"
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
[output from serial is random]
"
I have config the frequency both on HRCW and devie tree is the same, why the
frequency for serial on linux is not right? Why the 528/260/400 is Ok, the
660/330/400 has problem on serial.
Thank you very much.
>From: Scott Wood <scottwood@freescale.com>
>Reply-To:
>To: <guojin02@tsinghua.org.cn>
>Subject: Re: Hi,friends, the question about the u-boot and device tree?
>Date:Tue, 18 Mar 2008 13:28:41 -0500
>
>On Thu, Mar 13, 2008 at 11:31:11PM +0800, wrote:
>> I make all the frequency(timebase-frequency;bus-frequency;clock-frequency)
value
>> on device tree file equal to zero, I think those frequency will filled by
u-boot
>> during bootm, but in fact, the u-boot did not fill any frequency. after bootm,
>> crashed. Why?
>
>What board? Are you using a device-tree-aware u-boot and the three-argument
>form of bootm? What sort of crash? How do you know it's not filling in the
>frequencies?
>
>> Why so many document point out that the zero value will be filled by u-boot?
>
>Because it does. :-)
>If it's not doing so on your board, that needs to be fixed.
>
>-Scott
>
^ permalink raw reply
* Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
From: Paul Mackerras @ 2008-03-19 3:57 UTC (permalink / raw)
To: skumar; +Cc: Poornima Nayak, linuxppc-dev, akpm, linux-kernel
In-Reply-To: <20080318052921.GA32259@in.ibm.com>
Sudhir Kumar writes:
> Unable to handle kernel paging request for data at address
> 0xd00008000000002e
Looks like some driver tried to access I/O port 0x2e without checking
whether there was possibly anything there first.
> Faulting instruction address: 0xc00000000074ded8
> cpu 0x0: Vector: 300 (Data Access) at [c00000003e073aa0]
> pc: c00000000074ded8: .f71805f_find+0x44/0x32c
> lr: c00000000074e1f8: .f71805f_init+0x38/0x194
> sp: c00000003e073d20
> msr: 8000000000009032
> dar: d00008000000002e
> dsisr: 42000000
> current = 0xc0000000220851c0
> paca = 0xc0000000007c2700
> pid = 1, comm = swapper
> enter ? for help
> [c00000003e073dc0] c00000000074e1f8 .f71805f_init+0x38/0x194
Looks like it might be the f71805f driver, whatever that is...
Hmmm, drivers/hwmon/f71805f.c looks like it, and indeed it does go
poking around in PCI I/O space with no checks whatever.
I suggest you turn off CONFIG_SENSORS_F71805F.
It doesn't help, of course, that CONFIG_HWMON defaults to y. :(
Paul.
^ permalink raw reply
* Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Grant Likely @ 2008-03-19 4:15 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080212213120.D51157F806B@mail176-sin.bigfish.com>
On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> In the future, this will be used to provide similar configuration for
> PowerPC and Microblaze. It may also be convenient for those using
> Xilinx cores as peripherals for external processors, rather than
> explicitly having a dependance on the processor architecture.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> ---
>
> Grant,
>
> This is the patch, updated for all of the drivers that I think are in
> the tree. I think the problematic parts may be the ppc part, which is
> required for backward compatibility. If this has to wait until ppc
> dies, then that's fine with me, I guess.
>
> It may also be better to clean up the Kconfig lines for Sysace and
> framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS.
> My understanding is that those config options are there because of
> people using external PPCs with those devices in the FPGA.
Hey Steve;
I haven't forgotten about this patch, but I've been thinking about it
some more and I'm coming to the conclusion that it might just be
better to eliminate driver dependence on XILINX_DRIVERS and
XILINX_VIRTEX entirely and instead just make each of them "depends on
PPC32 || MICROBLAZE". There's no reason to restrict compiling these
drivers to platforms that are known to have xilinx parts on them.
I know that in most cases they will not be used, but by relaxing the
dependencies they will get compile tested on more platforms than they
are now and they'll get picked up for make allyesconfigs builds. In
my mind this means greater chances of compile bugs getting found and
reported.
In fact, it would be nice to drop the PPC32 || MICROBLAZE dependency
too; but I think the drivers are using io primitives at the moment
that are not portable to x86.
Thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Stephen Neuendorffer @ 2008-03-19 4:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803182115k241050f0meafccc29b4ef16@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3322 bytes --]
Hmm... interesting points. I guess my feeling was that XILINX_DRIVERS could be a more broadly configurable option, with some of these ideas in mind. Currently, it's hidden by default, but we could easily change this to be visible by default, or selected by a broader number of architectures. I tend to think about them as a group: What if x86 *did* support the primitives needed by these drivers, then if the individual drivers depend on XILINX_DRIVERS, then the modification could be made in one spot. By your suggestion, we would have to modify each one independantly.
I do dislike the hodgepodge of different configuration dependencies (such as Sysace)... It makes sense to me to have them be uniformly available. If they are all going to be PPC32 || microblaze, then it seems to me like there should be an intermediate configuration option that expresses exactly that set.
Would you feel differently if we flipped the dependencies around, like XILINX_DRIVERS depends on PPC32 || MICROBLAZE?
Steve
-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Tue 3/18/2008 9:15 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; jacmet@sunsite.dk
Subject: Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> In the future, this will be used to provide similar configuration for
> PowerPC and Microblaze. It may also be convenient for those using
> Xilinx cores as peripherals for external processors, rather than
> explicitly having a dependance on the processor architecture.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> ---
>
> Grant,
>
> This is the patch, updated for all of the drivers that I think are in
> the tree. I think the problematic parts may be the ppc part, which is
> required for backward compatibility. If this has to wait until ppc
> dies, then that's fine with me, I guess.
>
> It may also be better to clean up the Kconfig lines for Sysace and
> framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS.
> My understanding is that those config options are there because of
> people using external PPCs with those devices in the FPGA.
Hey Steve;
I haven't forgotten about this patch, but I've been thinking about it
some more and I'm coming to the conclusion that it might just be
better to eliminate driver dependence on XILINX_DRIVERS and
XILINX_VIRTEX entirely and instead just make each of them "depends on
PPC32 || MICROBLAZE". There's no reason to restrict compiling these
drivers to platforms that are known to have xilinx parts on them.
I know that in most cases they will not be used, but by relaxing the
dependencies they will get compile tested on more platforms than they
are now and they'll get picked up for make allyesconfigs builds. In
my mind this means greater chances of compile bugs getting found and
reported.
In fact, it would be nice to drop the PPC32 || MICROBLAZE dependency
too; but I think the drivers are using io primitives at the moment
that are not portable to x86.
Thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[-- Attachment #2: Type: text/html, Size: 4229 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
From: Grant Likely @ 2008-03-19 5:05 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080319043205.12E1F11E0071@mail67-dub.bigfish.com>
On Tue, Mar 18, 2008 at 10:32 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
>
>
>
> Hmm... interesting points. I guess my feeling was that XILINX_DRIVERS could
> be a more broadly configurable option, with some of these ideas in mind.
> Currently, it's hidden by default, but we could easily change this to be
> visible by default, or selected by a broader number of architectures. I
> tend to think about them as a group: What if x86 *did* support the
> primitives needed by these drivers, then if the individual drivers depend on
> XILINX_DRIVERS, then the modification could be made in one spot. By your
> suggestion, we would have to modify each one independantly.
Heh; it's not *that* many drivers and it's just Kconfig stuff which is
real easy to change. My preference would be to eliminate
XILINX_DRIVERS entirely, but I'm not going to fight about it. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Paul Mackerras @ 2008-03-19 5:26 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080317195305.GA13298@aepfle.de>
Olaf Hering writes:
> I cant reproduce this bug on my board, but:
>
> The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
> ipic_init() fails. init_ipic_sysfs() will crash in that case.
>
> Something like this may fix it:
Is this needed for 2.6.25? Is the system at all usable if ipic_init
fails?
Paul.
^ permalink raw reply
* Re: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Qin Lin @ 2008-03-19 5:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <16089631.post@talk.nabble.com>
Hi,All
I found out what the problem was from.
When i set the Bus clock frequency to 50MHz and Processor clock Frequency
200MHz, opb_ethernet does not work with the driver.
And i check the driver,don't find the code base on the frequency . Anyone
knows the reason?
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16137363.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ 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