* Re: [PATCH 1/7] powerpc: Add interface to get msi region information
From: Scott Wood @ 2013-10-08 17:09 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: agraf@suse.de, Wood Scott-B07421, joro@8bytes.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, alex.williamson@redhat.com,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAErSpo742BOxzxRaFQn+UnsNday4_8LM6+3G6=cfp9DHecPxDg@mail.gmail.com>
On Tue, 2013-10-08 at 10:47 -0600, Bjorn Helgaas wrote:
> On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777
> <R65777@freescale.com> wrote:
>
> >> I don't know enough about VFIO to understand why these new interfaces are
> >> needed. Is this the first VFIO IOMMU driver? I see vfio_iommu_spapr_tce.c and
> >> vfio_iommu_type1.c but I don't know if they're comparable to the Freescale PAMU.
> >> Do other VFIO IOMMU implementations support MSI? If so, do they handle the
> >> problem of mapping the MSI regions in a different way?
> >
> > PAMU is an aperture type of IOMMU while other are paging type, So they are completely different from what PAMU is and handle that differently.
>
> This is not an explanation or a justification for adding new
> interfaces. I still have no idea what an "aperture type IOMMU" is,
> other than that it is "different." But I see that Alex is working on
> this issue with you in a different thread, so I'm sure you guys will
> sort it out.
PAMU is a very constrained IOMMU that cannot do arbitrary page mappings.
Due to these constraints, we cannot map the MSI I/O page at its normal
address while also mapping RAM at the address we want. The address we
can map it at depends on the addresses of other mappings, so it can't be
hidden in the IOMMU driver -- the user needs to be in control.
Another difference is that (if I understand correctly) PCs handle MSIs
specially, via interrupt remapping, rather than being translated as a
normal memory access through the IOMMU.
-Scott
^ permalink raw reply
* Re: [PATCH 1/7] powerpc: Add interface to get msi region information
From: Bjorn Helgaas @ 2013-10-08 16:47 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: agraf@suse.de, Wood Scott-B07421, joro@8bytes.org,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
alex.williamson@redhat.com, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0718FA58@039-SN2MPN1-011.039d.mgd.msft.net>
On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777
<R65777@freescale.com> wrote:
>> I don't know enough about VFIO to understand why these new interfaces are
>> needed. Is this the first VFIO IOMMU driver? I see vfio_iommu_spapr_tce.c and
>> vfio_iommu_type1.c but I don't know if they're comparable to the Freescale PAMU.
>> Do other VFIO IOMMU implementations support MSI? If so, do they handle the
>> problem of mapping the MSI regions in a different way?
>
> PAMU is an aperture type of IOMMU while other are paging type, So they are completely different from what PAMU is and handle that differently.
This is not an explanation or a justification for adding new
interfaces. I still have no idea what an "aperture type IOMMU" is,
other than that it is "different." But I see that Alex is working on
this issue with you in a different thread, so I'm sure you guys will
sort it out.
Bjorn
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-10-08 14:50 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F1543925901094898@039-SN2MPN1-021.039d.mgd.msft.net>
On Mon, 2013-10-07 at 22:58 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 01, 2013 7:06 AM
> > To: Wang Dongsheng-B40534
> > Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> > dev@lists.ozlabs.org
> > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> > On Sun, 2013-09-29 at 01:57 -0500, Wang Dongsheng-B40534 wrote:
> > > I think we need to do this:
> > >
> > > #define U64_LOW_MASK 0xffffffffULL
> > > #define U64_MASK 0xffffffffffffffffULL
> > >
> > > u32 tmp_rem;
> > > u64 ns_u_rem, ns_u, ns_l, ns_l_carry;
> > > u64 cycle;
> > >
> > > ns_u = ns >> 32;
> > > ns_l = ns & U64_LOW_MASK;
> > >
> > > ns_l *= tb_ticks_per_usec;
> > > ns_l_carry = ns_l >> 32;
> > > ns_u *= tb_ticks_per_usec;
> > > ns_u += ns_l_carry;
> > >
> > > ns_u = div_u64_rem(ns_u, 1000, &tmp_rem);
> > > ns_u_rem = tmp_rem;
> > > ns_l = (ns_l & U64_LOW_MASK) | ((ns_u_rem) << 32);
> > > ns_l = div_u64(ns_l, 1000);
> > >
> > > if (ns_u >> 32)
> > > cycle = U64_MASK;
> > > else
> > > cycle = (ns_u << 32) | (ns_l & U64_LOW_MASK);
> > >
> > > I has already tested this code, and works good. :)
> >
> > Ugh. I don't think we need to get this complicated (and I'd rather not
> > spend the time verifying the correctness of this).
> >
> > If for some reason we did need something like this in some other context
> > (I don't want to see it just for pw20), I'd be more inclined to see
> > general 128-bit mult/divide support.
> >
> I would like to use my version,:), because it can handle any situation and we do not need to restrict users.
It also would take more time to review than I have to spend on it, not
to mention the impact on anyone in the future that wants to understand
or maintain this code -- all for very unlikely situations (and the
"failure" in those very unlikely situations is just that we go into PW20
more often than intended).
-Scott
^ permalink raw reply
* Elbc device driver
From: Mercier Ivan @ 2013-10-08 14:06 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm working on a powerpc qoriq p3041 and trying to communicate with a
device by elbc bus in gpmc mode.
I 've integrated CONFIG_FSL_LBC in Linux which provide the basic functions.
Now I'm wondering how can I do read and write operations on the
bus.Where is mapped my device?
Should I code .read and .write driver functions?How can I start?
How integrates my device in the device tree?
thanks a lot,
Ivan
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-08 12:22 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, linux390, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
Ben Hutchings, linuxppc-dev
In-Reply-To: <20131007180111.GC2481@htj.dyndns.org>
On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
> > What about introducing pci_lock_msi() and pci_unlock_msi() and let device
> > drivers care about their ranges and specifics in race-safe manner?
> > I do not call to introduce it right now (since it appears pSeries has not
> > been hitting the race for years) just as a possible alternative to Ben's
> > proposal.
>
> I don't think the same race condition would happen with the loop.
We need to distinguish the contexts we're discussing.
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?).
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 :)
> 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.
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
From: Bartlomiej Zolnierkiewicz @ 2013-10-08 9:33 UTC (permalink / raw)
To: Michael Ellerman
Cc: Kyungmin Park, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <20131008035623.GA31666@concordia>
On Tuesday, October 08, 2013 02:56:23 PM Michael Ellerman wrote:
> On Thu, Oct 03, 2013 at 01:51:27PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday, October 01, 2013 04:13:25 PM Michael Ellerman wrote:
> > > On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > __initdata tag should be placed between the variable name and equal
> > > > sign for the variable to be placed in the intended .init.data section.
> > >
> > > I see lots of other occurences of that in arch/powerpc. Why not send a
> > > single patch to update them all?
> >
> > The other occurences while not following the preferred kernel coding style
> > are (probably) working OK with gcc. This particular occurence just doesn't
> > work as it should.
>
> Why would the other occurrences work but not this one?
Because gcc seems to generate the correct code for things like i.e. this one:
struct of_device_id __initdata legacy_serial_parents[]
but not for ones like this:
struct __initdata of_device_id legacy_serial_parents[]
> Regardless, why don't we just do a single patch to clean them all up to
> match coding style and (probably) do what they're intended.
Because:
- fixing this occurence changes runtime, fixing others won't
- there were no such request from powerpc Maintainers
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-08 9:07 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Bjorn Helgaas, Dan Williams,
Jon Mason, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <20131007182117.GC27396@htj.dyndns.org>
On Mon, Oct 07, 2013 at 02:21:17PM -0400, Tejun Heo wrote:
> Whee.... that's a lot more than I expected. I was just scanning
> multiple msi users. Maybe we can stage the work in more manageable
> steps so that you don't have to go through massive conversion only to
> do it all over again afterwards and likewise people don't get
> bombarded on each iteration? Maybe we can first update pci / msi code
> proper, msi and then msix?
Multipe MSIs is just a handful of drivers, really. MSI-X impact still
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.
> tejun
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH RFC 05/77] PCI/MSI: Convert pci_msix_table_size() to a public interface
From: Alexander Gordeev @ 2013-10-08 7:56 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Bjorn Helgaas, Dan Williams,
Jon Mason, Solarflare linux maintainers, netdev, linux-kernel,
Ralf Baechle, e1000-devel, Martin Schwidefsky, linux390,
linuxppc-dev
In-Reply-To: <20131007181043.GA27396@htj.dyndns.org>
On Mon, Oct 07, 2013 at 02:10:43PM -0400, Tejun Heo wrote:
> On Wed, Oct 02, 2013 at 12:48:21PM +0200, Alexander Gordeev wrote:
> > Make pci_msix_table_size() to return a error code if the device
> > does not support MSI-X. This update is needed to facilitate a
> > forthcoming re-design MSI/MSI-X interrupts enabling pattern.
> >
> > Device drivers will use this interface to obtain maximum number
> > of MSI-X interrupts the device supports and use that value in
> > the following call to pci_enable_msix() interface.
>
> Hmmm... I probably missed something but why is this necessary? To
> discern between -EINVAL and -ENOSPC? If so, does that really matter?
pci_msix_table_size() is kind of helper and returns 0 if a device does
not have MSI-X table. If we want drivers to use it we need return -EINVAL
for MSI-X incapable/disabled devices. Nothing about -ENOSPC.
> tejun
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-08 7:48 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-mips, linux-doc, VMware, Inc., linux-nvme, linux-ide,
linux-s390, Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar,
linux-pci, iss_storagedev, linux-driver, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
linux390, linuxppc-dev
In-Reply-To: <20131007181749.GB27396@htj.dyndns.org>
On Mon, Oct 07, 2013 at 02:17:49PM -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Oct 02, 2013 at 12:48:23PM +0200, Alexander Gordeev wrote:
> > +static int foo_driver_enable_msi(struct foo_adapter *adapter, int nvec)
> > +{
> > + rc = pci_get_msi_cap(adapter->pdev);
> > + if (rc < 0)
> > + return rc;
> > +
> > + nvec = min(nvec, rc);
> > + if (nvec < FOO_DRIVER_MINIMUM_NVEC) {
> > + return -ENOSPC;
> > +
> > + rc = pci_enable_msi_block(adapter->pdev, nvec);
> > + return rc;
> > +}
>
> 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.
> > @@ -975,7 +951,7 @@ int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
> > if (nr_entries < 0)
> > return nr_entries;
> > if (nvec > nr_entries)
> > - return nr_entries;
> > + return -EINVAL;
> >
> > /* Check for any invalid entries */
> > for (i = 0; i < nvec; i++) {
>
> 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.
> 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?
> tejun
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* [PATCH] powerpc/powernv: Add a debugfs file to read the firmware console
From: Benjamin Herrenschmidt @ 2013-10-08 7:46 UTC (permalink / raw)
To: linuxppc-dev
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 <benh@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 */
+struct memcons {
+ uint64_t magic;
+#define MEMCONS_MAGIC 0x6630696567726173
+ 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 0x80000000u
+#define MEMCONS_OUT_POS_MASK 0x00ffffffu
+ uint32_t in_prod;
+ uint32_t in_cons;
+};
+
static struct device_node *opal_node;
static DEFINE_SPINLOCK(opal_write_lock);
extern u64 opal_mc_secondary_handler[];
@@ -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;
+ }
+
+ opos = pos = *ppos;
+
+ /* Sanity check arguments */
+ if (pos < 0)
+ return -EINVAL;
+ if (pos >= available || !count)
+ return 0;
+ if (count > available - pos)
+ count = available - pos;
+
+ /* Handle first chunk */
+ if (pos < chunk0) {
+ lcount = min(count, chunk0 - (size_t)pos);
+ ret = copy_to_user(to, start + pos, lcount);
+ if (ret == lcount)
+ return -EFAULT;
+ lcount -= ret;
+ count -= lcount;
+ *ppos += lcount;
+ to += lcount;
+ pos = 0;
+ } else {
+ *ppos += chunk0;
+ pos -= chunk0;
+ ret = 0;
+ }
+
+ /* Handle second chunk */
+ if (count && chunk1 && ret == 0) {
+ lcount = min(count, chunk1 - (size_t)pos);
+ ret = copy_to_user(to, conbuf + pos, lcount);
+ if (ret == lcount)
+ return -EFAULT;
+ lcount -= ret;
+ *ppos += lcount;
+ }
+ return *ppos - opos;
+
+}
+
+static const struct file_operations opal_fops_memcons = {
+ .read = opal_memcons_read,
+ .open = simple_open,
+ .llseek = default_llseek,
+};
+
+static void opal_init_debugfs(void)
+{
+ u64 mcaddr;
+
+ if (of_property_read_u64(opal_node, "ibm,opal-memcons", &mcaddr) == 0)
+ debugfs_create_file("opal-log", 0400, powerpc_debugfs_root,
+ __va(mcaddr), &opal_fops_memcons);
+}
+#else
+static void opal_init_debugfs(void) { }
+#endif /* CONFIG_DEBUG_FS */
+
static int __init opal_init(void)
{
struct device_node *np, *consoles;
@@ -414,6 +515,9 @@ static int __init opal_init(void)
" (0x%x)\n", rc, irq, hwirq);
opal_irqs[i] = irq;
}
+
+ opal_init_debugfs();
+
return 0;
}
subsys_initcall(opal_init);
^ permalink raw reply related
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-08 7:33 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
linux390, linuxppc-dev
In-Reply-To: <20131008043330.GF31666@concordia>
On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote:
> On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> > This technique proved to be confusing and error-prone. Vast share
> > of device drivers simply fail to follow the described guidelines.
>
> To clarify "Vast share of device drivers":
>
> - 58 drivers call pci_enable_msix()
> - 24 try a single allocation and then fallback to MSI/LSI
> - 19 use the loop style allocation as above
> - 14 try an allocation, and if it fails retry once
> - 1 incorrectly continues when pci_enable_msix() returns > 0
>
> So 33 drivers (> 50%) successfully make use of the "confusing and
> error-prone" return value.
Ok, you caught me - 'vast share' is incorrect and is a subject to
rewording. But out of 19/58 how many drivers tested fallbacks on the
real hardware? IOW, which drivers are affected by the pSeries quota?
> And yes, one is buggy, so obviously the interface is too complex. Thanks
> drivers/ntb/ntb_hw.c
vmxnet3 would be the best example.
> cheers
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts
From: Anshuman Khandual @ 2013-10-08 7:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, mikey
In-Reply-To: <20131008042137.GE31666@concordia>
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. Besides, we can always look at these code consolidation
issues in future. But this patch solves a problem which is happening right now.
Regards
Anshuman
^ permalink raw reply
* Re: [PATCH v2 14/14] Kconfig cleanup (PARPORT_PC dependencies)
From: Ralf Baechle @ 2013-10-08 7:00 UTC (permalink / raw)
To: Mark Salter
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Paul Mackerras,
H. Peter Anvin, sparclinux, Guan Xuetao, Russell King,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Fenghua Yu, microblaze-uclinux,
Thomas Gleixner, linux-arm-kernel, Richard Henderson,
Michal Simek, Tony Luck, linux-parisc, Vineet Gupta, linux-kernel,
Paul Mundt, linux-alpha, linuxppc-dev, David S. Miller
In-Reply-To: <1381209030-351-15-git-send-email-msalter@redhat.com>
On Tue, Oct 08, 2013 at 01:10:30AM -0400, Mark Salter wrote:
> Remove messy dependencies from PARPORT_PC by having it depend on one
> Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures
> which need it, select ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig.
> New architectures are unlikely to need PARPORT_PC, so this avoids
> having an ever growing list of architectures to exclude. Those
> architectures which do select ARCH_MAY_HAVE_PC_PARPORT in this
> patch are the ones which have an asm/parport.h (or use the generic
> version).
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: [PATCH v2 14/14] Kconfig cleanup (PARPORT_PC dependencies)
From: Ingo Molnar @ 2013-10-08 5:46 UTC (permalink / raw)
To: Mark Salter
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Paul Mackerras,
H. Peter Anvin, sparclinux, Guan Xuetao, Russell King,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Fenghua Yu, microblaze-uclinux,
Thomas Gleixner, linux-arm-kernel, Richard Henderson,
Michal Simek, Tony Luck, linux-parisc, Vineet Gupta, linux-kernel,
Ralf Baechle, Paul Mundt, linux-alpha, linuxppc-dev,
David S. Miller
In-Reply-To: <1381209030-351-15-git-send-email-msalter@redhat.com>
* Mark Salter <msalter@redhat.com> wrote:
> Remove messy dependencies from PARPORT_PC by having it depend on one
> Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures
> which need it, select ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig.
> New architectures are unlikely to need PARPORT_PC, so this avoids
> having an ever growing list of architectures to exclude. Those
> architectures which do select ARCH_MAY_HAVE_PC_PARPORT in this
> patch are the ones which have an asm/parport.h (or use the generic
> version).
>
> Signed-off-by: Mark Salter <msalter@redhat.com>
> CC: Richard Henderson <rth@twiddle.net>
> CC: linux-alpha@vger.kernel.org
> CC: Vineet Gupta <vgupta@synopsys.com>
> CC: Russell King <linux@arm.linux.org.uk>
> CC: linux-arm-kernel@lists.infradead.org
> CC: Tony Luck <tony.luck@intel.com>
> CC: Fenghua Yu <fenghua.yu@intel.com>
> CC: linux-ia64@vger.kernel.org
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> CC: linux-m68k@lists.linux-m68k.org
> CC: Michal Simek <monstr@monstr.eu>
> CC: microblaze-uclinux@itee.uq.edu.au
> CC: Ralf Baechle <ralf@linux-mips.org>
> CC: linux-mips@linux-mips.org
> CC: "James E.J. Bottomley" <jejb@parisc-linux.org>
> CC: Helge Deller <deller@gmx.de>
> CC: linux-parisc@vger.kernel.org
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: linuxppc-dev@lists.ozlabs.org
> CC: Paul Mundt <lethal@linux-sh.org>
> CC: linux-sh@vger.kernel.org
> CC: "David S. Miller" <davem@davemloft.net>
> CC: sparclinux@vger.kernel.org
> CC: Guan Xuetao <gxt@mprc.pku.edu.cn>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Ingo Molnar <mingo@redhat.com>
> CC: "H. Peter Anvin" <hpa@zytor.com>
> CC: x86@kernel.org
> ---
> drivers/parport/Kconfig | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
> index 70694ce..a079b18 100644
> --- a/drivers/parport/Kconfig
> +++ b/drivers/parport/Kconfig
> @@ -31,13 +31,17 @@ menuconfig PARPORT
>
> If unsure, say Y.
>
> +config ARCH_MAY_HAVE_PC_PARPORT
> + bool
> + help
> + Select this config option from the architecture Kconfig if
> + the architecture may have PC parallel port hardware.
> +
> if PARPORT
>
> config PARPORT_PC
> tristate "PC-style hardware"
> - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
> - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
> - !XTENSA && !CRIS && !H8300
> + depends on ARCH_MAY_HAVE_PC_PARPORT
>
> ---help---
> You should say Y here if you have a PC-style parallel port. All
Since it's not a permission to have a parallel port but a possibility,
I suspect the whole series needs a:
s/MAY_HAVE/MIGHT_HAVE
s/may have/might have
Otherwise:
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* [PATCH v2 14/14] Kconfig cleanup (PARPORT_PC dependencies)
From: Mark Salter @ 2013-10-08 5:10 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-m68k, linux-ia64, linux-sh, Paul Mackerras,
H. Peter Anvin, sparclinux, Guan Xuetao, Russell King,
Helge Deller, x86, James E.J. Bottomley, Ingo Molnar,
Geert Uytterhoeven, Mark Salter, Fenghua Yu, microblaze-uclinux,
Thomas Gleixner, linux-arm-kernel, Richard Henderson,
Michal Simek, Tony Luck, linux-parisc, Vineet Gupta, Ralf Baechle,
Paul Mundt, linux-alpha, linuxppc-dev, David S. Miller
In-Reply-To: <1381209030-351-1-git-send-email-msalter@redhat.com>
Remove messy dependencies from PARPORT_PC by having it depend on one
Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures
which need it, select ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig.
New architectures are unlikely to need PARPORT_PC, so this avoids
having an ever growing list of architectures to exclude. Those
architectures which do select ARCH_MAY_HAVE_PC_PARPORT in this
patch are the ones which have an asm/parport.h (or use the generic
version).
Signed-off-by: Mark Salter <msalter@redhat.com>
CC: Richard Henderson <rth@twiddle.net>
CC: linux-alpha@vger.kernel.org
CC: Vineet Gupta <vgupta@synopsys.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
CC: Tony Luck <tony.luck@intel.com>
CC: Fenghua Yu <fenghua.yu@intel.com>
CC: linux-ia64@vger.kernel.org
CC: Geert Uytterhoeven <geert@linux-m68k.org>
CC: linux-m68k@lists.linux-m68k.org
CC: Michal Simek <monstr@monstr.eu>
CC: microblaze-uclinux@itee.uq.edu.au
CC: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
CC: "James E.J. Bottomley" <jejb@parisc-linux.org>
CC: Helge Deller <deller@gmx.de>
CC: linux-parisc@vger.kernel.org
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
CC: Paul Mundt <lethal@linux-sh.org>
CC: linux-sh@vger.kernel.org
CC: "David S. Miller" <davem@davemloft.net>
CC: sparclinux@vger.kernel.org
CC: Guan Xuetao <gxt@mprc.pku.edu.cn>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
---
drivers/parport/Kconfig | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/parport/Kconfig b/drivers/parport/Kconfig
index 70694ce..a079b18 100644
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -31,13 +31,17 @@ menuconfig PARPORT
If unsure, say Y.
+config ARCH_MAY_HAVE_PC_PARPORT
+ bool
+ help
+ Select this config option from the architecture Kconfig if
+ the architecture may have PC parallel port hardware.
+
if PARPORT
config PARPORT_PC
tristate "PC-style hardware"
- depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS && !H8300
+ depends on ARCH_MAY_HAVE_PC_PARPORT
---help---
You should say Y here if you have a PC-style parallel port. All
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 09/14] powerpc: select ARCH_MAY_HAVE_PC_PARPORT
From: Mark Salter @ 2013-10-08 5:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev, Mark Salter
In-Reply-To: <1381209030-351-1-git-send-email-msalter@redhat.com>
Architectures which support CONFIG_PARPORT_PC should select
ARCH_MAY_HAVE_PC_PARPORT.
Signed-off-by: Mark Salter <msalter@redhat.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 38f3b7e..9211207 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -85,6 +85,7 @@ config GENERIC_HWEIGHT
config PPC
bool
default y
+ select ARCH_MAY_HAVE_PC_PARPORT
select BINFMT_ELF
select OF
select OF_EARLY_FLATTREE
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Michael Ellerman @ 2013-10-08 4:33 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, VMware, Inc., linux-nvme, linux-ide, linux-s390,
Andy King, linux-scsi, linux-rdma, x86, Ingo Molnar, linux-pci,
iss_storagedev, linux-driver, Tejun Heo, Bjorn Helgaas,
Dan Williams, Jon Mason, Solarflare linux maintainers, netdev,
linux-kernel, Ralf Baechle, e1000-devel, Martin Schwidefsky,
linux390, linuxppc-dev
In-Reply-To: <cover.1380703262.git.agordeev@redhat.com>
On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote:
> This series is against "next" branch in Bjorn's repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
>
> Currently pci_enable_msi_block() and pci_enable_msix() interfaces
> return a error code in case of failure, 0 in case of success and a
> positive value which indicates the number of MSI-X/MSI interrupts
> that could have been allocated. The latter value should be passed
> to a repeated call to the interfaces until a failure or success:
>
>
> for (i = 0; i < FOO_DRIVER_MAXIMUM_NVEC; i++)
> adapter->msix_entries[i].entry = i;
>
> while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
> rc = pci_enable_msix(adapter->pdev,
> adapter->msix_entries, nvec);
> if (rc > 0)
> nvec = rc;
> else
> return rc;
> }
>
> return -ENOSPC;
>
>
> This technique proved to be confusing and error-prone. Vast share
> of device drivers simply fail to follow the described guidelines.
To clarify "Vast share of device drivers":
- 58 drivers call pci_enable_msix()
- 24 try a single allocation and then fallback to MSI/LSI
- 19 use the loop style allocation as above
- 14 try an allocation, and if it fails retry once
- 1 incorrectly continues when pci_enable_msix() returns > 0
So 33 drivers (> 50%) successfully make use of the "confusing and
error-prone" return value.
Another 24 happily ignore it, which is also entirely fine.
And yes, one is buggy, so obviously the interface is too complex. Thanks
drivers/ntb/ntb_hw.c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc, perf: Configure BHRB filter before enabling PMU interrupts
From: Michael Ellerman @ 2013-10-08 4:21 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, mikey
In-Reply-To: <1381120226-14838-1-git-send-email-khandual@linux.vnet.ibm.com>
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()" ?
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc/kernel/sysfs: cleanup set up macros for PMC/non-PMC SPRs
From: Michael Ellerman @ 2013-10-08 4:17 UTC (permalink / raw)
To: Madhavan Srinivasan; +Cc: olof, linuxppc-dev
In-Reply-To: <1380792456-19128-1-git-send-email-maddy@linux.vnet.ibm.com>
On Thu, Oct 03, 2013 at 02:57:35PM +0530, Madhavan Srinivasan wrote:
> Currently PMC (Performance Monitor Counter) setup macros are used
> for other SPRs. Since not all SPRs are PMC related, this patch
> modifies the exisiting macro and uses it to setup both PMC and
> non PMC SPRs accordingly.
>
> V3 changes:
>
> 1) No logic change, just renamed generic macro and removed #define for empty string
> 2) Changes in the comment to explain better.
>
> V2 changes:
>
> 1) Modified SYSFS_PMCSETUP to a generic macro with additional parameter
> 2) Added PMC and SPR macro to call the generic macro
> 3) Changes in the comment to explain better.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Acked-by: Michael Ellerman <michael@ellerman.id.au>
Thanks for putting up with all the bike-shedding.
cheers
^ permalink raw reply
* Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
From: Michael Ellerman @ 2013-10-08 4:00 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <20131003190325.GB21561@us.ibm.com>
On Thu, Oct 03, 2013 at 12:03:25PM -0700, Sukadev Bhattiprolu wrote:
> Michael Ellerman [michael@ellerman.id.au] wrote:
> | On Tue, Oct 01, 2013 at 05:15:06PM -0700, Sukadev Bhattiprolu wrote:
> | > Implement is_instr_load_store() to detect whether a given instruction
> | > is one of the fixed-point or floating-point load/store instructions.
> | > This function will be used in a follow-on patch to save memory hierarchy
> | > information of the load/store.
> |
> | Anyway, I think the following logic is all we need for opcode 31:
> |
> | bool is_load_store(int ext_opcode)
>
> how about I call this is_load_store_2_06() and add a comment. Horrible
> but minimizes chance of misuse.
Actually it's is_opcode_31_load_store_2_06() - which is even more
horrible :)
But you can probably fold it in to the main routine and then call that
is_load_store_2_06(). Or whatever seems best, but yeah I think we should
make it very clear that it's only for 2.06.
cheers
^ permalink raw reply
* RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-10-08 3:58 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Bhushan Bharat-R65777
In-Reply-To: <1380582385.24959.542.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAwMSwgMjAxMyA3OjA2IEFNDQo+IFRvOiBXYW5n
IERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBCaHVzaGFuIEJoYXJh
dC1SNjU3Nzc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIHY0IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAgc3RhdGUg
YW5kDQo+IGFsdGl2ZWMgaWRsZQ0KPiANCj4gT24gU3VuLCAyMDEzLTA5LTI5IGF0IDAxOjU3IC0w
NTAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2Vu
dDogU2F0dXJkYXksIFNlcHRlbWJlciAyOCwgMjAxMyA1OjMzIEFNDQo+ID4gPiBUbzogV2FuZyBE
b25nc2hlbmctQjQwNTM0DQo+ID4gPiBDYzogV29vZCBTY290dC1CMDc0MjE7IEJodXNoYW4gQmhh
cmF0LVI2NTc3NzsgbGludXhwcGMtDQo+ID4gPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4g
U3ViamVjdDogUmU6IFtQQVRDSCB2NCA0LzRdIHBvd2VycGMvODV4eDogYWRkIHN5c2ZzIGZvciBw
dzIwIHN0YXRlDQo+ID4gPiBhbmQgYWx0aXZlYyBpZGxlDQo+ID4gPg0KPiA+ID4gT24gVGh1LCAy
MDEzLTA5LTI2IGF0IDIyOjM0IC0wNTAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQgd3JvdGU6DQo+
ID4gPiA+IGN5Y2xlID0gZGl2X3U2NChucyAqIHRiX3RpY2tzX3Blcl91c2VjLCAxMDAwKTsgSXQn
cyBsb29rIGdvb2QuDQo+ID4gPiA+IEJ1dCB3aHkgd2UgbmVlZDoNCj4gPiA+ID4gCWlmIChucyA+
PSAxMDAwMCkNCj4gPiA+ID4gCQljeWNsZSA9ICgobnMgKyA1MDApIC8gMTAwMCkgKiB0Yl90aWNr
c19wZXJfdXNlYzsgPw0KPiA+ID4gPg0KPiA+ID4gPiBJIHRoaW5rICJjeWNsZSA9IGRpdl91NjQo
bnMgKiB0Yl90aWNrc19wZXJfdXNlYywgMTAwMCkiIGlzIGdvb2QNCj4gPiA+ID4gZW5vdWdoLiA6
KQ0KPiA+ID4NCj4gPiA+IEl0J3MgdG8gZGVhbCB3aXRoIG92ZXJmbG93IGlmIGEgdmVyeSBsYXJn
ZSB2YWx1ZSBvZiBucyBpcyBwcm92aWRlZA0KPiA+ID4gKGFuZC9vciB0Yl90aWNrc19wZXJfdXNl
YyBpcyBsYXJnZXIgdGhhbiB3ZSBleHBlY3QpLg0KPiA+ID4NCj4gPiA6KSwgYXMgSSB0aGluaywg
aXQncyB0byBkZWFsIHdpdGggb3ZlcmZsb3cuIEJ1dCB5b3UgdmVyc2lvbiBjYW5ub3QgZG8NCj4g
ZGVhbCB3aXRoIGl0Lg0KPiA+IEJlY2F1c2UgbnMgaXMgdTY0LCBpZiBucyA+IDB4ZmZmZmZmZmZf
ZmZmZmZlMGIsIG5zICsgNTAwIHdpbGwgb3ZlcmZsb3csDQo+IEFuZCBpZiB0Yl90aWNrc19wZXJf
dXNlYyA+IDEwMDAgYW5kIG5zID4gKDB4ZmZmZmZmZmZfZmZmZmZmZmYgLyAxMCkgY3ljbGUNCj4g
YWxzbyB3aWxsIG92ZXJmbG93Lg0KPiANCj4gU2lnaC4uLiBJdCBzaWduaWZpY2FudGx5IGluY3Jl
YXNlcyB0aGUgdmFsdWUgb2YgbnMgYXQgd2hpY2ggeW91J2xsIGdldA0KPiBvdmVyZmxvdyBwcm9i
bGVtcy4gOi0pICBJIHdhcyBtb3JlIGNvbmNlcm5lZCB3aXRoIGxhcmdlLWJ1dC1zb21ld2hhdC0N
Cj4gcmVhc29uYWJsZSB2YWx1ZXMgb2YgbnMgKGUuZy4gdGhhbiB3aXRoIHRyeWluZyB0byBoYW5k
bGUgZXZlcnkgcG9zc2libGUNCj4gaW5wdXQuICBFdmVuIHdpdGhvdXQgdGhhdCB0ZXN0LCBnZXR0
aW5nIG92ZXJmbG93IGlzIHN0cmV0Y2hpbmcgdGhlIGJvdW5kcw0KPiBvZiByZWFzb25hYmxlbmVz
cyAoZS5nLiBhIDEgR0h6IHRpbWViYXNlIHdvdWxkIHJlcXVpcmUgYSB0aW1lb3V0IG9mIG92ZXIN
Cj4gNyBtb250aHMgdG8gb3ZlcmZsb3cpLCBidXQgaXQgd2FzIGxvdy1oYW5naW5nIGZydWl0LiAg
QW5kIHRoZSB3b3JzdCBjYXNlDQo+IGlzIHdlIGdvIHRvIHB3MjAgc29vbmVyIHRoYW4gdGhlIHVz
ZXIgd2FudGVkLCBzbyBsZXQncyBub3QgZ28gdG9vDQo+IG92ZXJib2FyZC4NCj4gDQo+IEkgZG91
YnQgeW91IHdvdWxkIHNlZSA+IDB4ZmZmZmZmZmZfZmZmZmZlMGIgZXhjZXB0IGlmIHNvbWVvbmUg
aXMgdHJ5aW5nDQo+IHRvIGRpc2FibGUgaXQgYnkgc2V0dGluZyAweGZmZmZmZmZmX2ZmZmZmZmZm
IGV2ZW4gdGhvdWdoIGEgc2VwYXJhdGUgQVBJDQo+IGlzIHByb3ZpZGVkIHRvIGNsZWFubHkgZGlz
YWJsZSBpdC4NCj4gDQo+ID4gSSB0aGluayB3ZSBuZWVkIHRvIGRvIHRoaXM6DQo+ID4NCj4gPiAj
ZGVmaW5lIFU2NF9MT1dfTUFTSyAgICAgICAgICAgIDB4ZmZmZmZmZmZVTEwNCj4gPiAjZGVmaW5l
IFU2NF9NQVNLICAgICAgICAgICAgICAgIDB4ZmZmZmZmZmZmZmZmZmZmZlVMTA0KPiA+DQo+ID4g
ICAgICAgICB1MzIgdG1wX3JlbTsNCj4gPiAgICAgICAgIHU2NCBuc191X3JlbSwgbnNfdSwgbnNf
bCwgbnNfbF9jYXJyeTsNCj4gPiAgICAgICAgIHU2NCBjeWNsZTsNCj4gPg0KPiA+ICAgICAgICAg
bnNfdSA9IG5zID4+IDMyOw0KPiA+ICAgICAgICAgbnNfbCA9IG5zICYgVTY0X0xPV19NQVNLOw0K
PiA+DQo+ID4gICAgICAgICBuc19sICo9IHRiX3RpY2tzX3Blcl91c2VjOw0KPiA+ICAgICAgICAg
bnNfbF9jYXJyeSA9IG5zX2wgPj4gMzI7DQo+ID4gICAgICAgICBuc191ICo9IHRiX3RpY2tzX3Bl
cl91c2VjOw0KPiA+ICAgICAgICAgbnNfdSArPSBuc19sX2NhcnJ5Ow0KPiA+DQo+ID4gICAgICAg
ICBuc191ID0gZGl2X3U2NF9yZW0obnNfdSwgMTAwMCwgJnRtcF9yZW0pOw0KPiA+ICAgICAgICAg
bnNfdV9yZW0gPSB0bXBfcmVtOw0KPiA+ICAgICAgICAgbnNfbCA9IChuc19sICYgVTY0X0xPV19N
QVNLKSB8ICgobnNfdV9yZW0pIDw8IDMyKTsNCj4gPiAgICAgICAgIG5zX2wgPSBkaXZfdTY0KG5z
X2wsIDEwMDApOw0KPiA+DQo+ID4gICAgICAgICBpZiAobnNfdSA+PiAzMikNCj4gPiAgICAgICAg
ICAgICAgICAgY3ljbGUgPSBVNjRfTUFTSzsNCj4gPiAgICAgICAgIGVsc2UNCj4gPiAgICAgICAg
ICAgICAgICAgY3ljbGUgPSAobnNfdSA8PCAzMikgfCAobnNfbCAmIFU2NF9MT1dfTUFTSyk7DQo+
ID4NCj4gPiBJIGhhcyBhbHJlYWR5IHRlc3RlZCB0aGlzIGNvZGUsIGFuZCB3b3JrcyBnb29kLiA6
KQ0KPiANCj4gVWdoLiAgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGdldCB0aGlzIGNvbXBsaWNh
dGVkIChhbmQgSSdkIHJhdGhlciBub3QNCj4gc3BlbmQgdGhlIHRpbWUgdmVyaWZ5aW5nIHRoZSBj
b3JyZWN0bmVzcyBvZiB0aGlzKS4NCj4gDQo+IElmIGZvciBzb21lIHJlYXNvbiB3ZSBkaWQgbmVl
ZCBzb21ldGhpbmcgbGlrZSB0aGlzIGluIHNvbWUgb3RoZXIgY29udGV4dA0KPiAoSSBkb24ndCB3
YW50IHRvIHNlZSBpdCBqdXN0IGZvciBwdzIwKSwgSSdkIGJlIG1vcmUgaW5jbGluZWQgdG8gc2Vl
DQo+IGdlbmVyYWwgMTI4LWJpdCBtdWx0L2RpdmlkZSBzdXBwb3J0Lg0KPiANCkkgd291bGQgbGlr
ZSB0byB1c2UgbXkgdmVyc2lvbiw6KSwgYmVjYXVzZSBpdCBjYW4gaGFuZGxlIGFueSBzaXR1YXRp
b24gYW5kIHdlIGRvIG5vdCBuZWVkIHRvIHJlc3RyaWN0IHVzZXJzLg0KSGVyZSBpcyBhIGtpbmQg
b2Ygc3BlY2lhbCB3YXkgdG8gZ2V0IHRoZSBjeWNsZS4gSWYgdGhpcyAxMjgtYml0IHNpdHVhdGlv
biBpcyBtb3JlIGFuZCBtb3JlLCBhdCB0aGF0IHRpbWUgd2UgZ28gdG8gc3VwcG9ydCBpdC4NCg0K
LWRvbmdzaGVuZw0KDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 2/9][v5] powerpc/perf: Export Power8 generic events in sysfs
From: Michael Ellerman @ 2013-10-08 3:58 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Arnaldo Carvalho de Melo, Anshuman Khandual
In-Reply-To: <20131003175757.GA21561@us.ibm.com>
On Thu, Oct 03, 2013 at 10:57:57AM -0700, Sukadev Bhattiprolu wrote:
> Michael Ellerman [michael@ellerman.id.au] wrote:
> | On Tue, Oct 01, 2013 at 05:15:03PM -0700, Sukadev Bhattiprolu wrote:
> | > Export generic perf events for Power8 in sysfs.
> | >
> | > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> | > Reviewed-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> | > ---
> | > arch/powerpc/perf/power8-pmu.c | 23 +++++++++++++++++++++++
> | > 1 file changed, 23 insertions(+)
> | >
> | > diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
> | > index 976c203..b991b2e 100644
> | > --- a/arch/powerpc/perf/power8-pmu.c
> | > +++ b/arch/powerpc/perf/power8-pmu.c
> | > @@ -510,6 +510,28 @@ static void power8_disable_pmc(unsigned int pmc, unsigned long mmcr[])
> | > mmcr[1] &= ~(0xffUL << MMCR1_PMCSEL_SHIFT(pmc + 1));
> | > }
> | >
> | > +GENERIC_EVENT_ATTR(cpu-cyles, PM_CYC);
> | > +GENERIC_EVENT_ATTR(stalled-cycles-frontend, PM_GCT_NOSLOT_CYC);
> | > +GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL);
> | > +GENERIC_EVENT_ATTR(instructions, PM_INST_CMPL);
> | > +GENERIC_EVENT_ATTR(branch-instructions, PM_BRU_FIN);
> | > +GENERIC_EVENT_ATTR(branch-misses, PM_BR_MPRED_CMPL);
> |
> | And here you use PM_ not PME_ - I'm confused.
>
> It is a bit confusing. The GENERIC_EVENT_ATTR() adds the PME_ prefix.
So doesn't that give you PME_PM_CYC ?
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/legacy_serial: fix incorrect placement of __initdata tag
From: Michael Ellerman @ 2013-10-08 3:56 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Kyungmin Park, linuxppc-dev, linux-kernel, Paul Mackerras
In-Reply-To: <1600459.LJx7sBeEJs@amdc1032>
On Thu, Oct 03, 2013 at 01:51:27PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday, October 01, 2013 04:13:25 PM Michael Ellerman wrote:
> > On Mon, Sep 30, 2013 at 03:11:42PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > __initdata tag should be placed between the variable name and equal
> > > sign for the variable to be placed in the intended .init.data section.
> >
> > I see lots of other occurences of that in arch/powerpc. Why not send a
> > single patch to update them all?
>
> The other occurences while not following the preferred kernel coding style
> are (probably) working OK with gcc. This particular occurence just doesn't
> work as it should.
Why would the other occurrences work but not this one?
Regardless, why don't we just do a single patch to clean them all up to
match coding style and (probably) do what they're intended.
cheers
^ permalink raw reply
* RE: [PATCH 2/7] iommu: add api to get iommu_domain of a device
From: Bhushan Bharat-R65777 @ 2013-10-08 3:42 UTC (permalink / raw)
To: Alex Williamson
Cc: agraf@suse.de, Wood Scott-B07421, linux-pci@vger.kernel.org,
joro@8bytes.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1381201980.6330.4.camel@ul30vt.home>
PiA+ID4gRG8geW91IHJlYWxseSB3YW50IG1vZHVsZSBkZXBlbmRlbmNpZXMgYmV0d2VlbiB2Zmlv
IGFuZCB5b3VyIGNvcmUNCj4gPiA+IGtlcm5lbCBNU0kgc2V0dXA/ICBMb29rIGF0IHRoZSB2Zmlv
IGV4dGVybmFsIHVzZXIgaW50ZXJmYWNlIHRoYXQgd2UndmUNCj4gYWxyZWFkeSBkZWZpbmVkLg0K
PiA+ID4gVGhhdCBhbGxvd3Mgb3RoZXIgY29tcG9uZW50cyBvZiB0aGUga2VybmVsIHRvIGdldCBh
IHByb3BlciByZWZlcmVuY2UNCj4gPiA+IHRvIGEgdmZpbyBncm91cC4gIEZyb20gdGhlcmUgeW91
IGNhbiB3b3JrIG91dCBob3cgdG8gZ2V0IHdoYXQgeW91DQo+ID4gPiB3YW50LiAgQW5vdGhlciBh
bHRlcm5hdGl2ZSBpcyB0aGF0IHZmaW8gY291bGQgcmVnaXN0ZXIgYW4gTVNJIHRvDQo+ID4gPiBJ
T1ZBIG1hcHBpbmcgd2l0aCBhcmNoaXRlY3R1cmUgY29kZSB3aGVuIHRoZSBtYXBwaW5nIGlzIGNy
ZWF0ZWQuDQo+ID4gPiBUaGUgTVNJIHNldHVwIHBhdGggY291bGQgdGhlbiBkbyBhIGxvb2t1cCBp
biBhcmNoaXRlY3R1cmUgY29kZSBmb3INCj4gPiA+IHRoZSBtYXBwaW5nLiAgWW91IGNvdWxkIGV2
ZW4gc3RvcmUgdGhlIE1TSSB0byBJT1ZBIG1hcHBpbmcgaW4gVkZJTw0KPiA+ID4gYW5kIGNyZWF0
ZSBhbiBpbnRlcmZhY2Ugd2hlcmUgU0VUX0lSUSBwYXNzZXMgdGhhdCBtYXBwaW5nIGludG8gc2V0
dXAgY29kZS4NCj4gPg0KPiA+IE9rLCBXaGF0IEkgd2FudCBpcyB0byBnZXQgSU9WQSBhc3NvY2lh
dGVkIHdpdGggYSBwaHlzaWNhbCBhZGRyZXNzDQo+ID4gKHBoeXNpY2FsIGFkZHJlc3Mgb2YgTVNJ
LWJhbmspLg0KPiA+IEFuZCBjdXJyZW50bHkgSSBkbyBub3Qgc2VlIGEgd2F5IHRvIGtub3cgSU9W
QSBvZiBhIHBoeXNpY2FsIGFkZHJlc3MNCj4gPiBhbmQgZG9pbmcgYWxsIHRoaXMgZG9tYWluIGdl
dCBhbmQgdGhlbiBzZWFyY2ggdGhyb3VnaCBhbGwgb2YNCj4gPiBpb21tdS13aW5kb3dzIG9mIHRo
YXQgZG9tYWluLg0KPiA+DQo+ID4gV2hhdCBpZiB3ZSBhZGQgYW4gaW9tbXUtQVBJIHdoaWNoIGNh
biByZXR1cm4gdGhlIElPVkEgbWFwcGluZyBvZiBhDQo+ID4gcGh5c2ljYWwgYWRkcmVzcy4gQ3Vy
cmVudCB1c2UgY2FzZSBpcyBzZXR0aW5nIHVwIE1TSSdzIGZvciBhcGVydHVyZQ0KPiA+IHR5cGUg
b2YgSU9NTVUgYWxzbyBnZXR0aW5nIGEgcGh5c190b19pb3ZhKCkgbWFwcGluZyBpcyBpbmRlcGVu
ZGVudCBvZg0KPiA+IFZGSU8sIHlvdXIgdGhvdWdodD8NCj4gDQo+IEEgcGh5c2ljYWwgYWRkcmVz
cyBjYW4gYmUgbWFwcGVkIHRvIG11bHRpcGxlIElPVkFzLCBzbyB0aGUgaW50ZXJmYWNlIHNlZW1z
DQo+IGZsYXdlZCBieSBkZXNpZ24uICBJdCBhbHNvIGhhcyB0aGUgc2FtZSBwcm9ibGVtIGFzIGFi
b3ZlLCBpdCdzIGEgYmFja2Rvb3IgdGhhdA0KPiBjYW4gYmUgY2FsbGVkIGFzeW5jaHJvbm91cyB0
byB0aGUgb3duZXIgb2YgdGhlIGRvbWFpbiwgc28gd2hhdCByZWFzb24gaXMgdGhlcmUNCj4gdG8g
YmVsaWV2ZSB0aGUgcmVzdWx0PyAgSXQganVzdCByZXBsYWNlcyBhbiBpb21tdV9kb21haW4gcG9p
bnRlciB3aXRoIGFuIElPVkEuDQo+IFZGSU8ga25vd3MgdGhpcyBtYXBwaW5nLCBzbyB3aHkgYXJl
IHdlIHRyeWluZyB0byBnbyBiZWhpbmQgaXRzIGJhY2sgYW5kIGFzayB0aGUNCj4gSU9NTVU/DQpJ
T01NVSBpcyB0aGUgZmluYWwgcGxhY2Ugd2hlcmUgbWFwcGluZyBpcyBjcmVhdGVkLCBzbyBtYXkg
YmUgdG9kYXkgaXQgaXMgY2FsbGluZyBvbiBiZWhhbGYgb2YgVkZJTywgdG9tb3Jyb3cgaXQgY2Fu
IGJlIGZvciBub3JtYWwgTGludXggb3Igc29tZSBvdGhlciBpbnRlcmZhY2UuIEJ1dCBJIGFtIGZp
bmUgdG8gZGlyZWN0bHkgdGFsayB0byB2ZmlvIGFuZCB3aWxsIG5vdCB0cnkgdG8gc29sdmUgYSBw
cm9ibGVtIHdoaWNoIGRvZXMgbm90IGV4aXN0cyB0b2RheS4NCg0KTVNJIHN1YnN5c3RlbSBrbm93
cyBwZGV2IChwY2kgZGV2aWNlKSBhbmQgcGh5c2ljYWwgYWRkcmVzcywgdGhlbiB3aGF0IGludGVy
ZmFjZSBpdCB3aWxsIHVzZSB0byBnZXQgdGhlIElPVkEgZnJvbSBWRklPPw0KDQpUaGFua3MNCi1C
aGFyYXQNCg0KPiAgVGhhbmtzLA0KPiANCj4gQWxleA0KPiANCg0K
^ permalink raw reply
* Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().
From: Michael Ellerman @ 2013-10-08 3:28 UTC (permalink / raw)
To: Tom Musta
Cc: linux-kernel, Stephane Eranian, linuxppc-dev, Paul Mackerras,
Arnaldo Carvalho de Melo, Sukadev Bhattiprolu, Anshuman Khandual
In-Reply-To: <524DCAE6.5090601@gmail.com>
On Thu, 2013-10-03 at 14:52 -0500, Tom Musta wrote:
> On 10/3/2013 2:03 PM, Sukadev Bhattiprolu wrote:
> > Michael Ellerman [michael@ellerman.id.au] wrote:
> <snip>
> > |
> > | if (lower == 6)
> > | if (upper <= 1)
> > | return true;
> > | return false;
> > v
> Note that this case covers the lvsl/lvsr instructions, which, despite their
> names are not actually loads. So you could eliminate this check and do
> just a little bit better.
Yes you're right Tom, thanks for checking.
I saw "Load" in the name and that was good enough for me :)
cheers
^ 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