* Re: [PATCH -V2 5/5] powerpc: mm: book3s: Enable _PAGE_NUMA for book3s
From: Paul Mackerras @ 2013-11-20 4:37 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:13PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> We steal the _PAGE_COHERENCE bit and use that for indicating NUMA ptes.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V2 4/5] powerpc: mm: Only check for _PAGE_PRESENT in set_pte/pmd functions
From: Paul Mackerras @ 2013-11-20 4:36 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-5-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:12PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> We want to make sure we don't use these function when updating a pte
> or pmd entry that have a valid hpte entry, because these functions
> don't invalidate them. So limit the check to _PAGE_PRESENT bit.
> Numafault core changes use these functions for updating _PAGE_NUMA bits.
> That should be ok because when _PAGE_NUMA is set we can be sure that
> hpte entries are not present.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V2 2/5] powerpc: Free up _PAGE_COHERENCE for numa fault use later
From: Paul Mackerras @ 2013-11-20 4:35 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-3-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:10PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> 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 <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH -V2 1/5] powerpc: Use HPTE constants when updating hpte bits
From: Paul Mackerras @ 2013-11-20 4:35 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-mm
In-Reply-To: <1384766893-10189-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Mon, Nov 18, 2013 at 02:58:09PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Even though we have same value for linux PTE bits and hash PTE pits
bits, not pits :)
> use the hash pte bits wen updating hash pte
when, not wen
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
If you fix the spelling errors in the patch description:
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-20 4:16 UTC (permalink / raw)
To: Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Shawn Guo, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, Zhengxiong Jin, oskar@scara.com,
Fabio Estevam, lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131120033745.GD11009@MrMyself>
> > > The udelay just doesn't make sense to what you are talking about.
> > >
> > > Does SAI really need 10us delay between two register-updating?
> > >
> >
> > No, this is not must be.
>=20
> Then you should explain in your comments why you really put it here or
> just drop it if it's just a mistake.
>=20
The udelay will be removed then.
> > > ISSUE 2: There are two cases listed in 'Synchronous mode'.
> > > However, your driver doesn't take care of them.
> > > The SAI's synchronous mode looks like more flexible
> > > than SSI's. The driver needs to be more sophisticated
> > > so that it can handle multiple cases when TX/RX clocks
> > > are controlled by either TX or RX, and surely, the
> > > asynchronous mode as well.
> > >
> >
> > Because in Vybrid the transmitter bit clock and frame sync are to be
> > used by both the transmitter and receiver, and only this case can be
> > used here, so now I only handle this case.
>=20
> It's fairly okay if adding explicit comments to indicate that currently
> the driver only supports its Synchronous mode with clocks controlled by
> TX only.
>=20
Just think, on other platforms maybe only the Rx's clock is available.
Thus I think there should be one DT property to control this, and then the =
SAI driver can be more flexible.
Or could you give me some more practical ideas ?
--
Best Regards,
Xiubo
^ permalink raw reply
* Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Nicolin Chen @ 2013-11-20 3:37 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Wang Huan-B18965, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Guo Shawn-R65073, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, Jin Zhengxiong-R64188, oskar@scara.com,
Estevam Fabio-R49496, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, rob@landley.net,
Chen Guangyu-B42378, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F828AE980@039-SN2MPN1-012.039d.mgd.msft.net>
On Wed, Nov 20, 2013 at 11:37:45AM +0800, Xiubo Li-B47053 wrote:
>
> > The udelay just doesn't make sense to what you are talking about.
> >
> > Does SAI really need 10us delay between two register-updating?
> >
>
> No, this is not must be.
Then you should explain in your comments why you really put it here or just
drop it if it's just a mistake.
> > We basically use udelay only if the IP hardware actually needs it: some
> > IP needs time to boot itself up after doing software reset for example.
> > But it doesn't look reasonable to me by using udelay to make sure "the
> > last enabled".
> >
> > And from the 'Synchronous mode' you just provided, there're another issue:
> >
> > + case SNDRV_PCM_TRIGGER_START:
> > + case SNDRV_PCM_TRIGGER_RESUME:
> > + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> > + tcsr |= FSL_SAI_CSR_TERE;
> > + rcsr |= FSL_SAI_CSR_TERE;
> > + writel(rcsr, sai->base + FSL_SAI_RCSR);
> > + udelay(10);
> > + writel(tcsr, sai->base + FSL_SAI_TCSR);
> > + break;
> > +
> > + case SNDRV_PCM_TRIGGER_STOP:
> > + case SNDRV_PCM_TRIGGER_SUSPEND:
> > + case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> > + if (!(dai->playback_active || dai->capture_active)) {
> > + tcsr &= ~FSL_SAI_CSR_TERE;
> > + rcsr &= ~FSL_SAI_CSR_TERE;
> > + }
> > + writel(rcsr, sai->base + FSL_SAI_RCSR);
> > + udelay(10);
> > + writel(tcsr, sai->base + FSL_SAI_TCSR);
> > + break;
> >
> > ISSUE 1: You might make sure transmitter is the last enabled.
> > However, it's not the first disabled. Is this okay?
> >
>
> Yes, this is just programming mistake. I'll revise it.
>
> In this case the transmitter should be the last enabled and the first disabled.
>
>
> > ISSUE 2: There are two cases listed in 'Synchronous mode'.
> > However, your driver doesn't take care of them.
> > The SAI's synchronous mode looks like more flexible
> > than SSI's. The driver needs to be more sophisticated
> > so that it can handle multiple cases when TX/RX clocks
> > are controlled by either TX or RX, and surely, the
> > asynchronous mode as well.
> >
>
> Because in Vybrid the transmitter bit clock and frame sync are to be used by
> both the transmitter and receiver, and only this case can be used here, so
> now I only handle this case.
It's fairly okay if adding explicit comments to indicate that currently the
driver only supports its Synchronous mode with clocks controlled by TX only.
Best,
Nicolin Chen
> >
> > And there's another personal tip: I think you can first try to focus on
> > this SAI driver and pend the others. There might be two many things you
> > need to refine if you are doing them at the same time.
> >
>
> I'll implement them later if needed.
>
>
> --
> Best Regards,
> Xiubo
>
^ permalink raw reply
* RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-20 3:37 UTC (permalink / raw)
To: Guangyu Chen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
perex@perex.cz, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Shawn Guo, grant.likely@linaro.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, Zhengxiong Jin, oskar@scara.com,
Fabio Estevam, lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131104043338.GA2345@MrMyself>
=20
> The udelay just doesn't make sense to what you are talking about.
>=20
> Does SAI really need 10us delay between two register-updating?
>=20
No, this is not must be.
> We basically use udelay only if the IP hardware actually needs it: some
> IP needs time to boot itself up after doing software reset for example.
> But it doesn't look reasonable to me by using udelay to make sure "the
> last enabled".
>=20
> And from the 'Synchronous mode' you just provided, there're another issue=
:
>=20
> + case SNDRV_PCM_TRIGGER_START:
> + case SNDRV_PCM_TRIGGER_RESUME:
> + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + tcsr |=3D FSL_SAI_CSR_TERE;
> + rcsr |=3D FSL_SAI_CSR_TERE;
> + writel(rcsr, sai->base + FSL_SAI_RCSR);
> + udelay(10);
> + writel(tcsr, sai->base + FSL_SAI_TCSR);
> + break;
> +
> + case SNDRV_PCM_TRIGGER_STOP:
> + case SNDRV_PCM_TRIGGER_SUSPEND:
> + case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> + if (!(dai->playback_active || dai->capture_active)) {
> + tcsr &=3D ~FSL_SAI_CSR_TERE;
> + rcsr &=3D ~FSL_SAI_CSR_TERE;
> + }
> + writel(rcsr, sai->base + FSL_SAI_RCSR);
> + udelay(10);
> + writel(tcsr, sai->base + FSL_SAI_TCSR);
> + break;
>=20
> ISSUE 1: You might make sure transmitter is the last enabled.
> However, it's not the first disabled. Is this okay?
>=20
Yes, this is just programming mistake. I'll revise it.
In this case the transmitter should be the last enabled and the first disab=
led.
> ISSUE 2: There are two cases listed in 'Synchronous mode'.
> However, your driver doesn't take care of them.
> The SAI's synchronous mode looks like more flexible
> than SSI's. The driver needs to be more sophisticated
> so that it can handle multiple cases when TX/RX clocks
> are controlled by either TX or RX, and surely, the
> asynchronous mode as well.
>=20
Because in Vybrid the transmitter bit clock and frame sync are to be used b=
y both the transmitter and receiver, and only this case can be used here, s=
o now I only handle this case.
>=20
> And there's another personal tip: I think you can first try to focus on
> this SAI driver and pend the others. There might be two many things you
> need to refine if you are doing them at the same time.
>=20
I'll implement them later if needed.
--
Best Regards,
Xiubo
^ permalink raw reply
* Recall: [PATCH 24/34] PCI: use weak functions for MSI arch-specific functions
From: Richard Zhu @ 2013-11-20 3:23 UTC (permalink / raw)
To: Richard Zhu
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
Heiko Carstens, Paul Mackerras, H. Peter Anvin,
sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King, x86@kernel.org, Ingo Molnar, Fenghua Yu,
Jason Cooper, Chris Metcalf, Thomas Gleixner, Thomas Petazzoni,
Tony Luck, Ralf Baechle, Martin Schwidefsky, linux390@de.ibm.com,
linuxppc-dev@lists.ozlabs.org, David S. Miller
Zhu Richard-R65037 would like to recall the message, "[PATCH 24/34] PCI: us=
e weak functions for MSI arch-specific functions".=
^ permalink raw reply
* [PATCH 24/34] PCI: use weak functions for MSI arch-specific functions
From: Richard Zhu @ 2013-11-20 2:50 UTC (permalink / raw)
To: r65037
Cc: linux-mips, linux-ia64, Heiko Carstens, Paul Mackerras,
H. Peter Anvin, sparclinux, linux-s390, Russell King, x86,
Ingo Molnar, Fenghua Yu, Jason Cooper, Chris Metcalf,
Thomas Gleixner, Thomas Petazzoni, Tony Luck, Ralf Baechle,
Martin Schwidefsky, linux390, linuxppc-dev, David S. Miller
In-Reply-To: <1384915853-31006-1-git-send-email-r65037@freescale.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch all those functions to use
the 'weak' mechanism. This commit converts all the architectures that
were overidding those MSI functions to use the new strategy.
Note that we keep two separate, non-weak, functions
default_teardown_msi_irqs() and default_restore_msi_irqs() for the
default behavior of the arch_teardown_msi_irqs() and
arch_restore_msi_irqs(), as the default behavior is needed by x86 PCI
code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: Daniel Price <daniel.price@gmail.com>
Tested-by: Thierry Reding <thierry.reding@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
arch/mips/include/asm/pci.h | 5 ----
arch/powerpc/include/asm/pci.h | 5 ----
arch/s390/include/asm/pci.h | 4 ---
arch/x86/include/asm/pci.h | 30 -------------------------
arch/x86/kernel/x86_init.c | 24 ++++++++++++++++++++
drivers/pci/msi.c | 48 ++++++++++++++++++++--------------------
include/linux/msi.h | 8 +++++-
7 files changed, 55 insertions(+), 69 deletions(-)
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index b8e24fd..031f4c1 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
return channel ? 15 : 14;
}
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-/* MSI arch hook for OCTEON */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#endif
-
extern char * (*pcibios_plat_setup)(char *str);
#ifdef CONFIG_OF
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6653f27..95145a1 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
/* Decide whether to display the domain number in /proc */
extern int pci_proc_domain(struct pci_bus *bus);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-#define arch_msi_check_device arch_msi_check_device
-
struct vm_area_struct;
/* Map a range of PCI memory or I/O space for a device into user space */
int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 6c18012..8641e8d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
int pci_domain_nr(struct pci_bus *);
int pci_proc_domain(struct pci_bus *);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-
#define ZPCI_BUS_NR 0 /* default bus number */
#define ZPCI_DEVFN 0 /* default device number */
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index d9e9e6c..7d74432 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
extern void pci_iommu_alloc(void);
#ifdef CONFIG_PCI_MSI
-/* MSI arch specific hooks */
-static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
- return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
-{
- x86_msi.teardown_msi_irqs(dev);
-}
-
-static inline void x86_teardown_msi_irq(unsigned int irq)
-{
- x86_msi.teardown_msi_irq(irq);
-}
-static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
-{
- x86_msi.restore_msi_irqs(dev, irq);
-}
-#define arch_setup_msi_irqs x86_setup_msi_irqs
-#define arch_teardown_msi_irqs x86_teardown_msi_irqs
-#define arch_teardown_msi_irq x86_teardown_msi_irq
-#define arch_restore_msi_irqs x86_restore_msi_irqs
/* implemented in arch/x86/kernel/apic/io_apic. */
struct msi_desc;
int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
@@ -130,16 +107,9 @@ void native_teardown_msi_irq(unsigned int irq);
void native_restore_msi_irqs(struct pci_dev *dev, int irq);
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
unsigned int irq_base, unsigned int irq_offset);
-/* default to the implementation in drivers/lib/msi.c */
-#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#define HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_teardown_msi_irqs(struct pci_dev *dev);
-void default_restore_msi_irqs(struct pci_dev *dev, int irq);
#else
#define native_setup_msi_irqs NULL
#define native_teardown_msi_irq NULL
-#define default_teardown_msi_irqs NULL
-#define default_restore_msi_irqs NULL
#endif
#define PCI_DMA_BUS_IS_PHYS (dma_ops->is_phys)
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 45a14db..5587f99 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -107,6 +107,8 @@ struct x86_platform_ops x86_platform = {
};
EXPORT_SYMBOL_GPL(x86_platform);
+
+#if defined(CONFIG_PCI_MSI)
struct x86_msi_ops x86_msi = {
.setup_msi_irqs = native_setup_msi_irqs,
.compose_msi_msg = native_compose_msi_msg,
@@ -116,6 +118,28 @@ struct x86_msi_ops x86_msi = {
.setup_hpet_msi = default_setup_hpet_msi,
};
+/* MSI arch specific hooks */
+int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ return x86_msi.setup_msi_irqs(dev, nvec, type);
+}
+
+void arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ x86_msi.teardown_msi_irqs(dev);
+}
+
+void arch_teardown_msi_irq(unsigned int irq)
+{
+ x86_msi.teardown_msi_irq(irq);
+}
+
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+ x86_msi.restore_msi_irqs(dev, irq);
+}
+#endif
+
struct x86_io_apic_ops x86_io_apic_ops = {
.init = native_io_apic_init_mappings,
.read = native_io_apic_read,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index aca7578..823c386 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
/* Arch hooks */
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
- return 0;
+ return -EINVAL;
}
-#endif
-#ifndef arch_setup_msi_irqs
-# define arch_setup_msi_irqs default_setup_msi_irqs
-# define HAVE_DEFAULT_MSI_SETUP_IRQS
-#endif
+void __weak arch_teardown_msi_irq(unsigned int irq)
+{
+}
-#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
-int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+ return 0;
+}
+
+int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
int ret;
@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
return 0;
}
-#endif
-
-#ifndef arch_teardown_msi_irqs
-# define arch_teardown_msi_irqs default_teardown_msi_irqs
-# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#endif
-#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
+/*
+ * We have a default implementation available as a separate non-weak
+ * function, as it is used by the Xen x86 PCI code
+ */
void default_teardown_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *entry;
@@ -89,14 +87,12 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
arch_teardown_msi_irq(entry->irq + i);
}
}
-#endif
-#ifndef arch_restore_msi_irqs
-# define arch_restore_msi_irqs default_restore_msi_irqs
-# define HAVE_DEFAULT_MSI_RESTORE_IRQS
-#endif
+void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ return default_teardown_msi_irqs(dev);
+}
-#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
void default_restore_msi_irqs(struct pci_dev *dev, int irq)
{
struct msi_desc *entry;
@@ -114,7 +110,11 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
if (entry)
write_msi_msg(irq, &entry->msg);
}
-#endif
+
+void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+ return default_restore_msi_irqs(dev, irq);
+}
static void msi_set_enable(struct pci_dev *dev, int enable)
{
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ee66f3a..271dfd1 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -51,12 +51,18 @@ struct msi_desc {
};
/*
- * The arch hook for setup up msi irqs
+ * The arch hooks to setup up msi irqs. Those functions are
+ * implemented as weak symbols so that they /can/ be overriden by
+ * architecture specific code if needed.
*/
int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
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);
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
+
+void default_teardown_msi_irqs(struct pci_dev *dev);
+void default_restore_msi_irqs(struct pci_dev *dev, int irq);
#endif /* LINUX_MSI_H */
--
1.7.8
^ permalink raw reply related
* Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Liu Gang @ 2013-11-20 2:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-gpio, linus.walleij, linuxppc-dev, r61911, b07421
In-Reply-To: <1384901494.1403.383.camel@snotra.buserror.net>
On Tue, 2013-11-19 at 16:51 -0600, Scott Wood wrote:
> > @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> > struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
> >
> > val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> > + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR);
> >
> > return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> > }
>
> It seems odd to update ->data in a function that's supposed to be
> reading things... Perhaps it would be better to keep ->data in a good
> state from the beginning.
>
> -Scott
Yes, keeping the ->data in a good state from the beginning will be
better. But this will need more code in different functions to cover
all the scenarios.
First, we should check the direct of the pin in the function
"mpc8xxx_gpio_set", and clean the input bit in ->data after setting
operation.
In addition, we may change a output pin to input and then read the
input status. So we also should update the ->data in
"mpc8xxx_gpio_dir_in" function.
So maybe it's better to eliminate the effects of the ->data to the
input pins when reading the status, regardless of the possible changes
of the pins and the data.
Do you think so?
Best Regards,
Liu Gang
^ permalink raw reply
* Re: [PATCH RESEND v4] powerpc: kvm: fix rare but potential deadlock scene
From: Liu ping fan @ 2013-11-20 2:42 UTC (permalink / raw)
To: Alexander Graf
Cc: Gleb Natapov, kvm@vger.kernel.org mailing list, kvm-ppc,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <C03A0DFC-4883-43CA-8EBB-0F80821C31BE@suse.de>
On Tue, Nov 19, 2013 at 6:39 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 19.11.2013, at 07:12, Liu Ping Fan <kernelfans@gmail.com> wrote:
>
>> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and
>> realmode, so it can trigger the deadlock.
>>
>> Suppose the following scene:
>>
>> Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of
>> vcpus.
>>
>> If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched
>> out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be
>> caught in realmode for a long time.
>>
>> What makes things even worse if the following happens,
>> On cpuM, bitlockX is hold, on cpuN, Y is hold.
>> vcpu_B_2 try to lock Y on cpuM in realmode
>> vcpu_A_2 try to lock X on cpuN in realmode
>>
>> Oops! deadlock happens
>>
>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>
> Any particular reason for the resend? The patch is already applied, no?
>
Oh, seems that I misunderstood your meaning. You said "Actually, I've
changed my mind and moved the patch to the for-3.13 branch instead.
Please make sure to CC kvm@vger on all patches you submit though". So
I think it is necessary to resend with cc kvm@vger
Regards,
Pingfan
^ permalink raw reply
* Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Liu Gang @ 2013-11-20 2:07 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linux-gpio, linus.walleij, linuxppc-dev, r61911, b07421
In-Reply-To: <20131119163230.70964d1f@crub>
On Tue, 2013-11-19 at 16:32 +0100, Anatolij Gustschin wrote:
> On Fri, 15 Nov 2013 15:16:29 +0800
> Liu Gang <Gang.Liu@freescale.com> wrote:
>
> > For MPC8572/MPC8536, the status of GPIOs defined as output
> > cannot be determined by reading GPDAT register, so the code
> > use shadow data register instead. But if the input pins are
> > asserted high, they will always read high due to the shadow
> > data, even if the pins are set to low.
>
> Could you please add a better description of the problem?
> I'm having some difficulties to understand the last sentence
> above. Does the issue appear if some pins were configured as
> inputs and were asserted high before booting the kernel, and
> therefore the shadow data has been initialized with these pin
> values?
>
> Or does the issue appear if some pin has been configured as output
> first and has been set to the high value, then reconfigured as
> input? Now reading the pin state will always return high even
> if the actual pin state is low?
>
> It seems the issue will appear in both cases. If so, please add
> this information to the commit message.
>
Yes, you are right.
I'll updated the description more clear.
> > val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> > + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR);
>
> we can reduce one in_be32() call here, i.e.
>
> u32 out_mask;
> ...
> out_mask = in_be32(mm->regs + GPIO_DIR);
> val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
> mpc8xxx_gc->data &= out_mask;
>
> > return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> > }
>
> Thanks,
>
> Anatolij
>
Granted, it will be better to reduce one in_be32() call.
I'll improve the method based on your and Scott's comments.
Thanks
Liu Gang
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
From: Li Zhong @ 2013-11-20 2:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, PowerPC email list, rmk+kernel
In-Reply-To: <1384910882.26969.57.camel@pasglop>
On Wed, 2013-11-20 at 12:28 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
> > I encountered following issue:
> > [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool
> > [ 5.688822] ibmvscsi: probe of 30000015 failed with error -1
> >
> > which prevents the storage from being recognized, and the machine from
> > booting.
> >
> > After some digging, it seems that it is caused by commit 4886c399da
> >
> > as dma_mask pointer in viodev->dev is not set, so in
> > dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called
> > because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO.
> > While before the commit, dma_set_coherent_mask() is always called.
> >
> > I tried to replace dma_set_mask_and_coherent() with
> > dma_coerce_mask_and_coherent(), and the machine could boot again.
> >
> > But I'm not sure whether this is the correct fix...
>
> Russell, care to chime in ? I can't make sense of the semantics...
>
> The original commit was fairly clear:
>
> <<
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
> >>
>
> It all makes sense so far ... but doesn't work for some odd reason,
> and the "fix" uses a function whose name doesn't make much sense to
> me ... what is the difference between "setting" and "coercing"
> the mask ? And why doe replacing two "set" with a "set both" doesn't
> work and require a coerce ?
I think the difference is because the check of return value from
dma_set_mask in dma_coerce_mask_and_coherent():
--
int rc = dma_set_mask(dev, mask);
if (rc == 0)
dma_set_coherent_mask(dev, mask);
--
and in struct device {, dma_mask is a pointer, while coherent_dma_mask
is value (don't know why we have this difference).
And here for pseries, dma_set_mask() failed because the dma_mask pointer
still remains null.
And in dma_coerce_mask_and_coherent(), the dma_mask is set with the
address of coherent_dma_mask
--
dev->dma_mask = &dev->coherent_dma_mask;
--
Thanks, Zhong
>
> I'm asking because I'm worried about breakage elsewhere...
>
> Cheers,
> Ben.
>
> > ---
> > arch/powerpc/kernel/vio.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> > index e7d0c88..76a6482 100644
> > --- a/arch/powerpc/kernel/vio.c
> > +++ b/arch/powerpc/kernel/vio.c
> > @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
> >
> > /* needed to ensure proper operation of coherent allocations
> > * later, in case driver doesn't set it explicitly */
> > - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> > + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> > }
> >
> > /* register with generic device framework */
> >
> >
> >
> >
>
>
^ permalink raw reply
* Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
From: Benjamin Herrenschmidt @ 2013-11-20 1:28 UTC (permalink / raw)
To: Li Zhong; +Cc: Paul Mackerras, PowerPC email list, rmk+kernel
In-Reply-To: <1384848697.2511.17.camel@ThinkPad-T5421>
On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
> I encountered following issue:
> [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool
> [ 5.688822] ibmvscsi: probe of 30000015 failed with error -1
>
> which prevents the storage from being recognized, and the machine from
> booting.
>
> After some digging, it seems that it is caused by commit 4886c399da
>
> as dma_mask pointer in viodev->dev is not set, so in
> dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called
> because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO.
> While before the commit, dma_set_coherent_mask() is always called.
>
> I tried to replace dma_set_mask_and_coherent() with
> dma_coerce_mask_and_coherent(), and the machine could boot again.
>
> But I'm not sure whether this is the correct fix...
Russell, care to chime in ? I can't make sense of the semantics...
The original commit was fairly clear:
<<
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
>>
It all makes sense so far ... but doesn't work for some odd reason,
and the "fix" uses a function whose name doesn't make much sense to
me ... what is the difference between "setting" and "coercing"
the mask ? And why doe replacing two "set" with a "set both" doesn't
work and require a coerce ?
I'm asking because I'm worried about breakage elsewhere...
Cheers,
Ben.
> ---
> arch/powerpc/kernel/vio.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index e7d0c88..76a6482 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
>
> /* needed to ensure proper operation of coherent allocations
> * later, in case driver doesn't set it explicitly */
> - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> }
>
> /* register with generic device framework */
>
>
>
>
^ permalink raw reply
* [PATCH 2/2] powerpc/pseries: Fix SMP=n build of rng.c
From: Michael Ellerman @ 2013-11-20 0:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1384905902-18042-1-git-send-email-mpe@ellerman.id.au>
In commit a489043 "Implement arch_get_random_long() based on H_RANDOM" I
broke the SMP=n build. We were getting plpar_wrappers.h via spinlock.h
which breaks when SMP=n.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/rng.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/rng.c b/arch/powerpc/platforms/pseries/rng.c
index a702f1c..72a1027 100644
--- a/arch/powerpc/platforms/pseries/rng.c
+++ b/arch/powerpc/platforms/pseries/rng.c
@@ -13,6 +13,7 @@
#include <linux/of.h>
#include <asm/archrandom.h>
#include <asm/machdep.h>
+#include <asm/plpar_wrappers.h>
static int pseries_get_random_long(unsigned long *v)
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/2] powerpc: Make cpu_to_chip_id() available when SMP=n
From: Michael Ellerman @ 2013-11-20 0:05 UTC (permalink / raw)
To: linuxppc-dev
Up until now we have only used cpu_to_chip_id() in the topology code,
which is only used on SMP builds. However my recent commit a4da0d5
"Implement arch_get_random_long/int() for powernv" added a usage when
SMP=n, breaking the build.
Move cpu_to_chip_id() into prom.c so it is available for SMP=n builds.
We would move the extern to prom.h, but that breaks the include in
topology.h. Instead we leave it in smp.h, but move it out of the
CONFIG_SMP #ifdef. We also need to include asm/smp.h in rng.c, because
the linux version skips asm/smp.h on UP. What a mess.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/smp.h | 2 +-
arch/powerpc/kernel/prom.c | 20 ++++++++++++++++++++
arch/powerpc/kernel/smp.c | 16 ----------------
arch/powerpc/platforms/powernv/rng.c | 1 +
4 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 98da78e..084e080 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -33,6 +33,7 @@ extern int boot_cpuid;
extern int spinning_secondaries;
extern void cpu_die(void);
+extern int cpu_to_chip_id(int cpu);
#ifdef CONFIG_SMP
@@ -112,7 +113,6 @@ static inline struct cpumask *cpu_core_mask(int cpu)
}
extern int cpu_to_core_id(int cpu);
-extern int cpu_to_chip_id(int cpu);
/* Since OpenPIC has only 4 IPIs, we use slightly different message numbers.
*
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 4432fd8..67a7b3b 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -786,6 +786,26 @@ int of_get_ibm_chip_id(struct device_node *np)
return -1;
}
+/**
+ * cpu_to_chip_id - Return the cpus chip-id
+ * @cpu: The logical cpu number.
+ *
+ * Return the value of the ibm,chip-id property corresponding to the given
+ * logical cpu number. If the chip-id can not be found, returns -1.
+ */
+int cpu_to_chip_id(int cpu)
+{
+ struct device_node *np;
+
+ np = of_get_cpu_node(cpu, NULL);
+ if (!np)
+ return -1;
+
+ of_node_put(np);
+ return of_get_ibm_chip_id(np);
+}
+EXPORT_SYMBOL(cpu_to_chip_id);
+
#ifdef CONFIG_PPC_PSERIES
/*
* Fix up the uninitialized fields in a new device node:
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 8e59abc..e5174d3 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -597,22 +597,6 @@ out:
return id;
}
-/* Return the value of the chip-id property corresponding
- * to the given logical cpu.
- */
-int cpu_to_chip_id(int cpu)
-{
- struct device_node *np;
-
- np = of_get_cpu_node(cpu, NULL);
- if (!np)
- return -1;
-
- of_node_put(np);
- return of_get_ibm_chip_id(np);
-}
-EXPORT_SYMBOL(cpu_to_chip_id);
-
/* Helper routines for cpu to core mapping */
int cpu_core_index_of_thread(int cpu)
{
diff --git a/arch/powerpc/platforms/powernv/rng.c b/arch/powerpc/platforms/powernv/rng.c
index 8844628..1cb160d 100644
--- a/arch/powerpc/platforms/powernv/rng.c
+++ b/arch/powerpc/platforms/powernv/rng.c
@@ -19,6 +19,7 @@
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/machdep.h>
+#include <asm/smp.h>
struct powernv_rng {
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] lib/crc32: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx.
From: Scott Wood @ 2013-11-19 23:43 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Christophe Leroy, Marcelo Tosatti, Bob Pearson, linuxppc-dev,
linux-kernel
In-Reply-To: <OFE596957E.9CEC5C97-ONC1257C28.00814EE8-C1257C28.0081FB80@transmode.se>
On Wed, 2013-11-20 at 00:39 +0100, Joakim Tjernlund wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2013/11/19 19:29:26:
> >
> > I don't think we should go littering the Kconfig with defaults for
> > various bits of hardware -- especially since you've already pointed out
> > non-8xx hardware that would also want this. Put it in defconfig
> > instead, unless you can identify very broad classes of machines for
> > which SLICEBY4 is faster.
>
> hmm, when 64bits went in there was not much proof that it was faster for
> a wide range of CPU, just 2 or 3 if I recall correctly. I suspect there
> are quite a few CPUs where 32 bits a equal or faster.
That may be the case, but I don't think we want a big list of them in
lib/Kconfig. Whether the default should change (for all targets that
don't override it in defconfig, or at least for some broader category
such as "all 32-bit chips") is a different discussion.
-Scott
^ permalink raw reply
* Re: [PATCH] lib/crc32: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx.
From: Joakim Tjernlund @ 2013-11-19 23:39 UTC (permalink / raw)
To: Scott Wood
Cc: Christophe Leroy, Marcelo Tosatti, Bob Pearson, linuxppc-dev,
linux-kernel
In-Reply-To: <1384885766.1403.366.camel@snotra.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 2013/11/19 19:29:26:
>=20
> I don't think we should go littering the Kconfig with defaults for
> various bits of hardware -- especially since you've already pointed out
> non-8xx hardware that would also want this. Put it in defconfig
> instead, unless you can identify very broad classes of machines for
> which SLICEBY4 is faster.
hmm, when 64bits went in there was not much proof that it was faster for
a wide range of CPU, just 2 or 3 if I recall correctly. I suspect there
are quite a few CPUs where 32 bits a equal or faster.
Jocke
>=20
> -Scott
>=20
> On Tue, 2013-11-19 at 15:11 +0100, Joakim Tjernlund wrote:
> > I found the same on MPC8321 long time ago(when 64 bits change went=20
in),=20
> > the 32 bits were much faster. I guess the "smaller"
> > CPUs cannot handle the cache trashing these big tables impose, I=20
didn't=20
> > look into the details though.
> > So I think this is a good change for 8xx.
> >=20
> > Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> >=20
> > Christophe Leroy <christophe.leroy@c-s.fr> wrote on 2013/11/18=20
08:04:23:
> >=20
> > > From: Christophe Leroy <christophe.leroy@c-s.fr>
> > > To: Vitaly Bordug <vitb@kernel.crashing.org>, Marcelo Tosatti=20
> > <marcelo@kvack.org>, Joakim Tjernlund <joakim.tjernlund@transmode.se>, =
Bob=20
> > Pearson <rpearson@systemfabricworks.com>,=20
> > > Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
> > > Date: 2013/11/19 13:05
> > > Subject: [PATCH] lib/crc32: slice by 4 is more efficient than the=20
> > default slice by 8 on Powerpc 8xx.
> > >=20
> > > On PPC=5F8xx, CRC32=5FSLICEBY4 is more efficient (almost twice) than =
> > CRC32=5FSLICEBY8,
> > > as shown below:
> > >=20
> > > With CRC32=5FSLICEBY8:
> > > [ 1.109204] crc32: CRC=5FLE=5FBITS =3D 64, CRC=5FBE BITS =3D 64
> > > [ 1.114401] crc32: self tests passed, processed 225944 bytes in=20
> > 15118910 nsec
> > > [ 1.130655] crc32c: CRC=5FLE=5FBITS =3D 64
> > > [ 1.134235] crc32c: self tests passed, processed 225944 bytes in=20
> > 4479879 nsec
> > >=20
> > > With CRC32=5FSLICEBY4:
> > > [ 1.097129] crc32: CRC=5FLE=5FBITS =3D 32, CRC=5FBE BITS =3D 32
> > > [ 1.101878] crc32: self tests passed, processed 225944 bytes in=20
> > 8616242 nsec
> > > [ 1.116298] crc32c: CRC=5FLE=5FBITS =3D 32
> > > [ 1.119607] crc32c: self tests passed, processed 225944 bytes in=20
> > 3289576 nsec
> > >=20
> > > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> > >=20
> > > Index: a/lib/Kconfig
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > --- a/lib/Kconfig (r=C3=A9vision 5325)
> > > +++ b/lib/Kconfig (copie de travail)
> > > @@ -102,6 +102,7 @@
> > > choice
> > > prompt "CRC32 implementation"
> > > depends on CRC32
> > > + default CRC32=5FSLICEBY4 if PPC=5F8xx
> > > default CRC32=5FSLICEBY8
> > > help
> > > This option allows a kernel builder to override the default=20
choice
> >=20
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >=20
> >=20
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Scott Wood @ 2013-11-19 22:51 UTC (permalink / raw)
To: Liu Gang; +Cc: linux-gpio, linus.walleij, linuxppc-dev, r61911, b07421
In-Reply-To: <1384499789-3631-1-git-send-email-Gang.Liu@freescale.com>
On Fri, 2013-11-15 at 15:16 +0800, Liu Gang wrote:
> For MPC8572/MPC8536, the status of GPIOs defined as output
> cannot be determined by reading GPDAT register, so the code
> use shadow data register instead. But if the input pins are
> asserted high, they will always read high due to the shadow
> data, even if the pins are set to low.
>
> So the input pins should be read directly from GPDAT, not
> the shadow data.
>
> Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
> ---
> drivers/gpio/gpio-mpc8xxx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 9ae29cc..1d4ac75 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
>
> val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR);
>
> return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> }
It seems odd to update ->data in a function that's supposed to be
reading things... Perhaps it would be better to keep ->data in a good
state from the beginning.
-Scott
^ permalink raw reply
* Re: [PATCH v5 01/17] powerpc/fsl-pci: improve clock API use
From: Scott Wood @ 2013-11-19 22:41 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Mike Turquette, Detlev Zundel, Minghuan Lian, Paul Mackerras,
Anatolij Gustschin, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384729577-7336-2-git-send-email-gsi@denx.de>
On Mon, 2013-11-18 at 00:06 +0100, Gerhard Sittig wrote:
> make the Freescale PCI driver get, prepare and enable the PCI clock
> during probe(); the clock gets put upon device shutdown by the devm
> approach
>
> clock lookup is non-fatal as not all platforms may provide clock specs
> in their device tree or implement a device tree based clock provider,
> but failure to enable clocks after successful lookup is fatal
>
> the driver appears to not have a remove() routine, so no reference to
> the clock is kept during use, and the clock isn't released (the devm
> approach will put the clock, but it won't get disabled or unprepared)
>
> the 85xx/86xx platforms go through the probe() routine, where clock
> lookup occurs and the clock gets acquired if one was specified; the
> 512x/83xx platforms don't pass through probe() but instead directly call
> the add_bridge() routine at a point in time where the clock provider has
> not been setup yet even if the platform implements one -- add comments
> to the code paths as a reminder for the potential need of a workaround
> in the platform's clock driver, and to keep awareness if code should get
> re-arranged or moved
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 52 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
Please coordinate this change with Minghuan Lian's patchset (posted Oct
23) to move the bulk of this driver outside of arch/powerpc.
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index ccfb50ddfe38..efa0916f61b6 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -17,6 +17,8 @@
> * Free Software Foundation; either version 2 of the License, or (at your
> * option) any later version.
> */
> +
> +#include <linux/clk.h>
> #include <linux/kernel.h>
> #include <linux/pci.h>
> #include <linux/delay.h>
> @@ -755,6 +757,32 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
> const int *bus_range;
> int primary;
>
> + /*
> + * 85xx/86xx platforms take the path through the probe() routine
> + * as one would expect, PCI related clocks get acquired there if
> + * specified
> + *
> + * 83xx/512x _don't_ pass through probe(), this add_bridge()
> + * routine instead is called from within .setup_arch() at a
> + * point in time where clock providers haven't been setup yet;
> + * so clocks cannot get acquired here -- lookup would always
> + * fail even on those platforms which implement the provider
> + *
> + * there is no counterpart for add_bridge() just like there is
> + * no remove() counterpart for probe(), so in either case the
> + * PCI related clock won't get released, and all of the
> + * 512x/83xx/85xx/86xx platforms behave in identical ways
How is it identical if 85xx/86xx will acquire a clock in probe(), but
83xx/512x can't acquire it in add_bridge()?
Could you explain the relevance of releasing clocks here?
> + *
> + * this comment is here to "keep the balance" against the
> + * probe() routine, and as a reminder to acquire clocks if the
> + * add_bridge() call should move to some later point in time
> + *
> + * until then clock providers are expected to work around the
> + * peripheral driver's not acquiring the PCI clock on those
> + * platforms where clock providers exist, while nothing needs to
> + * be done for those platforms without a clock provider
> + */
What would be involved in moving 83xx/512x to use .probe() as well?
> is_mpc83xx_pci = 1;
>
> if (!of_device_is_available(dev)) {
> @@ -1086,9 +1114,33 @@ void fsl_pci_assign_primary(void)
>
> static int fsl_pci_probe(struct platform_device *pdev)
> {
> + struct clk *clk;
> int ret;
> struct device_node *node;
>
> + /*
> + * clock lookup is non-fatal since the driver is shared among
> + * platforms and not all of them provide clocks specs in their
> + * device tree, but failure to enable a specified clock is
> + * considered fatal
> + *
> + * note that only the 85xx and 86xx platforms pass through this
> + * probe() routine, while 83xx and 512x directly invoke the
> + * mpc83xx_add_bridge() routine from within .setup_arch() code
> + */
> + clk = devm_clk_get(&pdev->dev, "ipg");
> + if (!IS_ERR(clk)) {
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Could not enable PCI clock\n");
> + return ret;
> + }
> + /*
> + * TODO where to store the 'clk' reference? there appears
> + * to be no remove() routine which undoes what probe() does
> + */
> + }
There is a .remove(); this driver just doesn't support it.
As for where to store things, you could turn private_data into a struct
rather than a direct iomem pointer. Or just replace the comment with a
non-TODO statement that says we'll never release the clock because the
PCI controller driver is non-removable.
-Scott
^ permalink raw reply
* Re: [PATCH v2] panic: Make panic_timeout configurable
From: Jason Baron @ 2013-11-19 22:04 UTC (permalink / raw)
To: Ingo Molnar, benh@kernel.crashing.org, paulus@samba.org,
Felipe Contreras
Cc: Andrew Morton, linuxppc-dev, linux-kernel@vger.kernel.org,
ralf@linux-mips.org
In-Reply-To: <20131119070905.GF32367@gmail.com>
On 11/19/2013 02:09 AM, Ingo Molnar wrote:
>
> * Jason Baron <jbaron@akamai.com> wrote:
>
>> On 11/18/2013 05:30 PM, Andrew Morton wrote:
>>> On Mon, 18 Nov 2013 21:04:36 +0000 (GMT) Jason Baron <jbaron@akamai.com> wrote:
>>>
>>>> The panic_timeout value can be set via the command line option 'panic=x', or via
>>>> /proc/sys/kernel/panic, however that is not sufficient when the panic occurs
>>>> before we are able to set up these values. Thus, add a CONFIG_PANIC_TIMEOUT
>>>> so that we can set the desired value from the .config.
>>>>
>>>> The default panic_timeout value continues to be 0 - wait forever,
>>>> except for powerpc and mips, which have been defaulted to 180 and
>>>> 5 respectively. This is in keeping with the fact that these
>>>> arches already set panic_timeout in their arch init code.
>>>> However, I found three exceptions- two in mips and one in powerpc
>>>> where the settings didn't match these default values. In those
>>>> cases, I left the arch code so it continues to override, in case
>>>> the user has not changed from the default. It would nice if these
>>>> arches had one default value, or if we could determine the
>>>> correct setting at compile-time.
>>>
>>> Felipe is proposing a simpler patch ("panic: setup panic_timeout
>>> early") which switches to early_param(). Is that sufficient for
>>> the (undescribed!) failure which you are presumably observing?
>>>
>>
>> No - that patch doesn't change the 'panic_timeout' value until the
>> call to 'parse_early_param()' is made. If there is a panic before
>> that point, the param doesn't do anything. The idea of this patch is
>> to allow it to be configured at build-time.
>>
>> I've tested the patch by simply inserting a panic() call at the
>> beginning of 'start_kernel()'. So, no I do not have a specific panic
>> in mind for this.
>
> Would you be interested in picking up Felipe's patch/fix on top of
> yours? I was unable to communicate with him efficiently, but I'd take
> the patch if it's signed off by you.
>
> Thanks,
>
> Ingo
>
Sure, I can round up all the related patches in this area that make
sense and re-submit as a series.
Felipe, would the CONFIG_PANIC_TIMEOUT=xx .config parameter work for your
needs, or would you still like to see the command-line processing moved
up?
I'd also like to hear from the PowerPC folks about the arch defaults
there. Now, that mips is ok with CONFIG_PANIC_TIMEOUT, PowerPC is the
only arch doing specific initialization of 'panic_timeout'.
Thanks,
-Jason
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: Anatolij Gustschin @ 2013-11-19 21:45 UTC (permalink / raw)
To: neorf3k; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <F24AEED4-A8F7-4DE8-A1BB-D0BED489A223@gmail.com>
Hi Lorenzo,
On Tue, 19 Nov 2013 11:20:24 +0100
neorf3k <neorf3k@gmail.com> wrote:
> Hello Anatolij, this is our code, used at University, but again it doesn=
=E2=80=99t work=E2=80=A6
>=20
> How i told, the only information we have about that reg are:
>=20
> Chip select 4 specification:
> Lp_cs4
> bus size: 8 bit
> bus control: 2 wait state R/W ACK disabled
> size allocated: 4 KByte
>=20
> Our Register 8 bit LP_cs4 (we want to write)
>=20
> cs4 offset: 0x001
is the byte in FPGA at offset 0x0 writable? In your code you
currently test read/write access to the byte at offset 0x0.
If the read/write access works under U-Boot, then maybe the
chip select parameters for CS4 are configured differently
in U-Boot. You can dump the Chip Select 4 configuration
registers under U-Boot and compare. Is address- and data-bus
to the FPGA multipexed? Another possible reason for non-working
access could be that the configured CS4 range 0x10020000 - 0x10030000
overlaps with configured range for CS0, CS1, CS2 or CS3. Can you
verify that no such overlapping exists.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] lib/crc32: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx.
From: Scott Wood @ 2013-11-19 18:29 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: Christophe Leroy, Marcelo Tosatti, Bob Pearson, linuxppc-dev,
linux-kernel
In-Reply-To: <OF5004EA63.AA9B7989-ONC1257C28.004D6C13-C1257C28.004DF922@transmode.se>
I don't think we should go littering the Kconfig with defaults for
various bits of hardware -- especially since you've already pointed out
non-8xx hardware that would also want this. Put it in defconfig
instead, unless you can identify very broad classes of machines for
which SLICEBY4 is faster.
-Scott
On Tue, 2013-11-19 at 15:11 +0100, Joakim Tjernlund wrote:
> I found the same on MPC8321 long time ago(when 64 bits change went in),=
=20
> the 32 bits were much faster. I guess the "smaller"
> CPUs cannot handle the cache trashing these big tables impose, I didn't=
=20
> look into the details though.
> So I think this is a good change for 8xx.
>=20
> Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
>=20
> Christophe Leroy <christophe.leroy@c-s.fr> wrote on 2013/11/18 08:04:23=
:
>=20
> > From: Christophe Leroy <christophe.leroy@c-s.fr>
> > To: Vitaly Bordug <vitb@kernel.crashing.org>, Marcelo Tosatti=20
> <marcelo@kvack.org>, Joakim Tjernlund <joakim.tjernlund@transmode.se>, =
Bob=20
> Pearson <rpearson@systemfabricworks.com>,=20
> > Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
> > Date: 2013/11/19 13:05
> > Subject: [PATCH] lib/crc32: slice by 4 is more efficient than the=20
> default slice by 8 on Powerpc 8xx.
> >=20
> > On PPC_8xx, CRC32_SLICEBY4 is more efficient (almost twice) than=20
> CRC32_SLICEBY8,
> > as shown below:
> >=20
> > With CRC32_SLICEBY8:
> > [ 1.109204] crc32: CRC_LE_BITS =3D 64, CRC_BE BITS =3D 64
> > [ 1.114401] crc32: self tests passed, processed 225944 bytes in=20
> 15118910 nsec
> > [ 1.130655] crc32c: CRC_LE_BITS =3D 64
> > [ 1.134235] crc32c: self tests passed, processed 225944 bytes in=20
> 4479879 nsec
> >=20
> > With CRC32_SLICEBY4:
> > [ 1.097129] crc32: CRC_LE_BITS =3D 32, CRC_BE BITS =3D 32
> > [ 1.101878] crc32: self tests passed, processed 225944 bytes in=20
> 8616242 nsec
> > [ 1.116298] crc32c: CRC_LE_BITS =3D 32
> > [ 1.119607] crc32c: self tests passed, processed 225944 bytes in=20
> 3289576 nsec
> >=20
> > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >=20
> > Index: a/lib/Kconfig
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- a/lib/Kconfig (r=C3=83=C2=A9vision 5325)
> > +++ b/lib/Kconfig (copie de travail)
> > @@ -102,6 +102,7 @@
> > choice
> > prompt "CRC32 implementation"
> > depends on CRC32
> > + default CRC32_SLICEBY4 if PPC_8xx
> > default CRC32_SLICEBY8
> > help
> > This option allows a kernel builder to override the default cho=
ice
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Anatolij Gustschin @ 2013-11-19 15:32 UTC (permalink / raw)
To: Liu Gang; +Cc: linux-gpio, linus.walleij, linuxppc-dev, r61911, b07421
In-Reply-To: <1384499789-3631-1-git-send-email-Gang.Liu@freescale.com>
On Fri, 15 Nov 2013 15:16:29 +0800
Liu Gang <Gang.Liu@freescale.com> wrote:
> For MPC8572/MPC8536, the status of GPIOs defined as output
> cannot be determined by reading GPDAT register, so the code
> use shadow data register instead. But if the input pins are
> asserted high, they will always read high due to the shadow
> data, even if the pins are set to low.
Could you please add a better description of the problem?
I'm having some difficulties to understand the last sentence
above. Does the issue appear if some pins were configured as
inputs and were asserted high before booting the kernel, and
therefore the shadow data has been initialized with these pin
values?
Or does the issue appear if some pin has been configured as output
first and has been set to the high value, then reconfigured as
input? Now reading the pin state will always return high even
if the actual pin state is low?
It seems the issue will appear in both cases. If so, please add
this information to the commit message.
> So the input pins should be read directly from GPDAT, not
> the shadow data.
>
> Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
> ---
> drivers/gpio/gpio-mpc8xxx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 9ae29cc..1d4ac75 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
>
> val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> + mpc8xxx_gc->data &= in_be32(mm->regs + GPIO_DIR);
we can reduce one in_be32() call here, i.e.
u32 out_mask;
...
out_mask = in_be32(mm->regs + GPIO_DIR);
val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
mpc8xxx_gc->data &= out_mask;
> return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> }
Thanks,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH] lib/crc32: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx.
From: Joakim Tjernlund @ 2013-11-19 14:11 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Marcelo Tosatti, Bob Pearson, linuxppc-dev, linux-kernel
In-Reply-To: <20131118070423.E47181A4D3D@localhost.localdomain>
I found the same on MPC8321 long time ago(when 64 bits change went in),=20
the 32 bits were much faster. I guess the "smaller"
CPUs cannot handle the cache trashing these big tables impose, I didn't=20
look into the details though.
So I think this is a good change for 8xx.
Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
Christophe Leroy <christophe.leroy@c-s.fr> wrote on 2013/11/18 08:04:23:
> From: Christophe Leroy <christophe.leroy@c-s.fr>
> To: Vitaly Bordug <vitb@kernel.crashing.org>, Marcelo Tosatti=20
<marcelo@kvack.org>, Joakim Tjernlund <joakim.tjernlund@transmode.se>, Bob =
Pearson <rpearson@systemfabricworks.com>,=20
> Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
> Date: 2013/11/19 13:05
> Subject: [PATCH] lib/crc32: slice by 4 is more efficient than the=20
default slice by 8 on Powerpc 8xx.
>=20
> On PPC=5F8xx, CRC32=5FSLICEBY4 is more efficient (almost twice) than=20
CRC32=5FSLICEBY8,
> as shown below:
>=20
> With CRC32=5FSLICEBY8:
> [ 1.109204] crc32: CRC=5FLE=5FBITS =3D 64, CRC=5FBE BITS =3D 64
> [ 1.114401] crc32: self tests passed, processed 225944 bytes in=20
15118910 nsec
> [ 1.130655] crc32c: CRC=5FLE=5FBITS =3D 64
> [ 1.134235] crc32c: self tests passed, processed 225944 bytes in=20
4479879 nsec
>=20
> With CRC32=5FSLICEBY4:
> [ 1.097129] crc32: CRC=5FLE=5FBITS =3D 32, CRC=5FBE BITS =3D 32
> [ 1.101878] crc32: self tests passed, processed 225944 bytes in=20
8616242 nsec
> [ 1.116298] crc32c: CRC=5FLE=5FBITS =3D 32
> [ 1.119607] crc32c: self tests passed, processed 225944 bytes in=20
3289576 nsec
>=20
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>=20
> Index: a/lib/Kconfig
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- a/lib/Kconfig (r=C3=A9vision 5325)
> +++ b/lib/Kconfig (copie de travail)
> @@ -102,6 +102,7 @@
> choice
> prompt "CRC32 implementation"
> depends on CRC32
> + default CRC32=5FSLICEBY4 if PPC=5F8xx
> default CRC32=5FSLICEBY8
> help
> This option allows a kernel builder to override the default choice
^ 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