* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-04 15:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-mtd, Milton Miller
In-Reply-To: <f24cbe6245fb2a52d153edb9be678f5a@kernel.crashing.org>
Segher Boessenkool wrote:
>>> You make no sense to me. It's like saying that knowing that a 8250 chip
>>> on ISA cannot be accessed if you don't know it's IO ports so it
>>> shouldn't say "8250" in compatible property ?!?!?!?
>> No, it's a completely different case. Base address and even flash
>> size are not the only things that matter. There's bus width
> Bus width is an (inherent) property of the _parent_
> node. Device width is normally equal to that, and
> if not, it is obvious from the device model.
Eh... obvious? From the bus controller node? Maybe and maybe not. Those
are seem to be generally multifuntional and so don't have their "chip selects"
fixed to some kind of interface, i.e. it's selectable, as well as the bus
width even... at least it's so in my case (and nevertheless, the board has
interleaved flash, so it's not a matter of a bus width fixed to 32 bits as you
can see).
> Also, you need to know if the devices are byte-addressable
> or only per natural unit; and even more importantly,
> the same question for the flash bus.
>> and interleave factors
> Not a property of the flash chips really.
Who said it is?
>> that influence the access (and possibly, byte-swapping too, although
>> this is unlikely to happen in PPC world).
> Byte swapping? 1) This should _never_ be necessary,
> just swap the data on the device itself, duh;
Oh, I'm afraid that's only wishful thinking after having some real life
experience in bi-endian world. Luckily, the PPC world seems to be (at least
mostly) big-endian.
> 2) more likely this would be determined by the flash bus, not
> per flash device.
Indeed, by wiring the bus pins to flash pins. :-)
> And, 3) why would you want to include this in the flash
> binding while we don't yet have a reasonable overview
> of in what circumstances byte swap is needed/used?
This was just a real world example. I do hope PPC would never have to deal
with it, though...
>>> Also, whatever shortcomings of the linux MTD drivers are totally
>>> irrelevant to what is correct to have in a device-tree. While we do
>>> tailor our device-tree specification around linux needs in most cases,
>>> there are cases like this one where common sense should be enough to
>>> understand that it's not because the linux MTD subsystem, as of today,
>>> cannot be told what programming interface to use, that we shouldn't
>>> provide that information in the tree.
>> We did provide it, in the form of probing hints ("probe-type" prop).
> Which is 103% redundant. That same information (and
> more!) is required in the "compatible" property, already.
Yeah, but then we would have needed more than one node -- which I avoided
back then... well, I have cheated and mistaken. :-)
Anyway, the "rom" device node as it appeared in booting-without-of.txt
was based upon suggestions from Linux/MTD maintainer.
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Arnd Bergmann @ 2007-06-04 17:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <90f8b99fa6a8e4b8898d64630d96036f68668b03.1180961962.git.michael@ellerman.id.au>
On Monday 04 June 2007, Michael Ellerman wrote:
> This patch adds support for the setup and decoding of MSIs
> on Axon-based Cell systems.
Looks pretty good, just two details I noticed:
> +/* Flags */
> +#define MSIC_ENABLE 0x0001 /* Bit 31 */
> +#define MSIC_FIFO_FULL_ENABLE 0x0002 /* Bit 30 */
> +#define MSIC_IRQ_ENABLE 0x0008 /* Bit 28 */
> +#define MSIC_FULL_STOP_ENABLE 0x0010 /* Bit 27 */
The comments behind each definition look rather bogus, as much as
we all love to have documentation normally.
If you have the specification for the hardware, the bit numbers
are in there, for everyone else, the IBM numbering scheme can
only confuse the reader...
> +#define MSIC_DCR_BASE MSIC_CTRL_REG_ADDR
> +#define MSIC_DCR_SIZE (MSIC_WRITE_OFFSET_REG - MSIC_CTRL_REG_ADDR)
shouldn't that come from the device tree?
Arnd <><
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Arnd Bergmann @ 2007-06-04 17:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <90f8b99fa6a8e4b8898d64630d96036f68668b03.1180961962.git.michael@ellerman.id.au>
T24gTW9uZGF5IDA0IEp1bmUgMjAwNywgTWljaGFlbCBFbGxlcm1hbiB3cm90ZToKPiAroKCgoKCg
oGZvcl9lYWNoX2NvbXBhdGlibGVfbm9kZShub2RlLCBOVUxMLCAiaWJtLGF4b24tbXNpYyIpIHsK
PiAroKCgoKCgoKCgoKCgoKCgaWYgKGF4b25fbXNpX3NldHVwX29uZShvZl9ub2RlX2dldChub2Rl
KSkgPT0gMCkKPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBmb3VuZCsrOwo+ICugoKCgoKCgfQo+
ICugoKCgoKCgb2Zfbm9kZV9wdXQobm9kZSk7CgpPbmUgbW9yZSB0aGluZzogQUZBSUNTICdub2Rl
JyBpcyBndWFyYW50ZWVkIHRvIGJlIE5VTEwgd2hlbiB5b3UgZ2V0Cm91dCBvZiB0aGUgZm9yX2Vh
Y2hfY29tcGF0aWJsZV9ub2RlIGxvb3AsIHNvIHlvdSBkb24ndCBuZWVkIHRoZQpvZl9ub2RlX3B1
dCgpLgoKCUFybmQgPD48Cg==
^ permalink raw reply
* [patch 0/3] cell bug fixes for 2.6.22
From: Arnd Bergmann @ 2007-06-04 18:14 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, cbe-oss-dev
These are some small fixes that I'd still like to get into 2.6.22.
The first one still needs an Acked-by: benh, the other two have
been reviewed on the list already.
Arnd <><
--
^ permalink raw reply
* [patch 1/3] powerpc: fix pci_setup_phb_io_dynamic for pci_iomap
From: Arnd Bergmann @ 2007-06-04 18:14 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <20070604181438.569356702@arndb.de>
From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
We had a problem on a system with only dynamically allocated
PCI buses (using of_pci_phb_driver) in combination with libata.
This setup ended up having no "primary" phb, which means
that pci_io_base never got initialized and all IO port
numbers are 64 bit numbers, which is larger than the
PIO_MASK limit.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-2.6/arch/powerpc/kernel/of_platform.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/of_platform.c
+++ linux-2.6/arch/powerpc/kernel/of_platform.c
@@ -433,7 +433,7 @@ static int __devinit of_pci_phb_probe(st
* Note also that we don't do ISA, this will also be fixed with a
* more massive rework.
*/
- pci_setup_phb_io(phb, 0);
+ pci_setup_phb_io(phb, pci_io_base == 0);
/* Init pci_dn data structures */
pci_devs_phb_init_dynamic(phb);
--
^ permalink raw reply
* [patch 2/3] cbe_cpufreq: limit frequency via cpufreq notifier chain
From: Arnd Bergmann @ 2007-06-04 18:14 UTC (permalink / raw)
To: paulus
Cc: Arnd Bergmann, linuxppc-dev, Christian Krafft, cbe-oss-dev,
Thomas Renninger
In-Reply-To: <20070604181438.569356702@arndb.de>
From: Thomas Renninger <trenn@suse.de>
and get rid of cpufreq_set_policy call that caused a build
failure due interfering commits
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
---
arch/powerpc/platforms/cell/cbe_cpufreq.c | 28 ++++++++++++++++++++++------
1 file changed, 22 insertions(+), 6 deletions(-)
Index: linux-2.6/arch/powerpc/platforms/cell/cbe_cpufreq.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ linux-2.6/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -67,6 +67,7 @@ static u64 MIC_Slow_Next_Timer_table[] =
0x00003FC000000000ull,
};
+static unsigned int pmi_frequency_limit = 0;
/*
* hardware specific functions
*/
@@ -164,7 +165,6 @@ static int set_pmode(int cpu, unsigned i
static void cbe_cpufreq_handle_pmi(struct of_device *dev, pmi_message_t pmi_msg)
{
- struct cpufreq_policy policy;
u8 cpu;
u8 cbe_pmode_new;
@@ -173,15 +173,27 @@ static void cbe_cpufreq_handle_pmi(struc
cpu = cbe_node_to_cpu(pmi_msg.data1);
cbe_pmode_new = pmi_msg.data2;
- cpufreq_get_policy(&policy, cpu);
+ pmi_frequency_limit = cbe_freqs[cbe_pmode_new].frequency;
- policy.max = min(policy.max, cbe_freqs[cbe_pmode_new].frequency);
- policy.min = min(policy.min, policy.max);
+ pr_debug("cbe_handle_pmi: max freq=%d\n", pmi_frequency_limit);
+}
+
+static int pmi_notifier(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct cpufreq_policy *policy = data;
- pr_debug("cbe_handle_pmi: new policy.min=%d policy.max=%d\n", policy.min, policy.max);
- cpufreq_set_policy(&policy);
+ if (event != CPUFREQ_INCOMPATIBLE)
+ return 0;
+
+ cpufreq_verify_within_limits(policy, 0, pmi_frequency_limit);
+ return 0;
}
+static struct notifier_block pmi_notifier_block = {
+ .notifier_call = pmi_notifier,
+};
+
static struct pmi_handler cbe_pmi_handler = {
.type = PMI_TYPE_FREQ_CHANGE,
.handle_pmi_message = cbe_cpufreq_handle_pmi,
@@ -238,12 +250,21 @@ static int cbe_cpufreq_cpu_init(struct c
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
+ if (pmi_dev) {
+ /* frequency might get limited later, initialize limit with max_freq */
+ pmi_frequency_limit = max_freq;
+ cpufreq_register_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
+ }
+
/* this ensures that policy->cpuinfo_min and policy->cpuinfo_max are set correctly */
return cpufreq_frequency_table_cpuinfo(policy, cbe_freqs);
}
static int cbe_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
+ if (pmi_dev)
+ cpufreq_unregister_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
+
cpufreq_frequency_table_put_attr(policy->cpu);
return 0;
}
--
^ permalink raw reply
* [patch 3/3] scc_sio: fix link failure
From: Arnd Bergmann @ 2007-06-04 18:14 UTC (permalink / raw)
To: paulus; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, Christoph Hellwig
In-Reply-To: <20070604181438.569356702@arndb.de>
From: Christoph Hellwig <hch@lst.de>
scc_sio.o should only be built if the txx9 serial driver is actually built
into the kernel.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/celleb/Makefile
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/celleb/Makefile
+++ linux-2.6/arch/powerpc/platforms/celleb/Makefile
@@ -4,5 +4,5 @@ obj-y += interrupt.o iommu.o setup.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PPC_UDBG_BEAT) += udbg_beat.o
-obj-$(CONFIG_HAS_TXX9_SERIAL) += scc_sio.o
+obj-$(CONFIG_SERIAL_TXX9) += scc_sio.o
obj-$(CONFIG_SPU_BASE) += spu_priv1.o
--
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-06-04 18:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180828253.14025.22.camel@localhost.localdomain>
On Sat, 2007-06-02 at 18:50, Benjamin Herrenschmidt wrote:
> Minor nits (in addition to needing a "reg" property)
>
> > +
> > + i8259: i8259@4d0 {
>
> Name should probably be "interrupt-controller" as well to follow the
> recommended naming practice.
>
> > + clock-frequency = <0>;
> > + interrupt-controller;
> > + device_type = "interrupt-controller";
> > + #address-cells = <0>;
> > + #interrupt-cells = <2>;
> > + built-in;
> > + compatible = "chrp,iic";
> > + big-endian;
>
> big-endian ? On a 8259 ?
>
> > + interrupts = <49 2>;
> > + interrupt-parent =
> > + <&mpic>;
> > + };
> > + };
> > + };
> > };
> >
> > };
>
Since the interrupt controller issues are a bit unrelated
to the PCI-Express enablement patches here, I'll submit a
follow-up patch set to clean them up.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-06-04 18:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4fb92a9dfccf515bdc1522d08f10f823@kernel.crashing.org>
On Sat, 2007-06-02 at 03:22, Segher Boessenkool wrote:
> >> "reg" included in "ranges"? Something is wrong here.
> >
> > I think it's correct for soc nodes.
>
> It is not. "ranges" is the address space translation
> between the parent and child busses; "reg" is the stuff
> that's on the bridge device itself.
>
> > At least, it appears that all of
> > the dts files with soc nodes do similar things (including this one even
> > without this patch).
>
> Yes, but that doesn't make it right.
But removing it does break things. I'm going to leave
it as-is for now, and we can wrestle over "fixing" it
in a follow up patch.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 6/8] Let subordinate transparent bridges be transparent.
From: Jon Loeliger @ 2007-06-04 18:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180740416.19517.476.camel@localhost.localdomain>
On Fri, 2007-06-01 at 18:26, Benjamin Herrenschmidt wrote:
> NAK. The mem case needs a similar fix. I think we should instead do
>
> - if (!res->flags)
> - continue;
> + if (!res->flags || bus->self->transparent)
> + continue;
Right. Fixed as indicated.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Jon Loeliger @ 2007-06-04 19:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras, Wei Zhang
In-Reply-To: <1180740531.19517.480.camel@localhost.localdomain>
On Fri, 2007-06-01 at 18:28, Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-01 at 14:58 -0500, Kumar Gala wrote:
> >
> > So looking at the code it looks like pci_assign_all_buses should
> > handle numbering the busses properly when we scan the busses, so
> > what's the issue that causes that not to be correct?
>
> Yeah, that's what powermac uses... Any reason it wouldn't work ?
>
> Ben.
Empirical testing says it doesn't work.
jdl
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Andy Fleming @ 2007-06-04 19:25 UTC (permalink / raw)
To: Marc Leeman; +Cc: linuxppc-dev
In-Reply-To: <20070604095625.GF17456@chiana.homelinux.org>
On Jun 4, 2007, at 04:56, Marc Leeman wrote:
>
> I am moving my boards from arch/ppc/ to arch/powerpc/ and am trying to
> use the MPC83xx_IRQ_EXT? pins.
>
> The device (hardcoded to use 23 as with the arch/ppc/ config, EXT7)
> does not signal the ints to the CPU.
>
> The only reference I find to this usage in arch/powerpc/ is in
> arch/powerpc/platforms/83xx/mpc834x_itx.h, which is most likely
> something left over while moving from arch/ppc/
>
> Probably, I need to enable them in the dts tree (?) but since it's
> a PCI
> device that uses a GPIO pin for signalling interrupts, I'm trying to
> find out where and how to configure this.
Wow. Hardware designers sure like to make things easy, don't they?
I'm assuming it's a PCI device on the board (and not in a slot).
I believe you're ok if you explicitly define the node, and point it
at the IPIC for its interrupt. Something like this:
pci1: pci@8000 {
...
my_pci_device@0 {
...
interrupts = <irq#, sense>;
interrupt-parent = <&ipic>;
}
}
^ permalink raw reply
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-04 19:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1180983026.9632.22.camel@ld0161-tx32>
>>>> "reg" included in "ranges"? Something is wrong here.
>>>
>>> I think it's correct for soc nodes.
>>
>> It is not. "ranges" is the address space translation
>> between the parent and child busses; "reg" is the stuff
>> that's on the bridge device itself.
>>
>>> At least, it appears that all of
>>> the dts files with soc nodes do similar things (including this one
>>> even
>>> without this patch).
>>
>> Yes, but that doesn't make it right.
>
> But removing it does break things.
What breaks? This sounds like a Linux bug, in
your port perhaps, or in some OF parsing code.
> I'm going to leave
> it as-is for now, and we can wrestle over "fixing" it
> in a follow up patch.
Fine with me -- please figure out what exactly it
is that is breaking though.
Thanks,
Segher
^ permalink raw reply
* Re: [PATCH 8/8] Wrote quirk_mpc8641_transparent() to initialize bridge resources.
From: Jon Loeliger @ 2007-06-04 19:32 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <bfe9571d7d435aa6f52ae8d9ec61a1d5@bga.com>
On Mon, 2007-06-04 at 00:55, Milton Miller wrote:
> This is totally unreadable. include/linux/pci_ids.h exists for a
> reason,
> please use it. At least the vendor should be in there.
>
> If you want to define the device id with the same naming convention
> but in the local source file, I won't object.
> Please use the (new) helper of_read_number in prom.h.
> milton
>
> PS: how about create instead of wrote in the subject?
All yup.
Thanks,
jdl
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Segher Boessenkool @ 2007-06-04 19:35 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <4E25DA41-741E-40AC-9186-936FEEFE6B29@freescale.com>
>> Probably, I need to enable them in the dts tree (?) but since it's
>> a PCI
>> device that uses a GPIO pin for signalling interrupts, I'm trying to
>> find out where and how to configure this.
>
> Wow. Hardware designers sure like to make things easy, don't they?
>
> I'm assuming it's a PCI device on the board (and not in a slot).
>
> I believe you're ok if you explicitly define the node, and point it
> at the IPIC for its interrupt.
That's the simplest way to do it, yes (and sometimes
the only way). I believe for Linux you can get away
with not defining any of the standard PCI properties
in that new PCI node (well you need "reg" and very very
basic stuff like that, of course).
> Something like this:
>
> pci1: pci@8000 {
> ...
> my_pci_device@0 {
> ...
> interrupts = <irq#, sense>;
> interrupt-parent = <&ipic>;
> }
> }
Exactly. Please remember that "interrupts" here
is in the ipic domain and not in the PCI domain,
so get the # interrupt cells and the sense value
from the ipic.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Mark A. Greer @ 2007-06-04 19:40 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <7fc919fce0761f861be3069a853d3169@bga.com>
On Fri, Jun 01, 2007 at 11:30:32PM -0500, Milton Miller wrote:
> On Sat Jun 2 09:20:22 EST 2007, Mark A. Greer wrote:
>
> >Find the "rom" device for the prpmc2800 and create a device for it.
> >The device will be picked up by the code in
> >drivers/mtd/maps/physmap_of.c
> >and will setup MTD on that FLASH device.
> ...
> > /*
> >+ * Register a platform device for MTD.
> >+ */
> >+static int __init prpmc2800_register_mtd(void)
> >+{
> >+ struct device_node *np;
> >+
> >+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
> >+ of_platform_device_create(np, np->name, NULL);
> >+}
> >+arch_initcall(prpmc2800_register_mtd);
> >
>
> I think "direct-mapped" as compatible is a bit too broad or vague.
It is. Basically, all I was trying to do was fit with the code that was
already in drivers/mtd/maps/physmap_of.c. I wasn't expecting to (re)trigger
the debate that it did. Its a good thing, though. FLASH/MTD
representation in the DT needs to get sorted out.
> The compatible is supposed to be useable to find and match a driver
> without regard to the name of the node. Perhaps direct-mapped-rom?
> (as opossed to a direct-mapped-ram, sram, or some width flash bank).
>
> Actually, looking back at your device tree {1], your list several
> properties for flash, including bank-width and partition names.
> Perhaps first compatible should be direct-mapped-partitioned-flash,
> direct-mapped-partitioned-rom, direct-mapped-rom (to me a
> direct-mapped-rom driver would expose one section of address space
> read-only). I'm assuming that your driver for this "direct-mapped"
> device will look at these properties from the of device node and
> call the mtd layer somewhat directly with their contents.
The "driver" is already there, drivers/mtd/maps/physmap_of.c. I
conjured up the DT node so it would work with that existing driver.
> PS: I know you've posted this a few times. I'm just behind in
> my reading and replying :-).
No problem. I just missed an entire thread the was directed at me :-P
Mark
^ permalink raw reply
* Re: [PATCH 4/5] powerpc: Add of_register_i2c_devices().
From: Guennadi Liakhovetski @ 2007-06-04 19:57 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, i2c
In-Reply-To: <20070518100908.aa803cc6.sfr@canb.auug.org.au>
Hi,
I need this patch, as well as "Scott Wood: [PATCH 5/5] powerpc: Call
of_register_i2c_devices() for fsl-i2c."
(http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html) to keep
linkstation working after the migration of the rtc-rs5c372 driver to the
new i2c api.
On Fri, 18 May 2007, Stephen Rothwell wrote:
> On Thu, 17 May 2007 09:38:56 -0500 Scott Wood <scottwood@freescale.com> wrote:
> >
> > + addr = get_property(node, "reg", &len);
>
> get_property has been replaced by of_get_property.
>
> > + name = get_property(node, "compatible", NULL);
>
> ditto.
Taking care of these corrections, and also using platform device id for
i2c adapter number, as suggested by Grant Likely (added to cc:) in
"[PATCH] Make i2c-mpc driver use i2c_add_numbered_adapter"
(http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036079.html), and using
"model" of-property, if available, to specify the exact model of the i2c
device, below is the updated version of the original patch of the hijacked
thread. Not sure what I shall do with sign-offs... I think, I'll post it
with none first, wait for Scott Woods comment and his sign-off, and then
add mine.
Please notice, these two patches suffice to be able to use i2c device
definitions from of. the "[PATCH 3/5] powerpc: Document device nodes for
I2C devices." is just documentation, that nobody needs anyway (/me hides),
and "[PATCH 2/5] i2c: Allow preallocation of I2C bus numbers." was pretty
controversal too, so, they can be addressed later again...
Thanks
Guennadi
---
Guennadi Liakhovetski
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 3786dcc..9caf96d 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -1067,3 +1067,49 @@ void __iomem *of_iomap(struct device_node *np, int index)
return ioremap(res.start, 1 + res.end - res.start);
}
EXPORT_SYMBOL(of_iomap);
+
+#ifdef CONFIG_I2C
+#include <linux/i2c.h>
+
+void 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;
+ const char *name, *model;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > 0xffff)
+ continue;
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ name = of_get_property(node, "compatible", NULL);
+ if (!name)
+ name = node->name;
+ if (!name)
+ continue;
+
+ model = of_get_property(node, "model", NULL);
+ if (!model)
+ model = name;
+
+ /* FIXME: the i2c code should allow drivers to specify
+ * multiple match names; board code shouldn't need to
+ * know what driver will handle a given type.
+ */
+
+ snprintf(info.driver_name, KOBJ_NAME_LEN, name);
+ snprintf(info.type, KOBJ_NAME_LEN, model);
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_register_board_info(bus_num, &info, 1);
+ }
+}
+#endif /* CONFIG_I2C */
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index c6b6898..a769efc 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -327,9 +327,10 @@ static int fsl_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, 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_adapter(&i2c->adap)) < 0) {
+ if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
goto fail_add;
}
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 6845af9..ed085e1 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -305,6 +305,7 @@ extern int of_irq_map_raw(struct device_node *parent, const u32 *intspec,
u32 ointsize, const u32 *addr,
struct of_irq *out_irq);
+void of_register_i2c_devices(struct device_node *adap_node, int bus_num);
/**
* of_irq_map_one - Resolve an interrupt for a device
^ permalink raw reply related
* [PATCH] add rtc-on-i2c node to two linkstation device-trees
From: Guennadi Liakhovetski @ 2007-06-04 20:17 UTC (permalink / raw)
To: linuxppc-dev
If approved here, this patch will follow the previous one for i2c-of
definitions to the -mm tree, to fix linkstation breakage caused by
converting rtc-rs5c372 driver to the new i2c api.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts b/arch/powerpc/boot/dts/kuroboxHG.dts
index 919eb29..4a904b1 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -70,11 +70,20 @@ build with: "dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts"
i2c@80003000 {
linux,phandle = <4300>;
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <80003000 1000>;
interrupts = <5 2>;
interrupt-parent = <4400>;
+
+ rtc@32 {
+ device_type = "rtc";
+ compatible = "rtc-rs5c372";
+ model = "rs5c372b";
+ reg = <32>;
+ };
};
serial@80004500 {
diff --git a/arch/powerpc/boot/dts/kuroboxHD.dts b/arch/powerpc/boot/dts/kuroboxHD.dts
index 157dc98..b5c0e78 100644
--- a/arch/powerpc/boot/dts/kuroboxHD.dts
+++ b/arch/powerpc/boot/dts/kuroboxHD.dts
@@ -70,11 +70,20 @@ build with: "dtc -f -I dts -O dtb -o kuroboxHD.dtb -V 16 kuroboxHD.dts"
i2c@80003000 {
linux,phandle = <4300>;
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <80003000 1000>;
interrupts = <5 2>;
interrupt-parent = <4400>;
+
+ rtc@32 {
+ device_type = "rtc";
+ compatible = "rtc-rs5c372";
+ model = "rs5c372b";
+ reg = <32>;
+ };
};
serial@80004500 {
^ permalink raw reply related
* [PATCH] Replace use of GET_64BIT(prop, i) with of_read_number().
From: Jon Loeliger @ 2007-06-04 20:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Remove uses of hack GET_64BIT() property macro and use
the more general of_read_number() function from prom.h
as suggested by Milton.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Someone in 64-bit land please check this!
I have no board on which to test this. Sorry.
jdl
arch/powerpc/kernel/pci_64.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 249cca2..b7cd53f 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -291,7 +291,6 @@ static unsigned int pci_parse_of_flags(u32 addr0)
return flags;
}
-#define GET_64BIT(prop, i) ((((u64) (prop)[(i)]) << 32) | (prop)[(i)+1])
static void pci_parse_of_addrs(struct device_node *node, struct pci_dev *dev)
{
@@ -310,8 +309,8 @@ static void pci_parse_of_addrs(struct device_node *node, struct pci_dev *dev)
flags = pci_parse_of_flags(addrs[0]);
if (!flags)
continue;
- base = GET_64BIT(addrs, 1);
- size = GET_64BIT(addrs, 3);
+ base = of_read_number(&addrs[1], 2);
+ size = of_read_number(&addrs[3], 2);
if (!size)
continue;
i = addrs[0] & 0xff;
@@ -477,7 +476,7 @@ void __devinit of_scan_pci_bridge(struct device_node *node,
i = 1;
for (; len >= 32; len -= 32, ranges += 8) {
flags = pci_parse_of_flags(ranges[0]);
- size = GET_64BIT(ranges, 6);
+ size = of_read_number(&ranges[6], 2);
if (flags == 0 || size == 0)
continue;
if (flags & IORESOURCE_IO) {
@@ -496,7 +495,7 @@ void __devinit of_scan_pci_bridge(struct device_node *node,
res = bus->resource[i];
++i;
}
- res->start = GET_64BIT(ranges, 1);
+ res->start = of_read_number(&ranges[1], 2);
res->end = res->start + size - 1;
res->flags = flags;
fixup_resource(res, dev);
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Andy Fleming @ 2007-06-04 20:27 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070603083339.GB2157@iram.es>
On Jun 3, 2007, at 03:33, Gabriel Paubert wrote:
> On Sun, Jun 03, 2007 at 09:41:33AM +0200, Segher Boessenkool wrote:
>>>> Oh what the hell, I'm too curious... "pnpPNP,0" it is.
>>>>
>>>>> I believe that "8259" should appear somewhere because of the
>>>>> "8259-interrupt-acknowledge" property (defined in CHRP bindings)
>>>>> which you can have on the parent bridge to speed up interrupt
>>>>> vector acquisition.
>>>>
>>>> You're not CHRP so you have nothing to do with the CHRP
>>>> bindings...
>>>
>>> Still, you are close to CHRP
>>
>> Not at all, the rest of the device interrupt subsystem
>> is very different, too.
>
> Given how well you agree, I understand how other people
> might get a bit confused ;-)
>
> This said, I'm looking at device trees right now, and I can understand
> that interrupt-parent of the 8259 is &mpic in mpc8641_hpcn.dts, but
> I don't understand at all why it is &pci1 on the mpc85??cds.dts.
>
> But the definition of the ISA bridge in these files is very strange to
> start with: I've never seen an ISA bridge with only an interrupt
> controller
> on it, no interrupts are connected to it and its reg property is
> almost certainly wrong. Maybe it is an example of things that should
> not be done.
I take full responsibility for that. The CDS is a strange beast, so
I did some strange things in the DTS.
The i8259 is on a subsidiary bus, and so it's one bus #1. I chose
not to create a proper node around it. Not for any good reason. The
reason its interrupt parent is pci1 is because the i8259 emits its
irq though PCI. This is because the 8555 (and other CDS chips) are
actually on a PCI card which is connected through PCI 1, while the
i8259 is behind a bridge on the motherboard into which the CDS
Carrier Card is plugged.
I always find my grammar stretched to the breaking point when
describing the PCI topology of the CDS!
The 8641's topology is much simpler, and the i8259 sends its
interrupts over an external interrupt pin which goes through the mpic/
openpic.
Andy
^ permalink raw reply
* Linux interrupt managing on 8xx
From: DI BACCO ANTONIO - technolabs @ 2007-06-04 20:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
I have a component named pca9555 (on the i2c bus) that is an I/O expander. It can generate an interrupt to the MPC8xx processor (SIU_IRQ1 pin). This pin will be active till I read registers of pca9555. Because I cannot access the i2c bus in the interrupt handler I queue a work on a work queue. Just at the end of the interrupt handler should I disable the interrupt on the mpc8xx? I think that otherwise the interrupt will pop up again till I execute the work in the work queue finally reading the pca9555 and shutting off the source of the interrupt.
Bye,
Antonio.
[-- Attachment #2: Type: text/html, Size: 961 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Mark A. Greer @ 2007-06-04 20:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070601232022.GA21237@mag.az.mvista.com>
Okay, >25 msgs from a ~10 line patch. I think that's a new personal
record for me. ;)
More seriously, I've simply been trying to provide a DT node that works
with the current code in drivers/mtd/maps/physmap_of.c. Obviously,
there are issues with that code and my DT node.
So to try a different approach, here is the hardware info and a copy of
the relevant DT that I currently have. Segher, et. al., if you can
find the time, please give me your best guidance as to what the DT
node(s) should really look like (and how physmap.c should really work).
I'll be happy to hack physmap_of.c once I have a clear understanding of
how it should work (and there is clear agreement on that :).
Mark
---
Hardware:
---------
[As I read this, I realize I have the DT node messed up anyway.]
- Not that this matters but this is a Marvell mv64360/mv64362 based board
with a MPC7447A processor.
- There are two 32MB banks of two Intel Stata Flash (NOR) chips (CFI).
Each 32MB bank is 32-bits wide built with two 8Mx16 28F128K3 devices
(http://download.intel.com/design/flcomp/datashts/29073709.pdf).
Bits 0-15 from the first device, bits 16-31 from the second one.
The two banks are contiguous in the processor's physical memory space.
- The MTD partitions are described in the DT.
For your reference, the exiting DT:
-----------------------------------
mv64x60@f1000000 { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <1>;
model = "mv64360"; /* Default */
compatible = "marvell,mv64x60";
clock-frequency = <7f28155>; /* 133.333333 MHz */
reg = <f1000000 00010000>;
virtual-reg = <f1000000>;
ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
80000000 80000000 08000000 /* PCI 0 MEM Space */
a0000000 a0000000 04000000 /* User FLASH */
00000000 f1000000 00010000 /* Bridge's regs */
f2000000 f2000000 00040000>; /* Integrated SRAM */
flash@a0000000 {
device_type = "rom";
compatible = "direct-mapped";
reg = <a0000000 4000000>; /* Default (64MB) */
probe-type = "CFI";
bank-width = <4>;
partitions = <00000000 00100000 /* RO */
00100000 00040001 /* RW */
00140000 00400000 /* RO */
00540000 039c0000 /* RO */
03f00000 00100000>; /* RO */
partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
};
So, what should the DT look like for this thing? And, what should
phymap_of.c be doing?
Mark
^ permalink raw reply
* [PATCH] powerpc: fix typo in booting-without-of-txt section numbering
From: Stuart Yoder @ 2007-06-04 21:16 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
>From 799bc4dbad6b4e8c2d88c7c2c4746072b9175222 Mon Sep 17 00:00:00 2001
From: Stuart Yoder <stuart.yoder@freescale.com>
Date: Mon, 4 Jun 2007 16:08:35 -0500
Subject: [PATCH] test
Fix typo in section numbering.
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index b49ce16..258a279 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1687,7 +1687,7 @@ platforms are moved over to use the flattened-device-tree model.
};
};
- g) Flash chip nodes
+ j) Flash chip nodes
Flash chips (Memory Technology Devices) are often used for solid state
file systems on embedded devices.
--
1.5.0.3
^ permalink raw reply related
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Marc Leeman @ 2007-06-04 21:17 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <4E25DA41-741E-40AC-9186-936FEEFE6B29@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
> Wow. Hardware designers sure like to make things easy, don't they?
<rant>
The reason that I am switching to powerpc is that dts seems a cleaner
way to handle the I-didn't-know-what-a-reference-design-is-for decisions
from our hardware designers and just connect up the devices like a large
box of lego :-/.
Even getting the gianfar eth devices up can become a challenge (not
again) because someone thought 'it makes more sense like this'. On
the bright side, I always have a reason in digging into the mpc834x
processor manual.
</rant>
> I'm assuming it's a PCI device on the board (and not in a slot).
yep, it's an FPGA device using PCI and GPIOs for interrupts (depending
on the board, it's for a MAC core in FPGA or custom logic).
> I believe you're ok if you explicitly define the node, and point it
> at the IPIC for its interrupt. Something like this:
>
> pci1: pci@8000 {
> ...
> my_pci_device@0 {
> ...
> interrupts = <irq#, sense>;
> interrupt-parent = <&ipic>;
> }
> }
So I don't have to define the GPIO pins in pio-map in "vi) Pin
configuration nodes" and already set in the U-Boot bootloader? Using the
GPIOs for interrupts or IO would just work "out of the box" after the
U-boot initialisation (used for TI's HPI in with the UPMB).
Hang, and I finally thought the documentation made sense to me :-)
I already tried hardcoding the EXT7 pin as assigned in the ppc arch
(int 23); this would mean that, in the powerpc arch, the assignments of
interrupts is different wrt to ppc?
--
greetz, marc
You'll be happy to know I have a plan.
Crichton - Through the Looking Glass
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Andy Fleming @ 2007-06-04 21:57 UTC (permalink / raw)
To: Marc Leeman; +Cc: linuxppc-dev
In-Reply-To: <20070604211740.GN17456@chiana.homelinux.org>
On Jun 4, 2007, at 16:17, Marc Leeman wrote:
>
> So I don't have to define the GPIO pins in pio-map in "vi) Pin
> configuration nodes" and already set in the U-Boot bootloader?
> Using the
> GPIOs for interrupts or IO would just work "out of the box" after the
> U-boot initialisation (used for TI's HPI in with the UPMB).
I meant external interrupts, not GPIOs. I just had a brain fart.
>
> Hang, and I finally thought the documentation made sense to me :-)
>
> I already tried hardcoding the EXT7 pin as assigned in the ppc arch
> (int 23); this would mean that, in the powerpc arch, the
> assignments of
> interrupts is different wrt to ppc?
In the intervening versions between the introduction of arch/powerpc,
and now, the interrupt mapping has also changed. The interrupts are
now all virtualized, and therefore all the interrupts start at 1 for
each interrupt controller. The numbers therefore change depending on
how things are initialized. You can't use hard-coded numbers
anymore. You need to map them into virtual numbers. The easiest way
is to set up an of node for the device, and invoke the necessary
translation functions from your board code (Take a look at the CDS
code for an example with a fairly complicated tree. Or any other fsl
board code for an almost-reasonable topology. :) )
Andy
^ 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