* Re: Build regressions/improvements in v3.10-rc5
From: Anca Emanuel @ 2013-06-10 14:37 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development, Linux Kernel Development
In-Reply-To: <alpine.DEB.2.00.1306100924570.22024@ayla.of.borg>
The relevant maintainers do not get a copy of this.
On Mon, Jun 10, 2013 at 10:25 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
>> JFYI, when comparing v3.10-rc5 to v3.10-rc4[3], the summaries are:
>> - build errors: +19/-10
>> [1] http://kisskb.ellerman.id.au/kisskb/head/6308/ (all 120 configs)
>
> + arch/powerpc/kernel/cacheinfo.c: error: 'associativity' may be used uninitialized in this function [-Werror=uninitialized]: => 571:16
> + arch/powerpc/kernel/cacheinfo.c: error: 'size_kb' may be used uninitialized in this function [-Werror=uninitialized]: => 522:16
> + arch/powerpc/kernel/pci_dn.c: error: 'ret' may be used uninitialized in this function [-Werror=uninitialized]: => 97:8
> + arch/powerpc/kvm/book3s_32_mmu.c: error: 'sr' may be used uninitialized in this function [-Werror=uninitialized]: => 63:2
> + arch/powerpc/kvm/book3s_64_mmu.c: error: 'slb' may be used uninitialized in this function [-Werror=uninitialized]: => 485:3
> + arch/powerpc/mm/hash_native_64.c: error: 'a_size' may be used uninitialized in this function [-Werror=uninitialized]: => 67:31
> + arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when assigning to type 'kgid_t' from type 'int': => 628:16
> + arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when assigning to type 'kuid_t' from type 'int': => 623:16
> + arch/powerpc/platforms/pseries/msi.c: error: 'total' may be used uninitialized in this function [-Werror=uninitialized]: => 320:24
> + arch/powerpc/platforms/pseries/pci.c: error: 'pcie_link_speed_stats' may be used uninitialized in this function [-Werror=uninitialized]: => 150:31
>
> powerpc-randconfig
>
>> [3] http://kisskb.ellerman.id.au/kisskb/head/6290/ (all 120 configs)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: PowerPC assembler question
From: David Laight @ 2013-06-10 12:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20130610211439.a69d2b26ee216f34caf473bd@mega-nerd.com>
> > Note: It's more readable if you use the register names, ie:
> >
> > lwz %r30, .label - (1b)(%r31)
> >
> > The form of lwz is
> >
> > lwz dest_reg, offset(address_reg)
> >
> > So it will load a 32-bit value from memory at the address contained =
in
> > r31 offset by ".label - 1b" which is itself the difference between
> > two labels, "label", and the first "1:" label before the instruction
...
> Is there something I could replace this above lwz instruction with
> that would work for PIC with offsets greater than +/- 32k?
With a scratch register there are some two instruction sequences.
Reusing the destination register something like:
addis %r30,%r31,hi(.label - 1b)
lwzx %r30,lo(.label - 1b)(%r30)
(Not sure of the hi()/lo() functions for ppc!)
It is even possible that there are some macros for the
assembler that will do this automatically - %r1 might
even be reserved for the purpose (as it is on MIPS).
David
^ permalink raw reply
* Re: [BUG] PCI related panic on powerpc based board with 3.10-rcX
From: Rojhalat Ibrahim @ 2013-06-10 11:41 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <CALG0vJu9-640D=Q-2RoSOnWtR=sERwj0fSCibK+ijprcf-T6Ag@mail.gmail.com>
Hi Mike,
could you please try this patch:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-May/106624.html
http://patchwork.ozlabs.org/patch/244515/
Rojhalat
On Saturday 08 June 2013 21:39:37 Michael Guntsche wrote:
> After bisecting I found the responsible commit.
>
> 50d8f87d2b3: powerpc/fsl-pci Make PCIe hotplug work with Freescale
> PCIe controllers
>
> Reverting this commit allowed my board to boot again.
>
> @Rojhalat: Please have a look at
> http://marc.info/?l=linux-kernel&m=137071294204858&w=2
> for my initial bugreport.
>
> What I do not understand at all is why this is affecting my platform.
> AFAIK there is no PCIe hardware on it AND I completely disabled PCIe
> support in config.
>
> Kind regards,
> Mike
^ permalink raw reply
* Re: PowerPC assembler question
From: Erik de Castro Lopo @ 2013-06-10 11:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1370820095.14883.45.camel@pasglop>
Benjamin Herrenschmidt wrote:
> No, this loads a 32-bit value (16-bit would be lhz).
My understanding so far (which may be wrong) is that it loads a
32 bit value but it loads it from a memory location that needs
to be within +/- 32k of the instriction doing the load.
The reason I think this is because when this generated code is
compiled I get the error:
/tmp/ghc2806_0/ghc2806_1.s:51766:0:
Error: operand out of range (0x000000000000adf8 is not between
0xffffffffffff8000 and 0x0000000000007fff)
which suggests a 16 bit offset.
Btw, this is code generated by the Glasgow Haskell Compiler (GHC). The
GHC bug is here:
http://hackage.haskell.org/trac/ghc/ticket/7830
> Note: It's more readable if you use the register names, ie:
>
> lwz %r30, .label - (1b)(%r31)
>
> The form of lwz is
>
> lwz dest_reg, offset(address_reg)
>
> So it will load a 32-bit value from memory at the address contained in
> r31 offset by ".label - 1b" which is itself the difference between
> two labels, "label", and the first "1:" label before the instruction
>
> (gcc supports numeric labels that can be referenced with the suffix "b"
> for backward and "f" for forward which are handy for small
> displacements)
Ahh, that would be +/- 32k!
> So for example if 1: was the base of the structure and .label a field
> in the structure, it would load the 32-bit value of that field for the
> structure instance starting at %r31.
>
> In this case, this looks more like some kind of position-independent
> code though.
That would definitely make sense.
Is there something I could replace this above lwz instruction with
that would work for PIC with offsets greater than +/- 32k?
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
^ permalink raw reply
* Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
From: Grant Likely @ 2013-06-10 10:50 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Arnd Bergmann, linux-kernel@vger.kernel.org,
Thomas Gleixner, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <CACRpkda+WD5dMoZ9s7mTLgOgUrm+EH3Mqxio=BuLTDr3aOEruw@mail.gmail.com>
On Mon, Jun 10, 2013 at 8:40 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely <grant.likely@linaro.org> wrote:
>
>> This is an RFC patch to convert the versatile FPGA irq controller driver
>> to use generic irq chip. It builds on the series that extends the
>> generic chip code to allow a linear irq domain to contain one or more
>> generic irq chips so that each interrupt controller doesn't need to hand
>> code the generic chip setup.
>>
>> I've written this as a proof of concept to see if the new generic irq
>> code does what it needs to. I had to extend it slightly to properly
>> handle the valid mask used by the versatile FPGA driver.
>>
>> Tested on QEMU, but not on real hardware.
>
> Is this the same as the one I tested previously?
>
> If it need re-testing please push a branch and I'll take it
> for a spin.
Yes, it's the same, but if you can test the branch I would appreciate
it. I've done some heavy rework on the irqdomain code that makes
everything simpler, but also makes it likely that I've broken
something.
git://git.secretlab.ca/git/linux.git irqdomain/test
g.
^ permalink raw reply
* Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
From: Grant Likely @ 2013-06-10 10:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Arnd Bergmann, Linus Walleij, Linux Kernel Mailing List,
Thomas Gleixner, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130610090357.GQ18614@n2100.arm.linux.org.uk>
On Mon, Jun 10, 2013 at 10:03 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jun 10, 2013 at 01:49:22AM +0100, Grant Likely wrote:
>> This is an RFC patch to convert the versatile FPGA irq controller driver
>> to use generic irq chip. It builds on the series that extends the
>> generic chip code to allow a linear irq domain to contain one or more
>> generic irq chips so that each interrupt controller doesn't need to hand
>> code the generic chip setup.
>
> NAK, this makes functional changes. You assume that the validity mask is
> a set of zeros followed by a set of ones. This is not always the case.
> The PIC on Integrator/CP only has bits 29-22 and 11-0 set because 21-12
> are not valid.
Actually, I don't (at least I don't intend to). It chooses the size of
the irq_domain based on fls(), but that is only because the size has
to allocates for both the holes and the active irqs. You'll notice
that gc->unused is set to ~valid, and the generic chip code will
refuse to map in interrupt that isn't supported. If you see something
different, please point out where because that would be a bug.
g.
^ permalink raw reply
* Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
From: Russell King - ARM Linux @ 2013-06-10 9:03 UTC (permalink / raw)
To: Grant Likely
Cc: Arnd Bergmann, Linus Walleij, linux-kernel, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <1370825362-11145-11-git-send-email-grant.likely@linaro.org>
On Mon, Jun 10, 2013 at 01:49:22AM +0100, Grant Likely wrote:
> This is an RFC patch to convert the versatile FPGA irq controller driver
> to use generic irq chip. It builds on the series that extends the
> generic chip code to allow a linear irq domain to contain one or more
> generic irq chips so that each interrupt controller doesn't need to hand
> code the generic chip setup.
NAK, this makes functional changes. You assume that the validity mask is
a set of zeros followed by a set of ones. This is not always the case.
The PIC on Integrator/CP only has bits 29-22 and 11-0 set because 21-12
are not valid.
^ permalink raw reply
* [PATCH] powerpc/mpc512x: add MPC5125 reset module support for system restart
From: Matteo Facchinetti @ 2013-06-10 8:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: agust
Only part of MPC5125 reset module is like as MPC5121.
In detail, RCWH register doesn't contain informations about:
- PCI arbiter
- NAND flash page size
- NAND flash port size
For this reason, in device tree, this module has a different name then
MPC5121 reset module but use the same "struct mpc512x_reset_module"
register definition and the same restart procedure.
Signed-off-by: Matteo Facchinetti <engineering@sirius-es.it>
---
arch/powerpc/platforms/512x/mpc512x.h | 1 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 15 ++++++++++++++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
index fdb4303..cc97f02 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -17,6 +17,7 @@ extern void __init mpc512x_init(void);
extern void __init mpc512x_setup_arch(void);
extern int __init mpc5121_clk_init(void);
extern const char *mpc512x_select_psc_compat(void);
+extern const char *mpc512x_select_reset_compat(void);
extern void mpc512x_restart(char *cmd);
#endif /* __MPC512X_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index a8b5110..a82a41b 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -35,8 +35,10 @@ static struct mpc512x_reset_module __iomem *reset_module_base;
static void __init mpc512x_restart_init(void)
{
struct device_node *np;
+ const char *reset_compat;
- np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-reset");
+ reset_compat = mpc512x_select_reset_compat();
+ np = of_find_compatible_node(NULL, NULL, reset_compat);
if (!np)
return;
@@ -355,6 +357,17 @@ const char *mpc512x_select_psc_compat(void)
return NULL;
}
+const char *mpc512x_select_reset_compat(void)
+{
+ if (of_machine_is_compatible("fsl,mpc5121"))
+ return "fsl,mpc5121-reset";
+
+ if (of_machine_is_compatible("fsl,mpc5125"))
+ return "fsl,mpc5125-reset";
+
+ return NULL;
+}
+
static unsigned int __init get_fifo_size(struct device_node *np,
char *prop_name)
{
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 1/2] perf/Power7: Save dcache_src fields in sample record.
From: Anshuman Khandual @ 2013-06-10 8:03 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Anton Blanchard, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, mingo
In-Reply-To: <20130607204008.GA3281@us.ibm.com>
>
> AFAICT, Power7 supports one extra level in the cache-hierarchy, so we propose
> to add a new cache level, REM_CCE3 shown above.
>
> To maintain consistency in terminology (i.e 2-hops = remote, 3-hops = distant),
> I propose leaving the REM_MEM1 unused and adding another level, REM_MEM3.
>
Agreed.
> Further, in the above REM_CCE1 case, Power7 can also identify if the data came
> from the L2 or L3 cache of another core on the same chip. To describe this to
> user space, we propose to set ->mem_lvl to:
>
> PERF_MEM_LVL_REM_CCE1|PERF_MEM_LVL_L2
>
> PERF_MEM_LVL_REM_CCE1|PERF_MEM_LVL_L3
>
> Either that or we could leave REM_CCE1 unused in Power and add two more levels:
>
> PERF_MEM_XLVL_REM_L2_CCE1
> PERF_MEM_XLVL_REM_L3_CCE1
>
> The former approach seems less confusing and this patch uses that approach.
>
Yeah, the former approach is simpler and makes sense.
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/perf_event_server.h | 2 +
> arch/powerpc/perf/core-book3s.c | 4 +
> arch/powerpc/perf/power7-pmu.c | 81 ++++++++++++++++++++++++++
> include/uapi/linux/perf_event.h | 12 +++-
> 4 files changed, 97 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
> index f265049..f2d162b 100644
> --- a/arch/powerpc/include/asm/perf_event_server.h
> +++ b/arch/powerpc/include/asm/perf_event_server.h
> @@ -37,6 +37,8 @@ struct power_pmu {
> void (*config_bhrb)(u64 pmu_bhrb_filter);
> void (*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
> int (*limited_pmc_event)(u64 event_id);
> + void (*get_mem_data_src)(struct perf_sample_data *data,
> + struct pt_regs *regs);
> u32 flags;
> const struct attribute_group **attr_groups;
> int n_generic;
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 426180b..7778fa9 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -1632,6 +1632,10 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
> data.br_stack = &cpuhw->bhrb_stack;
> }
>
> + if (event->attr.sample_type & PERF_SAMPLE_DATA_SRC &&
> + ppmu->get_mem_data_src)
> + ppmu->get_mem_data_src(&data, regs);
> +
> if (perf_event_overflow(event, &data, regs))
> power_pmu_stop(event, 0);
> }
> diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
> index 3c475d6..af92bfe 100644
> --- a/arch/powerpc/perf/power7-pmu.c
> +++ b/arch/powerpc/perf/power7-pmu.c
> @@ -209,6 +209,85 @@ static int power7_get_alternatives(u64 event, unsigned int flags, u64 alt[])
> return nalt;
> }
>
> +#define POWER7_MMCRA_PEMPTY (0x1L << 63)
> +#define POWER7_MMCRA_FIN_STALL (0x1L << 62)
> +#define POWER7_MMCRA_CMPL_STALL (0x1L << 61)
> +#define POWER7_MMCRA_STALL_REASON_MASK (0xFL << 60)
> +
> +#define POWER7_MMCRA_DCACHE_MISS (0x1L << 55)
> +
> +#define POWER7_MMCRA_DCACHE_SRC_SHIFT 51
> +#define POWER7_MMCRA_DCACHE_SRC_MASK (0xFL << POWER7_MMCRA_DCACHE_SRC_SHIFT)
> +
> +#define POWER7_MMCRA_MDTLB_MISS (0x1L << 50)
> +
> +#define POWER7_MMCRA_MDTLB_SRC_SHIFT 46
> +#define POWER7_MMCRA_MDTLB_SRC_MASK (0xFL << POWER7_MMCRA_MDTLB_SRC_SHIFT)
> +
> +#define POWER7_MMCRA_MDERAT_MISS (0x1L<< 45)
> +#define POWER7_MMCRA_MLSU_REJ (0x1L<< 44)
> +
> +/* and so on */
> +
> +/*
> + * Map DCACHE_SRC fields to the Linux memory hierarchy levels.
> + *
> + * Bits 9..12 in the MMCRA indicate the source of a data-cache entry, with
> + * each of the 16 possible values referring to a specific source. Eg: if
> + * the 4-bits have the value 1 (0b0001), the dcache entry was found local
> + * L3 cache.
> + *
> + * We use the table, dcache_src_map, to map this value 1 to PERF_MEM_LVL_L3,
> + * the arch-neutral representation of the L3 cache.
> + *
> + * Similarly, in case of marked data TLB miss, bits 14..17 of the MMCRA
> + * indicate the load source of a marked DTLB entry. dtlb_src_map[] gives
> + * the mapping to the arch-neutral values of the TLB source.
Where did you define dtlb_src_map[] ?
^ permalink raw reply
* Re: [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
From: Linus Walleij @ 2013-06-10 7:40 UTC (permalink / raw)
To: Grant Likely
Cc: Russell King, Arnd Bergmann, linux-kernel@vger.kernel.org,
Thomas Gleixner, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1370825362-11145-11-git-send-email-grant.likely@linaro.org>
On Mon, Jun 10, 2013 at 2:49 AM, Grant Likely <grant.likely@linaro.org> wrote:
> This is an RFC patch to convert the versatile FPGA irq controller driver
> to use generic irq chip. It builds on the series that extends the
> generic chip code to allow a linear irq domain to contain one or more
> generic irq chips so that each interrupt controller doesn't need to hand
> code the generic chip setup.
>
> I've written this as a proof of concept to see if the new generic irq
> code does what it needs to. I had to extend it slightly to properly
> handle the valid mask used by the versatile FPGA driver.
>
> Tested on QEMU, but not on real hardware.
Is this the same as the one I tested previously?
If it need re-testing please push a branch and I'll take it
for a spin.
Yours.
Linus Walleij
^ permalink raw reply
* Re: Build regressions/improvements in v3.10-rc5
From: Geert Uytterhoeven @ 2013-06-10 7:25 UTC (permalink / raw)
To: Linux Kernel Development; +Cc: Linux/PPC Development
In-Reply-To: <alpine.DEB.2.00.1306100922530.21948@ayla.of.borg>
On Mon, 10 Jun 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.10-rc5 to v3.10-rc4[3], the summaries are:
> - build errors: +19/-10
> [1] http://kisskb.ellerman.id.au/kisskb/head/6308/ (all 120 configs)
+ arch/powerpc/kernel/cacheinfo.c: error: 'associativity' may be used uninitialized in this function [-Werror=uninitialized]: => 571:16
+ arch/powerpc/kernel/cacheinfo.c: error: 'size_kb' may be used uninitialized in this function [-Werror=uninitialized]: => 522:16
+ arch/powerpc/kernel/pci_dn.c: error: 'ret' may be used uninitialized in this function [-Werror=uninitialized]: => 97:8
+ arch/powerpc/kvm/book3s_32_mmu.c: error: 'sr' may be used uninitialized in this function [-Werror=uninitialized]: => 63:2
+ arch/powerpc/kvm/book3s_64_mmu.c: error: 'slb' may be used uninitialized in this function [-Werror=uninitialized]: => 485:3
+ arch/powerpc/mm/hash_native_64.c: error: 'a_size' may be used uninitialized in this function [-Werror=uninitialized]: => 67:31
+ arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when assigning to type 'kgid_t' from type 'int': => 628:16
+ arch/powerpc/platforms/cell/spufs/inode.c: error: incompatible types when assigning to type 'kuid_t' from type 'int': => 623:16
+ arch/powerpc/platforms/pseries/msi.c: error: 'total' may be used uninitialized in this function [-Werror=uninitialized]: => 320:24
+ arch/powerpc/platforms/pseries/pci.c: error: 'pcie_link_speed_stats' may be used uninitialized in this function [-Werror=uninitialized]: => 150:31
powerpc-randconfig
> [3] http://kisskb.ellerman.id.au/kisskb/head/6290/ (all 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V3 2/2] powerpc, perf: BHRB filter configuration should follow the task
From: Anshuman Khandual @ 2013-06-10 5:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey
In-Reply-To: <1370843609-32618-1-git-send-email-khandual@linux.vnet.ibm.com>
When the task moves around the system, the corresponding cpuhw
per cpu strcuture should be popullated with the BHRB filter
request value so that PMU could be configured appropriately with
that during the next call into power_pmu_enable().
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 426180b..48c68a8 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1122,8 +1122,11 @@ nocheck:
ret = 0;
out:
- if (has_branch_stack(event))
+ if (has_branch_stack(event)) {
power_pmu_bhrb_enable(event);
+ cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
+ event->attr.branch_sample_type);
+ }
perf_pmu_enable(event->pmu);
local_irq_restore(flags);
--
1.7.11.7
^ permalink raw reply related
* [PATCH V3 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request
From: Anshuman Khandual @ 2013-06-10 5:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey
In-Reply-To: <1370843609-32618-1-git-send-email-khandual@linux.vnet.ibm.com>
Completely ignore BHRB privilege state filter request as we are
already configuring that with privilege state filtering attribute
for the accompanying PMU event. This would help achieve cleaner
user space interaction for BHRB.
This patch fixes a situation like this
Before patch:-
------------
./perf record -j any -e branch-misses:k ls
Error:
The sys_perf_event_open() syscall returned with 95 (Operation not
supported) for event (branch-misses:k).
/bin/dmesg may provide additional information.
No CONFIG_PERF_EVENTS=y kernel support configured?
Here 'perf record' actually copies over ':k' filter request into BHRB
privilege state filter config and our previous check in kernel would
fail that.
After patch:-
-------------
./perf record -j any -e branch-misses:k ls
perf perf.data perf.data.old test-mmap-ring
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~102 samples)]
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/perf/power8-pmu.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index f7d1c4f..371c6e7 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -523,18 +523,13 @@ static int power8_generic_events[] = {
static u64 power8_bhrb_filter_map(u64 branch_sample_type)
{
u64 pmu_bhrb_filter = 0;
- u64 br_privilege = branch_sample_type & ONLY_PLM;
- /* BHRB and regular PMU events share the same prvillege state
+ /* BHRB and regular PMU events share the same privilege state
* filter configuration. BHRB is always recorded along with a
- * regular PMU event. So privilege state filter criteria for BHRB
- * and the companion PMU events has to be the same. As a default
- * "perf record" tool sets all privillege bits ON when no filter
- * criteria is provided in the command line. So as along as all
- * privillege bits are ON or they are OFF, we are good to go.
+ * regular PMU event. As the privilege state filter is handled
+ * in the basic PMC configuration of the accompanying regular
+ * PMU event, we ignore any separate BHRB specific request.
*/
- if ((br_privilege != 7) && (br_privilege != 0))
- return -1;
/* No branch filter requested */
if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY)
--
1.7.11.7
^ permalink raw reply related
* [PATCH V3 0/2] Improvement and fixes for BHRB
From: Anshuman Khandual @ 2013-06-10 5:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey
(1) The first patch fixes a situation like this
Before patch:-
------------
./perf record -j any -e branch-misses:k ls
Error:
The sys_perf_event_open() syscall returned with 95 (Operation not supported) for event (branch-misses:k).
/bin/dmesg may provide additional information.
No CONFIG_PERF_EVENTS=y kernel support configured?
Here 'perf record' actually copies over ':k' filter request into BHRB
privilege state filter config and our previous check in kernel would
fail that.
After patch:-
-------------
/perf record -j any -e branch-misses:k ls
perf perf.data perf.data.old test-mmap-ring
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~102 samples) ]
(2) The second patch fixes context migration for BHRB filter configuration
Changes in V2
-------------
(1) Updated the comment section of the code
(2) Removed the informational print
(3) Updated the commit section of the first patch
Changes in V3
-------------
(1) Fixed the compilation warning problem after removing the unused variable
Anshuman Khandual (2):
powerpc, perf: Ignore separate BHRB privilege state filter request
powerpc, perf: BHRB filter configuration should follow the task
arch/powerpc/perf/core-book3s.c | 5 ++++-
arch/powerpc/perf/power8-pmu.c | 13 ++++---------
2 files changed, 8 insertions(+), 10 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [PATCH V3 2/2] powerpc, perf: BHRB filter configuration should follow the task
From: Anshuman Khandual @ 2013-06-10 5:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey
In-Reply-To: <1370841910-28695-1-git-send-email-khandual@linux.vnet.ibm.com>
When the task moves around the system, the corresponding cpuhw
per cpu strcuture should be popullated with the BHRB filter
request value so that PMU could be configured appropriately with
that during the next call into power_pmu_enable().
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 426180b..48c68a8 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1122,8 +1122,11 @@ nocheck:
ret = 0;
out:
- if (has_branch_stack(event))
+ if (has_branch_stack(event)) {
power_pmu_bhrb_enable(event);
+ cpuhw->bhrb_filter = ppmu->bhrb_filter_map(
+ event->attr.branch_sample_type);
+ }
perf_pmu_enable(event->pmu);
local_irq_restore(flags);
--
1.7.11.7
^ permalink raw reply related
* [PATCH V3 0/2] Improvement and fixes for BHRB
From: Anshuman Khandual @ 2013-06-10 5:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey
(1) The first patch fixes a situation like this
Before patch:-
------------
./perf record -j any -e branch-misses:k ls
Error:
The sys_perf_event_open() syscall returned with 95 (Operation not supported) for event (branch-misses:k).
/bin/dmesg may provide additional information.
No CONFIG_PERF_EVENTS=y kernel support configured?
Here 'perf record' actually copies over ':k' filter request into BHRB
privilege state filter config and our previous check in kernel would
fail that.
After patch:-
-------------
/perf record -j any -e branch-misses:k ls
perf perf.data perf.data.old test-mmap-ring
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~102 samples) ]
(2) The second patch fixes context migration for BHRB filter configuration
Changes in V2
-------------
(1) Updated the comment section of the code
(2) Removed the informational print
(3) Updated the commit section of the first patch
Changes in V3
-------------
(1) Fixed the compilation warning problem after removing the unused variable
Anshuman Khandual (2):
powerpc, perf: Ignore separate BHRB privilege state filter request
powerpc, perf: BHRB filter configuration should follow the task
arch/powerpc/perf/core-book3s.c | 5 ++++-
arch/powerpc/perf/power8-pmu.c | 13 ++++---------
2 files changed, 8 insertions(+), 10 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [PATCH V3 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request
From: Anshuman Khandual @ 2013-06-10 5:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey
In-Reply-To: <1370841910-28695-1-git-send-email-khandual@linux.vnet.ibm.com>
Completely ignore BHRB privilege state filter request as we are
already configuring that with privilege state filtering attribute
for the accompanying PMU event. This would help achieve cleaner
user space interaction for BHRB.
This patch fixes a situation like this
Before patch:-
------------
./perf record -j any -e branch-misses:k ls
Error:
The sys_perf_event_open() syscall returned with 95 (Operation not
supported) for event (branch-misses:k).
/bin/dmesg may provide additional information.
No CONFIG_PERF_EVENTS=y kernel support configured?
Here 'perf record' actually copies over ':k' filter request into BHRB
privilege state filter config and our previous check in kernel would
fail that.
After patch:-
-------------
./perf record -j any -e branch-misses:k ls
perf perf.data perf.data.old test-mmap-ring
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~102 samples)]
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/perf/power8-pmu.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index f7d1c4f..371c6e7 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -523,18 +523,13 @@ static int power8_generic_events[] = {
static u64 power8_bhrb_filter_map(u64 branch_sample_type)
{
u64 pmu_bhrb_filter = 0;
- u64 br_privilege = branch_sample_type & ONLY_PLM;
- /* BHRB and regular PMU events share the same prvillege state
+ /* BHRB and regular PMU events share the same privilege state
* filter configuration. BHRB is always recorded along with a
- * regular PMU event. So privilege state filter criteria for BHRB
- * and the companion PMU events has to be the same. As a default
- * "perf record" tool sets all privillege bits ON when no filter
- * criteria is provided in the command line. So as along as all
- * privillege bits are ON or they are OFF, we are good to go.
+ * regular PMU event. As the privilege state filter is handled
+ * in the basic PMC configuration of the accompanying regular
+ * PMU event, we ignore any separate BHRB specific request.
*/
- if ((br_privilege != 7) && (br_privilege != 0))
- return -1;
/* No branch filter requested */
if (branch_sample_type & PERF_SAMPLE_BRANCH_ANY)
--
1.7.11.7
^ permalink raw reply related
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2013-06-10 4:24 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, Linux Kernel list, Patchwork ML
In-Reply-To: <51B553FE.6010201@ozlabs.org>
On Sun, Jun 9, 2013 at 9:20 PM, Jeremy Kerr <jk@ozlabs.org> wrote:
>
> So, we now use the original date header (if present) in the mbox views:
>
> $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
> Date: Fri, 7 Jun 2013 15:42:54 +1000
>
> ... for all your data-mining needs.
Goodie, and I see that it even works with old patches. Thanks.
Linus
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Jeremy Kerr @ 2013-06-10 4:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list, Patchwork ML
In-Reply-To: <CA+55aFzHT3NWrF6gq+BaLcZmEtrFwkiXv0_qZ0jGjxTO6-8iPQ@mail.gmail.com>
Hi Linus,
> No. The date from the email was
>
> Date: Fri, 7 Jun 2013 15:42:54 +1000
>
> and we want *that* date.
Ah, gotchya.
So, we now use the original date header (if present) in the mbox views:
$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 7 Jun 2013 15:42:54 +1000
... for all your data-mining needs.
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH] powerpc: Partial revert of "Context switch more PMU related SPRs"
From: Anshuman Khandual @ 2013-06-10 4:18 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1370491416-1807-1-git-send-email-michael@ellerman.id.au>
On 06/06/2013 09:33 AM, Michael Ellerman wrote:
> In commit 59affcd I added context switching of more PMU SPRs, because
> they are potentially exposed to userspace on Power8. However despite me
> being a smart arse in the commit message it's actually not correct. In
> particular it interacts badly with a global perf record.
Could you please explain how it would interact badly with a global perf record.
If any user space try to mess around with the MMCR* registers itself, it would
definitely interfere with the kernel's own PMU config going on during perf record.
But thats how it works. So when we are actually dealing with MMCR* registers
directly, we should not invoke "perf record" session which can potential run on
the same PMU.
Regards
Anshuman
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2013-06-10 3:36 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, Linux Kernel list, Patchwork ML
In-Reply-To: <CA+55aFxJxY3J2X7DsEY4nz050PmNFgsZRewQEPoVWc1gzdiLGw@mail.gmail.com>
On Sun, Jun 9, 2013 at 8:20 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> .. the rationale for this is that the work pattern of people is
> actually interesting information. You can do things like this:
>
> git log --pretty=%aD --author=Torvalds
Final side note: for me, and other git users that apply other peoples
patches, it's probably better to use
git log --pretty=%cD --committer=Torvalds
instead.
Interestingly, that shows a different pattern than my "authorship"
statistics, which are mainly pull requests. It turns out I commit
patches much more in the afternoon. The reason is probably simple: in
the mornings, I have pull requests waiting from overnight, so a fair
number of pull requests where I am author at 9-11. But my biggest
source of patches tends to be Andrew Morton, who sends the patches in
the afternoon, so suddenly the commit counts skew towards being
between 3pm-8pm when you take all my commits into accoint.
Doing
git log --since=6.months --pretty=%aD --grep=Signed.*Andrew.Morton
backs that up: most of the commits that have sign-offs by Andrew are
sent in the afternoon.
I just find details like that really interesting, where you can
actually mine for the workpatterns of people.
Linus
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2013-06-10 3:20 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, Linux Kernel list, Patchwork ML
In-Reply-To: <CA+55aFzHT3NWrF6gq+BaLcZmEtrFwkiXv0_qZ0jGjxTO6-8iPQ@mail.gmail.com>
On Sun, Jun 9, 2013 at 8:06 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> And it does matter.
.. the rationale for this is that the work pattern of people is
actually interesting information. You can do things like this:
git log --pretty=%aD --author=Torvalds
to see what my work pattern is, and I think that's *interesting*.
Gathering statistics like whether people are generally doing 9-5
Mon-Fri is actually interesting data. You can do things like this:
git log --since=6.months --pretty=%aD --author=Torvalds |
cut -c1-3 |
sort |
uniq -c |
sort -n
and see (for example) that I do slow down on weekends.
Same goes for things like what time of day ends up being most
productive. You can do the statistics for me, and see that I tend to
do the bulk of my pulls in the mornings (peak between 9-11) and that
I'm not a night-owl (*big* drop-off after 8PM - that's what kids do to
you). You can see a few really early-morning cases, but I suspect they
were when I was jetlagged.
So the date data is actually meaningful data. It's not just random noise.
And to do these kinds of things, you absolutely have to have
local-time with proper timezone information. Anything that screws that
up is *broken*. git gets this right, unlike a lot of other broken
SCM's. Git gets it right for a reason.
Yeah, yeah, when people forward other peoples patches they often drop
the date field, and the date of the patch ends up being the time that
the last version of the patch got sent rather than anything else, so
many of the statistics aren't valid. But a _tool_ that actively
corrupts the date and time of a patch is just broken.
Linus
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Linus Torvalds @ 2013-06-10 3:06 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, Linux Kernel list, Patchwork ML
In-Reply-To: <51B53DAB.10501@ozlabs.org>
On Sun, Jun 9, 2013 at 7:44 PM, Jeremy Kerr <jk@ozlabs.org> wrote:
>
> We keep all patch dates in UTC, but were generating the Date header
> incorrectly. Now fixed:
No, not fixed.
Keeping patch dates in UTC *corrupts* the date.
I'll ask people to stop using patchworks if it cannot keep track of
emailed dates. The date very much is a local time WITH A TIMEZONE.
And it does matter.
> $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
> Date: Fri, 07 Jun 2013 05:42:54 -0000
No. The date from the email was
Date: Fri, 7 Jun 2013 15:42:54 +1000
and we want *that* date. Not some random date that patchwork makes up
that has no relevance.
I know you have that date, because it shows up when asking for the
headers in patchwork. Just use the right one, don't make up incorrect
ones.
Linus
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Jeremy Kerr @ 2013-06-10 2:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list, Patchwork ML
In-Reply-To: <CA+55aFxAC4EksZcz7SaZNjF9mfKkwLjWp2rEKxMZT8m-7uBeNQ@mail.gmail.com>
Hi Linus,
> Is Jeremy the patchwork maintainer?
Yep, that's me.
> and it turns out that apparently 'patchwork' is just making up random
> times, because when you download the email as an mbox, it will turn
> this into that corrupt and incorrect
>
> Date: Thu, 06 Jun 2013 19:42:54 -0000
>
> thing which is apparently how you got the wrong timestamp to begin with.
We keep all patch dates in UTC, but were generating the Date header
incorrectly. Now fixed:
$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 07 Jun 2013 05:42:54 -0000
Commit is at:
http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=e7353352
Cheers,
Jeremy
^ permalink raw reply
* [RFC 10/10] irqchip: Make versatile fpga irq driver a generic chip
From: Grant Likely @ 2013-06-10 0:49 UTC (permalink / raw)
To: linux-kernel
Cc: Russell King, Arnd Bergmann, Linus Walleij, Grant Likely,
Thomas Gleixner, linuxppc-dev
In-Reply-To: <1370825362-11145-1-git-send-email-grant.likely@linaro.org>
This is an RFC patch to convert the versatile FPGA irq controller driver
to use generic irq chip. It builds on the series that extends the
generic chip code to allow a linear irq domain to contain one or more
generic irq chips so that each interrupt controller doesn't need to hand
code the generic chip setup.
I've written this as a proof of concept to see if the new generic irq
code does what it needs to. I had to extend it slightly to properly
handle the valid mask used by the versatile FPGA driver.
Tested on QEMU, but not on real hardware.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-versatile-fpga.c | 104 +++++++++++++----------------------
2 files changed, 39 insertions(+), 66 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..8765502 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -14,6 +14,7 @@ config ARM_VIC
bool
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
+ select GENERIC_IRQ_CHIP
config ARM_VIC_NR
int
diff --git a/drivers/irqchip/irq-versatile-fpga.c b/drivers/irqchip/irq-versatile-fpga.c
index 47a52ab..8c7097b 100644
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -34,37 +34,18 @@
* @used_irqs: number of active IRQs on this controller
*/
struct fpga_irq_data {
- void __iomem *base;
- struct irq_chip chip;
- u32 valid;
struct irq_domain *domain;
- u8 used_irqs;
};
/* we cannot allocate memory when the controllers are initially registered */
static struct fpga_irq_data fpga_irq_devices[CONFIG_VERSATILE_FPGA_IRQ_NR];
static int fpga_irq_id;
-static void fpga_irq_mask(struct irq_data *d)
-{
- struct fpga_irq_data *f = irq_data_get_irq_chip_data(d);
- u32 mask = 1 << d->hwirq;
-
- writel(mask, f->base + IRQ_ENABLE_CLEAR);
-}
-
-static void fpga_irq_unmask(struct irq_data *d)
-{
- struct fpga_irq_data *f = irq_data_get_irq_chip_data(d);
- u32 mask = 1 << d->hwirq;
-
- writel(mask, f->base + IRQ_ENABLE_SET);
-}
-
static void fpga_irq_handle(unsigned int irq, struct irq_desc *desc)
{
- struct fpga_irq_data *f = irq_desc_get_handler_data(desc);
- u32 status = readl(f->base + IRQ_STATUS);
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(domain, 0);
+ u32 status = readl(gc->reg_base + IRQ_STATUS);
if (status == 0) {
do_bad_IRQ(irq, desc);
@@ -74,7 +55,7 @@ static void fpga_irq_handle(unsigned int irq, struct irq_desc *desc)
do {
irq = ffs(status) - 1;
status &= ~(1 << irq);
- generic_handle_irq(irq_find_mapping(f->domain, irq));
+ generic_handle_irq(irq_find_mapping(domain, irq));
} while (status);
}
@@ -85,11 +66,12 @@ static void fpga_irq_handle(unsigned int irq, struct irq_desc *desc)
*/
static int handle_one_fpga(struct fpga_irq_data *f, struct pt_regs *regs)
{
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(f->domain, 0);
int handled = 0;
int irq;
u32 status;
- while ((status = readl(f->base + IRQ_STATUS))) {
+ while ((status = readl(gc->reg_base + IRQ_STATUS))) {
irq = ffs(status) - 1;
handle_IRQ(irq_find_mapping(f->domain, irq), regs);
handled = 1;
@@ -112,63 +94,53 @@ asmlinkage void __exception_irq_entry fpga_handle_irq(struct pt_regs *regs)
} while (handled);
}
-static int fpga_irqdomain_map(struct irq_domain *d, unsigned int irq,
- irq_hw_number_t hwirq)
-{
- struct fpga_irq_data *f = d->host_data;
-
- /* Skip invalid IRQs, only register handlers for the real ones */
- if (!(f->valid & BIT(hwirq)))
- return -EPERM;
- irq_set_chip_data(irq, f);
- irq_set_chip_and_handler(irq, &f->chip,
- handle_level_irq);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
- return 0;
-}
-
-static struct irq_domain_ops fpga_irqdomain_ops = {
- .map = fpga_irqdomain_map,
- .xlate = irq_domain_xlate_onetwocell,
-};
-
void __init fpga_irq_init(void __iomem *base, const char *name, int irq_start,
int parent_irq, u32 valid, struct device_node *node)
{
+ struct irq_chip_generic *gc;
struct fpga_irq_data *f;
- int i;
+ int ret;
if (fpga_irq_id >= ARRAY_SIZE(fpga_irq_devices)) {
pr_err("%s: too few FPGA IRQ controllers, increase CONFIG_VERSATILE_FPGA_IRQ_NR\n", __func__);
return;
}
f = &fpga_irq_devices[fpga_irq_id];
- f->base = base;
- f->chip.name = name;
- f->chip.irq_ack = fpga_irq_mask;
- f->chip.irq_mask = fpga_irq_mask;
- f->chip.irq_unmask = fpga_irq_unmask;
- f->valid = valid;
+
+ /* This will also allocate irq descriptors */
+ f->domain = irq_domain_add_linear(node, fls(valid),
+ &irq_generic_chip_ops, f);
+ if (!f->domain) {
+ pr_err("FPGA IRQ setup failed allocation domain\n");
+ return;
+ }
+
+ ret = irq_alloc_domain_generic_chips(f->domain, fls(valid), 1,
+ name, handle_level_irq,
+ IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN, 0, 0);
+ if (ret) {
+ pr_err("FPGA IRQ setup failed allocating generic chip\n");
+ return;
+ }
+
+ gc = irq_get_domain_generic_chip(f->domain, 0);
+ gc->reg_base = base;
+ gc->unused = ~valid;
+ gc->chip_types[0].regs.enable = IRQ_ENABLE_SET;
+ gc->chip_types[0].regs.disable = IRQ_ENABLE_CLEAR;
+ gc->chip_types[0].chip.irq_ack = irq_gc_mask_disable_reg;
+ gc->chip_types[0].chip.irq_mask = irq_gc_mask_disable_reg;
+ gc->chip_types[0].chip.irq_unmask = irq_gc_unmask_enable_reg;
if (parent_irq != -1) {
- irq_set_handler_data(parent_irq, f);
+ irq_set_handler_data(parent_irq, f->domain);
irq_set_chained_handler(parent_irq, fpga_irq_handle);
}
- /* This will also allocate irq descriptors */
- f->domain = irq_domain_add_simple(node, fls(valid), irq_start,
- &fpga_irqdomain_ops, f);
-
- /* This will allocate all valid descriptors in the linear case */
- for (i = 0; i < fls(valid); i++)
- if (valid & BIT(i)) {
- if (!irq_start)
- irq_create_mapping(f->domain, i);
- f->used_irqs++;
- }
-
- pr_info("FPGA IRQ chip %d \"%s\" @ %p, %u irqs\n",
- fpga_irq_id, name, base, f->used_irqs);
+ if (irq_start)
+ irq_domain_associate_many(f->domain, irq_start, 0, fls(valid));
+
+ pr_info("FPGA IRQ chip %d \"%s\" @ %p\n", fpga_irq_id, name, base);
fpga_irq_id++;
}
--
1.8.1.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox