* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Benjamin Herrenschmidt @ 2012-04-02 21:08 UTC (permalink / raw)
To: Josh Boyer
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
linuxppc-dev
In-Reply-To: <CA+5PVA6jQgme0sS=i8yYX6b_R5179+BtWPh7QXCGNfoLTCt46A@mail.gmail.com>
On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote:
> On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
> >
> >> Hi Josh Boyer,
> >>
> >> just wanted to add that I'm experiencing the same problem that Robert
> >> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
> >> mfdcrx instruction, so maybe it's more to it than just a binutils bug?
> >
> > The kernel shouldn't have tried to build that instruction on 8xx, though
> > I suppose if it's in arch/powerpc/boot, we are a bit too eager at
> > building everything including what's not relevant, we might to be a bit
> > more careful at excluding 4xx stuff on a 8xx kernel.
>
> It's still a binutils issue. Sounds like the toolchain being used to
> build the 8xx kernel is specifically built for 8xx. A generally built
> binutils should have worked fine (assuming it was new enough), since
> we pass -mcpu=405.
Still, it makes sense to limit the building of the wrappers to the CPU
family of the kernel...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 21:11 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2r4w6jugo.fsf@linux-m68k.org>
On Mon, 2012-04-02 at 12:31 +0200, Andreas Schwab wrote:
> > - PowerMac7,3 aka Dual G5 AGP. This ones has U3 + K2 and
> > uses cascaded MPICs
>
> That's the same as mine, config is attached. I'm currently trying to
> bisect the commit that actually broke the series.
Hrm, odd.. I'll dbl check today that I didn't b0rk something in my test
(like loading the wrong kernel :-) I'll also try with your config.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 21:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: devicetree-discuss, LKML, Milton Miller, Andreas Schwab,
Rob Herring, Russell King, linuxppc-dev, LAK
In-Reply-To: <alpine.LFD.2.02.1204022251420.2542@ionos>
On Mon, 2012-04-02 at 22:52 +0200, Thomas Gleixner wrote:
> > When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> > long-term regression in genirq irq_set_irq_type() handling") on top
> of
> > 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
>
> Hmm. Which irq chip is handling the interrupt for that sata irq ?
MPIC. The irq is a PCI IRQ, and so should be level-low, it should have
been mapped by the PCI code using the of_* calls.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Andreas Schwab @ 2012-04-02 21:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: devicetree-discuss, LKML, Milton Miller, Rob Herring,
Russell King, linuxppc-dev, LAK
In-Reply-To: <alpine.LFD.2.02.1204022251420.2542@ionos>
Thomas Gleixner <tglx@linutronix.de> writes:
> Hmm. Which irq chip is handling the interrupt for that sata irq ?
It's MPIC 1.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 08/18] PCI, powerpc: Register busn_res for root buses
From: Benjamin Herrenschmidt @ 2012-04-02 21:22 UTC (permalink / raw)
To: Milton Miller
Cc: Tony Luck, Linus Torvalds, linuxppc-dev, lkml, Dominik Brodowski,
Jesse Barnes, Greg Kroah-Hartmann, Bjorn Helgaas, Andrew Morton,
Yinghai Lu
In-Reply-To: <powerpc-pci-domains-by-busnumber-resend@mdm.bga.com>
On Mon, 2012-04-02 at 05:19 -0500, Milton Miller wrote:
>
> In the POWER3 era we had several boxes that split the pci bus number
> space across domains and RTAS used the bus number to find the correct
> PHB. This contineed to the first RS64 boxes. By S80 and RS64-III
> it was obvious that we didn't have enough numbers to continue this
> ilusion and we added the presently used RTAS calls that take the pci
> domain as well as bus, device, and function numbers.
>
> The bus numbers split across pci domains started with the F50
> F50 chrp 32 bit platforms.
Ok, so old CHRPs would have a split as well...
I think the best is to honor the bus-range property of the PHB as min &
max values, and if we feel a need to allow the kernel to assign busses
beyond that, we can always quirk the appropriate platform code.
Cheers,
Ben.
^ permalink raw reply
* Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
From: Josh Boyer @ 2012-04-02 21:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
linuxppc-dev
In-Reply-To: <1333400910.30734.54.camel@pasglop>
On Mon, Apr 2, 2012 at 5:08 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote:
>> On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e wrote:
>> >
>> >> Hi Josh Boyer,
>> >>
>> >> just wanted to add that I'm experiencing the same problem that Robert
>> >> reported, but on 8xx instead of 4xx. The mpc8xx does not support the
>> >> mfdcrx instruction, so maybe it's more to it than just a binutils bug=
?
>> >
>> > The kernel shouldn't have tried to build that instruction on 8xx, thou=
gh
>> > I suppose if it's in arch/powerpc/boot, we are a bit too eager at
>> > building everything including what's not relevant, we might to be a bi=
t
>> > more careful at excluding 4xx stuff on a 8xx kernel.
>>
>> It's still a binutils issue. =A0Sounds like the toolchain being used to
>> build the 8xx kernel is specifically built for 8xx. =A0A generally built
>> binutils should have worked fine (assuming it was new enough), since
>> we pass -mcpu=3D405.
>
> Still, it makes sense to limit the building of the wrappers to the CPU
> family of the kernel...
Oh, I'm not really disagreeing with that. I think I said as much about
4 years ago, but at the time the prevailing opinion was what we
currently have. I never really understood why.
Out with the old, in with the sane.
josh
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Thomas Gleixner @ 2012-04-02 21:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, LKML, Milton Miller, Andreas Schwab,
Rob Herring, Russell King, linuxppc-dev, LAK
In-Reply-To: <1333401600.30734.56.camel@pasglop>
On Tue, 3 Apr 2012, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-02 at 22:52 +0200, Thomas Gleixner wrote:
> > > When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> > > long-term regression in genirq irq_set_irq_type() handling") on top
> > of
> > > 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> >
> > Hmm. Which irq chip is handling the interrupt for that sata irq ?
>
> MPIC. The irq is a PCI IRQ, and so should be level-low, it should have
> been mapped by the PCI code using the of_* calls.
So it's covered by this section:
mpic_set_irq_type()
if (flow_type == IRQ_TYPE_NONE)
if (mpic->senses && src < mpic->senses_count)
flow_type = mpic->senses[src];
if (flow_type == IRQ_TYPE_NONE)
flow_type = IRQ_TYPE_LEVEL_LOW;
And with IRQ_TYPE_NONE this is always going to end up with
IRQ_TYPE_LEVEL_LOW simply because the only function which might set
mpic->senses is mpic_set_default_senses(). And this function does not
have a single caller .....
/me scratches head
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Russell King - ARM Linux @ 2012-04-02 21:55 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Andreas Schwab,
Rob Herring, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402202848.1EB833E02A7@localhost>
On Mon, Apr 02, 2012 at 02:28:48PM -0600, Grant Likely wrote:
> On Mon, 02 Apr 2012 18:29:15 +0200, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > Andreas Schwab <schwab@linux-m68k.org> writes:
> >
> > > Grant Likely <grant.likely@secretlab.ca> writes:
> > >
> > >> This patch drops the powerpc-specific irq_map table and replaces it with
> > >> directly using the irq_alloc_desc()/irq_free_desc() interfaces for allocating
> > >> and freeing irq_desc structures.
> > >
> > > This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> > > driver.
> >
> > When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> > long-term regression in genirq irq_set_irq_type() handling") on top of
> > 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> > interrupts. Also the X server is broken somehow, though I don't know
> > whether that is related or a different bug.
>
> That change is:
>
> @@ -61,8 +61,7 @@ int irq_set_irq_type(unsigned int irq, unsigned int type)
> return -EINVAL;
>
> type &= IRQ_TYPE_SENSE_MASK;
> - if (type != IRQ_TYPE_NONE)
> - ret = __irq_set_trigger(desc, irq, type);
> + ret = __irq_set_trigger(desc, irq, type);
> irq_put_desc_busunlock(desc, flags);
> return ret;
>
> So presumably irq_set_irq_type() is getting called with type ==
> IRQ_TYPE_NONE. From Russell's description, presumably that would mean
> the G5 sata driver isn't setting the correct type for the interrupt,
> but I have *no* idea how that intersects with the change removing the
> powerpc irq map.
Well, presumably someone is calling irq_set_irq_type() asking explicitly
for IRQ_TYPE_NONE. The code will now (as it always used to before David's
change) do exactly what you ask this to: it will ask the type to be set
to none.
If you don't want to set the type to none, don't call the interface asking
for that to happen.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 22:32 UTC (permalink / raw)
To: Thomas Gleixner
Cc: devicetree-discuss, LKML, Milton Miller, Andreas Schwab,
Rob Herring, Russell King, linuxppc-dev, LAK
In-Reply-To: <alpine.LFD.2.02.1204022324140.2542@ionos>
On Mon, 2012-04-02 at 23:27 +0200, Thomas Gleixner wrote:
> So it's covered by this section:
>
> mpic_set_irq_type()
>
> if (flow_type == IRQ_TYPE_NONE)
> if (mpic->senses && src < mpic->senses_count)
> flow_type = mpic->senses[src];
> if (flow_type == IRQ_TYPE_NONE)
> flow_type = IRQ_TYPE_LEVEL_LOW;
>
> And with IRQ_TYPE_NONE this is always going to end up with
> IRQ_TYPE_LEVEL_LOW simply because the only function which might set
> mpic->senses is mpic_set_default_senses(). And this function does not
> have a single caller .....
>
> /me scratches head
Something must have broken ... when converting from the device-tree we
should be calling xlate which should extract the polarity/sense from the
device-tree.
Now, afaik, IRQ_LEVEL_LOW is correct for PCI unless the interrupt is
inverted inside Apple ASIC which is possible... (it's not an external
PCI, it's a cell inside K2).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 22:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree-discuss, linux-kernel, Rob Herring, Andreas Schwab,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402215524.GM24211@n2100.arm.linux.org.uk>
On Mon, 2012-04-02 at 22:55 +0100, Russell King - ARM Linux wrote:
> Well, presumably someone is calling irq_set_irq_type() asking explicitly
> for IRQ_TYPE_NONE. The code will now (as it always used to before David's
> change) do exactly what you ask this to: it will ask the type to be set
> to none.
>
> If you don't want to set the type to none, don't call the interface asking
> for that to happen.
I think part of the idea with NONE is to use it as "reset that interrupt
to the "default" setting, whatever that means ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Russell King - ARM Linux @ 2012-04-02 22:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, linux-kernel, Rob Herring, Andreas Schwab,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1333406005.30734.61.camel@pasglop>
On Tue, Apr 03, 2012 at 08:33:25AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-02 at 22:55 +0100, Russell King - ARM Linux wrote:
> > Well, presumably someone is calling irq_set_irq_type() asking explicitly
> > for IRQ_TYPE_NONE. The code will now (as it always used to before David's
> > change) do exactly what you ask this to: it will ask the type to be set
> > to none.
> >
> > If you don't want to set the type to none, don't call the interface asking
> > for that to happen.
>
> I think part of the idea with NONE is to use it as "reset that interrupt
> to the "default" setting, whatever that means ...
No, it never was (anyone who thought that is plain wrong because that
wasn't my original design.)
NONE really did mean "I don't want any trigger level" for set_irq_type()
as it was originally designed on ARM, and there's a number of PCMCIA
socket drivers which rely on that behaviour: the reason is that with
edge triggered interrupts, Linux normally remembers edges which happen
with the interrupt disabled, and delivers those events when the interrupt
is re-enabled. There are situations (such as edge triggered status GPIOs)
where we _really_ do want to ignore transitions on an edge triggered
input. And PCMCIA soc_common uses set_irq_type() with NONE to do this.
The reason you can't request an interrupt with a NONE type is because
I saw that to be pointless - and in any case, the type is a bitmask and
NONE ended up being zero. Zero is also what you get with request_irq()
used with drivers which don't pass any IRQ trigger flags, so request_irq()
has to ignore this case.
Now, arguably, we could say that there should be an interface for clearing
pending edges in our interrupt model, but traditionally there hasn't been,
even when my ARM IRQ stuff was moved forward into genirq. However,
subsequently changing genirq in a way which breaks previously working
stuff is a regression, and that's what my revert addresses.
If we want to fix it a better way, then sure, that'll be good. But what
we shouldn't do is re-introduce one regression to fix a different
regression.
So, Thomas, what do you think about providing a way that a disabled
interrupt could have its pending status cleared such that when it's
enabled, any queued events are ignored? Maybe an enable_and_clear_irq() ?
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-02 23:38 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree-discuss, linux-kernel, Rob Herring, Andreas Schwab,
Milton Miller, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402225223.GN24211@n2100.arm.linux.org.uk>
On Mon, 2012-04-02 at 23:52 +0100, Russell King - ARM Linux wrote:
> If we want to fix it a better way, then sure, that'll be good. But
> what
> we shouldn't do is re-introduce one regression to fix a different
> regression.
>
> So, Thomas, what do you think about providing a way that a disabled
> interrupt could have its pending status cleared such that when it's
> enabled, any queued events are ignored? Maybe an
> enable_and_clear_irq() ?
Ok. Doesn't matter anyway, this shouldn't be the problem in this
specific case. IE. we shouldn't be setting that interrupt to NONE.
We should have parsed the device-tree and set the trigger appropriately.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Benjamin Herrenschmidt @ 2012-04-03 0:37 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree-discuss, linux-kernel, Rob Herring, Milton Miller,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <m2hax2qeqs.fsf@igel.home>
On Mon, 2012-04-02 at 18:29 +0200, Andreas Schwab wrote:
> > This breaks irqs on PowerMac G5. I see lost irq errors from the sata
> > driver.
>
> When I revert a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 ("genirq: Fix
> long-term regression in genirq irq_set_irq_type() handling") on top of
> 3.4-rc1 the sata irq errors disappear, but I see a lot of spurious
> interrupts. Also the X server is broken somehow, though I don't know
> whether that is related or a different bug.
I can't explain why but it works for me with your config on a similar
dual G5.
It would be interesting to figure out what causes the call to
set_irq_type(NONE)...
The SATA driver isn't doing anything. What should be happening
is that:
- pci_read_irq_line() in arch/powerpc/kernel/pci-common.c
This will call of_irq_map_pci() and then call irq_of_create_mapping()
with the result if it's successful (it should be).
- irq_of_create_mapping in kernel/irq/irqdomain.c
That should then call domain->ops->xlate() where domain is the domain
of the first MPIC (the one in K2), which should return your IRQ number
for the SATA controller (btw, it's 0, in case that matters, ie, HW irq 0
on MPIC 1 iirc) and the interrupt type. This is where you should
get IRQ_TYPE_LEVEL_LOW (i verified and that's what my device-tree
contains).
You can add printk's in there to see what's happening in your case ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/boot: Only build board support files when required.
From: Tony Breeds @ 2012-04-03 0:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev, Josh Boyer
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger
[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]
Currently we build all board files regardless of the final zImage
target. This is sub-optimal (in terms on compilation) and leads to
problems in one platform needlessly causing failures for other
platforms.
Use the Kconfig variables to selectively construct this board files to
build.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/boot/Makefile | 69 +++++++++++++++++++++++++++++++++-----------
1 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e8461cb..3d4d9ea 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -65,23 +65,58 @@ $(addprefix $(obj)/,$(libfdt) libfdt-wrapper.o simpleboot.o epapr.o): \
src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
$(libfdt) libfdt-wrapper.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
- gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
- 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
- fsl-soc.c mpc8xx.c pq2.c ugecon.c
-src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c cuboot-hotfoot.c epapr.c treeboot-ebony.c \
- prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
- cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
- fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \
- cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \
- virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
- cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c \
- gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c \
- treeboot-currituck.c
+ gunzip_util.c elf_util.c $(zlib) devtree.c stdlib.c \
+ oflib.c ofconsole.c cuboot.c mpsc.c cpm-serial.c \
+ uartlite.c mpc52xx-psc.c
+src-plat := of.c
+ifeq ($(CONFIG_40x),y)
+src-wlib += 4xx.c planetcore.c
+src-plat += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \
+ cuboot-acadia.c cuboot-kilauea.c \
+ simpleboot.c virtex405-head.S virtex.c
+endif
+ifeq ($(CONFIG_44x),y)
+src-wlib += 4xx.c ebony.c bamboo.c
+src-plat += treeboot-ebony cuboot-ebony treeboot-bamboo cuboot-bamboo \
+ cuboot-sam440ep.c cuboot-sequoia.c cuboot-rainier.c \
+ cuboot-taishan.c cuboot-katmai.c cuboot-warp.c \
+ cuboot-yosemite.c treeboot-iss4xx.c treeboot-currituck.c \
+ simpleboot.c fixed-head.S virtex.c
+endif
+ifeq ($(CONFIG_8xx),y)
+src-wlib += mpc8xx.c planetcore.c
+src-plat += cuboot-8xx.c fixed-head.S ep88xc.c redboot-8xx.c
+endif
+ifeq ($(CONFIG_PPC_MPC52xx),y)
+src-plat += cuboot-52xx.c
+endif
+ifeq ($(CONFIG_PPC_82xx),y)
+src-wlib += pq2.c fsl-soc.c
+src-plat += cuboot-pq2.c fixed-head.S ep8248e.c cuboot-824x.c
+endif
+ifeq ($(CONFIG_PPC_83xx),y)
+src-plat += cuboot-83xx.c fixed-head.S redboot-83xx.c
+endif
+ifeq ($(CONFIG_FSL_SOC_BOOKE),y)
+src-plat += cuboot-85xx.c cuboot-85xx-cpm2.c
+endif
+ifeq ($(CONFIG_EMBEDDED6xx),y)
+src-wlib += mv64x60.c mv64x60_i2c.c ugecon.c
+src-plat += cuboot-pq2.c cuboot-mpc7448hpc2.c cuboot-c2k.c \
+ gamecube-head.S gamecube.c wii-head.S wii.c holly.c \
+ prpmc2800.c
+endif
+ifeq ($(CONFIG_AMIGAONE),y)
+src-plat += cuboot-amigaone.c
+endif
+ifeq ($(CONFIG_PPC_PS3),y)
+src-plat += ps3-head.S ps3-hvcall.S ps3.c
+endif
+ifeq ($(CONFIG_EPAPR_BOOT),y)
+src-plat += epapr.c
+endif
+src-wlib := $(sort $(src-wlib))
+src-plat := $(sort $(src-plat))
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
--
1.7.7.6
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: David Gibson @ 2012-04-03 1:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, LinuxPPC-dev, Josh Boyer, Wolfgang Denk,
robert.karl.berger, Frank Svendsbøe
In-Reply-To: <20120403005558.GA9194@thor.bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
On Tue, Apr 03, 2012 at 10:55:59AM +1000, Tony Breeds wrote:
> Currently we build all board files regardless of the final zImage
> target. This is sub-optimal (in terms on compilation) and leads to
> problems in one platform needlessly causing failures for other
> platforms.
Um.. I believe the one platform breaking another is actually working
as intended. I think Paulus did it this way to stop people breaking
platforms other than the one they were working on without realising
it.
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Benjamin Herrenschmidt @ 2012-04-03 1:26 UTC (permalink / raw)
To: David Gibson
Cc: Frank Svendsbøe, LinuxPPC-dev, Wolfgang Denk,
robert.karl.berger
In-Reply-To: <20120403010002.GE7481@truffala.fritz.box>
On Tue, 2012-04-03 at 11:00 +1000, David Gibson wrote:
> On Tue, Apr 03, 2012 at 10:55:59AM +1000, Tony Breeds wrote:
> > Currently we build all board files regardless of the final zImage
> > target. This is sub-optimal (in terms on compilation) and leads to
> > problems in one platform needlessly causing failures for other
> > platforms.
>
> Um.. I believe the one platform breaking another is actually working
> as intended. I think Paulus did it this way to stop people breaking
> platforms other than the one they were working on without realising
> it.
But that doesn't make sense to enforce that accross CPU families since
they cannot be built together within a single kernel anyway...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Tony Breeds @ 2012-04-03 1:31 UTC (permalink / raw)
To: David Gibson
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
LinuxPPC-dev
In-Reply-To: <20120403010002.GE7481@truffala.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
On Tue, Apr 03, 2012 at 11:00:02AM +1000, David Gibson wrote:
> Um.. I believe the one platform breaking another is actually working
> as intended. I think Paulus did it this way to stop people breaking
> platforms other than the one they were working on without realising
> it.
Well that may have been the original intent but in the thread "Re:
kilauea compilation breaks with v3.3 kernel and ELDK 4.2" we're seeing
4xx break 8xx as the 8xx binutils (in use) doesn't have a mfdcrx
instruction.
So by breaking it up we gain a small decrease in compile times, less
chance of a very targeted build breaking an unrelated board. We do as
you point out potentially delay discovery of breakage for some time.
I don't mind either way but the patch is out there now :)
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Stephen Rothwell @ 2012-04-03 1:41 UTC (permalink / raw)
To: Tony Breeds
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
LinuxPPC-dev
In-Reply-To: <20120403005558.GA9194@thor.bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]
Hi Tony,
On Tue, 3 Apr 2012 10:55:59 +1000 Tony Breeds <tony@bakeyournoodle.com> wrote:
>
> arch/powerpc/boot/Makefile | 69 +++++++++++++++++++++++++++++++++-----------
> 1 files changed, 52 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index e8461cb..3d4d9ea 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -65,23 +65,58 @@ $(addprefix $(obj)/,$(libfdt) libfdt-wrapper.o simpleboot.o epapr.o): \
> src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
> $(libfdt) libfdt-wrapper.c \
> ns16550.c serial.c simple_alloc.c div64.S util.S \
> - gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
> - 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
> - cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
> - fsl-soc.c mpc8xx.c pq2.c ugecon.c
> -src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
> - cuboot-ebony.c cuboot-hotfoot.c epapr.c treeboot-ebony.c \
> - prpmc2800.c \
> - ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
> - cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
> - cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
> - fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \
> - cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
> - cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \
> - virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
> - cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c \
> - gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c \
> - treeboot-currituck.c
> + gunzip_util.c elf_util.c $(zlib) devtree.c stdlib.c \
> + oflib.c ofconsole.c cuboot.c mpsc.c cpm-serial.c \
> + uartlite.c mpc52xx-psc.c
> +src-plat := of.c
> +ifeq ($(CONFIG_40x),y)
> +src-wlib += 4xx.c planetcore.c
> +src-plat += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \
> + cuboot-acadia.c cuboot-kilauea.c \
> + simpleboot.c virtex405-head.S virtex.c
> +endif
It is more ususal in the kernel makefiles to do something like:
src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
src-plat-$(CONFIG_40x) += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \
...
and then use $(src-wlib-y) and $(src-plat-y)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Tony Breeds @ 2012-04-03 1:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
LinuxPPC-dev
In-Reply-To: <20120403114150.cbf53c999ed842b25e9932b5@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 4519 bytes --]
On Tue, Apr 03, 2012 at 11:41:50AM +1000, Stephen Rothwell wrote:
> It is more ususal in the kernel makefiles to do something like:
>
> src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
> src-plat-$(CONFIG_40x) += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \
Gah you are right. How about this.
From b59e3f86d72fe3e16881ec972602a9bb3e28045a Mon Sep 17 00:00:00 2001
From: Tony Breeds <tony@bakeyournoodle.com>
Date: Mon, 2 Apr 2012 16:20:35 +1000
Subject: [PATCH] powerpc/boot: Only build board support files when required.
Currently we build all board files regardless of the final zImage
target. This is sub-optimal (in terms on compilation) and leads to
problems in one platform needlessly causing failures for other
platforms.
Use the Kconfig variables to selectively construct this board files to
build.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/boot/Makefile | 57 +++++++++++++++++++++++++++++--------------
1 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e8461cb..a05d32d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,27 +62,46 @@ libfdtheader := fdt.h libfdt.h libfdt_internal.h
$(addprefix $(obj)/,$(libfdt) libfdt-wrapper.o simpleboot.o epapr.o): \
$(addprefix $(obj)/,$(libfdtheader))
-src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
+src-wlib-y := string.S crt0.S crtsavres.S stdio.c main.c \
$(libfdt) libfdt-wrapper.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
- gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
- 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
- fsl-soc.c mpc8xx.c pq2.c ugecon.c
-src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c cuboot-hotfoot.c epapr.c treeboot-ebony.c \
- prpmc2800.c \
- ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
- cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
- fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \
- cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \
- virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
- cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c \
- gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c \
- treeboot-currituck.c
-src-boot := $(src-wlib) $(src-plat) empty.c
+ gunzip_util.c elf_util.c $(zlib) devtree.c stdlib.c \
+ oflib.c ofconsole.c cuboot.c mpsc.c cpm-serial.c \
+ uartlite.c mpc52xx-psc.c
+src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
+src-wlib-$(CONFIG_44x) += 4xx.c ebony.c bamboo.c
+src-wlib-$(CONFIG_8xx) += mpc8xx.c planetcore.c
+src-wlib-$(CONFIG_PPC_82xx) += pq2.c fsl-soc.c
+src-wlib-$(CONFIG_EMBEDDED6xx) += mv64x60.c mv64x60_i2c.c ugecon.c
+
+src-plat-y := of.c
+src-plat-$(CONFIG_40x) += fixed-head.S ep405.c cuboot-hotfoot.c \
+ treeboot-walnut.c cuboot-acadia.c \
+ cuboot-kilauea.c simpleboot.c \
+ virtex405-head.S virtex.c
+src-plat-$(CONFIG_44x) += treeboot-ebony cuboot-ebony treeboot-bamboo \
+ cuboot-bamboo cuboot-sam440ep.c \
+ cuboot-sequoia.c cuboot-rainier.c \
+ cuboot-taishan.c cuboot-katmai.c \
+ cuboot-warp.c cuboot-yosemite.c \
+ treeboot-iss4xx.c treeboot-currituck.c \
+ simpleboot.c fixed-head.S virtex.c
+src-plat-$(CONFIG_8xx) += cuboot-8xx.c fixed-head.S ep88xc.c redboot-8xx.c
+src-plat-$(CONFIG_PPC_MPC52xx) += cuboot-52xx.c
+src-plat-$(CONFIG_PPC_82xx) += cuboot-pq2.c fixed-head.S ep8248e.c cuboot-824x.c
+src-plat-$(CONFIG_PPC_83xx) += cuboot-83xx.c fixed-head.S redboot-83xx.c
+src-plat-$(CONFIG_FSL_SOC_BOOKE) += cuboot-85xx.c cuboot-85xx-cpm2.c
+src-plat-$(CONFIG_EMBEDDED6xx) += cuboot-pq2.c cuboot-mpc7448hpc2.c \
+ cuboot-c2k.c gamecube-head.S \
+ gamecube.c wii-head.S wii.c holly.c \
+ prpmc2800.c
+src-plat-$(CONFIG_AMIGAONE) += cuboot-amigaone.c
+src-plat-$(CONFIG_PPC_PS3) += ps3-head.S ps3-hvcall.S ps3.c
+src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c
+
+src-wlib := $(sort $(src-wlib-y))
+src-plat := $(sort $(src-plat-y))
+src-boot := $(src-wlib-y) $(src-plat-y) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
obj-boot := $(addsuffix .o, $(basename $(src-boot)))
--
1.7.7.6
Yours Tony
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: Only build board support files when required.
From: Stephen Rothwell @ 2012-04-03 1:57 UTC (permalink / raw)
To: Tony Breeds
Cc: Frank Svendsbøe, Wolfgang Denk, robert.karl.berger,
LinuxPPC-dev
In-Reply-To: <20120403015508.GC9194@thor.bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi Tony,
On Tue, 3 Apr 2012 11:55:08 +1000 Tony Breeds <tony@bakeyournoodle.com> wrote:
>
> On Tue, Apr 03, 2012 at 11:41:50AM +1000, Stephen Rothwell wrote:
>
> > It is more ususal in the kernel makefiles to do something like:
> >
> > src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
> > src-plat-$(CONFIG_40x) += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \
>
> Gah you are right. How about this.
Looks better to me.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] [v1] powerpc/44x: Support CPM for Maui APM821xxx SoC and Bluestone board
From: Mai La @ 2012-04-03 3:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: Mai La
In this patch:
- Add CPM node for Maui APM821xxx SoC and Bluestone board in DTS
Signed-off-by: Mai La <mla@apm.com>
---
v1:
Per Grant Likely's comment:
* Fix typo
---
arch/powerpc/boot/dts/bluestone.dts | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..15a9516 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -117,6 +117,15 @@
dcr-reg = <0x00c 0x002>;
};
+ CPM0: cpm {
+ compatible = "ibm,cpm-apm821xx", "ibm,cpm";
+ cell-index = <0>;
+ dcr-reg = <0x160 0x003>;
+ er-offset = <0>;
+ idle-doze = <0x02000000>;
+ standby = <0x302570F0>;
+ };
+
plb {
compatible = "ibm,plb4";
#address-cells = <2>;
--
1.7.3.4
^ permalink raw reply related
* 3.4.0-rc1: No init found
From: Christian Kujau @ 2012-04-03 7:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: LKML
Going from 3.3-rc7 to 3.4-rc1 (with "make oldconfig" inbetween) did not
go well on this PowerBook G4 machine:
Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted filesystem with ordered data mode. Opts: (null)
Apr 2 15:18:23 [ 8.320286] VFS: Mounted root (ext4 filesystem) readonly on device 3:6.
Apr 2 15:18:23 [ 8.341555] devtmpfs: mounted
Apr 2 15:18:23 [ 8.343384] Freeing unused kernel memory: 204k freed
Apr 2 15:18:23 [ 8.457056] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
Apr 2 15:18:23 [ 8.459936] Rebooting in 180 seconds..
No bootoptions were changed, no disks swapped, no partitions altered
whatsoever. Full .config & dmesg:
http://nerdbynature.de/bits/3.4.0-rc1/init/
Thanks,
Christian.
PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
right now (which is still installed via "yaboot" and present in
/boot), because of this:
http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
Booting into Debian's "squeeze" kernel (2.6.32) which resides in
the same /boot directory succeeds.
--
BOFH excuse #334:
50% of the manual is in .pdf readme files
^ permalink raw reply
* Re: 3.4.0-rc1: No init found
From: Benjamin Herrenschmidt @ 2012-04-03 8:08 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, LKML, Al Viro
In-Reply-To: <alpine.DEB.2.01.1204030008080.4930@trent.utfs.org>
On Tue, 2012-04-03 at 00:20 -0700, Christian Kujau wrote:
> Going from 3.3-rc7 to 3.4-rc1 (with "make oldconfig" inbetween) did not
> go well on this PowerBook G4 machine:
>
> Apr 2 15:18:23 [ 8.318816] EXT4-fs (hda6): mounted filesystem with ordered data mode. Opts: (null)
> Apr 2 15:18:23 [ 8.320286] VFS: Mounted root (ext4 filesystem) readonly on device 3:6.
> Apr 2 15:18:23 [ 8.341555] devtmpfs: mounted
> Apr 2 15:18:23 [ 8.343384] Freeing unused kernel memory: 204k freed
> Apr 2 15:18:23 [ 8.457056] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
> Apr 2 15:18:23 [ 8.459936] Rebooting in 180 seconds..
I have observed this randomly on the G5 ... sometimes, if I try again,
it works... it's very very odd. There is some kind of race maybe with
async startup ? Or a problem with the vfs path walking ? It's certainly
not easily reproducable for me, it goes away from one boot to the next.
It also happens sometimes with an initramfs (cpio), it's not specific to
ext{2,3,4}.
Cheers,
Ben.
> No bootoptions were changed, no disks swapped, no partitions altered
> whatsoever. Full .config & dmesg:
>
> http://nerdbynature.de/bits/3.4.0-rc1/init/
>
> Thanks,
> Christian.
>
> PS: Unfortunately I cannot boot into the old (3.3-rc7) kernel
> right now (which is still installed via "yaboot" and present in
> /boot), because of this:
> http://nerdbynature.de/bits/3.4.0-rc1/init/mac-invalid-memory.JPG
> Booting into Debian's "squeeze" kernel (2.6.32) which resides in
> the same /boot directory succeeds.
Hrm, did it used to boot ? Can you do printenv in OF and tell me what
your load-base, real-base, virt-base etc... are ?
Might also be worth updating yaboot, debian should have 1.3.16 nowadays.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Thomas Gleixner @ 2012-04-03 8:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Russell King - ARM Linux, devicetree-discuss, linux-kernel,
Milton Miller, Andreas Schwab, Rob Herring, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1333406005.30734.61.camel@pasglop>
On Tue, 3 Apr 2012, Benjamin Herrenschmidt wrote:
> On Mon, 2012-04-02 at 22:55 +0100, Russell King - ARM Linux wrote:
> > Well, presumably someone is calling irq_set_irq_type() asking explicitly
> > for IRQ_TYPE_NONE. The code will now (as it always used to before David's
> > change) do exactly what you ask this to: it will ask the type to be set
> > to none.
> >
> > If you don't want to set the type to none, don't call the interface asking
> > for that to happen.
>
> I think part of the idea with NONE is to use it as "reset that interrupt
> to the "default" setting, whatever that means ...
Well, the ship side set_type function could simply leave it alone and
not touch the thing at all. That's how the core code did until we
discovered that we broke Russells toys that way.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v5 06/27] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
From: Thomas Gleixner @ 2012-04-03 8:23 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree-discuss, linux-kernel, Milton Miller, Andreas Schwab,
Rob Herring, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120402225223.GN24211@n2100.arm.linux.org.uk>
On Mon, 2 Apr 2012, Russell King - ARM Linux wrote:
> If we want to fix it a better way, then sure, that'll be good. But what
> we shouldn't do is re-introduce one regression to fix a different
> regression.
>
> So, Thomas, what do you think about providing a way that a disabled
> interrupt could have its pending status cleared such that when it's
> enabled, any queued events are ignored? Maybe an enable_and_clear_irq() ?
We can make it a flag, which you can either add to the irq itself or
hand it in on request_irq().
Does that require a special chip->callback() function as well ?
Thanks,
tglx
^ 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