* [PATCH v3 03/21] ARM: dts: omap: Add generic compatible string for I2C EEPROM
From: Rob Herring @ 2017-04-19 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414010445.21727-4-javier@osg.samsung.com>
On Thu, Apr 13, 2017 at 10:04:27PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/am335x-baltos.dtsi | 2 +-
> arch/arm/boot/dts/am335x-base0033.dts | 2 +-
> arch/arm/boot/dts/am335x-bone-common.dtsi | 10 +++++-----
> arch/arm/boot/dts/am335x-nano.dts | 2 +-
> arch/arm/boot/dts/am335x-pepper.dts | 2 +-
> arch/arm/boot/dts/am335x-shc.dts | 2 +-
> arch/arm/boot/dts/am335x-sl50.dts | 2 +-
> arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
> arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
> arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
> arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 2 +-
> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> arch/arm/boot/dts/omap3-sb-t35.dtsi | 2 +-
> arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 +-
> arch/arm/boot/dts/omap5-cm-t54.dts | 2 +-
> arch/arm/boot/dts/omap5-sbc-t54.dts | 2 +-
> 17 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
> index d42b98f15e8b..6ca780d0623f 100644
> --- a/arch/arm/boot/dts/am335x-baltos.dtsi
> +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
> @@ -255,7 +255,7 @@
> };
>
> at24 at 50 {
> - compatible = "at24,24c02";
> + compatible = "at24,24c02", "atmel,24c02";
I think you can just drop the at24 compatibles. A new kernel doesn't
need it. An old kernel ignores the manufacturer. I checked that u-boot
only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
couldn't find anything.
Minimally, the deprecated compatible should come last.
Rob
^ permalink raw reply
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jon Masters @ 2017-04-19 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414001911.GA13163@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn, JC,
On 04/13/2017 08:19 PM, Bjorn Helgaas wrote:
> I tentatively applied both patches to pci/host-thunder for v4.12.
Thanks for that :)
> However, I am concerned about the topology here:
Various feedback has been provided on this one over the past $time. In
addition, I have requested that this serve as an example of why we need
a more complete PCIe integration guide for ARMv8. It's on the list of
things for my intended opus magnum on the topic ;)
> On Thu, Apr 13, 2017 at 08:30:45PM +0000, Jayachandran C wrote:
>> On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the
>> PCI topology is slightly unusual. For a multi-node system, it looks
>> like:
>>
>> 00:00.0 [PCI] bridge to [bus 01-1e]
>> 01:0a.0 [PCI-PCIe bridge, type 8] bridge to [bus 02-04]
>> 02:00.0 [PCIe root port, type 4] bridge to [bus 03-04] (XLATE_ROOT)
>> 03:00.0 PCIe Endpoint
>
> A root port normally has a single PCIe link leading downstream.
In integration terms, there's always a bus on the other side of the RC.
It's just usually a processor local bus of some kind on a proprietary
interconnect, but there's always something there. The issue is when you
can see it as PCIe and it's not through a transparent glue bridge.
I had originally hoped that the ECAM could be hacked up so that we would
first walk the topology at the 02:00.0 as a root and not see what's
above it BUT there are other device attachments up there for the on-SoC
devices and I think we really intend to use those.
Bottom line in my opinion is document this case, use it as a learning
example, and move forward. This has been useful in justifying why we
need better integration documentation from the server community. And in
particular from the OS vendors, of which I guess we can allude to their
being more than Linux interested in ARM server these days ;)
Jon.
--
Computer Architect | Sent from my Fedora powered Ryzen
^ permalink raw reply
* [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: André Przywara @ 2017-04-19 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412111400.2296-5-clabbe.montjoie@gmail.com>
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.
> + "allwinner,sun8i-a83t-system-controller"
> +
> +Example:
> +syscon: syscon at 01c00000 {
> + compatible = "allwinner,sun8i-h3-system-controller", "syscon";
> + reg = <0x01c00000 0x1000>;
> +};
>
^ permalink raw reply
* [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page
From: Shuah Khan @ 2017-04-19 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414094643.GG17774@n2100.armlinux.org.uk>
Hi Russell, and Marek,
On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
>>>> This would be however quite large task, especially taking into account
>>>> all current users of DMA-buf framework...
>>> Yeah it will be a large task.
>>
>> Maybe once scatterlist are switched to pfns, changing dmabuf internal
>> memory representation to pfn array might be much easier.
>
> Switching to a PFN array won't work either as we have no cross-arch
> way to translate PFNs to a DMA address and vice versa. Yes, we have
> them in ARM, but they are an _implementation detail_ of ARM's
> DMA API support, they are not for use by drivers.
>
> So, the very first problem that needs solving is this:
>
> How do we go from a coherent DMA allocation for device X to a set
> of DMA addresses for device Y.
>
> Essentially, we need a way of remapping the DMA buffer for use with
> another device, and returning a DMA address suitable for that device.
> This could well mean that we need to deal with setting up an IOMMU
> mapping. My guess is that this needs to happen at the DMA coherent
> API level - the DMA coherent API needs to be augmented with support
> for this. I'll call this "DMA coherent remap".
>
> We then need to think about how to pass this through the dma-buf API.
> dma_map_sg() is done by the exporter, who should know what kind of
> memory is being exported. The exporter can avoid calling dma_map_sg()
> if it knows in advance that it is exporting DMA coherent memory.
> Instead, the exporter can simply create a scatterlist with the DMA
> address and DMA length prepopulated with the results of the DMA
> coherent remap operation above.
As Russell pointed to armama-drm case, I looked at that closely.
armada-drm is creating sg_table and populating it with DMA-address in
its map_dma_buf ops and unmap_dma_buf ops handles the special case and
doesn't call dma_unmap_sg().
In the case of drm, gem_prime_map_dma_buf interfaces and the common
drm_gem_map_dma_buf() will need modification to not do dma_map_sg()
and create scatterlist with the DMA address and DMA length instead.
We have to get drm_gem_map_dma_buf() info. to have it not do dma_map_sg()
and create scatterlist.
Focusing on drm for now, looks like there are probably about 15 or so
map_dma_buf interfaces will need to handle coherent memory case.
>
> What the scatterlist can't carry in this case is a set of valid
> struct page pointers, and an importer must not walk the scatterlist
> expecting to get at the virtual address parameters or struct page
> pointers.
Right - importers need handling to not walk the sg_list and handle
it differently. Is there a good example drm you can point me to for
this? aramda-drm seems to special case this in armada_gem_map_import()
if I am not mistaken.
>
> On the mmap() side of things, remember that DMA coherent allocations
> may require special mapping into userspace, and which can only be
> mapped by the DMA coherent mmap support. kmap etc will also need to
> be different. So it probably makes sense for DMA coherent dma-buf
> exports to use a completely separate set of dma_buf_ops from the
> streaming version.
>
I agree. It would make is easier and also limits the scope of changes.
> I think this is the easiest approach to solving the problem without
> needing massive driver changes all over the kernel.
>
Anyway this is a quick note to say that I am looking into this and
haven't drooped it :)
thanks,
-- Shuah
^ permalink raw reply
* [GIT PULL] ARM: SOC PM domain for 4.12
From: santosh.shilimkar at oracle.com @ 2017-04-19 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0jtLFgzB-u1Prhn1AvPH3OzLZ=uc--YP4fo9-7irikag@mail.gmail.com>
+Dave,
On 4/19/17 12:56 PM, Arnd Bergmann wrote:
> On Thu, Apr 6, 2017 at 7:42 PM, Santosh Shilimkar <ssantosh@kernel.org> wrote:
>> Hi Arnd, Olof,
>>
>> As inidcated on the list, because of various dependencies, am senidng
>> Dave Gerlach's full patchset in single pull request.
>>
>> The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:
>>
>> Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/arm-soc-pmdomain
>>
>> for you to fetch changes up to ae3874cc931b760c08bd6617a45fec1ba97d87f8:
>>
>> ARM: keystone: Drop PM domain support for k2g (2017-04-04 08:59:28 -0700)
>>
>> ----------------------------------------------------------------
>> ARM SOC PM domain support for 4.12
>>
>> Dave Gerlach (5):
>> PM / Domains: Add generic data pointer to genpd data struct
>> PM / Domains: Do not check if simple providers have phandle cells
>> dt-bindings: Add TI SCI PM Domains
>> soc: ti: Add ti_sci_pm_domains driver
>> ARM: keystone: Drop PM domain support for k2g
>
> I went through the list of arm at kernel.org emails that had not seen a reply after
> Olof's pull marathon today. I did not get a reply for this one, but I
> see that Olof
> has merged it into next/drivers.
>
Thanks.
> 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...
>
Dave, please care to follow up Arnd's concerns on those defines.
Regards,
Santosh
^ permalink raw reply
* [PATCH v2] soc: brcmstb: enable drivers for ARM64 and BMIPS
From: Markus Mayer @ 2017-04-19 22:50 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Mayer <mmayer@broadcom.com>
We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64 and
BMIPS.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
---
I used (COMPILE_TEST & OF) as condition like Raspberry Pi, since we
have of_* calls in our code, too.
Changes since v1:
- Add BMIPS
- Add COMPILE_TEST
drivers/soc/bcm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
index a39b0d58ddd0..9463d6709909 100644
--- a/drivers/soc/bcm/Kconfig
+++ b/drivers/soc/bcm/Kconfig
@@ -11,7 +11,7 @@ config RASPBERRYPI_POWER
config SOC_BRCMSTB
bool "Broadcom STB SoC drivers"
- depends on ARM
+ depends on ARM || ARM64 || BMIPS_GENERIC || (COMPILE_TEST && OF)
select SOC_BUS
help
Enables drivers for the Broadcom Set-Top Box (STB) series of chips.
--
2.12.0
^ permalink raw reply related
* linux-next: manual merge of the at91 tree with the arm-soc tree
From: Stephen Rothwell @ 2017-04-19 22:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nicolas,
Today's linux-next merge of the at91 tree got a conflict in:
arch/arm/boot/dts/at91-tse850-3.dts
between commit:
e67cedc92812 ("ARM: dts: at91: add envelope detector mux to the Axentia TSE-850")
from the arm-soc tree and commit:
29dd89418007 ("ARM: dts: at91: add envelope detector mux to the Axentia TSE-850")
from the at91 tree.
I fixed it up (I used the arm-soc tree version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH V3] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-19 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419142215.GA12105@localhost>
On Wednesday, April 19, 2017 07:22:15 AM Olof Johansson wrote:
> Hi Viresh,
>
> On Tue, Apr 18, 2017 at 10:44:50AM +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> (sunxi)
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
> > Acked-by: Rob Herring <robh@kernel.org>
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> We've already turned down other patches that does this in a sweeping manner
> like this, since they tend to be conflict prone with other DT changes.
>
> Please split per platform and merge with each maintainer.
OK
So I'm assuming that you guys will take care of this going forward.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 2/4] net: macb: Add tsu_clk to device tree
From: Rob Herring @ 2017-04-19 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492090686-14778-1-git-send-email-rafalo@cadence.com>
On Thu, Apr 13, 2017 at 02:38:06PM +0100, Rafal Ozieblo wrote:
> Signed-off-by: Rafal Ozieblo <rafalo@cadence.com>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH V2] ARM: dts: BCM5301X: Specify MDIO bus in the DT
From: Rafał Miłecki @ 2017-04-19 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170402210840.11429-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
V2: Disable MDIO bus by default.
Add mdio label to allow enabling it easily per board
---
arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..1f34bc6905f2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,14 @@
};
};
+ mdio: mdio at 18003000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18003000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+ status = "disabled";
+ };
+
i2c0: i2c at 18009000 {
compatible = "brcm,iproc-i2c";
reg = <0x18009000 0x50>;
--
2.11.0
^ permalink raw reply related
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Doug Anderson @ 2017-04-19 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <212870399.174480.1492633502649@email.1und1.de>
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?
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().
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. 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...
> chrdev_open 87 85716519 us 985247.3 us 1951112835 us
> tty_open 3 85714494 us 28571498 us 3743206849 us
> tty_port_open 3 85712603 us 28570867 us 1968003468 us
> serial_open 1 85712472 us 85712472 us 0.000 us
> serial_port_activate 1 85709890 us 85709890 us 0.000 us
> pl2303_open 1 85709875 us 85709875 us 0.000 us
> usb_serial_generic_open 1 85701170 us 85701170 us 0.000 us
> usb_serial_generic_submit_read 1 85701166 us 85701166 us 0.000 us
> usb_serial_generic_submit_read 2 85701160 us 42850580 us 2252410463 us
> handle_irq_event 1082482 80686112 us 74.538 us 36417905 us
> handle_irq_event_percpu 1082482 78398378 us 72.424 us 34060119 us
> __handle_irq_event_percpu 1082482 68466046 us 63.249 us 53609076 us
> usb_hcd_irq 1078945 59761116 us 55.388 us 25139388 us
> _dwc2_hcd_irq 1078945 57481606 us 53.275 us 30847036 us
> dwc2_handle_hcd_intr 1078945 55380910 us 51.328 us 35986237 us
> do_idle 394 43577379 us 110602.4 us 84278209 us
> dwc2_hc_n_intr 651065 42408491 us 65.137 us 7281229 us
> default_idle_call 229969 38021287 us 165.332 us 11386904 us
> arch_cpu_idle 229969 37379305 us 162.540 us 2168909 us
> dwc2_halt_channel 650811 34208348 us 52.562 us 7792012 us
> dwc2_release_channel 651065 33042638 us 50.751 us 8112754 us
> dwc2_hc_nak_intr 334689 18892951 us 56.449 us 1823592 us
> dwc2_hc_ack_intr 315986 18323433 us 57.988 us 151346.6 us
> dwc2_hcd_select_transactions 1730010 11694955 us 6.760 us 1188442 us
> dwc2_hcd_queue_transactions 651065 10931854 us 16.790 us 952074.2 us
> dwc2_assign_and_init_hc 651065 9540885 us 14.654 us 258067.1 us
> dwc2_queue_transaction 651065 9192559 us 14.119 us 736431.6 us
> tick_nohz_irq_exit 325055 9052192 us 27.848 us 916293.3 us
> __tick_nohz_idle_enter.constpr 324760 8463861 us 26.061 us 2410440 us
> dwc2_hc_start_transfer 651065 7687376 us 11.807 us 625773.3 us
> irq_enter 1082482 6627959 us 6.122 us 11528932 us
> arm_heavy_mb 10903913 6603586 us 0.605 us 60562924 us
> unmask_irq 1082482 4763699 us 4.400 us 1032638 us
> tick_irq_enter 326467 4377088 us 13.407 us 4606805 us
> dwc2_handle_common_intr 1078945 3799392 us 3.521 us 1131504 us
> add_interrupt_randomness 1082482 3542044 us 3.272 us 30545511 us
> get_next_armctrl_hwirq 1443829 3276974 us 2.269 us 2116848 us
> tick_nohz_restart 70325 3250462 us 46.220 us 35710.73 us
> dwc2_hc_cleanup 651065 3079003 us 4.729 us 81202.50 us
> dwc2_hcd_qh_deactivate 651065 3039940 us 4.669 us 90928.10 us
> ledtrig_cpu 459938 2450327 us 5.327 us 1466705 us
> arch_cpu_idle_exit 229969 2443315 us 10.624 us 8606787 us
> do_page_fault 5509 2304998 us 418.405 us 17961439 us
> ktime_get 795998 2121741 us 2.665 us 166119.5 us
> get_next_timer_interrupt 324760 1998999 us 6.155 us 32201.63 us
> handle_mm_fault 5537 1945500 us 351.363 us 8324917 us
> dwc2_is_controller_alive 2157890 1473590 us 0.682 us 291399.4 us
> hrtimer_cancel 70450 1394330 us 19.791 us 36980.28 us
> arch_cpu_idle_enter 229969 1350759 us 5.873 us 10789.94 us
> hrtimer_try_to_cancel 71029 1266967 us 17.837 us 30260.75 us
> filemap_map_pages 1632 1263006 us 773.900 us 207846.4 us
> tick_program_event 141799 1260485 us 8.889 us 9343.194 us
> hrtimer_start_range_ns 97555 1253698 us 12.851 us 43166.94 us
> irq_to_desc 1082482 1146955 us 1.059 us 546937.6 us
> link_path_walk 3486 1134351 us 325.401 us 484443.0 us
> __remove_hrtimer 99205 999724.0 us 10.077 us 201933.9 us
> clockevents_program_event 141799 985346.0 us 6.948 us 7114.725 us
> note_interrupt 1082482 899494.0 us 0.830 us 705141.6 us
> update_ts_time_stats.constprop 324760 862996.0 us 2.657 us 21813.81 us
> alloc_set_pte 20011 805880.0 us 40.271 us 1086748 us
> SyS_read 1940 805061.0 us 414.979 us 164198.7 us
> _local_bh_enable 326467 777908.0 us 2.382 us 37202.43 us
> vfs_read 2080 761487.0 us 366.099 us 22944777 us
> dwc2_hcd_get_frame_number 1097673 721108.0 us 0.656 us 525348.1 us
> do_munmap 1194 717161.0 us 600.637 us 65635.31 us
> schedule 3297 700578.0 us 212.489 us 28594.59 us
> __vfs_read 2080 694376.0 us 333.834 us 21955675 us
> walk_component 9912 683211.0 us 68.927 us 349771.7 us
> irq_find_mapping 1082482 673162.0 us 0.621 us 900861.5 us
> __next_timer_interrupt 324929 667175.0 us 2.053 us 4576.720 us
> armctrl_translate_shortcut 1079274 662875.0 us 0.614 us 164464.8 us
> filename_lookup 1316 646059.0 us 490.926 us 148884.8 us
> mmput 259 644417.0 us 2488.096 us 33155247 us
> armctrl_unmask_irq 1082482 639692.0 us 0.590 us 891074.7 us
> armctrl_mask_irq 1082482 636505.0 us 0.588 us 888583.1 us
> exit_mmap 45 634389.0 us 14097.53 us 24105769 us
> irq_state_set_masked 1082482 622182.0 us 0.574 us 894212.6 us
> user_path_at_empty 1156 620229.0 us 536.530 us 166865.3 us
> SyS_munmap 895 600613.0 us 671.075 us 75763.68 us
> vm_mmap_pgoff 1437 598955.0 us 416.809 us 55882.41 us
> read_current_timer 1082666 598757.0 us 0.553 us 86817.59 us
> irq_may_run 1082482 598471.0 us 0.552 us 898308.6 us
> vm_munmap 937 595309.0 us 635.335 us 70914.31 us
> path_lookupat 1316 592448.0 us 450.188 us 147624.4 us
> SyS_mmap_pgoff 1325 588992.0 us 444.522 us 62142.49 us
> irq_state_clr_masked 1082482 582077.0 us 0.537 us 893572.4 us
> idle_cpu 1082482 580428.0 us 0.536 us 905609.5 us
> do_execve 28 573864.0 us 20495.14 us 98356111 us
> do_execveat_common 28 573576.0 us 20484.85 us 98471441 us
> dwc2_hc_set_even_odd_frame 651065 570127.0 us 0.875 us 543701.5 us
> ledtrig_cpu.part.0 229969 549060.0 us 2.387 us 9142.920 us
> do_mmap 1437 548817.0 us 381.918 us 54270.64 us
> do_work_pending 2211 525805.0 us 237.813 us 234836.0 us
> led_trigger_event 460228 501093.0 us 1.088 us 4759241 us
> search_binary_handler 28 501026.0 us 17893.78 us 93445723 us
> clocksource_mmio_readl_up 807791 500765.0 us 0.619 us 91050.42 us
> load_elf_binary 28 500359.0 us 17869.96 us 93309220 us
> process_one_work 558 496994.0 us 890.670 us 7196614 us
> tick_do_update_jiffies64 324826 496168.0 us 1.527 us 3422867 us
> hrtimer_forward 72095 490887.0 us 6.808 us 4548.034 us
> unmap_vmas 1239 490538.0 us 395.914 us 2723415 us
> finish_task_switch 3926 479983.0 us 122.257 us 25336.71 us
> unmap_single_vma 3403 474812.0 us 139.527 us 959184.6 us
> __sync_icache_dcache 27231 468069.0 us 17.188 us 364740.1 us
> SyS_execve 16 462210.0 us 28888.12 us 4450186 us
> unmap_region 1194 460297.0 us 385.508 us 44372.58 us
> unmap_page_range 3403 455941.0 us 133.982 us 956896.1 us
> bcm2835_time_interrupt 3208 455584.0 us 142.014 us 56012.72 us
> mmap_region 1437 449599.0 us 312.873 us 55175.49 us
> hrtimer_interrupt 3208 443908.0 us 138.375 us 55446.73 us
> dwc2_hcd_qh_add 632341 436511.0 us 0.690 us 58787.66 us
> lookup_fast 11601 436227.0 us 37.602 us 570183.6 us
> inode_permission 14699 426528.0 us 29.017 us 404007.8 us
> SyS_access 561 412200.0 us 734.759 us 146663.8 us
> dwc2_hcd_qh_unlink 632344 410157.0 us 0.648 us 87505.07 us
> seq_read 669 408885.0 us 611.188 us 226703.8 us
> SyS_faccessat 564 406969.0 us 721.576 us 141955.4 us
> dwc2_check_qtd_still_ok 651065 392283.0 us 0.602 us 59460.80 us
> SyS_getdents64 392 379673.0 us 968.553 us 13678636 us
> SyS_write 404 378782.0 us 937.579 us 254399.0 us
> iterate_dir 393 367777.0 us 935.819 us 13659529 us
> vfs_write 404 358326.0 us 886.945 us 240956.8 us
> __hrtimer_run_queues.constprop 3227 357720.0 us 110.852 us 47783.12 us
> task_work_run 1460 350902.0 us 240.343 us 71379.18 us
> _cond_resched 109971 344855.0 us 3.135 us 2245087 us
> __vfs_write 404 333260.0 us 824.900 us 230347.3 us
> ____fput 1680 326232.0 us 194.185 us 40913.99 us
> __inode_permission 14699 324102.0 us 22.049 us 328791.7 us
> __fput 1680 316285.0 us 188.264 us 40874.09 us
> flush_old_exec 28 313336.0 us 11190.57 us 96843591 us
> tick_sched_timer 1964 312793.0 us 159.263 us 2002.533 us
> do_wp_page 1758 300693.0 us 171.042 us 17667.03 us
> _do_fork 29 281388.0 us 9703.034 us 54207832 us
> copy_process.part.4 29 273985.0 us 9447.758 us 53888393 us
> SyS_clone 17 267170.0 us 15715.88 us 2444683 us
> free_pgtables 1239 265593.0 us 214.360 us 500428.0 us
> dput 15879 265579.0 us 16.725 us 269685.7 us
> SyS_openat 205 258191.0 us 1259.468 us 209643.6 us
> pfn_valid 18146 257726.0 us 14.202 us 121416.6 us
> update_wall_time 5957 250787.0 us 42.099 us 619.230 us
> mmc_blk_issue_rq 63 246608.0 us 3914.412 us 8858815 us
> mmc_blk_issue_rw_rq 63 241626.0 us 3835.333 us 8884205 us
> vfs_statx 441 232198.0 us 526.526 us 150124.0 us
> SyS_sendmsg 316 226698.0 us 717.398 us 164208.5 us
> mmc_start_request 145 225615.0 us 1555.965 us 5542154 us
> __sys_sendmsg 316 223856.0 us 708.405 us 164907.1 us
> wp_page_copy 1061 222841.0 us 210.029 us 13010.76 us
> __generic_file_write_iter 206 219092.0 us 1063.553 us 242948.7 us
> terminate_walk 3225 217649.0 us 67.488 us 47336.14 us
> ext4_file_write_iter 170 216280.0 us 1272.235 us 127738.3 us
> __mmc_start_request 145 214090.0 us 1476.482 us 5509235 us
> ___sys_sendmsg 316 212732.0 us 673.202 us 161410.8 us
> kmem_cache_alloc 17570 210590.0 us 11.985 us 120917.2 us
> mmc_start_areq 63 210528.0 us 3341.714 us 9610382 us
> sdhci_request 145 209828.0 us 1447.089 us 5547701 us
> sock_sendmsg 353 208523.0 us 590.716 us 147666.9 us
> __split_vma 981 206458.0 us 210.456 us 13253.43 us
> credit_entropy_bits 16914 205434.0 us 12.145 us 208.830 us
> hrtimer_get_next_event 324760 199659.0 us 0.614 us 17454.58 us
> path_put 6090 196782.0 us 32.312 us 54264.43 us
> SyS_mprotect 427 193190.0 us 452.435 us 42168.10 us
> SyS_stat64 370 181587.0 us 490.775 us 119707.4 us
> nr_iowait_cpu 324760 176767.0 us 0.544 us 17782.33 us
> __vma_adjust 1452 174253.0 us 120.008 us 5746.323 us
> tick_sched_handle 1964 174004.0 us 88.596 us 419.232 us
> sdhci_irq 211 173984.0 us 824.568 us 4212897 us
> touch_softlockup_watchdog_sche 323207 173767.0 us 0.537 us 108651.0 us
> kernfs_iop_permission 5012 173442.0 us 34.605 us 21830.09 us
> __local_bh_enable 329502 172898.0 us 0.524 us 9002.660 us
> proc_single_show 233 170938.0 us 733.639 us 235941.1 us
> mprotect_fixup 455 163622.0 us 359.608 us 43581.82 us
> SyS_recvmsg 515 163337.0 us 317.159 us 23749.85 us
> update_process_times 1964 161227.0 us 82.091 us 436.558 us
> usb_control_msg 131 160306.0 us 1223.709 us 63779.20 us
> __sys_recvmsg 515 159685.0 us 310.067 us 23888.88 us
> check_carrier 29 159209.0 us 5489.965 us 157176.1 us
> __dentry_kill 1306 159044.0 us 121.779 us 13522.69 us
> smsc95xx_mdio_read 29 156605.0 us 5400.172 us 147578.2 us
> __smsc95xx_mdio_read 29 156128.0 us 5383.724 us 153872.9 us
> ext4_readdir 60 152036.0 us 2533.933 us 67111799 us
> run_ksoftirqd 844 151846.0 us 179.912 us 74010.42 us
> usb_start_wait_urb 131 151181.0 us 1154.053 us 59721.86 us
> find_vma 8806 149418.0 us 16.967 us 419885.5 us
> __alloc_pages_nodemask 4365 143647.0 us 32.908 us 22236.43 us
> ___sys_recvmsg 515 143567.0 us 278.770 us 23183.05 us
> memblock_is_map_memory 18146 142969.0 us 7.878 us 62191.29 us
> timekeeping_max_deferment 252165 141177.0 us 0.559 us 3782.924 us
> unlink_anon_vmas 3403 137080.0 us 40.282 us 17090.37 us
> __vma_link_rb 3403 136104.0 us 39.995 us 12357.79 us
> rcu_process_callbacks 1050 135701.0 us 129.239 us 66292.86 us
> SyS_close 1977 135041.0 us 68.306 us 4406.697 us
> pick_next_task_fair 3996 133622.0 us 33.438 us 1391.499 us
> proc_readfd 50 133185.0 us 2663.700 us 18788258 us
> proc_readfd_common 50 132911.0 us 2658.220 us 18769391 us
> generic_perform_write 206 132888.0 us 645.087 us 134152.0 us
> __mix_pool_bytes 16914 128343.0 us 7.587 us 303.814 us
> run_timer_softirq 1960 127980.0 us 65.295 us 13337.43 us
> timekeeping_update 5956 127128.0 us 21.344 us 147.035 us
> try_to_wake_up 2348 125639.0 us 53.508 us 5318.431 us
> ktime_add_safe 241886 125624.0 us 0.519 us 6352.310 us
> __rcu_process_callbacks 2100 125522.0 us 59.772 us 1422883 us
> __wake_up 19318 121496.0 us 6.289 us 54037.07 us
> tick_nohz_idle_enter 394 119544.0 us 303.411 us 24204.73 us
> proc_fill_cache 402 119333.0 us 296.848 us 32614.19 us
> unix_dgram_sendmsg 144 119088.0 us 827.000 us 197140.4 us
> enqueue_hrtimer 99205 118756.0 us 1.197 us 1634.105 us
> call_usermodehelper_exec_async 12 117852.0 us 9821.000 us 319067.4 us
> mutex_lock 14089 117414.0 us 8.333 us 245056.5 us
> sock_recvmsg 548 116787.0 us 213.114 us 20249.99 us
> __smsc95xx_read_reg 87 116418.0 us 1338.137 us 39000.81 us
> usbnet_read_cmd 87 115523.0 us 1327.850 us 37075.87 us
> SyS_epoll_wait 336 114271.0 us 340.092 us 47629.77 us
> __close_fd 1977 113569.0 us 57.445 us 3969.846 us
> split_vma 501 112236.0 us 224.023 us 20703.73 us
> vma_link 1248 111097.0 us 89.020 us 5058.706 us
> __usbnet_read_cmd 87 111024.0 us 1276.137 us 34288.14 us
> schedule_hrtimeout_range 390 107480.0 us 275.589 us 10798.57 us
> dentry_unlink_inode 733 107440.0 us 146.575 us 8915.389 us
> unix_find_other 172 106799.0 us 620.924 us 79499.41 us
> iput 757 106445.0 us 140.614 us 8828.710 us
> ext4_htree_fill_tree 36 106438.0 us 2956.611 us 10423331 us
> kernfs_fop_read 198 105215.0 us 531.388 us 48887.87 us
> htree_dirblock_to_tree 36 104352.0 us 2898.666 us 10008360 us
> schedule_hrtimeout_range_clock 390 103931.0 us 266.489 us 10595.17 us
> SyS_connect 99 102476.0 us 1035.111 us 160650.8 us
> __mark_inode_dirty 641 102069.0 us 159.234 us 35047.69 us
> expire_timers 700 100145.0 us 143.064 us 8519.548 us
> do_wait 42 99498.00 us 2369.000 us 11701021 us
> lookup_slow 413 99137.00 us 240.041 us 40034.02 us
> release_task 29 98995.00 us 3413.620 us 12343735 us
> SyS_fstat64 1168 98993.00 us 84.754 us 5326.254 us
> wait_consider_task 444 98839.00 us 222.610 us 1532328 us
> kmem_cache_free 17783 98715.00 us 5.551 us 72804.30 us
>
> ...
^ permalink raw reply
* [GIT PULL 00/16] clocksource: arm_arch_timer: GTDT-based MMIO timer support
From: Daniel Lezcano @ 2017-04-19 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492620273-30037-1-git-send-email-mark.rutland@arm.com>
On Wed, Apr 19, 2017 at 05:44:17PM +0100, Mark Rutland wrote:
> Hi Daniel,
>
> The series enables support for the MMIO architected timers (useful for
> system-level idle), which need to be probed via the GTDT when using ACPI.
>
> 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.
>
> The bulk of the series is a refactoring to cleanly separate the core driver, DT
> probe path, and ACPI probe path. The final patch of the series adds GTDT-based
> probing of the SBSA watchdog, using the new GTDT probing infrastructure. I've
> tested the patches on arm and arm64 platforms.
>
> The ACPI parts have all been appropriately acked, and it's preferred that these
> all go through the clocksource tree.
>
> The series is based on Marc's arch-timer-errata tag, which is alread in
> tip/timers/core.
Hi Thomas,
the series is ok for me. Is it possible to pull these changes directly in
tip/timers/core?
There is a single trivial conflict with a trace.
-- Daniel
>
> The following changes since commit d003d029cea8a28139b4f9b88a36b8fac864f45b:
>
> arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching data (2017-04-07 11:22:10 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git tags/arch-timer-gtdt
>
> for you to fetch changes up to ca9ae5ec4ef0ed13833b03297ab319676965492c:
>
> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver (2017-04-19 17:00:15 +0100)
>
> ----------------------------------------------------------------
> arch timer GTDT patches
>
> - arch_timer cleanups and refactoring
> - new common GTDT parser
> - GTDT-based MMIO arch_timer support
> - GTDT-based SBSA watchdog support
>
> ----------------------------------------------------------------
> Fu Wei (16):
> clocksource: arm_arch_timer: clean up printk usage
> clocksource: arm_arch_timer: rename type macros
> clocksource: arm_arch_timer: rename the PPI enum
> clocksource: arm_arch_timer: move enums and defines to header file
> clocksource: arm_arch_timer: add a new enum for spi type
> clocksource: arm_arch_timer: rework PPI selection
> clocksource: arm_arch_timer: split dt-only rate handling
> clocksource: arm_arch_timer: refactor arch_timer_needs_probing
> clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init call
> clocksource: arm_arch_timer: add structs to describe MMIO timer
> clocksource: arm_arch_timer: split MMIO timer probing.
> acpi/arm64: Add GTDT table parse driver
> clocksource: arm_arch_timer: simplify ACPI support code.
> acpi/arm64: Add memory-mapped timer support in GTDT driver
> clocksource: arm_arch_timer: add GTDT support for memory-mapped timer
> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>
> arch/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Kconfig | 3 +
> drivers/acpi/arm64/Makefile | 1 +
> drivers/acpi/arm64/gtdt.c | 417 +++++++++++++++++++++++++
> drivers/clocksource/arm_arch_timer.c | 573 +++++++++++++++++++++++------------
> include/clocksource/arm_arch_timer.h | 34 +++
> include/linux/acpi.h | 7 +
> 7 files changed, 834 insertions(+), 202 deletions(-)
> create mode 100644 drivers/acpi/arm64/gtdt.c
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Rob Herring @ 2017-04-19 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492068787-17838-2-git-send-email-minghsiu.tsai@mediatek.com>
On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> If the mdp_* nodes are under an mdp sub-node, their corresponding
> platform device does not automatically get its iommu assigned properly.
>
> Fix this by moving the mdp component nodes up a level such that they are
> siblings of mdp and all other SoC subsystems. This also simplifies the
> device tree.
It may simplify the DT, but it also breaks compatibility with old DT.
Not sure if that's a problem on Mediatek platforms, but please be
explicit here that you are breaking compatibility and why that is okay.
>
> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Should this have Daniel as the author?
>
> ---
> Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> index 4182063..0d03e3a 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -2,7 +2,7 @@
>
> Media Data Path is used for scaling and color space conversion.
>
> -Required properties (controller (parent) node):
> +Required properties (controller node):
> - compatible: "mediatek,mt8173-mdp"
> - mediatek,vpu: the node of video processor unit, see
> Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> for details.
>
> Example:
> -mdp {
> - compatible = "mediatek,mt8173-mdp";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> - mediatek,vpu = <&vpu>;
> -
> mdp_rdma0: rdma at 14001000 {
> compatible = "mediatek,mt8173-mdp-rdma";
> + "mediatek,mt8173-mdp";
> reg = <0 0x14001000 0 0x1000>;
> clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> <&mmsys CLK_MM_MUTEX_32K>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> mediatek,larb = <&larb0>;
> + mediatek,vpu = <&vpu>;
> };
>
> mdp_rdma1: rdma at 14002000 {
> @@ -106,4 +101,3 @@ mdp {
> iommus = <&iommu M4U_PORT_MDP_WROT1>;
> mediatek,larb = <&larb4>;
> };
> -};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] soc: bcm: brcmstb: Correctly match 7435 SoC
From: Florian Fainelli @ 2017-04-19 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADtm3G5yJhM8cfqS_xbp2TjWxsB_ipfsL5oFoMq_1SH-mW3rHA@mail.gmail.com>
On 04/19/2017 01:28 PM, Gregory Fong wrote:
> On Wed, Apr 19, 2017 at 10:01 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> Remove the duplicate brcm,bcm7425-sun-top-ctrl compatible string and
>> replace it with brcm,bcm7435-sun-top-ctrl which was intentend.
>
> s/intentend/intended/
>
>>
>> Fixes: bd0faf08dc7f ("soc: bcm: brcmstb: Match additional compatible strings")
>> Reported-by: Andreas Oberritter <obi@saftware.de>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
>
Fixed the typo and applied with your Acked-by, thanks Gregory!
--
Florian
^ permalink raw reply
* [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: Rob Herring @ 2017-04-19 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492067108-14748-2-git-send-email-sean.wang@mediatek.com>
On Thu, Apr 13, 2017 at 03:05:07PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Document the devicetree bindings for Mediatek random number
> generator which could be found on MT7623 SoC or other similar
> Mediatek SoCs.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm64: prefetch: Change assembly to be compatible with gcc and clang
From: Matthias Kaehlcke @ 2017-04-19 21:22 UTC (permalink / raw)
To: linux-arm-kernel
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.
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
^ permalink raw reply related
* [PATCH] soc: brcmstb: enable drivers for ARM64 also
From: Florian Fainelli @ 2017-04-19 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419201811.70246-1-code@mmayer.net>
On 04/19/2017 01:18 PM, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> We enable the BRCMSTB SoC drivers not only for ARM, but also ARM64.
This looks fine, can you also put add || BMIPS_GENERIC in there since
the driver is also used for these platforms?
We may also want a || COMPILE_TEST just to improve build coverage.
Thanks!
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
> drivers/soc/bcm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
> index a39b0d5..b3834b9 100644
> --- a/drivers/soc/bcm/Kconfig
> +++ b/drivers/soc/bcm/Kconfig
> @@ -11,7 +11,7 @@ config RASPBERRYPI_POWER
>
> config SOC_BRCMSTB
> bool "Broadcom STB SoC drivers"
> - depends on ARM
> + depends on ARM || ARM64
> select SOC_BUS
> help
> Enables drivers for the Broadcom Set-Top Box (STB) series of chips.
>
--
Florian
^ permalink raw reply
* [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Rob Herring @ 2017-04-19 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412111400.2296-5-clabbe.montjoie@gmail.com>
On Wed, Apr 12, 2017 at 01:13:46PM +0200, 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
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-19 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+G_jbQTDfyPBZ4Er8vz46tEojrWf29Eztq56c9zBnMeA@mail.gmail.com>
On Sun, Apr 16, 2017 at 9:09 AM, Adam Ford <aford173@gmail.com> wrote:
>
>
> On Apr 13, 2017 10:04 AM, "Rob Herring" <robh@kernel.org> wrote:
>
> Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
> devices.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: netdev at vger.kernel.org
> Cc: devicetree at vger.kernel.org
> ---
> v3:
> - rebase on bluetooth-next
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35
> ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> new file mode 100644
> index 000000000000..cbad73a84ac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -0,0 +1,35 @@
> +TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
> +
> +TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
> +and GPS over what's called "shared transport". The shared transport is
> +standard BT HCI protocol with additional channels for the other functions.
> +
> +These devices also have a separate WiFi interface as described in
> +wireless/ti,wlcore.txt.
> +
> +This bindings follows the UART slave device binding in
> +../serial/slave-device.txt.
> +
> +Required properties:
> + - compatible: should be one of the following:
> + "ti,wl1271-st"
> + "ti,wl1273-st"
> + "ti,wl1831-st"
> + "ti,wl1835-st"
> + "ti,wl1837-st"
> +
>
>
> Would you expect the wl1283 chipset too?
Probably, but I left it out as there's no public information.
> I can help test this if you like after the holiday weekend. I have a board
> with WL1283 and currently using pdata-quirks to support it.
^ permalink raw reply
* [PATCH v2 11/11] fsl/soc/qbman: Enable FSL_LAYERSCAPE config on ARM
From: Roy Pledge @ 2017-04-19 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492634930-10765-1-git-send-email-roy.pledge@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
[Stuart: changed to use ARCH_LAYERSCAPE]
Signed-off-by: Stuart Yoder <stuart.yoder@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig
index 757033c..fb4e6bf 100644
--- a/drivers/soc/fsl/qbman/Kconfig
+++ b/drivers/soc/fsl/qbman/Kconfig
@@ -1,6 +1,6 @@
menuconfig FSL_DPAA
bool "Freescale DPAA 1.x support"
- depends on FSL_SOC_BOOKE
+ depends on (FSL_SOC_BOOKE || ARCH_LAYERSCAPE)
select GENERIC_ALLOCATOR
help
The Freescale Data Path Acceleration Architecture (DPAA) is a set of
--
2.7.4
^ permalink raw reply related
* [PATCH v2 10/11] soc/fsl/qbman: Add missing headers on ARM
From: Roy Pledge @ 2017-04-19 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492634930-10765-1-git-send-email-roy.pledge@nxp.com>
From: Claudiu Manoil <claudiu.manoil@nxp.com>
Unlike PPC builds, ARM builds need following headers
explicitly:
+#include <linux/io.h> for ioread32be()
+#include <linux/delay.h> for udelay()
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/dpaa_sys.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index 81a9a5e..9925013 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -44,6 +44,8 @@
#include <linux/prefetch.h>
#include <linux/genalloc.h>
#include <asm/cacheflush.h>
+#include <linux/io.h>
+#include <linux/delay.h>
/* For 2-element tables related to cache-inhibited and cache-enabled mappings */
#define DPAA_PORTAL_CE 0
--
2.7.4
^ permalink raw reply related
* [PATCH v2 09/11] soc/fsl/qbman: different register offsets on ARM
From: Roy Pledge @ 2017-04-19 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492634930-10765-1-git-send-email-roy.pledge@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/bman.c | 22 ++++++++++++++++++++++
drivers/soc/fsl/qbman/qman.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
index 3acded1..1fa9099 100644
--- a/drivers/soc/fsl/qbman/bman.c
+++ b/drivers/soc/fsl/qbman/bman.c
@@ -35,6 +35,27 @@
/* Portal register assists */
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+/* Cache-inhibited register offsets */
+#define BM_REG_RCR_PI_CINH 0x3000
+#define BM_REG_RCR_CI_CINH 0x3100
+#define BM_REG_RCR_ITR 0x3200
+#define BM_REG_CFG 0x3300
+#define BM_REG_SCN(n) (0x3400 + ((n) << 6))
+#define BM_REG_ISR 0x3e00
+#define BM_REG_IER 0x3e40
+#define BM_REG_ISDR 0x3e80
+#define BM_REG_IIR 0x3ec0
+
+/* Cache-enabled register offsets */
+#define BM_CL_CR 0x0000
+#define BM_CL_RR0 0x0100
+#define BM_CL_RR1 0x0140
+#define BM_CL_RCR 0x1000
+#define BM_CL_RCR_PI_CENA 0x3000
+#define BM_CL_RCR_CI_CENA 0x3100
+
+#else
/* Cache-inhibited register offsets */
#define BM_REG_RCR_PI_CINH 0x0000
#define BM_REG_RCR_CI_CINH 0x0004
@@ -53,6 +74,7 @@
#define BM_CL_RCR 0x1000
#define BM_CL_RCR_PI_CENA 0x3000
#define BM_CL_RCR_CI_CENA 0x3100
+#endif
/*
* Portal modes.
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 3f60289..121bbb7 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -41,6 +41,43 @@
/* Portal register assists */
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+/* Cache-inhibited register offsets */
+#define QM_REG_EQCR_PI_CINH 0x3000
+#define QM_REG_EQCR_CI_CINH 0x3040
+#define QM_REG_EQCR_ITR 0x3080
+#define QM_REG_DQRR_PI_CINH 0x3100
+#define QM_REG_DQRR_CI_CINH 0x3140
+#define QM_REG_DQRR_ITR 0x3180
+#define QM_REG_DQRR_DCAP 0x31C0
+#define QM_REG_DQRR_SDQCR 0x3200
+#define QM_REG_DQRR_VDQCR 0x3240
+#define QM_REG_DQRR_PDQCR 0x3280
+#define QM_REG_MR_PI_CINH 0x3300
+#define QM_REG_MR_CI_CINH 0x3340
+#define QM_REG_MR_ITR 0x3380
+#define QM_REG_CFG 0x3500
+#define QM_REG_ISR 0x3600
+#define QM_REG_IER 0x3640
+#define QM_REG_ISDR 0x3680
+#define QM_REG_IIR 0x36C0
+#define QM_REG_ITPR 0x3740
+
+/* Cache-enabled register offsets */
+#define QM_CL_EQCR 0x0000
+#define QM_CL_DQRR 0x1000
+#define QM_CL_MR 0x2000
+#define QM_CL_EQCR_PI_CENA 0x3000
+#define QM_CL_EQCR_CI_CENA 0x3040
+#define QM_CL_DQRR_PI_CENA 0x3100
+#define QM_CL_DQRR_CI_CENA 0x3140
+#define QM_CL_MR_PI_CENA 0x3300
+#define QM_CL_MR_CI_CENA 0x3340
+#define QM_CL_CR 0x3800
+#define QM_CL_RR0 0x3900
+#define QM_CL_RR1 0x3940
+
+#else
/* Cache-inhibited register offsets */
#define QM_REG_EQCR_PI_CINH 0x0000
#define QM_REG_EQCR_CI_CINH 0x0004
@@ -75,6 +112,7 @@
#define QM_CL_CR 0x3800
#define QM_CL_RR0 0x3900
#define QM_CL_RR1 0x3940
+#endif
/*
* BTW, the drivers (and h/w programming model) already obtain the required
--
2.7.4
^ permalink raw reply related
* [PATCH v2 08/11] soc/fsl/qbman: add QMAN_REV32
From: Roy Pledge @ 2017-04-19 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492634930-10765-1-git-send-email-roy.pledge@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Add revision 3.2 of the QBMan block. This is the version
for LS1043A and LS1046A SoCs.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++
drivers/soc/fsl/qbman/qman_priv.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
index 39ad7c4..9327374 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -720,6 +720,8 @@ static int fsl_qman_probe(struct platform_device *pdev)
qman_ip_rev = QMAN_REV30;
else if (major == 3 && minor == 1)
qman_ip_rev = QMAN_REV31;
+ else if (major == 3 && minor == 2)
+ qman_ip_rev = QMAN_REV32;
else {
dev_err(dev, "Unknown QMan version\n");
return -ENODEV;
diff --git a/drivers/soc/fsl/qbman/qman_priv.h b/drivers/soc/fsl/qbman/qman_priv.h
index 1e998ea5..96f58c4 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -186,6 +186,7 @@ struct qm_portal_config {
#define QMAN_REV20 0x0200
#define QMAN_REV30 0x0300
#define QMAN_REV31 0x0301
+#define QMAN_REV32 0x0302
extern u16 qman_ip_rev; /* 0 if uninitialised, otherwise QMAN_REVx */
#define QM_FQID_RANGE_START 1 /* FQID 0 reserved for internal use */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 07/11] soc/fsl/qbman: Rework ioremap() calls for ARM/PPC
From: Roy Pledge @ 2017-04-19 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492634930-10765-1-git-send-email-roy.pledge@nxp.com>
Rework ioremap() for PPC and ARM. The PPC devices require a
non-coherent mapping while ARM will work with a non-cachable/write
combine mapping.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/bman_portal.c | 16 +++++++++++++---
drivers/soc/fsl/qbman/qman_portal.c | 16 +++++++++++++---
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/fsl/qbman/bman_portal.c b/drivers/soc/fsl/qbman/bman_portal.c
index 8354d4d..a661f30 100644
--- a/drivers/soc/fsl/qbman/bman_portal.c
+++ b/drivers/soc/fsl/qbman/bman_portal.c
@@ -125,7 +125,18 @@ static int bman_portal_probe(struct platform_device *pdev)
}
pcfg->irq = irq;
- va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]), 0);
+#ifdef CONFIG_PPC
+ /* PPC requires a cacheable/non-coherent mapping of the portal */
+ va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]),
+ (pgprot_val(PAGE_KERNEL) & ~_PAGE_COHERENT));
+#else
+ /*
+ * For ARM we can use write combine mapping. A cacheable/non shareable
+ * mapping will perform better but equires additional platform
+ * support which is not currently available
+ */
+ va = ioremap_wc(addr_phys[0]->start, resource_size(addr_phys[0]));
+#endif
if (!va) {
dev_err(dev, "ioremap::CE failed\n");
goto err_ioremap1;
@@ -133,8 +144,7 @@ static int bman_portal_probe(struct platform_device *pdev)
pcfg->addr_virt[DPAA_PORTAL_CE] = va;
- va = ioremap_prot(addr_phys[1]->start, resource_size(addr_phys[1]),
- _PAGE_GUARDED | _PAGE_NO_CACHE);
+ va = ioremap(addr_phys[1]->start, resource_size(addr_phys[1]));
if (!va) {
dev_err(dev, "ioremap::CI failed\n");
goto err_ioremap2;
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index adbaa30..e7a9eef 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -265,7 +265,18 @@ static int qman_portal_probe(struct platform_device *pdev)
}
pcfg->irq = irq;
- va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]), 0);
+#ifdef CONFIG_PPC
+ /* PPC requires a cacheable/non-coherent mapping of the portal */
+ va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]),
+ (pgprot_val(PAGE_KERNEL) & ~_PAGE_COHERENT));
+#else
+ /*
+ * For ARM we can use write combine mapping. A cacheable/non shareable
+ * mapping will perform better but equires additional platform
+ * support which is not currently available
+ */
+ va = ioremap_wc(addr_phys[0]->start, resource_size(addr_phys[0]));
+#endif
if (!va) {
dev_err(dev, "ioremap::CE failed\n");
goto err_ioremap1;
@@ -273,8 +284,7 @@ static int qman_portal_probe(struct platform_device *pdev)
pcfg->addr_virt[DPAA_PORTAL_CE] = va;
- va = ioremap_prot(addr_phys[1]->start, resource_size(addr_phys[1]),
- _PAGE_GUARDED | _PAGE_NO_CACHE);
+ va = ioremap(addr_phys[1]->start, resource_size(addr_phys[1]));
if (!va) {
dev_err(dev, "ioremap::CI failed\n");
goto err_ioremap2;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 06/11] soc/fsl/qbman: Fix ARM32 typo
From: Roy Pledge @ 2017-04-19 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492634930-10765-1-git-send-email-roy.pledge@nxp.com>
From: Valentin Rothberg <valentinrothberg@gmail.com>
The Kconfig symbol for 32bit ARM is 'ARM', not 'ARM32'.
Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/dpaa_sys.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index f85c319..81a9a5e 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -53,7 +53,7 @@ static inline void dpaa_flush(void *p)
{
#ifdef CONFIG_PPC
flush_dcache_range((unsigned long)p, (unsigned long)p+64);
-#elif defined(CONFIG_ARM32)
+#elif defined(CONFIG_ARM)
__cpuc_flush_dcache_area(p, 64);
#elif defined(CONFIG_ARM64)
__flush_dcache_area(p, 64);
--
2.7.4
^ 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