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
Nobody calls it; remove the function
Signed-off-by: Grant Likely
---
include/linux/irqdomain.h | 8
kernel/irq/irqdomain.c| 15 ---
2 files changed, 23 deletions(-)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index f9e8e06..fe7c57d 100644
--- a/i
Originally, irq_domain_associate_many() was designed to unwind the
mapped irqs on a failure of any individual association. However, that
proved to be a problem with certain IRQ controllers. Some of them only
support a subset of irqs, and will fail when attempting to map a
reserved IRQ. In those cas
After refactoring the irqdomain code, there are a number of API
functions that are merely empty wrappers around core code. Drop those
wrappers out of the C file and replace them with static inlines in the
header.
Signed-off-by: Grant Likely
---
arch/powerpc/platforms/cell/beat_interrupt.c | 2
This patch increases the amount of output produced by the
irq_domain_mapping debugfs file by first listing all of the registered
irq domains at the beginning of the output, and then by including all
mapped IRQs in the output, not just the active ones. It is very useful
when debugging irqdomain issu
The NOMAP irq_domain type is only used by a handful of interrupt
controllers and it unnecessarily complicates the code by adding special
cases on how to look up mappings and different revmap functions are used
for each type which need to validate the correct type is passed to it
before performing t
From: Grant Likely
Keeping them separate makes irq_domain more complex and adds a lot of
code (as proven by the diffstat). Merging them simplifies the whole
scheme. This change makes it so both the tree and linear methods can be
used by the same irq_domain instance. If the hwirq is less than t
This patch adds a name field to the irq_domain structure to help mere
mortals understand the mappings between irq domains and virqs. It also
converts a number of places that have open-coded some kind of fudging
an irqdomain name to use the new field. This means a more consistent
display of names in
The LEGACY mapping unnecessarily complicates the irqdomain code and
can easily be implemented with a linear mapping. By ripping it out
and replacing it with the LINEAR mapping the object size of
irqdomain.c shrinks by about 330 bytes (ARMv7) which offsets the
additional allocation required by the
Commit 98aa468e, "irqdomain: Support for static IRQ mapping and
association" introduced an API for directly associating blocks of hwirqs
to linux irqs. However, if any irq in that block failed to map (say if
the mapping functions returns an error because the irq is already
mapped) then the whole th
Hi all,
I'm trying to fix a problem in the PowerPC backend of the Glasgow
Haskell Compiler (GHC) and have a problem with the following
instruction form:
lwz 30, .label - (1b)(31)
Reading the documentation I could find, I have figured out that this
loads a 16 bit value into register 30. H
I've done a bunch of refactoring work on the irq_domain infrastructure.
Some of these patches I've posted before, and some our brand new. The
goal of this is to greatly simplify how irq_domains work. With this
series, instead of there being multiple different types of irq domains,
each with differe
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:-
./p
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
---
arch/powerpc/perf/co
(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_EV
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
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
---
arch/powerpc/perf/co
(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_EV
On Sun, Jun 9, 2013 at 9:20 PM, Jeremy Kerr 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
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
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
On Sun, Jun 9, 2013 at 8:20 PM, Linus Torvalds
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 p
On Sun, Jun 9, 2013 at 8:06 PM, Linus Torvalds
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 tha
On Sun, Jun 9, 2013 at 7:44 PM, Jeremy Kerr 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.
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 -
>
>
On Mon, 2013-06-10 at 09:01 +1000, Erik de Castro Lopo wrote:
> Hi all,
>
> I'm trying to fix a problem in the PowerPC backend of the Glasgow
> Haskell Compiler (GHC) and have a problem with the following
> instruction form:
>
> lwz 30, .label - (1b)(31)
>
> Reading the documentation I c
Hi all,
I'm trying to fix a problem in the PowerPC backend of the Glasgow
Haskell Compiler (GHC) and have a problem with the following
instruction form:
lwz 30, .label - (1b)(31)
Reading the documentation I could find, I have figured out that this
loads a 16 bit value into register 30. H
Hi Linus !
Here's the previous pull request with a couple of commits removed,
this is purely regressions (though not all recent ones) or stable
material.
Cheers,
Ben.
The following changes since commit 1612e111e4e565422242727efb59499cce8738e4:
Merge git://git.kernel.org/pub/scm/linux/kernel/
On Sun, 2013-06-09 at 14:33 -0700, Linus Torvalds wrote:
> On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt
> wrote:
> >
> > Here are a few more powerpc changes for 3.10. I've merged your
> > tree in at some point (which I generally avoid) in order to get
> > the compat network fixes as soo
[ Is Jeremy the patchwork maintainer? If not, can people forward this
to the real maintainer? ]
On Sun, Jun 9, 2013 at 2:33 PM, Linus Torvalds
wrote:
>
> This is not just bugfixes. In fact, as far as I can tell, this
> *introduces* bugs, with that "get_user()" in the exception path that
> can app
On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt
wrote:
>
> Here are a few more powerpc changes for 3.10. I've merged your
> tree in at some point (which I generally avoid) in order to get
> the compat network fixes as soon as possible.
>
> Mostly regressions, and stuff I judged could/shoul
Sorry, Please ignore this patch.
This is replaced.
Replace by: http://patchwork.ozlabs.org/patch/250033/
- dongsheng
> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 1:23 PM
> To: b...@kernel.crashing.org; johan...@sipsolutions.net; an...@enomsg.org
> Cc: W
Sorry, Please ignore this patch.
This is replaced.
Replace by: http://patchwork.ozlabs.org/patch/250032/
- dongsheng
> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 1:21 PM
> To: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421
> Cc: ga...@ke
add restore_mmu_context to replace switch_mmu_context in
restore_processor_state, because the switch_mmu_context will do
a whole pile of stuff that are probably completely unnecessary.
There just need to restore the existing process context, and
invalidate TLB for boot core.
Signed-off-by: Wang D
Update the 64-bit hibernation code to support Book E CPUs.
Some registers and instructions are not defined for Book3e
(SDR reg, tlbia instruction).
SDR: Storage Description Register. Book3S and Book3E have different
address translation mode, we do not need HTABORG & HTABSIZE to
translate virtual a
Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active. Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.
The current
Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active. Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.
The current
Currently we clear out the MSR TM bits on signal return assuming that the
signal should never return to an active transaction.
This is bogus as the user may do this. It's most likely the transaction will
be doomed due to a treclaim but that's a problem for the HW not the kernel.
The current code
Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit signal
without SIGINFO (non RT) inside a transaction, on signal return we don't
restore the signal frame correctly.
This checks if the signal frame being restoring is an active transaction, and
if so, it copies the additional
The MSR TM controls are in the top 32 bits of the MSR hence on 32 bit signals,
we stick the top half of the MSR in the checkpointed signal context so that the
user can access it.
Unfortunately, we don't currently write anything to the checkpointed signal
context when coming in a from a non transac
Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 20:36 +1000, Michael Neuling wrote:
> > Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit
> > signal
> > without SIGINFO (non RT) inside a transaction, on signal return we don't
> > restore the signal frame correctly.
>
Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 20:36 +1000, Michael Neuling wrote:
> > Currently we clear out the MSR TM bits on signal return assuming that the
> > signal should never return to an active transaction.
> >
> > This is bogus as the user may do this. It's most likely the tr
Guenter Roeck wrote:
> On Fri, Jun 07, 2013 at 12:58:16PM -0700, Greg KH wrote:
> > I'm announcing the release of the 3.9.5 kernel.
> >
> > All users of the 3.9 kernel series must upgrade.
> >
> > The updated 3.9.y git tree can be found at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/
Hi kumar,
Could you apply this patche?
Thanks.
-dongsheng
> -Original Message-
> From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Friday, May 24, 2013 1:34 AM
> To: Wang Dongsheng-B40534
> Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing
Hi ben,
Could you apply these patches? Thanks. :)
- dongsheng
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Monday, May 13, 2013 1:00 PM
> To: Wang Dongsheng-B40534
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> ga...@kernel.cras
Hi Linus !
Here are a few more powerpc changes for 3.10. I've merged your
tree in at some point (which I generally avoid) in order to get
the compat network fixes as soon as possible.
Mostly regressions, and stuff I judged could/should still go in at
this stage.
I'm still waiting on some more fi
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Sunday, June 09, 2013 3:46 PM
> To: Wang Dongsheng-B40534
> Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subjec
On Sun, 2013-06-09 at 07:44 +, Wang Dongsheng-B40534 wrote:
> So we just need set set_context() in restore_mmu_context().
>
> void restore_mmu_context(struct mm_struct *next) {
> set_context(next->context.id, next->pgd);
> }
We probably also want to flush the TLB, just in case the boo
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Sunday, June 09, 2013 2:44 PM
> To: Wang Dongsheng-B40534
> Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subjec
On Fri, 2013-06-07 at 20:36 +1000, Michael Neuling wrote:
> Currently we clear out the MSR TM bits on signal return assuming that the
> signal should never return to an active transaction.
>
> This is bogus as the user may do this. It's most likely the transaction will
> be doomed due to a trecla
On Fri, 2013-06-07 at 20:36 +1000, Michael Neuling wrote:
> Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit
> signal
> without SIGINFO (non RT) inside a transaction, on signal return we don't
> restore the signal frame correctly.
>
> This checks if the signal frame being
This is duplicated code from math-emu and implements such a small
subset of the FPU (load/stores/fmr) that it's essentially pointless
nowdays.
Signed-off-by: Benjamin Herrenschmidt
---
Note that arch/powerpc/math-emu/math.c seems to have code in there
to do exactly the same thing (subset emulati
(Including 64-bit ones)
This allow SW emulation by the kernel of optional instructions
such as fsqrt which aren't implemented on some processors, and
thus fixes some Fedora 19 issues such as Anaconda since the
compiler is set to generate those by default on 64-bit.
Signed-off-by: Benjamin Herrens
The decoding of some instructions such as fsqrt{s} was incorrect,
using the wrong registers, and thus could not work.
This fixes it and also adds a couple of place holders for missing
instructions.
Signed-off-by: Benjamin Herrenschmidt
---
Note: fre.c etc.. are still empty placeholders, just li
54 matches
Mail list logo
