next/mmotm unbootable on G5: irqdomain
I have to revert the patch below from mmotm 2012-07-20-16-30 or
next-20120720 in order to boot on the PowerPC G5: otherwise it
freezes before switching to the framebuffer console - but I'm
not certain where because that initial console doesn't scroll
(there are mpic messages at bottom and at top of screen, probably
later messages at the top but I don't know the sequence).
Hugh
commit 94f036a1f242f98cc30700b7676c07270a9c5c27
Author: Grant Likely
Date: Sun Jun 3 22:04:39 2012 -0700
irqdomain: eliminate slow-path revmap lookups
With the current state of irq_domain, the reverse map is always updated
when new IRQs get mapped. This means that the irq_find_mapping() function
can be simplified to execute the revmap lookup functions unconditionally
This patch adds lookup functions for the revmaps that don't yet have one
and removes the slow path lookup code path.
v8: Broke out unrelated changes into separate patches. Rebased on Paul's irq
association patches.
v7: Rebased to irqdomain/next for v3.4 and applied before the removal of 'hint'
v6: Remove the slow path entirely. The only place where the slow path
could get called is for a linear mapping if the hwirq number is larger
than the linear revmap size. There shouldn't be any interrupt
controllers that do that.
v5: rewrite to not use a ->revmap() callback. It is simpler, smaller,
safer and faster to open code each of the revmap lookups directly into
irq_find_mapping() via a switch statement.
v4: Fix build failure on incorrect variable reference.
Signed-off-by: Grant Likely
Cc: Benjamin Herrenschmidt
Cc: Thomas Gleixner
Cc: Milton Miller
Cc: Paul Mundt
Cc: Rob Herring
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index c0e638b..a9b810e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -686,16 +686,11 @@ EXPORT_SYMBOL_GPL(irq_dispose_mapping);
* irq_find_mapping() - Find a linux irq from an hw irq number.
* @domain: domain owning this hardware interrupt
* @hwirq: hardware irq number in that domain space
- *
- * This is a slow path, for use by generic code. It's expected that an
- * irq controller implementation directly calls the appropriate low level
- * mapping function.
*/
unsigned int irq_find_mapping(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
- unsigned int i;
- unsigned int hint = hwirq % nr_irqs;
+ struct irq_data *data;
/* Look for default domain if nececssary */
if (domain == NULL)
@@ -703,22 +698,27 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
if (domain == NULL)
return 0;
- /* legacy -> bail early */
- if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
+ switch (domain->revmap_type) {
+ case IRQ_DOMAIN_MAP_LEGACY:
return irq_domain_legacy_revmap(domain, hwirq);
-
- /* Slow path does a linear search of the map */
- if (hint == 0)
- hint = 1;
- i = hint;
- do {
- struct irq_data *data = irq_get_irq_data(i);
+ case IRQ_DOMAIN_MAP_LINEAR:
+ return irq_linear_revmap(domain, hwirq);
+ case IRQ_DOMAIN_MAP_TREE:
+ rcu_read_lock();
+ data = radix_tree_lookup(&domain->revmap_data.tree, hwirq);
+ rcu_read_unlock();
+ if (data)
+ return data->irq;
+ break;
+ case IRQ_DOMAIN_MAP_NOMAP:
+ data = irq_get_irq_data(hwirq);
if (data && (data->domain == domain) && (data->hwirq == hwirq))
- return i;
- i++;
- if (i >= nr_irqs)
- i = 1;
- } while(i != hint);
+ return hwirq;
+ break;
+ }
+
+ WARN(1, "ERROR: irq revmap went horribly wrong. revmap_type=%i\n",
+ domain->revmap_type);
return 0;
}
EXPORT_SYMBOL_GPL(irq_find_mapping);
@@ -728,32 +728,19 @@ EXPORT_SYMBOL_GPL(irq_find_mapping);
* @domain: domain owning this hardware interrupt
* @hwirq: hardware irq number in that domain space
*
- * This is a fast path, for use by irq controller code that uses linear
- * revmaps. It does fallback to the slow path if the revmap doesn't exist
- * yet and will create the revmap entry with appropriate locking
+ * This is a fast path that can be called directly by irq controller code to
+ * save a handful of instructions.
*/
unsigned int irq_linear_revmap(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
- unsigned int *revmap;
+ BUG_ON(domain->revmap_type != IRQ_DOMAIN_MAP_LINEAR);
- if (WARN_ON_ONCE(domain->revmap_type != IRQ_DOMAIN_MAP_LINEAR))
- return irq_find_mapping(domain, hwirq);
-
- /* Check revmap bounds */
- if (unlikely(hwirq >= domain->revmap_data.linear.size))
- return irq_find_mapping(
Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
Kumar Gala wrote on 2012/07/20 20:53:10:
> From: Kumar Gala
> To: Joakim Tjernlund ,
> Cc: scottw...@freescale.com, linuxppc-...@ozlabs.org
> Date: 2012/07/20 20:53
> Subject: Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
>
>
> On Jul 20, 2012, at 2:17 AM, Joakim Tjernlund wrote:
>
> >
> > Hi Guys
> >
> > I see that you have been hacking Freescale PCI before so I send this to
> > you(and the list)
> >
> > We are using PCIe(as RC) on P2010(basically a mpc85xx) and have PCI device
> > that
> > started from user space (needs advance clock conf) so when linux boots
> > there is
> > no device at all.
> > Trying to "hotplug" the device after it is enabled fails, no amount of
> > recan/remove using
> > either fake or real hotplug makes a difference.
> >
> > I found the cause eventually but I can't fix it properly as I known almost
> > nothing about PCI.
> > Cause:
> > indirect_pci.c:indirect_read_config() tests for if (hose->indirect_type &
> > PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > and returns PCIBIOS_DEVICE_NOT_FOUND
> >
> > PPC_INDIRECT_TYPE_NO_PCIE_LINK get set by fsl_pci.c (look for
> > fsl_pcie_check_link) but is never cleared.
> > Clearing it as appropriate makes a small difference. If you
> > remove the RC and do a few of rescan's then the device appears.
> >
> > Hacking some more, like so:
> >
> > int fsl_pcie_check_link(struct pci_controller *hose)
> > {
> >u32 val;
> >
> >early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
> >hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> >if (val < PCIE_LTSSM_L0)
> > return 1;
> >hose->indirect_type &= ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> >return 0;
> > }
> > and then using it carefully(it is easy to make linux hang) in
> > indirect_read_config():
> > indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> >int len, u32 *val)
> > {
> >struct pci_controller *hose = pci_bus_to_host(bus);
> >volatile void __iomem *cfg_data;
> >u8 cfg_type = 0;
> >u32 bus_no, reg;
> >
> >if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK) {
> > if (bus->number != hose->first_busno ||
> > devfn != 0) {
> > fsl_pcie_check_link(hose);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> >}
> >
> > Now it works, just one rescan and the device appears!
> > This is a hack, I don't known what other trouble it can cause, I hope you
> > can
> > sort this out.
>
Related, should not all those fsl quirks be __devinit instead of __init?
See this for motivation
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=85a053fa5f2d67ae5b2968305b16e8d2fe4cdf4d
Could quirk_fsl_pcie_header be moved to early fixup time? I recall some code,
maybe is was hotplug,
complaining about not recognising the header because it executed before the
header fixup.
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
Kumar Gala wrote on 2012/07/20 20:53:10:
>
>
> On Jul 20, 2012, at 2:17 AM, Joakim Tjernlund wrote:
>
> >
> > Hi Guys
> >
> > I see that you have been hacking Freescale PCI before so I send this to
> > you(and the list)
> >
> > We are using PCIe(as RC) on P2010(basically a mpc85xx) and have PCI device
> > that
> > started from user space (needs advance clock conf) so when linux boots
> > there is
> > no device at all.
> > Trying to "hotplug" the device after it is enabled fails, no amount of
> > recan/remove using
> > either fake or real hotplug makes a difference.
> >
> > I found the cause eventually but I can't fix it properly as I known almost
> > nothing about PCI.
> > Cause:
> > indirect_pci.c:indirect_read_config() tests for if (hose->indirect_type &
> > PPC_INDIRECT_TYPE_NO_PCIE_LINK)
> > and returns PCIBIOS_DEVICE_NOT_FOUND
> >
> > PPC_INDIRECT_TYPE_NO_PCIE_LINK get set by fsl_pci.c (look for
> > fsl_pcie_check_link) but is never cleared.
> > Clearing it as appropriate makes a small difference. If you
> > remove the RC and do a few of rescan's then the device appears.
> >
> > Hacking some more, like so:
> >
> > int fsl_pcie_check_link(struct pci_controller *hose)
> > {
> >u32 val;
> >
> >early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
> >hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> >if (val < PCIE_LTSSM_L0)
> > return 1;
> >hose->indirect_type &= ~PPC_INDIRECT_TYPE_NO_PCIE_LINK;
> >return 0;
> > }
> > and then using it carefully(it is easy to make linux hang) in
> > indirect_read_config():
> > indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> >int len, u32 *val)
> > {
> >struct pci_controller *hose = pci_bus_to_host(bus);
> >volatile void __iomem *cfg_data;
> >u8 cfg_type = 0;
> >u32 bus_no, reg;
> >
> >if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK) {
> > if (bus->number != hose->first_busno ||
> > devfn != 0) {
> > fsl_pcie_check_link(hose);
> > return PCIBIOS_DEVICE_NOT_FOUND;
> > }
> >}
> >
> > Now it works, just one rescan and the device appears!
> > This is a hack, I don't known what other trouble it can cause, I hope you
> > can
> > sort this out.
>
> How are you forcing the re-scan? We can see if we can add a re-check of the
> link state in that flow somewhere.
echo 1 > /sys/bus/pci/rescan
Why is that check important? Seems like some very ppc specific workaround for
something.
>
> Can you do a dump_stack() or something to get a call chain?
here?
indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 *val)
{
struct pci_controller *hose = pci_bus_to_host(bus);
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
u32 bus_no, reg;
static int first_dump;
if (!first_dump) {
dump_stack();
first_dump = 1;
}
...
I am not at work and and my board needs a reset button press to recover :(
Furthermore, my vacation starts next week, not sure I can get it fixed soon
enough
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: SMT priority (PPR) save and restore
On Mon, 2012-07-16 at 13:41 +1000, Michael Neuling wrote: > Heaven Myneni wrote: > > > powerpc: SMT priority (PPR) save and restore > > > > On P7 systems, users can define SMT priority levels 2,3 and 4 for > > processes so that some can run higher priority than the other ones. > > In the current kernel, the default priority is set to 4 which prohibits > > processes to use higher priority. Also the kernel boosts the priority to > > 4 during exception without saving the user defined priority values when > > the task enters the kernel. So we will be loosing the process PPR value > > and can not be restored it back when the task exits the kernel. > > > > This patch sets the default priority to 3 when tasks are created such > > that users can use 4 for higher priority tasks. It also provides to save > > and restore the user defined priorities for all tasks. > > > > When the task enters in to kernel space, the user defined priority (PPR) > > will be saved in to PACA at the beginning of first level exception > > vector and then copy from PACA to thread_info in second level vector. > > PPR will be restored from thread_info before exits the kernel space. > > > > P7 temporarily raises the thread priority to higher level during > > exception until the program executes HMT_* calls. But it will not modify > > PPR register. So we saves PPR value whenever some register is available > > to use and then calls HMT_MEDIUM to increase the priority. This feature > > supports on P7 or later processors. > > > > Signed-off-by: Haren Myneni > > Can you break this patch into a few parts that are easier to review than > one giant patch. Start by adding the PPR ftr bits, then the extra space > in the paca, then the new macros, then use the new infrastructure. I'm > sure you can get 5 or so patches which will be much easier to review. > > Also this has been white space munged. See here: > http://patchwork.ozlabs.org/patch/170993/ > All the #defines are broken. > > Also, do you know what the impacts of this are on null syscall/page > faults etc on machines which need the PPR switched? If it's big, we > might want to have this as a CONFIG option for those who don't care and > want the speed bump. Thanks for your comments. Sure will split this patch in to 5/6 patches. With Anton's num_syscall test - http://ozlabs.org/~anton/junkcode/null_syscall.c, noticed 6% overhead. As you suggested, will add CONFIG option for this feature. Sorry, my e-mail client messed-up some tabs. will post next time properly. Please see my responses below. > More comments below. > > > > > diff --git a/arch/powerpc/include/asm/cputable.h > > b/arch/powerpc/include/asm/cputable.h > > index 50d82c8..e7b80d6 100644 > > --- a/arch/powerpc/include/asm/cputable.h > > +++ b/arch/powerpc/include/asm/cputable.h > > @@ -203,6 +203,7 @@ extern const char *powerpc_base_platform; > > #define CPU_FTR_POPCNTD > > LONG_ASM_CONST(0x0800) > > #define CPU_FTR_ICSWX > > LONG_ASM_CONST(0x1000) > > #define CPU_FTR_VMX_COPY LONG_ASM_CONST(0x2000) > > +#define CPU_FTR_HAS_PPR > > LONG_ASM_CONST(0x4000) > > > > #ifndef __ASSEMBLY__ > > > > @@ -432,7 +433,8 @@ extern const char *powerpc_base_platform; > > CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \ > > CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \ > > CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | > > \ > > - CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY) > > + CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | > > \ > > + CPU_FTR_HAS_PPR) > > Add CPU_FTR_HAS_PPR to CPU_FTRS_POSSIBLE as well. CPU_FTRS_POWER7 is already defined to CPU_FTRS_POSSIBLE. So do we still need CPU_FTR_HAS_PPR to CPU_FTRS_POSSIBLE? #define CPU_FTRS_POSSIBLE \ (CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 | \ CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \ CPU_FTRS_POWER7 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \ CPU_FTR_VSX) > > > > #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ > > CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ > > CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \ > > diff --git a/arch/powerpc/include/asm/exception-64s.h > > b/arch/powerpc/include/asm/exception-64s.h > > index d58fc4e..1fae8aa 100644 > > --- a/arch/powerpc/include/asm/exception-64s.h > > +++ b/arch/powerpc/include/asm/exception-64s.h > > @@ -47,6 +47,7 @@ > > #define EX_R3 64 > > #define EX_LR 72 > > #define EX_CFAR80 > > +#define EX_PPR 88 /* SMT thread status register > > (priority) */ > > > > /* > > * We're short on space and time in the exception prolog, so we can't > > @@ -61,10 +62,46 @@ > > #define EXC_HV H > > #define EXC_STD >
RE: [PATCH][upstream] TDM Framework
> -Original Message- > From: Linuxppc-dev [mailto:linuxppc-dev- > bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of > Aggrwal Poonam-B10812 > Sent: Saturday, July 21, 2012 1:07 PM > To: Josh Boyer; Michael Ellerman > Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400 > Subject: RE: [PATCH][upstream] TDM Framework > > > > > -Original Message- > > From: Josh Boyer [mailto:jwbo...@gmail.com] > > Sent: Friday, July 20, 2012 6:57 PM > > To: Michael Ellerman > > Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812; linuxppc- > > d...@lists.ozlabs.org > > Subject: Re: [PATCH][upstream] TDM Framework > > > > On Fri, Jul 20, 2012 at 8:54 AM, Michael Ellerman > > wrote: > > > On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: > > >> From: Sandeep Singh > > >> > > >> TDM Framework is an attempt to provide a platform independent layer > > >> which can offer a standard interface for TDM access to different > > client modules. > > >> Beneath, the framework layer can house different types of TDM > > >> drivers to handle various TDM devices, the hardware intricacies of > > >> the devices being completely taken care by TDM drivers. > > > > > > TDM ? > > > > And here I was thinking I was the only one scratching his head. All I > > could come up with was Time Division Multiplexing. > > > Sorry for that. TDM refers to Time Division Multiplexing. Actually the > first version of this patch set also had a patch which documented TDM > basics. > We missed it this time. > > Will just send the TDM documentation patch also. The documentation patch is at: http://patchwork.ozlabs.org/patch/145857/ > > Regards > Poonam > > For your reference: > > > Protip: If you use an acronym a billion times in a patch, expand it at > > least in one place. > > > > josh > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][upstream] TDM Framework
> -Original Message- > From: Josh Boyer [mailto:jwbo...@gmail.com] > Sent: Friday, July 20, 2012 6:57 PM > To: Michael Ellerman > Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [PATCH][upstream] TDM Framework > > On Fri, Jul 20, 2012 at 8:54 AM, Michael Ellerman > wrote: > > On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: > >> From: Sandeep Singh > >> > >> TDM Framework is an attempt to provide a platform independent layer > >> which can offer a standard interface for TDM access to different > client modules. > >> Beneath, the framework layer can house different types of TDM drivers > >> to handle various TDM devices, the hardware intricacies of the > >> devices being completely taken care by TDM drivers. > > > > TDM ? > > And here I was thinking I was the only one scratching his head. All I > could come up with was Time Division Multiplexing. > Sorry for that. TDM refers to Time Division Multiplexing. Actually the first version of this patch set also had a patch which documented TDM basics. We missed it this time. Will just send the TDM documentation patch also. Regards Poonam For your reference: > Protip: If you use an acronym a billion times in a patch, expand it at > least in one place. > > josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][upstream] TDM Framework
Sorry the documentation patch got missed in this patchset. Will send it again. Regards Poonam > -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Friday, July 20, 2012 8:20 PM > To: Singh Sandeep-B37400 > Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400; Aggrwal Poonam- > B10812 > Subject: Re: [PATCH][upstream] TDM Framework > > Hi, > > On Fri, 20 Jul 2012 18:05:13 +0530 wrote: > > > > From: Sandeep Singh > > > > TDM Framework is an attempt to provide a platform independent layer > > which can offer a standard interface for TDM access to different > client modules. > > I also wondered what TDM is. > > > +++ b/drivers/tdm/Kconfig > > @@ -0,0 +1,18 @@ > > +# > > +# TDM subsystem configuration > > +# > > + > > +menuconfig TDM > > + tristate "TDM support" > > + ---help--- > > + More information is contained in the directory > > +, > > ^^ > > + especially in the file called "summary" there. > ^^^ > > It might help if those files were included in the patch set ... > > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
