On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
How about no?
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
will get most/all of the MSIs and other devices miss out.
Out of curiosity -
From: Hongbo Zhang hongbo.zh...@freescale.com
Hi DMA and DT maintainers, please have a look at these V10 patches.
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.
V9-V10 changes:
- update binding description text, mainly about the reg
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch updates the discription of each type of DMA controller and its
channels, it is preparation for adding another new DMA controller binding, it
also fixes some defects of indent for text alignment at the same time.
Signed-off-by: Hongbo Zhang
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 69
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/Kconfig |9 +
On 09/14/2013 06:19 AM, Sukadev Bhattiprolu wrote:
On Power7, the DCACHE_SRC field in MMCRA register identifies the memory
hierarchy level (eg: L2, L3 etc) from which a data-cache miss for a
marked instruction was satisfied.
Use the 'perf_mem_data_src' object to export this hierarchy level
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Hi,
The cache bindings are generic and used by many other architectures
apart from PPC. These patches fixes and move the existing definition
of of_find_next_cache_node to DT common code.
Regards,
Sudeep
Sudeep KarkadaNagesha (2):
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Currently big endianness of the device tree data is assumed in
of_find_next_cache_node for 'handle' when calling of_find_node_by_phandle.
In preparation to move this function to common code, this patch fixes
the endianness using
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Since the definition of_find_next_cache_node is architecture independent,
the existing definition in powerpc can be moved to driver/of/base.c
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Grant Likely grant.lik...@linaro.org
Cc:
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
simultaneously. This patch is for this purpose. It derives
the common functions from
The Freescale's Layerscape series processors will use the same PCI
controller but change cores from PowerPC to ARM. This patch is to
rework FSL PCI driver to support PowerPC and ARM simultaneously.
PowerPC uses structure pci_controller to describe PCI controller,
but arm uses structure hw_pci and
The of_irq_to_resource() helper that is used to implement of_irq_count()
tries to resolve interrupts and in fact creates a mapping for resolved
interrupts. That's pretty heavy lifting for something that claims to
just return the number of interrupts requested by a given device node.
Instead, use
Hi,
This small series allows interrupt references from the device tree to be
resolved at driver probe time, rather than at device creation time. The
current implementation resolves such references while devices are added
during the call to of_platform_populate(), which happens very early in
the
Replace some instances of of_irq_map_one()/irq_create_of_mapping() and
of_irq_to_resource() by the simpler equivalent irq_of_parse_and_map().
Signed-off-by: Thierry Reding tred...@nvidia.com
---
arch/arm/mach-u300/timer.c | 9 -
This is a version of irq_create_mapping() that propagates the precise
error code instead of returning 0 for all errors. It will be used in
subsequent patches to allow further propagation of error codes.
To avoid code duplication, implement irq_create_mapping() as a wrapper
around the new
Instead of returning 0 for all errors, allow the precise error code to
be propagated. This will be used in subsequent patches to allow further
propagation of error codes.
The interrupt number corresponding to the new mapping is returned in an
output parameter so that the return value is reserved
This is a version of irq_of_parse_and_map() that propagates the precise
error code instead of returning 0 for all errors. It will be used in
subsequent patches to allow further propagation of error codes.
To avoid code duplication, implement irq_of_parse_and_map() as a static
inline wrapper
Update of_irq_to_resource() to return 0 on success and a negative error
code on failure. This allows the precise nature of the failure to be
determined in the caller and errors to be propagated appropriately.
While at it, make the index parameter unsigned. Accessing negative
indices is invalid,
Now that all helpers return precise error codes, this function can
propagate these errors to the caller properly.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v2:
- return 0 on success or a negative error code on failure
- convert callers to new calling convention
Instead of resolving interrupt references at device creation time, delay
resolution until probe time. At device creation time, there is nothing
that can be done if an interrupt parent isn't ready yet, and the device
will end up with an invalid interrupt number (0).
If the interrupt reference is
With the driver core now resolving interrupt references at probe time,
it is no longer necessary to force explicit probe ordering using
initcalls.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Note that there are potentially many more drivers that can be switched
to the generic
First of all, sorry for my english (I'm spanish).
At our company, we work in various projects in control systems and
automation in industrial environment, mostly with embedded custom linux
distributions with Freescale PowerPC processors (MPC5200b, MPC5125,
P1022, MPC8536E...).
In one of our
Hello,
On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
How about no?
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
On Wed, Sep 18, 2013 at 03:24:46PM +0200, Thierry Reding wrote:
For the MIPS bits:
Acked-by: Ralf Baechle r...@linux-mips.org
Ralf
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Sep 18, 2013 at 03:24:49PM +0200, Thierry Reding wrote:
For the MIPS bits:
Acked-by: Ralf Baechle r...@linux-mips.org
Ralf
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 18 Sep 2013 11:53:03 +0100, Sudeep KarkadaNagesha
sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Hi,
The cache bindings are generic and used by many other architectures
apart from PPC. These patches fixes and move the existing
On 18/09/13 15:51, Grant Likely wrote:
On Wed, 18 Sep 2013 11:53:03 +0100, Sudeep KarkadaNagesha
sudeep.karkadanage...@arm.com wrote:
From: Sudeep KarkadaNagesha sudeep.karkadanage...@arm.com
Hi,
The cache bindings are generic and used by many other architectures
apart from PPC. These
On Wed, Sep 18, 2013 at 09:22:31AM -0500, Tejun Heo wrote:
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
will get most/all of the MSIs and other devices miss out.
Out of curiosity - how pSeries
On Mon, 2013-09-16 at 21:11 -0500, Kushwaha Prabhakar-B32579 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, September 17, 2013 2:49 AM
To: Kushwaha Prabhakar-B32579
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
ga...@kernel.crashing.org; Aggrwal
Signed-off-by: Anoop Thomas Mathew a...@profoundis.com
---
arch/arc/kernel/kprobes.c |2 +-
arch/ia64/kernel/kprobes.c|2 +-
arch/powerpc/kernel/kprobes.c |2 +-
arch/s390/kernel/kprobes.c|2 +-
arch/sparc/kernel/kprobes.c |2 +-
5 files changed, 5 insertions(+),
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 from the LTIBs packages from Freescale. Both cards
31 matches
Mail list logo
