* disable modules and get "multiple definition" errors?
From: Kevin Diggs @ 2008-08-22 1:28 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am trying to do some compile testing of my cpufreq driver. If
I disable modules I am getting multiple definition errors of inline
functions:
inline volatile unsigned int get_PLL(void)
{
unsigned int ret;
__asm__ __volatile__ ("mfspr %0,%1":
"=r"(ret):
"i"(SPRN_HID1)
);
return ret;
}
arch/powerpc/kernel/cpu/pll_if.o(.text+0x1c): In function `get_PLL':
: multiple definition of `get_PLL'
arch/powerpc/kernel/cpu/cpufreq/built-in.o(.text+0x0): first defined here
What am I doing wrong?
kevin
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Josh Boyer @ 2008-08-22 1:15 UTC (permalink / raw)
To: David Miller
Cc: devicetree-discuss, linuxppc-dev, sparclinux, paulus, scottwood
In-Reply-To: <20080821.163216.239892875.davem@davemloft.net>
On Thu, 2008-08-21 at 16:32 -0700, David Miller wrote:
> From: "Grant Likely" <grant.likely@secretlab.ca>
> Date: Thu, 21 Aug 2008 17:14:57 -0600
>
> > On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> > > David Miller wrote:
> > >>>
> > >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > >> If you guys created this format in your compressed openfirmware
> > >> trees, is it possible for you to "fix" it to match what Sparc
> > >> systems following the proper bindings do?
> > >
> > > Possibly, though it'll cause some pain when old trees are used with a kernel
> > > that expects the new binding.
> >
> > Ugh, more like loads of pain. There are deployed platforms using the
> > embedded 'invented' bindings. I don't think it is an option to break
> > compatibility with older trees. If there is some backwards
> > compatibility code then I'm all for migrating to the same binding as
> > Sparc and PowerMac
>
> You could even put the detection and reg property fixups in the device
> tree expander. This way generic code in drivers/of/of_i2c.c doesn't
> need to know about this huge mistake.
Huge? I'd say mistake, but not necessarily huge. I mean nobody other
than you (at least in the context of this conversation) had access to
the IEEE1275 proposed binding so it wasn't like there was tons to go on.
Have patience with the embedded people that are both new to OpenFirmware
and trying to make stuff work at the same time. I think the
devicetree-discuss list will help here as new bindings are proposed. I
hope you're subscribed.
josh
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Jon Smirl @ 2008-08-21 23:45 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linuxppc-dev, sparclinux, paulus, Scott Wood,
David Miller
In-Reply-To: <fa686aa40808211614q72f6719btd391830abded58f6@mail.gmail.com>
On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> > David Miller wrote:
> >>>
> >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>
> >> If you guys created this format in your compressed openfirmware
> >> trees, is it possible for you to "fix" it to match what Sparc
> >> systems following the proper bindings do?
> >
> > Possibly, though it'll cause some pain when old trees are used with a kernel
> > that expects the new binding.
>
>
> Ugh, more like loads of pain. There are deployed platforms using the
> embedded 'invented' bindings. I don't think it is an option to break
> compatibility with older trees. If there is some backwards
> compatibility code then I'm all for migrating to the same binding as
> Sparc and PowerMac
Has anything really been deployed? These bindings are only a few months old.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* About physmap driver
From: lim.chongkean @ 2008-08-21 23:36 UTC (permalink / raw)
To: Linuxppc-embedded
when i try to do the following on the target system:
cat /proc/mtd
dev: size erasesize name
mtd0: 04000000 00020000 "physmap-flash.0"
no partition is showing,
i've enabled the MTD partition support in make menuconfig.
appreciate for any guide out there.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-21 23:32 UTC (permalink / raw)
To: grant.likely
Cc: scottwood, sparclinux, devicetree-discuss, paulus, linuxppc-dev
In-Reply-To: <fa686aa40808211614q72f6719btd391830abded58f6@mail.gmail.com>
From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 17:14:57 -0600
> On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> > David Miller wrote:
> >>>
> >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> >> If you guys created this format in your compressed openfirmware
> >> trees, is it possible for you to "fix" it to match what Sparc
> >> systems following the proper bindings do?
> >
> > Possibly, though it'll cause some pain when old trees are used with a kernel
> > that expects the new binding.
>
> Ugh, more like loads of pain. There are deployed platforms using the
> embedded 'invented' bindings. I don't think it is an option to break
> compatibility with older trees. If there is some backwards
> compatibility code then I'm all for migrating to the same binding as
> Sparc and PowerMac
You could even put the detection and reg property fixups in the device
tree expander. This way generic code in drivers/of/of_i2c.c doesn't
need to know about this huge mistake.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Grant Likely @ 2008-08-21 23:14 UTC (permalink / raw)
To: Scott Wood
Cc: sparclinux, linuxppc-dev, devicetree-discuss, paulus,
David Miller
In-Reply-To: <48ADDF86.2040200@freescale.com>
On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <scottwood@freescale.com> wrote:
> David Miller wrote:
>>>
>>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>> If you guys created this format in your compressed openfirmware
>> trees, is it possible for you to "fix" it to match what Sparc
>> systems following the proper bindings do?
>
> Possibly, though it'll cause some pain when old trees are used with a kernel
> that expects the new binding.
Ugh, more like loads of pain. There are deployed platforms using the
embedded 'invented' bindings. I don't think it is an option to break
compatibility with older trees. If there is some backwards
compatibility code then I'm all for migrating to the same binding as
Sparc and PowerMac
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3]: of: Add some I2C mod aliases table entries for sparc64 systems.
From: David Miller @ 2008-08-21 22:55 UTC (permalink / raw)
To: grant.likely; +Cc: sparclinux, linuxppc-dev, devicetree-discuss, paulus
In-Reply-To: <fa686aa40808211552x4ff22c4bve2b8c9dbc88ff0e4@mail.gmail.com>
From: "Grant Likely" <grant.likely@secretlab.ca>
Date: Thu, 21 Aug 2008 16:52:32 -0600
> On Thu, Aug 21, 2008 at 1:10 AM, David Miller <davem@davemloft.net> wrote:
> >
> > of: Add some I2C mod aliases table entries for sparc64 systems.
> >
> > Signed-off-by: David S. Miller <davem@davemloft.net>
>
> I'd like to see a comment above these three lines stating that they
> appear in Sparc systems, but otherwise...
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Ok, I'll add that.
^ permalink raw reply
* Re: New Patchwork beta
From: Josh Boyer @ 2008-08-21 22:52 UTC (permalink / raw)
To: Kumar Gala
Cc: bazaar-ng, linuxppc-dev, linux-mtd, Jeremy Kerr,
linuxppc-embedded, cbe-oss-dev
In-Reply-To: <985DF0C9-8615-439A-8DBB-06FAB53CE68F@kernel.crashing.org>
On Thu, 2008-08-21 at 15:32 -0500, Kumar Gala wrote:
> Some feedback:
>
> * Can we increase the font size a bit?
NOO. Just use CTRL-SHIFT-+.
> * For the list of patches can we change the background of every other
> line (light gray)
That would work well.
> * Parsing subject header for determining state -- "[RFC]"
That is going to fail miserably because people tend to do silly things
like post final patches in the middle of an [RFC] thread.
josh
^ permalink raw reply
* Re: [PATCH 3/3]: of: Add some I2C mod aliases table entries for sparc64 systems.
From: Grant Likely @ 2008-08-21 22:52 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, devicetree-discuss, paulus
In-Reply-To: <20080821.001025.76289480.davem@davemloft.net>
On Thu, Aug 21, 2008 at 1:10 AM, David Miller <davem@davemloft.net> wrote:
>
> of: Add some I2C mod aliases table entries for sparc64 systems.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
I'd like to see a comment above these three lines stating that they
appear in Sparc systems, but otherwise...
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
> ---
> drivers/of/base.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ad8ac1a..e849f69 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -410,7 +410,9 @@ struct of_modalias_table {
> char *modalias;
> };
> static struct of_modalias_table of_modalias_table[] = {
> - /* Empty for now; add entries as needed */
> + { "i2c-adm1031", "adm1031" },
> + { "i2c-at24c64", "24c64" },
> + { "i2c-at34c02", "spd" },
> };
>
> /**
> --
> 1.5.6.5.GIT
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt @ 2008-08-21 22:39 UTC (permalink / raw)
To: David Miller; +Cc: scottwood, sparclinux, paulus, linuxppc-dev
In-Reply-To: <20080821.152857.84114588.davem@davemloft.net>
On Thu, 2008-08-21 at 15:28 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Fri, 22 Aug 2008 08:05:02 +1000
>
> > Apple additionally have different ways of representing multiple busses
> > on one controller though. On some machines, they just use bits 0xF00 of
> > the address as the bus number, which is a bit gross, and on some, they
> > have sub-nodes i2c-bus@NN under the controller.
>
> Ok, Sun uses a 2-cell scheme. We can handle both cases of reg
> encoding quite easily:
>
> 1) If there is a single cell, tread bits 8 and above as bus number.
> They will be zero on Sparc.
Depends if you want also to handle 10-bit addresses... though the
support for that could be enabled by an explicit property
10-bit-addresses in the controller node... But as I said before, I
wouldn't worry too much about powermac for now, it's not using this code
and may never do.
> 2) If there are two cells, first cell is bus number.
>
> For the hierarchical case, I'm not so sure how to handle it.
>
> Also, last night, I posted patches to the I2C list to add bus
> addressing support to the I2C code and the PCF algo implementation.
Ben.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt @ 2008-08-21 22:38 UTC (permalink / raw)
To: David Miller; +Cc: scottwood, sparclinux, paulus, linuxppc-dev
In-Reply-To: <20080821.152701.261427328.davem@davemloft.net>
> Thanks for the clarification. The bus encoding seems different
> but we can solve that too.
>
> I've started a dialogue between Scott and the openfirmware Sun
> folks I know so that hopefully Scott can get a copy of the I2C
> bindings Sun uses and we can sort all of this out.
Sure. Currently the powermac stuff isn't too relevant because I
use my own infrastructure (not a huge thing, but I have a special
layer of low level polled i2c drivers that I can use early during
boot or during low level suspend/resume with IRQs off etc... that
hooks up on to the main linux i2c stack etc...)
So I'll let you guys come up with something, and we can later see if
there's any interest in moving some of the pmac stuff over to it.
Ben.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-21 22:28 UTC (permalink / raw)
To: benh; +Cc: scottwood, sparclinux, paulus, linuxppc-dev
In-Reply-To: <1219356302.21386.147.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 22 Aug 2008 08:05:02 +1000
> Apple additionally have different ways of representing multiple busses
> on one controller though. On some machines, they just use bits 0xF00 of
> the address as the bus number, which is a bit gross, and on some, they
> have sub-nodes i2c-bus@NN under the controller.
Ok, Sun uses a 2-cell scheme. We can handle both cases of reg
encoding quite easily:
1) If there is a single cell, tread bits 8 and above as bus number.
They will be zero on Sparc.
2) If there are two cells, first cell is bus number.
For the hierarchical case, I'm not so sure how to handle it.
Also, last night, I posted patches to the I2C list to add bus
addressing support to the I2C code and the PCF algo implementation.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-21 22:27 UTC (permalink / raw)
To: benh; +Cc: scottwood, sparclinux, paulus, linuxppc-dev
In-Reply-To: <1219356350.21386.150.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 22 Aug 2008 08:05:50 +1000
> On Thu, 2008-08-21 at 14:45 -0700, David Miller wrote:
> > > As far as I can tell from poking around
> > > http://penguinppc.org/historical/dev-trees-html/, they don't include
> > reg
> > > at all for i2c clients.
> >
> > That actually simplifies things for us, thanks for checking.
>
> Unfortunately, while that may be true for old stuff, most recent
> powermacs do. Encoding is mostly like sparc though (see other mails).
Thanks for the clarification. The bus encoding seems different
but we can solve that too.
I've started a dialogue between Scott and the openfirmware Sun
folks I know so that hopefully Scott can get a copy of the I2C
bindings Sun uses and we can sort all of this out.
^ permalink raw reply
* Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
From: Hollis Blanchard @ 2008-08-21 22:25 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <200808191328.16934.arnd@arndb.de>
On Tue, 2008-08-19 at 13:28 +0200, Arnd Bergmann wrote:
> On Tuesday 19 August 2008, ehrhardt@linux.vnet.ibm.com wrote:
> > +static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
> > +{
> > + register unsigned long hcall asm ("r0") = nr;
> > + register unsigned long arg1 asm ("r3") = p1;
> > + register long ret asm ("r11");
> > +
> > + asm volatile(".long %1"
> > + : "=r"(ret)
> > + : "i"(KVM_HYPERCALL_BIN), "r"(hcall), "r"(arg1)
> > + : "r4", "r5", "r6", "r7", "r8",
> > + "r9", "r10", "r12", "cc");
> > + return ret;
> > +}
>
> What is the reasoning for making the calling convention different from
> all the existing hcall interfaces here?
>
> pseries uses r3 for the hcall number, lv1 and beat use r11, so using
> r0 just for the sake of being different seems counterintuitive.
There was a really good reason at the time, but I can't seem to remember
it now. ;) We're thinking about it.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt @ 2008-08-21 22:05 UTC (permalink / raw)
To: David Miller; +Cc: scottwood, sparclinux, paulus, linuxppc-dev
In-Reply-To: <20080821.144545.54542588.davem@davemloft.net>
On Thu, 2008-08-21 at 14:45 -0700, David Miller wrote:
> > As far as I can tell from poking around
> > http://penguinppc.org/historical/dev-trees-html/, they don't include
> reg
> > at all for i2c clients.
>
> That actually simplifies things for us, thanks for checking.
Unfortunately, while that may be true for old stuff, most recent
powermacs do. Encoding is mostly like sparc though (see other mails).
Ben.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt @ 2008-08-21 22:05 UTC (permalink / raw)
To: Scott Wood; +Cc: sparclinux, linuxppc-dev, paulus, David Miller
In-Reply-To: <48ADDF86.2040200@freescale.com>
> It's not really an instruction-set architecture issue, it's a binding
> issue. What if a non-OF embedded SPARC comes along that copies i2c from
> a PowerPC DTS file, or we come across a real-OF PowerPC that does it the
> SPARC way?
Like PowerMac ? :-)
Apple additionally have different ways of representing multiple busses
on one controller though. On some machines, they just use bits 0xF00 of
the address as the bus number, which is a bit gross, and on some, they
have sub-nodes i2c-bus@NN under the controller.
But at least the address encoding (shifted by 1 bit) is common with sparc
and I think is a fairly common way of representing i2c addresses.
> As far as I can tell from poking around
> http://penguinppc.org/historical/dev-trees-html/, they don't include reg
> at all for i2c clients.
Most of the device-trees on penguinppc.org are obsolete. i2c is mostly
used in the device-tree for newer stuff such as G5s.
Ben.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Benjamin Herrenschmidt @ 2008-08-21 22:01 UTC (permalink / raw)
To: Scott Wood; +Cc: sparclinux, linuxppc-dev, paulus, David Miller
In-Reply-To: <20080821163256.GC15669@ld0162-tx32.am.freescale.net>
On Thu, 2008-08-21 at 11:32 -0500, Scott Wood wrote:
> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > Mostly straightforward stuff _except_ for the I2C address encoding.
> >
> > What I2C IEEE1275 device binding was used to write that code in
> > of_i2c.c? Is it some PowerPC specific thing? Was it "invented"
> > by the embedded folks (I hope not)?
>
> Yes, it was "invented". There was no documented i2c OF binding that I
> could find, and AFAIR nobody came forward with examples of existing
> practice at the time.
Well, there were examples in the powermac code :-)
> > And, furthermore, the device address is shifted up 1 bit higher
> > than the Linux I2C layer expects. It includes the low direction
> > bit, bit 0, so we have to shift it down by 1 bit before we give
> > it to the Linux I2C layer.
>
> Yuck.
Apple does the same. IE. I take the address from "reg" and shift it
right by one bit before passing it to linux.
> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> > giving it to the Linux I2C layer.
>
> Maybe we should distinguish by the type of I2C bus node instead.
Or fix the embedded stuff :-)
Ben.
^ permalink raw reply
* Re: [PATCH] math-emu: Fix compiler warnings
From: Kumar Gala @ 2008-08-21 21:59 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080821.140346.236252915.davem@davemloft.net>
On Aug 21, 2008, at 4:03 PM, David Miller wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Date: Thu, 21 Aug 2008 07:50:20 -0500
>
>> Fix warnings of the form:
>> arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used
>> uninitialized in this function
>> arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used
>> uninitialized in this function
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> You should look at the compiler options we use on sparc to build this
> stuff :-)
>
> EXTRA_CFLAGS = -Iinclude/math-emu -w
Yeah, I plan on doing that on PPC once I move over the global include/
math-emu files.
- k
^ permalink raw reply
* Re: [PATCH 1/3]: sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
From: David Miller @ 2008-08-21 21:59 UTC (permalink / raw)
To: avorontsov; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821215611.GA14354@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Fri, 22 Aug 2008 01:56:11 +0400
> On Thu, Aug 21, 2008 at 12:10:17AM -0700, David Miller wrote:
> > @@ -96,6 +96,14 @@ static inline void of_node_put(struct device_node *node)
> > {
> > }
> >
> > +/* These routines are here to provide compatibility with how powerpc
> > + * handles IRQ mapping for OF device nodes. We precompute and permanently
> > + * register them in the of_device objects, whereas powerpc computes them
> > + * on request.
> > + */
> > +extern int irq_of_parse_and_map(struct device_node *node, int index);
>
> On powerpc irq_of_parse_and_map() returns unsigned type.
>
> > +#define irq_dispose_mapping(irq) do { } while (0)
>
> I'd rather write it as a static inline function, for type checking,
> plus, I think with this macros gcc may generate warnings about
> defined but unused variables.
Thanks, I'll fix that.
> > +
> > /*
> > * NB: This is here while we transition from using asm/prom.h
> > * to linux/of.h
> > diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
> > index cc4c235..56e9a71 100644
> > --- a/arch/sparc/kernel/of_device.c
> > +++ b/arch/sparc/kernel/of_device.c
> > @@ -29,6 +29,17 @@ struct of_device *of_find_device_by_node(struct device_node *dp)
> > }
> > EXPORT_SYMBOL(of_find_device_by_node);
> >
> > +int irq_of_parse_and_map(struct device_node *node, int index)
> > +{
> > + struct of_device *op = of_find_device_by_node(node);
> > +
> > + if (!op || index >= op->num_irqs)
> > + return 0xffffffff;
>
> This is valid virq, unfortunately. There is only one invalid virq: 0.
> With this most drivers will fail to identify 'there is no irq' case.
> Does virq0 has special meaning on sparc?
No, I'll fix this up, thanks.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-21 21:58 UTC (permalink / raw)
To: jonsmirl; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <9e4733910808211453t63f0a6f5h2139e027319263f1@mail.gmail.com>
From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Thu, 21 Aug 2008 17:53:02 -0400
> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> > giving it to the Linux I2C layer.
>
> How do you deal with a 10-bit address i2c device? Is it multiplied by two too?
Yes.
^ permalink raw reply
* Re: [PATCH 1/3]: sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
From: Anton Vorontsov @ 2008-08-21 21:56 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821.001017.261408123.davem@davemloft.net>
On Thu, Aug 21, 2008 at 12:10:17AM -0700, David Miller wrote:
>
> sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
>
> This allows more OF layer code to be shared between powerpc and
> sparc.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> arch/sparc/include/asm/prom.h | 8 ++++++++
> arch/sparc/kernel/of_device.c | 11 +++++++++++
> arch/sparc64/kernel/of_device.c | 11 +++++++++++
> 3 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
> index b5efc4d..58b85fa 100644
> --- a/arch/sparc/include/asm/prom.h
> +++ b/arch/sparc/include/asm/prom.h
> @@ -96,6 +96,14 @@ static inline void of_node_put(struct device_node *node)
> {
> }
>
> +/* These routines are here to provide compatibility with how powerpc
> + * handles IRQ mapping for OF device nodes. We precompute and permanently
> + * register them in the of_device objects, whereas powerpc computes them
> + * on request.
> + */
> +extern int irq_of_parse_and_map(struct device_node *node, int index);
On powerpc irq_of_parse_and_map() returns unsigned type.
> +#define irq_dispose_mapping(irq) do { } while (0)
I'd rather write it as a static inline function, for type checking,
plus, I think with this macros gcc may generate warnings about
defined but unused variables.
> +
> /*
> * NB: This is here while we transition from using asm/prom.h
> * to linux/of.h
> diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
> index cc4c235..56e9a71 100644
> --- a/arch/sparc/kernel/of_device.c
> +++ b/arch/sparc/kernel/of_device.c
> @@ -29,6 +29,17 @@ struct of_device *of_find_device_by_node(struct device_node *dp)
> }
> EXPORT_SYMBOL(of_find_device_by_node);
>
> +int irq_of_parse_and_map(struct device_node *node, int index)
> +{
> + struct of_device *op = of_find_device_by_node(node);
> +
> + if (!op || index >= op->num_irqs)
> + return 0xffffffff;
This is valid virq, unfortunately. There is only one invalid virq: 0.
With this most drivers will fail to identify 'there is no irq' case.
Does virq0 has special meaning on sparc?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Jon Smirl @ 2008-08-21 21:53 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821.001012.265401427.davem@davemloft.net>
On 8/21/08, David Miller <davem@davemloft.net> wrote:
>
> I'm working on some drivers for I2C bus support on some of my sparc64
> workstations (for lm-sensor and eeprom type devices sitting behind
> them) so I went back to trying to get of_i2c.c usable on sparc.
>
> Mostly straightforward stuff _except_ for the I2C address encoding.
>
> What I2C IEEE1275 device binding was used to write that code in
> of_i2c.c? Is it some PowerPC specific thing? Was it "invented"
> by the embedded folks (I hope not)?
>
> On sparc, the encoding is either 1 cell or 2 cell.
>
> If it's one cell, it's just the device address.
>
> If it's two cells, it's a bus number (for I2C controllers that
> can manage multiple I2C bus segments, think PCI domains) in the
> first cell and the device address in the second cell.
>
> And, furthermore, the device address is shifted up 1 bit higher
> than the Linux I2C layer expects. It includes the low direction
> bit, bit 0, so we have to shift it down by 1 bit before we give
> it to the Linux I2C layer.
>
> Does PowerPC really encode these things differently? And if so what
> IEEE1275 I2C device binding specification covers that?
>
> If PowerPC really does encode the device address in the same format as
> the Linux I2C layer expects, that's OK and I used some property tests
> and ifdefs to make it all work out. What I did in these patches is:
>
> 1) Check the #address-cells property. If not present, assume the value
> is "1". Only accept values of "1" and "2".
>
> 2) When CONFIG_SPARC, shift the device address down by one bit before
> giving it to the Linux I2C layer.
How do you deal with a 10-bit address i2c device? Is it multiplied by two too?
Here's the i2c spec,
http://www.semiconductors.philips.com/acrobat_download/literature/9398/39340011.pdf
It says the basic addresses are 7 bit.
> I haven't added support to the I2C layer for the bus number yet, that
> will come later.
>
> The first patch in this series add the powerpc-compat IRQ probing
> interfaces, mostly straightforward stuff as we precompute these
> IRQs in of_device objects so we just search for the of_device corresponding
> to the device node and return the interrupt, if any. Dispost is a NOP.
>
> The second patch deals with the addressing issues described above and
> lets it be compiled on non-ppc systems.
>
> The third patch adds device modaliases for a couple of I2C chip devices
> I've seen on my SunBlade2500 workstation. More will come later as I
> flesh out my I2C sparc64 drivers which are not being posted here yet.
> I have a fully functional Sun pcf8584 I2C bus driver.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: David Miller @ 2008-08-21 21:45 UTC (permalink / raw)
To: scottwood; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <48ADDF86.2040200@freescale.com>
From: Scott Wood <scottwood@freescale.com>
Date: Thu, 21 Aug 2008 16:35:02 -0500
> David Miller wrote:
> > If you guys created this format in your compressed openfirmware
> > trees, is it possible for you to "fix" it to match what Sparc
> > systems following the proper bindings do?
>
> Possibly, though it'll cause some pain when old trees are used with a
> kernel that expects the new binding.
>
> You mentioned having an actual binding document for I2C on Open
> Firmware; is it available online anywhere?
It's a Sun internal document I got from a Sun employee, I'll ask
if there is a way I can at least share it with you privately so
you can use it as a reference.
> > Don't PowerMACs and such have I2C controllers and devices?
> > How do they encode these I2C client device reg properties?
>
> As far as I can tell from poking around
> http://penguinppc.org/historical/dev-trees-html/, they don't include reg
> at all for i2c clients.
That actually simplifies things for us, thanks for checking.
^ permalink raw reply
* Re: [PATCH] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
From: Kumar Gala @ 2008-08-21 21:40 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1219352996-22243-1-git-send-email-becky.bruce@freescale.com>
> #define _PMD_PRESENT 0
> #define _PMD_PRESENT_MASK (PAGE_MASK)
> @@ -517,7 +522,13 @@ extern unsigned long
> bad_call_to_PMD_PAGE_SIZE(void);
>
> #define pte_none(pte) ((pte_val(pte) & ~_PTE_NONE_MASK) == 0)
> #define pte_present(pte) (pte_val(pte) & _PAGE_PRESENT)
> +
> +#if (defined(CONFIG_PTE_64BIT) && (_PAGE_HASHPTE != 0))
> +#define pte_clear(mm, addr, ptep) \
> + do { pte_update((ptep), (~_PAGE_HASHPTE), __pte(0)); } while (0)
drop the __pte(0), doesn't make sense for pte_update
>
> +#else
> #define pte_clear(mm,addr,ptep) do { set_pte_at((mm), (addr),
> (ptep), __pte(0)); } while (0)
> +#endif
Can we just always (for all ppc32) do:
#define pte_clear(mm,addr,ptep) do { pte_update(ptep,
(~_PAGE_HASHPTE), 0); } while (0)
I've already changed this to be:
#define pte_clear(mm,addr,ptep) do { pte_update(ptep, ~0, 0); } while
(0)
> /*
> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/
> asm/types.h
> index d3374bc..a9a9262 100644
> --- a/arch/powerpc/include/asm/types.h
> +++ b/arch/powerpc/include/asm/types.h
> @@ -55,7 +55,7 @@ typedef u64 phys_addr_t;
> typedef u32 phys_addr_t;
> #endif
>
> -#ifdef __powerpc64__
> +#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
> typedef u64 dma_addr_t;
> #else
> typedef u32 dma_addr_t;
is this really part of this patchset of the IOMMU changes?
- k
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Scott Wood @ 2008-08-21 21:35 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, paulus
In-Reply-To: <20080821.142134.127315039.davem@davemloft.net>
David Miller wrote:
>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
>>> 2) When CONFIG_SPARC, shift the device address down by one bit before
>>> giving it to the Linux I2C layer.
>> Maybe we should distinguish by the type of I2C bus node instead.
>
> How so? If a Sparc and a PowerPC system use similar I2C
> controllers, we risk double matches.
It's not really an instruction-set architecture issue, it's a binding
issue. What if a non-OF embedded SPARC comes along that copies i2c from
a PowerPC DTS file, or we come across a real-OF PowerPC that does it the
SPARC way?
If we do come across two systems that claim their i2c bus nodes are
compatible but use different bindings, *then* we'll find some
out-of-band information to disambiguate.
> If you guys created this format in your compressed openfirmware
> trees, is it possible for you to "fix" it to match what Sparc
> systems following the proper bindings do?
Possibly, though it'll cause some pain when old trees are used with a
kernel that expects the new binding.
You mentioned having an actual binding document for I2C on Open
Firmware; is it available online anywhere?
> Don't PowerMACs and such have I2C controllers and devices?
> How do they encode these I2C client device reg properties?
As far as I can tell from poking around
http://penguinppc.org/historical/dev-trees-html/, they don't include reg
at all for i2c clients.
-Scott
^ 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