On Tuesday 22 July 2008, Ben Nizette wrote:
> But I'll let you get back to solving the UIO problem at hand :-D
I already surrendered and created (hacked) a read/write driver, which let me
use the old userspace drivers I'm trying to port (with some changes of
course). This was way faster than un
On Fri, 05 Sep 2008 14:36:41 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-09-04 at 20:49 -0700, Andrew Morton wrote:
> > On Fri, 05 Sep 2008 13:42:44 +1000 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> >
> > >
> > > > This is stupid:
> > > >
> > > > g5:/usr
On Thu, 2008-09-04 at 21:04 -0700, Andrew Morton wrote:
> On Fri, 05 Sep 2008 13:54:22 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
>
> > > a) someone broke powerpc's kallsyms processing and
> > >
> > > b) someone screwed up their procfs handling.
> >
> > I think the proc bug is ol
On Thu, 2008-09-04 at 20:49 -0700, Andrew Morton wrote:
> On Fri, 05 Sep 2008 13:42:44 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
>
> >
> > > This is stupid:
> > >
> > > g5:/usr/src/25> gdb vmlinux
> > > GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
> > > Copyright 2004 Free Software Fo
On Fri, 05 Sep 2008 13:54:22 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> > a) someone broke powerpc's kallsyms processing and
> >
> > b) someone screwed up their procfs handling.
>
> I think the proc bug is old, might have to do with /proc/bus/pci...
> I have that on my G5 too wi
> a) someone broke powerpc's kallsyms processing and
>
> b) someone screwed up their procfs handling.
I think the proc bug is old, might have to do with /proc/bus/pci...
I have that on my G5 too with 2.6.26, I think I just forgot about it..
Care to give that untested patch a try ?
powerpc: Alw
On Fri, 05 Sep 2008 13:42:44 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > This is stupid:
> >
> > g5:/usr/src/25> gdb vmlinux
> > GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public
> This is stupid:
>
> g5:/usr/src/25> gdb vmlinux
> GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
On Fri, 5 Sep 2008 12:10:37 +1000
Simon Horman <[EMAIL PROTECTED]> wrote:
> > +static irqreturn_t mal_int(int irq, void *dev_instance)
> > +{
> > + struct mal_instance *mal = dev_instance;
> > + u32 esr = get_mal_dcrn(mal, MAL_ESR);
> > +
> > + if (esr & MAL_ESR_EVB) {
> > + /* de
On Fri, 05 Sep 2008 13:19:23 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-09-04 at 11:02 -0400, Josh Boyer wrote:
> > There are some PowerPC SoCs that do odd things with the MAL handling. In
> > order to accommodate them, we need to introduce a feature mechanism that is
On Thu, 2008-09-04 at 11:02 -0400, Josh Boyer wrote:
> There are some PowerPC SoCs that do odd things with the MAL handling. In
> order to accommodate them, we need to introduce a feature mechanism that is
> similar to the existing emac_has_feature function.
>
> This adds a feature variable to th
Booting the putative 2.6.27-rc5-mm1 lineup on the g5 I see:
io scheduler cfq registered
proc_dir_entry '00' already registered
Call Trace:
[c0017a0fbae0] [c0012540] unrecov_restore+0x98d8/0x1220c
(unreliable)
[c0017a0fbb90] [c0149798] dst_error+0x117d3c/0x42ba04
[c001
On Thu, Sep 04, 2008 at 11:02:16AM -0400, Josh Boyer wrote:
> The PowerPC 405EZ SoC has some differences in the interrupt layout and
> handling for the MAL. The SERR, TXDE, and RXDE interrupts are OR'd into
> a single interrupt. Also, due to the possibility for interrupt coalescing,
> the TXEOB a
There is a small bug in the handling of 16G hugepages recently added
to the kernel. This doesn't cause a crash or other user-visible
problems, but it does mean that more levels of pagetable are allocated
than makes sense for 16G pages. The hugepage pagetables for the 16G
pages are allocated much
On Thu, Sep 04, 2008 at 04:08:30PM -0500, Jon Tollefson wrote:
> Jon Tollefson wrote:
> > David Gibson wrote:
> >
> >> On Tue, Sep 02, 2008 at 12:12:27PM -0500, Jon Tollefson wrote:
[snip]
> > I have run through the tests twice now with this new patch using a 4k
> > base page size(and 16G huge p
> I assume that's the reason the suggested approach failed.
I think (hope) that Vitaly actually fixed that before trying it :-)
> I don't mind doing that, provided the changes are cleaned up so that
> they don't affect people who aren't building kernels for 44x systems.
I also find the CONFIG_
Current linus tree fail to build for me for a 64bit powerpc config with:
WARNING: modpost: Found 13 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
mm/built-in.o: In function `.strndup_user':
(.text+0x1401a): undefined reference to `.LCTOC0'
On Wed, Sep 03, 2008 at 05:19:27PM -0500, Jon Tollefson wrote:
> David Gibson wrote:
> > On Tue, Sep 02, 2008 at 12:12:27PM -0500, Jon Tollefson wrote:
> >
> >> David Gibson wrote:
> >>
> >>> When BenH and I were looking at the new code for handling 16G pages,
> >>> we noticed a small bug.
> -Original Message-
> From: Scott Wood [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 4 September 2008 3:15 AM
> To: Janaka Subhawickrama
> Cc: 'linuxppc-dev@ozlabs.org'
> Subject: Re: Kernel crash while initialising PCI
>
> On Wed, Sep 03, 2008 at 05:50:10PM +1000, Janaka Subhawickrama wrote
>> Make dereference_function_descriptor() more accommodating by allowing
>> architecture overrides. I put the three overrides (for parisc64, ppc64
>> and ia64) in arch/kernel/module.c because that's where the kernel
>> internal linker which knows how to deal with function descriptors sits.
>>
>> S
On Wed, 2008-09-03 at 10:37 -0500, Becky Bruce wrote:
> It's the size of the hardware PTE; make that clear in the name.
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
> ---
> arch/powerpc/mm/hash_low_32.S | 36 ++-
> Make dereference_function_descriptor() more accommodating by allowing
> architecture overrides. I put the three overrides (for parisc64, ppc64
> and ia64) in arch/kernel/module.c because that's where the kernel
> internal linker which knows how to deal with function descriptors sits.
>
> Signed
On Fri, 5 Sep 2008, Vitaly Bordug wrote:
> I've started looking this way. Sorry, but this approach is a little bit
> fragile, and unreliable.
>
> First, it just did not work out in case of usb2 hub with memory stick
> and keybord plugged - OHCI did not suspend, ehci is hosed and we're
> happily u
On Thu, 2008-09-04 at 21:17 +0200, Rafal Jaworowski wrote:
> Kumar Gala wrote:
> [...]
> > The intent of this change is to handle SMP based invalidates via IPIs
> > instead
> > of broadcasts as the mechanism scales better for larger number of cores.
>
> Hi Kumar,
>
> How is the inter-IPI deadloc
Jon Tollefson wrote:
> David Gibson wrote:
>
>> On Tue, Sep 02, 2008 at 12:12:27PM -0500, Jon Tollefson wrote:
>>
>>
>>> David Gibson wrote:
>>>
>>>
When BenH and I were looking at the new code for handling 16G pages,
we noticed a small bug. It doesn't actually bre
В Fri, 29 Aug 2008 17:30:57 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> пишет:
> On Fri, 29 Aug 2008, Vitaly Bordug wrote:
>
> > But even assuming PM set, common use-case of
> > embedded systems to have stuff on USB bus that is never plugged off;
> > and in case of compiled-in ehci and ohci there
I followed your advice : I used the UART layer.
It is easier.
Thanks
Benjamin Herrenschmidt a écrit :
On Tue, 2008-09-02 at 09:34 +0200, Sébastien Chrétien wrote:
ok is it a bad way to write a tty driver ? why ?
Not necessarily, it's just overkill. The UART layer handles a lot
of st
On Wed, Aug 6, 2008 at 11:48 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Add the fsl,playback-dma and fsl,capture-dma properties to the Freescale
> MPC8610 HPCD device tree. These properties connect the SSI nodes to the
> DMA nodes for the DMA channels that the SSI should use. Also update the
> s
Kumar Gala wrote:
[...]
> The intent of this change is to handle SMP based invalidates via IPIs instead
> of broadcasts as the mechanism scales better for larger number of cores.
Hi Kumar,
How is the inter-IPI deadlock avoidance designed in this new approach? I don't
know the close details of low
Thanks Scott,
It is hooked and alive! Your couple of lines guided me through. Here's
the outline of what I did after looking
at other powerpc drivers and the ePAPR document from Power.org:
1. Assumed that MPC83xx_IRQ_EXT1 (0x11 without offset) corresponds to IRQ1.
2. Created a node in my dts t
В Thu, 04 Sep 2008 08:01:38 +0200
Heiko Schocher <[EMAIL PROTECTED]> пишет:
> Hello Vitaly,
>
> I tried to use the mii-bitbang driver
> (drivers/net/fs_enet/mii-bitbang.c) as a module and got the following
> error, when inserting it with insmod:
>
> ~ # insmod fs_enet
> eth0: fs_enet: a6:07:11:7
> I would be careful about adding overhead to memcpy. I found that in
> the kernel, almost all calls to memcpy are for less than 128 bytes (1
> cache line on most 64-bit machines). So, adding a lot of code to
> detect cacheability and do prefetching is just going to slow down the
> common case, w
On Thu, Sep 04, 2008 at 06:28:29PM +0400, Dmitry Baryshkov wrote:
> Hi,
>
> Sorry to bother you. I'm searching for the information/guides related to
> the Maple D board (XSC-100). I've downloaded all the info I could get
> from the IBM, but I'm still missing the docs about board
> jumpers/settings
On Thursday 04 September 2008 17:01:21 Gunnar Von Boehn wrote:
>[...]
> Regarding the 5121.
> David, you did create a very special memcopy for the 5121e CPU.
> Your test showed us that the normal glibc memcopy is about 10 times
> slower than expected on the 5121.
>
> I really wonder why this is the
Hi Steven,
On Thursday 04 September 2008 16:31:13 Steven Munroe wrote:
>[...]
> > Yes, I admit my testcase is focussing on optimizing memcpy() of uncached
> > data, and that interest stems from the fact that I was testing X11
> > performance (using xorg kdrive and xorg-server), and wondering why
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the default config file for GE Fanuc's SBC610, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---
arch/powerpc/configs/86xx/gef_sbc610_defconfig
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's SBC610, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 26
The following series implements basic board support for GE Fanuc's SBC610, a
6U single board computer, based on Freescale's MPC8641D.
This series provides basic functionality:
- The board can boot with a serial console.
- Ethernet works, though the phys are polled.
- The PCI bus is scanned and sa
Add simple defconfig for the AMCC PowerPC 405EZ Acadia evaluation board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/configs/40x/acadia_defconfig | 917 +
1 files changed, 917 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/40x
This adds a cuboot wrapper for the AMCC PowerPC 405EZ Acadia board. The
clocking code is derived from U-Boot, originally written by Stefan Roese.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile|4 +-
arch/powerpc/boot/cuboot-acadia.c | 198 ++
Add base support for the AMCC PowerPC 405EZ Acadia evalution board. In addition
to some of the normal PPC 40x peripherals, the Acadia board has:
- 64 MiB PSRAM
- NOR and NAND flash
- Two USB 1.1 host ports
- Two CAN 2.0 ports
- ADC and DAC connectors
- LCD display
This adds the basic platfo
Add the DTS for the AMCC PowerPC 405EZ Acadia evaluation board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/acadia.dts | 224 ++
1 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/acadia.dts
This adds initial support for the AMCC PowerPC 405EZ board. Mostly
sending these out for comments as I clean them up. The cuboot wrapper
needs particular cleaning, as the clocking function has a ridiculous
number of variables. But hey, it works. These patches depend on the
EMAC series I sent ou
On Wed, 03 Sep 2008 19:26:35 -0400
Jerry Van Baren <[EMAIL PROTECTED]> wrote:
> Martyn Welch wrote:
> > On Fri, 29 Aug 2008 07:04:18 -0500
> > Kumar Gala <[EMAIL PROTECTED]> wrote:
> >> what u-boot version are you using/shipping with these boards?
> >
> > U-boot 1.2.0
>
> 1.2.0 predates the libf
On Thu, 04 Sep 2008 10:04:04 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
> Martyn Welch wrote:
> > On Tue, 2 Sep 2008 13:27:09 -0500
> > Scott Wood <[EMAIL PROTECTED]> wrote:
> >
> >> On Mon, Sep 01, 2008 at 11:27:59AM +0100, Martyn Welch wrote:
> >>> +static __initdata struct of_device_id of_bus
Scott Wood wrote:
On Wed, Sep 03, 2008 at 03:55:41PM -0700, Oscar Takeshita wrote:
I've been trying to hook an IRQ on a modified mpc8349emitx board without
success.
The IRQ is hooked physically to IRQ1/GPIO2[13] on the mpc8349e. No other
devices are
tied to this pin.
I'm using uboot 1.2.0 a
On Thu, Sep 04, 2008 at 08:44:31AM -0500, Matt Sealey wrote:
> I was thinking about this actually, similar to the Efika Device Tree
> Supplement for MPC5200B board (which adds a lot of device tree nodes
> not present on the production model and fixes some things), we have
> a Pegasos one too whic
Hi Steve,
> I have personally optimized memcpy for power4/5/6 and they are all
> different. There are dozens of different PPC implementations from
> different manufacturers and design, every one is different! With painful
> negotiation I was able to get the --with-cpu= framework added to glibc
> b
Hi David,
Regarding your testcase.
I think we all agree with you that improving the performance for PPC
is a noble quest
and we should all try do improve the performance where possible.
Regarding the 5200B and 5221 CPUs.
As we all know the 5200B is a G2 PowerPC from Freescale.
The factor for
Steve,
I think we should be grateful for people being interested in improving
performance for PPC,
and we should not bash them.
The proposal to optimize the memcopy for the 5200 is good.
Steve, you said that you've heard about the 5200..
Maybe I can refresh your memory:
I did send you an optimi
Hi,
Sorry to bother you. I'm searching for the information/guides related to
the Maple D board (XSC-100). I've downloaded all the info I could get
from the IBM, but I'm still missing the docs about board
jumpers/settings/etc. All official sources for info are dead since long
ago. So, if one has an
Martyn Welch wrote:
On Tue, 2 Sep 2008 13:27:09 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
On Mon, Sep 01, 2008 at 11:27:59AM +0100, Martyn Welch wrote:
+static __initdata struct of_device_id of_bus_ids[] = {
+ { .compatible = "simple-bus", },
+ { .type = "serial", },
+ { .t
The PowerPC 405EZ SoC has some differences in the interrupt layout and
handling for the MAL. The SERR, TXDE, and RXDE interrupts are OR'd into
a single interrupt. Also, due to the possibility for interrupt coalescing,
the TXEOB and RXEOB interrupts require an interrupt bit to be cleared in
the IC
There are some PowerPC SoCs that do odd things with the MAL handling. In
order to accommodate them, we need to introduce a feature mechanism that is
similar to the existing emac_has_feature function.
This adds a feature variable to the mal_instance structure, and adds a
mal_has_feature function w
Some PowerPC 40x chips have errata that force us not to use the integrated
flow control. We have the feature defined, but it currently can't be used
because it is never added to EMAC_FTRS_POSSIBLE.
This adds a Kconfig option for affected platforms to select and puts the
feature in the EMAC_FTRS_P
The following patch series adds things needed to support the
PowerPC 405EZ SoC. I'm mostly sending these out now for review
and feedback, since I'll need to get these fixed up before I can
send out the Acadia board port patches.
The first patch should be good as-is. The second two might need a
b
On Tue, 2 Sep 2008 13:27:09 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 01, 2008 at 11:27:59AM +0100, Martyn Welch wrote:
> > +static __initdata struct of_device_id of_bus_ids[] = {
> > + { .compatible = "simple-bus", },
> > + { .type = "serial", },
> > + { .type = "soc", },
>
This patch adds support for the AD7414 temperature sensor
on Sequoia PPC440EPx board.
Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/
On Wed, Sep 03, 2008 at 03:55:41PM -0700, Oscar Takeshita wrote:
> I've been trying to hook an IRQ on a modified mpc8349emitx board without
> success.
>
> The IRQ is hooked physically to IRQ1/GPIO2[13] on the mpc8349e. No other
> devices are
> tied to this pin.
>
> I'm using uboot 1.2.0 and ker
Hi,
On Thursday 04 September 2008 14:25, Josh Boyer wrote:
> On Thu, Sep 04, 2008 at 11:55:02AM +0200, Matthias Fuchs wrote:
> >Hi,
> >
> >I added support for the Sequoia on-board I2C temperature sensor to the
> >device.
> >I am not sure if there is any node naming convention for such devices.
>
On Thu, 2008-09-04 at 14:59 +0200, David Jander wrote:
> On Thursday 04 September 2008 14:19:26 Josh Boyer wrote:
> >[...]
> > >(I have edited the output of this tool to fit into an e-mail without
> > > wrapping lines for readability).
> > >Please tell me how on earth there can be such a big differ
On Thu, Sep 04, 2008 at 03:23:21PM +0200, Sébastien Chrétien wrote:
> I try to write a device tree about irq :
>
> IT_controller: [EMAIL PROTECTED] {
>clock-frequency = <0>;
>interrupt-controller;
> #address-cells = <0>;
>reg = <0x2000600
Commit a61f5345 (spi_mpc83xx clockrate fixes) broke clockrate
calculation for low speeds. SPMODE_DIV16 should be set if the
divider is higher than 64, not only if the divider gets clipped
to 1024.
Furthermore, the clipping check was off by a factor 16 as well.
Signed-off-by: Peter Korsgaard <[EMA
I was thinking about this actually, similar to the Efika Device Tree Supplement
for MPC5200B board (which adds a lot of device tree nodes not present on the
production model and fixes some things), we have a Pegasos one too which changes
some very minor stuff.
This could be in the kernel (chrp fi
Various changes to support QE USB Host and Gadget on MPC8360E-MDS
boards:
- Update the device tree per QE USB bindings;
- Configure QE Par IO;
- Set up BCSR for both USB Host and Peripheral modes;
- Add timer (GTM) node;
- Add gpio-controller node for BCSR13 bank;
- Select FSL_GTM and QE_USB.
The
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may
be found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks.
I try to write a device tree about irq :
IT_controller: [EMAIL PROTECTED] {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
reg = <0x20006000 0x100>;
compatible = "it";
device_type = "it";
On Thursday 04 September 2008 14:19:26 Josh Boyer wrote:
>[...]
> >$ ./memcpyspeed
> >Fully aligned:
> >10 chunks of 5 bytes : 3.48 Mbyte/s ( throughput: 6.96 Mbytes/s)
> >5 chunks of 16 bytes : 14.3 Mbyte/s ( throughput: 28.6 Mbytes/s)
> >1 chunks of 100 bytes : 14.4 Mbyte/s
On Thursday 04 September 2008, Josh Boyer wrote:
> >Do we want to add this to the sequoia dts file? If this is how it should
> > be done, I will commit a proper patch.
>
> See comments below. Out of curiosity, do you have a working driver and
> setup with this?
Sure, it did hit mainline with 2.6.
irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
and insertion which happen in interrupt and process context respectively.
Separate the function into its 2 components, one for lookup only and one
for insertion only.
Fix the only user of the revmap tree (XICS) to use the ne
Hi ,
here is V4 for the powerpc IRQ radix tree reverse mapping rework.
Big thanks to Benjamin Herrenschmidt for his most useful comments.
V3 -> V4: from comments by Benjamin Herrenschmidt
- Dump the use of a global atomic variable for synchronization between the
radix tree initiali
The radix trees used by interrupt controllers for their irq reverse mapping
(currently only the XICS found on pSeries) have a complex locking scheme
dating back to before the advent of the lockless radix tree.
Take advantage of this and of the fact that the items of the tree are
pointers to a
On Thu, Sep 04, 2008 at 11:55:02AM +0200, Matthias Fuchs wrote:
>Hi,
>
>I added support for the Sequoia on-board I2C temperature sensor to the device.
>I am not sure if there is any node naming convention for such devices.
>The needed I2C driver can be found under drivers/hwmon in the kernel source
On Thu, Sep 04, 2008 at 02:45:05PM +0800, Li Yang-R58472 wrote:
> > -Original Message-
> > From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
> > Sent: Monday, September 01, 2008 9:35 PM
> > To: Kumar Gala
> > Cc: linuxppc-dev@ozlabs.org; Li Yang-R58472
> > Subject: [RFC PATCH 2/2 v2] powerpc
On Thu, Sep 04, 2008 at 02:05:16PM +0200, David Jander wrote:
>> I would be careful about adding overhead to memcpy. I found that in
>> the kernel, almost all calls to memcpy are for less than 128 bytes (1
>> cache line on most 64-bit machines). So, adding a lot of code to
>> detect cacheability
On Thursday 04 September 2008 04:04:58 Paul Mackerras wrote:
> prodyut hazarika writes:
> > glibc memxxx for powerpc are horribly inefficient. For optimal
> > performance, we should should dcbt instruction to establish the source
> > address in cache, and dcbz to establish the destination address i
Hi,
I added support for the Sequoia on-board I2C temperature sensor to the device.
I am not sure if there is any node naming convention for such devices.
The needed I2C driver can be found under drivers/hwmon in the kernel sources,
so I found "hwmon" suitable for the node.
Do we want to add this
I read the booting_without_of.txt document and the Interrupt Mapping
docucument from http://playground.sun.com/1275. But I don't understand all
parameters. Can somebody help me to create my device tree about interrupt
part ?
I have an interrupt controller at the adresse 0x20006000. The irq_id rang
On Tue, 2 Sep 2008 13:27:09 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 01, 2008 at 11:27:59AM +0100, Martyn Welch wrote:
> > +static __initdata struct of_device_id of_bus_ids[] = {
> > + { .compatible = "simple-bus", },
> > + { .type = "serial", },
> > + { .type = "soc", },
>
On Thu, 04 Sep 2008 17:58:56 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > There's nothing to 'de-initialize' here, or am I missing something?
> > radix_tree_insert() will return ENOMEM and won't insert anything.
>
> Forget my comment, just fallback.
>
> > > Or you can fallba
> There's nothing to 'de-initialize' here, or am I missing something?
> radix_tree_insert() will return ENOMEM and won't insert anything.
Forget my comment, just fallback.
> > Or you can fallback if you don't find, as easy, probably
> > easier since it shouldn't happen in practice.
>
> That
On Thu, 04 Sep 2008 17:34:03 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > > > I could not think of anything simple so far and I'm open for
> > > > suggestions.
> > >
> > > GFP_KERNEL should not fail, it will just block no ?
> >
> > No it won't block and will fail (returns
> > > I could not think of anything simple so far and I'm open for
> > > suggestions.
> >
> > GFP_KERNEL should not fail, it will just block no ?
>
> No it won't block and will fail (returns NULL).
hrm... it used to never fail.. that may have changed. But it will
definitely block and try v
On Thu, 04 Sep 2008 12:52:19 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-09-03 at 15:41 +0200, Sebastien Dugue wrote:
> > On Wed, 20 Aug 2008 15:23:01 +1000 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> >
> > > BTW. It would be good to try to turn the GFP_AT
Hi all,
I am trying to port Linux 2.6 on PPC405 processor.I have EDK 10.1,
Xilinx University program board (with Virtex II Pro device)
linux kernel from Xilinx git. (git.xilinx.com)
Cross Compiler (Croostool)
fdt.dts file generated by EDK using with help of Xilinx fdt
patch.(gen-device-tree-mh
85 matches
Mail list logo
