* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 0:50 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012071346.13434.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On Tue, 2010-12-07 at 13:46 +0100, Guillaume Dargaud wrote:
> Michael,
> in your example, when is foo_driver_probe() actually called ?
> It's not being called when I do an insmod.
It should be called when the driver core finds a device that matches
your match table.
When you register your driver the driver core will iterate over all
devices on the platform bus and if they match then it will call your
probe routine.
I assume you've update the compatible property in the match table, I'm
not sure what else could be causing it to not be called.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 0:37 UTC (permalink / raw)
To: Mark Mason; +Cc: linuxppc-dev
In-Reply-To: <20101207232445.GB29218@postdiluvian.org>
On Tue, 7 Dec 2010 18:24:45 -0500
Mark Mason <mason@postdiluvian.org> wrote:
> Scott Wood <scottwood@freescale.com> wrote:
>
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason <mason@postdiluvian.org> wrote:
> >
> > > What I found, though, was that the NAND did not inherently assert BUSY
> > > as part of the erase - BUSY was asserted because the driver polled for
> > > the status (NAND_CMD_STATUS). If the status poll was delayed for the
> > > duration of the erase then the MPC could talk to the video chip while
> > > the erase was in progress. At the end of the 1ms delay I would then
> > > poll for status, which would complete effectively immediately.
> >
> > That's what we originially did. The problem is that during this
> > interval the NAND chip will be driving the busy pin, which corrupts
> > other LBC transactions.
>
> This is not what we observed with our flash part. For a page erase,
> the NAND did not assert the busy pin until the status read was done.
> This was confirmed with a logic analyzer, and taking advantage of this
> behavior is the sole purpose of the change.
How would that work, in the normal case where you wait for busy to go
away before reading status?
We observed this corruption happening. It was the motivation for
commit 476459a6cf46d20ec73d9b211f3894ced5f9871e.
> > Newer chips have this added text in their reference manuals under
> > "NAND Flash Block Erase Command Sequence Example":
> >
> > Note that operations specified by OP3 and OP4 (status read) should
> > never be skipped while erasing a NAND Flash device, because, in
> > case that happens, contention may arise on LGPL4. A possible case
> > is that the next transaction from eLBC may try to use that pin as
> > an output and since the NAND Flash device might already be driving
> > it, contention will occur. In case OP3 and OP4 operations are
> > skipped, it may also happen that a new command is issued to the
> > NAND Flash device even when the device has not yet finished
> > processing the previous request. This may also result in
> > unpredictable behavior.
>
> I would expect those operations to be mandatory.
...but you remove them from the original FIR. They're not just
mandatory to be done eventually, it has to be done within the one
transaction that is atomic at the LBC.
> > > I know almost nothing at all about the scheduler, but I'm pretty
> > > sure that this behavior would cause the scheduler to think the
> > > video thread was a CPU hog, since the video thread was running for
> > > 1ms for every 20us that the UBI BGT ran, which would cause the
> > > scheduler to unfairly prefer the UBI BGT. I initially tried to
> > > address this problem with thread priorities, but the unfortunate
> > > reality was that either the NAND writes could fall behind or the
> > > video chip could fall behind, and there wasn't spare bandwidth to
> > > allow either.
> >
> > If you set a realtime priority and have preemption enabled, you
> > should be able to avoid being delayed by more than one NAND
> > transaction, until the realtime thread sleeps. Be careful to ensure
> > that it does sleep enough for other things to run.
>
> I tried that, but if the erases were held off enough to get the other
> bus bandwidth we required then the NAND writes fell behind and the
> kernel oom'd.
Another possibility (but still hackish) is to have the NAND driver
poll rather than be interrupt driven, and disable interrupts while
polling. Then, whenever anything else runs (assuming no SMP), it
should be safe to access LBC without high latency -- so the scheduler
shouldn't get confused.
To make it somewhat cleaner, provide the same benefit on SMP, and allow
non-LBC things to run, you could use a mutex to synchronize between all
LBC users, though that's more work and could be a nuisance if you want
to access the LBC from an interrupt handler.
-Scott
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 1:03 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012061544.40124.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]
On Mon, 2010-12-06 at 15:44 +0100, Guillaume Dargaud wrote:
> Hello all,
>
> > OK, that should be all pretty straight forward, and covered by the
> > material in LDD and similar references. You just need to get your device
> > probed.
>
> I'm not sure what you mean with that term: simply identifying that the device
> works using device specific code ?
I just mean connecting your driver up to a struct device that represents
your device.
> I've looked at several *_probe functions from other drivers and they are all
> completely different with no common code...
Yes that's pretty normal, the probe routine usually finds device
specific info about the device and stores it in some sort of structure
for later use.
> Or do you mean calling of_platform_bus_probe() ? What does that function do ?
The platform code does that. That function create devices on the
platform bus by examining the device tree. It looks for nodes that are
compatible with the compatible strings you give it, and treats them as
busses, ie. creates devices for all child nodes of those nodes.
> > No it's just that platform_drivers are now able to do all the things an
> > of_platform_driver can do, so new code should just use platform_driver.
> >
> > I'm not sure if of_platform_bus_probe() will go away eventually, but for
> > now it is the only way to achieve what you need.
>
> I assume the kernel needs to be compiled with CONFIG_OF.
Yes absolutely.
> ...hmm I had to "git pull" in order for this to compile your snippet. That's
> really recent! Unfortunately i need to reflash my device with the new kernel
> before i can begin testing my module.
It shouldn't be that recent, what kernel version were you using?
> When I try to compile your (adapted) snippet, I got this minor problems:
>
> .probe = foo_driver_probe,
> ^ warning: initialization from incompatible pointer type
> Shouldn't foo_driver_probe be:
> static int foo_driver_probe(struct platform_device *pdev)
> instead of:
> static int foo_driver_probe(struct platform_device *device,
> const struct of_device_id *device_id)
Yes sorry, that's a cut & paste bug, between the old and new style code.
> Also:
> struct foo_device *foo;
> That's where I put my own content, right ?
Yep.
> And needs to be kfreed in a foo_driver_remove() function, right ?
If you have a remove then yes.
> > > I still need a platform_device_register() after your sample init, right ?
> >
> > I had one in there already, in foo_driver_init(), didn't I?
>
> You had platform_driver_register(), not that I'm all clear yet on the
> distinction...
Oh sorry, I always read those wrong.
platform_device_register() creates a device on the platform bus. You
then write a driver for that device, and register it with
platform_driver_register(), your driver then attaches to the device.
In this case though you don't need to call platform_device_register()
because the device has already been created, using the device tree (by
of_platform_bus_probe()).
In general on powerpc we don't use platform_device_register() much,
instead things are described in the device tree and devices are created
for them.
platform_device_register() tends to be for cases where you can't
discover or probe a device, but you "know" that it exists.
> Another question: I just spent 10 minutes trying to find where "struct device"
> was defined. (ack-)grep was absolutely no use. Isn't there a way to cross-
> reference my own kernel, the way I've compiled it ?
Yes, "make tags", then use vim :)
If you're cross-compiling make sure to set ARCH=powerpc when you make
tags.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Run 'usermode-agent' cause kernel panic on Powerpc
From: xufeng zhang @ 2010-12-08 1:20 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: Linuxppc-dev
In-Reply-To: <1291730683.16003.4.camel@shaggy-w500>
On 12/07/2010 10:04 PM, Dave Kleikamp wrote:
> On Tue, 2010-12-07 at 14:48 +0800, xufeng zhang wrote:
>
>> Hi Dave,
>>
>> I have a question with the below patch you made before:
>> ----------------------------------------
>> powerpc/booke: Add support for advanced debug registers
>>
>> From: Dave Kleikamp<shaggy@linux.vnet.ibm.com>
>>
>> Based on patches originally written by Torez Smith.
>> -----------------------------------------
>>
>> I meet a kernel panic problem while running 'usermode-agent' on PowerPC
>> ----------------------------------------
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> PREEMPT LTT NESTING LEVEL : 0
>> MPC8536 DS
>> last sysfs file:
>> /sys/devices/f3000000.soc/f3003100.i2c/i2c-1/i2c-dev/i2c-1/dev
>> Modules linked in:
>> NIP: c00081a0 LR: c03a9560 CTR: c003547c
>> REGS: ef11bf10 TRAP: 2002 Not tainted (2.6.34.6-WR4.0.0.0_standard)
>> MSR: 00021000<ME,CE> CR: 44000624 XER: 00000000
>> TASK = efc1de00[752] 'usermode-agent' THREAD: ef63e000
>> GPR00: cc00cc00 ef63fe60 efc1de00 efc1de00 efc1f700 c04c8000 00258560
>> ffffffff
>> GPR08: ffda8a00 40000000 00001fda c0500000 49eaebbd 1008b654 3ff8a900
>> 00000000
>> GPR16: 00000000 eed84c40 c03b4570 c04ee4d0 c04ca870 ef63e03c 00000000
>> 00000000
>> GPR24: c04f7ee8 c04ee4c0 00000004 c04ca440 ef63e000 efc1f700 c04ca440
>> efc1de00
>> NIP [c00081a0] __switch_to+0xac/0x104
>> LR [c03a9560] schedule+0x20c/0x3f4
>> Call Trace:
>> [ef63fe60] [efc1f700] 0xefc1f700 (unreliable)
>> [ef63fe70] [c03a9560] schedule+0x20c/0x3f4
>> [ef63fec0] [c00429e0] do_wait+0x1a4/0x278
>> [ef63fef0] [c0042b44] sys_wait4+0x90/0xf8
>> [ef63ff40] [c00106d4] ret_from_syscall+0x0/0x4
>> ------------------------------------------
>>
>> Actually, this problem is caused by enabling On Chip Debugging, when On
>> Chip Debugging is enabled, we enable MSR_DE as below:
>> #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
>>
>> If I comment out "mtspr(SPRN_DBCR0, thread->dbcr0);" in
>> prime_debug_regs() function,
>> then it will be ok.
>>
>> Here is my analysis for this problem:
>> Run 'usermode-agent' application will set Internal Debug Mode(IDM) and
>> Instruction Complete Debug Event(ICMP)flags for thread.
>> As MSR_DE is enabled, when execute context switching in prime_debug_regs(),
>> thread->dbcr0 would write to SPRN_DBCR0 register.
>> So this will enable Instruction Complete Debug Event interrupt, and it
>> will cause a kernel-mode
>> exception right now, it will be handled in native_DebugException(), then
>> kernel detected
>> this exception not happens in user-mode, lastly kernel call die() and
>> kill current process.
>>
>> So my question is could I just comment out "mtspr(SPRN_DBCR0,
>> thread->dbcr0);" in prime_debug_regs()?
>> I'm sure whether or not it will impose a bad impact on debugging.
>>
> I believe it would have such an impact. I don't see that user-mode
> debugging would be enabled at all.
>
> Maybe something like this untested patch:
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 84906d3..0e7d1cf 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -323,6 +323,13 @@ static void set_debug_reg_defaults(struct thread_struct *thread)
>
> static void prime_debug_regs(struct thread_struct *thread)
> {
> + /*
> + * If we're setting up debug events for user space, make sure they
> + * don't fire in kernel space before we get to user space
> + */
> + if (thread->dbcr0& DBCR0_IDM)
> + mtmsr(mfmsr()& ~MSR_DE);
> +
> mtspr(SPRN_IAC1, thread->iac1);
> mtspr(SPRN_IAC2, thread->iac2);
> #if CONFIG_PPC_ADV_DEBUG_IACS> 2
>
>
Thanks for your reply, Dave, I know where the problem is.
Thanks,
Xufeng Zhang
^ permalink raw reply
* Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2010-12-08 5:36 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, linuxppc-dev, Samuel Ortiz,
Ben Dooks
In-Reply-To: <1291451028-22532-1-git-send-email-hs@denx.de>
On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: linux-fbdev@vger.kernel.org
> cc: devicetree-discuss@ozlabs.org
> ---
> based against 2.6.37-rc4
>
> ./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch lems and is ready for
> total: 0 errors, 0 warnings, 1067 lines checked
>
> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission.
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
Given that this is all SM501 dependent, is there some particular reason
why you neglected to Cc the author or the MFD folks?
^ permalink raw reply
* [PATCH] powerpc: Hardcode popcnt instructions for old assemblers
From: Anton Blanchard @ 2010-12-08 5:58 UTC (permalink / raw)
To: benh, sfr; +Cc: linuxppc-dev
The popcnt instructions went into binutils relatively recently. As with a
number of other instructions, create macros and hardcode them.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/ppc-opcode.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/ppc-opcode.h 2010-12-08 16:50:12.760796093 +1100
+++ powerpc.git/arch/powerpc/include/asm/ppc-opcode.h 2010-12-08 16:57:10.181788576 +1100
@@ -36,6 +36,8 @@
#define PPC_INST_NOP 0x60000000
#define PPC_INST_POPCNTB 0x7c0000f4
#define PPC_INST_POPCNTB_MASK 0xfc0007fe
+#define PPC_INST_POPCNTD 0x7c0003f4
+#define PPC_INST_POPCNTW 0x7c0002f4
#define PPC_INST_RFCI 0x4c000066
#define PPC_INST_RFDI 0x4c00004e
#define PPC_INST_RFMCI 0x4c00004c
@@ -88,6 +90,12 @@
__PPC_RB(b) | __PPC_EH(eh))
#define PPC_MSGSND(b) stringify_in_c(.long PPC_INST_MSGSND | \
__PPC_RB(b))
+#define PPC_POPCNTB(a, s) stringify_in_c(.long PPC_INST_POPCNTB | \
+ __PPC_RA(a) | __PPC_RS(s))
+#define PPC_POPCNTD(a, s) stringify_in_c(.long PPC_INST_POPCNTD | \
+ __PPC_RA(a) | __PPC_RS(s))
+#define PPC_POPCNTW(a, s) stringify_in_c(.long PPC_INST_POPCNTW | \
+ __PPC_RA(a) | __PPC_RS(s))
#define PPC_RFCI stringify_in_c(.long PPC_INST_RFCI)
#define PPC_RFDI stringify_in_c(.long PPC_INST_RFDI)
#define PPC_RFMCI stringify_in_c(.long PPC_INST_RFMCI)
Index: powerpc.git/arch/powerpc/lib/hweight_64.S
===================================================================
--- powerpc.git.orig/arch/powerpc/lib/hweight_64.S 2010-12-08 16:50:12.760796093 +1100
+++ powerpc.git/arch/powerpc/lib/hweight_64.S 2010-12-08 16:50:16.560623089 +1100
@@ -28,7 +28,7 @@ BEGIN_FTR_SECTION
nop
nop
FTR_SECTION_ELSE
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_IFCLR(CPU_FTR_POPCNTB)
@@ -42,14 +42,14 @@ BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
BEGIN_FTR_SECTION_NESTED(50)
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
srdi r4,r3,8
add r3,r4,r3
clrldi r3,r3,64-8
blr
FTR_SECTION_ELSE_NESTED(50)
clrlwi r3,r3,16
- popcntw r3,r3
+ PPC_POPCNTW(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_POPCNTD, 50)
@@ -66,7 +66,7 @@ BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
BEGIN_FTR_SECTION_NESTED(51)
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
srdi r4,r3,16
add r3,r4,r3
srdi r4,r3,8
@@ -74,7 +74,7 @@ FTR_SECTION_ELSE
clrldi r3,r3,64-8
blr
FTR_SECTION_ELSE_NESTED(51)
- popcntw r3,r3
+ PPC_POPCNTW(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_POPCNTD, 51)
@@ -93,7 +93,7 @@ BEGIN_FTR_SECTION
nop
FTR_SECTION_ELSE
BEGIN_FTR_SECTION_NESTED(52)
- popcntb r3,r3
+ PPC_POPCNTB(r3,r3)
srdi r4,r3,32
add r3,r4,r3
srdi r4,r3,16
@@ -103,7 +103,7 @@ FTR_SECTION_ELSE
clrldi r3,r3,64-8
blr
FTR_SECTION_ELSE_NESTED(52)
- popcntd r3,r3
+ PPC_POPCNTD(r3,r3)
clrldi r3,r3,64-8
blr
ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_POPCNTD, 52)
^ permalink raw reply
* Re: [PATCH] powerpc: Hardcode popcnt instructions for old assemblers
From: Stephen Rothwell @ 2010-12-08 7:27 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20101208165817.0df89814@kryten>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
Hi Anton,
On Wed, 8 Dec 2010 16:58:17 +1100 Anton Blanchard <anton@samba.org> wrote:
>
> The popcnt instructions went into binutils relatively recently. As with a
> number of other instructions, create macros and hardcode them.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
That certainly fixes the build issue for me (tested ppc64_defconfig with
binutils 2.19.1).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 7:59 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101207145153.540da45a@udp111988uds.am.freescale.net>
>
> On Mon, 6 Dec 2010 22:15:54 -0500
> Mark Mason <mason@postdiluvian.org> wrote:
>
> > A few months ago I ran into some performance problems involving
> > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > found a solution for this, which worked well, at least with the
> > hardware I was working with. I suspect the same problem affects other
> > PPCs, probably including multicore devices, and maybe other
> > architectures as well.
> >
> > I don't have experience with similar NAND controllers on other
> > devices, so I'd like to explain what I found and see if someone who's
> > more familiar with the family and/or driver can tell if this is
> > useful.
> >
> > The problem cropped up when there was a lot of traffic to the NAND
> > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > a video chip that needed constant and prompt attention.
>
> If you attach NAND to the LBC, you should not attach anything else to
> it which is latency-sensitive.
This "feature" makes the LBC useless to us. Is there some workaround or plan
to address this limitation?
Jocke
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-08 10:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291770234.2041.102.camel@concordia>
Thanks again for your detailed answer,
I'm learning, but not as fast as my colleagues with a deadline want me to !
> The platform code does that. That function create devices on the
> platform bus by examining the device tree. It looks for nodes that are
> compatible with the compatible strings you give it, and treats them as
> busses, ie. creates devices for all child nodes of those nodes.
Is there a way to enable some debug output from it, to see what's going on ?
> > ...hmm I had to "git pull" in order for this to compile your snippet.
> > That's really recent! Unfortunately i need to reflash my device with the
> > new kernel before i can begin testing my module.
>
> It shouldn't be that recent, what kernel version were you using?
I had to go from 2.6.34 to 2.6.35, xilinx git tree.
> Yes sorry, that's a cut & paste bug, between the old and new style code.
No worries, I knew it was some uncompiled example.
> platform_device_register() creates a device on the platform bus. You
> then write a driver for that device, and register it with
> platform_driver_register(), your driver then attaches to the device.
>
> In this case though you don't need to call platform_device_register()
> because the device has already been created, using the device tree (by
> of_platform_bus_probe()).
OK, I'll have to remove it from my sample code below.
> In general on powerpc we don't use platform_device_register() much,
> instead things are described in the device tree and devices are created
> for them.
>
> platform_device_register() tends to be for cases where you can't
> discover or probe a device, but you "know" that it exists.
When you see something in /sys/devices/plb.0/, it means that you don't need
platform_device_register, right ?
> Yes, "make tags", then use vim :)
Great, that works.
OK, here's the relevant part of my code, ripped directly from your sample,
with a few additions and different variable names. Why do you think
xad_driver_probe() is not being called ?
#include <linux/kernel.h>
#include <linux/init.h>
#include <asm/device.h>
#include <linux/platform_device.h>
#include <linux/cdev.h> // char device
#include <linux/fs.h>
#include <linux/of.h>
#include <linux/interrupt.h>
#define DEVNAME "xps-acqui-data"
#define NAME "xad" // This is only used for printk
#define SD "{%s %d} "
#define FL , __func__, __LINE__
static dev_t first;
static unsigned int count = 1;
static int my_major = 241, my_minor = 0;
// You must run "mknod /dev/xad c 241 0" in a shell at least once
struct cdev *my_cdev=NULL;
struct platform_device *pdev=NULL;
typedef struct XadDevice {
struct resource *hw_region;
struct device *dev;
int irq;
} tXadDevice;
tXadDevice Xad;
// There should be something in:
// ll /sys/devices/plb.0/c9800000.xps-acqui-data
static const struct of_device_id xad_device_id[] = {
{ .compatible = "xlnx,xps-acqui-data-3.00.a" }, // Must match
the DTS
{}
};
static irqreturn_t XadIsr(int irq, void *dev_id) {
printk(KERN_INFO SD "IRQ:%d\n" FL, irq);
return IRQ_HANDLED;
}
///////////////////////////////////////////////////////////////////////////////
// Platform Bus Support
///////////////////////////////////////////////////////////////////////////////
static int xad_driver_probe(struct platform_device *device /*,
const struct of_device_id *device_id*/ ) {
struct device_node *dn = device->dev.of_node;
int rc;
pr_devel("Probing %s\n", dn->full_name);
Xad.irq = irq_of_parse_and_map(dn, 0);
rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING | IRQF_DISABLED,
"XadIsr", &Xad);
if (rc) printk(KERN_INFO SD "Failled IRQ request: %d\n" FL, rc);
return 0;
}
static int __devexit xad_driver_remove(struct platform_device *device) {
printk(KERN_INFO SD "Removing...\n" FL);
return 0;
}
static struct platform_driver xad_driver = {
.probe = xad_driver_probe,
.remove = xad_driver_remove,
.driver = {
.owner = THIS_MODULE,
.name = "xad-driver",
.of_match_table = xad_device_id,
},
};
///////////////////////////////////////////////////////////////////////////////
// This section deals with the /dev/xad device
///////////////////////////////////////////////////////////////////////////////
static int xad_open(struct inode *node, struct file *filep) {
printk (KERN_INFO SD "OPENING device: %s\n" FL, NAME);
return 0;
}
static int xad_release(struct inode *node, struct file *filep) {
printk (KERN_INFO SD "RELEASING device: %s\n" FL, NAME);
return 0;
}
static int xad_ioctl(struct inode *node, struct file *filep, unsigned int cmd,
unsigned long arg) {
printk (KERN_INFO SD "IOCTL on device: %s, cmd:%d, arg:%lu\n" FL, NAME, cmd,
arg);
return 0;
}
static struct file_operations fops = {
.owner = THIS_MODULE,
.open = xad_open,
.release = xad_release,
.ioctl = xad_ioctl,
};
///////////////////////////////////////////////////////////////////////////////
// Called on insmod
static int __init xad_init(void) {
int rc=0;
printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
// Deal with the device
first = MKDEV (my_major, my_minor);
register_chrdev_region(first, count, DEVNAME);
my_cdev = cdev_alloc ();
if (NULL==my_cdev) goto Err;
cdev_init(my_cdev, &fops);
cdev_add (my_cdev, first, count);
printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
my_major, my_minor, count);
// Driver
rc = platform_driver_register(&xad_driver);
// rc = platform_driver_probe(&xad_driver, xad_driver_probe);
if (rc) goto err_plat;
// Device
pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
if (IS_ERR(pdev)) {
rc = PTR_ERR(pdev);
platform_driver_unregister(&xad_driver);
goto err_plat;
}
return 0;
err_plat:
unregister_chrdev_region(first, count);
Err:
printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
return rc;
}
///////////////////////////////////////////////////////////////////////////////
// Called on rmmod
static void xad_exit(void) {
platform_device_unregister(pdev); pdev=NULL;
platform_driver_unregister(&xad_driver);
cdev_del (my_cdev); my_cdev=NULL;
unregister_chrdev_region (first, count);
printk(KERN_INFO SD "Module %s unloaded\n" FL, NAME);
}
module_init(xad_init);
module_exit(xad_exit);
MODULE_AUTHOR("Guillaume Dargaud");
MODULE_LICENSE("GPL");
And here's the result:
# tail -f /var/log/messages &
# insmod xad.ko
Dec 7 14:42:02 gandalf user.info kernel: [15897.152109] {xad_init 162} Module
xad: loading...
Dec 7 14:42:02 gandalf user.info kernel: [15897.156665] {xad_init 173} Module
xad: Major=241, Minor=0, Count=1
# ./xad_test # A simple prog that opens, does an iocl and closes the device
./xad_test Initialisation
./xad_test Ioctl
./xad_test Closing
Dec 7 14:42:16 gandalf user.info kernel: [15911.160343] {xad_open 130}
OPENING device: xad
Dec 7 14:42:16 gandalf user.info kernel: [15911.164521] {xad_ioctl 142} IOCTL
on device: xad, cmd:0, arg:0
Dec 7 14:42:16 gandalf user.info kernel: [15911.173035] {xad_release 136}
RELEASING device: xad
# rmmod xad
Dec 7 14:42:23 gandalf user.info kernel: [15918.753661] {xad_exit 206} Module
xad unloaded
And in the dts:
/dts-v1/;
/ {
...
plb: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-
bus";
ranges ;
...
xps_acqui_data_0: xps-acqui-data@c9800000 {
compatible = "xlnx,xps-acqui-data-3.00.a";
interrupt-parent = <&xps_intc_0>;
interrupts = < 0 2 >;
reg = < 0xc9800000 0x10000 >;
xlnx,family = "virtex4";
xlnx,include-dphase-timer = <0x1>;
xlnx,mplb-awidth = <0x20>;
xlnx,mplb-clk-period-ps = <0x2710>;
xlnx,mplb-dwidth = <0x40>;
xlnx,mplb-native-dwidth = <0x40>;
xlnx,mplb-p2p = <0x0>;
xlnx,mplb-smallest-slave = <0x20>;
} ;
...
} ;
...
} ;
# ll /sys/devices/plb.0/c9800000.xps-acqui-data/
-r--r--r-- 1 root root 4.0K Dec 7 12:55 devspec
-r--r--r-- 1 root root 4.0K Dec 7 12:55 modalias
-r--r--r-- 1 root root 4.0K Dec 7 12:55 name
lrwxrwxrwx 1 root root 0 Dec 7 12:55 subsystem ->
../../../bus/of_platform/
-rw-r--r-- 1 root root 4.0K Dec 7 12:55 uevent
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* [PATCH] powerpc: Fix incorrect comment about interrupt stack allocation
From: Anton Blanchard @ 2010-12-08 10:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
We now allow interrupt stacks anywhere in the first segment which can be
256M or 1TB. Fix the comment.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/setup_64.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/setup_64.c 2010-08-19 09:05:17.090741942 +1000
+++ powerpc.git/arch/powerpc/kernel/setup_64.c 2010-08-19 09:06:08.151991499 +1000
@@ -428,8 +428,8 @@ static void __init irqstack_early_init(v
unsigned int i;
/*
- * interrupt stacks must be under 256MB, we cannot afford to take
- * SLB misses on them.
+ * Interrupt stacks must be in the first segment since we
+ * cannot afford to take SLB misses on them.
*/
for_each_possible_cpu(i) {
softirq_ctx[i] = (struct thread_info *)
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-08 13:45 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012081118.13977.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 7255 bytes --]
On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
> Thanks again for your detailed answer,
> I'm learning, but not as fast as my colleagues with a deadline want me to !
:)
> > The platform code does that. That function create devices on the
> > platform bus by examining the device tree. It looks for nodes that are
> > compatible with the compatible strings you give it, and treats them as
> > busses, ie. creates devices for all child nodes of those nodes.
>
> Is there a way to enable some debug output from it, to see what's going on ?
Not really, but there probably should be.
> > > ...hmm I had to "git pull" in order for this to compile your snippet.
> > > That's really recent! Unfortunately i need to reflash my device with the
> > > new kernel before i can begin testing my module.
> >
> > It shouldn't be that recent, what kernel version were you using?
>
> I had to go from 2.6.34 to 2.6.35, xilinx git tree.
Ah that is the problem I think.
Sorry I assumed you were working on mainline. In 2.6.35 you still need
to use an of_platform_driver, I'll describe below.
> > platform_device_register() tends to be for cases where you can't
> > discover or probe a device, but you "know" that it exists.
>
> When you see something in /sys/devices/plb.0/, it means that you don't need
> platform_device_register, right ?
That's right.
> > Yes, "make tags", then use vim :)
>
> Great, that works.
Cool.
> OK, here's the relevant part of my code, ripped directly from your sample,
> with a few additions and different variable names. Why do you think
> xad_driver_probe() is not being called ?
As I said above in 2.6.35 platform drivers and of_platform drivers were
still separate. So your device is on the of_platform_bus (ie. was
discovered using the device tree), but your driver is on the
platform_bus. Yes this is very confusing.
So basically you need to change all occurrences of platform_driver to
of_platform_driver.
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <asm/device.h>
> #include <linux/platform_device.h>
> #include <linux/cdev.h> // char device
> #include <linux/fs.h>
> #include <linux/of.h>
> #include <linux/interrupt.h>
>
> #define DEVNAME "xps-acqui-data"
> #define NAME "xad" // This is only used for printk
>
> #define SD "{%s %d} "
> #define FL , __func__, __LINE__
>
> static dev_t first;
> static unsigned int count = 1;
> static int my_major = 241, my_minor = 0;
> // You must run "mknod /dev/xad c 241 0" in a shell at least once
>
> struct cdev *my_cdev=NULL;
> struct platform_device *pdev=NULL;
>
> typedef struct XadDevice {
> struct resource *hw_region;
> struct device *dev;
> int irq;
> } tXadDevice;
> tXadDevice Xad;
>
> // There should be something in:
> // ll /sys/devices/plb.0/c9800000.xps-acqui-data
> static const struct of_device_id xad_device_id[] = {
> { .compatible = "xlnx,xps-acqui-data-3.00.a" }, // Must match
> the DTS
> {}
> };
>
>
> static irqreturn_t XadIsr(int irq, void *dev_id) {
> printk(KERN_INFO SD "IRQ:%d\n" FL, irq);
> return IRQ_HANDLED;
> }
>
> ///////////////////////////////////////////////////////////////////////////////
> // Platform Bus Support
> ///////////////////////////////////////////////////////////////////////////////
>
> static int xad_driver_probe(struct platform_device *device /*,
> const struct of_device_id *device_id*/ ) {
So you need to switch the prototype here to:
static int xad_driver_probe(struct of_platform_device *ofdev,
const struct of_device_id *device_id) {
> struct device_node *dn = device->dev.of_node;
> int rc;
>
> pr_devel("Probing %s\n", dn->full_name);
>
> Xad.irq = irq_of_parse_and_map(dn, 0);
> rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING | IRQF_DISABLED,
> "XadIsr", &Xad);
> if (rc) printk(KERN_INFO SD "Failled IRQ request: %d\n" FL, rc);
>
> return 0;
> }
>
> static int __devexit xad_driver_remove(struct platform_device *device) {
> printk(KERN_INFO SD "Removing...\n" FL);
> return 0;
> }
>
> static struct platform_driver xad_driver = {
Becomes of_platform_driver
> .probe = xad_driver_probe,
> .remove = xad_driver_remove,
> .driver = {
> .owner = THIS_MODULE,
> .name = "xad-driver",
> .of_match_table = xad_device_id,
> },
> };
>
>
> ///////////////////////////////////////////////////////////////////////////////
> // This section deals with the /dev/xad device
> ///////////////////////////////////////////////////////////////////////////////
> static int xad_open(struct inode *node, struct file *filep) {
> printk (KERN_INFO SD "OPENING device: %s\n" FL, NAME);
> return 0;
> }
>
> static int xad_release(struct inode *node, struct file *filep) {
> printk (KERN_INFO SD "RELEASING device: %s\n" FL, NAME);
> return 0;
> }
>
> static int xad_ioctl(struct inode *node, struct file *filep, unsigned int cmd,
> unsigned long arg) {
> printk (KERN_INFO SD "IOCTL on device: %s, cmd:%d, arg:%lu\n" FL, NAME, cmd,
> arg);
> return 0;
> }
>
> static struct file_operations fops = {
> .owner = THIS_MODULE,
> .open = xad_open,
> .release = xad_release,
> .ioctl = xad_ioctl,
> };
>
>
> ///////////////////////////////////////////////////////////////////////////////
> // Called on insmod
> static int __init xad_init(void) {
> int rc=0;
> printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
>
> // Deal with the device
> first = MKDEV (my_major, my_minor);
> register_chrdev_region(first, count, DEVNAME);
> my_cdev = cdev_alloc ();
> if (NULL==my_cdev) goto Err;
>
> cdev_init(my_cdev, &fops);
> cdev_add (my_cdev, first, count);
>
> printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
> my_major, my_minor, count);
>
> // Driver
> rc = platform_driver_register(&xad_driver);
Should be of_register_platform_driver()
> // rc = platform_driver_probe(&xad_driver, xad_driver_probe);
> if (rc) goto err_plat;
>
> // Device
> pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
> if (IS_ERR(pdev)) {
> rc = PTR_ERR(pdev);
> platform_driver_unregister(&xad_driver);
> goto err_plat;
> }
>
>
> return 0;
>
> err_plat:
> unregister_chrdev_region(first, count);
> Err:
> printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
> return rc;
> }
>
> ///////////////////////////////////////////////////////////////////////////////
> // Called on rmmod
> static void xad_exit(void) {
> platform_device_unregister(pdev); pdev=NULL;
> platform_driver_unregister(&xad_driver);
>
> cdev_del (my_cdev); my_cdev=NULL;
> unregister_chrdev_region (first, count);
> printk(KERN_INFO SD "Module %s unloaded\n" FL, NAME);
> }
>
> module_init(xad_init);
> module_exit(xad_exit);
>
> MODULE_AUTHOR("Guillaume Dargaud");
> MODULE_LICENSE("GPL");
>
>
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 0/4] V3 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Changes from V2:
Rule to create assembly wrapper for blob changed to use Sam Ravnborgs
suggested implementation.
Rules in architecture specific Makefiles changed to use the cmd
function instead of the if_changed function.
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 12 +++---------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
6 files changed, 65 insertions(+), 16 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
scripts/Makefile.lib | 23 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..86e3cd0 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..05cbad0 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..63b287c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,6 +200,29 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+quiet_cmd_dt_S_dtb= DTB $@
+cmd_dt_S_dtb= \
+( \
+ echo '\#include <asm-generic/vmlinux.lds.h>'; \
+ echo '.section .dtb.init.rodata,"a"'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+ echo '.global __dtb_$(*F)_begin'; \
+ echo '__dtb_$(*F)_begin:'; \
+ echo '.incbin "$<" '; \
+ echo '__dtb_$(*F)_end:'; \
+ echo '.global __dtb_$(*F)_end'; \
+ echo '.balign STRUCT_ALIGNMENT'; \
+) > $@
+
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ $(call cmd,dt_S_dtb)
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..e5f3b7b 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call cmd,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..96deec6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call cmd,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/microblaze/boot/Makefile | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index be01d78..4c4e58e 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
OBJCOPYFLAGS := -O binary
-# Where the DTS files live
-dtstree := $(srctree)/$(src)/dts
-
# Ensure system.dtb exists
$(obj)/linked_dtb.o: $(obj)/system.dtb
@@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
$(call if_changed,strip)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
-# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
# Rule to build device tree blobs
-quiet_cmd_dtc = DTC $@
- cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
+DTC_FLAGS := -p 1024
-$(obj)/%.dtb: $(dtstree)/%.dts FORCE
- $(call if_changed,dtc)
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
+ $(call cmd,dtc)
clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2] powerpc, 5200: add support for charon board
From: Wolfram Sang @ 2010-12-08 15:49 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <1291705135-26805-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Tue, Dec 07, 2010 at 07:58:55AM +0100, Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-08 15:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291815910.12093.15.camel@concordia>
> Sorry I assumed you were working on mainline. In 2.6.35 you still need
> to use an of_platform_driver, I'll describe below.
> So basically you need to change all occurrences of platform_driver to
> of_platform_driver.
OK, thanks, I did that, compiled and ran the driver and its test prog... no
changes: xad_driver_probe() doesn't get called.
...?
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-08 17:18 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OFF94B1B01.88594E81-ONC12577F3.002B63AA-C12577F3.002BEE0B@transmode.se>
On Wed, 8 Dec 2010 08:59:49 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > On Mon, 6 Dec 2010 22:15:54 -0500
> > Mark Mason <mason@postdiluvian.org> wrote:
> >
> > > A few months ago I ran into some performance problems involving
> > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > found a solution for this, which worked well, at least with the
> > > hardware I was working with. I suspect the same problem affects other
> > > PPCs, probably including multicore devices, and maybe other
> > > architectures as well.
> > >
> > > I don't have experience with similar NAND controllers on other
> > > devices, so I'd like to explain what I found and see if someone who's
> > > more familiar with the family and/or driver can tell if this is
> > > useful.
> > >
> > > The problem cropped up when there was a lot of traffic to the NAND
> > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > a video chip that needed constant and prompt attention.
> >
> > If you attach NAND to the LBC, you should not attach anything else to
> > it which is latency-sensitive.
>
> This "feature" makes the LBC useless to us. Is there some workaround or plan
> to address this limitation?
Complain to your support or sales contact.
I've complained about it in the past, and got a "but pins are a limited
resource!" response. They need to hear that it's a problem from
customers.
-Scott
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 17:32 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208111839.1cf95553@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
>
> On Wed, 8 Dec 2010 08:59:49 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > >
> > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > Mark Mason <mason@postdiluvian.org> wrote:
> > >
> > > > A few months ago I ran into some performance problems involving
> > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > found a solution for this, which worked well, at least with the
> > > > hardware I was working with. I suspect the same problem affects other
> > > > PPCs, probably including multicore devices, and maybe other
> > > > architectures as well.
> > > >
> > > > I don't have experience with similar NAND controllers on other
> > > > devices, so I'd like to explain what I found and see if someone who's
> > > > more familiar with the family and/or driver can tell if this is
> > > > useful.
> > > >
> > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > a video chip that needed constant and prompt attention.
> > >
> > > If you attach NAND to the LBC, you should not attach anything else to
> > > it which is latency-sensitive.
> >
> > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > to address this limitation?
>
> Complain to your support or sales contact.
>
> I've complained about it in the past, and got a "but pins are a limited
> resource!" response. They need to hear that it's a problem from
> customers.
Done, lets see what I get in return. I think this problem will be
a major obstacle for our next generation boards which will be NAND
based.
Jocke
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Mark Mason @ 2010-12-08 19:26 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF349DC945.8BC48D34-ONC12577F3.00601D94-C12577F3.00605153@transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> >
> > On Wed, 8 Dec 2010 08:59:49 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > >
> > > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > > Mark Mason <mason@postdiluvian.org> wrote:
> > > >
> > > > > A few months ago I ran into some performance problems involving
> > > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > > found a solution for this, which worked well, at least with the
> > > > > hardware I was working with. I suspect the same problem affects other
> > > > > PPCs, probably including multicore devices, and maybe other
> > > > > architectures as well.
> > > > >
> > > > > I don't have experience with similar NAND controllers on other
> > > > > devices, so I'd like to explain what I found and see if someone who's
> > > > > more familiar with the family and/or driver can tell if this is
> > > > > useful.
> > > > >
> > > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > > a video chip that needed constant and prompt attention.
> > > >
> > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > it which is latency-sensitive.
> > >
> > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > to address this limitation?
> >
> > Complain to your support or sales contact.
> >
> > I've complained about it in the past, and got a "but pins are a limited
> > resource!" response. They need to hear that it's a problem from
> > customers.
>
> Done, lets see what I get in return. I think this problem will be
> a major obstacle for our next generation boards which will be NAND
> based.
It was a big problem, and a big surprise, for me too. The next
generation of a couple of the chips on the bus have pcie, but those
are noticably more expensive.
Another problem I ran into was that the DMA performance from a
non-incrementing address was abysmal, PIO turned out to be
significantly faster. I guess internally the bus does an entire
cacheline transfer for every word read from a fixed address, or
something like that. I was doing DMA from a device that had only six
address bits, it should have been in the middle of the bus with the
bottom address pins not connected, which would have allowed
incrementing address DMA. The transfer speed wasn't so much of a
problem, but the longer transfers meant that there was that much less
bus bandwidth for the other devices, so we wound up sacrificing CPU to
get more bus bandwidth.
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Joachim Förster @ 2010-12-08 19:20 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <1291815910.12093.15.camel@concordia>
Hi Guillaume,
Michael Ellerman wrote:
> On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
>> ///////////////////////////////////////////////////////////////////////////////
>> // Called on insmod
>> static int __init xad_init(void) {
>> int rc=0;
>> printk(KERN_INFO SD "Module %s: loading...\n" FL, NAME);
>>
Are you sure that you want to have the chrdev registration here (the
following code)?
Such stuff typically goes into the probe() function. The modules's
init() just registers the driver. Furthermore your global variables
prohibit having more than one device instance using the driver.
>> // Deal with the device
>> first = MKDEV (my_major, my_minor);
>> register_chrdev_region(first, count, DEVNAME);
>> my_cdev = cdev_alloc ();
>> if (NULL==my_cdev) goto Err;
>>
>> cdev_init(my_cdev, &fops);
>> cdev_add (my_cdev, first, count);
>>
>> printk(KERN_INFO SD "Module %s: Major=%d, Minor=%d, Count=%d\n" FL, NAME,
>> my_major, my_minor, count);
>>
>> // Driver
>> rc = platform_driver_register(&xad_driver);
>
> Should be of_register_platform_driver()
>
>> // rc = platform_driver_probe(&xad_driver, xad_driver_probe);
>> if (rc) goto err_plat;
>>
I think the following function call to platform_device_register_simple()
and if() does not belong here.
As was said before, "devices" are registered by the (platform) bus. Your
driver module, needs to just register, well, the "driver". You are doing
this above - and that's it: (of_)platform_driver_register().
>> // Device
>> pdev=platform_device_register_simple("xps-acqui-data", -1, NULL, 0);
>> if (IS_ERR(pdev)) {
>> rc = PTR_ERR(pdev);
>> platform_driver_unregister(&xad_driver);
>> goto err_plat;
>> }
>>
>>
>> return 0;
>>
>> err_plat:
>> unregister_chrdev_region(first, count);
>> Err:
>> printk(KERN_ERR SD "Module %s: Failed loading rc=%d\n" FL, NAME, rc);
>> return rc;
>> }
Joachim
^ permalink raw reply
* [PATCH 5/5] of/device: Show even unavailable nodes in procfs
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
Use the new "raw" of_get_next_child() variant so all device tree nodes
will appear in procfs.
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
fs/proc/proc_devtree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
index d9396a4..aa914eb 100644
--- a/fs/proc/proc_devtree.c
+++ b/fs/proc/proc_devtree.c
@@ -188,7 +188,7 @@ void proc_device_tree_add_node(struct device_node *np,
const char *p;
set_node_proc_entry(np, de);
- for (child = NULL; (child = of_get_next_child(np, child));) {
+ for (child = NULL; (child = _of_get_next_child(np, child));) {
/* Use everything after the last slash, or the full name */
p = strrchr(child->full_name, '/');
if (!p)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/5] of/device: Centralize checking of 'status' properties
From: Deepak Saxena @ 2010-12-08 19:29 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev
In-Reply-To: <cover.1291799069.git.deepak_saxena@mentor.com>
Don't call any of_platform_driver's probe() function if the device node is
not accessible (as denoted in the status property).
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
---
arch/powerpc/platforms/83xx/suspend.c | 3 ---
drivers/mmc/host/sdhci-of-core.c | 3 ---
drivers/net/gianfar.c | 2 +-
drivers/net/ibm_newemac/core.c | 2 +-
drivers/of/platform.c | 7 +++++--
5 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c
index 75ae77f..a5a54aa 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -326,9 +326,6 @@ static int pmc_probe(struct platform_device *ofdev,
struct pmc_type *type = match->data;
int ret = 0;
- if (!of_device_is_available(np))
- return -ENODEV;
-
has_deep_sleep = type->has_deep_sleep;
immrbase = get_immrbase();
pmc_dev = ofdev;
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index c51b711..51218d4 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -126,9 +126,6 @@ static int __devinit sdhci_of_probe(struct platform_device *ofdev,
int size;
int ret;
- if (!of_device_is_available(np))
- return -ENODEV;
-
host = sdhci_alloc_host(&ofdev->dev, sizeof(*of_host));
if (IS_ERR(host))
return -ENOMEM;
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index d1bec62..9918914 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -620,7 +620,7 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev)
unsigned int num_tx_qs, num_rx_qs;
u32 *tx_queues, *rx_queues;
- if (!np || !of_device_is_available(np))
+ if (!np)
return -ENODEV;
/* parse the num of tx and rx queues */
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 06bb9b7..290fff2 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2732,7 +2732,7 @@ static int __devinit emac_probe(struct platform_device *ofdev,
* property here for now, but new flat device trees should set a
* status property to "disabled" instead.
*/
- if (of_get_property(np, "unused", NULL) || !of_device_is_available(np))
+ if (of_get_property(np, "unused", NULL))
return -ENODEV;
/* Find ourselves in the bootlist if we are there */
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b4a07f..14370a0 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -56,7 +56,10 @@ static int platform_driver_probe_shim(struct platform_device *pdev)
* come up empty. Return -EINVAL in this case so other drivers get
* the chance to bind. */
match = of_match_device(pdev->dev.driver->of_match_table, &pdev->dev);
- return match ? ofpdrv->probe(pdev, match) : -EINVAL;
+ if (match && of_device_is_available(pdev->dev.of_node))
+ return ofpdrv->probe(pdev, match);
+
+ return -EINVAL;
}
static void platform_driver_shutdown_shim(struct platform_device *pdev)
@@ -142,7 +145,7 @@ static int of_platform_device_probe(struct device *dev)
of_dev_get(of_dev);
match = of_match_device(drv->driver.of_match_table, dev);
- if (match)
+ if (match && of_device_is_available(dev->of_node))
error = drv->probe(of_dev, match);
if (error)
of_dev_put(of_dev);
--
1.6.3.3
^ permalink raw reply related
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-08 19:57 UTC (permalink / raw)
To: Mark Mason; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20101208192616.GA24560@postdiluvian.org>
Mark Mason <mason@postdiluvian.org> wrote on 2010/12/08 20:26:16:
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 18:18:39:
> > >
> > > On Wed, 8 Dec 2010 08:59:49 +0100
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > > >
> > > > > On Mon, 6 Dec 2010 22:15:54 -0500
> > > > > Mark Mason <mason@postdiluvian.org> wrote:
> > > > >
> > > > > > A few months ago I ran into some performance problems involving
> > > > > > UBI/NAND erases holding other devices off the LBC on an MPC8315. I
> > > > > > found a solution for this, which worked well, at least with the
> > > > > > hardware I was working with. I suspect the same problem affects other
> > > > > > PPCs, probably including multicore devices, and maybe other
> > > > > > architectures as well.
> > > > > >
> > > > > > I don't have experience with similar NAND controllers on other
> > > > > > devices, so I'd like to explain what I found and see if someone who's
> > > > > > more familiar with the family and/or driver can tell if this is
> > > > > > useful.
> > > > > >
> > > > > > The problem cropped up when there was a lot of traffic to the NAND
> > > > > > (Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
> > > > > > a video chip that needed constant and prompt attention.
> > > > >
> > > > > If you attach NAND to the LBC, you should not attach anything else to
> > > > > it which is latency-sensitive.
> > > >
> > > > This "feature" makes the LBC useless to us. Is there some workaround or plan
> > > > to address this limitation?
> > >
> > > Complain to your support or sales contact.
> > >
> > > I've complained about it in the past, and got a "but pins are a limited
> > > resource!" response. They need to hear that it's a problem from
> > > customers.
> >
> > Done, lets see what I get in return. I think this problem will be
> > a major obstacle for our next generation boards which will be NAND
> > based.
>
> It was a big problem, and a big surprise, for me too. The next
> generation of a couple of the chips on the bus have pcie, but those
> are noticably more expensive.
Can you think of any workaround such as not connecting the BUSY pin at all?
^ 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