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,
From: Tang Yuantian
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian
Signed-off-by: Li Yang
---
v5:
- refine the binding document
- update the compatible string
v4:
- add binding document
-
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
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 K
This was missing on powerpc and I am getting compilation error
drivers/vfio/pci/vfio_pci_rdwr.c:193: undefined reference to `__cmpdi2'
drivers/vfio/pci/vfio_pci_rdwr.c:193: undefined reference to `__cmpdi2'
Signed-off-by: Bharat Bhushan
---
arch/powerpc/kernel/misc_32.S | 14 ++
Oops it came as 1/4,
I am sorry, please ignore this
Thanks
-Bharat
> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Wednesday, October 09, 2013 10:39 AM
> To: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; b...@kernel.crashing.org
> Cc: Bhushan Bharat-R65777; Bhushan Bharat-R
This was missing on powerpc and I am getting compilation error
drivers/vfio/pci/vfio_pci_rdwr.c:193: undefined reference to `__cmpdi2'
drivers/vfio/pci/vfio_pci_rdwr.c:193: undefined reference to `__cmpdi2'
Signed-off-by: Bharat Bhushan
---
arch/powerpc/kernel/misc_32.S | 14 ++
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, October 09, 2013 4:27 AM
> To: Bhushan Bharat-R65777
> Cc: alex.william...@redhat.com; j...@8bytes.org; b...@kernel.crashing.org;
> ga...@kernel.crashing.org; linux-ker...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org;
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 a
On Tue, 2013-10-08 at 20:55 -0700, H. Peter Anvin wrote:
> Why not add a minimum number to pci_enable_msix(), i.e.:
>
> pci_enable_msix(pdev, msix_entries, nvec, minvec)
>
> ... which means "nvec" is the number of interrupts *requested*, and
> "minvec" is the minimum acceptable number (otherwise
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
> > diagnostic
On 10/02/2013 03:29 AM, Alexander Gordeev wrote:
>
> As result, device drivers will cease to use the overcomplicated
> repeated fallbacks technique and resort to a straightforward
> pattern - determine the number of MSI/MSI-X interrupts required
> before calling pci_enable_msi_block() and pci_enab
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
> ---
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterio
On Tue, Oct 08, 2013 at 09:33:02AM +0200, Alexander Gordeev wrote:
> 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 drive
On Wed, Oct 09, 2013 at 12:03:19PM +1100, Michael Ellerman wrote:
> On Tue, 2013-10-08 at 12:31 -0700, Sukadev Bhattiprolu wrote:
> > Michael Ellerman [mich...@ellerman.id.au] wrote:
> > | bool is_load_store(int ext_opcode)
> > | {
> > | upper = ext_opcode >> 5;
> > | lower = ext_op
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 PM
On Tue, 2013-10-08 at 12:31 -0700, Sukadev Bhattiprolu wrote:
> Michael Ellerman [mich...@ellerman.id.au] wrote:
> | bool is_load_store(int ext_opcode)
> | {
> | upper = ext_opcode >> 5;
> | lower = ext_opcode & 0x1f;
> |
> | /* Short circuit as many misses as we can */
> |
> > > We made this change to pseries in 2011 and I think it makes
> > > sense to do the same on powernv.
> >
> > I'd vote we set it to 10s for all 64-bit machines in
> > arch/powerpc/kernel/setup_64.c.
>
> Why is 64-bit relevant? And wouldn't such a short delay be a problem
> if the crash is di
On Tue, 8 Oct 2013, Joseph S. Myers wrote:
> I'll send as a followup the testcase I used for verifying that the
> instructions (other than the theoretical conversions to 64-bit
> integers) produce the correct results. In addition, this has been
> tested with the glibc testsuite (with the e500 por
From: Joseph Myers
The e500 SPE floating-point emulation code has several problems in how
it handles conversions to integer and fixed-point fractional types.
There are the following 20 relevant instructions. These can convert
to signed or unsigned 32-bit integers, either rounding towards zero
(
On Tue, 2013-10-08 at 17:25 -0600, Bjorn Helgaas wrote:
> >> - u32 msiir_offset; /* Offset of MSIIR, relative to start of CCSR */
> >> + dma_addr_t msiir; /* MSIIR Address in CCSR */
> >
> > Are you sure dma_addr_t is right here, versus phys_addr_t? It implies
> > that it's the output of t
On Tue, 2013-10-08 at 18:20 -0500, Scott Wood wrote:
> > So I'll apply these given an ack from the powerpc folks.
>
> ACK this patch. The second one I'd like to see broken up into
> digestible chunks so I can better review it.
Bjorn, for such FSL-only stuff, Scott ack is enough, don't wait for
m
>> - u32 msiir_offset; /* Offset of MSIIR, relative to start of CCSR */
>> + dma_addr_t msiir; /* MSIIR Address in CCSR */
>
> Are you sure dma_addr_t is right here, versus phys_addr_t? It implies
> that it's the output of the DMA API, but I don't think the DMA API is
> used in the MSI dri
From: Joseph Myers
On overflow, the math-emu macro _FP_TO_INT_ROUND tries to saturate its
result (subject to the value of rsigned specifying the desired
overflow semantics). However, if the rounding step has the effect of
increasing the exponent so as to cause overflow (if the rounded result
is
On Tue, 2013-10-08 at 17:09 -0600, Bjorn Helgaas wrote:
> On Tue, Oct 8, 2013 at 4:46 PM, Scott Wood wrote:
> > On Tue, 2013-10-08 at 13:13 -0600, Bjorn Helgaas wrote:
> >> [+cc Ben, Paul, linuxppc-dev]
> >>
> >> On Mon, Sep 30, 2013 at 04:52:54PM +0800, Minghuan Lian wrote:
> >> > The Freescale's
From: Joseph Myers
The math-emu macros _FP_TO_INT and _FP_TO_INT_ROUND are supposed to
saturate their results for out-of-range arguments, except in the case
rsigned == 2 (when instead the low bits of the result are taken).
However, in the case rsigned == 0 (converting to unsigned integers),
they
On Tue, Oct 8, 2013 at 4:46 PM, Scott Wood wrote:
> On Tue, 2013-10-08 at 13:13 -0600, Bjorn Helgaas wrote:
>> [+cc Ben, Paul, linuxppc-dev]
>>
>> On Mon, Sep 30, 2013 at 04:52:54PM +0800, Minghuan Lian wrote:
>> > The Freescale's Layerscape series processors will use ARM cores.
>> > The LS1's PCI
On Thu, 2013-09-19 at 12:59 +0530, Bharat Bhushan wrote:
> @@ -376,6 +405,7 @@ static int fsl_of_msi_probe(struct platform_device *dev)
> int len;
> u32 offset;
> static const u32 all_avail[] = { 0, NR_MSI_IRQS };
> + static int bank_index;
>
> match = of_match_device(
On Tue, 2013-10-08 at 13:13 -0600, Bjorn Helgaas wrote:
> [+cc Ben, Paul, linuxppc-dev]
>
> On Mon, Sep 30, 2013 at 04:52:54PM +0800, Minghuan Lian wrote:
> > The Freescale's Layerscape series processors will use ARM cores.
> > The LS1's PCIe controllers is the same as T4240's. So it's better
> >
On Tue, 2013-10-08 at 16:06 +0200, Mercier Ivan wrote:
> 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 wr
On Fri, 2013-10-04 at 12:03 +, Thomas Hühn wrote:
> [code]
> [ 2671.841927] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 2671.847141] Freescale P1014
> [ 2671.849925] Modules linked in: ath9k pppoe ppp_async iptable_nat
> ath9k_common pppox p
> e xt_tcpudp xt_tcpmss xt_string xt_statistic x
On Tue, 2013-10-01 at 18:39 +1000, Michael Ellerman wrote:
> On Thu, Sep 26, 2013 at 09:17:19PM +1000, Anton Blanchard wrote:
> >
> > We made this change to pseries in 2011 and I think it makes
> > sense to do the same on powernv.
>
> I'd vote we set it to 10s for all 64-bit machines in
> arch/po
On Fri, 27 Sep 2013 17:28:38 +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 "i
On Fri, 4 Oct 2013 17:37:09 +0200
Wolfram Sang wrote:
> This more or less reverts commit 6391f697d4892a6f233501beea553e13f7745a23.
> Instead of adding an unneeded 'default', mark the variable to prevent
> the false positive 'uninitialized var'. The other change (fixing the
> printout) needs reve
On Wed, 2013-09-18 at 22:43 -0400, Dorin D wrote:
> I am working on bringing up two Linux systems, both based on Freescale
> PowerPC devices, one is a MPC8349, the other a P1020. I was able to
> build, install and boot the kernel on both cards. The kernel is 2.6.32
> and the toolchains are coming
Michael Ellerman [mich...@ellerman.id.au] wrote:
| bool is_load_store(int ext_opcode)
| {
| upper = ext_opcode >> 5;
| lower = ext_opcode & 0x1f;
|
| /* Short circuit as many misses as we can */
| if (lower < 3 || lower > 23)
| return false;
I see some
[+cc Ben, Paul, linuxppc-dev]
On Mon, Sep 30, 2013 at 04:52:54PM +0800, Minghuan Lian wrote:
> The Freescale's Layerscape series processors will use ARM cores.
> The LS1's PCIe controllers is the same as T4240's. So it's better
> the PCIe controller driver can support PowerPC and ARM
> simultaneou
On Tue, 2013-10-08 at 10:47 -0600, Bjorn Helgaas wrote:
> On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777
> 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
> >
> -Original Message-
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Tuesday, October 08, 2013 10:32 PM
> To: Bjorn Helgaas
> Cc: Bhushan Bharat-R65777; alex.william...@redhat.com;
> b...@kernel.crashing.org;
> ga...@kernel.crashing.org; linux-ker...@vger.kernel.org; linuxppc-
>
On Tue, Oct 08, 2013 at 10:47:49AM -0600, Bjorn Helgaas wrote:
> I still have no idea what an "aperture type IOMMU" is,
> other than that it is "different."
An aperture based IOMMU is basically any GART-like IOMMU which can only
remap a small window (the aperture) of the DMA address space. DMA
out
On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777
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 Fre
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-
> > d...@lists.ozlabs.org
> > Subject:
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 .re
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 hitt
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:
> > > >
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 afterwar
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 i
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)
> > +
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
---
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powern
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 sh
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 w
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 unlik
53 matches
Mail list logo
