* Re: [PATCH RFC 50/77] mlx5: Update MSI/MSI-X interrupts enablement code
From: Eli Cohen @ 2013-10-03 7:14 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
linux390, linuxppc-dev
In-Reply-To: <9650a7dfbcfd5f1da21f7b093665abf4b1041071.1380703263.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:49:06PM +0200, Alexander Gordeev wrote:
>
> + err = pci_msix_table_size(dev->pdev);
> + if (err < 0)
> + return err;
> +
> nvec = dev->caps.num_ports * num_online_cpus() + MLX5_EQ_VEC_COMP_BASE;
> nvec = min_t(int, nvec, num_eqs);
> + nvec = min_t(int, nvec, err);
> if (nvec <= MLX5_EQ_VEC_COMP_BASE)
> return -ENOSPC;
Making sure we don't request more vectors then the device's is capable
of -- looks good.
>
> @@ -131,20 +136,15 @@ static int mlx5_enable_msix(struct mlx5_core_dev *dev)
> for (i = 0; i < nvec; i++)
> table->msix_arr[i].entry = i;
>
> -retry:
> - table->num_comp_vectors = nvec - MLX5_EQ_VEC_COMP_BASE;
> err = pci_enable_msix(dev->pdev, table->msix_arr, nvec);
> - if (err <= 0) {
> + if (err) {
> + kfree(table->msix_arr);
> return err;
> - } else if (err > MLX5_EQ_VEC_COMP_BASE) {
> - nvec = err;
> - goto retry;
> }
>
According to latest sources, pci_enable_msix() may still fail so why
do you want to remove this code?
> - mlx5_core_dbg(dev, "received %d MSI vectors out of %d requested\n", err, nvec);
> - kfree(table->msix_arr);
> + table->num_comp_vectors = nvec - MLX5_EQ_VEC_COMP_BASE;
>
> - return -ENOSPC;
> + return 0;
> }
>
> static void mlx5_disable_msix(struct mlx5_core_dev *dev)
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-03 6:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <1380751642.645.71.camel@pasglop>
On Thu, Oct 03, 2013 at 08:07:22AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
>
> > Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> > interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> > use hypercall instead of emulating the device (in kernel or somewhere
> > else?). Another things is that on a host hwrnd is protected from
> > direct userspace access by virtue of been a device, but guest code (event
> > kernel mode) is userspace as far as hosts security model goes, so by
> > implementing this hypercall in a way that directly access hwrnd you
> > expose hwrnd to a userspace unconditionally. Why is this a good idea?
>
> BTW. Is this always going to be like this ?
>
If something questionable will be noticed explanation will be required.
It is like that for all arches and all parts of kernel.
> Every *single* architectural or design decision we make for our
> architecture has to be justified 30 times over, every piece of code bike
> shedded to oblivion for month, etc... ?
>
This is simply not true, most powerpc patches go in without any comments.
> Do we always have to finally get to some kind of agreement on design, go
> to the 6 month bike-shedding phase, just to have somebody else come up
> and start re-questioning the whole original design (without any
> understanding of our specific constraints of course) ?
>
Do you really think that nobody here understands that exit to userspace
is slow?
> You guys are the most horrendous community I have ever got to work with.
> It's simply impossible to get anything done in any reasonable time
> frame .
>
> At this stage, it would have taken us an order of magnitude less time to
> simply rewrite an entire hypervisor from scratch.
Of course, it is always much easier to ignore other people input and do
everything your way. Why listen to people who deal with migration issues
for many years if you can commit the patch and forget about it until
migration fails, but who cares, you got there in an order of magnitude
less time and this is what counts.
>
> This is sad.
>
Agree.
--
Gleb.
^ permalink raw reply
* Re: [PATCH 6/9][v5] powerpc/perf: Define big-endian version of perf_mem_data_src
From: Sukadev Bhattiprolu @ 2013-10-03 6:20 UTC (permalink / raw)
To: Michael Ellerman
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <20131003053944.GD17237@concordia>
Michael Ellerman [michael@ellerman.id.au] wrote:
| On Tue, Oct 01, 2013 at 05:15:07PM -0700, Sukadev Bhattiprolu wrote:
| > perf_mem_data_src is an union that is initialized via the ->val field
| > and accessed via the bitmap fields. For this to work on big endian
| > platforms, we also need a big-endian represenation of perf_mem_data_src.
| >
| > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
| > index ca1d90b..846f399 100644
| > --- a/include/uapi/linux/perf_event.h
| > +++ b/include/uapi/linux/perf_event.h
| > @@ -19,6 +19,50 @@
| > #include <asm/byteorder.h>
| >
| > /*
| > + * Kernel and userspace check for endianness in incompatible ways.
| > + * In user space, <endian.h> defines both __BIG_ENDIAN and __LITTLE_ENDIAN
| > + * but sets __BYTE_ORDER to one or the other. So user space uses checks are:
|
|
| Why can't you use __BIG_ENDIAN_BITFIELD ?
That macro is not available when building the perf tool - bc there is
a util/include/asm/byterorder.h which gets included instead of the
usual <asm/byteorder.h>.
|
| cheers
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-03 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <1380752480.645.74.camel@pasglop>
On Thu, Oct 03, 2013 at 08:21:20AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-10-02 at 17:37 +0300, Gleb Natapov wrote:
> > On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
> > > Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > > > > The hwrng is accessible by host userspace via /dev/mem.
> > > >
> > > > A guest should live on the same permission level as a user space
> > > > application. If you run QEMU as UID 1000 without access to /dev/mem, why
> > > > should the guest suddenly be able to directly access a memory location
> > > > (MMIO) it couldn't access directly through a normal user space interface.
> > > >
> > > > It's basically a layering violation.
> > >
> > > With Michael's earlier patch in this series, the hwrng is accessible by
> > > host userspace via /dev/hwrng, no?
> > >
> > Access to which can be controlled by its permission. Permission of
> > /dev/kvm may be different. If we route hypercall via userspace and
> > configure qemu to get entropy from /dev/hwrng everything will fall
> > nicely together (except performance).
>
> Yes, except abysmall performance and a lot more code for something
> completely and utterly pointless .... nice.
>
Pointless? You yourself said that fallback to userspace will be required
for migration, so the code have to be there regardless. About abysmal
performance this is what you repeatedly refused to prove. All you
said is that exit to userspace is expensive, we all know that, it is
slow for all arch and all devices implemented in usrerspace, but we do
not move all of them to the kernel. We do move some, most performance
critical, so all you need to show that for typical guest workload having
device in the kernel speed up things measurably. Why not do that instead
of writing rude emails?
--
Gleb.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-03 5:48 UTC (permalink / raw)
To: Paul Mackerras
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, mpm, Paolo Bonzini
In-Reply-To: <20131002224542.GA10016@iris.ozlabs.ibm.com>
On Thu, Oct 03, 2013 at 08:45:42AM +1000, Paul Mackerras wrote:
> On Wed, Oct 02, 2013 at 04:36:05PM +0200, Alexander Graf wrote:
> >
> > On 02.10.2013, at 16:33, Paolo Bonzini wrote:
> >
> > > Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > >>> The hwrng is accessible by host userspace via /dev/mem.
> > >>
> > >> A guest should live on the same permission level as a user space
> > >> application. If you run QEMU as UID 1000 without access to /dev/mem, why
> > >> should the guest suddenly be able to directly access a memory location
> > >> (MMIO) it couldn't access directly through a normal user space interface.
> > >>
> > >> It's basically a layering violation.
> > >
> > > With Michael's earlier patch in this series, the hwrng is accessible by
> > > host userspace via /dev/hwrng, no?
> >
> > Yes, but there's not token from user space that gets passed into the kernel to check whether access is ok or not. So while QEMU may not have permission to open /dev/hwrng it could spawn a guest that opens it, drains all entropy out of it and thus stall other processes which try to fetch entropy, no?
>
> Even if you drain all entropy out of it, wait 64 microseconds and it
> will be full again. :) Basically it produces 64 bits every
> microsecond and puts that in a 64 entry x 64-bit FIFO buffer, which is
> what is read by the MMIO. So there is no danger of stalling other
> processes for any significant amount of time.
>
Even if user crates 100s guests each one of which reads hwrng in a loop?
--
Gleb.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Gleb Natapov @ 2013-10-03 5:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <1380751340.645.68.camel@pasglop>
On Thu, Oct 03, 2013 at 08:02:20AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
>
> > Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> > interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> > use hypercall instead of emulating the device (in kernel or somewhere
> > else?).
>
> Migration will have to be dealt with one way or another, I suppose we
> will indeed need a qemu fallback.
>
So at least from amount of code perspective userspace and kernel space
solutions are on par since later will require former anyway.
What about other direction? Migration from KVM that does not have the
hypercall to one that has? We try to not change HW under a guest.
> As for why hypercall instead of MMIO, well, you'd have to ask the folks
> who wrote the PAPR spec :-) It's specified as a hypercall and
> implemented as such in pHyp (PowerVM). The existing guests expect it
> that way.
OK.
>
> It might have to do with the required whitening done by the hypervisor
> (H_RANDOM output is supposed to be clean). It also abstracts us from the
> underlying HW implementation which could in theory change.
>
But I guess bare metal OS has to know how to do whitening and deal with
HW change already. Anyway this is not the place to discuss PAPR
decisions. Thanks for insights.
> > Another things is that on a host hwrnd is protected from
> > direct userspace access by virtue of been a device, but guest code (event
> > kernel mode) is userspace as far as hosts security model goes, so by
> > implementing this hypercall in a way that directly access hwrnd you
> > expose hwrnd to a userspace unconditionally. Why is this a good idea?
>
> Why would this be a bad idea ?
>
When you elevate privilege you need to explain why it is not harmful
and why the privilege was restricted in the first place. /dev/hwrng
that first patch created gives access only to root, this patch changes
it to whoever can create a guest.
Why it can be a bad idea? User can drain hwrng continuously making other
users of it much slower, or even worse, making them fall back to another
much less reliable, source of entropy.
--
Gleb.
^ permalink raw reply
* Re: [PATCH 6/9][v5] powerpc/perf: Define big-endian version of perf_mem_data_src
From: Michael Ellerman @ 2013-10-03 5:39 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <1380672911-12812-7-git-send-email-sukadev@linux.vnet.ibm.com>
On Tue, Oct 01, 2013 at 05:15:07PM -0700, Sukadev Bhattiprolu wrote:
> perf_mem_data_src is an union that is initialized via the ->val field
> and accessed via the bitmap fields. For this to work on big endian
> platforms, we also need a big-endian represenation of perf_mem_data_src.
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index ca1d90b..846f399 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -19,6 +19,50 @@
> #include <asm/byteorder.h>
>
> /*
> + * Kernel and userspace check for endianness in incompatible ways.
> + * In user space, <endian.h> defines both __BIG_ENDIAN and __LITTLE_ENDIAN
> + * but sets __BYTE_ORDER to one or the other. So user space uses checks are:
Why can't you use __BIG_ENDIAN_BITFIELD ?
cheers
^ permalink raw reply
* Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
From: Michael Ellerman @ 2013-10-03 5:35 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <1380672911-12812-6-git-send-email-sukadev@linux.vnet.ibm.com>
On Tue, Oct 01, 2013 at 05:15:06PM -0700, Sukadev Bhattiprolu wrote:
> Implement is_instr_load_store() to detect whether a given instruction
> is one of the fixed-point or floating-point load/store instructions.
> This function will be used in a follow-on patch to save memory hierarchy
> information of the load/store.
The search over the array is a bit of a pity, especially as the worst
case penalises you when you haven't hit a load/store.
I think we can do better. If you look at the opcode maps, and in
particular the extended table for opcode 31, you'll see there's a
reasonable amount of structure.
The following is only valid for arch 2.06, ie. it will classify reserved
opcodes as being load/store, but I think that's fine for the moment. If
we need to use it somewhere in future we can update it. But we should
add a big comment saying it's only valid in that case.
Anyway, I think the following logic is all we need for opcode 31:
bool is_load_store(int ext_opcode)
{
upper = ext_opcode >> 5;
lower = ext_opcode & 0x1f;
/* Short circuit as many misses as we can */
if (lower < 3 || lower > 23)
return false;
if (lower == 3)
if (upper >= 16)
return true;
return false;
if (lower == 6)
if (upper <= 1)
return true;
return false;
if (lower == 7 || lower == 12)
return true;
if (lower >= 20) /* && lower <= 23 (implicit) */
return true;
return false;
}
Which is not pretty, but I think it's preferable to the full search over the
array.
cheers
^ permalink raw reply
* [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check
From: Guenter Roeck @ 2013-10-03 4:15 UTC (permalink / raw)
To: alsa-devel
Cc: Timur Tabi, Takashi Iwai, linux-kernel, Liam Girdwood,
Jaroslav Kysela, Mark Brown, Geert Uytterhoeven, Grant Likely,
linuxppc-dev, Guenter Roeck
irq_of_parse_and_map() returns 0 on error, not NO_IRQ.
Fix the following xtensa:allmodconfig build error.
sound/soc/fsl/fsl_ssi.c:705:26: error: 'NO_IRQ' undeclared (first use in this function)
make[4]: *** [sound/soc/fsl/fsl_ssi.o] Error 1
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
Previously submitted by Grant Likely as part of a different patch set.
See https://lkml.org/lkml/2012/1/11/342.
Also see https://lkml.org/lkml/2013/7/25/642.
sound/soc/fsl/fsl_ssi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index c6b7439..6b81d0c 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -936,7 +936,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->ssi_phys = res.start;
ssi_private->irq = irq_of_parse_and_map(np, 0);
- if (ssi_private->irq == NO_IRQ) {
+ if (ssi_private->irq == 0) {
dev_err(&pdev->dev, "no irq for node %s\n", np->full_name);
return -ENXIO;
}
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH] kvm: powerpc: book3s: Fix build break for BOOK3S_32
From: Paul Mackerras @ 2013-10-03 4:14 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <1380724724-12892-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Wed, Oct 02, 2013 at 08:08:44PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> This was introduced by 85a0d845d8bb5df5d2669416212f56cbe1474c6b
It's a good idea to give the headline of the commit as well as the ID.
I also like to trim the ID to 10 characters or so. So it should look
like this:
This was introduced by 85a0d845d8 ("KVM: PPC: Book3S PR: Allocate
kvm_vcpu structs from kvm_vcpu_cache").
> arch/powerpc/kvm/book3s_pr.c: In function 'kvmppc_core_vcpu_create':
> arch/powerpc/kvm/book3s_pr.c:1182:30: error: 'struct kvmppc_vcpu_book3s' has no member named 'shadow_vcpu'
> make[1]: *** [arch/powerpc/kvm/book3s_pr.o] Error 1
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Paul.
^ permalink raw reply
* Re: [PATCH 2/9][v5] powerpc/perf: Export Power8 generic events in sysfs
From: Michael Ellerman @ 2013-10-03 4:04 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <1380672911-12812-3-git-send-email-sukadev@linux.vnet.ibm.com>
On Tue, Oct 01, 2013 at 05:15:03PM -0700, Sukadev Bhattiprolu wrote:
> Export generic perf events for Power8 in sysfs.
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Reviewed-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/power8-pmu.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
> index 976c203..b991b2e 100644
> --- a/arch/powerpc/perf/power8-pmu.c
> +++ b/arch/powerpc/perf/power8-pmu.c
> @@ -510,6 +510,28 @@ static void power8_disable_pmc(unsigned int pmc, unsigned long mmcr[])
> mmcr[1] &= ~(0xffUL << MMCR1_PMCSEL_SHIFT(pmc + 1));
> }
>
> +GENERIC_EVENT_ATTR(cpu-cyles, PM_CYC);
> +GENERIC_EVENT_ATTR(stalled-cycles-frontend, PM_GCT_NOSLOT_CYC);
> +GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL);
> +GENERIC_EVENT_ATTR(instructions, PM_INST_CMPL);
> +GENERIC_EVENT_ATTR(branch-instructions, PM_BRU_FIN);
> +GENERIC_EVENT_ATTR(branch-misses, PM_BR_MPRED_CMPL);
And here you use PM_ not PME_ - I'm confused.
cheers
^ permalink raw reply
* Re: [PATCH 1/9][v5] powerpc/perf: Rename Power8 macros to start with PME
From: Michael Ellerman @ 2013-10-03 4:02 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <1380672911-12812-2-git-send-email-sukadev@linux.vnet.ibm.com>
On Tue, Oct 01, 2013 at 05:15:02PM -0700, Sukadev Bhattiprolu wrote:
> We use helpers like GENERIC_EVENT_ATTR() to list the generic events in
> sysfs. To avoid name collisions, GENERIC_EVENT_ATTR() requires the perf
> event macros to start with PME.
It's a bit unfortunate, because they no longer match the documentation,
or any of the comments. Are we seeing actual name collisions with PM_,
or is it just a theoretical worry?
cheers
^ permalink raw reply
* [PATCH 2/2][v8] powerpc/fsl-booke: Add initial T104x_QDS board support
From: Prabhakar Kushwaha @ 2013-10-03 3:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Poonam Aggrwal, Prabhakar Kushwaha, Priyanka Jain
Add support for T104x board in board file t104x_qds.c, It is common for
both T1040 and T1042 as they share same QDS board.
T1040QDS board Overview
-----------------------
- SERDES Connections, 8 lanes supporting:
=E2=80=94 PCI Express: supporting Gen 1 and Gen 2;
=E2=80=94 SGMII
=E2=80=94 QSGMII
=E2=80=94 SATA 2.0
=E2=80=94 Aurora debug with dedicated connectors (T1040 only)
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank t=
ypes.
-IFC/Local Bus
- NAND flash: 8-bit, async, up to 2GB.
- NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB
- GASIC: Simple (minimal) target within Qixis FPGA
- PromJET rapid memory download support
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep (T1040 only)
- QIXIS System Logic FPGA
- Clocks
- System and DDR clock (SYSCLK, =E2=80=9CDDRCLK=E2=80=9D)
- SERDES clocks
- Power Supplies
- Video
- DIU supports video at up to 1280x1024x32bpp
- USB
- Supports two USB 2.0 ports with integrated PHYs
=E2=80=94 Two type A ports with 5V@1.5A per port.
=E2=80=94 Second port can be converted to OTG mini-AB
- SDHC
- SDHC port connects directly to an adapter card slot, featuring:
- Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC
=E2=80=94 Supporting eMMC memory devices
- SPI
- On-board support of 3 different devices and sizes
- Other IO
- Two Serial ports
- ProfiBus port
- Four I2C ports
Add T104xQDS support in Kconfig and Makefile. Also create device tree.
Following features are currently not implmented.
- SerDes: Aurora
- IFC: GASIC, Promjet
- QIXIS
- Ethernet
- DIU
- power supplies management
- ProfiBus
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.gi=
t
Branch merge
Changes for v2: Incorporated Scott's comments
- Created t104xqds.dtsi, both t1040qds & t1042qds include it
- Updated get_irq=20
Changes for v3: Sending as it is
Changes for v4: Updated description
Changes for v5: Incorporated Scott's comments
- Ported on top of Kevin's patch
Changes for v6: Updated depedencies
Changes for v7: Incororated Scott's commetns
- Create patch set
changes for v8: Sending as it is
=20
This patch depends upon followng patches in mentioned order
1) powerpc/b4qds: enable coreint
http://patchwork.ozlabs.org/patch/274390/
2) powerpc/85xx: introduce corenet_generic machine
http://patchwork.ozlabs.org/patch/278067/
3) powerpc/85xx: rename the corenet_ds.c to corenet_generic.c
http://patchwork.ozlabs.org/patch/278072/
4) powerpc/85xx: use one kernel option for all the CoreNet_Generic board=
s
http://patchwork.ozlabs.org/patch/278073/
arch/powerpc/boot/dts/t1040qds.dts | 46 ++++++
arch/powerpc/boot/dts/t1042qds.dts | 46 ++++++
arch/powerpc/boot/dts/t104xqds.dtsi | 192 +++++++++++++++++++=
++++++
arch/powerpc/platforms/85xx/corenet_generic.c | 4 +
4 files changed, 288 insertions(+)
create mode 100644 arch/powerpc/boot/dts/t1040qds.dts
create mode 100644 arch/powerpc/boot/dts/t1042qds.dts
create mode 100644 arch/powerpc/boot/dts/t104xqds.dtsi
diff --git a/arch/powerpc/boot/dts/t1040qds.dts b/arch/powerpc/boot/dts/t=
1040qds.dts
new file mode 100644
index 0000000..973c29c
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040qds.dts
@@ -0,0 +1,46 @@
+/*
+ * T1040QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission=
.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xqds.dtsi"
+
+/ {
+ model =3D "fsl,T1040QDS";
+ compatible =3D "fsl,T1040QDS";
+ #address-cells =3D <2>;
+ #size-cells =3D <2>;
+ interrupt-parent =3D <&mpic>;
+};
+
+/include/ "fsl/t1040si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t1042qds.dts b/arch/powerpc/boot/dts/t=
1042qds.dts
new file mode 100644
index 0000000..45bd037
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042qds.dts
@@ -0,0 +1,46 @@
+/*
+ * T1042QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission=
.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/t104xsi-pre.dtsi"
+/include/ "t104xqds.dtsi"
+
+/ {
+ model =3D "fsl,T1042QDS";
+ compatible =3D "fsl,T1042QDS";
+ #address-cells =3D <2>;
+ #size-cells =3D <2>;
+ interrupt-parent =3D <&mpic>;
+};
+
+/include/ "fsl/t1042si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t104xqds.dtsi b/arch/powerpc/boot/dts/=
t104xqds.dtsi
new file mode 100644
index 0000000..5a518b3
--- /dev/null
+++ b/arch/powerpc/boot/dts/t104xqds.dtsi
@@ -0,0 +1,192 @@
+/*
+ * T104xQDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions ar=
e met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyrig=
ht
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission=
.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of th=
e
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMP=
LIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AR=
E
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR A=
NY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DA=
MAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SE=
RVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUS=
ED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR=
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE=
OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+ model =3D "fsl,T1040QDS";
+ compatible =3D "fsl,T1040QDS";
+ #address-cells =3D <2>;
+ #size-cells =3D <2>;
+ interrupt-parent =3D <&mpic>;
+
+ ifc: localbus@ffe124000 {
+ reg =3D <0xf 0xfe124000 0 0x2000>;
+ ranges =3D <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "cfi-flash";
+ reg =3D <0x0 0x0 0x8000000>;
+
+ bank-width =3D <2>;
+ device-width =3D <1>;
+ };
+
+ nand@2,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "fsl,ifc-nand";
+ reg =3D <0x2 0x0 0x10000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg =3D <0x0 0x00100000>;
+ label =3D "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg =3D <0x00100000 0x00100000>;
+ label =3D "NAND DTB Image";
+ };
+
+ partition@200000 {
+ /* 10MB for Linux Kernel Image */
+ reg =3D <0x00200000 0x00A00000>;
+ label =3D "NAND Linux Kernel Image";
+ };
+
+ partition@C00000 {
+ /* 500MB for Root file System Image */
+ reg =3D <0x00c00000 0x1F400000>;
+ label =3D "NAND RFS Image";
+ };
+ };
+
+ board-control@3,0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "fsl,tetra-fpga", "fsl,fpga-qixis";
+ reg =3D <3 0 0x300>;
+ };
+ };
+
+ memory {
+ device_type =3D "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges =3D <0x00000000 0xf 0x00000000 0x01072000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges =3D <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg =3D <0xf 0xfe000000 0 0x00001000>;
+ spi@110000 {
+ flash@0 {
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ compatible =3D "micron,n25q512a";
+ reg =3D <0>;
+ spi-max-frequency =3D <10000000>; /* input clock */
+ };
+ };
+
+ i2c@118000 {
+ pca9547@77 {
+ compatible =3D "philips,pca9547";
+ reg =3D <0x77>;
+ };
+ rtc@68 {
+ compatible =3D "dallas,ds3232";
+ reg =3D <0x68>;
+ interrupts =3D <0x1 0x1 0 0>;
+ };
+ };
+ };
+
+ pci0: pcie@ffe240000 {
+ reg =3D <0xf 0xfe240000 0 0x10000>;
+ ranges =3D <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges =3D <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe250000 {
+ reg =3D <0xf 0xfe250000 0 0x10000>;
+ ranges =3D <0x02000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ pcie@0 {
+ ranges =3D <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe260000 {
+ reg =3D <0xf 0xfe260000 0 0x1000>;
+ ranges =3D <0x02000000 0 0xe0000000 0xc 0x40000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ pcie@0 {
+ ranges =3D <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@ffe270000 {
+ reg =3D <0xf 0xfe270000 0 0x10000>;
+ ranges =3D <0x02000000 0 0xe0000000 0xc 0x60000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+ pcie@0 {
+ ranges =3D <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc=
/platforms/85xx/corenet_generic.c
index fbd871e..f4a7621 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -106,6 +106,8 @@ static const char * const boards[] __initconst =3D {
"fsl,B4860QDS",
"fsl,B4420QDS",
"fsl,B4220QDS",
+ "fsl,T1040QDS",
+ "fsl,T1042QDS",
NULL
};
=20
@@ -119,6 +121,8 @@ static const char * const hv_boards[] __initconst =3D=
{
"fsl,B4860QDS-hv",
"fsl,B4420QDS-hv",
"fsl,B4220QDS-hv",
+ "fsl,T1040QDS-hv",
+ "fsl,T1042QDS-hv",
NULL
};
=20
--=20
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2][v8] powerpc/mpc85xx:Add initial device tree support of T104x
From: Prabhakar Kushwaha @ 2013-10-03 3:44 UTC (permalink / raw)
To: linuxppc-dev
Cc: Poonam Aggrwal, Priyanka Jain, scottwood, Varun Sethi,
Prabhakar Kushwaha
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
processor cores with high-performance data path acceleration architecture
and network peripheral interfaces required for networking & telecommunications.
T1042 personality is a reduced personality of T1040 without Integrated 8-port
Gigabit Ethernet switch.
The T1040/T1042 SoC includes the following function and features:
- Four e5500 cores, each with a private 256 KB L2 cache
- 256 KB shared L3 CoreNet platform cache (CPC)
- Interconnect CoreNet platform
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
support
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
for the following functions:
- Packet parsing, classification, and distribution
- Queue management for scheduling, packet sequencing, and congestion
management
- Cryptography Acceleration (SEC 5.0)
- RegEx Pattern Matching Acceleration (PME 2.2)
- IEEE Std 1588 support
- Hardware buffer management for buffer allocation and deallocation
- Ethernet interfaces
- Integrated 8-port Gigabit Ethernet switch (T1040 only)
- Four 1 Gbps Ethernet controllers
- Two RGMII interfaces or one RGMII and one MII interfaces
- High speed peripheral interfaces
- Four PCI Express 2.0 controllers running at up to 5 GHz
- Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
- Upto two QSGMII interface
- Upto six SGMII interface supporting 1000 Mbps
- One SGMII interface supporting upto 2500 Mbps
- Additional peripheral interfaces
- Two USB 2.0 controllers with integrated PHY
- SD/eSDHC/eMMC
- eSPI controller
- Four I2C controllers
- Four UARTs
- Four GPIO controllers
- Integrated flash controller (IFC)
- Change this to LCD/ HDMI interface (DIU) with 12 bit dual data rate
- TDM interface
- Multicore programmable interrupt controller (PIC)
- Two 8-channel DMA engines
- Single source clocking implementation
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
Branch merge
Changes for v2: Incorporated Scott's comments
- Update t1040si-post.dtsi
- update clock device tree node as per
http://patchwork.ozlabs.org/patch/274134/
- removed DMA node, It will be added later as per
http://patchwork.ozlabs.org/patch/271238/
- Updated display compatible field
Changes for v3: Incorporated Scott's comments
- Updated soc compatible field
- updated clock compatible field
Changes for v4: Sending as it is
Changes for v5: Sending as it is
Changes for v6: Updated branch of creation
Changes for v7: Incororated Scott's commetns
- Create patch set
- remove whitespace
- Removed l2switch. It will be added later
Changes for v8: Incorporated Scott's comments
- Added comment line in T1042si-post.dtsi
- removed extra lines
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 418 +++++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t1042si-post.dtsi | 37 +++
arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi | 106 +++++++
3 files changed, 561 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
new file mode 100644
index 0000000..9bf1c30
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -0,0 +1,418 @@
+/*
+ * T1040 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ interrupts = <25 2 0 0>;
+};
+
+&pci0 {
+ compatible = "fsl,t1040-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0x0 0xff>;
+ interrupts = <20 2 0 0>;
+ fsl,iommu-parent = <&pamu0>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <20 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 40 1 0 0
+ 0000 0 0 2 &mpic 1 1 0 0
+ 0000 0 0 3 &mpic 2 1 0 0
+ 0000 0 0 4 &mpic 3 1 0 0
+ >;
+ };
+};
+
+&pci1 {
+ compatible = "fsl,t1040-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 0xff>;
+ interrupts = <21 2 0 0>;
+ fsl,iommu-parent = <&pamu0>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <21 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 41 1 0 0
+ 0000 0 0 2 &mpic 5 1 0 0
+ 0000 0 0 3 &mpic 6 1 0 0
+ 0000 0 0 4 &mpic 7 1 0 0
+ >;
+ };
+};
+
+&pci2 {
+ compatible = "fsl,t1040-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0x0 0xff>;
+ interrupts = <22 2 0 0>;
+ fsl,iommu-parent = <&pamu0>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <22 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 42 1 0 0
+ 0000 0 0 2 &mpic 9 1 0 0
+ 0000 0 0 3 &mpic 10 1 0 0
+ 0000 0 0 4 &mpic 11 1 0 0
+ >;
+ };
+};
+
+&pci3 {
+ compatible = "fsl,t1040-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0x0 0xff>;
+ interrupts = <23 2 0 0>;
+ fsl,iommu-parent = <&pamu0>;
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <23 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0 0 1 &mpic 43 1 0 0
+ 0000 0 0 2 &mpic 0 1 0 0
+ 0000 0 0 3 &mpic 4 1 0 0
+ 0000 0 0 4 &mpic 8 1 0 0
+ >;
+ };
+};
+
+&dcsr {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,dcsr", "simple-bus";
+
+ dcsr-epu@0 {
+ compatible = "fsl,t1040-dcsr-epu", "fsl,dcsr-epu";
+ interrupts = <52 2 0 0
+ 84 2 0 0
+ 85 2 0 0>;
+ reg = <0x0 0x1000>;
+ };
+ dcsr-npc {
+ compatible = "fsl,t1040-dcsr-cnpc", "fsl,dcsr-cnpc";
+ reg = <0x1000 0x1000 0x1002000 0x10000>;
+ };
+ dcsr-nxc@2000 {
+ compatible = "fsl,dcsr-nxc";
+ reg = <0x2000 0x1000>;
+ };
+ dcsr-corenet {
+ compatible = "fsl,dcsr-corenet";
+ reg = <0x8000 0x1000 0x1A000 0x1000>;
+ };
+ dcsr-dpaa@9000 {
+ compatible = "fsl,t1040-dcsr-dpaa", "fsl,dcsr-dpaa";
+ reg = <0x9000 0x1000>;
+ };
+ dcsr-ocn@11000 {
+ compatible = "fsl,t1040-dcsr-ocn", "fsl,dcsr-ocn";
+ reg = <0x11000 0x1000>;
+ };
+ dcsr-ddr@12000 {
+ compatible = "fsl,dcsr-ddr";
+ dev-handle = <&ddr1>;
+ reg = <0x12000 0x1000>;
+ };
+ dcsr-nal@18000 {
+ compatible = "fsl,t1040-dcsr-nal", "fsl,dcsr-nal";
+ reg = <0x18000 0x1000>;
+ };
+ dcsr-rcpm@22000 {
+ compatible = "fsl,t1040-dcsr-rcpm", "fsl,dcsr-rcpm";
+ reg = <0x22000 0x1000>;
+ };
+ dcsr-snpc@30000 {
+ compatible = "fsl,t1040-dcsr-snpc", "fsl,dcsr-snpc";
+ reg = <0x30000 0x1000 0x1022000 0x10000>;
+ };
+ dcsr-snpc@31000 {
+ compatible = "fsl,t1040-dcsr-snpc", "fsl,dcsr-snpc";
+ reg = <0x31000 0x1000 0x1042000 0x10000>;
+ };
+ dcsr-cpu-sb-proxy@100000 {
+ compatible = "fsl,dcsr-e5500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu0>;
+ reg = <0x100000 0x1000 0x101000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@108000 {
+ compatible = "fsl,dcsr-e5500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu1>;
+ reg = <0x108000 0x1000 0x109000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@110000 {
+ compatible = "fsl,dcsr-e5500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu2>;
+ reg = <0x110000 0x1000 0x111000 0x1000>;
+ };
+ dcsr-cpu-sb-proxy@118000 {
+ compatible = "fsl,dcsr-e5500-sb-proxy", "fsl,dcsr-cpu-sb-proxy";
+ cpu-handle = <&cpu3>;
+ reg = <0x118000 0x1000 0x119000 0x1000>;
+ };
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+
+ soc-sram-error {
+ compatible = "fsl,soc-sram-error";
+ interrupts = <16 2 1 29>;
+ };
+
+ corenet-law@0 {
+ compatible = "fsl,corenet-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <16>;
+ };
+
+ ddr1: memory-controller@8000 {
+ compatible = "fsl,qoriq-memory-controller-v5.0",
+ "fsl,qoriq-memory-controller";
+ reg = <0x8000 0x1000>;
+ interrupts = <16 2 1 23>;
+ };
+
+ cpc: l3-cache-controller@10000 {
+ compatible = "fsl,t1040-l3-cache-controller", "cache";
+ reg = <0x10000 0x1000>;
+ interrupts = <16 2 1 27>;
+ };
+
+ corenet-cf@18000 {
+ compatible = "fsl,corenet2-cf";
+ reg = <0x18000 0x1000>;
+ interrupts = <16 2 1 31>;
+ fsl,ccf-num-csdids = <32>;
+ fsl,ccf-num-snoopids = <32>;
+ };
+
+ iommu@20000 {
+ compatible = "fsl,pamu-v1.0", "fsl,pamu";
+ reg = <0x20000 0x1000>;
+ ranges = <0 0x20000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupts = <
+ 24 2 0 0
+ 16 2 1 30>;
+ pamu0: pamu@0 {
+ reg = <0 0x1000>;
+ fsl,primary-cache-geometry = <128 1>;
+ fsl,secondary-cache-geometry = <16 2>;
+ };
+ };
+
+/include/ "qoriq-mpic.dtsi"
+
+ guts: global-utilities@e0000 {
+ compatible = "fsl,t1040-device-config", "fsl,qoriq-device-config-2.0";
+ reg = <0xe0000 0xe00>;
+ fsl,has-rstcr;
+ fsl,liodn-bits = <12>;
+ };
+
+ clockgen: global-utilities@e1000 {
+ compatible = "fsl,t1040-clockgen", "fsl,qoriq-clockgen-2.0",
+ "fixed-clock";
+ reg = <0xe1000 0x1000>;
+ clock-output-names = "sysclk";
+ #clock-cells = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800 4>;
+ compatible = "fsl,qoriq-core-pll-2.0";
+ clocks = <&clockgen>;
+ clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ };
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820 4>;
+ compatible = "fsl,qoriq-core-pll-2.0";
+ clocks = <&clockgen>;
+ clock-output-names = "pll1", "pll1-div2", "pll1-div4";
+ };
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0 4>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2";
+ clock-output-names = "cmux0";
+ };
+ mux1: mux1@20 {
+ #clock-cells = <0>;
+ reg = <0x20 4>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2";
+ clock-output-names = "cmux1";
+ };
+ mux2: mux2@40 {
+ #clock-cells = <0>;
+ reg = <0x40 4>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2";
+ clock-output-names = "cmux2";
+ };
+ mux3: mux3@60 {
+ #clock-cells = <0>;
+ reg = <0x60 4>;
+ compatible = "fsl,core-mux-clock";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0_0", "pll0_1", "pll0_2",
+ "pll1_0", "pll1_1", "pll1_2";
+ clock-output-names = "cmux3";
+ };
+ };
+
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,t1040-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+ sfp: sfp@e8000 {
+ compatible = "fsl,t1040-sfp";
+ reg = <0xe8000 0x1000>;
+ };
+
+ serdes: serdes@ea000 {
+ compatible = "fsl,t1040-serdes";
+ reg = <0xea000 0x4000>;
+ };
+
+/include/ "qoriq-espi-0.dtsi"
+ spi@110000 {
+ fsl,espi-num-chipselects = <4>;
+ };
+
+/include/ "qoriq-esdhc-0.dtsi"
+ sdhc@114000 {
+ compatible = "fsl,t1040-esdhc", "fsl,esdhc";
+ fsl,iommu-parent = <&pamu0>;
+ fsl,liodn-reg = <&guts 0x530>; /* eSDHCLIODNR */
+ sdhci,auto-cmd12;
+ };
+/include/ "qoriq-i2c-0.dtsi"
+/include/ "qoriq-i2c-1.dtsi"
+/include/ "qoriq-duart-0.dtsi"
+/include/ "qoriq-duart-1.dtsi"
+/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-gpio-1.dtsi"
+/include/ "qoriq-gpio-2.dtsi"
+/include/ "qoriq-gpio-3.dtsi"
+/include/ "qoriq-usb2-mph-0.dtsi"
+ usb0: usb@210000 {
+ compatible = "fsl-usb2-mph-v2.4", "fsl-usb2-mph";
+ fsl,iommu-parent = <&pamu0>;
+ fsl,liodn-reg = <&guts 0x520>; /* USB1LIODNR */
+ phy_type = "utmi";
+ port0;
+ };
+/include/ "qoriq-usb2-dr-0.dtsi"
+ usb1: usb@211000 {
+ compatible = "fsl-usb2-dr-v2.4", "fsl-usb2-dr";
+ fsl,iommu-parent = <&pamu0>;
+ fsl,liodn-reg = <&guts 0x524>; /* USB2LIODNR */
+ dr_mode = "host";
+ phy_type = "utmi";
+ };
+
+ display@180000 {
+ compatible = "fsl,t1040-diu", "fsl,diu";
+ reg = <0x180000 1000>;
+ interrupts = <74 2 0 0>;
+ };
+
+/include/ "qoriq-sata2-0.dtsi"
+sata@220000 {
+ fsl,iommu-parent = <&pamu0>;
+ fsl,liodn-reg = <&guts 0x550>; /* SATA1LIODNR */
+};
+/include/ "qoriq-sata2-1.dtsi"
+sata@221000 {
+ fsl,iommu-parent = <&pamu0>;
+ fsl,liodn-reg = <&guts 0x554>; /* SATA2LIODNR */
+};
+/include/ "qoriq-sec5.0-0.dtsi"
+};
diff --git a/arch/powerpc/boot/dts/fsl/t1042si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
new file mode 100644
index 0000000..319b74f
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
@@ -0,0 +1,37 @@
+/*
+ * T1042 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "t1040si-post.dtsi"
+
+/* Place holder for ethernet related device tree nodes */
diff --git a/arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi b/arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
new file mode 100644
index 0000000..c0ae954
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
@@ -0,0 +1,106 @@
+/*
+ * T1040/T1042 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ "e5500_power_isa.dtsi"
+
+/ {
+ compatible = "fsl,T104x";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ ccsr = &soc;
+ dcsr = &dcsr;
+
+ serial0 = &serial0;
+ serial1 = &serial1;
+ serial2 = &serial2;
+ serial3 = &serial3;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ pci3 = &pci3;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ sdhc = &sdhc;
+
+ crypto = &crypto;
+
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: PowerPC,e5500@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&mux0>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu1: PowerPC,e5500@1 {
+ device_type = "cpu";
+ reg = <1>;
+ clocks = <&mux1>;
+ next-level-cache = <&L2_2>;
+ L2_2: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu2: PowerPC,e5500@2 {
+ device_type = "cpu";
+ reg = <2>;
+ clocks = <&mux2>;
+ next-level-cache = <&L2_3>;
+ L2_3: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ cpu3: PowerPC,e5500@3 {
+ device_type = "cpu";
+ reg = <3>;
+ clocks = <&mux3>;
+ next-level-cache = <&L2_4>;
+ L2_4: l2-cache {
+ next-level-cache = <&cpc>;
+ };
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH RFC 55/77] ntb: Update MSI/MSI-X interrupts enablement code
From: Jon Mason @ 2013-10-03 1:02 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <49eb592e15aaec804f9c11ca132d2b85c516aefa.1380703263.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:49:11PM +0200, Alexander Gordeev wrote:
> As result of recent re-design of the MSI/MSI-X interrupts enabling
> pattern this driver has to be updated to use the new technique to
> obtain a optimal number of MSI/MSI-X interrupts required.
>
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
> drivers/ntb/ntb_hw.c | 41 +++++++++++++----------------------------
> drivers/ntb/ntb_hw.h | 2 --
> 2 files changed, 13 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> index eccd5e5..7776429 100644
> --- a/drivers/ntb/ntb_hw.c
> +++ b/drivers/ntb/ntb_hw.c
> @@ -1032,23 +1032,26 @@ static int ntb_setup_msix(struct ntb_device *ndev)
> struct msix_entry *msix;
> int msix_entries;
> int rc, i;
> - u16 val;
>
> - if (!pdev->msix_cap) {
> - rc = -EIO;
> + rc = pci_msix_table_size(pdev);
> + if (rc < 0)
> goto err;
> - }
>
> - rc = pci_read_config_word(pdev, pdev->msix_cap + PCI_MSIX_FLAGS, &val);
> - if (rc)
> + /*
> + * On SNB, the link interrupt is always tied to 4th vector. If
> + * we can't get all 4, then we can't use MSI-X.
> + */
> + if ((rc < SNB_MSIX_CNT) && (ndev->hw_type != BWD_HW)) {
Please check for the HW type first, and then compare to
ndev->limits.msix_cnt (which will be SNB_MSIX_CNT on SNB HW). Also,
put the comment inside the if statement and remove the unecessary "()"
around the comparisons. OCD on my part, but I like it that way.
> + rc = -ENOSPC;
> goto err;
> -
> - msix_entries = msix_table_size(val);
> - if (msix_entries > ndev->limits.msix_cnt) {
> + }
else if...
> + if (rc > ndev->limits.msix_cnt) {
> rc = -EINVAL;
> goto err;
> }
>
> + msix_entries = rc;
> +
> ndev->msix_entries = kmalloc(sizeof(struct msix_entry) * msix_entries,
> GFP_KERNEL);
> if (!ndev->msix_entries) {
> @@ -1060,26 +1063,8 @@ static int ntb_setup_msix(struct ntb_device *ndev)
> ndev->msix_entries[i].entry = i;
>
> rc = pci_enable_msix(pdev, ndev->msix_entries, msix_entries);
> - if (rc < 0)
> + if (rc)
> goto err1;
> - if (rc > 0) {
> - /* On SNB, the link interrupt is always tied to 4th vector. If
> - * we can't get all 4, then we can't use MSI-X.
> - */
> - if ((rc < SNB_MSIX_CNT) && (ndev->hw_type != BWD_HW)) {
> - rc = -EIO;
> - goto err1;
> - }
> -
> - dev_warn(&pdev->dev,
> - "Only %d MSI-X vectors. Limiting the number of queues to that number.\n",
> - rc);
> - msix_entries = rc;
> -
> - rc = pci_enable_msix(pdev, ndev->msix_entries, msix_entries);
> - if (rc)
> - goto err1;
> - }
>
> for (i = 0; i < msix_entries; i++) {
> msix = &ndev->msix_entries[i];
> diff --git a/drivers/ntb/ntb_hw.h b/drivers/ntb/ntb_hw.h
> index 0a31ced..50bd760 100644
> --- a/drivers/ntb/ntb_hw.h
> +++ b/drivers/ntb/ntb_hw.h
> @@ -60,8 +60,6 @@
> #define PCI_DEVICE_ID_INTEL_NTB_SS_HSX 0x2F0F
> #define PCI_DEVICE_ID_INTEL_NTB_B2B_BWD 0x0C4E
>
> -#define msix_table_size(control) ((control & PCI_MSIX_FLAGS_QSIZE)+1)
Good riddance! :-)
> -
> #ifndef readq
> static inline u64 readq(void __iomem *addr)
> {
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [PATCH RFC 53/77] ntb: Fix missed call to pci_enable_msix()
From: Jon Mason @ 2013-10-03 0:49 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, stable,
linux-s390, Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <0590d63c3432229a3824bada71e07a08fb955498.1380703263.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:49:09PM +0200, Alexander Gordeev wrote:
> Current MSI-X enablement code assumes MSI-Xs were successfully
> allocated in case less than requested vectors were available.
> That assumption is wrong, since MSI-Xs should be enabled with
> a repeated call to pci_enable_msix(). This update fixes this.
Good catch, I'll pull it in for my next NTB release.
Thanks,
Jon
>
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
> drivers/ntb/ntb_hw.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> index 1cb6e51..de2062c 100644
> --- a/drivers/ntb/ntb_hw.c
> +++ b/drivers/ntb/ntb_hw.c
> @@ -1075,6 +1075,10 @@ static int ntb_setup_msix(struct ntb_device *ndev)
> "Only %d MSI-X vectors. Limiting the number of queues to that number.\n",
> rc);
> msix_entries = rc;
> +
> + rc = pci_enable_msix(pdev, ndev->msix_entries, msix_entries);
> + if (rc)
> + goto err1;
> }
>
> for (i = 0; i < msix_entries; i++) {
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [PATCH RFC 54/77] ntb: Ensure number of MSIs on SNB is enough for the link interrupt
From: Jon Mason @ 2013-10-03 0:48 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, stable,
linux-s390, Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <5d9c5b2d3bbc444ff32bddeece7a239d046bd79c.1380703263.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:49:10PM +0200, Alexander Gordeev wrote:
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
> drivers/ntb/ntb_hw.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ntb/ntb_hw.c b/drivers/ntb/ntb_hw.c
> index de2062c..eccd5e5 100644
> --- a/drivers/ntb/ntb_hw.c
> +++ b/drivers/ntb/ntb_hw.c
> @@ -1066,7 +1066,7 @@ static int ntb_setup_msix(struct ntb_device *ndev)
> /* On SNB, the link interrupt is always tied to 4th vector. If
> * we can't get all 4, then we can't use MSI-X.
> */
> - if (ndev->hw_type != BWD_HW) {
> + if ((rc < SNB_MSIX_CNT) && (ndev->hw_type != BWD_HW)) {
Nack, this check is unnecessary.
Also, no comment in the commit on why it could be necessary.
> rc = -EIO;
> goto err1;
> }
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [PATCH RFC 01/77] PCI/MSI: Fix return value when populate_msi_sysfs() failed
From: Jon Mason @ 2013-10-03 0:39 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, stable,
linux-s390, Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar,
linux-pci, iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <3ff5236944aae69f2cd934b5b6da7c1c269df7c1.1380703262.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:48:17PM +0200, Alexander Gordeev wrote:
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Since you are changing the behavior of the msix_capability_init
function on populate_msi_sysfs error, a comment describing why in this
commit would be nice.
> ---
> drivers/pci/msi.c | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index d5f90d6..b43f391 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -719,7 +719,7 @@ static int msix_capability_init(struct pci_dev *dev,
>
> ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
> if (ret)
> - goto error;
> + goto out_avail;
>
> /*
> * Some devices require MSI-X to be enabled before we can touch the
> @@ -732,10 +732,8 @@ static int msix_capability_init(struct pci_dev *dev,
> msix_program_entries(dev, entries);
>
> ret = populate_msi_sysfs(dev);
> - if (ret) {
> - ret = 0;
> - goto error;
> - }
> + if (ret)
> + goto out_free;
>
> /* Set MSI-X enabled bits and unmask the function */
> pci_intx_for_msi(dev, 0);
> @@ -746,7 +744,7 @@ static int msix_capability_init(struct pci_dev *dev,
>
> return 0;
>
> -error:
> +out_avail:
> if (ret < 0) {
> /*
> * If we had some success, report the number of irqs
> @@ -763,6 +761,7 @@ error:
> ret = avail;
> }
>
> +out_free:
> free_msi_irqs(dev);
>
> return ret;
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [PATCH RFC 77/77] vxge: Update MSI/MSI-X interrupts enablement code
From: Jon Mason @ 2013-10-03 0:29 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <467ce10b1df795edf80ed222816ab739fee7b0ea.1380703263.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:49:33PM +0200, Alexander Gordeev wrote:
> As result of recent re-design of the MSI/MSI-X interrupts enabling
> pattern this driver has to be updated to use the new technique to
> obtain a optimal number of MSI/MSI-X interrupts required.
>
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
> drivers/net/ethernet/neterion/vxge/vxge-main.c | 36 ++++++++++-------------
> 1 files changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.c b/drivers/net/ethernet/neterion/vxge/vxge-main.c
> index b81ff8b..b4d40dd 100644
> --- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
> +++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
> @@ -2297,7 +2297,21 @@ static int vxge_alloc_msix(struct vxgedev *vdev)
> int msix_intr_vect = 0, temp;
> vdev->intr_cnt = 0;
>
> -start:
> + ret = pci_msix_table_size(vdev->pdev);
> + if (ret < 0)
> + goto alloc_entries_failed;
> +
> + if (ret < (vdev->no_of_vpath * 2 + 1)) {
> + if ((max_config_vpath != VXGE_USE_DEFAULT) || (ret < 3)) {
> + ret = -ENOSPC;
> + goto alloc_entries_failed;
> + }
> + /* Try with less no of vector by reducing no of vpaths count */
> + temp = (ret - 1)/2;
> + vxge_close_vpaths(vdev, temp);
> + vdev->no_of_vpath = temp;
> + }
The original code was ugly (not my code, so I can say that). I'd like
to see it a little stream lined. Something like:
vdev->intr_cnt = pci_msix_table_size(vdev->pdev);
if (vdev->intr_cnt % 2 == 0)
vdev->intr_cnt--;
if (vdev->intr_cnt < 3 || max_config_vpath != VXGE_USE_DEFAULT)
goto alloc_entries_failed;
if (vdev->intr_cnt != vdev->no_of_vpath * 2 + 1) {
vxge_close_vpaths(vdev, vdev->intr_cnt / 2);
vdev->no_of_vpath = vdev->intr_cnt / 2;
}
> +
> /* Tx/Rx MSIX Vectors count */
> vdev->intr_cnt = vdev->no_of_vpath * 2;
>
> @@ -2347,25 +2361,7 @@ start:
> vdev->vxge_entries[j].in_use = 0;
>
> ret = pci_enable_msix(vdev->pdev, vdev->entries, vdev->intr_cnt);
> - if (ret > 0) {
> - vxge_debug_init(VXGE_ERR,
> - "%s: MSI-X enable failed for %d vectors, ret: %d",
> - VXGE_DRIVER_NAME, vdev->intr_cnt, ret);
> - if ((max_config_vpath != VXGE_USE_DEFAULT) || (ret < 3)) {
> - ret = -ENOSPC;
> - goto enable_msix_failed;
> - }
> -
> - kfree(vdev->entries);
> - kfree(vdev->vxge_entries);
> - vdev->entries = NULL;
> - vdev->vxge_entries = NULL;
> - /* Try with less no of vector by reducing no of vpaths count */
> - temp = (ret - 1)/2;
> - vxge_close_vpaths(vdev, temp);
> - vdev->no_of_vpath = temp;
> - goto start;
> - } else if (ret < 0)
> + if (ret)
> goto enable_msix_failed;
Nit, space here please.
> return 0;
>
> --
> 1.7.7.6
>
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Paul Mackerras @ 2013-10-02 22:45 UTC (permalink / raw)
To: Alexander Graf
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, mpm, Paolo Bonzini
In-Reply-To: <C4834CF8-F81C-4B82-B1A7-1751D50AADB7@suse.de>
On Wed, Oct 02, 2013 at 04:36:05PM +0200, Alexander Graf wrote:
>
> On 02.10.2013, at 16:33, Paolo Bonzini wrote:
>
> > Il 02/10/2013 16:08, Alexander Graf ha scritto:
> >>> The hwrng is accessible by host userspace via /dev/mem.
> >>
> >> A guest should live on the same permission level as a user space
> >> application. If you run QEMU as UID 1000 without access to /dev/mem, why
> >> should the guest suddenly be able to directly access a memory location
> >> (MMIO) it couldn't access directly through a normal user space interface.
> >>
> >> It's basically a layering violation.
> >
> > With Michael's earlier patch in this series, the hwrng is accessible by
> > host userspace via /dev/hwrng, no?
>
> Yes, but there's not token from user space that gets passed into the kernel to check whether access is ok or not. So while QEMU may not have permission to open /dev/hwrng it could spawn a guest that opens it, drains all entropy out of it and thus stall other processes which try to fetch entropy, no?
Even if you drain all entropy out of it, wait 64 microseconds and it
will be full again. :) Basically it produces 64 bits every
microsecond and puts that in a 64 entry x 64-bit FIFO buffer, which is
what is read by the MMIO. So there is no danger of stalling other
processes for any significant amount of time.
Paul.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Benjamin Herrenschmidt @ 2013-10-02 22:21 UTC (permalink / raw)
To: Gleb Natapov
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <20131002143720.GK17294@redhat.com>
On Wed, 2013-10-02 at 17:37 +0300, Gleb Natapov wrote:
> On Wed, Oct 02, 2013 at 04:33:18PM +0200, Paolo Bonzini wrote:
> > Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > > > The hwrng is accessible by host userspace via /dev/mem.
> > >
> > > A guest should live on the same permission level as a user space
> > > application. If you run QEMU as UID 1000 without access to /dev/mem, why
> > > should the guest suddenly be able to directly access a memory location
> > > (MMIO) it couldn't access directly through a normal user space interface.
> > >
> > > It's basically a layering violation.
> >
> > With Michael's earlier patch in this series, the hwrng is accessible by
> > host userspace via /dev/hwrng, no?
> >
> Access to which can be controlled by its permission. Permission of
> /dev/kvm may be different. If we route hypercall via userspace and
> configure qemu to get entropy from /dev/hwrng everything will fall
> nicely together (except performance).
Yes, except abysmall performance and a lot more code for something
completely and utterly pointless .... nice.
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Benjamin Herrenschmidt @ 2013-10-02 22:15 UTC (permalink / raw)
To: Gleb Natapov
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <20131002141032.GI17294@redhat.com>
On Wed, 2013-10-02 at 17:10 +0300, Gleb Natapov wrote:
> > The hwrng is accessible by host userspace via /dev/mem.
> >
> Regular user has no access to /dev/mem, but he can start kvm guest and
> gain access to the device.
Seriously. You guys are really trying hard to make our life hell or
what ? That discussion about access permissions makes no sense
whatsoever. Please stop.
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Benjamin Herrenschmidt @ 2013-10-02 22:13 UTC (permalink / raw)
To: Alexander Graf
Cc: tytso, kvm, Gleb Natapov, linuxppc-dev, linux-kernel, kvm-ppc,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <029A8D6C-C23C-42B2-8C26-D76B59E2C9DD@suse.de>
On Wed, 2013-10-02 at 16:08 +0200, Alexander Graf wrote:
> A guest should live on the same permission level as a user space
> application. If you run QEMU as UID 1000 without access to /dev/mem,
> why should the guest suddenly be able to directly access a memory
> location (MMIO) it couldn't access directly through a normal user
> space interface.
>
> It's basically a layering violation.
Guys, please stop with the academic non-sense !
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Benjamin Herrenschmidt @ 2013-10-02 22:07 UTC (permalink / raw)
To: Gleb Natapov
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <20131002100224.GF17294@redhat.com>
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> use hypercall instead of emulating the device (in kernel or somewhere
> else?). Another things is that on a host hwrnd is protected from
> direct userspace access by virtue of been a device, but guest code (event
> kernel mode) is userspace as far as hosts security model goes, so by
> implementing this hypercall in a way that directly access hwrnd you
> expose hwrnd to a userspace unconditionally. Why is this a good idea?
BTW. Is this always going to be like this ?
Every *single* architectural or design decision we make for our
architecture has to be justified 30 times over, every piece of code bike
shedded to oblivion for month, etc... ?
Do we always have to finally get to some kind of agreement on design, go
to the 6 month bike-shedding phase, just to have somebody else come up
and start re-questioning the whole original design (without any
understanding of our specific constraints of course) ?
You guys are the most horrendous community I have ever got to work with.
It's simply impossible to get anything done in any reasonable time
frame .
At this stage, it would have taken us an order of magnitude less time to
simply rewrite an entire hypervisor from scratch.
This is sad.
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Benjamin Herrenschmidt @ 2013-10-02 22:02 UTC (permalink / raw)
To: Gleb Natapov
Cc: tytso, kvm, linuxppc-dev, Alexander Graf, kvm-ppc, linux-kernel,
herbert, Paul Mackerras, mpm, Paolo Bonzini
In-Reply-To: <20131002100224.GF17294@redhat.com>
On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> use hypercall instead of emulating the device (in kernel or somewhere
> else?).
Migration will have to be dealt with one way or another, I suppose we
will indeed need a qemu fallback.
As for why hypercall instead of MMIO, well, you'd have to ask the folks
who wrote the PAPR spec :-) It's specified as a hypercall and
implemented as such in pHyp (PowerVM). The existing guests expect it
that way.
It might have to do with the required whitening done by the hypervisor
(H_RANDOM output is supposed to be clean). It also abstracts us from the
underlying HW implementation which could in theory change.
> Another things is that on a host hwrnd is protected from
> direct userspace access by virtue of been a device, but guest code (event
> kernel mode) is userspace as far as hosts security model goes, so by
> implementing this hypercall in a way that directly access hwrnd you
> expose hwrnd to a userspace unconditionally. Why is this a good idea?
Why would this be a bad idea ?
Ben.
> --
> Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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