* [PATCH 1/3] ARM: dts: r8a7743: add PFC support
From: Simon Horman @ 2017-04-20 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414211505.733692280@cogentembedded.com>
On Sat, Apr 15, 2017 at 12:09:42AM +0300, Sergei Shtylyov wrote:
> Define the generic R8A7743 part of the PFC device node.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> arch/arm/boot/dts/r8a7743.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -1,7 +1,7 @@
> /*
> * Device Tree Source for the r8a7743 SoC
> *
> - * Copyright (C) 2016 Cogent Embedded Inc.
> + * Copyright (C) 2016-2017 Cogent Embedded Inc.
> *
> * This file is licensed under the terms of the GNU General Public License
> * version 2. This program is licensed "as is" without any warranty of any
> @@ -123,6 +123,11 @@
> #power-domain-cells = <1>;
> };
>
> + pfc: pin-controller at e6060000 {
> + compatible = "renesas,pfc-r8a7743";
> + reg = <0 0xe6060000 0 0x250>;
> + };
> +
I am curious to know why pin-controller was chosen rather than pfc which
is dominant in the DT for Renesas SoCs. And as a follow-up question, do
you think it would be worth creating patches to make this uniform
across the DT for Renesas SoCs.
> dmac0: dma-controller at e6700000 {
> compatible = "renesas,dmac-r8a7743",
> "renesas,rcar-dmac";
>
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Mark Rutland @ 2017-04-20 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492623846-29335-1-git-send-email-ganapatrao.kulkarni@cavium.com>
On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote:
> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in HYP)
> is returning error for perf syscall with mixed attribute set for exclude_kernel
> and exclude_hv. This change is breaking some applications (observed with hhvm)
> when ran on VHE enabled platforms.
>
> Adding fix to consider only exclude_kernel attribute when kernel is
> running in HYP. Also adding sysfs file to notify the bhehaviour
> of attribute exclude_hv.
>
> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> ---
>
> Changelog:
>
> V2:
> - Changes as per Will Deacon's suggestion.
>
> V1: Initial patch
>
> arch/arm64/kernel/perf_event.c | 28 ++++++++++++++++++++++++----
> include/linux/perf/arm_pmu.h | 1 +
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>
> if (attr->exclude_idle)
> return -EPERM;
> - if (is_kernel_in_hyp_mode() &&
> - attr->exclude_kernel != attr->exclude_hv)
> - return -EINVAL;
> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel)
> + config_base |= ARMV8_PMU_INCLUDE_EL2;
> if (attr->exclude_user)
> config_base |= ARMV8_PMU_EXCLUDE_EL0;
> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
> config_base |= ARMV8_PMU_EXCLUDE_EL1;
> - if (!attr->exclude_hv)
> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv)
> config_base |= ARMV8_PMU_INCLUDE_EL2;
This isn't quite what Will suggested.
The idea was that userspace would read sysfs, then use that to determine
the correct exclusion parameters [1,2]. This logic was not expected to
change; it correctly validates whether we can provide what the user
requests.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/499224.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/499493.html
>
> /*
> @@ -1008,6 +1026,8 @@ static int armv8_pmuv3_init(struct arm_pmu *cpu_pmu)
> &armv8_pmuv3_events_attr_group;
> cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_FORMATS] =
> &armv8_pmuv3_format_attr_group;
> + cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_ATTR] =
> + &armv8_pmuv3_attr_group;
> return armv8pmu_probe_pmu(cpu_pmu);
> }
>
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index 8462da2..a26ffc7 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -81,6 +81,7 @@ enum armpmu_attr_groups {
> ARMPMU_ATTR_GROUP_COMMON,
> ARMPMU_ATTR_GROUP_EVENTS,
> ARMPMU_ATTR_GROUP_FORMATS,
> + ARMPMU_ATTR_GROUP_ATTR,
> ARMPMU_NR_ATTR_GROUPS
> };
>
> --
> 1.8.1.4
>
^ permalink raw reply
* [PATCH] arm64: prefetch: Change assembly to be compatible with gcc and clang
From: Mark Rutland @ 2017-04-20 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419212211.95803-1-mka@chromium.org>
On Wed, Apr 19, 2017 at 02:22:11PM -0700, Matthias Kaehlcke wrote:
> clang fails to build with the current code:
>
> arch/arm64/include/asm/processor.h:172:15: error: invalid operand in
> inline asm: 'prfm pldl1keep, ${0:a}'
>
> Apparently clang does not support the 'a' modifier. Change the
> constraint from 'p' ('An operand that is a valid memory address is
> allowed') to 'Q' ('A memory address which uses a single base register
> with no offset'), which works for both gcc and clang.
It looks like the current %a0 template and p constraint were inherited
from arch/arm, as they've been there from day one on arm64.
Looking at the arch/arm history, the "a" operand modifier and "p"
constraint were introduced in commit:
16f719de62809e22 ("[ARM] 5196/1: fix inline asm constraints for preload")
... so as to avoid GCC assuming prefetch of a pointer implied it was not
NULL. Until that point, we'd used no operand modifier and "o"
constraint.
It's not clear to me whether "o", "p", and "Q" constraints differ in
this regard on AArch64, or if the issue regarding NULL is still
relevant. The GCC docs say the "p" constraint is used for "a valid
memory address", which does sound like it shouldn't be NULL.
Otherwise, this does look consistent with what we do elsewhere.
Thanks,
Mark.
>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> arch/arm64/include/asm/processor.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index c97b8bd2acba..bfdc82e924a5 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -165,21 +165,21 @@ extern struct task_struct *cpu_switch_to(struct task_struct *prev,
> #define ARCH_HAS_PREFETCH
> static inline void prefetch(const void *ptr)
> {
> - asm volatile("prfm pldl1keep, %a0\n" : : "p" (ptr));
> + asm volatile("prfm pldl1keep, %0\n" : : "Q" (ptr));
> }
>
> #define ARCH_HAS_PREFETCHW
> static inline void prefetchw(const void *ptr)
> {
> - asm volatile("prfm pstl1keep, %a0\n" : : "p" (ptr));
> + asm volatile("prfm pstl1keep, %0\n" : : "Q" (ptr));
> }
>
> #define ARCH_HAS_SPINLOCK_PREFETCH
> static inline void spin_lock_prefetch(const void *ptr)
> {
> asm volatile(ARM64_LSE_ATOMIC_INSN(
> - "prfm pstl1strm, %a0",
> - "nop") : : "p" (ptr));
> + "prfm pstl1strm, %0",
> + "nop") : : "Q" (ptr));
> }
>
> #define HAVE_ARCH_PICK_MMAP_LAYOUT
> --
> 2.12.2.816.g2cccc81164-goog
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
From: Maxime Ripard @ 2017-04-20 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88F5FAC9-1873-4C76-9AB9-FF361C07664E@aosc.io>
On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
> >> + /* Get the physical address of the buffer in memory */
> >> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> >> +
> >> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
> >> +
> >> + /* Compute the start of the displayed memory */
> >> + bpp = fb->format->cpp[0];
> >> + paddr = gem->paddr + fb->offsets[0];
> >> + paddr += (state->src_x >> 16) * bpp;
> >> + paddr += (state->src_y >> 16) * fb->pitches[0];
> >> +
> >> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
> >> +
> >> + paddr_u32 = (uint32_t) paddr;
> >
> >How does that work on 64-bits systems ?
>
> The hardware is not designed to work on 64-bit systems.
>
> Even 64-bit A64/H5 has also 3GiB memory limit.
That's a fragile assumption.
> The address cell in mixer hardware is also only 32-bit.
>
> So we should just keep the force conversion here. If we then really
> met 4GiB-capable AW SoC without changing DE2, I think we should have
> other way to limit CMA pool inside 4GiB.
The register name looks like this is only the lower 32 bits that you
can set here, and that there is another register for the upper 32 bits
of that address somewhere.
In that case, please use the lower_32_bits and upper_32_bits helper,
and don't cast it that way.
If it isn't the case, you should set the DMA mask (through
dma_set_mask) so that we only allocate memory that can be accessed by
this device.
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/20170420/77277f32/attachment.sig>
^ permalink raw reply
* [GIT PULL 00/16] clocksource: arm_arch_timer: GTDT-based MMIO timer support
From: Fu Wei @ 2017-04-20 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420082627.GA31436@leverpostej>
Hi Daniel, Lorenzo, Mark,
On 20 April 2017 at 16:26, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Apr 19, 2017 at 11:39:44PM +0200, Daniel Lezcano wrote:
>> On Wed, Apr 19, 2017 at 05:44:17PM +0100, Mark Rutland wrote:
>> > Hi Daniel,
>
>> > I realise this is a little late, but I would very much appreciate if you could
>> > pull these arch timer GTDT patches for v4.12. The series has been largely fine
>> > for a while now, and the major hold-ups were edge cases in error handling which
>> > have now been addressed.
>
>> Hi Thomas,
>>
>> the series is ok for me. Is it possible to pull these changes directly in
>> tip/timers/core?
>
> The tip-bot tells me it was.
>
> Many thanks for picking these up, it's much appreciated.
Great thanks to all of you, I very appreciate all the help and
suggestion from you :-)
>
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v2 8/9] staging: fsl-dpaa2/eth: Add TODO file
From: Ruxandra Ioana Radulescu @ 2017-04-20 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEac7ta6h=_TT9MCZc8G4-raN47HrAphKf4ufUurX+zoOjm1gQ@mail.gmail.com>
> -----Original Message-----
> From: Stuart Yoder [mailto:stuyoder at gmail.com]
> Sent: Wednesday, April 19, 2017 6:44 AM
> To: Ruxandra Ioana Radulescu <ruxandra.radulescu@nxp.com>
> Cc: gregkh at linuxfoundation.org; devel at driverdev.osuosl.org; linux-
> kernel at vger.kernel.org; Alexander Graf <agraf@suse.de>; Arnd Bergmann
> <arnd@arndb.de>; linux-arm-kernel at lists.infradead.org; Alexandru
> Marginean <alexandru.marginean@nxp.com>; Bogdan Hamciuc
> <bogdan.hamciuc@nxp.com>; Laurentiu Tudor <laurentiu.tudor@nxp.com>;
> Roy Pledge <roy.pledge@nxp.com>; Haiying Wang
> <haiying.wang@nxp.com>
> Subject: Re: [PATCH v2 8/9] staging: fsl-dpaa2/eth: Add TODO file
>
> On Wed, Apr 12, 2017 at 11:25 AM, Ioana Radulescu
> <ruxandra.radulescu@nxp.com> wrote:
> > Add a list of TODO items for the Ethernet driver
> >
> > Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
> > ---
> > v2: Add note
> >
> > drivers/staging/fsl-dpaa2/ethernet/TODO | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> > create mode 100644 drivers/staging/fsl-dpaa2/ethernet/TODO
> >
> > diff --git a/drivers/staging/fsl-dpaa2/ethernet/TODO b/drivers/staging/fsl-
> dpaa2/ethernet/TODO
> > new file mode 100644
> > index 000000000000..110e66d44b42
> > --- /dev/null
> > +++ b/drivers/staging/fsl-dpaa2/ethernet/TODO
> > @@ -0,0 +1,14 @@
> > +* Add a DPAA2 MAC kernel driver in order to allow PHY management;
> currently
> > + the DPMAC objects and their link to DPNIs are handled by MC internally
> > + and all PHYs are seen as fixed-link
> > +* add more debug support: decide how to expose detailed debug
> statistics,
> > + add ingress error queue support
> > +* MC firmware uprev; the DPAA2 objects used by the Ethernet driver
> need to
> > + be kept in sync with binary interface changes in MC
> > +* refine README file
> > +* cleanup
> > +
> > +NOTE: None of the above is must-have before getting the DPAA2
> Ethernet driver
> > +out of staging. The main requirement for that is to have the drivers it
> > +depends on, fsl-mc bus and DPIO driver, moved to drivers/bus and
> drivers/soc
> > +respectively.
>
> The TODO file should have contact info (I think)...look at other
> drivers/staging TODO
> for examples.
Thanks Stuart, I missed that. If I send a v3 of this patchset I'll include
this update, otherwise I'll send a separate patch for it.
Ioana
^ permalink raw reply
* [GIT PULL 00/16] clocksource: arm_arch_timer: GTDT-based MMIO timer support
From: Mark Rutland @ 2017-04-20 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419213944.GC2523@mai>
On Wed, Apr 19, 2017 at 11:39:44PM +0200, Daniel Lezcano wrote:
> On Wed, Apr 19, 2017 at 05:44:17PM +0100, Mark Rutland wrote:
> > Hi Daniel,
> > I realise this is a little late, but I would very much appreciate if you could
> > pull these arch timer GTDT patches for v4.12. The series has been largely fine
> > for a while now, and the major hold-ups were edge cases in error handling which
> > have now been addressed.
> Hi Thomas,
>
> the series is ok for me. Is it possible to pull these changes directly in
> tip/timers/core?
The tip-bot tells me it was.
Many thanks for picking these up, it's much appreciated.
Mark.
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Arnd Bergmann @ 2017-04-20 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8df7c5a9-c71c-4ee9-9bc2-9c861cf9796c@kapsi.fi>
On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
> On 19.04.2017 21:24, Arnd Bergmann wrote:
>>
>> When dma_addr_t and phys_addr_t are not the same size, we get a warning
>> from the dma_alloc_wc function:
>>
>> drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
>> drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of
>> 'dma_alloc_wc' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>> pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
>> ^
>> In file included from drivers/gpu/host1x/cdma.c:22:0:
>> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long
>> long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned
>> int *}'
>> static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev,
>> size_t size,
>> ^~~~~~~~~~~~
>> drivers/gpu/host1x/cdma.c:113:48: error: passing argument 3 of
>> 'dma_alloc_wc' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>> pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
>> ^
>> In file included from drivers/gpu/host1x/cdma.c:22:0:
>> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long
>> long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned
>> int *}'
>> static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev,
>> size_t size,
>> ^~~~~~~~~~~~
>>
>> The problem here is that dma_alloc_wc() returns a pointer to a dma_addr_t
>> that may already be translated by an IOMMU, but the driver passes this
>> into iommu_map() as a physical address. This works by accident only when
>> the IOMMU does not get registered with the DMA API and there is a 1:1
>> mapping between physical addresses as seen by the CPU and the device.
>>
>> The fundamental problem here is the lack of a generic API to do what the
>> driver wants: allocating CPU-visible memory for use by a device through
>> user-defined IOMMU settings. Neither the dma-mapping API nor the IOMMU
>> API can do this by itself, and combining the two is not well-defined.
>>
>> This patch addresses the type mismatch by adding a third pointer into the
>> push_buffer structure: in addition to the address as seen from the CPU
>> and the address inside of the local IOMMU domain, the pb->alloc pointer
>> is the token returned by dma_alloc_wc(), and this is what we later need
>> to pass into dma_free_wc().
>>
>> The address we pass into iommu_map() however is the physical address
>> computed from virt_to_phys(), assuming that the pointer we have here
>> is part of the linear mapping (which is also questionable, e.g. when we
>> have a non-coherent device on ARM32 this may be false). Also, when
>> the DMA API uses the IOMMU to allocate the pointer for the default
>> domain, we end up with two IOMMU mappings for the same physical address.
>>
>
> I think we have a "policy" on Tegra that the DMA API will never allocate
> using the IOMMU (Thierry can elaborate on this), which is why I wrote the
> code with that assumption. Essentially, we have made the DMA API into the
> API that allocates CPU-visible memory.
I don't think this can be a per-platform policy.
> Considering that, I'm wondering if we can just have a temporary local
> dma_addr_t and then cast that to phys_addr_t, combined with a good comment?
That was my first approach, and it does address the warning, but
I did not send it because it still felt too wrong.
Arnd
^ permalink raw reply
* [PATCH] lib/mpi: fix build with clang
From: Arnd Bergmann @ 2017-04-20 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420034022.24109-1-stefan@agner.ch>
On Thu, Apr 20, 2017 at 5:40 AM, Stefan Agner <stefan@agner.ch> wrote:
> Use just @ to denote comments which works with gcc and clang.
> Otherwise clang reports an escape sequence error:
> error: invalid % escape in inline assembly string
>
> Use %0-%3 as operand references, this avoids:
> error: invalid operand in inline asm: 'umull ${1:r}, ${0:r}, ${2:r}, ${3:r}'
>
> Also remove superfluous casts on output operands to avoid warnings
> such as:
> warning: invalid use of a cast in an inline asm context requiring an l-value
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> I checked the output of gcc with -S switch before and after this change,
> gcc generated the same assembly.
I've done a lot of build testing on a tree that contains a very similar patch.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
From: Mason @ 2017-04-20 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d48d57-5f9f-1b35-99da-ab39de2d3d48@free.fr>
On 19/04/2017 13:19, Mason wrote:
> My biggest problem is that tango_unmask() is never called.
FTR, the missing incantation was:
Explicitly calling tango_{mask/unmask/ack} from the corresponding msi_{mask/unmask/ack}
Marc, I have one nagging doubt, wrt splitting MSI line selection
and MSI enable.
tango_irq_domain_alloc : finds an available MSI 'j' to allocate
tango_irq_domain_free : release MSI 'j'
tango_unmask : enable MSI 'j'
tango_mask : disable MSI 'j'
Is the following scenario guaranteed to never happen?
tango_irq_domain_alloc // alloc 0
tango_irq_domain_free // free 0
tango_irq_domain_alloc // alloc 0
tango_unmask // enable 0
tango_unmask // enable 0 = NOP
tango_mask // disable 0
In this theoretical scenario, we would be left with a non-functional
MSI 0.
Regards.
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.12, take 2
From: Maxime Ripard @ 2017-04-20 8:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike, Stephen,
Here are the few last minor fixes that didn't go through for 4.11,
plus two fixes for previous drivers changes found in the earlier pull
request for 4.12.
Thanks!
Maxime
The following changes since commit cb545960dea2749771c88b0cb26e5adfd12a0315:
clk: sunxi-ng: Display index when clock registration fails (2017-04-06 09:10:30 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.12-2
for you to fetch changes up to 7149c1becddf49022fe0aad2fa395377cd8f753e:
clk: sunxi-ng: a80: Fix audio PLL comment not matching actual code (2017-04-13 14:09:30 +0200)
----------------------------------------------------------------
Allwinner clock changes, take 2
A few minor bug and comment fixes, plus some fixes for the PRCM CCU driver
merged in the prior pull request
----------------------------------------------------------------
Chen-Yu Tsai (3):
clk: sunxi-ng: use 1 as fallback for minimum multiplier
clk: sunxi-ng: Fix round_rate/set_rate multiplier minimum mismatch
clk: sunxi-ng: a80: Fix audio PLL comment not matching actual code
Icenowy Zheng (2):
clk: sunxi-ng: fix PRCM CCU ir clk parent
clk: sunxi-ng: fix PRCM CCU CLK_NUMBER value
drivers/clk/sunxi-ng/ccu-sun8i-r.c | 2 +-
drivers/clk/sunxi-ng/ccu-sun8i-r.h | 2 +-
drivers/clk/sunxi-ng/ccu-sun9i-a80.c | 3 +--
drivers/clk/sunxi-ng/ccu_nk.c | 8 ++++----
drivers/clk/sunxi-ng/ccu_nkm.c | 8 ++++----
drivers/clk/sunxi-ng/ccu_nkmp.c | 8 ++++----
drivers/clk/sunxi-ng/ccu_nm.c | 4 ++--
7 files changed, 17 insertions(+), 18 deletions(-)
--
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/20170420/78e44516/attachment.sig>
^ permalink raw reply
* [PATCH] ASoC: mediatek: add I2C dependency for CS42XX8
From: Arnd Bergmann @ 2017-04-20 8:15 UTC (permalink / raw)
To: linux-arm-kernel
We should not select drivers that depend on I2C when that is disabled,
as it results in a build error:
warning: (SND_SOC_MT2701_WM8960) selects SND_SOC_WM8960 which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && I2C)
sound/soc/codecs/wm8960.c:1469:1: error: data definition has no type or storage class [-Werror]
sound/soc/codecs/wm8960.c:1469:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int]
Fixes: 8625c1dbd876 ("ASoC: mediatek: Add mt2701-wm8960 machine driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
sound/soc/mediatek/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index c6f39040f71f..5c68797f36c4 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -24,7 +24,7 @@ config SND_SOC_MT2701_CS42448
config SND_SOC_MT2701_WM8960
tristate "ASoc Audio driver for MT2701 with WM8960 codec"
- depends on SND_SOC_MT2701
+ depends on SND_SOC_MT2701 && I2C
select SND_SOC_WM8960
help
This adds ASoC driver for Mediatek MT2701 boards
--
2.9.0
^ permalink raw reply related
* [GIT PULL] ARM: SOC PM domain for 4.12
From: Arnd Bergmann @ 2017-04-20 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F81269.70207@ti.com>
On Thu, Apr 20, 2017 at 3:44 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> On 04/19/2017 05:54 PM, santosh.shilimkar at oracle.com wrote:
>> On 4/19/17 12:56 PM, Arnd Bergmann wrote:
>>
>>> Since I was looking at it, I also took a closer look at the contents of the
>>> patch series. The driver itself looks fine, but for the record, I'm not that
>>> happy about seeing a header file duplicating the information from the
>>> data sheet: We only use dt-binding headers to establish an interface between
>>> the driver and the sources when there is well-defined fixed way to enumerate
>>> resources, but in this case there clearly is...
>>>
>
> I apologize but I'm not clear on exactly what your concern is? Currently we
> define a device ID which is associated to a "device" in the firmware's view of
> the world, however the firmware has no knowledge of what goes on in the kernel
> and vice-versa. The device ID is associated to that device only on that
> hardware, it could be a different ID on a different SoC making use of SCI. The
> only way a device is identified to the firmware is through this number, it will
> also be used by the ti-sci-clock [1] and ti-sci-reset [2] drivers to identify
> the device.
>
> I'm not sure what you mean by "We only use dt-binding headers to establish an
> interface between the driver and the sources when there is well-defined fixed
> way to enumerate resources."
More generally speaking, header files are used as interfaces when you want to
ensure that a number you pick, or a function prototype is the same between
two or more parts of a system.
For the reset handling and the pm domain, this is not the case: the header
only gets included by the dts files and the driver does not use it at all, so
you can simply remove the header and open-code the numbers in the
dts file, as you do in the same files for all other numbers (register addresses,
interrupts, gpio lines). Please remove these to save the pointless indirection.
For the clk driver, this is a little less obvious as you do use the K2G_DEV_*
macros in both the dts files and in the driver. However, I think these still
fall in the same basic category, as the numbers are not picked arbitrarily
when writing the driver to describe the usual mess of register offsets in
a clock controller. Rather this one is apparently used for communicating
with the firmware using a proper interface, so you can simply move the
header file contents into the driver.
Arnd
^ permalink raw reply
* [PATCH] arm64: sunxi: always enable reset controller
From: Maxime Ripard @ 2017-04-20 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419173601.3773999-1-arnd@arndb.de>
On Wed, Apr 19, 2017 at 07:35:36PM +0200, Arnd Bergmann wrote:
> The sunxi clk driver causes a link error when the reset controller
> subsystem is disabled:
>
> drivers/clk/built-in.o: In function `sun4i_ve_clk_setup':
> :(.init.text+0xd040): undefined reference to `reset_controller_register'
> drivers/clk/built-in.o: In function `sun4i_a10_display_init':
> :(.init.text+0xe5e0): undefined reference to `reset_controller_register'
> drivers/clk/built-in.o: In function `sunxi_usb_clk_setup':
> :(.init.text+0x10074): undefined reference to `reset_controller_register'
>
> We already force it to be enabled on arm32 and some other arm64 platforms,
> but not on arm64/sunxi. This adds the respective Kconfig statements to
> also select it here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm64/Kconfig.platforms | 2 ++
> 1 file changed, 2 insertions(+)
>
> I'd suggest we can pick this up in arm-soc as a non-urgent bugfix for 4.12
That works for me, you can add my Acked-by.
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/20170420/8c6d2517/attachment.sig>
^ permalink raw reply
* [PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Maxime Ripard @ 2017-04-20 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d13e447e9cc080d81c4f2db3bd5433506d3ef739.1492666725.git.viresh.kumar@linaro.org>
Hi,
On Thu, Apr 20, 2017 at 11:14:16AM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
This patch doesn't apply, please make sure to base them on linux-next
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/20170420/e9981076/attachment.sig>
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2017-04-20 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UShTqx3JjijEZSayA4HtFzztye6rotsJubtoiYxxMC=g@mail.gmail.com>
Am 19.04.2017 um 23:47 schrieb Doug Anderson:
> Hi,
>
> On Wed, Apr 19, 2017 at 1:25 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> Hi,
>>
>>> Doug Anderson <dianders@chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>>>
>>>
>>> It's hard to know for sure that all of this time is really in
>>> urb_enqueue(). Possible we could have task switched out and been
>>> blocked elsewhere. Using ftrace to get more fine-grained timings
>>> would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
>>> friends here if you want to use trace_printk.
>> i'm a newbie to ftrace, so i hope this would be helpful.
>>
>> # connect PL2303 to the onboard hub
>> # echo 0 > options/sleep-time
>> # echo 0 > function_profile_enabled
>> # echo 1 > function_profile_enabled
>> # ./usb_test
>> # Waiting for at least 20 seconds and then disconnect PL2303
>> # echo 0 > function_profile_enabled
>> # cat trace_stat/function0
>>
>> Function Hit Time Avg s^2
>> -------- --- ---- --- ---
>> bcm2835_handle_irq 361347 219567633 us 607.636 us 1485199 us
>> __handle_domain_irq 1082482 212639551 us 196.437 us 3642030 us
>> generic_handle_irq 1082482 100592051 us 92.927 us 50511334 us
>> irq_exit 1082482 98197771 us 90.715 us 29649040 us
>> handle_level_irq 1082482 95812379 us 88.511 us 51910093 us
>> do_sys_open 1806 87612983 us 48512.17 us 2198507 us
>> SyS_open 1601 87372331 us 54573.59 us 1898996 us
>> do_filp_open 1862 87368058 us 46921.62 us 1634982 us
>> path_openat 1862 87314553 us 46892.88 us 3357817 us
>> __do_softirq 3035 86266050 us 28423.73 us 6449768 us
>> vfs_open 1515 85877012 us 56684.49 us 101673.5 us
>> do_dentry_open 1515 85861429 us 56674.21 us 812420.7 us
>> usb_submit_urb 136 85760172 us 630589.5 us 59532024 us
>> usb_hcd_submit_urb 134 85756518 us 639974.0 us 726298102 us
>> _dwc2_hcd_urb_enqueue 134 85738333 us 639838.3 us 874104371 us
> The 134 calls to this are taking a ton of time. It would be nice to
> know where all the time actually was in here. Are you on a
> single-core device, or multi-core?
Raspberry Pi B is a single core device which runs with 700 MHz cpu freq.
> Oh, probably this so slow because we're just getting interrupted
> constantly. You can see that during your trace 80686112 us was in
> handle_irq_event(). Presumably all of that time could have been
> counted towards whatever code you were in when the interrupt went off.
> Of that 80 seconds, 60 seconds or so was usb_hcd_irq, and of that 57
> seconds was in _dwc2_hcd_irq().
Since the FTDI (full speed device) and the PL2303 (also full speed
device) behaves differently, i will try to compare those ftraces.
>
> Presumably the big part of your problem is that dwc2_handle_hcd_intr()
> is just too slow. From glancing at the numbers below, it seems likely
> that nothing in particular is slow, it's just running a lot of code
> and (in total) all of that is slow. ...but someone with more time on
> their hands would need to really debug.
>
> One thing that would be interesting would be to see if you can
> increase the bug clock for talking to the dwc2 controller.
Unfortunately the bcm2835 datasheet [1] doesn't provide many information
about the USB IP core and the Synopsys documents aren't public
available. The Raspberry Pi Foundation decided to use a different driver
which uses FIQ in the downstream tree [2], but this won't be an option here.
Maybe i could start with comparing the register settings between dwc2
and dwc_otg.
[1] -
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
[2] -
https://github.com/raspberrypi/linux/commit/65165df02f2ba9feccebf45d8c732dffb34b6109
> Possibly
> some of those memory mapped IOs talking to dwc2 could be making
> everything slow?
>
> Other than that, maybe you can find some way to optimize the code in
> dwc2 so it runs faster, at least in the cases you care about...
>
^ permalink raw reply
* [PATCH 09/11] drm/sun4i: Support two display pipelines
From: Maxime Ripard @ 2017-04-20 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64etokrb2at8Z9mpRfLhQO_2BcypZBF_rG7sVSRKiW1KQ@mail.gmail.com>
Hi,
On Tue, Apr 18, 2017 at 06:10:26PM +0800, Chen-Yu Tsai wrote:
> >> >> >> @@ -540,14 +539,22 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
> >> >> >> /* This can fail if the DT does not have any downstream encoders. */
> >> >> >> tcon->id = sun4i_tcon_of_get_id(dev->of_node);
> >> >> >> if (tcon->id < 0) {
> >> >> >> - /*
> >> >> >> - * TODO We currently support only 1 TCON, so we can
> >> >> >> - * safely set this to 0. This should be revisited
> >> >> >> - * when we add support for multiple pipelines.
> >> >> >> - */
> >> >> >> - tcon->id = 0;
> >> >> >> + int i;
> >> >> >> +
> >> >> >> + /* find the first empty tcon in sun4i_drv */
> >> >> >> + for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++)
> >> >> >> + if (!drv->tcon[i])
> >> >> >> + tcon->id = i;
> >> >> >> +
> >> >> >> + /* bail out if that failed */
> >> >> >> + if (tcon->id < 0)
> >> >> >> + return tcon->id;
> >> >> >> }
> >> >> >>
> >> >> >> + /* We only support SUN4I_DRM_MAX_PIPELINES number of tcons */
> >> >> >> + if (tcon->id >= SUN4I_DRM_MAX_PIPELINES)
> >> >> >> + return -EINVAL;
> >> >> >> +
> >> >> >> tcon->lcd_rst = devm_reset_control_get(dev, "lcd");
> >> >> >> if (IS_ERR(tcon->lcd_rst)) {
> >> >> >> dev_err(dev, "Couldn't get our reset line\n");
> >> >> >> @@ -588,7 +595,7 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
> >> >> >> goto err_free_dotclock;
> >> >> >> }
> >> >> >>
> >> >> >> - tcon->crtc = sun4i_crtc_init(drm, drv->backend, tcon);
> >> >> >> + tcon->crtc = sun4i_crtc_init(drm, drv->backend[tcon->id], tcon);
> >> >> >
> >> >> > I'm not a big fan of those IDs. The heuristic seems to be a bit
> >> >> > fragile since we really never enforced any order in our bindings.
> >> >>
> >> >> Yes. I seem to have forgotten that bit which I had intended to add.
> >> >> The endpoint IDs would ideally match the actual mux values used.
> >> >
> >> > That works for me, but the binding documentation would need to be
> >> > amended.
> >> >
> >> >> On the TCON side that's not doable, so we might have to just require
> >> >> them being in an increasing order.
> >> >
> >> > What are you planning to use those IDs on for the TCON?
> >>
> >> This reply sat in my draft box for way too long.
> >>
> >> As mentioned, the IDs on the TCON side are for the IDing the TV encoders.
> >> I think having the IDs for the same type of encoder be increasing, such
> >> that the endpoint for TV encoder 1 has a higher ID than the one for TV
> >> encoder 0 should be enough. There aren't any other instances where we
> >> have 2 or more of the same type. Or we could just add some kind of index
> >> property to the TV encoder node. This is for the A20 by the way.
> >
> > Sorry if I'm missing a bit of context here, but I still don't get
> > *why* you would need to ID them. So far, your explanation seems to
> > have been "so that we can ID them", which is pretty circular to me :)
>
> The mux controls for the TCON output path to the TV/HDMI/MIPI encoders,
> and the TV encoder outputs, reside in the address space of the first TCON
> and TV encoder, respectively. That's why we need to ID them, to access
> the mux controls in the right block to setup the display pipeline.
Cant' we just do that based on the endpoint ID? Especially if the only
thing we really need to tell is which TCON, we basically just have to
loop around until we find a TCON, and use that one (and the same
applies for the TV encoder).
This needs to be documented properly, but I don't see anything wrong
with that
> >> >> > You seem to use it for two things:
> >> >> > - to match a TCON to its backend in our code
> >> >> > - to not step on each others' toes when registering the backends/tcons
> >> >> >
> >> >> > I think the second could be easily addressed using a linked list, and
> >> >> > the first one by storing the of_node. Then we just need to follow the
> >> >> > OF graph to our input of_node, and then iterate through our registered
> >> >> > backend list to find the one with the same of_node.
> >> >>
> >> >> Yes that would work for the above purposes.
> >> >>
> >> >> For getting the first TCON to access the mux registers, it kind of falls
> >> >> short. We also need something like this for the TV encoders on A10/A20.
> >> >> They too have a mux, which seems to be in the first TV encoder. This
> >> >> controls how the 8 DACs are mapped to the 4 external pins.
> >> >
> >> > How are those pins muxed between the two? Can't we just create a
> >> > connector that would be usable for both encoders?
> >>
> >> They are freely muxable. However if you want VGA output, you need 3 pins
> >> for RGB from the same TV encoder, plus H/V sync from it's upstream TCON.
> >
> > (you don't really need hsync and vsync on VGA, those are optional signals)
>
> Really? I think you are confusing VGA with the broader "component RGB video".
> AFAIK most monitors need separate sync signals.
>
> See https://en.wikipedia.org/wiki/Component_video#RGB_analog_component_video
Hmm, Wikipedia seem to contradict itself :)
https://en.wikipedia.org/wiki/VGA_connector
In the video signal box... but yeah, it seems like it's needed in VGA.
> >> And you have one pin left that you can use for composite, which would
> >> likely be fed from the other TCON, as you need interlaced YUV data,
> >> which is like the opposite of VGA.
> >
> > I'm not sure how these muxers should be implemented in DRM. One
> > trivial way would be to have a small pinctrl driver in the TCON driver
> > to deal with that, and switch states in both TV encoders at runtime
> > (if needed, statically otherwise).
> >
> > Or maybe we can do something simpler, I don't know.
>
> Pinctrl or pinctrl like seems to be a good solution. The lines are routed
> on the board so it doesn't make sense to have something runtime configurable.
> We just need to know which pins are in the same group, and what kind of
> signals they each expect.
I discussed this with Boris yesterday, and he also pointed out that
there is another solution that might work. The global DRM device also
has an atomic_check method we could use to check that we aren't using
an impossible combination (2 VGA outputs for example), and assign the
pins properly between the two blocks that need them.
This would be easier to implement than a pinctrl driver.
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/20170420/267ccdb3/attachment-0001.sig>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: icenowy at aosc.io @ 2017-04-20 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420055802.btibui5pspan4qal@lukather>
? 2017-04-20 13:58?Maxime Ripard ???
> On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote:
>>
>>
>> ? 2017?4?18? GMT+08:00 ??3:00:16, Maxime Ripard
>> <maxime.ripard@free-electrons.com> ??:
>> >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote:
>> >> Allwinner A64 SoC features a NMI controller, which is usually
>> >connected
>> >> to the AXP PMIC.
>> >>
>> >> Add support for it.
>> >>
>> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> >> Acked-by: Chen-Yu Tsai <wens@csie.org>
>> >> ---
>> >> Changes in v2:
>> >> - Added Chen-Yu's ACK.
>> >>
>> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
>> >> 1 file changed, 8 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> index 05ec9fc5e81f..53c18ca372ea 100644
>> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> @@ -403,6 +403,14 @@
>> >> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>> >> };
>> >>
>> >> + nmi_intc: interrupt-controller at 01f00c0c {
>> >> + compatible = "allwinner,sun6i-a31-sc-nmi";
>> >> + interrupt-controller;
>> >> + #interrupt-cells = <2>;
>> >> + reg = <0x01f00c0c 0x38>;
>> >
>> >The base address is not correct, and there's uncertainty on whether
>> >this is this particular controller or not. Did you even test this?
>>
>> Tested by axp20x-pek.
>
> Still, the base address is wrong, which is yet another hint that this
> is not the same interrupt controller, and just works by accident.
No, it's the same as other post-sun6i device trees.
See other post-sun6i device trees: (or maybe they're all wrong, but
as we have no document for it, we should temporarily keep them)
sun6i-a31.dtsi
```
nmi_intc: interrupt-controller at 01f00c0c {
compatible = "allwinner,sun6i-a31-sc-nmi";
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x01f00c0c 0x38>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
};
```
sun8i-a23-a33.dtsi
```
nmi_intc: interrupt-controller at 01f00c0c {
compatible = "allwinner,sun6i-a31-sc-nmi";
interrupt-controller;
#interrupt-cells = <2>;
reg = <0x01f00c0c 0x38>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
};
```
But according to the BSP device tree, the base address should be
0x01f00c00. Should I send some patch to fix all of them? (but it will
break device tree compatibility)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Mikko Perttunen @ 2017-04-20 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419182413.866327-1-arnd@arndb.de>
On 19.04.2017 21:24, Arnd Bergmann wrote:
> When dma_addr_t and phys_addr_t are not the same size, we get a warning
> from the dma_alloc_wc function:
>
> drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
> drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of 'dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types]
> pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> ^
> In file included from drivers/gpu/host1x/cdma.c:22:0:
> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
> static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev, size_t size,
> ^~~~~~~~~~~~
> drivers/gpu/host1x/cdma.c:113:48: error: passing argument 3 of 'dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types]
> pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> ^
> In file included from drivers/gpu/host1x/cdma.c:22:0:
> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
> static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev, size_t size,
> ^~~~~~~~~~~~
>
> The problem here is that dma_alloc_wc() returns a pointer to a dma_addr_t
> that may already be translated by an IOMMU, but the driver passes this
> into iommu_map() as a physical address. This works by accident only when
> the IOMMU does not get registered with the DMA API and there is a 1:1
> mapping between physical addresses as seen by the CPU and the device.
>
> The fundamental problem here is the lack of a generic API to do what the
> driver wants: allocating CPU-visible memory for use by a device through
> user-defined IOMMU settings. Neither the dma-mapping API nor the IOMMU
> API can do this by itself, and combining the two is not well-defined.
>
> This patch addresses the type mismatch by adding a third pointer into the
> push_buffer structure: in addition to the address as seen from the CPU
> and the address inside of the local IOMMU domain, the pb->alloc pointer
> is the token returned by dma_alloc_wc(), and this is what we later need
> to pass into dma_free_wc().
>
> The address we pass into iommu_map() however is the physical address
> computed from virt_to_phys(), assuming that the pointer we have here
> is part of the linear mapping (which is also questionable, e.g. when we
> have a non-coherent device on ARM32 this may be false). Also, when
> the DMA API uses the IOMMU to allocate the pointer for the default
> domain, we end up with two IOMMU mappings for the same physical address.
>
I think we have a "policy" on Tegra that the DMA API will never allocate
using the IOMMU (Thierry can elaborate on this), which is why I wrote
the code with that assumption. Essentially, we have made the DMA API
into the API that allocates CPU-visible memory.
Considering that, I'm wondering if we can just have a temporary local
dma_addr_t and then cast that to phys_addr_t, combined with a good comment?
Cheers,
Mikko.
> Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/gpu/host1x/cdma.c | 26 ++++++++++----------------
> drivers/gpu/host1x/cdma.h | 1 +
> 2 files changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> index 28541b280739..286edeca7ba1 100644
> --- a/drivers/gpu/host1x/cdma.c
> +++ b/drivers/gpu/host1x/cdma.c
> @@ -59,7 +59,7 @@ static void host1x_pushbuffer_destroy(struct push_buffer *pb)
> free_iova(&host1x->iova, iova_pfn(&host1x->iova, pb->dma));
> }
>
> - dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->phys);
> + dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->alloc);
>
> pb->mapped = NULL;
> pb->phys = 0;
> @@ -81,20 +81,21 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
> pb->size = HOST1X_PUSHBUFFER_SLOTS * 8;
>
> size = pb->size + 4;
> + if (host1x->domain)
> + size = iova_align(&host1x->iova, size);
>
> /* initialize buffer pointers */
> pb->fence = pb->size - 8;
> pb->pos = 0;
>
> - if (host1x->domain) {
> - unsigned long shift;
> + pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->alloc, GFP_KERNEL);
> + if (!pb->mapped)
> + return -ENOMEM;
>
> - size = iova_align(&host1x->iova, size);
> + pb->phys = virt_to_phys(pb->mapped);
>
> - pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> - GFP_KERNEL);
> - if (!pb->mapped)
> - return -ENOMEM;
> + if (host1x->domain) {
> + unsigned long shift;
>
> shift = iova_shift(&host1x->iova);
> alloc = alloc_iova(&host1x->iova, size >> shift,
> @@ -109,13 +110,6 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
> IOMMU_READ);
> if (err)
> goto iommu_free_iova;
> - } else {
> - pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> - GFP_KERNEL);
> - if (!pb->mapped)
> - return -ENOMEM;
> -
> - pb->dma = pb->phys;
> }
>
> pb->alloc_size = size;
> @@ -127,7 +121,7 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
> iommu_free_iova:
> __free_iova(&host1x->iova, alloc);
> iommu_free_mem:
> - dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->phys);
> + dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->alloc);
>
> return err;
> }
> diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
> index ec170a78f4e1..8479192d4265 100644
> --- a/drivers/gpu/host1x/cdma.h
> +++ b/drivers/gpu/host1x/cdma.h
> @@ -43,6 +43,7 @@ struct host1x_job;
>
> struct push_buffer {
> void *mapped; /* mapped pushbuffer memory */
> + dma_addr_t alloc; /* device address in root domain */
> dma_addr_t dma; /* device address of pushbuffer */
> phys_addr_t phys; /* physical address of pushbuffer */
> u32 fence; /* index we've written */
>
^ permalink raw reply
* [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Corentin Labbe @ 2017-04-20 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9382f9ae-895a-397b-3d8c-846cb0bc4486@arm.com>
On Thu, Apr 20, 2017 at 12:38:50AM +0100, Andr? Przywara wrote:
> On 12/04/17 12:13, Corentin Labbe wrote:
> > This patch adds documentation for Device-Tree bindings for the
> > syscon present in allwinner devices.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > .../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> > new file mode 100644
> > index 0000000..c056c5b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> > @@ -0,0 +1,19 @@
> > +* Allwinner sun8i system controller
> > +
> > +This file describes the bindings for the system controller present in
> > +Allwinner SoC H3, A83T and A64.
> > +The principal function of this syscon is to control EMAC PHY choice and
> > +config.
> > +
> > +Required properties for the system controller:
> > +- reg: address and length of the register for the device.
> > +- compatible: should be "syscon" and one of the following string:
> > + "allwinner,sun8i-h3-system-controller"
> > + "allwinner,sun8i-a64-system-controller"
>
> While sun8i might make some sense technically, all 64-bit sunxi
> compatible strings use the sun50i prefix to follow the Allwinner naming.
> So this should read:
> "allwinner,sun50i-a64-system-controller"
>
> Also I am wondering if we should add a compatible string for the H5
> (support for that SoC is in -next already):
> "allwinner,sun50i-h5-system-controller"
>
> Cheers,
> Andre.
>
I agree with sun50i-a64-system-controller, the sun8i-a64 is a copy/paste error.
I will add sun50i-h5-system-controller since all xxx-system-controller are just hypothetic compatible.
Thanks
Regards
^ permalink raw reply
* [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Heiko Stuebner @ 2017-04-20 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <319a2a72-ca25-08d7-68dc-7eae74f1a622@collabora.com>
Hi Guillaume,
Am Donnerstag, 20. April 2017, 06:44:56 CEST schrieb Guillaume Tucker:
> On 19/04/17 09:59, Heiko Stuebner wrote:
> > Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker:
> >> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
> >> opp table.
> >>
> >> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> >> ---
> >> arch/arm/boot/dts/rk3288.dtsi | 22 ++++++++++++++++++++++
> >> 1 file changed, 22 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> >> index df8a0dbe9d91..187eed528f83 100644
> >> --- a/arch/arm/boot/dts/rk3288.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >> @@ -43,6 +43,7 @@
> >> #include <dt-bindings/interrupt-controller/arm-gic.h>
> >> #include <dt-bindings/pinctrl/rockchip.h>
> >> #include <dt-bindings/clock/rk3288-cru.h>
> >> +#include <dt-bindings/power/rk3288-power.h>
> >> #include <dt-bindings/thermal/thermal.h>
> >> #include <dt-bindings/power/rk3288-power.h>
> >> #include <dt-bindings/soc/rockchip,boot-mode.h>
> >> @@ -227,6 +228,27 @@
> >> ports = <&vopl_out>, <&vopb_out>;
> >> };
> >>
> >> + gpu: mali at ffa30000 {
> >
> > please sort nodes by address. ffa30000 should be placed below hdmi at ff980000
> > and above qos at ffaa0000 .
>
> Sure, will fix that in v4.
>
> >> + compatible = "arm,mali-t760", "arm,mali-midgard";
> >
> > As indicated before I don't trust that a generic binding will work for
> > everything, so I would feel safer if we had a "rockchip,rk3288-mali" in
> > front for future purposes, making it a
> >
> > compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
>
> OK, sorry I overlooked this part. I'll add it in v4 with a
> vendor compatible string in the binding documentation.
great, thanks :-)
>
> >> + reg = <0xffa30000 0x10000>;
> >> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-names = "job", "mmu", "gpu";
> >> + clocks = <&cru ACLK_GPU>;
> >> + operating-points = <
> >> + /* KHz uV */
> >> + 100000 950000
> >> + 200000 950000
> >> + 300000 1000000
> >> + 400000 1100000
> >> + 500000 1200000
> >> + 600000 1250000
> >> + >;
> >
> > Wasn't there a wish for opp-v2 in a previous version?
>
> Well it wasn't entirely clear to me in Rob's email whether it was
> necessary to use opp-v2 now or rather if it would be a potential
> option whenever opp-v2 was needed. If operating-points (v1) are
> being deprecated then I can change that in my next patch v4.
> Using operating-points-v2 with the Mali driver works as far as I
> can tell on rk3288 so that's not an issue.
I don't care to much either way, just remembered it being mentioned
in the previous version. So lets see what Rob says.
Heiko
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-20 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5481965.3RkcDb038R@phil>
Hi Heiko,
On 19/04/17 10:02, Heiko Stuebner wrote:
> Am Mittwoch, 19. April 2017, 09:06:17 CEST schrieb Guillaume Tucker:
>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>> new file mode 100644
>> index 000000000000..917c4f8d178f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>> @@ -0,0 +1,57 @@
>> +ARM Mali Midgard GPU
>> +====================
>> +
>> +Required properties:
>> +
>> +- compatible :
>> + * Must be one of the following:
>> + + "arm,mali-t60x"
>> + + "arm,mali-t62x"
>> + + "arm,mali-t720"
>> + + "arm,mali-t760"
>> + + "arm,mali-t820"
>> + + "arm,mali-t830"
>> + + "arm,mali-t860"
>> + + "arm,mali-t880"
>> + * And, optionally, one of the vendor specific compatible:
>> + + "amlogic,meson-gxm-mali"
>
> Please add a "rockchip,rk3288-mali" as well :-) , as I don't trust that the
> generic compatible will be enough for all time and having that already
> defined makes fixing the per soc things later a lot easier.
Sure, will do in patch v4.
>> +
>> +- reg : Physical base address of the device and length of the register area.
>> +
>> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
>> +
>> +- interrupt-names : Contains the names of IRQ resources in the order they were
>> + provided in the interrupts property. Must contain: "job", "mmu", "gpu".
>> +
>> +
>> +Optional properties:
>> +
>> +- clocks : Phandle to clock for the Mali Midgard device.
>> +
>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>> +
>> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
>> + for details.
So I can simply change that to operating-points-v2. Both
versions can be used in practice but it sounds like
operating-points can just be ignored in this binding's
documentation. Could you please confirm?
Thanks,
Guillaume
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: Maxime Ripard @ 2017-04-20 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <FB3B3C68-EB16-4352-B0B9-64857B1A6C03@aosc.io>
On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote:
>
>
> ? 2017?4?18? GMT+08:00 ??3:00:16, Maxime Ripard <maxime.ripard@free-electrons.com> ??:
> >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote:
> >> Allwinner A64 SoC features a NMI controller, which is usually
> >connected
> >> to the AXP PMIC.
> >>
> >> Add support for it.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> Acked-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> Changes in v2:
> >> - Added Chen-Yu's ACK.
> >>
> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> index 05ec9fc5e81f..53c18ca372ea 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> @@ -403,6 +403,14 @@
> >> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> >> };
> >>
> >> + nmi_intc: interrupt-controller at 01f00c0c {
> >> + compatible = "allwinner,sun6i-a31-sc-nmi";
> >> + interrupt-controller;
> >> + #interrupt-cells = <2>;
> >> + reg = <0x01f00c0c 0x38>;
> >
> >The base address is not correct, and there's uncertainty on whether
> >this is this particular controller or not. Did you even test this?
>
> Tested by axp20x-pek.
Still, the base address is wrong, which is yet another hint that this
is not the same interrupt controller, and just works by accident.
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/20170420/e5ed6016/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Guillaume Tucker @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5403013.fQWx48MQOq@phil>
Hi Heiko,
On 19/04/17 09:59, Heiko Stuebner wrote:
> Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker:
>> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
>> opp table.
>>
>> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>> ---
>> arch/arm/boot/dts/rk3288.dtsi | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
>> index df8a0dbe9d91..187eed528f83 100644
>> --- a/arch/arm/boot/dts/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>> @@ -43,6 +43,7 @@
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/pinctrl/rockchip.h>
>> #include <dt-bindings/clock/rk3288-cru.h>
>> +#include <dt-bindings/power/rk3288-power.h>
>> #include <dt-bindings/thermal/thermal.h>
>> #include <dt-bindings/power/rk3288-power.h>
>> #include <dt-bindings/soc/rockchip,boot-mode.h>
>> @@ -227,6 +228,27 @@
>> ports = <&vopl_out>, <&vopb_out>;
>> };
>>
>> + gpu: mali at ffa30000 {
>
> please sort nodes by address. ffa30000 should be placed below hdmi at ff980000
> and above qos at ffaa0000 .
Sure, will fix that in v4.
>> + compatible = "arm,mali-t760", "arm,mali-midgard";
>
> As indicated before I don't trust that a generic binding will work for
> everything, so I would feel safer if we had a "rockchip,rk3288-mali" in
> front for future purposes, making it a
>
> compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
OK, sorry I overlooked this part. I'll add it in v4 with a
vendor compatible string in the binding documentation.
>> + reg = <0xffa30000 0x10000>;
>> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "job", "mmu", "gpu";
>> + clocks = <&cru ACLK_GPU>;
>> + operating-points = <
>> + /* KHz uV */
>> + 100000 950000
>> + 200000 950000
>> + 300000 1000000
>> + 400000 1100000
>> + 500000 1200000
>> + 600000 1250000
>> + >;
>
> Wasn't there a wish for opp-v2 in a previous version?
Well it wasn't entirely clear to me in Rob's email whether it was
necessary to use opp-v2 now or rather if it would be a potential
option whenever opp-v2 was needed. If operating-points (v1) are
being deprecated then I can change that in my next patch v4.
Using operating-points-v2 with the Mali driver works as far as I
can tell on rk3288 so that's not an issue.
Thanks,
Guillaume
^ permalink raw reply
* [PATCH V4 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
Compiling the DT file with W=1, DTC warns like follows:
Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
unit name, but no reg property
Fix this by replacing '@' with '-' as the OPP nodes will never have a
"reg" property.
Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index b850b2cd0adc..2c7dc69987df 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -118,27 +118,27 @@
compatible = "operating-points-v2";
opp-shared;
- opp at 500000000 {
+ opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
clock-latency-ns = <500000>;
};
- opp at 648000000 {
+ opp-648000000 {
opp-hz = /bits/ 64 <648000000>;
clock-latency-ns = <500000>;
};
- opp at 800000000 {
+ opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
clock-latency-ns = <500000>;
};
- opp at 1000000000 {
+ opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
clock-latency-ns = <500000>;
};
- opp at 1188000000 {
+ opp-1188000000 {
opp-hz = /bits/ 64 <1188000000>;
clock-latency-ns = <500000>;
};
--
2.12.0.432.g71c3a4f4ba37
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox