* Re: [PATCH] PPC: Don't sync timebase when inside VM
From: McClintock Matthew-B29882 @ 2012-03-08 18:46 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Wood Scott-B07421, kvm list, Alexander Graf,
<kvm-ppc@vger.kernel.org>, McClintock Matthew-B29882,
linuxppc-dev
In-Reply-To: <4F58FDC4.2080909@freescale.com>
On Thu, Mar 8, 2012 at 12:43 PM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 03/08/2012 12:24 PM, McClintock Matthew-B29882 wrote:
>> On Thu, Mar 8, 2012 at 12:20 PM, Scott Wood <scottwood@freescale.com> wr=
ote:
>>> On 03/08/2012 11:31 AM, McClintock Matthew-B29882 wrote:
>>>> On Fri, Mar 2, 2012 at 11:17 AM, Scott Wood <scottwood@freescale.com> =
wrote:
>>>>> On 03/02/2012 10:30 AM, Alexander Graf wrote:
>>>>>>
>>>>>> On 02.03.2012, at 17:20, Scott Wood wrote:
>>>>>>> Again, for 85xx we should *never* sync the timebase in the kernel,
>>>>>>> hypervisor or no.
>>>>>>
>>>>>> The code says "if the kexec config option is enabled, do the sync". =
I'm fairly sure it's there for a reason.
>>>>>
>>>>> Sigh. =A0I forgot about that. =A0It's because instead of doing kexec =
the
>>>>> simple way, we actually physically reset the core. =A0We really shoul=
dn't
>>>>> do that. =A0And we *really* shouldn't do it just because CONFIG_KEXEC=
is
>>>>> defined, regardless of whether we're actually booting from kexec.
>>>>
>>>> How would one rocver a core that's off in the weeds?
>>>
>>> System reset?
>>
>> kdump restarts a kernel using a reserved memory region to inspect the
>> memory of the crashed kernel. Wouldn't system reset cause issues here?
>
> Oh, kdump.
>
> Maybe in that case, go ahead and reset the other cores (or halt them via
> some other means), but don't do anything with them. =A0Just boot a single
> core in the dump kernel, do the dumping, then reset the system?
Yes, we could do one core here... but is it worthwhile to do kexec and
kdump differently?
> Or if you must sync the timebase in Linux, do it the way U-Boot does
> (and skip it if you don't have access to the relevant CCSR bits).
Ok - I've never even looked at how the timebase sync was done in Linux
or u-boot. Just enabled the timebase sync
> Are I/O devices a problem with kdump and not resetting the system,
> especially on some of our chips where certain I/O devices are difficult
> to reset?
Anything still occurring will be problematic and *possibly* prevent us
from determining what caused the actual crash.
-M=
^ permalink raw reply
* Re: [PATCH 19/38] KVM: PPC: e500mc: add load inst fixup
From: Marcelo Tosatti @ 2012-03-08 22:36 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1330474206-14794-20-git-send-email-agraf@suse.de>
On Wed, Feb 29, 2012 at 01:09:47AM +0100, Alexander Graf wrote:
> There's always a chance we're unable to read a guest instruction. The guest
> could have its TLB mapped execute-, but not readable, something odd happens
> and our TLB gets flushed. So it's a good idea to be prepared for that case
> and have a fallback that allows us to fix things up in that case.
>
> Add fixup code that keeps guest code from potentially crashing our host kernel.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> - fix whitespace
Still broken.
> - use explicit preempt counts
> ---
> arch/powerpc/kvm/bookehv_interrupts.S | 30 +++++++++++++++++++++++++++++-
> 1 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
> index 63023ae..f7dc3f6 100644
> --- a/arch/powerpc/kvm/bookehv_interrupts.S
> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
> @@ -28,6 +28,7 @@
> #include <asm/asm-compat.h>
> #include <asm/asm-offsets.h>
> #include <asm/bitsperlong.h>
> +#include <asm/thread_info.h>
>
> #include "../kernel/head_booke.h" /* for THREAD_NORMSAVE() */
>
> @@ -171,9 +172,36 @@
> PPC_STL r30, VCPU_GPR(r30)(r4)
> PPC_STL r31, VCPU_GPR(r31)(r4)
> mtspr SPRN_EPLC, r8
> +
> + /* disable preemption, so we are sure we hit the fixup handler */
> +#ifdef CONFIG_PPC64
> + clrrdi r8,r1,THREAD_SHIFT
> +#else
> + rlwinm r8,r1,0,0,31-THREAD_SHIFT /* current thread_info */
> +#endif
> + li r7, 1
> + stw r7, TI_PREEMPT(r8)
> +
> isync
> - lwepx r9, 0, r5
> +
> + /*
> + * In case the read goes wrong, we catch it and write an invalid value
> + * in LAST_INST instead.
> + */
> +1: lwepx r9, 0, r5
> +2:
> +.section .fixup, "ax"
> +3: li r9, KVM_INST_FETCH_FAILED
> + b 2b
> +.previous
> +.section __ex_table,"a"
> + PPC_LONG_ALIGN
> + PPC_LONG 1b,3b
> +.previous
> +
> mtspr SPRN_EPLC, r3
> + li r7, 0
> + stw r7, TI_PREEMPT(r8)
> stw r9, VCPU_LAST_INST(r4)
> .endif
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-08 23:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michael Neuling, linux-kernel, Rob Herring, linux-next,
Paul Mackerras, linuxppc-dev, Russell King
In-Reply-To: <1331185951.3105.29.camel@pasglop>
On Thu, 2012-03-08 at 16:52 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
> > Hi Mikey,
> >
> > On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling <mikey@neuling.org> wrote:
> > >
> > > Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.
> > >
> > > In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
> > > selectable, which we don't want anymore since ad5b7f1350c2.
> >
> > Yes, indeed. I will fix up the merge resolution for tomorrow.
>
> This is my fault. Grant's patch had a collision and I manually fixed it
> up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
> originally took out.
Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
I remove it, then I get Kconfig warnings:
warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Russell King @ 2012-03-09 0:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Rob Herring,
linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <1331249746.3105.40.camel@pasglop>
On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> I remove it, then I get Kconfig warnings:
>
> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* linux-next: manual merge of the pci tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 1:32 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-kernel, linux-next, Paul Mackerras, Bjorn Helgaas,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/platforms/iseries/pci.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit 673c97562489 ("powerpc/PCI: replace pci_probe_only with
pci_flags") from the pci tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 2:36 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-kernel, linux-next, Paul Mackerras, Joe Perches,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
("net: powerpc: remove the legacy iSeries ethernet driver") from the
powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
error messages") from the net-next tree.
I just removed the file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-09 3:13 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, Michael Neuling, linux-kernel, Rob Herring,
linux-next, Paul Mackerras, linuxppc-dev
In-Reply-To: <20120309003937.GC8680@flint.arm.linux.org.uk>
On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> > Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> > I remove it, then I get Kconfig warnings:
> >
> > warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> > (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
>
> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
Nope, Grant patch didn't mention a dependency.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Mai La @ 2012-03-09 3:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: open-source-review, Mai La
This patch consists of:
- Enable PCI MSI as default for Bluestone board
- Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board
- Fix returning ENODEV as finding MSI node
- Fix MSI physical high and low address
- Keep MSI data logically
Signed-off-by: Mai La <mla@apm.com>
---
arch/powerpc/platforms/44x/Kconfig | 2 ++
arch/powerpc/sysdev/Kconfig | 6 ++++++
arch/powerpc/sysdev/ppc4xx_msi.c | 27 ++++++++++++++++-----------
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index fcf6bf2..9f04ce3 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -23,6 +23,8 @@ config BLUESTONE
default n
select PPC44x_SIMPLE
select APM821xx
+ select PCI_MSI
+ select PPC4xx_MSI
select IBM_EMAC_RGMII
help
This option enables support for the APM APM821xx Evaluation board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 7b4df37..c86231e 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
default y if FSL_PCI
default y if PPC4xx_MSI
+config PPC4xx_NR_MSI_IRQS
+ int "Number of PCI MSI interrupts"
+ depends on PCI_MSI && PPC4xx_MSI
+ default "4" if !APM821xx
+ default "8" if APM821xx
+
source "arch/powerpc/sysdev/xics/Kconfig"
config PPC_SCOM
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
index 1c2d7af..3359237 100644
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -28,10 +28,11 @@
#include <linux/of_platform.h>
#include <linux/interrupt.h>
#include <linux/export.h>
+#include <linux/kernel.h>
#include <asm/prom.h>
#include <asm/hw_irq.h>
#include <asm/ppc-pci.h>
-#include <boot/dcr.h>
+#include <asm/dcr.h>
#include <asm/dcr-regs.h>
#include <asm/msi_bitmap.h>
@@ -43,7 +44,8 @@
#define PEIH_FLUSH0 0x30
#define PEIH_FLUSH1 0x38
#define PEIH_CNTRST 0x48
-#define NR_MSI_IRQS 4
+
+#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
struct ppc4xx_msi {
u32 msi_addr_lo;
@@ -150,12 +152,11 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
if (!sdr_addr)
return -1;
- SDR0_WRITE(sdr_addr, (u64)res.start >> 32); /*HIGH addr */
- SDR0_WRITE(sdr_addr + 1, res.start & 0xFFFFFFFF); /* Low addr */
-
+ mtdcri(SDR0, *sdr_addr, upper_32_bits(res.start)); /*HIGH addr */
+ mtdcri(SDR0, *sdr_addr + 1, lower_32_bits(res.start)); /* Low addr */
msi->msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
- if (msi->msi_dev)
+ if (!msi->msi_dev)
return -ENODEV;
msi->msi_regs = of_iomap(msi->msi_dev, 0);
@@ -167,9 +168,12 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
(u32) (msi->msi_regs + PEIH_TERMADH), (u32) (msi->msi_regs));
msi_virt = dma_alloc_coherent(&dev->dev, 64, &msi_phys, GFP_KERNEL);
- msi->msi_addr_hi = 0x0;
- msi->msi_addr_lo = (u32) msi_phys;
- dev_dbg(&dev->dev, "PCIE-MSI: msi address 0x%x\n", msi->msi_addr_lo);
+ if (!msi_virt)
+ return -ENOMEM;
+ msi->msi_addr_hi = (u32)(msi_phys >> 32);
+ msi->msi_addr_lo = (u32)(msi_phys & 0xffffffff);
+ dev_dbg(&dev->dev, "PCIE-MSI: msi address high 0x%x, low 0x%x\n",
+ msi->msi_addr_hi, msi->msi_addr_lo);
/* Progam the Interrupt handler Termination addr registers */
out_be32(msi->msi_regs + PEIH_TERMADH, msi->msi_addr_hi);
@@ -185,6 +189,8 @@ static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
out_be32(msi->msi_regs + PEIH_MSIED, *msi_data);
out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
+ dma_free_coherent(&dev->dev, 64, msi_virt, msi_phys);
+
return 0;
}
@@ -215,8 +221,6 @@ static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
struct resource res;
int err = 0;
- msi = &ppc4xx_msi;/*keep the msi data for further use*/
-
dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
@@ -242,6 +246,7 @@ static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
dev_err(&dev->dev, "Error allocating MSI bitmap\n");
goto error_out;
}
+ ppc4xx_msi = *msi;
ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] powerpc/44x: Add PCI MSI node for Maui APM821xx SoC and Bluestone board in DTS
From: Mai La @ 2012-03-09 3:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Josh Boyer, Matt Porter,
Tirumala R Marri, Grant Likely, Michael Neuling, Kumar Gala,
Anton Blanchard, linuxppc-dev, linux-kernel
Cc: open-source-review, Mai La
Signed-off-by: Mai La <mla@apm.com>
---
arch/powerpc/boot/dts/bluestone.dts | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index 2a56a0d..8ea6325 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -250,5 +250,29 @@
};
};
+ MSI: ppc4xx-msi@C10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0xC 0x10000000 0x100
+ 0xC 0x10000000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x00004440>;
+ msi-mask = <0x0000ffe0>;
+ interrupts =<0 1 2 3 4 5 6 7>;
+ interrupt-parent = <&MSI>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ msi-available-ranges = <0x0 0x100>;
+ interrupt-map = <
+ 0 &UIC3 0x18 1
+ 1 &UIC3 0x19 1
+ 2 &UIC3 0x1A 1
+ 3 &UIC3 0x1B 1
+ 4 &UIC3 0x1C 1
+ 5 &UIC3 0x1D 1
+ 6 &UIC3 0x1E 1
+ 7 &UIC3 0x1F 1
+ >;
+ };
};
};
--
1.7.3.4
^ permalink raw reply related
* 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Anton Blanchard @ 2012-03-09 3:25 UTC (permalink / raw)
To: sfr, benh, yinghai, jbarnes; +Cc: linuxppc-dev, linux-kernel
Hi,
I'm seeing this on a POWER7 blade booting 3.3.0-rc6-next-20120308:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x100000-0x10ffff] (bus address [0xf0000-0xfffff])
pci_bus 0000:00: root bus resource [mem 0x3b0000000000-0x3b001fffffff] (bus address [0xe0000000-0xffffffff])
IOMMU table initialized, virtual merging enabled
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io 0x210000-0x21ffff] (bus address [0xf0000-0xfffff])
pci_bus 0001:00: root bus resource [mem 0x3b0080000000-0x3b00ffffffff] (bus address [0x80000000-0xffffffff])
PCI host bridge to bus 0002:01
pci_bus 0002:01: root bus resource [io 0x320000-0x32ffff] (bus address [0xf0000-0xfffff])
pci_bus 0002:01: root bus resource [mem 0x3b0400000000-0x3b041fefffff] (bus address [0xe0000000-0xffefffff])
PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
PCI: Cannot allocate resource region 2 of device 0000:00:01.0, will remap
PCI: Cannot allocate resource region 6 of device 0000:00:01.0, will remap
PCI: Cannot allocate resource region 0 of device 0001:00:01.0, will remap
PCI: Cannot allocate resource region 0 of device 0001:00:01.1, will remap
PCI: Cannot allocate resource region 0 of device 0001:00:01.2, will remap
PCI: Cannot allocate resource region 0 of device 0002:01:00.0, will remap
PCI: Cannot allocate resource region 2 of device 0002:01:00.0, will
remap
...
pci 0001:00:01.0: device not available (can't reserve [mem 0x00000000-0x00000fff])
pci 0001:00:01.0: Can't enable PCI device, BIOS handoff failed.
pci 0001:00:01.1: device not available (can't reserve [mem 0x00000000-0x00000fff])
pci 0001:00:01.1: Can't enable PCI device, BIOS handoff failed.
pci 0001:00:01.2: device not available (can't reserve [mem 0x00000000-0x000000ff])
pci 0001:00:01.2: Can't enable PCI device, BIOS handoff failed.
Then we fail to find the root device. I haven't had a chance
to chase the cause of it down yet.
Anton
^ permalink raw reply
* Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Benjamin Herrenschmidt @ 2012-03-09 3:29 UTC (permalink / raw)
To: Anton Blanchard; +Cc: sfr, linuxppc-dev, yinghai, linux-kernel, jbarnes
In-Reply-To: <20120309142555.7ec5e0ac@kryten>
On Fri, 2012-03-09 at 14:25 +1100, Anton Blanchard wrote:
> Hi,
>
> I'm seeing this on a POWER7 blade booting 3.3.0-rc6-next-20120308:
Looks like something that got fixed but the new patches from Bjorn
aren't in next yet. I'll fwd you the patch separately to apply on top of
what you have see if that helps (to confirm that's indeed the issue).
Cheers,
Ben.
>
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x100000-0x10ffff] (bus address [0xf0000-0xfffff])
> pci_bus 0000:00: root bus resource [mem 0x3b0000000000-0x3b001fffffff] (bus address [0xe0000000-0xffffffff])
> IOMMU table initialized, virtual merging enabled
> PCI host bridge to bus 0001:00
> pci_bus 0001:00: root bus resource [io 0x210000-0x21ffff] (bus address [0xf0000-0xfffff])
> pci_bus 0001:00: root bus resource [mem 0x3b0080000000-0x3b00ffffffff] (bus address [0x80000000-0xffffffff])
> PCI host bridge to bus 0002:01
> pci_bus 0002:01: root bus resource [io 0x320000-0x32ffff] (bus address [0xf0000-0xfffff])
> pci_bus 0002:01: root bus resource [mem 0x3b0400000000-0x3b041fefffff] (bus address [0xe0000000-0xffefffff])
> PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
> PCI: Cannot allocate resource region 2 of device 0000:00:01.0, will remap
> PCI: Cannot allocate resource region 6 of device 0000:00:01.0, will remap
> PCI: Cannot allocate resource region 0 of device 0001:00:01.0, will remap
> PCI: Cannot allocate resource region 0 of device 0001:00:01.1, will remap
> PCI: Cannot allocate resource region 0 of device 0001:00:01.2, will remap
> PCI: Cannot allocate resource region 0 of device 0002:01:00.0, will remap
> PCI: Cannot allocate resource region 2 of device 0002:01:00.0, will
> remap
>
> ...
>
> pci 0001:00:01.0: device not available (can't reserve [mem 0x00000000-0x00000fff])
> pci 0001:00:01.0: Can't enable PCI device, BIOS handoff failed.
> pci 0001:00:01.1: device not available (can't reserve [mem 0x00000000-0x00000fff])
> pci 0001:00:01.1: Can't enable PCI device, BIOS handoff failed.
> pci 0001:00:01.2: device not available (can't reserve [mem 0x00000000-0x000000ff])
> pci 0001:00:01.2: Can't enable PCI device, BIOS handoff failed.
>
>
> Then we fail to find the root device. I haven't had a chance
> to chase the cause of it down yet.
>
> Anton
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Benjamin Herrenschmidt @ 2012-03-09 3:35 UTC (permalink / raw)
To: Mai La
Cc: Michael Neuling, open-source-review, Tirumala R Marri,
linux-kernel, Josh Boyer, Anton Blanchard, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1331263072-9612-1-git-send-email-mla@apm.com>
On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote:
> This patch consists of:
> - Enable PCI MSI as default for Bluestone board
> - Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board
> - Fix returning ENODEV as finding MSI node
> - Fix MSI physical high and low address
> - Keep MSI data logically
>
> Signed-off-by: Mai La <mla@apm.com>
> ---
> index 7b4df37..c86231e 100644
> --- a/arch/powerpc/sysdev/Kconfig
> +++ b/arch/powerpc/sysdev/Kconfig
> @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
> default y if FSL_PCI
> default y if PPC4xx_MSI
>
> +config PPC4xx_NR_MSI_IRQS
> + int "Number of PCI MSI interrupts"
> + depends on PCI_MSI && PPC4xx_MSI
> + default "4" if !APM821xx
> + default "8" if APM821xx
> +
.../...
> +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
ARGH.
We asked to -NOT MAKE THIS A COMPILE TIME OPTION-
CONFIG_foo is as bad as your previous ifdef, in fact you just added a
useless config option here.
Make that number dynamic. Count the entries in the device-tree (or add
a property with the number in it, whatever you fancy the most) but make
it something detected at RUNTIME !!!!!
Ben.
^ permalink raw reply
* Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Anton Blanchard @ 2012-03-09 3:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sfr, linuxppc-dev, yinghai, linux-kernel, jbarnes
In-Reply-To: <1331263785.3105.52.camel@pasglop>
Hi Ben,
> Looks like something that got fixed but the new patches from Bjorn
> aren't in next yet. I'll fwd you the patch separately to apply on top
> of what you have see if that helps (to confirm that's indeed the
> issue).
Thanks, confirmed that it fixes it. Patch below in case anyone else is
hitting it.
Anton
--
On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote:
> Or give me a chance to dig :-) I'll have a look next week.
This is indeed what bjorn suspected on irc, this patch fixes it:
(Bjorn, please fold it in the original offending patch)
Cheers,
Ben.
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index b37d0b5..5dd63f1 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -75,6 +75,7 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
{
u64 base, size;
unsigned int flags;
+ struct pci_bus_region region;
struct resource *res;
const u32 *addrs;
u32 i;
@@ -106,10 +107,12 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
}
- res->start = base;
- res->end = base + size - 1;
+
res->flags = flags;
res->name = pci_name(dev);
+ region.start = base;
+ region.end = base + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
}
@@ -209,6 +212,7 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
struct pci_bus *bus;
const u32 *busrange, *ranges;
int len, i, mode;
+ struct pci_bus_region region;
struct resource *res;
unsigned int flags;
u64 size;
@@ -270,9 +274,10 @@ void __devinit of_scan_pci_bridge(struct pci_dev *dev)
res = bus->resource[i];
++i;
}
- res->start = of_read_number(&ranges[1], 2);
- res->end = res->start + size - 1;
res->flags = flags;
+ region.start = of_read_number(&ranges[1], 2);
+ region.end = region.start + size - 1;
+ pcibios_bus_to_resource(dev, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
--=-aDzdhtAsqTK5gqnOark/--
^ permalink raw reply related
* linux-next: manual merge of the tip tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 4:40 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: linux-next, Paul Mackerras, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in
arch/powerpc/platforms/iseries/setup.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit bd2f55361f18 ("sched/rt: Use schedule_preempt_disabled()")
from the tip tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the driver-core tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 5:40 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-next, Alan Stern, Paul Mackerras,
linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/base/driver.c between commit fcd6f7620202 ("driver-core: remove
legacy iSeries hack") from the powerpc tree and commit 9875bb480cc8
("Eliminate get_driver() and put_driver()") from the driver-core tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/base/driver.c
index db4f54c,60e4f77..0000000
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@@ -123,34 -123,36 +123,6 @@@ void driver_remove_file(struct device_d
}
EXPORT_SYMBOL_GPL(driver_remove_file);
--/**
- * get_driver - increment driver reference count.
- * @drv: driver.
- */
- struct device_driver *get_driver(struct device_driver *drv)
- {
- if (drv) {
- struct driver_private *priv;
- struct kobject *kobj;
-
- kobj = kobject_get(&drv->p->kobj);
- priv = to_driver(kobj);
- return priv->driver;
- }
- return NULL;
- }
- EXPORT_SYMBOL_GPL(get_driver);
-
- /**
- * put_driver - decrement driver's refcount.
- * @drv: driver.
- */
- void put_driver(struct device_driver *drv)
- {
- kobject_put(&drv->p->kobj);
- }
- EXPORT_SYMBOL_GPL(put_driver);
-
- * driver_add_kobj - add a kobject below the specified driver
- * @drv: requesting device driver
- * @kobj: kobject to add below this driver
- * @fmt: format string that names the kobject
- *
- * You really don't want to do this, this is only here due to one looney
- * iseries driver, go poke those developers if you are annoyed about
- * this...
- */
-int driver_add_kobj(struct device_driver *drv, struct kobject *kobj,
- const char *fmt, ...)
-{
- va_list args;
- char *name;
- int ret;
-
- va_start(args, fmt);
- name = kvasprintf(GFP_KERNEL, fmt, args);
- va_end(args);
-
- if (!name)
- return -ENOMEM;
-
- ret = kobject_add(kobj, &drv->p->kobj, "%s", name);
- kfree(name);
- return ret;
-}
-EXPORT_SYMBOL_GPL(driver_add_kobj);
-
static int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups)
{
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: David Miller @ 2012-03-09 6:15 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-kernel, linux-next, paulus, joe, linuxppc-dev
In-Reply-To: <20120309133646.fb8cc30d8c2fd0ef7784d72c@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 9 Mar 2012 13:36:46 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
> ("net: powerpc: remove the legacy iSeries ethernet driver") from the
> powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
> error messages") from the net-next tree.
>
> I just removed the file.
If it makes life easier for anyone I can put the driver removal patch
into net-next.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 6:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, linux-next, paulus, joe, linuxppc-dev
In-Reply-To: <20120308.221534.712157352097242982.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
Hi Dave,
On Thu, 08 Mar 2012 22:15:34 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 9 Mar 2012 13:36:46 +1100
>
> > Today's linux-next merge of the net-next tree got a conflict in
> > drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
> > ("net: powerpc: remove the legacy iSeries ethernet driver") from the
> > powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
> > error messages") from the net-next tree.
> >
> > I just removed the file.
>
> If it makes life easier for anyone I can put the driver removal patch
> into net-next.
In this case, I think it will actually help, thanks. Note that it won;t
apply cleanly to your tree, but the fixup is easy :-)
And I discovered that "git am" doesn't like the style of patch I did
(without the body of the deleted file). If you just delete
drivers/net/ethernet/ibm/iseries_veth.c before trying to apply the patch
it will probably work.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the irqdomain tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 6:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-next, Paul Mackerras, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
Hi Grant,
Today's linux-next merge of the irqdomain tree got a conflict in
arch/powerpc/platforms/iseries/irq.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the tree
and three commits from the irqdomain tree.
I just removed the file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v3] powerpc/srio: Fix the compile errors when building with 64bit
From: Liu Gang @ 2012-03-09 8:10 UTC (permalink / raw)
To: linuxppc-dev, Alexandre.Bounine
Cc: r58472, linux-kernel, r61911, paul.gortmaker, Liu Gang, akpm,
Shaohui Xie
For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Changes in v2:
- Add the struct "rio_dbell_msg" to instead of some DBELL_* macros.
- Change the "virt_buf" to be "void *" type.
- Change "Signed-off-by" to "Reported-by" for Paul.
Changes in v3:
- Change the "%8.8lx" to be "%p" and remove the cast of the "buffer"
arch/powerpc/sysdev/fsl_rmu.c | 42 +++++++++++++++++++++-------------------
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..14bd522 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -100,14 +100,8 @@
#define DOORBELL_DSR_TE 0x00000080
#define DOORBELL_DSR_QFI 0x00000010
#define DOORBELL_DSR_DIQI 0x00000001
-#define DOORBELL_TID_OFFSET 0x02
-#define DOORBELL_SID_OFFSET 0x04
-#define DOORBELL_INFO_OFFSET 0x06
#define DOORBELL_MESSAGE_SIZE 0x08
-#define DBELL_SID(x) (*(u16 *)(x + DOORBELL_SID_OFFSET))
-#define DBELL_TID(x) (*(u16 *)(x + DOORBELL_TID_OFFSET))
-#define DBELL_INF(x) (*(u16 *)(x + DOORBELL_INFO_OFFSET))
struct rio_msg_regs {
u32 omr;
@@ -193,6 +187,13 @@ struct fsl_rmu {
int rxirq;
};
+struct rio_dbell_msg {
+ u16 pad1;
+ u16 tid;
+ u16 sid;
+ u16 info;
+};
+
/**
* fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
@@ -311,8 +312,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr & DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell->dbell_ring.virt +
+ struct rio_dbell_msg *dmsg =
+ fsl_dbell->dbell_ring.virt +
(in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -320,25 +321,25 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: processing doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg), DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid, dmsg->info);
for (i = 0; i < MAX_PORT_NUM; i++) {
if (fsl_dbell->mport[i]) {
list_for_each_entry(dbell,
&fsl_dbell->mport[i]->dbells, node) {
if ((dbell->res->start
- <= DBELL_INF(dmsg))
+ <= dmsg->info)
&& (dbell->res->end
- >= DBELL_INF(dmsg))) {
+ >= dmsg->info)) {
found = 1;
break;
}
}
if (found && dbell->dinb) {
dbell->dinb(fsl_dbell->mport[i],
- dbell->dev_id, DBELL_SID(dmsg),
- DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+ dbell->dev_id, dmsg->sid,
+ dmsg->tid,
+ dmsg->info);
break;
}
}
@@ -348,8 +349,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
("RIO: spurious doorbell,"
" sid %2.2x tid %2.2x info %4.4x\n",
- DBELL_SID(dmsg), DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+ dmsg->sid, dmsg->tid,
+ dmsg->info);
}
setbits32(&fsl_dbell->dbell_regs->dmr, DOORBELL_DMR_DI);
out_be32(&fsl_dbell->dbell_regs->dsr, DOORBELL_DSR_DIQI);
@@ -657,7 +658,7 @@ fsl_add_outb_message(struct rio_mport *mport, struct rio_dev *rdev, int mbox,
int ret = 0;
pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d buffer " \
- "%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer, len);
+ "%p len %8.8zx\n", rdev->destid, mbox, buffer, len);
if ((len < 8) || (len > RIO_MAX_MSG_SIZE)) {
ret = -EINVAL;
goto out;
@@ -972,7 +973,8 @@ out:
void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
{
struct fsl_rmu *rmu = GET_RMM_HANDLE(mport);
- u32 phys_buf, virt_buf;
+ u32 phys_buf;
+ void *virt_buf;
void *buf = NULL;
int buf_idx;
@@ -982,7 +984,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
if (phys_buf == in_be32(&rmu->msg_regs->ifqepar))
goto out2;
- virt_buf = (u32) rmu->msg_rx_ring.virt + (phys_buf
+ virt_buf = rmu->msg_rx_ring.virt + (phys_buf
- rmu->msg_rx_ring.phys);
buf_idx = (phys_buf - rmu->msg_rx_ring.phys) / RIO_MAX_MSG_SIZE;
buf = rmu->msg_rx_ring.virt_buffer[buf_idx];
@@ -994,7 +996,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
}
/* Copy max message size, caller is expected to allocate that big */
- memcpy(buf, (void *)virt_buf, RIO_MAX_MSG_SIZE);
+ memcpy(buf, virt_buf, RIO_MAX_MSG_SIZE);
/* Clear the available buffer */
rmu->msg_rx_ring.virt_buffer[buf_idx] = NULL;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Shawn Guo @ 2012-03-09 8:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Vinod Koul,
Barry Song, Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120306223321.GD15201@n2100.arm.linux.org.uk>
On Tue, Mar 06, 2012 at 10:33:21PM +0000, Russell King - ARM Linux wrote:
...
> drivers/dma/imx-sdma.c | 23 ++------
...
> drivers/dma/mxs-dma.c | 23 ++------
Tested-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
From: Josh Boyer @ 2012-03-09 11:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Neuling, open-source-review, Tirumala R Marri,
linux-kernel, Josh Boyer, Anton Blanchard, Mai La, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1331264145.3105.56.camel@pasglop>
On Thu, Mar 8, 2012 at 10:35 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote:
>> This patch consists of:
>> - Enable PCI MSI as default for Bluestone board
>> - Define number of MSI interrupt for Maui APM821xx SoC using in Blueston=
e board
>> - Fix returning ENODEV as finding MSI node
>> - Fix MSI physical high and low address
>> - Keep MSI data logically
>>
>> Signed-off-by: Mai La <mla@apm.com>
>> ---
>
>> index 7b4df37..c86231e 100644
>> --- a/arch/powerpc/sysdev/Kconfig
>> +++ b/arch/powerpc/sysdev/Kconfig
>> @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP
>> =A0 =A0 =A0 default y if FSL_PCI
>> =A0 =A0 =A0 default y if PPC4xx_MSI
>>
>> +config PPC4xx_NR_MSI_IRQS
>> + =A0 =A0 int "Number of PCI MSI interrupts"
>> + =A0 =A0 depends on PCI_MSI && PPC4xx_MSI
>> + =A0 =A0 default "4" if !APM821xx
>> + =A0 =A0 default "8" if APM821xx
>> +
>
> =A0.../...
>
>> +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS
>
> ARGH.
>
> We asked to -NOT MAKE THIS A COMPILE TIME OPTION-
Actually, I asked for basically exactly above. I was _wrong_ in asking,
but it was asked for.
> CONFIG_foo is as bad as your previous ifdef, in fact you just added a
> useless config option here.
>
> Make that number dynamic. Count the entries in the device-tree (or add
> a property with the number in it, whatever you fancy the most) but make
> it something detected at RUNTIME !!!!!
My apologies Mai. Ben is correct here and I should have thought more
about my suggestion before I made it.
josh
^ permalink raw reply
* Re: linux-next: manual merge of the driver-core tree with the powerpc tree
From: Greg KH @ 2012-03-09 15:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, linux-next, Alan Stern, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20120309164025.dc16cfacaa2ee35cbeea14a8@canb.auug.org.au>
On Fri, Mar 09, 2012 at 04:40:25PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/base/driver.c between commit fcd6f7620202 ("driver-core: remove
> legacy iSeries hack") from the powerpc tree and commit 9875bb480cc8
> ("Eliminate get_driver() and put_driver()") from the driver-core tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Looks good to me, thanks for doing this.
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Rob Herring @ 2012-03-09 16:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Neuling, Paul Mundt, linux-sh,
linux-kernel, linux-next, Paul Mackerras, linuxppc-dev,
Russell King
In-Reply-To: <1331262821.3105.47.camel@pasglop>
On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
>> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
>>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
>>> I remove it, then I get Kconfig warnings:
>>>
>>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
>>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
>>
>> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
>
> Nope, Grant patch didn't mention a dependency.
My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
simple solution was to just make it hidden. It wasn't clear if this was
desired or not for other arches at the time. There is a mixture of
settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
it user selectable for 64-bit.
I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
a hidden option. It really just needs the okay from SuperH folks.
Rob
^ permalink raw reply
* Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
From: Jesse Barnes @ 2012-03-09 18:28 UTC (permalink / raw)
To: Anton Blanchard; +Cc: sfr, yinghai, linuxppc-dev, linux-kernel
In-Reply-To: <20120309144645.5b5997d2@kryten>
On Fri, 9 Mar 2012 14:46:45 +1100
Anton Blanchard <anton@samba.org> wrote:
>
> Hi Ben,
>
> > Looks like something that got fixed but the new patches from Bjorn
> > aren't in next yet. I'll fwd you the patch separately to apply on
> > top of what you have see if that helps (to confirm that's indeed the
> > issue).
>
> Thanks, confirmed that it fixes it. Patch below in case anyone else is
> hitting it.
>
> Anton
>
> --
>
> On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote:
>
> > Or give me a chance to dig :-) I'll have a look next week.
>
> This is indeed what bjorn suspected on irc, this patch fixes it:
>
> (Bjorn, please fold it in the original offending patch)
Thanks guys; I'll push the fixes to -next when I get to a real network
(at the airport now about to run out of battery with a crappy
connection).
Jesse
^ permalink raw reply
* [PATCH][1/3][RFC] Adding documentation for TDM
From: Poonam Aggrwal @ 2012-03-10 12:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sandeep Singh, Poonam Aggrwal
From: Sandeep Singh <Sandeep@freescale.com>
tdm-summary.txt contains general description about TDM.
tdm-framework.txt contains specific description of TDM framework.
Signed-off-by: Sandeep Singh <Sandeep@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
---
Added the documentation to so that reviwers get the context.
Documentation/tdm/tdm-framework.txt | 257 +++++++++++++++++++++++++++++++++++
Documentation/tdm/tdm-summary.txt | 103 ++++++++++++++
2 files changed, 360 insertions(+), 0 deletions(-)
create mode 100644 Documentation/tdm/tdm-framework.txt
create mode 100644 Documentation/tdm/tdm-summary.txt
diff --git a/Documentation/tdm/tdm-framework.txt b/Documentation/tdm/tdm-framework.txt
new file mode 100644
index 0000000..9f0ca36
--- /dev/null
+++ b/Documentation/tdm/tdm-framework.txt
@@ -0,0 +1,257 @@
+This document gives an overview of TDM framework and its interface with
+low level drivers and upper level users/clients.
+
+Terminology:
+============
+1. Adapter or TDM adapter: Refers to an instance of TDM controller/device on
+ the system.
+2. TDM channel: The channel is the smallest entity on which all the TDM
+ read/write operations will occur.
+ Technically all channels map to a set of consecutive time slots on the
+ physical TDM frame.
+ The channels will be dynamically created and destroyed using
+ tdm_open_channel and tdm_close_channel.
+3. TDM frame: Is a set of TDM channels which is transmitted sequentially over
+ time. The frame start is identified by a frame sync signal that is briefly
+ asserted at the beginning of each frame.
+
+X----------TDM Frame 0-------------X------TDM Frame 1-----------------X
+|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
+| 0 | 1 | 2 | 3 | 4 | ...| n | 0 | 1 | 2 | 3 | 4 | ...| n |...
+|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
+<----> <---->
+ch 0 ch 0
+
+4. TDM client: Application/driver which registers with TDM framework to use TDM
+ device.
+5. TDM port: It can be seen as a virtual device exposed to a client. At a time
+ TDM port can work in one of the follwing configurations
+ full/fractional/E1/T1/raw.
+
+TDM modes
+========
+A TDM device can operate in one of the following modes:
+1. Single port full mode - Single user/no interleaving 2. Single port
+channelised mode (raw, E1, T1)- many users using different
+ channels
+3. Single port fractional mode -
+4. Multi port mode - multiple users using different ports in different
+ configurations.
+
+All the above configurations differ in number of TDM client they
+support, number of TDM channels and number of TDM ports.
+
+Currently we are supporting only single port channelised mode. Hence
+all the explanations below refer to channelised mode of TDM. This
+framework can be easily extended to support other modes.
+
+Single port Channelised Mode
+==============================
+In single port channelised mode there can be only one port and each
+channel can have only one time slot.The number of active channels can
+be less than the maximum supported channels/slots.
+
+X----------TDM Frame 0-------------X------TDM Frame 1-----------------X
+|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
+| 0 | 1 | 2 | 3 | 4 | ...| n | 0 | 1 | 2 | 3 | 4 | ...| n |...
+|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
+<----><---> <----><--->
+ch0 ch1 ch0 ch1
+client0 client1
+
+TDM Subsystem Overview
+========================
+
+ |-----------------------|
+ |user mode TDM clients |
+ |-----------------------|
+ ||
+-------------------------------------------------------------------
+ tdm-dev.c ||
+ ||
+ || |------------------------|
+ client register | kernel mode TDM clients|
+ || |------------------------|
+ || ||
+ || ||
+ || client register
+ || ||
+ \/ \/
+ ______________________________________________________________
+ | |
+ | client interface |
+ |------------------------------------------------------------|
+ | TDM Subsystem Framework |
+ | (tdm-core.c) |
+ | |
+ | ->buffer handling |
+ | ->interleaving/de-interleaving |
+ | |
+ |------------------------------------------------------------|
+ | TDM interface Line control interface |
+ |____________________________________________________________|
+ /\ /\
+ || ||
+ device register device register
+ || ||
+ || ||
+
+ fsl_tdm.c ucc_tdm.c slic_zarlink.c framer.c
+--------------------------------------------------------------------------
+_______________________ _____________________ ________ ________
+| | | | | | | |
+|[h/w] TDM controller | |UCC TDM controller | | SLIC | |Framer|
+|_____________________| |___________________| |______| |______|
+
+
+
+TDM Adapter Registration:
+=========================
+All the TDM adapter drivers will get registered as platform drivers to Linux.
+For every instance of the TDM adapter the relevant driver will be probed.
+As part of probe the driver will
+1. Do the basic initialization in terms of memory allocation for various
+ driver specific data structures, interrupts registration, etc.
+2. Initialize the TDM adapter and configure it in default configuration.
+ like operating mode, number of channels, channel type, etc.
+3. Add the TDM adapter to the TDM Framework via tdm_add_adapter() API.
+ As a result TDM framework will add this adapter to it's queue of
+ available adapters. As part of this adapter registration TDM framework
+ is also supplied a list of access algorithms for the particular TDM
+ adapter.
+4. Notifies the clients
+
+TDM Client Registration:
+========================
+Every TDM client gets itself registered with the TDM framework layer as
+a TDM driver using the API tdm_add_driver(). As part of this the TDM
+client supplies to the TDM framework the adapter with which it wants to
+hook and the function pointers of attach and detach functions which
+must be called as soon as the requested adapter is available.
+
+As a result the TDM framework keeps association of TDM adapters and TDM
+client drivers.
+As soon as this association gets established a tasklet is created for
+the adapter which is handled by tdm_data_tasklet_fn. The primary
+function of this tasklet acts as an interface to transfer the TDM data
+between the TDM adapter and the TDM client drivers.
+
+
+Currently TDM adaper can only be used in the default configuration.
+ie the configuration cannot be modified by TDM clients. This will be
+enhanced in future.
+
+Data handling:
+==============
+Some basic assumptions about data handling:
+
+1. As per standard voice rate of 8Khz or 8192Hz. Which means 8192
+samples must be sent every second. So if there are multiple clients
+sending voice data over TDM interface the rate should be such that the
+individual samples sent by them must be transmitted at 8Kz.
+
+This is defined in the driver as
+
+#define CH_1_MS_FRAMES 8
+
+2. Number of milliseconds at which TDM Rx interrupts occur This is
+basically the time for which the TDM data is sent in one Tx or Rx cycle
+of TDM controller hardware. In one DMA we send the data for 10ms.
+This gives enough time so that no buffer overflow or under-run occurs
+for transmit and receive respectively.
+
+#define NUM_MS 10
+
+3. TDM has programmable slot length (8 bits or 16 bits). This can be
+configured by depending on the type of sample. For example the sample
+could be 16 bit linear or 8bit u-law encoded etc. Presently only word
+length of 16 is supported which is the default configuration.
+
+4. Number of channels means the total number of channels per TDM port.
+For example for E1 mode it will be 24, for T1 it will be 32, etc.
+There can also be raw mode, where the use case is not E1 or T1.
+Here the number of channels can be any number as per the use case.
+
+The whole framework follows a triple buffer approach to make sure that
+TDM data is played continuously at the desired rate.
+
+Buffers Involved:
+=================
+
+1.TDM driver or device buffers:
+These buffers are the device level buffers. They contain the TDM data
+which is transmitted/received on the TDM physical signals. As such
+these buffers must be allocated from driver layer so that all the hardware requirements are met.
+As an optimized design to remove extra memcopies, the client can pass
+the data in the same buffers. But this is only true for full mode of
+TDM. Where the user data can be straightaway passed to the hardware for transmission.
+Although in other cases memcopy cannot be avoided, because the
+framework layer will have to interleave the individual channels data to
+create the TDM frame data buffer.For channelised mode size of this buffer will be governed by:
+
+-number of channels
+-number of slots per channel
+-number of bytes per slot
+-number of frames per ms
+-number of ms
+
+For a channelised mode with single port the size of the device level
+buffer will be:
+
+channels * slots per channel * bytes per slot * frames per ms * number of ms
+
+There will be 3 such buffers.
+
+2.Channel level buffers:
+In case the TDM device is configured for multiport/multichannel the
+Framework layer needs to maintain the data for each channel. Hence for
+each channel opened a Buffer Descriptor ring of 3 BDs(see note below)
+is allocated both for transmit and receive. The client reads
+from/writes to the buffers pointed by these BD rings.
+
+The framework layer maintains a Data Process Tasklet per TDM device
+which is scheduled from every Rx interrupt. The interrupt handling
+periodicity is governed by the TDM data buffer size configured in the
+above section. The data tasklet when scheduled, will do Rx and Tx
+processing to copy the data from/to the channel specific interleaved
+buffers. The TDM controller will DMA the data which is copied in the interleaved buffers or device level buffers.
+
+TDM framework provides the port level APIs and channel level APIs to
+the TDM client drivers to send and receive the respective data on different TDM slots.
+
+
+num of buffers = 3
+
+TDM client1 TDM Client2
+
+buf0------->buf1 buf0------->buf1
+^ | ^ |
+| V | V
+----buf2------ ------buf2----
+ | |
+ | |
+ | |
+ V V
+-----------------------------------------
+| |
+| DATA Tasklet |
+| |
+-----------------------------------------
+ |
+ |
+ V
+-----------------------------------------
+| TDM buffer interleaved * 3 |
+-----------------------------------------
+
+
+Not Implemented/Future work:
+============================
+1. TDM client will use the default configuration which is done at init time
+ and is not configurable. In future this should be made configurable as per
+ the needs of client.
+2. The TDM framework still needs to be enhanced to configure the ports and
+ their attributes. Currently only single port channelised mode is supported.
+3. Line control interface is not available in the framework presently.
+ Presently it offer very minimal kind of interface.
+4. SLIC interface will be enhanced as per Zarlink Open source APIs in future.
diff --git a/Documentation/tdm/tdm-summary.txt b/Documentation/tdm/tdm-summary.txt
new file mode 100644
index 0000000..d2e6eca
--- /dev/null
+++ b/Documentation/tdm/tdm-summary.txt
@@ -0,0 +1,103 @@
+Time-Division Multiplexing (TDM)
+=================================
+
+TDM is a type of digital or analog multiplexing in which two or more
+bit streams or signals are transferred apparently simultaneously as
+sub-channels in one communication channel, but are physically taking turns on the channel.
+
+The time domain is divided into several recurrent timeslots of fixed duration.
+These timeslot are grouped together to form a channel. A sample byte or
+data block of channel 1 is transmitted during timeslots allocated to
+channel 1, channel 2 during timeslot for channel 2, etc.
+
+One TDM frame consists of multiple channels. After the last channel the
+cycle starts all over again with a new frame, starting with the second
+sample, byte or data block from channel 1, and so on.
+
+X----------TDM Frame 0-------------X------TDM Frame 1-----------------X
+|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
+| 0 | 1 | 2 | 3 | 4 | ...| n | 0 | 1 | 2 | 3 | 4 | ...| n |...
+|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
+<----> <---->
+channel 0 channel 0
+-------------------------------------------------------------------->
+ Increasing Time
+
+Physical TDM interface
+=======================
+
+Physically TDM interface is a serial full duplex interface designed to
+communicate with variety of serial devices like industry standard
+framers, codecs, other DSPs, and microprocessors. It is typically used
+to transfer samples in a periodic manner. The TDM consists of
+independent transmitter and receiver sections with independent clock generation and frame synchronization.
+
+External TDM signals are:
+1. TDM_TCK: TDM Transmit clock
+2. TDM_RCK: TDM Receive clock
+3. TDM_TFS: TDM Tx frame sync to identify frame boundary 4. TDM_RFS:
+TDM Rx Frame sync to identify frame boundary 5. TDM_TD: TDM Tx data 6.
+TDM_RD: TDM Rx data
+
+TDM is generally used to simultaneously transmit periodic data for
+multiple users. Common use cases would be to carry voice for various
+telephone subscribers in the telephone networks. It is widely used to
+carry telephonic data of various industry standards like E1/T1 data, etc.
+
+T1 Details
+==========
+T1 frame consists of 24 channels of 8 bits each plus one frame alignment bit.
+So a T1 frame has a total of 24x8 + 1 = 193 bits. Since each T1 frame
+contains one byte of voice data for each of 24 channels and the system
+needs to maintain a data rate of 8000 samples/sec. This would require
+8000 frames/sec to be sent, yielding a data rate of 8000x193 bit/sec = 1.544 Mbps.
+
+E1 Details
+===========
+E1 frame consists of 32 channels each of 8 bits. Thus having a total
+frame length of 32x8 = 256 bits. Similar to the case of T1 it has to
+maintain a data rate of 8000 frames/sec. Thus having a data rate of
+8000 x 256 bits/sec =
+2.048 Mbps.
+
+TDM use cases
+=============
+
+With SLIC kind of devices
+=========================
+
+Typically TDM systems consist of TDM controller and a line control device.
+
+The TDM controller interfaces to the line control device through TDM
+interface which is digital TDM multiplexed data.
+
+The Line controller has the functionality to interface with the TDM
+controller at one end and interface with the analog units at the other.
+For example if the Line control device is a SLIC kind of device.
+The typical setup would be:
+
+|------------------|
+| |
+| | /-------\ |---------|
+| TDM controller |/ TDM \ | SLIC |<--------> s-ch0 analog phone 1
+| |\ data / | |<--------> s-ch1 analog phone 2
+| | \-------/ |---------|<--------> s-ch2 analog phone 3
+| |< digital > <analog>
+|------------------|
+
+
+
+Another use case (VoIP):
+========================
+
+ Voice packets on network
+ |--------| |------| _________ |------| |------|
+>----| |/---\| TDM | ( ) | TDM |/---\| |----->
+<----| SLIC |\---/| | ( n/w ) | |\---/| SLIC |-----<
+>----| | |------| --------- |------| | |----->
+ |--------| mux demux |------|
+
+In the above figure analog phones are connected to the hosts via SLICs.
+The voice spoken on the phones is multiplexed converted into VoIP
+packets and sent over network. At the rendering end the multiplexed
+data is de-multiplexed and sent to respective listeners via SLIC.
--
1.5.6.5
^ 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