Re: [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts
On Wed, Oct 09, 2013 at 10:16:32AM +0530, Anshuman Khandual wrote: On 10/09/2013 06:51 AM, Michael Ellerman wrote: On Tue, Oct 08, 2013 at 12:51:18PM +0530, Anshuman Khandual wrote: On 10/08/2013 09:51 AM, Michael Ellerman wrote: On Mon, Oct 07, 2013 at 10:00:26AM +0530, Anshuman Khandual wrote: Right now the `config_bhrb` PMU specific call happens after write_mmcr0 which actually enables the PMU for event counting and interrupt. So there is a small window of time where the PMU and BHRB runs without the required HW branch filter (if any) enabled in BHRB. This can cause some of the branch samples to be collected through BHRB without any filter being applied and hence affecting the correctness of the results. This patch moves the BHRB config function call before enabling the interrupts. Patch looks good. But it reminds me I have an item in my TODO list: - Why can't config_bhrb() be done in compute_mmcr() ? compute_mmcr() function deals with generic MMCR* configs for normal PMU events. Even if BHRB config touches MMCRA register, it's configuration does not interfere with the PMU config for general events. So its best to keep them separate. I'm unconvinced. If they'd been together to begin with this bug never would have happened. This is an ordering of configuration problem. Putting them together in the same function does not rule out the chances of this ordering problem. Could you please kindly explain how this could have been avoided ? The existing code already makes sure to write MMCRA before MMCR0. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: Add a debugfs file to read the firmware console
On Wed, Oct 09, 2013 at 03:23:21PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-09 at 14:23 +1100, Michael Ellerman wrote:
On Tue, Oct 08, 2013 at 06:46:40PM +1100, Benjamin Herrenschmidt wrote:
With OPALv3, the firmware can provide the address of it's internal console
to Linux, which we can then display using debugfs. This is handy for
diagnostics and debugging.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 2911abe..10d7894 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -17,6 +17,8 @@
#include linux/interrupt.h
#include linux/notifier.h
#include linux/slab.h
+#include linux/debugfs.h
+#include linux/uaccess.h
#include asm/opal.h
#include asm/firmware.h
@@ -27,6 +29,21 @@ struct opal {
u64 entry;
} opal;
+/* OPAL in-memory console */
It might be nice to point out that the format of the struct is defined
by OPAL and must be in sync with what OPAL is using.
Yes, we could move the structure definition to opal.h...
+struct memcons {
+ uint64_t magic;
u64 ?
Who cares ?
That's what we use in the kernel. But no I don't care.
+#define MEMCONS_MAGIC0x6630696567726173
+ uint64_t obuf_phys;
+ uint64_t ibuf_phys;
+ uint32_t obuf_size;
+ uint32_t ibuf_size;
+ uint32_t out_pos;
+#define MEMCONS_OUT_POS_WRAP 0x8000u
+#define MEMCONS_OUT_POS_MASK 0x00ffu
Where does this come from?
My a** :-) I made it up as I wrote the OPAL side one, why ?
...
+ uint32_t in_prod;
+ uint32_t in_cons;
+};
Should it be packed?
Nope, no need. It's all nice and naturally aligned.
Sure, that's obvious.
@@ -369,6 +386,90 @@ static irqreturn_t opal_interrupt(int irq, void
*data)
return IRQ_HANDLED;
}
+#ifdef CONFIG_DEBUG_FS
+static ssize_t opal_memcons_read(struct file *file, char __user *to,
+ size_t count, loff_t *ppos)
+{
+ struct memcons *mc = file-private_data;
+ size_t available, ret, chunk0, chunk1, lcount;
+ const char *start, *conbuf = __va(mc-obuf_phys);
+ loff_t opos, pos;
+
+ /*
+ * Find out how much is in the buffer. If it has wrapped
+ * the whole buffer, else just the beginning. It has wrapped
+ * if the next character is not \0
+ */
+ if (mc-out_pos MEMCONS_OUT_POS_WRAP) {
+ available = mc-obuf_size;
+ chunk1 = mc-out_pos MEMCONS_OUT_POS_MASK;
+ start = conbuf + chunk1;
+ chunk0 = mc-obuf_size - chunk1;
+ } else {
+ available = mc-out_pos;
+ start = conbuf;
+ chunk0 = available;
+ chunk1 = 0;
+ }
Surely simple_read_from_buffer() could make some of this simpler?
If you can find a way to make it deal with a ring buffer...
Call it twice.
And you wonder why no one reviews your patches?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Tang Yuantian yuantian.t...@freescale.com
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
v5:
- refine the binding document
- update the compatible string
v4:
- add binding document
- update compatible string
- update the reg property
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
.../devicetree/bindings/clock/corenet-clock.txt| 111
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi| 35 +++
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 35 +++
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 60 +++
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 60 +++
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 112 +
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 ++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 42
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 60 +++
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 85
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +++
17 files changed, 640 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 000..8efc62d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,111 @@
+* Clock Block on Freescale CoreNet Platforms
+
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+which can then be passed to a variety of internal logic, including
+cores and peripheral IP blocks.
+Please refer to the Reference Manual for details.
+
+1. Clock Block Binding
+
+Required properties:
+- compatible: Should include one or more of the following:
+ - fsl,chip-clockgen: for chip specific clock block
+ - fsl,qoriq-clockgen-[1,2].x: for chassis 1.x and 2.x clock
+- reg: Offset and length of the clock register set
+- clock-frequency: Indicates input clock frequency of clock block.
+ Will be set by u-boot
+
+Recommended properties:
+- #ddress-cells: Specifies the number of cells used to represent
+ physical base addresses. Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
+
+2. Clock Provider/Consumer Binding
+
+Most of the binding are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Should include one or more of the following:
+ - fsl,qoriq-core-pll-[1,2].x: Indicates a core PLL clock device
+ - fsl,qoriq-core-mux-[1,2].x: Indicates a core multiplexer clock
+ device; divided from the core PLL clock
+ - fixed-clock: From common clock binding; indicates output clock
+ of oscillator
+ - fsl,qoriq-sysclk-[1,2].x: Indicates input system clock
+- #clock-cells: From common clock binding; indicates the number of
+ output clock. 0 is for one output clock; 1 for more than one clock
+
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
+- clock-output-names: From common clock binding, indicates the names of
+ output clocks
+- reg: Should be the offset and length of clock block base address.
+ The length should be 4.
+
+Example for clock block and clock provider:
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
+ reg = 0xe1000 0x1000;
+ clock-frequency = 0;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ sysclk: sysclk {
+ #clock-cells = 0;
+ compatible = fsl,qoriq-sysclk-1.0, fixed-clock;
+ clock-output-names = sysclk;
+ }
+
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800
Re: [PATCH] powerpc/powernv: Add a debugfs file to read the firmware console
On Wed, 2013-10-09 at 17:06 +1100, Michael Ellerman wrote: Call it twice. And you wonder why no one reviews your patches? Not that easy :-) I had a look at using it and unless I did something stupid, it wasn't actually that trivial to figure out what arg to pass it for calling it twice, ie, it didn't simplify the code significantly ... I had another problem too but I don't remember what it was. But it could be that I had a very dumb moment... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [E1000-devel] [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
On Tue, 2013-10-08 at 07:10 +1100, Benjamin Herrenschmidt wrote: On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote: I don't think the same race condition would happen with the loop. The problem case is where multiple msi(x) allocation fails completely because the global limit went down before inquiry and allocation. In the loop based interface, it'd retry with the lower number. As long as the number of drivers which need this sort of adaptive allocation isn't too high and the common cases can be made simple, I don't think the complex part of interface is all that important. Maybe we can have reserve / cancel type interface or just keep the loop with more explicit function names (ie. try_enable or something like that). We want to be able to request an MSI-X at runtime anyway ... if I want to dynamically add a queue to my network interface, I want it to be able to pop a new arbitrary MSI-X. If you want to dynamically allocate another queue, you'd either need to have them all pre-allocated at alloc_etherdev_mqs(), or add a new API to netdev that allows adding new queues on the fly. How things are done today, the Tx queues are all tacked onto the end of the netdev struct. That would have to change to probably a linked list of queues that could be grown or shrunk on the fly. netif_alloc_netdev_queues() would need to change the kzalloc() to a list allocation. Cheers, -PJ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement code
-Original Message- From: Alexander Gordeev [mailto:agord...@redhat.com] Sent: Wednesday, October 02, 2013 3:49 AM To: linux-kernel Cc: Alexander Gordeev; Bjorn Helgaas; Ralf Baechle; Michael Ellerman; Benjamin Herrenschmidt; Martin Schwidefsky; Ingo Molnar; Tejun Heo; Dan Williams; Andy King; Jon Mason; Matt Porter; linux-pci; linux-mips@linux- mips.org; linuxppc-dev@lists.ozlabs.org; linux...@de.ibm.com; linux- s...@vger.kernel.org; x...@kernel.org; linux-...@vger.kernel.org; iss_storage...@hp.com; linux-n...@lists.infradead.org; linux- r...@vger.kernel.org; netdev; e1000-de...@lists.sourceforge.net; Dept- Eng Linux Driver; Solarflare linux maintainers; VMware, Inc.; linux-scsi Subject: [PATCH RFC 63/77] qlcnic: Update MSI/MSI-X interrupts enablement code 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. We will test this change for the driver and provide feedback. Signed-off-by: Alexander Gordeev agord...@redhat.com Thanks, Himanshu ___ 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 Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote: Hmmm... yean, the race condition could be an issue as multiple msi allocation might fail even if the driver can and explicitly handle multiple allocation if the quota gets reduced inbetween. BTW, should we care about the quota getting increased inbetween? That would entail.. kind of pci_get_msi_limit() :), but IMHO it is not worth it. tejun -- Regards, Alexander Gordeev agord...@redhat.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v2] pci: fsl: derive the common PCI driver to drivers/pci/host
On Wed, Oct 9, 2013 at 4:14 AM, Lian Minghuan-b31939 b31...@freescale.com wrote: arch/powerpc/sysdev/fsl_pci.c | 521 +- arch/powerpc/sysdev/fsl_pci.h | 89 .../fsl_pci.c = drivers/pci/host/pci-fsl-common.c | 591 + .../fsl_pci.h = include/linux/fsl/pci-common.h| 45 +- Is there any way to avoid putting this file in include/linux? I know you want to share it beyond PowerPC, and I know there are similar examples there already, but this is all arch-specific or chipset-specific stuff that seems like it should be in some not-so-public place. It doesn't seem scalable to add an include/linux subdirectory for every chipset that might be shared across architectures. [Minghuan] I can move pci-common.h to drivers/pci/host/ But in arch/powerpc/sysdev/fsl_pci.c I must include the header file like this: #include ../../../drivers/pci/host/pci-fsl-common.h. How about this modification? Given the existence of include/linux/fsl/ even before this patch, I'm OK with it as-is. After you work through Scott's comments on [2/2] and get his ack, I'll merge the whole bundle as a group. Bjorn ___ 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
Hello, On Tue, Oct 08, 2013 at 02:22:16PM +0200, Alexander Gordeev wrote: If we talk about pSeries quota, then the current pSeries pci_enable_msix() implementation is racy internally and could fail if the quota went down *while* pci_enable_msix() is executing. In this case the loop will have to exit rather than retry with a lower number (what number?). Ah, okay, so that one is already broken. In this regard the new scheme does not bring anything new and relies on the fact this race does not hit and therefore does not worry. If we talk about quota as it has to be, then yes - the loop scheme seems more preferable. Overall, looks like we just need to fix the pSeries implementation, if the guys want it, he-he :) If we can't figure out a better interface for the retry case, I think what can really help is having a simple interface for the simpler cases. The problem case is where multiple msi(x) allocation fails completely because the global limit went down before inquiry and allocation. In the loop based interface, it'd retry with the lower number. I am probably missing something here. If the global limit went down before inquiry then the inquiry will get what is available and try to allocate with than number. Oh, I should have written between inquiry and allocation. Sorry. Thanks. -- tejun ___ 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
Hello, On Wed, Oct 09, 2013 at 02:57:16PM +0200, Alexander Gordeev wrote: On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote: Hmmm... yean, the race condition could be an issue as multiple msi allocation might fail even if the driver can and explicitly handle multiple allocation if the quota gets reduced inbetween. BTW, should we care about the quota getting increased inbetween? That would entail.. kind of pci_get_msi_limit() :), but IMHO it is not worth it. I think we shouldn't. If the resource was low during a point in time during allocation, it's fine to base the result on that - the resource was actually low and which answer we return is just a question of timing and both are correct. The only reason the existing race condition is problematic is because it may fail even if the resource never falls below the failure point. Thanks. -- tejun ___ 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 Mon, Oct 07, 2013 at 09:48:01PM +0100, Ben Hutchings wrote: There is one major flaw in min-max approach - the generic MSI layer will have to take decisions on exact number of MSIs to request, not device drivers. [... No, the min-max functions should be implemented using the same loop that drivers are expected to use now. Wheee... earlier in the thread I thought you guys were referring to yourselves in the third person and was getting a bit worried. :) -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern
Hello, Alexander. On Tue, Oct 08, 2013 at 09:48:26AM +0200, Alexander Gordeev wrote: If there are many which duplicate the above pattern, it'd probably be worthwhile to provide a helper? It's usually a good idea to reduce the amount of boilerplate code in drivers. I wanted to limit discussion in v1 to as little changes as possible. I 'planned' those helper(s) for a separate effort if/when the most important change is accepted and soaked a bit. The thing is doing it this way generates more churns and noises. Once the simpler ones live behind a wrapper which can be built on the existing interface, we can have both reduced cost and more latitude on the complex cases. If we do things this way, it breaks all drivers using this interface until they're converted, right? Right. And the rest of the series does it. Which breaks bisection which we shouldn't do. Also, it probably isn't the best idea to flip the behavior like this as this can go completely unnoticed (no compiler warning or anything, the same function just behaves differently). Maybe it'd be a better idea to introduce a simpler interface that most can be converted to? Well, an *other* interface is a good idea. What do you mean with the simpler here? I'm still talking about a simpler wrapper for common cases, which is the important part anyway. Thanks. -- tejun ___ 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
Hello, On Tue, Oct 08, 2013 at 11:07:16AM +0200, Alexander Gordeev wrote: Multipe MSIs is just a handful of drivers, really. MSI-X impact still Yes, so it's pretty nice to try out things there before going full-on. will be huge. But if we opt a different name for the new pci_enable_msix() then we could first update pci/msi, then drivers (in few stages possibly) and finally remove the old implementation. Yes, that probably should be the steps to follow eventually. My point was that you don't have to submit patches for all 7x conversions for an RFC round. Scanning them and seeing what would be necessary definitely is a good idea but just giving summary of the full conversion with several examples should be good enough before settling on the way forward, which should be easier for all involved. Thanks a lot for your effort! -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
A002 is still in no plans to fix state, and applies to all the current P1/P2 parts as well, so it's resonable to enable its workaround by default, for all the soc's with etsec. The impact of not enabling this workaround for affected parts is that under certain conditons (runt frames or even frames with RX error detected at PHY level) during controller reset, the controller might fail to indicate Rx reset (GRS) completion. Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com --- drivers/net/ethernet/freescale/gianfar.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c index c4eaade..db5fc7b 100644 --- a/drivers/net/ethernet/freescale/gianfar.c +++ b/drivers/net/ethernet/freescale/gianfar.c @@ -947,6 +947,9 @@ static void gfar_detect_errata(struct gfar_private *priv) unsigned int mod = (svr 16) 0xfff6; /* w/o E suffix */ unsigned int rev = svr 0x; + /* no plans to fix */ + priv-errata |= GFAR_ERRATA_A002; + /* MPC8313 Rev 2.0 and higher; All MPC837x */ if ((pvr == 0x80850010 mod == 0x80b0 rev = 0x0020) || (pvr == 0x80861010 (mod 0xfff9) == 0x80c0)) @@ -957,11 +960,6 @@ static void gfar_detect_errata(struct gfar_private *priv) (pvr == 0x80861010 (mod 0xfff9) == 0x80c0)) priv-errata |= GFAR_ERRATA_76; - /* MPC8313 and MPC837x all rev */ - if ((pvr == 0x80850010 mod == 0x80b0) || - (pvr == 0x80861010 (mod 0xfff9) == 0x80c0)) - priv-errata |= GFAR_ERRATA_A002; - /* MPC8313 Rev 2.0, MPC8548 rev 2.0 */ if ((pvr == 0x80850010 mod == 0x80b0 rev 0x0020) || (pvr == 0x80210020 mod == 0x8030 rev == 0x0020)) @@ -1599,7 +1597,7 @@ static int __gfar_is_rx_idle(struct gfar_private *priv) /* Normaly TSEC should not hang on GRS commands, so we should * actually wait for IEVENT_GRSC flag. */ - if (likely(!gfar_has_errata(priv, GFAR_ERRATA_A002))) + if (!gfar_has_errata(priv, GFAR_ERRATA_A002)) return 0; /* Read the eTSEC register at offset 0xD1C. If bits 7-14 are -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] gianfar: Use mpc85xx support for errata detection
Use the macros and defines from mpc85xx.h to simplify
and prevent errors in identifying a mpc85xx based SoC
for errata detection.
This should help enabling (and identifying) workarounds
for various mpc85xx based chips and revisions.
For instance, express MPC8548 Rev.2 as:
(SVR_SOC_VER(svr) == SVR_8548) (SVR_REV(svr) == 0x20)
instead of:
(pvr == 0x80210020 mod == 0x8030 rev == 0x0020)
Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com
---
drivers/net/ethernet/freescale/gianfar.c | 33
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index db5fc7b..329a206 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -88,6 +88,7 @@
#include asm/io.h
#include asm/reg.h
+#include asm/mpc85xx.h
#include asm/irq.h
#include asm/uaccess.h
#include linux/module.h
@@ -939,17 +940,13 @@ static void gfar_init_filer_table(struct gfar_private
*priv)
}
}
-static void gfar_detect_errata(struct gfar_private *priv)
+static void __gfar_detect_errata_83xx(struct gfar_private *priv)
{
- struct device *dev = priv-ofdev-dev;
unsigned int pvr = mfspr(SPRN_PVR);
unsigned int svr = mfspr(SPRN_SVR);
unsigned int mod = (svr 16) 0xfff6; /* w/o E suffix */
unsigned int rev = svr 0x;
- /* no plans to fix */
- priv-errata |= GFAR_ERRATA_A002;
-
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr == 0x80850010 mod == 0x80b0 rev = 0x0020) ||
(pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
@@ -960,10 +957,30 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
priv-errata |= GFAR_ERRATA_76;
- /* MPC8313 Rev 2.0, MPC8548 rev 2.0 */
- if ((pvr == 0x80850010 mod == 0x80b0 rev 0x0020) ||
- (pvr == 0x80210020 mod == 0x8030 rev == 0x0020))
+ /* MPC8313 Rev 2.0 */
+ if (pvr == 0x80850010 mod == 0x80b0 rev 0x0020)
+ priv-errata |= GFAR_ERRATA_12;
+}
+
+static void __gfar_detect_errata_85xx(struct gfar_private *priv)
+{
+ unsigned int svr = mfspr(SPRN_SVR);
+
+ if ((SVR_SOC_VER(svr) == SVR_8548) (SVR_REV(svr) == 0x20))
priv-errata |= GFAR_ERRATA_12;
+}
+
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = priv-ofdev-dev;
+
+ /* no plans to fix */
+ priv-errata |= GFAR_ERRATA_A002;
+
+ if (pvr_version_is(PVR_VER_E500V1) || pvr_version_is(PVR_VER_E500V2))
+ __gfar_detect_errata_85xx(priv);
+ else /* non-mpc85xx parts, i.e. e300 core based */
+ __gfar_detect_errata_83xx(priv);
if (priv-errata)
dev_info(dev, enabled errata workarounds, flags: 0x%x\n,
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
Enable workaround for P2020/P2010 erratum eTSEC 20, Excess delays when transmitting TOE=1 large frames. The impact is that frames lager than 2500-bytes for which TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled may see excess delay before start of transmission. This erratum was fixed in Rev 2.0. Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com --- drivers/net/ethernet/freescale/gianfar.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c index 329a206..9fbe4dd 100644 --- a/drivers/net/ethernet/freescale/gianfar.c +++ b/drivers/net/ethernet/freescale/gianfar.c @@ -968,6 +968,9 @@ static void __gfar_detect_errata_85xx(struct gfar_private *priv) if ((SVR_SOC_VER(svr) == SVR_8548) (SVR_REV(svr) == 0x20)) priv-errata |= GFAR_ERRATA_12; + if (((SVR_SOC_VER(svr) == SVR_P2020) (SVR_REV(svr) 0x20)) || + ((SVR_SOC_VER(svr) == SVR_P2010) (SVR_REV(svr) 0x20))) + priv-errata |= GFAR_ERRATA_76; /* aka eTSEC 20 */ } static void gfar_detect_errata(struct gfar_private *priv) -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
From: Claudiu Manoil claudiu.man...@freescale.com Date: Wed, 9 Oct 2013 20:20:40 +0300 A002 is still in no plans to fix state, and applies to all the current P1/P2 parts as well, so it's resonable to enable its workaround by default, for all the soc's with etsec. The impact of not enabling this workaround for affected parts is that under certain conditons (runt frames or even frames with RX error detected at PHY level) during controller reset, the controller might fail to indicate Rx reset (GRS) completion. Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
From: Claudiu Manoil claudiu.man...@freescale.com Date: Wed, 9 Oct 2013 20:20:42 +0300 Enable workaround for P2020/P2010 erratum eTSEC 20, Excess delays when transmitting TOE=1 large frames. The impact is that frames lager than 2500-bytes for which TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled may see excess delay before start of transmission. This erratum was fixed in Rev 2.0. Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
From: Claudiu Manoil claudiu.man...@freescale.com Date: Wed, 9 Oct 2013 20:20:41 +0300 Use the macros and defines from mpc85xx.h to simplify and prevent errors in identifying a mpc85xx based SoC for errata detection. This should help enabling (and identifying) workarounds for various mpc85xx based chips and revisions. For instance, express MPC8548 Rev.2 as: (SVR_SOC_VER(svr) == SVR_8548) (SVR_REV(svr) == 0x20) instead of: (pvr == 0x80210020 mod == 0x8030 rev == 0x0020) Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v1] powerpc/mpc512x: silence build warning upon disabled DIU
Hi all,
(Please keep me on the CC list, as I'm not subscribed)
On Fri, Sep 27, 2013 at 05:28:38PM +0200, Gerhard Sittig wrote:
a disabled Kconfig option results in a reference to a not implemented
routine when the IS_ENABLED() macro is used for both conditional
implementation of the routine as well as a C language source code test
at the call site -- the if (0) func(); construct only gets eliminated
later by the optimizer, while the compiler already has emitted its
warning about func() being undeclared
provide an empty implementation for the mpc512x_setup_diu() and
mpc512x_init_diu() routines in case of the disabled option, to avoid the
compiler warning which is considered fatal and breaks compilation
the bug appeared with commit 2a63c90ab55ca3f054772c2e5ba7df810c48
powerpc/mpc512x: move common code to shared.c file, how to reproduce:
make mpc512x_defconfig
echo CONFIG_FB_FSL_DIU=n .config make olddefconfig
make
CC arch/powerpc/platforms/512x/mpc512x_shared.o
.../arch/powerpc/platforms/512x/mpc512x_shared.c: In function
'mpc512x_init_early':
.../arch/powerpc/platforms/512x/mpc512x_shared.c:456:3: error: implicit
declaration of function 'mpc512x_init_diu'
[-Werror=implicit-function-declaration]
.../arch/powerpc/platforms/512x/mpc512x_shared.c: In function
'mpc512x_setup_arch':
.../arch/powerpc/platforms/512x/mpc512x_shared.c:469:3: error: implicit
declaration of function 'mpc512x_setup_diu'
[-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[4]: *** [arch/powerpc/platforms/512x/mpc512x_shared.o] Error 1
I just ran across this same compile issue, and I have a few thoughts
below.
Signed-off-by: Gerhard Sittig g...@denx.de
CC: sta...@vger.kernel.org # v3.11
---
arch/powerpc/platforms/512x/mpc512x_shared.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index a82a41b..1a7b1d0 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -303,6 +303,9 @@ void __init mpc512x_setup_diu(void)
diu_ops.release_bootmem = mpc512x_release_bootmem;
}
+#else
+void __init mpc512x_setup_diu(void) { /* EMPTY */ }
+void __init mpc512x_init_diu(void) { /* EMPTY */ }
#endif
void __init mpc512x_init_IRQ(void)
I see an alternative solution:
Can't almost all of the code in mpc512x_shared.c be declared 'static'?
Then, you can get the real benefit of IS_ENABLED() by removing the
#if IS_ENABLED(CONFIG_FB_FSL_DIU)
from around all the DIU code, and it will automatically be removed by
the compiler when it is not used.
I think the current patch is necessary for immediate use, and it can be
sent to stable. But I might suggest a follow-up patch or 2 that makes
the functions static and kills the #ifdef entirely.
Thanks,
Brian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
On Wed, 2013-10-09 at 20:20 +0300, Claudiu Manoil wrote:
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = priv-ofdev-dev;
+
+ /* no plans to fix */
+ priv-errata |= GFAR_ERRATA_A002;
+
+ if (pvr_version_is(PVR_VER_E500V1) || pvr_version_is(PVR_VER_E500V2))
+ __gfar_detect_errata_85xx(priv);
+ else /* non-mpc85xx parts, i.e. e300 core based */
+ __gfar_detect_errata_83xx(priv);
It would be better to use CONFIG_E500 here (note that we do not support
building e500 and 83xx/86xx in the same kernel), on the off chance that
we put a gianfar in a chip with a newer e500 derivative. I suppose it's
harmless as long as the 83xx version checks the full PVR, until such a
chip exists and has an erratum workaround (other than A002) added for
it.
What about 86xx? Are there any gianfar errata there besides A002?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 0/6] perf: New conditional branch filter
On 09/26/2013 04:44 PM, Stephane Eranian wrote: So you are saying that the HW filter is exclusive. That seems odd. But I think it is because of the choices is ANY. ANY covers all the types of branches. Therefore it does not make a difference whether you add COND or not. And vice-versa, if you set COND, you need to disable ANY. I bet if you add other filters such as CALL, RETURN, then you could OR them and say: I want RETURN or CALLS. But that's okay. The API operates in OR mode but if the HW does not support it, you can check the mask and reject if more than one type is set. That is arch-specific code. The alternative, if to only capture ANY and emulate the filter in SW. This will work, of course. But the downside, is that you lose the way to appreciate how many, for instance, COND branches you sampled out of the total number of COND branches retired. Unless you can count COND branches separately. Hey Stephane, Thanks for your reply. I am working on a solution where PMU will process all the requested branch filters in HW only if it can filter all of them in an OR manner else it will just leave the entire thing upto the SW to process and do no filtering itself. This implies that branch filtering will either happen completely in HW or completely in SW and never in a mixed manner. This way it will conform to the OR mode defined in the API. I will post the revised patch set soon. Regards Anshuman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
