Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv2 2/6] mm/cma: Cleanup highmem check
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>


6b101e2a3ce4 ("mm/CMA: fix boot regression due to physical address of
high_memory") added checks to use __pa_nodebug on x86 since
CONFIG_DEBUG_VIRTUAL complains about high_memory not being linearlly
mapped. arm64 is now getting support for CONFIG_DEBUG_VIRTUAL as well.
Rather than add an explosion of arches to the #ifdef, switch to an
alternate method to calculate the physical start of highmem using
the page before highmem starts. This avoids the need for the #ifdef and
extra __pa_nodebug calls.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 mm/cma.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/mm/cma.c b/mm/cma.c
index 384c2cb..71a2ec1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -235,18 +235,13 @@ int __init cma_declare_contiguous(phys_addr_t base,
 	phys_addr_t highmem_start;
 	int ret = 0;
 
-#ifdef CONFIG_X86
 	/*
-	 * high_memory isn't direct mapped memory so retrieving its physical
-	 * address isn't appropriate.  But it would be useful to check the
-	 * physical address of the highmem boundary so it's justifiable to get
-	 * the physical address from it.  On x86 there is a validation check for
-	 * this case, so the following workaround is needed to avoid it.
+	 * We can't use __pa(high_memory) directly, since high_memory
+	 * isn't a valid direct map VA, and DEBUG_VIRTUAL will (validly)
+	 * complain. Find the boundary by adding one to the last valid
+	 * address.
 	 */
-	highmem_start = __pa_nodebug(high_memory);
-#else
-	highmem_start = __pa(high_memory);
-#endif
+	highmem_start = __pa(high_memory - 1) + 1;
 	pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n",
 		__func__, &size, &base, &limit, &alignment);
 
-- 
2.10.1

^ permalink raw reply related
* [PATCHv2 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161102210054.16621-1-labbott@redhat.com>


DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting
the same support. Rather than add a list of architectures, switch this
to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as
appropriate.

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 arch/x86/Kconfig  | 1 +
 lib/Kconfig.debug | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..f533321 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
 	select ARCH_CLOCKSOURCE_DATA
 	select ARCH_DISCARD_MEMBLOCK
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b01e547..5050530 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -603,9 +603,12 @@ config DEBUG_VM_PGFLAGS
 
 	  If unsure, say N.
 
+config ARCH_HAS_DEBUG_VIRTUAL
+	bool
+
 config DEBUG_VIRTUAL
 	bool "Debug VM translations"
-	depends on DEBUG_KERNEL && X86
+	depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
 	help
 	  Enable some costly sanity checks in virtual to page code. This can
 	  catch mistakes with virt_to_page() and friends.
-- 
2.10.1

^ permalink raw reply related
* [PATCHv2 0/6] CONFIG_DEBUG_VIRTUAL for arm64
From: Laura Abbott @ 2016-11-02 21:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

This is v2 of the series to add CONFIG_DEBUG_VIRTUAL support from arm64. This
has been split out into a number of patches:

Patch #1 Adds ARCH_HAS_DEBUG_VIRTUAL to avoid the need for adding arch
dependencies for DEBUG_VIRTUAL. This touches arch/x86/Kconfig

Patch #2 Cleans up cma to not rely on __pa_nodebug and have an #ifdef inline
in the function.

Patch #3 Adjust some macros in arm64 memory.h to be under __ASSEMBLY__
protection

Patch #4 Adds a cast for virt_to_pfn since __virt_to_phys for DEBUG_VIRTUAL no
longer has a cast.

Patch #5 Switches to using __pa_symbol for _end to avoid erroneously triggering
a bounds error with the debugging.

Patch #6 is the actual implementation of DEBUG_VIRTUAL. The biggest change from
the RFCv1 is the addition of __phys_addr_symbol. This is to handle several
places where the physical address of _end is needed. x86 avoids this problem by
doing its bounds check based on the entire possible image space which is well
beyond where _end would end up.

There are a few dependencies outside of arm64, so I don't know if
it will be easier for this to eventually go through arm64 or the mm tree.

Thanks,
Laura




Laura Abbott (6):
  lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
  mm/cma: Cleanup highmem check
  arm64: Move some macros under #ifndef __ASSEMBLY__
  arm64: Add cast for virt_to_pfn
  arm64: Use __pa_symbol for _end
  arm64: Add support for CONFIG_DEBUG_VIRTUAL

 arch/arm64/Kconfig              |  1 +
 arch/arm64/include/asm/memory.h | 50 ++++++++++++++++++++++++-----------------
 arch/arm64/mm/Makefile          |  2 ++
 arch/arm64/mm/init.c            |  4 ++--
 arch/arm64/mm/physaddr.c        | 34 ++++++++++++++++++++++++++++
 arch/x86/Kconfig                |  1 +
 lib/Kconfig.debug               |  5 ++++-
 mm/cma.c                        | 15 +++++--------
 8 files changed, 79 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm64/mm/physaddr.c

-- 
2.10.1

^ permalink raw reply
* Use of GICv3/ITS with PCIe host-generic driver - resizing ITS MAPD?
From: Marc Zyngier @ 2016-11-02 20:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CY1PR07MB2506C9B4133B1CE185AD0260D8A00@CY1PR07MB2506.namprd07.prod.outlook.com>

On Wed, Nov 02 2016 at 09:36:14 AM, Alan Douglas <adouglas@cadence.com> wrote:
> Hi Marc,
>
>> > When setting up bus 0, the ITS device is created, and
>> > its_build_map_cmd() sets the size of the ITS MAPD based on the number
>> > of interrupts claimed by bus 0.  When subsequent buses are enumerated,
>> > the ITS device will be reused, however we do not increase the number
>> > of supported interrupts to allow for the additional interrupts claimed
>> > by the additional devices being enumerated.  (This can be seen in
>> > its_msi_prepare(), which is called for each device which has MSI/MSI-X
>> > enabled, and will reuse an existing ITS. )
>> 
>> Am I right in understanding that all the PCIe devices in your system end-up
>> aliasing to the same RequesterID? If so, that's a major issue. The ITS is
>> designed so that each device exposes its *own* RID, and have its own
>> Interrupt Translation Table (ITT).
>> 
>> In your case, you seem to first discover the root port, which is not upstream
>> of anything, so it doesn't alias with anything at that point. We allocate the
>> corresponding ITT, and it's all fine. Until we start probing the rest, and ugly
>> things happen.
>> 
> Yes, your understanding is correct.  I will dig into this a bit
> further to see what is wrong then send an update.  I suspect my DTS
> msi mapping.

Right. That would explain a lot of what you're seeing. In general, and
unless you have some funky remapping going on, you're better off having
a very straightforward msi-map property in your RC node (such as example
#1 in Documentation/devicetree/bindings/pci/pci-msi.txt).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

^ permalink raw reply
* [PATCH 1/1] KVM: ARM64: Fix the issues when PMCCFILTR is configured
From: Wei Huang @ 2016-11-02 20:55 UTC (permalink / raw)
  To: linux-arm-kernel

KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bit of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, KVM
shouldn't return immediately, but instead it needs to check further if
select_idx is ARMV8_PMU_CYCLE_IDX.

Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
directly to attr.config. Istead it shoudl convert the request to
perf_event of type 0x11 (i.e. the "cpu cycle" event type).

Signed-off-by: Wei Huang <wei@redhat.com>
---
 virt/kvm/arm/pmu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..13cc812 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
 
 	/* Software increment event does't need to be backed by a perf event */
-	if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+	if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR &&
+	    select_idx != ARMV8_PMU_CYCLE_IDX)
 		return;
 
 	memset(&attr, 0, sizeof(struct perf_event_attr));
@@ -391,7 +392,7 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
 	attr.exclude_hv = 1; /* Don't count EL2 events */
 	attr.exclude_host = 1; /* Don't count host events */
-	attr.config = eventsel;
+	attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ? 0x011 : eventsel;
 
 	counter = kvm_pmu_get_counter_value(vcpu, select_idx);
 	/* The initial sample period (overflow count) of an event. */
-- 
2.7.4

^ permalink raw reply related
* [RFC PATCH v2 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-11-02 20:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161102165329.GB10528@bhelgaas-glaptop.roam.corp.google.com>

On Wed, Nov 2, 2016 at 9:53 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> Hi Duc,
>
> On Tue, Oct 25, 2016 at 06:24:32PM -0700, Duc Dang wrote:
> > PCIe controllers in X-Gene SoCs is not ECAM compliant: software
> > needs to configure additional controller's register to address
> > device at bus:dev:function.
> >
> > This patch depends on "ECAM quirks handling for ARM64 platforms"
> > series (http://www.spinics.net/lists/arm-kernel/msg530692.html,
> > the series was also modified by Bjorn) to address the limitation
> > above for X-Gene PCIe controller.
> >
> > The quirk will only be applied for X-Gene PCIe MCFG table with
> > OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>
> The quirks here contain some hard-coded address space consumed by
> ECAM.  The ECAM quirk itself is not a generic description of that
> address space in the sense of a PCI BAR or an ACPI _CRS method, i.e.,
> the quirk description is not enough to keep other parts of the kernel
> from treating the address space as "available".

Your concern here is the controller register region that I declared as
hard-coded array of resource (xgene_vx_csr_res) is not owned by the
root bridge? So unlike DT case where kernel discovers and knows
exactly who owns this resource (and we can also use
platform_get_resource to get the resource); in ACPI case with ECAM
quirk, kernel knows who requests this resource but does not know who
owns it? Do I understand correctly?

>
> Can you add a note here in the changelog about how you are describing
> this space generically?  The standard solution is a PNP0C02 device
> with _CRS that describes it.
>
> It would be ideal if you could open a bugzilla at bugzilla.kernel.org
> and attach there a dmesg log, /proc/iomem contents, and DSDT.  This
> would show both the generic PNP0C02 piece and the ECAM quirk piece.

We don't have PNP0C02 device in our ACPI Table. Do you want me add a
PNP0C02 device into our firmware and check/document the difference in
/proc/iomem output?
>
> BTW, I did refresh and re-push the pci/ecam-v6 branch where I'm
> collecting this stuff, so if you want to rebase your patch on top of
> that and test it, that would be great.

Thanks, I will definitely do that.
>
> > Signed-off-by: Duc Dang <dhdang@apm.com>
> > ---
> > v2 changes:
> >       1. Get rid of pci-xgene-ecam.c file and fold quirk code into pci-xgene.c
> >       2. Redefine fixup array for X-Gene
> >       3. Use devm_ioremap_resource to map csr_base
> >
> >  drivers/acpi/pci_mcfg.c      |  30 ++++++++
> >  drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-
> >  include/linux/pci-ecam.h     |   5 ++
> >  3 files changed, 197 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index bb2c508..9dfc937 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -96,6 +96,36 @@ struct mcfg_fixup {
> >       THUNDER_ECAM_MCFG(2, 12),
> >       THUNDER_ECAM_MCFG(2, 13),
> >  #endif
> > +#ifdef CONFIG_PCI_XGENE
> > +#define XGENE_V1_ECAM_MCFG(rev, seg) \
> > +     {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
> > +             &xgene_v1_pcie_ecam_ops }
> > +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
> > +     {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
> > +             &xgene_v2_1_pcie_ecam_ops }
> > +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
> > +     {"APM   ", "XGENE   ", rev, seg, MCFG_BUS_ANY, \
> > +             &xgene_v2_2_pcie_ecam_ops }
> > +
> > +     /* X-Gene SoC with v1 PCIe controller */
> > +     XGENE_V1_ECAM_MCFG(1, 0),
> > +     XGENE_V1_ECAM_MCFG(1, 1),
> > +     XGENE_V1_ECAM_MCFG(1, 2),
> > +     XGENE_V1_ECAM_MCFG(1, 3),
> > +     XGENE_V1_ECAM_MCFG(1, 4),
> > +     XGENE_V1_ECAM_MCFG(2, 0),
> > +     XGENE_V1_ECAM_MCFG(2, 1),
> > +     XGENE_V1_ECAM_MCFG(2, 2),
> > +     XGENE_V1_ECAM_MCFG(2, 3),
> > +     XGENE_V1_ECAM_MCFG(2, 4),
> > +     /* X-Gene SoC with v2.1 PCIe controller */
> > +     XGENE_V2_1_ECAM_MCFG(3, 0),
> > +     XGENE_V2_1_ECAM_MCFG(3, 1),
> > +     /* X-Gene SoC with v2.2 PCIe controller */
> > +     XGENE_V2_2_ECAM_MCFG(4, 0),
> > +     XGENE_V2_2_ECAM_MCFG(4, 1),
> > +     XGENE_V2_2_ECAM_MCFG(4, 2),
> > +#endif
> >  };
> >
> >  static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> > diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> > index 1de23d7..d6aa642 100644
> > --- a/drivers/pci/host/pci-xgene.c
> > +++ b/drivers/pci/host/pci-xgene.c
> > @@ -27,6 +27,8 @@
> >  #include <linux/of_irq.h>
> >  #include <linux/of_pci.h>
> >  #include <linux/pci.h>
> > +#include <linux/pci-acpi.h>
> > +#include <linux/pci-ecam.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/slab.h>
> >
> > @@ -64,6 +66,7 @@
> >  /* PCIe IP version */
> >  #define XGENE_PCIE_IP_VER_UNKN               0
> >  #define XGENE_PCIE_IP_VER_1          1
> > +#define XGENE_PCIE_IP_VER_2          2
> >
> >  struct xgene_pcie_port {
> >       struct device_node      *node;
> > @@ -97,7 +100,15 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
> >   */
> >  static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> >  {
> > -     struct xgene_pcie_port *port = bus->sysdata;
> > +     struct pci_config_window *cfg;
> > +     struct xgene_pcie_port *port;
> > +
> > +     if (acpi_disabled)
> > +             port = bus->sysdata;
> > +     else {
> > +             cfg = bus->sysdata;
> > +             port = cfg->priv;
> > +     }
> >
> >       if (bus->number >= (bus->primary + 1))
> >               return port->cfg_base + AXI_EP_CFG_ACCESS;
> > @@ -111,10 +122,18 @@ static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> >   */
> >  static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
> >  {
> > -     struct xgene_pcie_port *port = bus->sysdata;
> > +     struct pci_config_window *cfg;
> > +     struct xgene_pcie_port *port;
> >       unsigned int b, d, f;
> >       u32 rtdid_val = 0;
> >
> > +     if (acpi_disabled)
> > +             port = bus->sysdata;
> > +     else {
> > +             cfg = bus->sysdata;
> > +             port = cfg->priv;
> > +     }
> > +
> >       b = bus->number;
> >       d = PCI_SLOT(devfn);
> >       f = PCI_FUNC(devfn);
> > @@ -158,7 +177,15 @@ static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
> >  static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> >                                   int where, int size, u32 *val)
> >  {
> > -     struct xgene_pcie_port *port = bus->sysdata;
> > +     struct pci_config_window *cfg;
> > +     struct xgene_pcie_port *port;
> > +
> > +     if (acpi_disabled)
> > +             port = bus->sysdata;
> > +     else {
> > +             cfg = bus->sysdata;
> > +             port = cfg->priv;
> > +     }
> >
> >       if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
> >           PCIBIOS_SUCCESSFUL)
> > @@ -189,6 +216,138 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> >       .write = pci_generic_config_write32,
> >  };
> >
> > +#ifdef CONFIG_ACPI
> > +static struct resource xgene_v1_csr_res[] = {
> > +     [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > +     [1] = DEFINE_RES_MEM(0x1f2c0000UL, SZ_64K),
> > +     [2] = DEFINE_RES_MEM(0x1f2d0000UL, SZ_64K),
> > +     [3] = DEFINE_RES_MEM(0x1f500000UL, SZ_64K),
> > +     [4] = DEFINE_RES_MEM(0x1f510000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > +     struct acpi_device *adev = to_acpi_device(cfg->parent);
> > +     struct acpi_pci_root *root = acpi_driver_data(adev);
> > +     struct device *dev = cfg->parent;
> > +     struct xgene_pcie_port *port;
> > +     struct resource *csr;
> > +
> > +     port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > +     if (!port)
> > +             return -ENOMEM;
> > +
> > +     csr = &xgene_v1_csr_res[root->segment];
> > +     port->csr_base = devm_ioremap_resource(dev, csr);
> > +     if (IS_ERR(port->csr_base)) {
> > +             kfree(port);
> > +             return -ENOMEM;
> > +     }
> > +
> > +     port->cfg_base = cfg->win;
> > +     port->version = XGENE_PCIE_IP_VER_1;
> > +
> > +     cfg->priv = port;
> > +
> > +     return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v1_pcie_ecam_ops = {
> > +     .bus_shift      = 16,
> > +     .init           = xgene_v1_pcie_ecam_init,
> > +     .pci_ops        = {
> > +             .map_bus        = xgene_pcie_map_bus,
> > +             .read           = xgene_pcie_config_read32,
> > +             .write          = pci_generic_config_write,
> > +     }
> > +};
> > +
> > +static struct resource xgene_v2_1_csr_res[] = {
> > +     [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > +     [1] = DEFINE_RES_MEM(0x1f2c0000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v2_1_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > +     struct acpi_device *adev = to_acpi_device(cfg->parent);
> > +     struct acpi_pci_root *root = acpi_driver_data(adev);
> > +     struct device *dev = cfg->parent;
> > +     struct xgene_pcie_port *port;
> > +     struct resource *csr;
> > +
> > +     port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > +     if (!port)
> > +             return -ENOMEM;
> > +
> > +     csr = &xgene_v2_1_csr_res[root->segment];
> > +     port->csr_base = devm_ioremap_resource(dev, csr);
> > +     if (IS_ERR(port->csr_base)) {
> > +             kfree(port);
> > +             return -ENOMEM;
> > +     }
> > +
> > +     port->cfg_base = cfg->win;
> > +     port->version = XGENE_PCIE_IP_VER_2;
> > +
> > +     cfg->priv = port;
> > +
> > +     return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops = {
> > +     .bus_shift      = 16,
> > +     .init           = xgene_v2_1_pcie_ecam_init,
> > +     .pci_ops        = {
> > +             .map_bus        = xgene_pcie_map_bus,
> > +             .read           = xgene_pcie_config_read32,
> > +             .write          = pci_generic_config_write,
> > +     }
> > +};
> > +
> > +static struct resource xgene_v2_2_csr_res[] = {
> > +     [0] = DEFINE_RES_MEM(0x1f2b0000UL, SZ_64K),
> > +     [1] = DEFINE_RES_MEM(0x1f500000UL, SZ_64K),
> > +     [2] = DEFINE_RES_MEM(0x1f2d0000UL, SZ_64K),
> > +};
> > +
> > +static int xgene_v2_2_pcie_ecam_init(struct pci_config_window *cfg)
> > +{
> > +     struct acpi_device *adev = to_acpi_device(cfg->parent);
> > +     struct acpi_pci_root *root = acpi_driver_data(adev);
> > +     struct device *dev = cfg->parent;
> > +     struct xgene_pcie_port *port;
> > +     struct resource *csr;
> > +
> > +     port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > +     if (!port)
> > +             return -ENOMEM;
> > +
> > +     csr = &xgene_v2_2_csr_res[root->segment];
> > +     port->csr_base = devm_ioremap_resource(dev, csr);
> > +     if (IS_ERR(port->csr_base)) {
> > +             kfree(port);
> > +             return -ENOMEM;
> > +     }
> > +
> > +     port->cfg_base = cfg->win;
> > +     port->version = XGENE_PCIE_IP_VER_2;
> > +
> > +     cfg->priv = port;
> > +
> > +     return 0;
> > +}
> > +
> > +struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops = {
> > +     .bus_shift      = 16,
> > +     .init           = xgene_v2_2_pcie_ecam_init,
> > +     .pci_ops        = {
> > +             .map_bus        = xgene_pcie_map_bus,
> > +             .read           = xgene_pcie_config_read32,
> > +             .write          = pci_generic_config_write,
> > +     }
> > +};
> > +#endif
> > +
> >  static u64 xgene_pcie_set_ib_mask(struct xgene_pcie_port *port, u32 addr,
> >                                 u32 flags, u64 size)
> >  {
> > diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> > index 35f0e81..40da3e7 100644
> > --- a/include/linux/pci-ecam.h
> > +++ b/include/linux/pci-ecam.h
> > @@ -65,6 +65,11 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
> >  #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
> >  extern struct pci_ecam_ops pci_thunder_ecam_ops;
> >  #endif
> > +#ifdef CONFIG_PCI_XGENE
> > +extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops;
> > +extern struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops;
> > +extern struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops;
> > +#endif
> >
> >  #ifdef CONFIG_PCI_HOST_GENERIC
> >  /* for DT-based PCI controllers that support ECAM */
> > --
> > 1.9.1
> >
Regards,
Duc Dang.

^ permalink raw reply
* [RFC][PATCH] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-02 20:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8GjehaCrKv2CQbPRg_r6mK3vtFnsuHAJyDkS2n8STEkA@mail.gmail.com>

On 10/29/2016 02:39 AM, Ard Biesheuvel wrote:
> On 28 October 2016 at 23:07, Laura Abbott <labbott@redhat.com> wrote:
>>>>> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>>>>> new file mode 100644
>>>>> index 0000000..6c271e2
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/mm/physaddr.c
>>>>> @@ -0,0 +1,17 @@
>>>>> +#include <linux/mm.h>
>>>>> +
>>>>> +#include <asm/memory.h>
>>>>> +
>>>>> +unsigned long __virt_to_phys(unsigned long x)
>>>>> +{
>>>>> +    phys_addr_t __x = (phys_addr_t)x;
>>>>> +
>>>>> +    if (__x & BIT(VA_BITS - 1)) {
>>>>> +        /* The bit check ensures this is the right range */
>>>>> +        return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>>>>> +    } else {
>>>>> +        VIRTUAL_BUG_ON(x < kimage_vaddr || x > (unsigned long)_end);
>>>>
>>>>
>>>> IIUC, in (3) you were asking if the last check should be '>' or '>='?
>>>>
>>>> To match high_memory, I suspect the latter, as _end doesn't fall within
>>>> the mapped virtual address space.
>>>>
>>>
>>> I was actually concerned about if _end would be correct with KASLR.
>>> Ard confirmed that it gets fixed up to be correct. I'll change the
>>> check to check for >=.
>>>
>>
>> While testing this, I found two places with __pa(_end) to get bounds,
>> one in arm64 code and one in memblock code. x86 gets away with this
>> because memblock is actually __pa_symbol and x86 does image placement
>> different and can check against the maximum image size. I think
>> including _end in __pa_symbol but excluding it from the generic
>> __virt_to_phys makes sense. It's a bit nicer than doing _end - 1 +
>> 1 everywhere.
>>
>
> Could we redefine __pa_symbol() under CONFIG_DEBUG_VIRTUAL to
> something that checks (x >= kimage_vaddr + TEXT_OFFSET || x <=
> (unsigned long)_end), i.e., reject linear virtual addresses? (Assuming
> my understanding of the meaning of __pa_symbol() is correct)
>

Yes, that's going to be my approach. I originally prototyped this
with just x >= kimage_vaddr but kimage_vaddr + TEXT_OFFSET is
a tighter bound.

Thanks,
Laura

^ permalink raw reply
* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Sergei Shtylyov @ 2016-11-02 19:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161102172456.GA11881@broadcom.com>

On 11/02/2016 08:24 PM, Jon Mason wrote:

>>> Clean-up the documentation to the bgmac-amac driver, per suggestion by
>>> Rob Herring, and add details for NS2 support.
>>>
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>> Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++++++++++-----
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> index ba5ecc1..2fefa1a 100644
>>> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
>>> @@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
>>> -------------------------------------------------------------
>>>
>>> Required properties:
>>> - - compatible:	"brcm,amac" or "brcm,nsp-amac"
>>> - - reg:		Address and length of the GMAC registers,
>>> -		Address and length of the GMAC IDM registers
>>> - - reg-names:	Names of the registers.  Must have both "amac_base" and
>>> -		"idm_base"
>>> + - compatible:	"brcm,amac"
>>> +		"brcm,nsp-amac"
>>> +		"brcm,ns2-amac"
>>> + - reg:		Address and length of the register set for the device. It
>>> +		contains the information of registers in the same order as
>>> +		described by reg-names
>>> + - reg-names:	Names of the registers.
>>> +		"amac_base":	Address and length of the GMAC registers
>>> +		"idm_base":	Address and length of the GMAC IDM registers
>>> +		"nicpm_base":	Address and length of the NIC Port Manager
>>> +				registers (required for Northstar2)
>>
>>   Why this "_base" suffix? It looks redundant...
>
> Yes.  Rob Herring pointed out the same thing.  It is ugly, but follows
> the existing binding.

    Sorry, I didn't realize you're reformatting the existing bindings while 
adding some new text...

> Thanks,
> Jon

MBR, Sergei

^ permalink raw reply
* [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Nipun Gupta @ 2016-11-02 19:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <d1c89f6f-1b7a-6180-a376-27505d3b6c9f@arm.com>


Hi Robin,

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Wednesday, November 02, 2016 16:51
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com; linux-arm-
> kernel at lists.infradead.org; iommu at lists.linux-foundation.org
> Cc: Stuart Yoder <stuart.yoder@nxp.com>
> Subject: Re: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable
> caching of bypass entries
> 
> Hi Nipun,
> 
> On 02/11/16 13:35, Nipun Gupta wrote:
> > The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR)
> > provides an option to enable the updation of TLB in case of bypass
> > transactions due to no stream match in the stream match table. This
> > reduces the latencies of the subsequent transactions with the same stream-id
> which bypasses the SMMU.
> > This provides a significant performance benefit for certain networking
> > workloads.
> 
> ...at the cost of increased TLB contention against other workloads.
> However, in the general case we'd expect the system to be fully described, so if
> there aren't any unmatched Stream IDs there hopefully shouldn't be an impact
> to leaving this switched on. I'd be interested to see some actual performance
> numbers, though - you already know my opinion about unsubstantiated quotes
> from the MMU-500 TRM.

With this change we have seen substantial performance improvement of ~9-10%
with DPDK l3fwd application (http://dpdk.org/doc/guides/sample_app_ug/l3_forward.html)
on NXP's LS2088a platform (single core as well as multi-core). Also, with ODP reflector application
(loopback mode - NXP in-house) we have seen 5% improvement in performance on
LS1088 platform.

W.r.t. the read latencies, they are reduced to avg. ~50 platform cycles from avg. ~140
platform cycles per memory read transactions which follow this bypass path (on LS2088
with DPDK l3fwd application).

(Apologies, I cannot share the DPDK/ODP exact performance numbers on the mailing list).

> 
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >  drivers/iommu/arm-smmu.c | 21 +++++++++++++++------
> >  1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> > ce2a9d4..7010a5c 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
> >
> >  #define ARM_MMU500_ACTLR_CPRE		(1 << 1)
> >
> > +#define ACR_SMTNMB_TLBEN		(1 << 8)
> 
> ACR is entirely implementation-defined, so there are no generic field names.
> Please follow the naming convention handily demonstrated in the subsequent
> context line.
> 
> >  #define ARM_MMU500_ACR_CACHE_LOCK	(1 << 26)
> 
> Actually, can we also please keep these in descending order of bit position like
> everything else?
> 
> >  #define CB_PAR_F			(1 << 0)
> > @@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct
> arm_smmu_device *smmu)
> >  	for (i = 0; i < smmu->num_mapping_groups; ++i)
> >  		arm_smmu_write_sme(smmu, i);
> >
> > +	/* Get the major rev required for configuring ACR */
> 
> That comment is nonsense.
> 
> > +	reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> > +	major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> > +
> >  	/*
> >  	 * Before clearing ARM_MMU500_ACTLR_CPRE, need to
> >  	 * clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
> >  	 * bit is only present in MMU-500r2 onwards.
> >  	 */
> > -	reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> > -	major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> > -	if ((smmu->model == ARM_MMU500) && (major >= 2)) {
> > -		reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> > +	reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> > +	if ((smmu->model == ARM_MMU500) && (major >= 2))
> >  		reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> > -		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> > -	}
> > +
> > +	/*
> > +	 * Set the SMTNMB_TLBEN in ACR so that the transactions which
> > +	 * bypass with SMMU due to no stream match found in the SMR table
> > +	 * are updated in the TLB's.
> 
> Or simply, e.g. "Allow unmatched Stream IDs to allocate bypass TLB entries for
> reduced latency". It's already clear from the code what bit's being set where, we
> only need to remember *why*.
> 
> > +	 */
> > +	reg |= ACR_SMTNMB_TLBEN;
> > +	writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> 
> Are you sure it's perfectly fine to set that implementation-defined bit on any
> SMMU implementation other than the two-and-a-half ARM Ltd. ones which
> happen to share the same meaning? I'm certainly not.
> 
> The correct flow would be something like this:
> 
> 	if (smmu->model == ARM_MMU500) {
> 		reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
> 		major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
> 		reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
> 		if (major >= 2)
> 	  		reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
> 		reg |= ACR_SMTNMB_TLBEN;
> 		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
> 	}
> 
> The shape of the current code avoids an extra level of indentation, but once you
> have to have the nested conditional anyway, it might as well all be predicated
> appropriately.
> 

Thank you for providing the useful comments. I would incorporate them all in next version :).

Regards,
Nipun

> Robin.
> 
> >  	/* Make sure all context banks are disabled and clear CB_FSR  */
> >  	for (i = 0; i < smmu->num_context_banks; ++i) {
> >

^ permalink raw reply
* [PATCH v1] ARM:dmaengine:sun6i:fix the uninitialized value for v_lli
From: Maxime Ripard @ 2016-11-02 18:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161102053112.GA8109@arx-xi>

On Wed, Nov 02, 2016 at 01:31:12PM +0800, Axl-zhang wrote:
> dma_pool_alloc does not initialize the value of the newly allocated
> block for the v_lli, and the uninitilize value make the tests failed
> which is on pine64 with dmatest.
> we can fix it just change the "|=" to "=" for the v_lli->cfg.
> 
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/9194dd7d/attachment.sig>

^ permalink raw reply
* [PATCH] drm/sun4i: Add a few formats
From: Maxime Ripard @ 2016-11-02 18:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGb2v65SqkU-7W4+JnnnF+RzJO_0-TRq+DykJRf9og1wGc4azQ@mail.gmail.com>

On Sat, Oct 29, 2016 at 06:25:46PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 27, 2016 at 10:35 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Oct 25, 2016 at 08:42:26AM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Oct 24, 2016 at 10:40 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > Hi,
> >> >
> >> > On Fri, Oct 21, 2016 at 11:15:32AM +0800, Chen-Yu Tsai wrote:
> >> >> On Tue, Oct 18, 2016 at 4:46 PM, Maxime Ripard
> >> >> <maxime.ripard@free-electrons.com> wrote:
> >> >> > The planes can do more than what was previously exposed. Add support for
> >> >> > them.
> >> >> >
> >> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> >> > ---
> >> >> >  drivers/gpu/drm/sun4i/sun4i_backend.c | 20 ++++++++++++++++++++
> >> >> >  drivers/gpu/drm/sun4i/sun4i_layer.c   |  6 ++++++
> >> >> >  2 files changed, 26 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > index afb7ddf660ef..b184a476a480 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> > @@ -96,6 +96,22 @@ static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
> >> >> >                 *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB8888;
> >> >> >                 break;
> >> >> >
> >> >> > +       case DRM_FORMAT_ARGB4444:
> >> >> > +               *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB4444;
> >> >> > +               break;
> >> >> > +
> >> >> > +       case DRM_FORMAT_ARGB1555:
> >> >> > +               *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB1555;
> >> >> > +               break;
> >> >> > +
> >> >> > +       case DRM_FORMAT_RGBA5551:
> >> >> > +               *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA5551;
> >> >> > +               break;
> >> >> > +
> >> >> > +       case DRM_FORMAT_RGBA4444:
> >> >> > +               *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA4444;
> >> >>
> >> >> The A20 manual only lists ARGB4444, not RGBA4444. There might be
> >> >> some discrepancy here. We can deal with them
> >> >
> >> > Hmm, yes, that's weird. But I guess this would be part of porting it
> >> > to the A20.
> >> >
> >> >> Also there are some more formats missing from the list, could you
> >> >> add them as well?
> >> >
> >> > Which one do you refer to?
> >>
> >> RGB556 and RGB655.
> >
> > These formats are not supported by Linux yet though.
> 
> I see. Sorry for the noise.
> 
> Acked-by: Chen-Yu Tsai <wens@csie.org>

Applied with a more verbose commit log.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/5e496141/attachment.sig>

^ permalink raw reply
* [PATCH v5 3/7] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-02 18:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-4-git-send-email-jon.mason@broadcom.com>

On Wed, Nov 02, 2016 at 01:08:04PM -0400, Jon Mason wrote:
> The BCM54810 PHY requires some semi-unique configuration, which results
> in some additional configuration in addition to the standard config.
> Also, some users of the BCM54810 require the PHY lanes to be swapped.
> Since there is no way to detect this, add a device tree query to see if
> it is applicable.
> 
> Inspired-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: sun8i: Add SPI controller node in H3
From: Maxime Ripard @ 2016-11-02 18:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161028065412.23008-3-woogyom.kim@gmail.com>

1;4600;0c
On Fri, Oct 28, 2016 at 03:54:10PM +0900, Milo Kim wrote:
> H3 SPI subsystem is almost same as A31 SPI except buffer size, so those
> DT properties are reusable.
> 
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>

Applied both, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/ea817932/attachment.sig>

^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-11-02 18:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <edf05ad5-924d-87d8-fd8d-57e8e0a72052@st.com>

On Wed, Nov 2, 2016 at 2:14 PM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
>
>
> On 11/02/2016 05:07 PM, Bruno Herrera wrote:
>>
>> Hi
>>
>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>>>
>>> Hi
>>>
>>> On 10/31/2016 07:58 PM, Rados?aw Pietrzyk wrote:
>>>>
>>>>
>>>> I think wlcore driver searches dma-ranges in its parent that's why sdio
>>>> node needs it.
>>>
>>>
>>>
>>> Yes I agree. In this case it is needed as you have subnode in sdio node.
>>> So IMO empty dma-ranges could be removed from ethernet and usb node, but
>>> kept in future sdio subnode.
>>
>>
>> Now it is clear.
>
> Nice. Can I add your tested-by ?
>
Sure

>>
>>>
>>> Bruno,
>>> Do you plan to push sdio support ?
>>
>>
>> Yes I do, but I'm not sure how long it will take. The I had to
>> change(and hack) the mmci code because I could not get the ID from
>> STM32 SDIO IP.
>> My current WIP is at @
>>
>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>> I know Andrea Merello is also working on that (and he probably has a
>> more complete patch).
>>
>>>
>>>
>>>
>>>>
>>>> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>>>> <mailto:bruherrera@gmail.com>>:
>>>>
>>>>     On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
>>>>     <radoslaw.pietrzyk at gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
>>>>     wrote:
>>>>     > This is weird because dma ddresses are recalculated using parent's
>>>>     > dma-ranges property and soc already has it so there should be
>>>> absolutely no
>>>>     > problem.
>>>>
>>>>     These are my DTS and DTSI file.
>>>>     >
>>>>     > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>>>>     <mailto:bruherrera@gmail.com>>:
>>>>     >>
>>>>     >> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
>>>>     >> <radoslaw.pietrzyk@gmail.com
>>>>     <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
>>>>     >> > Have you defined your sdio node within soc node ?
>>>>     >>
>>>>     >> It is in the SOC node of the DSTI file.
>>>>     >>
>>>>     >> >
>>>>     >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
>>>>     <mailto:bruherrera@gmail.com>>:
>>>>     >> >>
>>>>     >> >> Hi Alex,
>>>>     >> >>
>>>>     >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>>>>     >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>>>> wrote:
>>>>     >> >> > Hi Bruno,
>>>>     >> >> >
>>>>     >> >> >
>>>>     >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>>>>     >> >> >>
>>>>     >> >> >> Hi Alex,
>>>>     >> >> >>
>>>>     >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>>>>     >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>>>>     wrote:
>>>>     >> >> >>>
>>>>     >> >> >>> Hi Bruno,
>>>>     >> >> >>>
>>>>     >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>> Hi Alexandre,
>>>>     >> >> >>>>
>>>>     >> >> >>>>>
>>>>     >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>>>>     start address
>>>>     >> >> >>>>> remapping
>>>>     >> >> >>>>> (to @0) to boost performances. A DMA translation through
>>>>     >> >> >>>>> "dma-ranges"
>>>>     >> >> >>>>> property was needed for other masters than the M4 CPU.
>>>>     >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>>>>     this DMA
>>>>     >> >> >>>>> translation.
>>>>     >> >> >>>>> This patches moves this DMA translation definition from
>>>>     stm32f429
>>>>     >> >> >>>>> soc
>>>>     >> >> >>>>> file
>>>>     >> >> >>>>> to board files.
>>>>     >> >> >>>>>
>>>>     >> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com
>>>>     <mailto:alexandre.torgue@st.com>>
>>>>
>>>>     >> >> >>>>>
>>>>     >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>>> index 13c7cd2..a763c15 100644
>>>>     >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>>> @@ -82,6 +82,10 @@
>>>>     >> >> >>>>>                 };
>>>>     >> >> >>>>>         };
>>>>     >> >> >>>>>
>>>>     >> >> >>>>> +       soc {
>>>>     >> >> >>>>> +               dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>>     >> >> >>>>> +       };
>>>>     >> >> >>>>> +
>>>>     >> >> >>>>>         usbotg_hs_phy: usbphy {
>>>>     >> >> >>>>>                 #phy-cells = <0>;
>>>>     >> >> >>>>>                 compatible = "usb-nop-xceiv";
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>> Shouldn't also the peripheral dma-ranges property move to
>>>>     board
>>>>     >> >> >>>> specific
>>>>     >> >> >>>> too?
>>>>     >> >> >>>> I  had this patch for while but I didn't had the time to
>>>>     submit:
>>>>     >> >> >>>
>>>>     >> >> >>>
>>>>     >> >> >>>
>>>>     >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>>>>     ysterday on
>>>>     >> >> >>> IIRC,
>>>>     >> >> >>> empty dma-ranges is not needed. Can you test on your side
>>>> by
>>>>     >> >> >>> removing
>>>>     >> >> >>> dma-ranges in usb node please ?
>>>>     >> >> >>
>>>>     >> >> >> Unfortunately will take a time for me to set up this
>>>>     environment on
>>>>     >> >> >> the STM32F4-EVAL board.
>>>>     >> >> >> And on the discovery boards we dont have this scenario.
>>>>     That was the
>>>>     >> >> >> main reason I did not submit the patch right away.
>>>>     >> >> >> My conclusion and I might be wrong but is based on the my
>>>>     tests with
>>>>     >> >> >> SDIO device at STM32F469I-DISCO board.
>>>>     >> >> >>
>>>>     >> >> >> I started this issue as discussion at ST Forum but Maxime
>>>>     gave me
>>>>     >> >> >> the
>>>>     >> >> >> hint.
>>>>     >> >> >>
>>>>     >> >> >>
>>>>     >> >> >>
>>>>     >> >> >>
>>>>     >> >> >>
>>>>
>>>>
>>>> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=44
>>>>
>>>>
>>>> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=44>
>>>>     >> >> >>
>>>>     >> >> >>> I will push a v2 by removing empty dma-ranges if tests are
>>>>     ok in
>>>>     >> >> >>> your
>>>>     >> >> >>> side.
>>>>     >> >> >>
>>>>     >> >> >>
>>>>     >> >> >> From my understating/conclusion is: when empty
>>>>     property(dma-ranges)
>>>>     >> >> >> is
>>>>     >> >> >> the device node, the mapping will be taken in consideration
>>>>     when
>>>>     >> >> >> using
>>>>     >> >> >> DMA otherwise the mapping is ignored.
>>>>     >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>>>>     >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>>>>     question
>>>>     >> >> >> so
>>>>     >> >> >> I suppose it can work without the property.
>>>>     >> >> >
>>>>     >> >> >
>>>>     >> >> > For sure translation has to be done but I'm not sure that an
>>>>     empty
>>>>     >> >> > "dma-ranges" is needed in device node to activate it. For
>>>>     Ethernet
>>>>     >> >> > empty
>>>>     >> >> > "dma-ranges" is not needed. I will try with usb.
>>>>     >> >>
>>>>     >> >> In the case of SDIO it is needed. As example this is my
>>>>     working SDIO
>>>>     >> >> node:
>>>>     >> >>
>>>>     >> >> sdio: sdio at 40012c00 {
>>>>     >> >> compatible = "arm,pl18x", "arm,primecell";
>>>>     >> >> arm,primecell-periphid = <0x00480181>;
>>>>     >> >> reg = <0x40012c00 0x400>;
>>>>     >> >> dmas =  <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>>>>     >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>>>>     >> >> dma-names = "rx", "tx";
>>>>     >> >> clocks = <&rcc 0 171>;
>>>>     >> >> clock-names = "apb_pclk";
>>>>     >> >> interrupts = <49>;
>>>>     >> >> status = "disabled";
>>>>     >> >> };
>>>>     >> >>
>>>>     >> >> &sdio {
>>>>     >> >> status = "okay";
>>>>     >> >> vmmc-supply = <&wlan_en>;
>>>>     >> >> bus-width = <4>;
>>>>     >> >> max-frequency = <24000000>;
>>>>     >> >> pinctrl-names = "default";
>>>>     >> >> pinctrl-0 = <&sdio_pins>;
>>>>     >> >> ti,non-removable;
>>>>     >> >> ti,needs-special-hs-handling;
>>>>     >> >> dma-ranges;
>>>>     >> >> cap-power-off-card;
>>>>     >> >> keep-power-in-suspend;
>>>>     >> >>
>>>>     >> >> #address-cells = <1>;
>>>>     >> >> #size-cells = <0>;
>>>>     >> >> wlcore: wlcore at 0 {
>>>>     >> >> compatible = "ti,wl1835";
>>>>     >> >> reg = <2>;
>>>>     >> >> interrupt-parent = <&gpioa>;
>>>>     >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>>>>     >> >> };
>>>>     >> >> };
>>>>     >> >>
>>>>     >> >> >
>>>>     >> >> > alex
>>>>     >> >> >
>>>>     >> >> >
>>>>     >> >> >>
>>>>     >> >> >>>
>>>>     >> >> >>> Thanks in advance
>>>>     >> >> >>> Alex
>>>>     >> >> >>>
>>>>     >> >> >>>
>>>>     >> >> >>>>
>>>>     >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
>>>>     <mailto:bruherrera@gmail.com>>
>>>>
>>>>     >> >> >>>> Date:   Sun Oct 16 14:50:00 2016 -0200
>>>>     >> >> >>>>
>>>>     >> >> >>>>     ARM: DT: STM32: Use dma-ranges property per board not
>>>>     at dtsi
>>>>     >> >> >>>> file
>>>>     >> >> >>>>
>>>>     >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>> index 6bfc595..2a22a82 100644
>>>>     >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>>>>     >> >> >>>> @@ -52,6 +52,10 @@
>>>>     >> >> >>>>         model = "STMicroelectronics STM32429i-EVAL
>>>> board";
>>>>     >> >> >>>>         compatible = "st,stm32429i-eval", "st,stm32f429";
>>>>     >> >> >>>>
>>>>     >> >> >>>> +       soc {
>>>>     >> >> >>>> +               dma-ranges = <0xC0000000 0x0 0x10000000>;
>>>>     >> >> >>>> +       };
>>>>     >> >> >>>> +
>>>>     >> >> >>>>         chosen {
>>>>     >> >> >>>>                 bootargs = "root=/dev/ram
>>>> rdinit=/linuxrc";
>>>>     >> >> >>>>                 stdout-path = "serial0:115200n8";
>>>>     >> >> >>>> @@ -96,6 +100,7 @@
>>>>     >> >> >>>>
>>>>     >> >> >>>>  &ethernet0 {
>>>>     >> >> >>>>         status = "okay";
>>>>     >> >> >>>> +       dma-ranges;
>>>>     >> >> >>>>         pinctrl-0       = <&ethernet0_mii>;
>>>>     >> >> >>>>         pinctrl-names   = "default";
>>>>     >> >> >>>>         phy-mode        = "mii-id";
>>>>     >> >> >>>> @@ -116,6 +121,7 @@
>>>>     >> >> >>>>  };
>>>>     >> >> >>>>
>>>>     >> >> >>>>  &usbotg_hs {
>>>>     >> >> >>>> +       dma-ranges;
>>>>     >> >> >>>>         dr_mode = "host";
>>>>     >> >> >>>>         phys = <&usbotg_hs_phy>;
>>>>     >> >> >>>>         phy-names = "usb2-phy";
>>>>     >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>> index 7d624a2..697a133 100644
>>>>     >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>> @@ -59,7 +59,6 @@
>>>>     >> >> >>>>         };
>>>>     >> >> >>>>
>>>>     >> >> >>>>         soc {
>>>>     >> >> >>>> -               dma-ranges = <0xc0000000 0x0 0x10000000>;
>>>>     >> >> >>>>
>>>>     >> >> >>>>                 timer2: timer at 40000000 {
>>>>     >> >> >>>>                         compatible = "st,stm32-timer";
>>>>     >> >> >>>> @@ -472,13 +471,11 @@
>>>>     >> >> >>>>                         st,syscon = <&syscfg 0x4>;
>>>>     >> >> >>>>                         snps,pbl = <8>;
>>>>     >> >> >>>>                         snps,mixed-burst;
>>>>     >> >> >>>> -                       dma-ranges;
>>>>     >> >> >>>>                         status = "disabled";
>>>>     >> >> >>>>                 };
>>>>     >> >> >>>>
>>>>     >> >> >>>>                 usbotg_hs: usb at 40040000 {
>>>>     >> >> >>>>                         compatible = "snps,dwc2";
>>>>     >> >> >>>> -                       dma-ranges;
>>>>     >> >> >>>>                         reg = <0x40040000 0x40000>;
>>>>     >> >> >>>>                         interrupts = <77>;
>>>>     >> >> >>>>                         clocks = <&rcc 0 29>;
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>>> index 0596d60..3a1cfdd 100644
>>>>     >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>>     >> >> >>>>> @@ -59,8 +59,6 @@
>>>>     >> >> >>>>>         };
>>>>     >> >> >>>>>
>>>>     >> >> >>>>>         soc {
>>>>     >> >> >>>>> -               dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>>     >> >> >>>>> -
>>>>     >> >> >>>>>                 timer2: timer at 40000000 {
>>>>     >> >> >>>>>                         compatible = "st,stm32-timer";
>>>>     >> >> >>>>>                         reg = <0x40000000 0x400>;
>>>>     >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>>>     >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>>>     >> >> >>>>> index 9e73656..c2213c0 100644
>>>>     >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>>>     >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>>>     >> >> >>>>> @@ -64,6 +64,10 @@
>>>>     >> >> >>>>>         aliases {
>>>>     >> >> >>>>>                 serial0 = &usart3;
>>>>     >> >> >>>>>         };
>>>>     >> >> >>>>> +
>>>>     >> >> >>>>> +       soc {
>>>>     >> >> >>>>> +               dma-ranges = <0xc0000000 0x0
>>>> 0x10000000>;
>>>>     >> >> >>>>> +       };
>>>>     >> >> >>>>>  };
>>>>     >> >> >>>>>
>>>>     >> >> >>>>>  &clk_hse {
>>>>     >> >> >>>>> --
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>>
>>>>     >> >> >>>> Br.,
>>>>     >> >> >>>> Bruno
>>>>     >> >> >>>>
>>>>     >> >> >>>
>>>>     >> >> >
>>>>     >> >>
>>>>     >> >> _______________________________________________
>>>>     >> >> linux-arm-kernel mailing list
>>>>     >> >> linux-arm-kernel at lists.infradead.org
>>>>     <mailto:linux-arm-kernel@lists.infradead.org>
>>>>     >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>     <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>>>>     >> >
>>>>     >> >
>>>>     >
>>>>     >
>>>>
>>>>
>>>
>

^ permalink raw reply
* [PATCH v7 RESEND 1/2] ASoC: samsung: Add DT bindings documentation for TM2 sound subsystem
From: Krzysztof Kozlowski @ 2016-11-02 18:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478102558-12524-1-git-send-email-s.nawrocki@samsung.com>

On Wed, Nov 02, 2016 at 05:02:37PM +0100, Sylwester Nawrocki wrote:
> This patch adds DT binding documentation for Exnos5433 based TM2
> and TM2E boards sound subsystem.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes since v5:
>  - none.
> 
> Changes since v4:
>  - indentation changes.
> 
> Changes since v2:
>  - none.
> 
> Changes since initial version:
>  - dropped clocks, clock-names properties, instead properties from
>    the CODEC node will be used,
>  - property renames: 'samsung,model' -> 'model', 'samsung,i2s-controller'
>    -> 'i2s-controller', 'samsung,speaker-amplifier' -> 'audio-amplifier',
>  - added 'audio-codec' property.
> ---
>  .../bindings/sound/samsung,tm2-audio.txt           | 38 ++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt
>


Acked-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof

^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-11-02 18:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAFvLkMSViXggGr0Set0qnQan_+bXUNzJx5WtZHP-Jyje=ZzDVw@mail.gmail.com>

On Wed, Nov 2, 2016 at 4:05 PM, Rados?aw Pietrzyk
<radoslaw.pietrzyk@gmail.com> wrote:
> Have you tried with
>
> sdio {
> ...
> compatible = "arm,primecell";
> arm,primecell-periphid = <id_to_define>;
> ...
> }
>
> This should register proper amba device and give it an ID you wish.

I'm using this:

sdio: sdio at 40012c00 {
compatible = "arm,pl18x", "arm,primecell";
arm,primecell-periphid = <0x00480181>;
reg = <0x40012c00 0x400>;
dmas =  <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
<&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
dma-names = "rx", "tx";
clocks = <&rcc 0 171>;
clock-names = "apb_pclk";
interrupts = <49>;
status = "disabled";
};

And on the driver side I added this:

/* STM32 variants */

{

        .id     = 0x00480181,

        .mask   = 0xf0ffffff,

        .data   = &variant_stm32f4x9,

},

My .id field is the .id from variant_ux500 plus one (and what I
believe is not valid).
And I cannot read the ID from STM32 IP because it always return zero.
Maybe someone from ST(@Alex) can get the real ID. ;)


>
> 2016-11-02 17:07 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
>>
>> Hi
>>
>> On Wed, Nov 2, 2016 at 12:32 PM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>> > Hi
>> >
>> > On 10/31/2016 07:58 PM, Rados?aw Pietrzyk wrote:
>> >>
>> >> I think wlcore driver searches dma-ranges in its parent that's why sdio
>> >> node needs it.
>> >
>> >
>> > Yes I agree. In this case it is needed as you have subnode in sdio node.
>> > So IMO empty dma-ranges could be removed from ethernet and usb node, but
>> > kept in future sdio subnode.
>>
>> Now it is clear.
>>
>> >
>> > Bruno,
>> > Do you plan to push sdio support ?
>>
>> Yes I do, but I'm not sure how long it will take. The I had to
>> change(and hack) the mmci code because I could not get the ID from
>> STM32 SDIO IP.
>> My current WIP is at @
>>
>> https://github.com/mcoquelin-stm32/afboot-stm32/pull/4#issuecomment-247571615
>> I know Andrea Merello is also working on that (and he probably has a
>> more complete patch).
>>
>> >
>> >
>> >
>> >>
>> >> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>> >> <mailto:bruherrera@gmail.com>>:
>> >>
>> >>     On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
>> >>     <radoslaw.pietrzyk at gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
>> >>     wrote:
>> >>     > This is weird because dma ddresses are recalculated using
>> >> parent's
>> >>     > dma-ranges property and soc already has it so there should be
>> >> absolutely no
>> >>     > problem.
>> >>
>> >>     These are my DTS and DTSI file.
>> >>     >
>> >>     > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
>> >>     <mailto:bruherrera@gmail.com>>:
>> >>     >>
>> >>     >> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
>> >>     >> <radoslaw.pietrzyk@gmail.com
>> >>     <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
>> >>     >> > Have you defined your sdio node within soc node ?
>> >>     >>
>> >>     >> It is in the SOC node of the DSTI file.
>> >>     >>
>> >>     >> >
>> >>     >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
>> >>     <mailto:bruherrera@gmail.com>>:
>> >>     >> >>
>> >>     >> >> Hi Alex,
>> >>     >> >>
>> >>     >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>> >>     >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>> >> wrote:
>> >>     >> >> > Hi Bruno,
>> >>     >> >> >
>> >>     >> >> >
>> >>     >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>> >>     >> >> >>
>> >>     >> >> >> Hi Alex,
>> >>     >> >> >>
>> >>     >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>> >>     >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
>> >>     wrote:
>> >>     >> >> >>>
>> >>     >> >> >>> Hi Bruno,
>> >>     >> >> >>>
>> >>     >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>> Hi Alexandre,
>> >>     >> >> >>>>
>> >>     >> >> >>>>>
>> >>     >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
>> >>     start address
>> >>     >> >> >>>>> remapping
>> >>     >> >> >>>>> (to @0) to boost performances. A DMA translation
>> >> through
>> >>     >> >> >>>>> "dma-ranges"
>> >>     >> >> >>>>> property was needed for other masters than the M4 CPU.
>> >>     >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
>> >>     this DMA
>> >>     >> >> >>>>> translation.
>> >>     >> >> >>>>> This patches moves this DMA translation definition from
>> >>     stm32f429
>> >>     >> >> >>>>> soc
>> >>     >> >> >>>>> file
>> >>     >> >> >>>>> to board files.
>> >>     >> >> >>>>>
>> >>     >> >> >>>>> Signed-off-by: Alexandre TORGUE
>> >> <alexandre.torgue@st.com
>> >>     <mailto:alexandre.torgue@st.com>>
>> >>
>> >>     >> >> >>>>>
>> >>     >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>>> index 13c7cd2..a763c15 100644
>> >>     >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>>> @@ -82,6 +82,10 @@
>> >>     >> >> >>>>>                 };
>> >>     >> >> >>>>>         };
>> >>     >> >> >>>>>
>> >>     >> >> >>>>> +       soc {
>> >>     >> >> >>>>> +               dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >>     >> >> >>>>> +       };
>> >>     >> >> >>>>> +
>> >>     >> >> >>>>>         usbotg_hs_phy: usbphy {
>> >>     >> >> >>>>>                 #phy-cells = <0>;
>> >>     >> >> >>>>>                 compatible = "usb-nop-xceiv";
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>> Shouldn't also the peripheral dma-ranges property move
>> >> to
>> >>     board
>> >>     >> >> >>>> specific
>> >>     >> >> >>>> too?
>> >>     >> >> >>>> I  had this patch for while but I didn't had the time to
>> >>     submit:
>> >>     >> >> >>>
>> >>     >> >> >>>
>> >>     >> >> >>>
>> >>     >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
>> >>     ysterday on
>> >>     >> >> >>> IIRC,
>> >>     >> >> >>> empty dma-ranges is not needed. Can you test on your side
>> >> by
>> >>     >> >> >>> removing
>> >>     >> >> >>> dma-ranges in usb node please ?
>> >>     >> >> >>
>> >>     >> >> >> Unfortunately will take a time for me to set up this
>> >>     environment on
>> >>     >> >> >> the STM32F4-EVAL board.
>> >>     >> >> >> And on the discovery boards we dont have this scenario.
>> >>     That was the
>> >>     >> >> >> main reason I did not submit the patch right away.
>> >>     >> >> >> My conclusion and I might be wrong but is based on the my
>> >>     tests with
>> >>     >> >> >> SDIO device at STM32F469I-DISCO board.
>> >>     >> >> >>
>> >>     >> >> >> I started this issue as discussion at ST Forum but Maxime
>> >>     gave me
>> >>     >> >> >> the
>> >>     >> >> >> hint.
>> >>     >> >> >>
>> >>     >> >> >>
>> >>     >> >> >>
>> >>     >> >> >>
>> >>     >> >> >>
>> >>
>> >>
>> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=44
>> >>
>> >>
>> >> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=44>
>> >>     >> >> >>
>> >>     >> >> >>> I will push a v2 by removing empty dma-ranges if tests
>> >> are
>> >>     ok in
>> >>     >> >> >>> your
>> >>     >> >> >>> side.
>> >>     >> >> >>
>> >>     >> >> >>
>> >>     >> >> >> From my understating/conclusion is: when empty
>> >>     property(dma-ranges)
>> >>     >> >> >> is
>> >>     >> >> >> the device node, the mapping will be taken in
>> >> consideration
>> >>     when
>> >>     >> >> >> using
>> >>     >> >> >> DMA otherwise the mapping is ignored.
>> >>     >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>> >>     >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
>> >>     question
>> >>     >> >> >> so
>> >>     >> >> >> I suppose it can work without the property.
>> >>     >> >> >
>> >>     >> >> >
>> >>     >> >> > For sure translation has to be done but I'm not sure that
>> >> an
>> >>     empty
>> >>     >> >> > "dma-ranges" is needed in device node to activate it. For
>> >>     Ethernet
>> >>     >> >> > empty
>> >>     >> >> > "dma-ranges" is not needed. I will try with usb.
>> >>     >> >>
>> >>     >> >> In the case of SDIO it is needed. As example this is my
>> >>     working SDIO
>> >>     >> >> node:
>> >>     >> >>
>> >>     >> >> sdio: sdio at 40012c00 {
>> >>     >> >> compatible = "arm,pl18x", "arm,primecell";
>> >>     >> >> arm,primecell-periphid = <0x00480181>;
>> >>     >> >> reg = <0x40012c00 0x400>;
>> >>     >> >> dmas =  <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>> >>     >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>> >>     >> >> dma-names = "rx", "tx";
>> >>     >> >> clocks = <&rcc 0 171>;
>> >>     >> >> clock-names = "apb_pclk";
>> >>     >> >> interrupts = <49>;
>> >>     >> >> status = "disabled";
>> >>     >> >> };
>> >>     >> >>
>> >>     >> >> &sdio {
>> >>     >> >> status = "okay";
>> >>     >> >> vmmc-supply = <&wlan_en>;
>> >>     >> >> bus-width = <4>;
>> >>     >> >> max-frequency = <24000000>;
>> >>     >> >> pinctrl-names = "default";
>> >>     >> >> pinctrl-0 = <&sdio_pins>;
>> >>     >> >> ti,non-removable;
>> >>     >> >> ti,needs-special-hs-handling;
>> >>     >> >> dma-ranges;
>> >>     >> >> cap-power-off-card;
>> >>     >> >> keep-power-in-suspend;
>> >>     >> >>
>> >>     >> >> #address-cells = <1>;
>> >>     >> >> #size-cells = <0>;
>> >>     >> >> wlcore: wlcore at 0 {
>> >>     >> >> compatible = "ti,wl1835";
>> >>     >> >> reg = <2>;
>> >>     >> >> interrupt-parent = <&gpioa>;
>> >>     >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>> >>     >> >> };
>> >>     >> >> };
>> >>     >> >>
>> >>     >> >> >
>> >>     >> >> > alex
>> >>     >> >> >
>> >>     >> >> >
>> >>     >> >> >>
>> >>     >> >> >>>
>> >>     >> >> >>> Thanks in advance
>> >>     >> >> >>> Alex
>> >>     >> >> >>>
>> >>     >> >> >>>
>> >>     >> >> >>>>
>> >>     >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
>> >>     <mailto:bruherrera@gmail.com>>
>> >>
>> >>     >> >> >>>> Date:   Sun Oct 16 14:50:00 2016 -0200
>> >>     >> >> >>>>
>> >>     >> >> >>>>     ARM: DT: STM32: Use dma-ranges property per board
>> >> not
>> >>     at dtsi
>> >>     >> >> >>>> file
>> >>     >> >> >>>>
>> >>     >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>> index 6bfc595..2a22a82 100644
>> >>     >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>     >> >> >>>> @@ -52,6 +52,10 @@
>> >>     >> >> >>>>         model = "STMicroelectronics STM32429i-EVAL
>> >> board";
>> >>     >> >> >>>>         compatible = "st,stm32429i-eval",
>> >> "st,stm32f429";
>> >>     >> >> >>>>
>> >>     >> >> >>>> +       soc {
>> >>     >> >> >>>> +               dma-ranges = <0xC0000000 0x0
>> >> 0x10000000>;
>> >>     >> >> >>>> +       };
>> >>     >> >> >>>> +
>> >>     >> >> >>>>         chosen {
>> >>     >> >> >>>>                 bootargs = "root=/dev/ram
>> >> rdinit=/linuxrc";
>> >>     >> >> >>>>                 stdout-path = "serial0:115200n8";
>> >>     >> >> >>>> @@ -96,6 +100,7 @@
>> >>     >> >> >>>>
>> >>     >> >> >>>>  &ethernet0 {
>> >>     >> >> >>>>         status = "okay";
>> >>     >> >> >>>> +       dma-ranges;
>> >>     >> >> >>>>         pinctrl-0       = <&ethernet0_mii>;
>> >>     >> >> >>>>         pinctrl-names   = "default";
>> >>     >> >> >>>>         phy-mode        = "mii-id";
>> >>     >> >> >>>> @@ -116,6 +121,7 @@
>> >>     >> >> >>>>  };
>> >>     >> >> >>>>
>> >>     >> >> >>>>  &usbotg_hs {
>> >>     >> >> >>>> +       dma-ranges;
>> >>     >> >> >>>>         dr_mode = "host";
>> >>     >> >> >>>>         phys = <&usbotg_hs_phy>;
>> >>     >> >> >>>>         phy-names = "usb2-phy";
>> >>     >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>> index 7d624a2..697a133 100644
>> >>     >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>> @@ -59,7 +59,6 @@
>> >>     >> >> >>>>         };
>> >>     >> >> >>>>
>> >>     >> >> >>>>         soc {
>> >>     >> >> >>>> -               dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >>     >> >> >>>>
>> >>     >> >> >>>>                 timer2: timer at 40000000 {
>> >>     >> >> >>>>                         compatible = "st,stm32-timer";
>> >>     >> >> >>>> @@ -472,13 +471,11 @@
>> >>     >> >> >>>>                         st,syscon = <&syscfg 0x4>;
>> >>     >> >> >>>>                         snps,pbl = <8>;
>> >>     >> >> >>>>                         snps,mixed-burst;
>> >>     >> >> >>>> -                       dma-ranges;
>> >>     >> >> >>>>                         status = "disabled";
>> >>     >> >> >>>>                 };
>> >>     >> >> >>>>
>> >>     >> >> >>>>                 usbotg_hs: usb at 40040000 {
>> >>     >> >> >>>>                         compatible = "snps,dwc2";
>> >>     >> >> >>>> -                       dma-ranges;
>> >>     >> >> >>>>                         reg = <0x40040000 0x40000>;
>> >>     >> >> >>>>                         interrupts = <77>;
>> >>     >> >> >>>>                         clocks = <&rcc 0 29>;
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>>> index 0596d60..3a1cfdd 100644
>> >>     >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >>     >> >> >>>>> @@ -59,8 +59,6 @@
>> >>     >> >> >>>>>         };
>> >>     >> >> >>>>>
>> >>     >> >> >>>>>         soc {
>> >>     >> >> >>>>> -               dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >>     >> >> >>>>> -
>> >>     >> >> >>>>>                 timer2: timer at 40000000 {
>> >>     >> >> >>>>>                         compatible = "st,stm32-timer";
>> >>     >> >> >>>>>                         reg = <0x40000000 0x400>;
>> >>     >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> >>     >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> >>     >> >> >>>>> index 9e73656..c2213c0 100644
>> >>     >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> >>     >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> >>     >> >> >>>>> @@ -64,6 +64,10 @@
>> >>     >> >> >>>>>         aliases {
>> >>     >> >> >>>>>                 serial0 = &usart3;
>> >>     >> >> >>>>>         };
>> >>     >> >> >>>>> +
>> >>     >> >> >>>>> +       soc {
>> >>     >> >> >>>>> +               dma-ranges = <0xc0000000 0x0
>> >> 0x10000000>;
>> >>     >> >> >>>>> +       };
>> >>     >> >> >>>>>  };
>> >>     >> >> >>>>>
>> >>     >> >> >>>>>  &clk_hse {
>> >>     >> >> >>>>> --
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>>
>> >>     >> >> >>>> Br.,
>> >>     >> >> >>>> Bruno
>> >>     >> >> >>>>
>> >>     >> >> >>>
>> >>     >> >> >
>> >>     >> >>
>> >>     >> >> _______________________________________________
>> >>     >> >> linux-arm-kernel mailing list
>> >>     >> >> linux-arm-kernel at lists.infradead.org
>> >>     <mailto:linux-arm-kernel@lists.infradead.org>
>> >>     >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >>     <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
>> >>     >> >
>> >>     >> >
>> >>     >
>> >>     >
>> >>
>> >>
>> >
>
>

^ permalink raw reply
* [PATCH] drm/sun4i: Fix error handling
From: Maxime Ripard @ 2016-11-02 18:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <c15282b4-e88a-06b1-527d-96aedce8b7eb@wanadoo.fr>

Hi,

On Sun, Oct 30, 2016 at 12:53:02PM +0100, Christophe JAILLET wrote:
> BTW, memory allocation in 'sun4i_layers_init()' looks spurious, especially
> the use of 'layer' in the for loop.
> Just my 2 cents.

What do you mean by it's spurious?

> I also forgot to say that we could propagate the error code returned by
> sun4i_layers_init instead of returning -EINVAL unconditionally

Indeed. Can you send a patch for that?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/4e98b055/attachment.sig>

^ permalink raw reply
* [PATCH V2 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Frank Li @ 2016-11-02 18:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478109604-18323-1-git-send-email-Frank.Li@nxp.com>

mmdc of i.MX6QP are little difference with i.MX6Q.
added new compatible stream fsl,imx6qp-mmdc

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
No change for this patch.
suspend resume code need fsl,imx6q-mmdc

 arch/arm/boot/dts/imx6qp.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
index 886dbf2..e0fdd0f 100644
--- a/arch/arm/boot/dts/imx6qp.dtsi
+++ b/arch/arm/boot/dts/imx6qp.dtsi
@@ -85,5 +85,12 @@
 		pcie: pcie at 0x01000000 {
 			compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
 		};
+
+		aips-bus at 02100000 {
+			mmdc0: mmdc at 021b0000 { /* MMDC0 */
+				compatible = "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc";
+				reg = <0x021b0000 0x4000>;
+			};
+		};
 	};
 };
-- 
2.5.2

^ permalink raw reply related
* [PATCH v2 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Frank Li @ 2016-11-02 18:00 UTC (permalink / raw)
  To: linux-arm-kernel

i.MX6QP added new reigster bit PROFILE_SEL in MADPCR0.
need set it at perf start.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
V1 to V2: remove fsl_mmdc_devtype

 arch/arm/mach-imx/mmdc.c | 38 ++++++++++++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index d82d14c..032cbe0 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -44,6 +44,7 @@
 #define DBG_RST			0x2
 #define PRF_FRZ			0x4
 #define CYC_OVF			0x8
+#define PROFILE_SEL		0x10
 
 #define MMDC_MADPCR0	0x410
 #define MMDC_MADPSR0	0x418
@@ -55,10 +56,29 @@
 
 #define MMDC_NUM_COUNTERS	6
 
+#define FSL_MMDC_QUIRK_PROFILE_SEL	0x1
+
 #define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
 
 static int ddr_type;
 
+struct fsl_mmdc_devtype_data {
+	int driver_data;
+};
+
+static struct fsl_mmdc_devtype_data imx6q_data = {
+};
+
+static struct fsl_mmdc_devtype_data imx6qp_data = {
+	.driver_data = FSL_MMDC_QUIRK_PROFILE_SEL,
+};
+
+static const struct of_device_id imx_mmdc_dt_ids[] = {
+	{ .compatible = "fsl,imx6q-mmdc", .data = (void *)&imx6q_data},
+	{ .compatible = "fsl,imx6qp-mmdc", .data = (void *)&imx6qp_data},
+	{ /* sentinel */ }
+};
+
 #ifdef CONFIG_PERF_EVENTS
 
 static DEFINE_IDA(mmdc_ida);
@@ -83,6 +103,7 @@ struct mmdc_pmu {
 	struct device *dev;
 	struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
 	struct hlist_node node;
+	struct fsl_mmdc_devtype_data *devtype_data;
 };
 
 /*
@@ -307,6 +328,7 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
 	struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
 	void __iomem *mmdc_base, *reg;
+	int val;
 
 	mmdc_base = pmu_mmdc->mmdc_base;
 	reg = mmdc_base + MMDC_MADPCR0;
@@ -321,7 +343,12 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
 	local64_set(&hwc->prev_count, 0);
 
 	writel(DBG_RST, reg);
-	writel(DBG_EN, reg);
+
+	val = DBG_EN;
+	if (pmu_mmdc->devtype_data->driver_data & FSL_MMDC_QUIRK_PROFILE_SEL)
+		val |= PROFILE_SEL;
+
+	writel(val, reg);
 }
 
 static int mmdc_pmu_event_add(struct perf_event *event, int flags)
@@ -436,6 +463,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
 	char *name;
 	int mmdc_num;
 	int ret;
+	const struct of_device_id *of_id =
+		of_match_device(imx_mmdc_dt_ids, &pdev->dev);
 
 	pmu_mmdc = kzalloc(sizeof(*pmu_mmdc), GFP_KERNEL);
 	if (!pmu_mmdc) {
@@ -450,6 +479,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
 		name = devm_kasprintf(&pdev->dev,
 				GFP_KERNEL, "mmdc%d", mmdc_num);
 
+	pmu_mmdc->devtype_data = (struct fsl_mmdc_devtype_data *)of_id->data;
+
 	hrtimer_init(&pmu_mmdc->hrtimer, CLOCK_MONOTONIC,
 			HRTIMER_MODE_REL);
 	pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
@@ -524,11 +555,6 @@ int imx_mmdc_get_ddr_type(void)
 	return ddr_type;
 }
 
-static const struct of_device_id imx_mmdc_dt_ids[] = {
-	{ .compatible = "fsl,imx6q-mmdc", },
-	{ /* sentinel */ }
-};
-
 static struct platform_driver imx_mmdc_driver = {
 	.driver		= {
 		.name	= "imx-mmdc",
-- 
2.5.2

^ permalink raw reply related
* [PATCH] drm/sun4i: Fix error handling
From: Maxime Ripard @ 2016-11-02 17:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161030084926.15303-1-christophe.jaillet@wanadoo.fr>

On Sun, Oct 30, 2016 at 09:49:26AM +0100, Christophe JAILLET wrote:
> 'sun4i_layers_init()' returns an error pointer in case of error, not
> NULL. So test it with IS_ERR.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/a688de85/attachment.sig>

^ permalink raw reply
* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Maxime Ripard @ 2016-11-02 17:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161027224712.GY25322@sirena.org.uk>

Hi Mark,

On Thu, Oct 27, 2016 at 11:47:12PM +0100, Mark Brown wrote:
> > > If the concern from the previous reviews to do with not using DMA is
> > > there some reason it's hard to do DMA?
> 
> > I think just like Alexandru that it is orthogonal. But to really
> > answer, no, it's not difficult. There's just been some fundamental
> > disagreement on whether DMA was supposed to be optional or not that
> > stalled everything I guess.
> 
> Oh, I seem to remember some patches adding DMA support that were doing
> some strange special snowflake thing with ignoring errors now that I
> think about it but that's not this one...  why did nobody ever follow up
> on those?

I have no idea. I think last time we discussed this was last
July. Especially with this in now, there's probably no rush anyway.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/b6ac813a/attachment.sig>

^ permalink raw reply
* [PATCH v5 2/7] Documentation: devicetree: add PHY lane swap binding
From: Andrew Lunn @ 2016-11-02 17:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-3-git-send-email-jon.mason@broadcom.com>

On Wed, Nov 02, 2016 at 01:08:03PM -0400, Jon Mason wrote:
> Add the documentation for PHY lane swapping.  This is a boolean entry to
> notify the phy device drivers that the TX/RX lanes need to be swapped.
> 
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply
* [PATCH] iommu/arm-smmu: Check that iommu_fwspecs are ours
From: Robin Murphy @ 2016-11-02 17:31 UTC (permalink / raw)
  To: linux-arm-kernel

We seem to have forgotten to check that iommu_fwspecs actually belong to
us before we go ahead and dereference their private data. Oops.

Fixes: 021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/arm-smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ef978db2bb54..ef0f8d635a3b 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1390,7 +1390,7 @@ static int arm_smmu_add_device(struct device *dev)
 		fwspec = dev->iommu_fwspec;
 		if (ret)
 			goto out_free;
-	} else if (fwspec) {
+	} else if (fwspec && fwspec->ops == &arm_smmu_ops) {
 		smmu = arm_smmu_get_by_node(to_of_node(fwspec->iommu_fwnode));
 	} else {
 		return -ENODEV;
-- 
2.10.2.dirty

^ permalink raw reply related
* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-11-02 17:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <ab064a45-0172-fa28-4ac6-0d3159a26506@cogentembedded.com>

On Wed, Nov 02, 2016 at 08:18:51PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/02/2016 08:08 PM, Jon Mason wrote:
> 
> >Clean-up the documentation to the bgmac-amac driver, per suggestion by
> >Rob Herring, and add details for NS2 support.
> >
> >Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> >---
> > Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++++++++++-----
> > 1 file changed, 11 insertions(+), 5 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> >index ba5ecc1..2fefa1a 100644
> >--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> >+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> >@@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
> > -------------------------------------------------------------
> >
> > Required properties:
> >- - compatible:	"brcm,amac" or "brcm,nsp-amac"
> >- - reg:		Address and length of the GMAC registers,
> >-		Address and length of the GMAC IDM registers
> >- - reg-names:	Names of the registers.  Must have both "amac_base" and
> >-		"idm_base"
> >+ - compatible:	"brcm,amac"
> >+		"brcm,nsp-amac"
> >+		"brcm,ns2-amac"
> >+ - reg:		Address and length of the register set for the device. It
> >+		contains the information of registers in the same order as
> >+		described by reg-names
> >+ - reg-names:	Names of the registers.
> >+		"amac_base":	Address and length of the GMAC registers
> >+		"idm_base":	Address and length of the GMAC IDM registers
> >+		"nicpm_base":	Address and length of the NIC Port Manager
> >+				registers (required for Northstar2)
> 
>   Why this "_base" suffix? It looks redundant...

Yes.  Rob Herring pointed out the same thing.  It is ugly, but follows
the existing binding.

Thanks,
Jon


> 
> [...]
> 
> MBR, Sergei
> 

^ permalink raw reply
* [PATCH v5 4/7] Documentation: devicetree: net: add NS2 bindings to amac
From: Sergei Shtylyov @ 2016-11-02 17:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478106488-11779-5-git-send-email-jon.mason@broadcom.com>

Hello.

On 11/02/2016 08:08 PM, Jon Mason wrote:

> Clean-up the documentation to the bgmac-amac driver, per suggestion by
> Rob Herring, and add details for NS2 support.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
>  Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
> index ba5ecc1..2fefa1a 100644
> --- a/Documentation/devicetree/bindings/net/brcm,amac.txt
> +++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
> @@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
>  -------------------------------------------------------------
>
>  Required properties:
> - - compatible:	"brcm,amac" or "brcm,nsp-amac"
> - - reg:		Address and length of the GMAC registers,
> -		Address and length of the GMAC IDM registers
> - - reg-names:	Names of the registers.  Must have both "amac_base" and
> -		"idm_base"
> + - compatible:	"brcm,amac"
> +		"brcm,nsp-amac"
> +		"brcm,ns2-amac"
> + - reg:		Address and length of the register set for the device. It
> +		contains the information of registers in the same order as
> +		described by reg-names
> + - reg-names:	Names of the registers.
> +		"amac_base":	Address and length of the GMAC registers
> +		"idm_base":	Address and length of the GMAC IDM registers
> +		"nicpm_base":	Address and length of the NIC Port Manager
> +				registers (required for Northstar2)

   Why this "_base" suffix? It looks redundant...

[...]

MBR, Sergei

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox