* High Memory problem on 2.4.22 Linux, 2GB ppc card
From: Ruksen INANIR @ 2008-06-30 9:22 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am working on a PPC Motorola card, which runs Linux 2.4.22. The
card has 2 GB onboard memory. But with use 1456 MB of the available
memory. To increase the memory capacity i need to increase the used
memory at least 64 MB. With CONFIG_HIGHMEM option all of the 2 GB memory
can be used but, but the fc driver on the card has no high memory
support, so this caused problems.
Then i saw that the memory is limited to 1456 by
#define MAX_LOW_MEM 0x5B000000 setting in pgtable.c. I tried
to increase it by 64 MB but i could only increase the value of
MAX_LOW_MEM by 47 MB (1503 MB) without CONFIG_HIGHMEM option.
1)Is there any other setting that i should set other than
MAX_LOW_MEM to increase the usable memory to 1520 ?
2)I knew that the addressable physical memory without high memory
option was 1 G. How was it possible to address 1503 MB without
CONFIG_HIGHMEM ? What is the max usable memory for 2.4.22 kernel?
Thanks,
Rinanir.
^ permalink raw reply
* High Memory problem on 2.4.22 Linux, 2GB ppc card
From: Ruksen INANIR @ 2008-06-30 9:20 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I am working on a PPC Motorola card, which runs Linux 2.4.22. The
card has 2 GB onboard memory. But with use 1456 MB of the available
memory. To increase the memory capacity i need to increase the used
memory at least 64 MB. With CONFIG_HIGHMEM option all of the 2 GB memory
can be used but, but the fc driver on the card has no high memory
support, so this caused problems.
Then i saw that the memory is limited to 1456 by
#define MAX_LOW_MEM 0x5B000000 setting in pgtable.c. I
tried to increase it by 64 MB but i could only increase the value of
MAX_LOW_MEM by 47 MB (1503 MB) without CONFIG_HIGHMEM option.
1)Is there any other setting that i should set other than
MAX_LOW_MEM to increase the usable memory to 1520 ?
2)I knew that the addressable physical memory without high memory
option was 1 G. How was it possible to address 1503 MB without
CONFIG_HIGHMEM ? What is the max usable memory for 2.4.22 kernel?
Thanks,
Rinanir.
^ permalink raw reply
* Re: [PATCH V2] Keep 3 high personality bytes across exec
From: Paul Mackerras @ 2008-06-30 8:19 UTC (permalink / raw)
To: Eric B Munson; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080628000813.GA19960@us.ibm.com>
Eric B Munson writes:
> --- a/include/asm-powerpc/elf.h
> +++ b/include/asm-powerpc/elf.h
> @@ -257,7 +257,8 @@ do { \
> else \
> clear_thread_flag(TIF_ABI_PENDING); \
> if (personality(current->personality) != PER_LINUX32) \
> - set_personality(PER_LINUX); \
> + set_personality(PER_LINUX | \
> + (current->personality & PER_INHERIT)); \
Couldn't we use ~PER_MASK here instead of PER_INHERIT? That would
mean we wouldn't have to modify include/linux/personality.h, and we
wouldn't have to keep updating PER_INHERIT as more flags get added.
(Nice patch description, BTW. Thanks.)
Paul.
^ permalink raw reply
* RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Michal Simek @ 2008-06-30 7:11 UTC (permalink / raw)
To: microblaze-uclinux
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew, alan,
linux-kernel, linuxppc-dev, will.newton, hpa, John Linn, drepper,
John Williams
In-Reply-To: <20080630033943.332471860046@mail171-va3.bigfish.com>
Hi Steve, John a others,
>In my opionion, we should only include dts files for reference designs, and it
>must be documented how to get the design that the dts corresponds to.
>MD5 hashing might be one way to prevent people from getting the dts file wrong,
>however without some way of checking it automatically, I don't think
>anyone will have the patience to checksum the design they have (even worse, with
>whitespace changes, the md5 sum will change, so this is pretty fragile.
What is reference design? Is reference design design from BSB or from Xilinx page?
I don't want to add dts files to kernel which has relation with reference design. I added platform folder
with generic one for preparing for others distribution which can add their supported board. I don't want
to added useless files to kernel. For non FPGA board make sense to me, they can't change everything.
I see the way that I can add ref design to my pages with correspond DTS file with some MD5 sums
but I haven't seen to add for every reference board dts file. This is not way. I see that people will write to us
that they use board ml401 and they set ml401 in menuconfig but the kernel doesn't work. IMHO, if no board specific options
are not there, people will be looking for what is the next step. And If they want to use platform option which is there, they can add their own platform to his kernel.
>Having a device tree in the kernel for documentation *shouldn't* be necessary,
>since noone should ever write their dts by hand. (right?)
>Hence, I'd prefer to not put the dts file in the kernel at all, and but to
>automatically generate the dts and store it in the blockram of the design.
>This inextricably associates the dts with the design.
This should be one choice to add DTB to bram with design but this could be only one choice
not in general. I can't imagine for example board where is reset logic on own IP which has specific
reason. Developers will be overwrite their DTS a lot.
I think this is the right time to stop discussion in this thread and annoying others with FPGA specific discuss. We can continue in specific thread.
>As for the copyright, I haven't been able to find much information on whether or
>not generated files are even copyrightable. One might argue that they
>don't have sufficient 'creative value' to be copyrightable. Or arguably, they
>are as copyrightable by the generator author as by the author or the .mhs file.
>I admit in this case, I've followed the safe route by claiming a copyright,
>which at least at Xilinx has significant precedent.
This part can be discuss only on microblaze mailing list and has no relation with first pull to mainline kernel.
As I wrote in previous email copyright on generic DTS will not be there.
Michal
>Steve
-----Original Message-----
From: John Williams [mailto:john.williams@petalogix.com]
Sent: Sun 6/29/2008 5:02 PM
To: grant.likely@secretlab.ca
Cc: monstr@seznam.cz; linux-kernel@vger.kernel.org; arnd@arndb.de;
linux-arch@vger.kernel.org; Stephen Neuendorffer; John Linn; matthew@wil.cx;
will.newton@gmail.com; drepper@redhat.com; microblaze-uclinux@itee.uq.edu.au;
linuxppc-dev@ozlabs.org; vapier.adi@gmail.com; alan@lxorguk.ukuu.org.uk;
hpa@zytor.com; Michal Simek
Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
On Sat, Jun 28, 2008 at 3:49 PM, Grant Likely <grant.likely@secretlab.ca>
wrote:
> On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
>> From: Michal Simek <monstr@monstr.eu>
>> arch/microblaze/platform/generic/system.dts | 300
+++++++++++++++++++++++++++
> Since this is a generated file, and entirely bitstream specific, does
> it make sense to include it in the kernel tree? If it does, then is
> it produced from one of the Xilinx reference designs? Can you add
> documentation to the header that specifies exactly which design
> version this .dts is for?
I think there's value in having a generic DTS as an example or
template, even if it doesn't correspond to any specific machine.
Agreed a comment block explaining this is valuable.
I'd almost oppose any attempt to include a standard DTS for things
like ML401 boards etc - they are just misleading. Unless we do MD5
hashes on MHS files, and use them as the filenames, any attempt to
define a standard platform will just fail and confuse people. Better
to show them how to generate the DTS for their system.
>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007-2008 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@monstr.eu>
>
> If this is a generated file, then is this copyright notice even appropriate?
I agree. I think Michal is just copying Xilinx's habit of putting
copyright headers in generated files, and it's one that we should stop
now.
Regards,
John
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH 19/60] microblaze_v4: checksum support
From: Michal Simek @ 2008-06-30 7:18 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev, alan,
hpa, drepper, john.williams, will.newton
In-Reply-To: <6e8c2b4453be89dba35e0595c9cfcf0a@kernel.crashing.org>
Hi Segher,
you find bug because there is microblaze asm code in generic folder.
Big thanks. I'll fix it and I'll look at parameters too.
Michal
> +static inline unsigned int
> +csum_tcpudp_nofold(unsigned long saddr, unsigned long daddr, unsigned
> short len,
> + unsigned short proto, unsigned int sum)
> +{
> + __asm__("add %0, %4, %1\n\t"
> + "addc %0, %4, %2\n\t"
> + "addc %0, %4, %3\n\t"
> + "addc %0, %4, r0\n\t"
> + : "=d" (sum)
> + : "d" (saddr), "d" (daddr), "d" (len + proto),
> + "0"(sum));
"sum" should use an earlyclobber, i.e. "=&d"(sum) , since some
inputs are used after %0 is first written to.
Also, you can use "+" instead of "=" to say the argument is both
input and output, and get rid of %4, if you like.
Segher
^ permalink raw reply
* [POWERPC] mpc7448hpc2.dts: remove chosen node from dts
From: Chunbo Luo @ 2008-06-30 3:03 UTC (permalink / raw)
To: linuxppc-dev
=EF=BB=BFModern versions of u-boot create a chosen node automatically. So =
if
we set the chosen node in the dts file, there will be 2 chosen nodes
passed in to the kernel, and the kernel command line will be taken from
the wrong node. So, remove the extra chosen node from the dts file.
=EF=BB=BFSigned-off-by: Chunbo Luo <chunbo.luo@windriver.com>
---
arch/powerpc/boot/dts/mpc7448hpc2.dts | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts
b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 4936349..d74727f 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -186,8 +186,5 @@
};
};
};
- chosen {
- linux,stdout-path =3D "/tsi108@c0000000/serial@7808";
- };
=20
};
---
^ permalink raw reply related
* Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Michal Simek @ 2008-06-30 6:48 UTC (permalink / raw)
To: John Williams
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, hpa, drepper, alan
In-Reply-To: <1d3f23370806291702g4344a2f9lb62f85cbb475fca4@mail.gmail.com>
Hi John, Steve and others,
in generic platform will be generic DTS which I sent in first versions.
This DTS will be for simple platform. There is not copyright.
FDT generator add copyright notice on the top of file. I added it when I start
to program this BSP. Xilinx only add their copyright line which is fine.
We can talk how big can be this copyright but I am convinced that will be
part of commented code forever because there is placed important information
which EDK version this file generated and which version of FDT this file generate.
We can talk about showing license there but I think this is out of topic now because there
won't be any license in first microblaze pack.
Michal
> Since this is a generated file, and entirely bitstream specific, does
> it make sense to include it in the kernel tree? If it does, then is
> it produced from one of the Xilinx reference designs? Can you add
> documentation to the header that specifies exactly which design
> version this .dts is for?
I think there's value in having a generic DTS as an example or
template, even if it doesn't correspond to any specific machine.
Agreed a comment block explaining this is valuable.
I'd almost oppose any attempt to include a standard DTS for things
like ML401 boards etc - they are just misleading. Unless we do MD5
hashes on MHS files, and use them as the filenames, any attempt to
define a standard platform will just fail and confuse people. Better
to show them how to generate the DTS for their system.
>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007-2008 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@monstr.eu>
>
> If this is a generated file, then is this copyright notice even appropriate?
I agree. I think Michal is just copying Xilinx's habit of putting
copyright headers in generated files, and it's one that we should stop
now.
Regards,
John
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v2] powerpc/bootwrapper: Add documentation of boot wrapper targets
From: Paul Mackerras @ 2008-06-30 5:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, john.linn
In-Reply-To: <20080628050407.6067.90225.stgit@trillian.secretlab.ca>
Grant Likely writes:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> There have been many questions on and off the mailing list about how
> exactly the bootwrapper is used for embedded targets. Add some
> documentation and help text to try and clarify the system.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
...
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index d6c96d9..7cd4182 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -203,6 +203,10 @@ simpleboot-virtex405-*)
> platformo="$object/virtex405-head.o $object/simpleboot.o"
> binary=y
> ;;
> +simpleboot-*)
> + platformo="$object/simpleboot.o"
> + binary=y
> + ;;
> esac
Evidently your patch does more than just "Add documentation"...
Paul.
^ permalink raw reply
* [POWERPC] mpc7448hpc2.dts: remove chosen node from dts
From: Chunbo Luo @ 2008-06-30 4:37 UTC (permalink / raw)
To: linuxppc-dev
=EF=BB=BF=EF=BB=BFModern versions of u-boot create a chosen node automatica=
lly. So if
we set the chosen node in the dts file, there will be 2 chosen nodes
passed in to the kernel, and the kernel command line will be taken from
the wrong node. So, remove the extra chosen node from the dts file.
=EF=BB=BFSigned-off-by: Chunbo Luo <chunbo.luo@windriver.com>
---
arch/powerpc/boot/dts/mpc7448hpc2.dts | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts
b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 4936349..d74727f 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -186,8 +186,5 @@
};
};
};
- chosen {
- linux,stdout-path =3D "/tsi108@c0000000/serial@7808";
- };
=20
};
---
^ permalink raw reply related
* Re: [PATCH 08/18 v2] powerpc: Do not probe PCI buses or eBus devices if CMO is enabled
From: Paul Mackerras @ 2008-06-30 4:32 UTC (permalink / raw)
To: Robert Jennings; +Cc: Brian King, linuxppc-dev, David Darrington
In-Reply-To: <20080625201721.GJ17020@linux.vnet.ibm.com>
Robert Jennings writes:
> From: Brian King <brking@linux.vnet.ibm.com>
>
> The Cooperative Memory Overcommit (CMO) on System p does not currently
> support native PCI devices or eBus devices when enabled.
Then why would we get any native PCI or eBus devices in the device
tree?
Paul.
^ permalink raw reply
* Re: [PATCH v2] powerpc: Add dma nodes to 83xx, 85xx and 86xx boards
From: David Gibson @ 2008-06-30 4:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0806271609540.10625@blarg.am.freescale.net>
On Fri, Jun 27, 2008 at 04:10:17PM -0500, Kumar Gala wrote:
> Added DMA nodes for the elo/elo-plus DMA engines.
>
> Renamed the interrupt controller alias in mpc832x_rdb.dts to ipic so that
> its the same as all the other boards.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
[snip]
> diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts b/arch/powerpc/boot/dts/asp834x-redboot.dts
> index 972cf78..8b1bb0e 100644
> --- a/arch/powerpc/boot/dts/asp834x-redboot.dts
> +++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
> @@ -118,6 +118,41 @@
> mode = "cpu";
> };
>
> + dma@82a8 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8347-dma", "fsl,elo-dma";
> + reg = <0x82a8 4>;
> + ranges = <0 0x8100 0x1a8>;
> + interrupt-parent = <&ipic>;
> + interrupts = <71 8>;
> + cell-index = <0>;
What's the cell-index in these nodes used to index? Given the
confusion there's been about the proper use of this property, a
comment indicating which shared registers this is used to index is
probably a good idea.
--
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: [PATCH 2/4] spi: split up spi_new_device() to allow two stage registration.
From: David Brownell @ 2008-06-30 4:10 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, fabrizio.garetto, linux-kernel, spi-devel-general
In-Reply-To: <fa686aa40806170028t2ccb679k22d2d3cea793ebc1@mail.gmail.com>
On Tuesday 17 June 2008, Grant Likely wrote:
> >>> This patch splits the allocation and registration portions of code out
> >>> of spi_new_device() and creates three new functions; spi_alloc_device(),
> >>> spi_register_device(), and spi_device_release().
> >>
> >> I have no problem with the first two, but why the last?
> >>
> >> If the devices are always allocated by spi_alloc_device() as
> >> they should be -- probably through an intermediary -- the
> >> only public function necessary for that cleanup should be
> >> the existing spi_dev_put().
> >
> > Ah, okay. I'm still a bit fuzzy on the device model conventions.
> > I'll remove that then.
>
> I've dug into this some more. spi_alloc_device only allocates the
> memory. It doesn't call device_initialize() to initialize the kref.
Well, the driver model idiom is initialize() then add(), with
register() calls combining the two. An alloc() is just a bit
outside those core idioms ...
But one alloc() example is platform_device_alloc(), which does
the device_initialize() call ... followed by platform_device_add().
The spi_new_device() call does a bunch of stuff beyond a register(),
but it also calls device_register().
> All of that behaviour is handled within device_register(). Therefore
> if a driver uses spi_alloc_device() and then if a later part of the
> initialization fails before spi_register_device() is called, then the
> alloc'd memory needs to be freed, but spi_dev_put() won't work because
> the kobj isn't set up so I need another function to handle freeing it
> in on a failure path.
I see ...
> Should I switch things around to do device_initialize() in the alloc
> function
Yes.
> and call device_add() instead of device_register() in the
> spi_register_device() function?
You should also rename it to spi_add_device(), since register()
calls always do the initialize() rather than having it done for
them in advance. People rely on those names supporting that
pattern (as they should).
> Is that sufficient to make put_device() work?
Looks like it to me. Calling device_initialize() will
do a kobject_init(), which is documented as requiring
a kobject_put() to clean up ... that's all put_device()
will ever do.
- Dave
^ permalink raw reply
* Re: [PATCH 2/4] spi: split up spi_new_device() to allow two stage registration.
From: David Brownell @ 2008-06-30 4:08 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, fabrizio.garetto, linux-kernel, spi-devel-general
In-Reply-To: <fa686aa40805232354g147acfcdx4753fce1a448ceb7@mail.gmail.com>
On Friday 23 May 2008, Grant Likely wrote:
> Question: spi_alloc_device() (and the original code) does a
> spi_master_get() on the spi_master device. Doesn't spi_master_put()
> need to be called when the device is discarded? spi_dev_put() doesn't
> do that explicitly; is it an implicit operation after a device has
> been deregistered from the spi_master?
Depends whether or not the add() has been done to hook things into
the driver model tree, as I recall. The add() presumes things are
properly refcounted. When you make a driver model tree node vanish,
its associated refcounts get updated too.
- Dave
^ permalink raw reply
* Re: [PATCH 4/6] MPC5121 Add MPC5121ADS cpld support
From: John Rigby @ 2008-06-30 4:01 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080629053646.GC13876@secretlab.ca>
On Sat, Jun 28, 2008 at 11:36 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> Minor comments below.
>
> On Fri, Jun 20, 2008 at 10:58:37AM -0600, John Rigby wrote:
>> Add a interrupt host for the interrupt
>> controller in the mpc5121ads cpld.
>> PCI interrupts are 0-7 the rest are 8-15
>> Touchscreen pendown irq is hardwired to irq1
>> All other irqs are chainged to irq0
>>
>> Signed-off-by: John Rigby <jrigby@freescale.com>
>> ---
>> arch/powerpc/platforms/512x/Kconfig | 1 +
>> arch/powerpc/platforms/512x/Makefile | 2 +-
>> arch/powerpc/platforms/512x/mpc5121_ads.c | 14 ++-
>> arch/powerpc/platforms/512x/mpc5121_ads.h | 14 ++
>> arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 204 ++++++++++++++++++++++++
>> 5 files changed, 233 insertions(+), 2 deletions(-)
>> create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads.h
>> create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
>>
>> diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
>> index f9a04da..0fd3b00 100644
>> --- a/arch/powerpc/platforms/512x/Kconfig
>> +++ b/arch/powerpc/platforms/512x/Kconfig
>> @@ -12,6 +12,7 @@ config MPC5121_ADS
>> depends on PPC_MULTIPLATFORM && PPC32
>> select DEFAULT_UIMAGE
>> select PPC_MPC5121
>> + select MPC5121_ADS_CPLD
>
> What is this for? I don't see it used anywhere.
Yes you are right, the Makefile just uses MPC5121_ADS to include the cpld code.
>
>> help
>> This option enables support for the MPC5121E ADS board.
>>
>> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c b/arch/powerpc/platforms/512x/mpc5121_ads.c
>> index 45bb2ef..36805fd 100644
>> --- a/arch/powerpc/platforms/512x/mpc5121_ads.c
>> +++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
>> + * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc. All rights reserved.
>> *
>> * Author: John Rigby, <jrigby@freescale.com>, Thur Mar 29 2007
>> *
>> @@ -23,6 +23,16 @@
>> #include <asm/time.h>
>>
>> #include "mpc512x.h"
>> +#include "mpc5121_ads.h"
>> +
>> +static void __init mpc5121_ads_setup_arch(void)
>> +{
>> + printk(KERN_INFO "MPC5121 ADS board from Freescale Semiconductor\n");
>> + /*
>> + * cpld regs are needed early
>> + */
>> + mpc5121_ads_cpld_map();
>> +}
>>
>> static struct of_device_id __initdata of_bus_ids[] = {
>> { .name = "soc", },
>> @@ -41,6 +51,7 @@ static void __init mpc5121_ads_declare_of_platform_devices(void)
>> static void __init mpc5121_ads_init_IRQ(void)
>> {
>> mpc512x_init_IRQ();
>> + mpc5121_ads_cpld_pic_init();
>
> Ah, I understand now. Ignore my related comment in the previous patch.
>
>> }
>>
>> /*
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: Stephen Neuendorffer @ 2008-06-30 3:39 UTC (permalink / raw)
To: John Williams, grant.likely
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, linuxppc-dev, will.newton, hpa,
John Linn, monstr, drepper, alan
In-Reply-To: <1d3f23370806291702g4344a2f9lb62f85cbb475fca4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3684 bytes --]
In my opionion, we should only include dts files for reference designs, and it must be documented how to get the design that the dts corresponds to.
MD5 hashing might be one way to prevent people from getting the dts file wrong, however without some way of checking it automatically, I don't think
anyone will have the patience to checksum the design they have (even worse, with whitespace changes, the md5 sum will change, so this is pretty fragile.
Having a device tree in the kernel for documentation *shouldn't* be necessary, since noone should ever write their dts by hand. (right?)
Hence, I'd prefer to not put the dts file in the kernel at all, and but to automatically generate the dts and store it in the blockram of the design.
This inextricably associates the dts with the design.
As for the copyright, I haven't been able to find much information on whether or not generated files are even copyrightable. One might argue that they
don't have sufficient 'creative value' to be copyrightable. Or arguably, they are as copyrightable by the generator author as by the author or the .mhs file.
I admit in this case, I've followed the safe route by claiming a copyright, which at least at Xilinx has significant precedent.
Steve
-----Original Message-----
From: John Williams [mailto:john.williams@petalogix.com]
Sent: Sun 6/29/2008 5:02 PM
To: grant.likely@secretlab.ca
Cc: monstr@seznam.cz; linux-kernel@vger.kernel.org; arnd@arndb.de; linux-arch@vger.kernel.org; Stephen Neuendorffer; John Linn; matthew@wil.cx; will.newton@gmail.com; drepper@redhat.com; microblaze-uclinux@itee.uq.edu.au; linuxppc-dev@ozlabs.org; vapier.adi@gmail.com; alan@lxorguk.ukuu.org.uk; hpa@zytor.com; Michal Simek
Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
On Sat, Jun 28, 2008 at 3:49 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
>> From: Michal Simek <monstr@monstr.eu>
>> arch/microblaze/platform/generic/system.dts | 300 +++++++++++++++++++++++++++
> Since this is a generated file, and entirely bitstream specific, does
> it make sense to include it in the kernel tree? If it does, then is
> it produced from one of the Xilinx reference designs? Can you add
> documentation to the header that specifies exactly which design
> version this .dts is for?
I think there's value in having a generic DTS as an example or
template, even if it doesn't correspond to any specific machine.
Agreed a comment block explaining this is valuable.
I'd almost oppose any attempt to include a standard DTS for things
like ML401 boards etc - they are just misleading. Unless we do MD5
hashes on MHS files, and use them as the filenames, any attempt to
define a standard platform will just fail and confuse people. Better
to show them how to generate the DTS for their system.
>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007-2008 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@monstr.eu>
>
> If this is a generated file, then is this copyright notice even appropriate?
I agree. I think Michal is just copying Xilinx's habit of putting
copyright headers in generated files, and it's one that we should stop
now.
Regards,
John
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 4531 bytes --]
^ permalink raw reply
* Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: John Williams @ 2008-06-30 3:59 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, linuxppc-dev, will.newton, hpa,
John Linn, monstr, drepper, alan
In-Reply-To: <20080630033943.332471860046@mail171-va3.bigfish.com>
Hi Steve,
> In my opionion, we should only include dts files for reference designs, and
> it must be documented how to get the design that the dts corresponds to.
I'm not sure you (or Xilinx) are quite ready for the pain this implies
- have you tried browsing reference designs on Xilinx.com recently?
It's a total mishmash of tool versions, boards, you name it. If
Xilinx is ready to declare a gold standard "ML401" design, and commit
to maintaining it tool version after tool version, lots of people will
be very happy, but I don't see it just yet!
I'm not having a go at you here, just questioning the notion that
there is really any such thing as a persistent 'reference design' for
these platforms. These are not physical boards that get manufactured
and persist as real objects.
> MD5 hashing might be one way to prevent people from getting the dts file
> wrong, however without some way of checking it automatically, I don't think
> anyone will have the patience to checksum the design they have (even worse,
> with whitespace changes, the md5 sum will change, so this is pretty fragile.
Actually I was only joking about the md5 hashing - just to prove my point :)
> Having a device tree in the kernel for documentation *shouldn't* be
> necessary,
Well, yes and no. A vanilla DTS that shows what a valid one might
look like - "oh, here's where I declare my main memory parameters,
..." has some value IMO.
> since noone should ever write their dts by hand. (right?)
I'm not certain you can guarantee that.
> Hence, I'd prefer to not put the dts file in the kernel at all, and but to
> automatically generate the dts and store it in the blockram of the design.
> This inextricably associates the dts with the design.
Whether the DTS lives in block ram or is pulled over the net by uboot
or whatever is not our call to make in the kernel - that's a
deployment issue.
> As for the copyright, I haven't been able to find much information on
> whether or not generated files are even copyrightable. One might argue that
> they
> don't have sufficient 'creative value' to be copyrightable. Or arguably,
> they are as copyrightable by the generator author as by the author or the
> .mhs file.
The DTS is a mechanical translation from one file format to another
(more or less). Auto-inserting a copyright Xilinx (or anyone else) in
there would be unenforceable, and therefore should probably just go
away.
How would you feel if the FSF claimed copyright over object code
derived from your source files simply because you ran them through
gcc? :) I believe there's a special clause in the GCC license to
explicitly cover this kind of situation.
Cheers,
John
^ permalink raw reply
* Re: [PATCH 5/6] MPC5121 Add PCI support
From: John Rigby @ 2008-06-30 3:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080629053844.GD13876@secretlab.ca>
Yes, Kumar made the same comment. The newer patch that moves the 83xx
add bridge routine to fsl_soc obsoletes this patch.
On Sat, Jun 28, 2008 at 11:38 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Fri, Jun 20, 2008 at 10:58:38AM -0600, John Rigby wrote:
>> Copied from 83xx minus support for two busses.
>
> If this is a copy, then can it be shared?
>
> g.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Please pull from 'powerpc-next' branch
From: Michael Ellerman @ 2008-06-30 3:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <24590FB3-5A41-4CCC-964F-BE861ABA7FC0@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]
On Fri, 2008-06-27 at 08:00 -0500, Kumar Gala wrote:
> On Jun 27, 2008, at 6:27 AM, Paul Mackerras wrote:
>
> > Kumar Gala writes:
> >
> >> Paul, any update on when we might see some of the various patches
> >> pulled into powerpc-next?
> >> I've got some work I'd like to see in .27 but it needs Michael's code
> >> patching patches.
> >
> > I thought you had some concerns about patches 5/14 and 12/14 of his
> > series?
>
> 5/14 needs some better comments but nothing that should hold up the
> acceptance and 12/14 or should be merged with 11/14 if he reposts the
> patch set. But again, nothing to hold things up.
I guess it would be easier for you Kumar if I do a fixup patch to add
comments, rather than rebasing and you having to rebase as well?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
From: Stephen Neuendorffer @ 2008-06-30 3:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, git, dwg
In-Reply-To: <fa686aa40806281333i5ae1833fg561622640b5d3a4e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
Is there really much of a chance of that, given the differences with the bootwrappers?
Does anyone care enough about legacy_serial for this to matter? My impression was that legacy serial was not preferred anyway...
Steve
-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Sat 6/28/2008 1:33 PM
To: Stephen Neuendorffer
Cc: dwg@au1.ibm.com; jwboyer@linux.vnet.ibm.com; linuxppc-dev@ozlabs.org; git
Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
On Fri, Jun 6, 2008 at 10:16 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> legacy_serial identifies a valid ns16550 on a simple-bus, but the
> legacy_serial driver doesn't understand the shift and offset flags
> necessary to get it to work, which results in no console.
>
> I think the easiest solution is to change the Kconfig so that
> PPC_UDBG_16550 is only selected based on !XILINX_VIRTEX. I've done this
> in my tree, but I've been swamped with other things at the moment, so I
> haven't verified it.
This is an easy solution, but it is not a good one. Doing so would
break UDBG on other 405 boards when building multiplatform kernels.
It would be better to teach legacy serial about the shift and offset.
Alternately, add code to add_legacy_soc_port() to skip it if the
shift/offset properties are present.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 2473 bytes --]
^ permalink raw reply
* Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
From: David Brownell @ 2008-06-30 2:51 UTC (permalink / raw)
To: Jean Delvare; +Cc: Wolfram Sang, linuxppc-dev list, Timur Tabi, Linux I2C
In-Reply-To: <20080629091725.291974e9@hyperion.delvare>
On Sunday 29 June 2008, Jean Delvare wrote:
>
> > After the i2c adapter registers itself, of_register_i2c_devices() is called
> > which walks through the child nodes of the i2c adapter node in the device
> > tree. Each child node is an i2c device, and it immediately get
> > registered with the adapter. Because this ensures that i2c device
> > registration always happens after adapter registration, and since the
> > pointer to the i2c_adapter is known, then i2c_new_device() can be used
> > directly without ever needing to know the bus number.
>
> Ah, OK. If you use i2c_new_device() then it's alright.
Right. Conceptually the way that the i2c core uses "numbered"
adapters and registered board_info could be viewed as a way to
let platforms avoid tracking that stuff themselves. Since
the of_* framework is already tracking that, there's no big win
in trying to have i2c-core track that too, on its behalf.
- Dave
^ permalink raw reply
* Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
From: John Williams @ 2008-06-30 0:02 UTC (permalink / raw)
To: Grant Likely
Cc: linux-arch, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, monstr, John.Linn, alan
In-Reply-To: <fa686aa40806272249l7eae0c34k43a20ad41672b77a@mail.gmail.com>
On Sat, Jun 28, 2008 at 3:49 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Jun 26, 2008 at 5:29 AM, <monstr@seznam.cz> wrote:
>> From: Michal Simek <monstr@monstr.eu>
>> arch/microblaze/platform/generic/system.dts | 300 +++++++++++++++++++++++++++
> Since this is a generated file, and entirely bitstream specific, does
> it make sense to include it in the kernel tree? If it does, then is
> it produced from one of the Xilinx reference designs? Can you add
> documentation to the header that specifies exactly which design
> version this .dts is for?
I think there's value in having a generic DTS as an example or
template, even if it doesn't correspond to any specific machine.
Agreed a comment block explaining this is valuable.
I'd almost oppose any attempt to include a standard DTS for things
like ML401 boards etc - they are just misleading. Unless we do MD5
hashes on MHS files, and use them as the filenames, any attempt to
define a standard platform will just fail and confuse people. Better
to show them how to generate the DTS for their system.
>> +/*
>> + * (C) Copyright 2007-2008 Xilinx, Inc.
>> + * (C) Copyright 2007-2008 Michal Simek
>> + *
>> + * Michal SIMEK <monstr@monstr.eu>
>
> If this is a generated file, then is this copyright notice even appropriate?
I agree. I think Michal is just copying Xilinx's habit of putting
copyright headers in generated files, and it's one that we should stop
now.
Regards,
John
^ permalink raw reply
* RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets
From: Stephen Neuendorffer @ 2008-06-29 21:30 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Scott Wood, paulus, John Linn, petermendham
In-Reply-To: <fa686aa40806272122g3f4148d3ua1e59df54709cc68@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]
simpleImage should also create an .elf (for xmd or systemAce loading)
If dtbImage and simpleImage could be merged, I'd be all for it...
At some point of course, I need to figure merge the Device Tree in BRAM code that I've been using, which would be a simpleImage which wouldn't need a device tree. However, I don't see this happening before August.
Steve
-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Fri 6/27/2008 9:22 PM
To: Stephen Neuendorffer
Cc: Josh Boyer; John Linn; linuxppc-dev@ozlabs.com; paulus@samba.org; petermendham@computing.dundee.ac.uk; Scott Wood; Geoff Levand
Subject: Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets
On Thu, Jun 26, 2008 at 1:16 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Forgive my ignorance here, but what specifically does this imply? As
> far as I can tell, generally speaking, some of the board-specific
> information is passed into the boot wrapper, which then stuffs it into
> the device tree.
Yes, you are correct. I'll fill out the documentation more here.
>> uImage is for device-tree aware U-Boot versions
>
> And this differs from above because it gets a device tree passed in,
> which uboot has already stuffed correctly.
Correct.
>> dtbImage is used for boards that can take an ELF zImage, but still
> need
>> a dtb provided.
>>
>> simpleImage, not sure here.
>
> So both of these are elfs... but how do they differ? Is it only in how
> the right head.s file gets picked up?
simpleImage is not an elf. Its a raw position-independent binary
which can be loaded anywhere in RAM.
Some dtbImages are elfs; but there are a flat binaries. The main
difference is that all simpleImages assume that firmware provides
nothing interesting; but the flat dtbImages have custom code for
extracting a little bit of data out of the boards firmware.
It's all a bit of a confusing mess. It might be a good idea to rework
all the image names to stuff not so non-obvious, but I'm not sure the
best way to go about it. There is a lot of historical stuff in there
where the various 'zImage.*' targets grew and morphed over time in
ways that are hard to follow. It may make more sense to change the
flat-binary dtbImages to be simpleImages instead with overrides for
specific boards (just like is done for virtex405-*). ps3 is the other
major user of dtbImage. I created the whole dtbImage stuff in the
first place to eliminate overloaded makefile targets where some
zImage% target were providing a device tree and other zImage% targets
were not. Splitting dtb-provided from dtb-not-provided targets
clarified the Makefile quite a bit. dtbImage is not a fantastic name,
but I needed something different from zImage for images with an
embedded device tree.
Looking at the Makefile, dtbImage and simpleImage targets are
virtually identical. Perhaps it would be best to merge the targets
and deal with all the differences in the wrapper script (with the
default to just use simpleboot.S as the init code). Thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 4469 bytes --]
^ permalink raw reply
* Re: [PATCH] Convert i2c-mpc from a platform driver into a of_platform driver, V2
From: Jochen Friedrich @ 2008-06-29 21:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linuxppc-dev, i2c
In-Reply-To: <20080629164443.4381.71902.stgit@terra>
Hi Jon,
> This version adds of_find_i2c_device_by_node() which is needed by ASOC drivers.
Cool. I was about to do something similar (of_get_adapter_nr_by_node).
IMHO, the patch should be splitted into the addition of of_find_i2c_device_by_node()
and the actual patch of i2c-mpc.
Thanks,
Jochen
^ permalink raw reply
* Re: [RFC] Non-numbered ibm iic driver
From: Jon Loeliger @ 2008-06-29 18:52 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080628232010.2bff2dcc@lappy.seanm.ca>
Sean MacLennan wrote:
> P.S. Do I need a signed-off-by for an RFC?
>
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> ---
Not usually. Some intentionally leave the S-o-b: off of
and RFC specifically to ensure that it stays RFC-ish and
doesn't slip into patchness.
jdl
^ permalink raw reply
* [PATCH] Convert i2c-mpc from a platform driver into a of_platform driver, V2
From: Jon Smirl @ 2008-06-29 16:44 UTC (permalink / raw)
To: i2c, Linuxppc-dev
This version adds of_find_i2c_device_by_node() which is needed by ASOC drivers. To make it work I had to make the i2c bus struct visible. It also picks up a couple of other minor fixes that have been posted to the lists.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
arch/powerpc/sysdev/fsl_soc.c | 122 -----------------------------------------
drivers/i2c/busses/i2c-mpc.c | 104 ++++++++++++++++++++---------------
drivers/i2c/i2c-core.c | 2 -
drivers/of/of_i2c.c | 37 +++++++++---
include/linux/i2c.h | 3 +
include/linux/of_i2c.h | 2 +
6 files changed, 92 insertions(+), 178 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 019657c..ebcec73 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -414,128 +414,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include <linux/i2c.h>
-struct i2c_driver_device {
- char *of_device;
- char *i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {"ricoh,rs5c372a", "rs5c372a"},
- {"ricoh,rs5c372b", "rs5c372b"},
- {"ricoh,rv5c386", "rv5c386"},
- {"ricoh,rv5c387a", "rv5c387a"},
- {"dallas,ds1307", "ds1307"},
- {"dallas,ds1337", "ds1337"},
- {"dallas,ds1338", "ds1338"},
- {"dallas,ds1339", "ds1339"},
- {"dallas,ds1340", "ds1340"},
- {"stm,m41t00", "m41t00"},
- {"dallas,ds1374", "ds1374"},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
- struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info->type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) >= I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_WARNING "fsl_soc.c: invalid i2c device entry\n");
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, &info) < 0)
- continue;
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, &info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i = 0;
- struct platform_device *i2c_dev;
- int ret;
-
- for_each_compatible_node(np, NULL, "fsl-i2c") {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(&r, 0, sizeof(r));
- memset(&i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, &r[1]);
-
- i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, "dfsrr", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, "fsl5200-clocking", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, &i2c_data,
- sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i++);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index a076129..36bea49 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,8 @@
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/init.h>
-#include <linux/platform_device.h>
+#include <linux/of_platform.h>
+#include <linux/of_i2c.h>
#include <asm/io.h>
#include <linux/fsl_devices.h>
@@ -25,13 +26,13 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME "mpc-i2c"
+
#define MPC_I2C_FDR 0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -315,102 +316,117 @@ static struct i2c_adapter mpc_ops = {
.timeout = 1,
};
-static int fsl_i2c_probe(struct platform_device *pdev)
+static int __devinit fsl_i2c_probe(struct of_device *op, const struct of_device_id *match)
{
int result = 0;
struct mpc_i2c *i2c;
- struct fsl_i2c_platform_data *pdata;
- struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
if (!i2c)
return -ENOMEM;
- i2c->irq = platform_get_irq(pdev, 0);
- if (i2c->irq < 0)
- i2c->irq = NO_IRQ; /* Use polling */
+ if (of_get_property(op->node, "dfsrr", NULL))
+ i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
- i2c->flags = pdata->device_flags;
- init_waitqueue_head(&i2c->queue);
+ if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
+ of_device_is_compatible(op->node, "mpc5200-i2c"))
+ i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
- i2c->base = ioremap((phys_addr_t)r->start, MPC_I2C_REGION);
+ init_waitqueue_head(&i2c->queue);
+ i2c->base = of_iomap(op->node, 0);
if (!i2c->base) {
printk(KERN_ERR "i2c-mpc - failed to map controller\n");
result = -ENOMEM;
goto fail_map;
}
- if (i2c->irq != NO_IRQ)
- if ((result = request_irq(i2c->irq, mpc_i2c_isr,
- IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
- printk(KERN_ERR
- "i2c-mpc - failed to attach interrupt\n");
- goto fail_irq;
+ i2c->irq = irq_of_parse_and_map(op->node, 0);
+ if (i2c->irq != NO_IRQ) { /* i2c->irq = NO_IRQ implies polling */
+ result = request_irq(i2c->irq, mpc_i2c_isr,
+ IRQF_SHARED, "i2c-mpc", i2c);
+ if (result < 0) {
+ printk(KERN_ERR "i2c-mpc - failed to attach interrupt\n");
+ goto fail_request;
}
-
+ }
+
mpc_i2c_setclock(i2c);
- platform_set_drvdata(pdev, i2c);
+
+ dev_set_drvdata(&op->dev, i2c);
i2c->adap = mpc_ops;
- i2c->adap.nr = pdev->id;
i2c_set_adapdata(&i2c->adap, i2c);
- i2c->adap.dev.parent = &pdev->dev;
- if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
+ i2c->adap.dev.parent = &op->dev;
+
+ result = i2c_add_adapter(&i2c->adap);
+ if (result < 0) {
printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
goto fail_add;
}
+ of_register_i2c_devices(&i2c->adap, op->node);
return result;
- fail_add:
- if (i2c->irq != NO_IRQ)
- free_irq(i2c->irq, i2c);
- fail_irq:
- iounmap(i2c->base);
- fail_map:
+ fail_add:
+ dev_set_drvdata(&op->dev, NULL);
+ free_irq(i2c->irq, i2c);
+ fail_request:
+ irq_dispose_mapping(i2c->irq);
+ iounmap(i2c->base);
+ fail_map:
kfree(i2c);
return result;
};
-static int fsl_i2c_remove(struct platform_device *pdev)
+static int __devexit fsl_i2c_remove(struct of_device *op)
{
- struct mpc_i2c *i2c = platform_get_drvdata(pdev);
+ struct mpc_i2c *i2c = dev_get_drvdata(&op->dev);
i2c_del_adapter(&i2c->adap);
- platform_set_drvdata(pdev, NULL);
+ dev_set_drvdata(&op->dev, NULL);
if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
+ irq_dispose_mapping(i2c->irq);
iounmap(i2c->base);
kfree(i2c);
return 0;
};
-/* work with hotplug and coldplug */
-MODULE_ALIAS("platform:fsl-i2c");
+static const struct of_device_id mpc_i2c_of_match[] = {
+ {.compatible = "fsl-i2c",},
+ {},
+};
+MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
+
/* Structure for a device driver */
-static struct platform_driver fsl_i2c_driver = {
- .probe = fsl_i2c_probe,
- .remove = fsl_i2c_remove,
- .driver = {
- .owner = THIS_MODULE,
- .name = "fsl-i2c",
+static struct of_platform_driver mpc_i2c_driver = {
+ .match_table = mpc_i2c_of_match,
+ .probe = fsl_i2c_probe,
+ .remove = __devexit_p(fsl_i2c_remove),
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
},
};
static int __init fsl_i2c_init(void)
{
- return platform_driver_register(&fsl_i2c_driver);
+ int rv;
+
+ rv = of_register_platform_driver(&mpc_i2c_driver);
+ if (rv)
+ printk(KERN_ERR DRV_NAME
+ " of_register_platform_driver failed (%i)\n", rv);
+ return rv;
}
static void __exit fsl_i2c_exit(void)
{
- platform_driver_unregister(&fsl_i2c_driver);
+ of_unregister_platform_driver(&mpc_i2c_driver);
}
module_init(fsl_i2c_init);
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d0175f4..e3abe1b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = {
{ },
};
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = "i2c",
.dev_attrs = i2c_dev_attrs,
.match = i2c_device_match,
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..67cbdc7 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -74,7 +74,7 @@ static int of_find_i2c_driver(struct device_node *node,
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node)
{
- void *result;
+ struct i2c_client *i2c_dev;
struct device_node *node;
for_each_child_of_node(adap_node, node) {
@@ -89,29 +89,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
continue;
}
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, &info) < 0) {
- irq_dispose_mapping(info.irq);
+ if (of_find_i2c_driver(node, &info) < 0)
continue;
- }
+ info.irq = irq_of_parse_and_map(node, 0);
info.addr = *addr;
- request_module(info.type);
+ request_module("%s", info.type);
- result = i2c_new_device(adap, &info);
- if (result == NULL) {
+ i2c_dev = i2c_new_device(adap, &info);
+ if (i2c_dev == NULL) {
printk(KERN_ERR
"of-i2c: Failed to load driver for %s\n",
info.type);
irq_dispose_mapping(info.irq);
continue;
}
+
+ i2c_dev->dev.archdata.of_node = of_node_get(node);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev->archdata.of_node == data;
+}
+
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
+{
+ struct device *dev;
+
+ dev = bus_find_device(&i2c_bus_type, NULL, node,
+ of_dev_node_match);
+ if (!dev)
+ return NULL;
+
+ return to_i2c_client(dev);
+}
+EXPORT_SYMBOL(of_find_i2c_device_by_node);
+
MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fb9af6a..186b22d 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -92,6 +92,9 @@ extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
u8 command, u8 length,
const u8 *values);
+
+/* Base of the i2c bus */
+extern struct bus_type i2c_bus_type;
/*
* A driver is capable of handling one or more physical devices present on
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index bd2a870..17d5897 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -16,5 +16,7 @@
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node);
+struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+
#endif /* __LINUX_OF_I2C_H */
^ permalink raw reply related
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