Re: [PATCH RFC 50/77] mlx5: Update MSI/MSI-X interrupts enablement code
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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
On Thu, 2013-10-03 at 08:43 +0300, Gleb Natapov wrote: > 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. Not in a very significant way, we generate entropy at 1Mhz after all, which is pretty good. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2] kvm: powerpc: book3s: Fix build break for BOOK3S_32
From: "Aneesh Kumar K.V"
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
Acked-by: Paul Mackerras
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kvm/book3s_pr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 8941885..6075dbd 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1179,7 +1179,7 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm,
unsigned int id)
#ifdef CONFIG_KVM_BOOK3S_32
vcpu->arch.shadow_vcpu =
- kzalloc(sizeof(*vcpu_book3s->shadow_vcpu), GFP_KERNEL);
+ kzalloc(sizeof(*vcpu->arch.shadow_vcpu), GFP_KERNEL);
if (!vcpu->arch.shadow_vcpu)
goto free_vcpu3s;
#endif
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc/kernel/sysfs: cleanup set up macros for PMC/non-PMC SPRs
Currently PMC (Performance Monitor Counter) setup macros are used
for other SPRs. Since not all SPRs are PMC related, this patch
modifies the exisiting macro and uses it to setup both PMC and
non PMC SPRs accordingly.
V3 changes:
1) No logic change, just renamed generic macro and removed #define for empty
string
2) Changes in the comment to explain better.
V2 changes:
1) Modified SYSFS_PMCSETUP to a generic macro with additional parameter
2) Added PMC and SPR macro to call the generic macro
3) Changes in the comment to explain better.
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/kernel/sysfs.c | 72 +++
1 file changed, 38 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 27a90b9..39e864a 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -107,14 +107,14 @@ void ppc_enable_pmcs(void)
}
EXPORT_SYMBOL(ppc_enable_pmcs);
-#define SYSFS_PMCSETUP(NAME, ADDRESS) \
+#define __SYSFS_SPRSETUP(NAME, ADDRESS, EXTRA) \
static void read_##NAME(void *val) \
{ \
*(unsigned long *)val = mfspr(ADDRESS); \
} \
static void write_##NAME(void *val) \
{ \
- ppc_enable_pmcs(); \
+ EXTRA; \
mtspr(ADDRESS, *(unsigned long *)val); \
} \
static ssize_t show_##NAME(struct device *dev, \
@@ -139,6 +139,10 @@ static ssize_t __used \
return count; \
}
+#define SYSFS_PMCSETUP(NAME, ADDRESS) \
+ __SYSFS_SPRSETUP(NAME, ADDRESS, ppc_enable_pmcs())
+#define SYSFS_SPRSETUP(NAME, ADDRESS) \
+ __SYSFS_SPRSETUP(NAME, ADDRESS, )
/* Let's define all possible registers, we'll only hook up the ones
* that are implemented on the current processor
@@ -174,10 +178,10 @@ SYSFS_PMCSETUP(pmc7, SPRN_PMC7);
SYSFS_PMCSETUP(pmc8, SPRN_PMC8);
SYSFS_PMCSETUP(mmcra, SPRN_MMCRA);
-SYSFS_PMCSETUP(purr, SPRN_PURR);
-SYSFS_PMCSETUP(spurr, SPRN_SPURR);
-SYSFS_PMCSETUP(dscr, SPRN_DSCR);
-SYSFS_PMCSETUP(pir, SPRN_PIR);
+SYSFS_SPRSETUP(purr, SPRN_PURR);
+SYSFS_SPRSETUP(spurr, SPRN_SPURR);
+SYSFS_SPRSETUP(dscr, SPRN_DSCR);
+SYSFS_SPRSETUP(pir, SPRN_PIR);
static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
@@ -238,34 +242,34 @@ SYSFS_PMCSETUP(pa6t_pmc3, SPRN_PA6T_PMC3);
SYSFS_PMCSETUP(pa6t_pmc4, SPRN_PA6T_PMC4);
SYSFS_PMCSETUP(pa6t_pmc5, SPRN_PA6T_PMC5);
#ifdef CONFIG_DEBUG_KERNEL
-SYSFS_PMCSETUP(hid0, SPRN_HID0);
-SYSFS_PMCSETUP(hid1, SPRN_HID1);
-SYSFS_PMCSETUP(hid4, SPRN_HID4);
-SYSFS_PMCSETUP(hid5, SPRN_HID5);
-SYSFS_PMCSETUP(ima0, SPRN_PA6T_IMA0);
-SYSFS_PMCSETUP(ima1, SPRN_PA6T_IMA1);
-SYSFS_PMCSETUP(ima2, SPRN_PA6T_IMA2);
-SYSFS_PMCSETUP(ima3, SPRN_PA6T_IMA3);
-SYSFS_PMCSETUP(ima4, SPRN_PA6T_IMA4);
-SYSFS_PMCSETUP(ima5, SPRN_PA6T_IMA5);
-SYSFS_PMCSETUP(ima6, SPRN_PA6T_IMA6);
-SYSFS_PMCSETUP(ima7, SPRN_PA6T_IMA7);
-SYSFS_PMCSETUP(ima8, SPRN_PA6T_IMA8);
-SYSFS_PMCSETUP(ima9, SPRN_PA6T_IMA9);
-SYSFS_PMCSETUP(imaat, SPRN_PA6T_IMAAT);
-SYSFS_PMCSETUP(btcr, SPRN_PA6T_BTCR);
-SYSFS_PMCSETUP(pccr, SPRN_PA6T_PCCR);
-SYSFS_PMCSETUP(rpccr, SPRN_PA6T_RPCCR);
-SYSFS_PMCSETUP(der, SPRN_PA6T_DER);
-SYSFS_PMCSETUP(mer, SPRN_PA6T_MER);
-SYSFS_PMCSETUP(ber, SPRN_PA6T_BER);
-SYSFS_PMCSETUP(ier, SPRN_PA6T_IER);
-SYSFS_PMCSETUP(sier, SPRN_PA6T_SIER);
-SYSFS_PMCSETUP(siar, SPRN_PA6T_SIAR);
-SYSFS_PMCSETUP(tsr0, SPRN_PA6T_TSR0);
-SYSFS_PMCSETUP(tsr1, SPRN_PA6T_TSR1);
-SYSFS_PMCSETUP(tsr2, SPRN_PA6T_TSR2);
-SYSFS_PMCSETUP(tsr3, SPRN_PA6T_TSR3);
+SYSFS_SPRSETUP(hid0, SPRN_HID0);
+SYSFS_SPRSETUP(hid1, SPRN_HID1);
+SYSFS_SPRSETUP(hid4, SPRN_HID4);
+SYSFS_SPRSETUP(hid5, SPRN_HID5);
+SYSFS_SPRSETUP(ima0, SPRN_PA6T_IMA0);
+SYSFS_SPRSETUP(ima1, SPRN_PA6T_IMA1);
+SYSFS_SPRSETUP(ima2, SPRN_PA6T_IMA2);
+SYSFS_SPRSETUP(ima3, SPRN_PA6T_IMA3);
+SYSFS_SPRSETUP(ima4, SPRN_PA6T_IMA4);
+SYSFS_SPRSETUP(ima5, SPRN_PA6T_IMA5);
+SYSFS_SPRSETUP(ima6, SPRN_PA6T_IMA6);
+SYSFS_SPRSETUP(ima7, SPRN_PA6T_IMA7);
+SYSFS_SPRSETUP(ima8, SPRN_PA6T_IMA8);
+SYSFS_SPRSETUP(ima9, SPRN_PA6T_IMA9);
+SYSFS_SPRSETUP(imaat, SPRN_PA6T_IMAAT);
+SYSFS_SPRSETUP(btcr, SPRN_PA6T_BTCR);
+SYSFS_SPRSETUP(pccr, SPRN_PA6T_PCCR);
+SYSFS_SPRSETUP(rpccr, SPRN_PA6T_RPCCR);
+SYSFS_SPRSETUP(der, SPRN_PA6T_DER);
+SYSFS_SPRSETUP(mer, SPRN_PA6T_MER);
+SYSFS_SPRSETUP(ber, SPRN_PA6T_BER);
+SYSFS_SPRSETUP(ier, SPRN_PA6T_IER);
+SYSFS_SPRSETUP(sier, SPRN_PA6T_SIER);
+SYSFS_SPRSETUP(siar, SPRN_PA6T_SIAR);
+SYSFS_SPRSETUP(tsr0, SPRN_PA6T_TSR0);
+SYSFS_SPRSETUP(tsr1, SPRN_PA6T_TSR1);
+SYSFS_SPRSETUP(tsr2, SPRN_PA6T_TSR2);
+SYSFS_SPRSETUP(tsr3, SPRN_PA6T_TSR3);
#endif /* CONFIG_DEBUG_KERNEL */
#endif /* HAS_PPC_PMC_PA6T */
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
On Thu, Oct 03, 2013 at 08:48:03AM +0300, Gleb Natapov wrote: > 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? Well, you can't actually have more guests running than there are cores in a system. POWER7+ has one RNG per chip and 8 cores per chip, each of which can run 4 threads (which have to be in the same guest). Michael's code uses the RNG on the same chip. Worst case therefore is 32 threads accessing the same RNG, so a given thread might have to wait up to 32 microseconds for its data. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
On Tuesday, October 01, 2013 04:13:25 PM Michael Ellerman wrote: > On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote: > > __initdata tag should be placed between the variable name and equal > > sign for the variable to be placed in the intended .init.data section. > > I see lots of other occurences of that in arch/powerpc. Why not send a > single patch to update them all? The other occurences while not following the preferred kernel coding style are (probably) working OK with gcc. This particular occurence just doesn't work as it should. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
On Thu, Oct 03, 2013 at 08:06:30PM +1000, Paul Mackerras wrote: > On Thu, Oct 03, 2013 at 08:48:03AM +0300, Gleb Natapov wrote: > > 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? > > Well, you can't actually have more guests running than there are cores > in a system. POWER7+ has one RNG per chip and 8 cores per chip, each > of which can run 4 threads (which have to be in the same guest). > > Michael's code uses the RNG on the same chip. Worst case therefore is > 32 threads accessing the same RNG, so a given thread might have to > wait up to 32 microseconds for its data. > OK, thanks. Even if it become an issue for some reason it is always possible to rate limit it. -- Gleb. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v2 0/5] MPC512x DMA slave s/g support, OF DMA lookup
v2013/7/14 Gerhard Sittig : > this series > - introduces slave s/g support (that's support for DMA transfers which > involve peripherals in contrast to mem-to-mem transfers) > - adds device tree based lookup support for DMA channels > - combines floating patches and related feedback which already covered > several aspects of what the suggested LPB driver needs, to demonstrate > how integration might be done > - carries Q&D SD card support to enable another DMA client during test, > while this patch needs to get dropped upon pickup > > changes since v1: > - re-order mpc8308 related code paths for improved readability, no > change in behaviour, introduction of symbolic channel names here > already > - squash 'execute() start condition' and 'terminate all' into the > introduction of 'slave s/g prep' and 'device control' support; refuse > s/g lists with more than one item since slave support is operational > yet proper s/g support is missing (can get addressed later) > - always start transfers from software on MPC8308 as there are no > external request lines for peripheral flow control > - drop dt-bindings header file and symbolic channel names in OF nodes Changes since v2 (RFC v3 was badly formed, excuse me for that): Part 1/5: - use #define instead of enum since individual channels don't require special handling. Part 2/5: - add a flag "will_access_peripheral" to DMA transfer descriptor according recommendations of Gerhard Sittig. This flag is set in mpc_dma_prep_memcpy() and mpc_dma_prep_slave_sg() and is evaluated in mpc_dma_execute() to choose a type of start for the transfer. - prevent descriptors of transfers which involve peripherals from being chained together; each of such transfers needs hardware initiated start. - add locking while working with struct mpc_dma_chan according recommendations of Lars-Peter Clausen. - remove default nbytes value. Client kernel modules must set src_maxburst and dst_maxburst fields of struct dma_slave_config (dmaengine.h). Part 6/8: unchanged. Part 7/8: unchanged. Part 8/8: unchanged. These changes are tested on MPC5125 - with SCLPC driver (transfers between dev and mem work fine). - with dmatest module (all 64 DMA channels can perform mem-to-mem transfers which can be chained in one DMA transaction). > known issues: > - it's yet to get confirmed whether MPC8308 can use slave support or > whether the DMA controller's driver shall actively reject it, the > information that's available so far suggests that peripheral transfers > to IP bus attached I/O is useful and shall not get blocked right away > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC v4 1/5] dma: mpc512x: reorder mpc8308 specific instructions
Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.
Signed-off-by: Alexander Popov
---
drivers/dma/mpc512x_dma.c | 42 +-
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2fe4353..f41639f 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -50,9 +50,17 @@
#define MPC_DMA_DESCRIPTORS64
/* Macro definitions */
-#define MPC_DMA_CHANNELS 64
#define MPC_DMA_TCD_OFFSET 0x1000
+/*
+ * Maximum channel counts for individual hardware variants
+ * and the maximum channel count over all supported controllers,
+ * used for data structure size
+ */
+#define MPC8308_DMACHAN_MAX16
+#define MPC512x_DMACHAN_MAX64
+#define MPC_DMA_CHANNELS 64
+
/* Arbitration mode of group and channel */
#define MPC_DMA_DMACR_EDCG (1 << 31)
#define MPC_DMA_DMACR_ERGA (1 << 3)
@@ -708,10 +716,10 @@ static int mpc_dma_probe(struct platform_device *op)
dma = &mdma->dma;
dma->dev = dev;
- if (!mdma->is_mpc8308)
- dma->chancnt = MPC_DMA_CHANNELS;
+ if (mdma->is_mpc8308)
+ dma->chancnt = MPC8308_DMACHAN_MAX;
else
- dma->chancnt = 16; /* MPC8308 DMA has only 16 channels */
+ dma->chancnt = MPC512x_DMACHAN_MAX;
dma->device_alloc_chan_resources = mpc_dma_alloc_chan_resources;
dma->device_free_chan_resources = mpc_dma_free_chan_resources;
dma->device_issue_pending = mpc_dma_issue_pending;
@@ -745,7 +753,19 @@ static int mpc_dma_probe(struct platform_device *op)
* - Round-robin group arbitration,
* - Round-robin channel arbitration.
*/
- if (!mdma->is_mpc8308) {
+ if (mdma->is_mpc8308) {
+ /* MPC8308 has 16 channels and lacks some registers */
+ out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
+
+ /* enable snooping */
+ out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
+ /* Disable error interrupts */
+ out_be32(&mdma->regs->dmaeeil, 0);
+
+ /* Clear interrupts status */
+ out_be32(&mdma->regs->dmaintl, 0x);
+ out_be32(&mdma->regs->dmaerrl, 0x);
+ } else {
out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_EDCG |
MPC_DMA_DMACR_ERGA |
MPC_DMA_DMACR_ERCA);
@@ -766,18 +786,6 @@ static int mpc_dma_probe(struct platform_device *op)
/* Route interrupts to IPIC */
out_be32(&mdma->regs->dmaihsa, 0);
out_be32(&mdma->regs->dmailsa, 0);
- } else {
- /* MPC8308 has 16 channels and lacks some registers */
- out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
-
- /* enable snooping */
- out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
- /* Disable error interrupts */
- out_be32(&mdma->regs->dmaeeil, 0);
-
- /* Clear interrupts status */
- out_be32(&mdma->regs->dmaintl, 0x);
- out_be32(&mdma->regs->dmaerrl, 0x);
}
/* Register DMA engine */
--
1.7.11.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC v4 2/5] dma: mpc512x: add support for peripheral transfers
Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.
Refuse to prepare chunked transfers (transfers with more than one part)
as long as proper support for scatter/gather is lacking.
Keep MPC8308 operational by always starting transfers from software,
this SoC appears to not have request lines for flow control when
peripherals are involved in transfers.
Signed-off-by: Alexander Popov
---
drivers/dma/mpc512x_dma.c | 201 --
1 file changed, 193 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index f41639f..d0c8950 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -2,6 +2,7 @@
* Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
* Copyright (C) Semihalf 2009
* Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2013
*
* Written by Piotr Ziecik . Hardware description
* (defines, structures and comments) was taken from MPC5121 DMA driver
@@ -28,11 +29,6 @@
* file called COPYING.
*/
-/*
- * This is initial version of MPC5121 DMA driver. Only memory to memory
- * transfers are supported (tested using dmatest module).
- */
-
#include
#include
#include
@@ -187,6 +183,7 @@ struct mpc_dma_desc {
dma_addr_t tcd_paddr;
int error;
struct list_headnode;
+ int will_access_peripheral;
};
struct mpc_dma_chan {
@@ -199,6 +196,10 @@ struct mpc_dma_chan {
struct mpc_dma_tcd *tcd;
dma_addr_t tcd_paddr;
+ /* Settings for access to peripheral FIFO */
+ dma_addr_t per_paddr; /* FIFO address */
+ u32 tcd_nunits;
+
/* Lock for this structure */
spinlock_t lock;
};
@@ -247,10 +248,27 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
struct mpc_dma_desc *first = NULL;
struct mpc_dma_desc *prev = NULL;
struct mpc_dma_desc *mdesc;
+ int staffed = 0;
int cid = mchan->chan.chan_id;
- /* Move all queued descriptors to active list */
- list_splice_tail_init(&mchan->queued, &mchan->active);
+ /*
+* Mem-to-mem transfers can be chained
+* together into one transaction.
+* But each transfer which involves peripherals
+* must be executed separately.
+*/
+ while (!staffed) {
+ mdesc = list_first_entry(&mchan->queued,
+ struct mpc_dma_desc, node);
+
+ if (!mdesc->will_access_peripheral)
+ list_move_tail(&mdesc->node, &mchan->active);
+ else {
+ staffed = 1;
+ if (list_empty(&mchan->active))
+ list_move_tail(&mdesc->node, &mchan->active);
+ }
+ }
/* Chain descriptors into one transaction */
list_for_each_entry(mdesc, &mchan->active, node) {
@@ -264,6 +282,8 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
prev->tcd->dlast_sga = mdesc->tcd_paddr;
prev->tcd->e_sg = 1;
+
+ /* software start for mem-to-mem transfers */
mdesc->tcd->start = 1;
prev = mdesc;
@@ -276,7 +296,17 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
if (first != prev)
mdma->tcd[cid].e_sg = 1;
- out_8(&mdma->regs->dmassrt, cid);
+
+ if (mdma->is_mpc8308) {
+ /* MPC8308, no request lines, software initiated start */
+ out_8(&mdma->regs->dmassrt, cid);
+ } else if (first->will_access_peripheral) {
+ /* peripherals involved, use external request line */
+ out_8(&mdma->regs->dmaserq, cid);
+ } else {
+ /* memory to memory transfer, software initiated start */
+ out_8(&mdma->regs->dmassrt, cid);
+ }
}
/* Handle interrupt on one half of DMA controller (32 channels) */
@@ -594,6 +624,7 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst,
dma_addr_t src,
}
mdesc->error = 0;
+ mdesc->will_access_peripheral = 0;
tcd = mdesc->tcd;
/* Prepare Transfer Control Descriptor for this transaction */
@@ -641,6 +672,157 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t
dst, dma_addr_t src,
return &mdesc->desc;
}
+static struct dma_async_tx_descriptor *mpc_dma_prep_slave_sg(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transf
Re: [PATCH RFC v2 3/5] dma: of: Add common xlate function for matching by channel id
From: Lars-Peter Clausen
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it
will use to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter. The filter
function will use this pointer to match only channels which belong to the
specified DMA controller.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Gerhard Sittig
---
drivers/dma/of-dma.c | 47 ++
+
include/linux/of_dma.h |4
2 files changed, 51 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 7aa0864..d5d528e 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -229,3 +229,50 @@ struct dma_chan *of_dma_simple_xlate(struct
of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+struct of_dma_filter_by_chan_id_args {
+ struct dma_device *dev;
+ unsigned int chan_id;
+};
+
+static bool of_dma_filter_by_chan_id(struct dma_chan *chan, void *params)
+{
+ struct of_dma_filter_by_chan_id_args *args = params;
+
+ return chan->device == args->dev && chan->chan_id == args->chan_id;
+}
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma:pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver
which wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+ struct of_dma_filter_by_chan_id_args args;
+ dma_cap_mask_t cap;
+
+ args.dev = ofdma->of_dma_data;
+ if (!args.dev)
+ return NULL;
+
+ if (dma_spec->args_count != 1)
+ return NULL;
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ args.chan_id = dma_spec->args[0];
+
+ return dma_request_channel(cap, of_dma_filter_by_chan_id, &args);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 364dda7..b7cf614 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -42,6 +42,8 @@ extern struct dma_chan
*of_dma_request_slave_channel(struct device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct
of_phandle_args *dma_spec,
+ struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -67,6 +69,8 @@ static inline struct dma_chan
*of_dma_simple_xlate(struct of_phandle_args *dma_s
return NULL;
}
+#define of_dma_xlate_by_chan_id NULL
+
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v2 4/5] dma: mpc512x: register for device tree channel lookup
From: Gerhard Sittig
register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees), provide
the '#dma-cells' property in the shared mpc5121.dtsi file, and introduce
a bindings document for the MPC512x DMA controller
Signed-off-by: Gerhard Sittig
---
.../devicetree/bindings/dma/
mpc512x-dma.txt| 55
arch/powerpc/boot/dts/mpc5121.dtsi |1 +
drivers/dma/mpc512x_dma.c | 21 ++--
3 files changed, 74 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 000..a4867d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,55 @@
+* Freescale MPC512x DMA Controller
+
+The DMA controller in the Freescale MPC512x SoC can move blocks of
+memory contents between memory and peripherals or memory to memory.
+
+Refer to the "Generic DMA Controller and DMA request bindings" description
+in the dma.txt file for a more detailled discussion of the binding. The
+MPC512x DMA engine binding follows the common scheme, but doesn't provide
+support for the optional channels and requests counters (those values are
+derived from the detected hardware features) and has a fixed client
+specifier length of 1 integer cell (the value is the DMA channel, since
+the DMA controller uses a fixed assignment of request lines per channel).
+
+
+DMA controller node properties:
+
+Required properties:
+- compatible: should be "fsl,mpc5121-dma"
+- reg: address and size of the DMA controller's register set
+- interrupts: interrupt spec for the DMA controller
+
+Optional properties:
+- #dma-cells: must be <1>, describes the number of integer cells
+ needed to specify the 'dmas' property in client nodes,
+ strongly recommended since common client helper code
+ uses this property
+
+Example:
+
+ dma0: dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ };
+
+
+Client node properties:
+
+Required properties:
+- dmas:list of DMA specifiers, consisting
each of a handle
+ for the DMA controller and integer cells to specify
+ the channel used within the DMA controller
+- dma-names: list of identifier strings for the DMA specifiers,
+ client device driver code uses these strings to
+ have DMA channels looked up at the controller
+
+Example:
+
+ sdhc@1500 {
+ compatible = "fsl,mpc5121-sdhc";
+ /* ... */
+ dmas = <&dma0 30>;
+ dma-names = "rx-tx";
+ };
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi
b/arch/powerpc/boot/dts/mpc5121.dtsi
index 384e692..dae99b7 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -394,6 +394,7 @@
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+ #dma-cells = <1>;
};
};
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 8f6d545..3d79e3a 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -939,11 +940,23 @@ static int mpc_dma_probe(struct platform_device *op)
/* Register DMA engine */
dev_set_drvdata(dev, mdma);
retval = dma_async_device_register(dma);
- if (retval) {
- devm_free_irq(dev, mdma->irq, mdma);
- irq_dispose_mapping(mdma->irq);
+ if (retval)
+ goto out_irq;
+
+ /* register with OF helpers for DMA lookups (nonfatal) */
+ if (dev->of_node) {
+ retval = of_dma_controller_register(dev->of_node,
+ of_dma_xlate_by_chan_id,
+ mdma);
+ if (retval)
+ dev_warn(dev, "could not register for OF lookup\n");
}
+ return 0;
+
+out_irq:
+ devm_free_irq(dev, mdma->irq, mdma);
+ irq_dispose_mapping(mdma->irq);
return retval;
}
@@ -952,6 +965,8 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = &op->dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
+ if (dev->of_node)
+ of_dma_controller_free(dev->of_node);
dma_async_device_unregister(&mdma->dma);
devm_free_irq(dev, m
Re: [PATCH RFC v2 5/5] HACK mmc: mxcmmc: enable clocks for the MPC512x
From: Gerhard Sittig
Q&D HACK to enable SD card support without correct COMMON_CLK support,
best viewed with 'git diff -w -b', NOT acceptable for mainline (NAKed)
Signed-off-by: Gerhard Sittig
---
drivers/mmc/host/mxcmmc.c | 41 +++---
---
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index d503635..b9d21cc 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -1121,20 +1121,29 @@ static int mxcmci_probe(struct platform_device *pdev)
host->res = r;
host->irq = irq;
- host->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
- if (IS_ERR(host->clk_ipg)) {
- ret = PTR_ERR(host->clk_ipg);
- goto out_iounmap;
- }
+ if (!is_mpc512x_mmc(host)) {
+ host->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+ if (IS_ERR(host->clk_ipg)) {
+ ret = PTR_ERR(host->clk_ipg);
+ goto out_iounmap;
+ }
- host->clk_per = devm_clk_get(&pdev->dev, "per");
- if (IS_ERR(host->clk_per)) {
- ret = PTR_ERR(host->clk_per);
- goto out_iounmap;
+ host->clk_per = devm_clk_get(&pdev->dev, "per");
+ if (IS_ERR(host->clk_per)) {
+ ret = PTR_ERR(host->clk_per);
+ goto out_iounmap;
+ }
+ } else {
+ host->clk_per = devm_clk_get(&pdev->dev, "sdhc_clk");
+ if (IS_ERR(host->clk_per)) {
+ ret = PTR_ERR(host->clk_per);
+ goto out_iounmap;
+ }
}
clk_prepare_enable(host->clk_per);
- clk_prepare_enable(host->clk_ipg);
+ if (host->clk_ipg)
+ clk_prepare_enable(host->clk_ipg);
mxcmci_softreset(host);
@@ -1204,7 +1213,8 @@ out_free_dma:
dma_release_channel(host->dma);
out_clk_put:
clk_disable_unprepare(host->clk_per);
- clk_disable_unprepare(host->clk_ipg);
+ if (host->clk_ipg)
+ clk_disable_unprepare(host->clk_ipg);
out_iounmap:
iounmap(host->base);
out_free:
@@ -1236,7 +1246,8 @@ static int mxcmci_remove(struct platform_device *pdev)
dma_release_channel(host->dma);
clk_disable_unprepare(host->clk_per);
- clk_disable_unprepare(host->clk_ipg);
+ if (host->clk_ipg)
+ clk_disable_unprepare(host->clk_ipg);
release_mem_region(host->res->start, resource_size(host->res));
@@ -1255,7 +1266,8 @@ static int mxcmci_suspend(struct device *dev)
if (mmc)
ret = mmc_suspend_host(mmc);
clk_disable_unprepare(host->clk_per);
- clk_disable_unprepare(host->clk_ipg);
+ if (host->clk_ipg)
+ clk_disable_unprepare(host->clk_ipg);
return ret;
}
@@ -1267,7 +1279,8 @@ static int mxcmci_resume(struct device *dev)
int ret = 0;
clk_prepare_enable(host->clk_per);
- clk_prepare_enable(host->clk_ipg);
+ if (host->clk_ipg)
+ clk_prepare_enable(host->clk_ipg);
if (mmc)
ret = mmc_resume_host(mmc);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 1/2] powerpc: Use HPTE constants when updating hpte bits
From: "Aneesh Kumar K.V"
Even though we have same value for linux PTE bits and hash PTE pits
use the hash pte bits wen updating hash pte
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/platforms/cell/beat_htab.c | 4 ++--
arch/powerpc/platforms/pseries/lpar.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/beat_htab.c
b/arch/powerpc/platforms/cell/beat_htab.c
index c34ee4e..d4d245c 100644
--- a/arch/powerpc/platforms/cell/beat_htab.c
+++ b/arch/powerpc/platforms/cell/beat_htab.c
@@ -111,7 +111,7 @@ static long beat_lpar_hpte_insert(unsigned long hpte_group,
DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
if (rflags & _PAGE_NO_CACHE)
- hpte_r &= ~_PAGE_COHERENT;
+ hpte_r &= ~HPTE_R_M;
raw_spin_lock(&beat_htab_lock);
lpar_rc = beat_read_mask(hpte_group);
@@ -337,7 +337,7 @@ static long beat_lpar_hpte_insert_v3(unsigned long
hpte_group,
DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
if (rflags & _PAGE_NO_CACHE)
- hpte_r &= ~_PAGE_COHERENT;
+ hpte_r &= ~HPTE_R_M;
/* insert into not-volted entry */
lpar_rc = beat_insert_htab_entry3(0, hpte_group, hpte_v, hpte_r,
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 02d6e21..78f2c59 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -146,8 +146,9 @@ static long pSeries_lpar_hpte_insert(unsigned long
hpte_group,
flags = 0;
/* Make pHyp happy */
- if ((rflags & _PAGE_NO_CACHE) & !(rflags & _PAGE_WRITETHRU))
- hpte_r &= ~_PAGE_COHERENT;
+ if ((rflags & _PAGE_NO_CACHE) && !(rflags & _PAGE_WRITETHRU))
+ hpte_r &= ~HPTE_R_M;
+
if (firmware_has_feature(FW_FEATURE_XCMO) && !(hpte_r & HPTE_R_N))
flags |= H_COALESCE_CAND;
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -V2 2/2] powerpc: Free up _PAGE_COHERENCE for numa fault use later
From: "Aneesh Kumar K.V" Set memory coherence always on hash64 config. If a platform cannot have memory coherence always set they can infer that from _PAGE_NO_CACHE and _PAGE_WRITETHRU like in lpar. So we dont' really need a separate bit for tracking _PAGE_COHERENCE. Signed-off-by: Aneesh Kumar K.V --- Changes from v1: Fix boot issue with Phyp, because of missing HPTE_R_M on bolted entries. arch/powerpc/include/asm/pte-hash64.h | 2 +- arch/powerpc/mm/hash_low_64.S | 15 --- arch/powerpc/mm/hash_utils_64.c | 7 --- arch/powerpc/mm/hugepage-hash64.c | 6 +- arch/powerpc/mm/hugetlbpage-hash64.c | 4 5 files changed, 26 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/include/asm/pte-hash64.h b/arch/powerpc/include/asm/pte-hash64.h index 0419eeb..55aea0c 100644 --- a/arch/powerpc/include/asm/pte-hash64.h +++ b/arch/powerpc/include/asm/pte-hash64.h @@ -19,7 +19,7 @@ #define _PAGE_FILE 0x0002 /* (!present only) software: pte holds file offset */ #define _PAGE_EXEC 0x0004 /* No execute on POWER4 and newer (we invert) */ #define _PAGE_GUARDED 0x0008 -#define _PAGE_COHERENT 0x0010 /* M: enforce memory coherence (SMP systems) */ +/* We can derive Memory coherence from _PAGE_NO_CACHE */ #define _PAGE_NO_CACHE 0x0020 /* I: cache inhibit */ #define _PAGE_WRITETHRU0x0040 /* W: cache write-through */ #define _PAGE_DIRTY0x0080 /* C: page changed */ diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S index d3cbda6..1136d26 100644 --- a/arch/powerpc/mm/hash_low_64.S +++ b/arch/powerpc/mm/hash_low_64.S @@ -148,7 +148,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT) and r0,r0,r4/* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/ andcr0,r30,r0 /* r0 = pte & ~r0 */ rlwimi r3,r0,32-1,31,31/* Insert result into PP lsb */ - ori r3,r3,HPTE_R_C /* Always add "C" bit for perf. */ + /* +* Always add "C" bit for perf. Memory coherence is always enabled +*/ + ori r3,r3,HPTE_R_C | HPTE_R_M /* We eventually do the icache sync here (maybe inline that * code rather than call a C function...) @@ -457,7 +460,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT) and r0,r0,r4/* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/ andcr0,r3,r0/* r0 = pte & ~r0 */ rlwimi r3,r0,32-1,31,31/* Insert result into PP lsb */ - ori r3,r3,HPTE_R_C /* Always add "C" bit for perf. */ + /* +* Always add "C" bit for perf. Memory coherence is always enabled +*/ + ori r3,r3,HPTE_R_C | HPTE_R_M /* We eventually do the icache sync here (maybe inline that * code rather than call a C function...) @@ -795,7 +801,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT) and r0,r0,r4/* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/ andcr0,r30,r0 /* r0 = pte & ~r0 */ rlwimi r3,r0,32-1,31,31/* Insert result into PP lsb */ - ori r3,r3,HPTE_R_C /* Always add "C" bit for perf. */ + /* +* Always add "C" bit for perf. Memory coherence is always enabled +*/ + ori r3,r3,HPTE_R_C | HPTE_R_M /* We eventually do the icache sync here (maybe inline that * code rather than call a C function...) diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 6ecc38b..4e9b932 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -169,9 +169,10 @@ static unsigned long htab_convert_pte_flags(unsigned long pteflags) if ((pteflags & _PAGE_USER) && !((pteflags & _PAGE_RW) && (pteflags & _PAGE_DIRTY))) rflags |= 1; - - /* Always add C */ - return rflags | HPTE_R_C; + /* +* Always add "C" bit for perf. Memory coherence is always enabled +*/ + return rflags | HPTE_R_C | HPTE_R_M; } int htab_bolt_mapping(unsigned long vstart, unsigned long vend, diff --git a/arch/powerpc/mm/hugepage-hash64.c b/arch/powerpc/mm/hugepage-hash64.c index 34de9e0..b640595 100644 --- a/arch/powerpc/mm/hugepage-hash64.c +++ b/arch/powerpc/mm/hugepage-hash64.c @@ -127,7 +127,11 @@ repeat: /* Add in WIMG bits */ rflags |= (new_pmd & (_PAGE_WRITETHRU | _PAGE_NO_CACHE | - _PAGE_COHERENT | _PAGE_GUARDED)); + _PAGE_GUARDED)); + /* +* enable the memory coherence always +*/ + rflgs |= HPTE_R_M; /* Insert into the hash table, primary slot */ slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags, 0, diff --git a/arch/powerp
Re: [PATCH 6/9][v5] powerpc/perf: Define big-endian version of perf_mem_data_src
Michael Ellerman [mich...@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 | > | > /* | > + * Kernel and userspace check for endianness in incompatible ways. | > + * In user space, 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 ? BTW, any clues on why there are so many different ways of checking endianness ? Any standards related stuff or just evolution ? Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check
On Wed, Oct 02, 2013 at 09:15:22PM -0700, Guenter Roeck wrote: > irq_of_parse_and_map() returns 0 on error, not NO_IRQ. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/9][v5] powerpc/perf: Export Power8 generic events in sysfs
Michael Ellerman [mich...@ellerman.id.au] wrote: | 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 | > Reviewed-by: Anshuman Khandual | > --- | > 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. It is a bit confusing. The GENERIC_EVENT_ATTR() adds the PME_ prefix. I kept this change minimal for now, since we will have to revisit this once the Power8 events are finalized. Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
Michael Ellerman [mich...@ellerman.id.au] wrote:
| 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.
Agree. Will try this out. This is certainly more efficient.
|
| 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)
how about I call this is_load_store_2_06() and add a comment. Horrible
but minimizes chance of misuse.
| {
| 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 50/77] mlx5: Update MSI/MSI-X interrupts enablement code
On Thu, Oct 03, 2013 at 10:14:33AM +0300, Eli Cohen wrote:
> 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?
pci_enable_msix() may fail, but it can not return a positive number.
We first calculate how many MSI-Xs we need, adjust to what we can get,
check if that is enough and only then go for it.
> > - 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)
--
Regards,
Alexander Gordeev
agord...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
On 10/3/2013 2:03 PM, Sukadev Bhattiprolu wrote: Michael Ellerman [mich...@ellerman.id.au] wrote: | | if (lower == 6) | if (upper <= 1) | return true; | return false; v Note that this case covers the lvsl/lvsr instructions, which, despite their names are not actually loads. So you could eliminate this check and do just a little bit better. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 01/77] PCI/MSI: Fix return value when populate_msi_sysfs() failed
On Wed, 2013-10-02 at 17:39 -0700, Jon Mason wrote: > On Wed, Oct 02, 2013 at 12:48:17PM +0200, Alexander Gordeev wrote: > > Signed-off-by: Alexander Gordeev > > 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. [...] This function was already treating that error as fatal, and freeing the MSIs. The change in behaviour is that it now returns the error code in this case, rather than 0. This is obviously correct and properly described by the one-line summary. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 06/77] PCI/MSI: Factor out pci_get_msi_cap() interface
On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
[...]
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -812,6 +812,21 @@ static int pci_msi_check_device(struct pci_dev *dev, int
> nvec, int type)
> return 0;
> }
>
> +int pci_get_msi_cap(struct pci_dev *dev)
> +{
> + int ret;
> + u16 msgctl;
> +
> + if (!dev->msi_cap)
> + return -EINVAL;
[...]
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1144,6 +1144,11 @@ struct msix_entry {
>
>
> #ifndef CONFIG_PCI_MSI
> +static inline int pci_get_msi_cap(struct pci_dev *dev)
> +{
> + return -1;
[...]
Shouldn't this also return -EINVAL?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
> This series is against "next" branch in Bjorn's repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
>
> Currently pci_enable_msi_block() and pci_enable_msix() interfaces
> return a error code in case of failure, 0 in case of success and a
> positive value which indicates the number of MSI-X/MSI interrupts
> that could have been allocated. The latter value should be passed
> to a repeated call to the interfaces until a failure or success:
>
>
> for (i = 0; i < FOO_DRIVER_MAXIMUM_NVEC; i++)
> adapter->msix_entries[i].entry = i;
>
> while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
> rc = pci_enable_msix(adapter->pdev,
>adapter->msix_entries, nvec);
> if (rc > 0)
> nvec = rc;
> else
> return rc;
> }
>
> return -ENOSPC;
>
>
> This technique proved to be confusing and error-prone. Vast share
> of device drivers simply fail to follow the described guidelines.
>
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
[...]
I think this is fundamentally flawed: pci_msix_table_size() and
pci_get_msi_cap() can only report the limits of the *device* (which the
driver usually already knows), whereas MSI allocation can also be
constrained due to *global* limits on the number of distinct IRQs.
Currently pci_enable_msix() will report a positive value if it fails due
to the global limit. Your patch 7 removes that. pci_enable_msi_block()
unfortunately doesn't appear to do this.
It seems to me that a more useful interface would take a minimum and
maximum number of vectors from the driver. This wouldn't allow the
driver to specify that it could only accept, say, any even number within
a certain range, but you could still leave the current functions
available for any driver that needs that.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v7] powerpc/mpc85xx:Add initial device tree support of T104x
On Mon, Sep 30, 2013 at 10:49 PM, Prabhakar Kushwaha wrote: > > do we have any scripts which check for whitespace as checkpatch never give > any warning/error. > it is a very silly mistake which I am doing continuously :( Use a proper code editor. I've never had this problem, so I'm guessing your editor is not good enough. I use Slickedit, but there are others that work just as well. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc/kernel/sysfs: cleanup set up macros for PMC/non-PMC SPRs
On Thu, Oct 3, 2013 at 2:27 AM, Madhavan Srinivasan wrote: > Currently PMC (Performance Monitor Counter) setup macros are used > for other SPRs. Since not all SPRs are PMC related, this patch > modifies the exisiting macro and uses it to setup both PMC and > non PMC SPRs accordingly. > > V3 changes: > > 1) No logic change, just renamed generic macro and removed #define for empty > string > 2) Changes in the comment to explain better. > > V2 changes: > > 1) Modified SYSFS_PMCSETUP to a generic macro with additional parameter > 2) Added PMC and SPR macro to call the generic macro > 3) Changes in the comment to explain better. > > Signed-off-by: Madhavan Srinivasan Acked-by: Olof Johansson For the pa6t parts -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 06/77] PCI/MSI: Factor out pci_get_msi_cap() interface
On Thu, Oct 03, 2013 at 10:52:54PM +0100, Ben Hutchings wrote:
> On Wed, 2013-10-02 at 12:48 +0200, Alexander Gordeev wrote:
> > #ifndef CONFIG_PCI_MSI
> > +static inline int pci_get_msi_cap(struct pci_dev *dev)
> > +{
> > + return -1;
> [...]
>
> Shouldn't this also return -EINVAL?
Yep, all inliners here are better to return -EINVAL.
Will do unless someone speaks out against.
> Ben.
--
Regards,
Alexander Gordeev
agord...@redhat.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 net-next] fix unsafe set_memory_rw from softirq
On Thu, 2013-10-03 at 21:11 -0700, Alexei Starovoitov wrote:
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index a6ac848..5d66cd9 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -25,15 +25,20 @@ struct sk_filter
> {
> atomic_trefcnt;
> unsigned intlen;/* Number of filter blocks */
> + struct rcu_head rcu;
> unsigned int(*bpf_func)(const struct sk_buff *skb,
> const struct sock_filter *filter);
> - struct rcu_head rcu;
> + /* insns start right after bpf_func, so that sk_run_filter() fetches
> + * first insn from the same cache line that was used to call into
> + * sk_run_filter()
> + */
> struct sock_filter insns[0];
> };
>
> static inline unsigned int sk_filter_len(const struct sk_filter *fp)
> {
> - return fp->len * sizeof(struct sock_filter) + sizeof(*fp);
> + return max(fp->len * sizeof(struct sock_filter),
> +sizeof(struct work_struct)) + sizeof(*fp);
> }
I would use for include/linux/filter.h this (untested) diff :
(Note the include )
I also remove your comment about cache lines, since there is nothing
to align stuff on a cache line boundary.
diff --git a/include/linux/filter.h b/include/linux/filter.h
index a6ac848..281b05c 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#ifdef CONFIG_COMPAT
@@ -25,15 +26,20 @@ struct sk_filter
{
atomic_trefcnt;
unsigned intlen;/* Number of filter blocks */
+ struct rcu_head rcu;
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct sock_filter *filter);
- struct rcu_head rcu;
- struct sock_filter insns[0];
+ union {
+ struct work_struct work;
+ struct sock_filter insns[0];
+ };
};
-static inline unsigned int sk_filter_len(const struct sk_filter *fp)
+static inline unsigned int sk_filter_size(const struct sk_filter *fp,
+ unsigned int proglen)
{
- return fp->len * sizeof(struct sock_filter) + sizeof(*fp);
+ return max(sizeof(*fp),
+ offsetof(struct sk_filter, insns[proglen]));
}
extern int sk_filter(struct sock *sk, struct sk_buff *skb);
This way, you can use sk_filter_size(fp, fprog->len)
instead of doing the max() games in sk_attach_filter() and
sk_unattached_filter_create()
Other than that, I think your patch is fine.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/7] powerpc: Add interface to get msi region information
> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-ow...@vger.kernel.org]
> On Behalf Of Bjorn Helgaas
> Sent: Wednesday, September 25, 2013 5:28 AM
> To: Bhushan Bharat-R65777
> Cc: alex.william...@redhat.com; j...@8bytes.org; b...@kernel.crashing.org;
> ga...@kernel.crashing.org; linux-ker...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-...@vger.kernel.org; ag...@suse.de; Wood Scott-
> B07421; io...@lists.linux-foundation.org; Bhushan Bharat-R65777
> Subject: Re: [PATCH 1/7] powerpc: Add interface to get msi region information
>
> On Thu, Sep 19, 2013 at 12:59:17PM +0530, Bharat Bhushan wrote:
> > This patch adds interface to get following information
> > - Number of MSI regions (which is number of MSI banks for powerpc).
> > - Get the region address range: Physical page which have the
> > address/addresses used for generating MSI interrupt
> > and size of the page.
> >
> > These are required to create IOMMU (Freescale PAMU) mapping for
> > devices which are directly assigned using VFIO.
> >
> > Signed-off-by: Bharat Bhushan
> > ---
> > arch/powerpc/include/asm/machdep.h |8 +++
> > arch/powerpc/include/asm/pci.h |2 +
> > arch/powerpc/kernel/msi.c | 18
> > arch/powerpc/sysdev/fsl_msi.c | 39
> > +--
> > arch/powerpc/sysdev/fsl_msi.h | 11 -
> > drivers/pci/msi.c | 26
> > include/linux/msi.h|8 +++
> > include/linux/pci.h| 13
> > 8 files changed, 120 insertions(+), 5 deletions(-)
> >
> > ...
>
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index
> > aca7578..6d85c15 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -30,6 +30,20 @@ static int pci_msi_enable = 1;
> >
> > /* Arch hooks */
> >
> > +#ifndef arch_msi_get_region_count
> > +int arch_msi_get_region_count(void)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > +#ifndef arch_msi_get_region
> > +int arch_msi_get_region(int region_num, struct msi_region *region) {
> > + return 0;
> > +}
> > +#endif
>
> This #define strategy is gone; see 4287d824 ("PCI: use weak functions for MSI
> arch-specific functions"). Please use the weak function strategy for your new
> MSI region functions.
ok
>
> > +
> > #ifndef arch_msi_check_device
> > int arch_msi_check_device(struct pci_dev *dev, int nvec, int type) {
> > @@ -903,6 +917,18 @@ void pci_disable_msi(struct pci_dev *dev) }
> > EXPORT_SYMBOL(pci_disable_msi);
> >
> > +int msi_get_region_count(void)
> > +{
> > + return arch_msi_get_region_count();
> > +}
> > +EXPORT_SYMBOL(msi_get_region_count);
> > +
> > +int msi_get_region(int region_num, struct msi_region *region) {
> > + return arch_msi_get_region(region_num, region); }
> > +EXPORT_SYMBOL(msi_get_region);
>
> Please split these interface additions, i.e., the drivers/pci/msi.c,
> include/linux/msi.h, and include/linux/pci.h changes, into a separate patch.
ok
>
> I don't know enough about VFIO to understand why these new interfaces are
> needed. Is this the first VFIO IOMMU driver? I see vfio_iommu_spapr_tce.c
> and
> vfio_iommu_type1.c but I don't know if they're comparable to the Freescale
> PAMU.
> Do other VFIO IOMMU implementations support MSI? If so, do they handle the
> problem of mapping the MSI regions in a different way?
PAMU is an aperture type of IOMMU while other are paging type, So they are
completely different from what PAMU is and handle that differently.
>
> > /**
> > * pci_msix_table_size - return the number of device's MSI-X table entries
> > * @dev: pointer to the pci_dev data structure of MSI-X device
> > function diff --git a/include/linux/msi.h b/include/linux/msi.h index
> > ee66f3a..ae32601 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -50,6 +50,12 @@ struct msi_desc {
> > struct kobject kobj;
> > };
> >
> > +struct msi_region {
> > + int region_num;
> > + dma_addr_t addr;
> > + size_t size;
> > +};
>
> This needs some sort of explanatory comment.
Ok
-Bharat
>
> > /*
> > * The arch hook for setup up msi irqs
> > */
> > @@ -58,5 +64,7 @@ void arch_teardown_msi_irq(unsigned int irq); int
> > arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); void
> > arch_teardown_msi_irqs(struct pci_dev *dev); int
> > arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> > +int arch_msi_get_region_count(void);
> > +int arch_msi_get_region(int region_num, struct msi_region *region);
> >
> > #endif /* LINUX_MSI_H */
> > diff --git a/include/linux/pci.h b/include/linux/pci.h index
> > 186540d..2b26a59 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -1126,6 +1126,7 @@ struct msix_entry {
> > u16 entry; /* driver uses to specify entry, OS writes */
> > };
> >
> > +struct msi_region;
> >
> > #ifndef CONFIG_PCI_MSI
> >
Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d
On Friday, September 27, 2013 04:44:20 PM Yinghai Lu wrote:
> [+ Rafael]
>
> On Fri, Sep 27, 2013 at 4:19 PM, Benjamin Herrenschmidt
> wrote:
> > On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:
> >
> >> ok, please if you are ok attached one instead. It will print some warning
> >> about
> >> driver skipping pci_set_master, so we can catch more problem with drivers.
> >
> > Except that the message is pretty cryptic :-) Especially since the
> > driver causing the message to be printed is not the one that did
> > the mistake in the first place, it's the next one coming up that
> > trips the warning.
> >
> > In any case, the root cause is indeed the PCIe port driver:
> >
> > We don't have ACPI, so pcie_port_platform_notify() isn't implemented,
> > and pcie_ports_auto is true, so we end up with capabilities set to 0.
>
> in
> | commit fe31e69740eddc7316071ed5165fed6703c8cd12
> | Author: Rafael J. Wysocki
> | Date: Sun Dec 19 15:57:16 2010 +0100
> |
> |PCI/PCIe: Clear Root PME Status bits early during system resume
> |
> |I noticed that PCI Express PMEs don't work on my Toshiba Portege R500
> |after the system has been woken up from a sleep state by a PME
> |(through Wake-on-LAN). After some investigation it turned out that
> |the BIOS didn't clear the Root PME Status bit in the root port that
> |received the wakeup PME and since the Requester ID was also set in
> |the port's Root Status register, any subsequent PMEs didn't trigger
> |interrupts.
> |
> |This problem can be avoided by clearing the Root PME Status bits in
> |all PCI Express root ports during early resume. For this purpose,
> |add an early resume routine to the PCIe port driver and make this
> |driver be always registered, even if pci_ports_disable is set (in
> |which case the driver's only function is to provide the early
> |resume callback).
> |
> |
> |@@ -349,15 +349,18 @@ int pcie_port_device_register(struct pci_dev *dev)
> |int status, capabilities, i, nr_service;
> |int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
> |
> |- /* Get and check PCI Express port services */
> |- capabilities = get_port_device_capability(dev);
> |- if (!capabilities)
> |- return -ENODEV;
> |-
> |/* Enable PCI Express port device */
> |status = pci_enable_device(dev);
> |if (status)
> |return status;
> |+
> |+ /* Get and check PCI Express port services */
> |+ capabilities = get_port_device_capability(dev);
> |+ if (!capabilities) {
> |+ pcie_no_aspm();
> |+ return 0;
> |+ }
> |+
> |pci_set_master(dev);
> |/*
> | * Initialize service irqs. Don't use service devices that
>
> >
> > Thus the port driver bails out before calling pci_set_master(). The fix
> > is to call pci_set_master() unconditionally. However that lead me to
> > find to a few interesting oddities in that port driver code:
>
> can we revert that partially change ? aka we should check get_port
> at first...
>
> like attached.
It looks like we can do something like this (just pasting your patch):
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 31063ac..1ee6f16 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -362,16 +362,16 @@ int pcie_port_device_register(struct pci_dev *dev)
int status, capabilities, i, nr_service;
int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
- /* Enable PCI Express port device */
- status = pci_enable_device(dev);
- if (status)
- return status;
-
/* Get and check PCI Express port services */
capabilities = get_port_device_capability(dev);
if (!capabilities)
return 0;
+ /* Enable PCI Express port device */
+ status = pci_enable_device(dev);
+ if (status)
+ return status;
+
pci_set_master(dev);
/*
* Initialize service irqs. Don't use service devices that
but I don't have that box with me to test whether or not it still works
correctly after this change. I'll be back home on the next Saturday if
all goes well.
Thanks,
Rafael
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 RESEND 0/3] cpufreq/ondemand support for Xserve G5 & iMac G5 iSight
On Monday, September 30, 2013 11:44:30 PM Aaro Koskinen wrote: > Hi, > > This is a resend of the v2 patchset: > > http://marc.info/?t=13779701321&r=1&w=2 > > No changes except rebasing. Any chance to get these into v3.13? Well, Ben's ACKs are missing as far as I'm concerned ... > Aaro Koskinen (3): > cpufreq: pmac64: speed up frequency switch > cpufreq: pmac64: provide cpufreq transition latency for older G5 > models > cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) model > > drivers/cpufreq/pmac64-cpufreq.c | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 59/77] qla2xxx: Update MSI/MSI-X interrupts enablement code
Acked-by: Saurav Kashyap
>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
>---
> drivers/scsi/qla2xxx/qla_isr.c | 18 +++---
> 1 files changed, 11 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/scsi/qla2xxx/qla_isr.c
>b/drivers/scsi/qla2xxx/qla_isr.c
>index df1b30b..6c11ab9 100644
>--- a/drivers/scsi/qla2xxx/qla_isr.c
>+++ b/drivers/scsi/qla2xxx/qla_isr.c
>@@ -2836,16 +2836,20 @@ qla24xx_enable_msix(struct qla_hw_data *ha,
>struct rsp_que *rsp)
> for (i = 0; i < ha->msix_count; i++)
> entries[i].entry = i;
>
>- ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
>- if (ret) {
>+ ret = pci_msix_table_size(ha->pdev);
>+ if (ret < 0) {
>+ goto msix_failed;
>+ } else {
> if (ret < MIN_MSIX_COUNT)
> goto msix_failed;
>
>- ql_log(ql_log_warn, vha, 0x00c6,
>- "MSI-X: Failed to enable support "
>- "-- %d/%d\n Retry with %d vectors.\n",
>- ha->msix_count, ret, ret);
>- ha->msix_count = ret;
>+ if (ret < ha->msix_count) {
>+ ql_log(ql_log_warn, vha, 0x00c6,
>+ "MSI-X: Failed to enable support "
>+ "-- %d/%d\n Retry with %d vectors.\n",
>+ ha->msix_count, ret, ret);
>+ ha->msix_count = ret;
>+ }
> ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
> if (ret) {
> msix_failed:
>--
>1.7.7.6
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 net-next] fix unsafe set_memory_rw from softirq
On Thu, Oct 03, 2013 at 07:24:06PM -0700, Alexei Starovoitov wrote: > diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c > index 7092392..a5df511 100644 > --- a/arch/s390/net/bpf_jit_comp.c > +++ b/arch/s390/net/bpf_jit_comp.c > @@ -881,7 +881,9 @@ void bpf_jit_free(struct sk_filter *fp) > struct bpf_binary_header *header = (void *)addr; > > if (fp->bpf_func == sk_run_filter) > - return; > + goto free_filter; > set_memory_rw(addr, header->pages); > module_free(NULL, header); > +free_filter: > + kfree(fp); > } For the s390 part: Acked-by: Heiko Carstens ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
