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 sand...@freescale.com wrote: From: Sandeep Singh sand...@freescale.com 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 +file:Documentation/tdm/, ^^ + 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
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 mich...@ellerman.id.au wrote: On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: From: Sandeep Singh sand...@freescale.com 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
-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 mich...@ellerman.id.au wrote: On Fri, 2012-07-20 at 18:05 +0530, sand...@freescale.com wrote: From: Sandeep Singh sand...@freescale.com 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] powerpc: SMT priority (PPR) save and restore
On Mon, 2012-07-16 at 13:41 +1000, Michael Neuling wrote: Heaven Myneni ha...@linux.vnet.ibm.com 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 hb...@us.ibm.com 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 +/* + * PPR save/restore macros - Used only on P7 or later processors + */ +#define SAVE_PPR(area, ra, rb) \
Re: mpc8xxx PCIe hotplug needs fixing, some clues ..
Kumar Gala ga...@kernel.crashing.org 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: mpc8xxx PCIe hotplug needs fixing, some clues ..
Kumar Gala ga...@kernel.crashing.org wrote on 2012/07/20 20:53:10:
From: Kumar Gala ga...@kernel.crashing.org
To: Joakim Tjernlund joakim.tjernl...@transmode.se,
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
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 grant.lik...@secretlab.ca
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 grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Milton Miller milt...@bga.com
Cc: Paul Mundt let...@linux-sh.org
Cc: Rob Herring rob.herr...@calxeda.com
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);
-
-
