* [PATCH v6 2/3] ARM: dts: add TOPEET itop elite based board
From: ayaka @ 2016-09-16 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6bd9905d-0818-a917-8b8e-6abce134a3d3@kernel.org>
On 09/16/2016 03:23 PM, Krzysztof Kozlowski wrote:
> On 09/07/2016 11:58 PM, Randy Li wrote:
>> The TOPEET itop exynos 4412 have three versions base board. The
>> Elite version is the cheap one without too much peripheral devices
>> on it.
>>
>> Currently supported are serial console, wired networking(USB),
>> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
>> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
>> enabled.
>>
>> The FIMC is not used for camera currently, I enabled it just for a
>> colorspace convertor.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>> ---
>> .../bindings/arm/samsung/samsung-boards.txt | 3 +
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/exynos4412-itop-elite.dts | 239 +++++++++++++++++++++
>> 3 files changed, 243 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
>> index 0ea7f14..c7159ac 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
>> @@ -22,6 +22,9 @@ Required root node properties:
>> * FriendlyARM
>> - "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
>> TINY4412 board.
>> + * TOPEET
>> + - "topeet,itop4412-elite" - for Exynos4412-based TOPEET
>> + Elite base board.
>>
>> * Google
>> - "google,pi" - for Exynos5800-based Google Peach Pi
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 207f96f..0b39d00 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
>> exynos4210-smdkv310.dtb \
>> exynos4210-trats.dtb \
>> exynos4210-universal_c210.dtb \
>> + exynos4412-itop-elite.dtb \
>> exynos4412-odroidu3.dtb \
>> exynos4412-odroidx.dtb \
>> exynos4412-odroidx2.dtb \
>> diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> new file mode 100644
>> index 0000000..dd83689
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
>> @@ -0,0 +1,239 @@
>> +/*
>> + * TOPEET's Exynos4412 based itop board device tree source
>> + *
>> + * Copyright (c) 2016 SUMOMO Computer Association
>> + * https://www.sumomo.mobi
>> + * Randy Li <ayaka@soulik.info>
>> + *
>> + * Device tree source file for TOPEET iTop Exynos 4412 core board
>> + * which is based on Samsung's Exynos4412 SoC.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +/dts-v1/;
>> +#include <dt-bindings/sound/samsung-i2s.h>
>> +#include "exynos4412-itop-scp-core.dtsi"
>> +
>> +/ {
>> + model = "TOPEET iTop 4412 Elite board based on Exynos4412";
>> + compatible = "topeet,itop4412-elite", "samsung,exynos4412", "samsung,exynos4";
>> +
>> + chosen {
>> + bootargs = "root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait";
>> + stdout-path = "serial2:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led2 {
>> + label = "red:system";
>> + gpios = <&gpx1 0 GPIO_ACTIVE_HIGH>;
>> + default-state = "off";
>> + linux,default-trigger = "heartbeat";
>> + };
>> +
>> + led3 {
>> + label = "red:user";
>> + gpios = <&gpk1 1 GPIO_ACTIVE_HIGH>;
>> + default-state = "off";
>> + };
>> + };
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> +
>> + home {
>> + label = "GPIO Key Home";
>> + linux,code = <KEY_HOME>;
>> + gpios = <&gpx1 1 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + back {
>> + label = "GPIO Key Back";
>> + linux,code = <KEY_BACK>;
>> + gpios = <&gpx1 2 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + sleep {
>> + label = "GPIO Key Sleep";
>> + linux,code = <KEY_POWER>;
>> + gpios = <&gpx3 3 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + vol-up {
>> + label = "GPIO Key Vol+";
>> + linux,code = <KEY_UP>;
>> + gpios = <&gpx2 1 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + vol-down {
>> + label = "GPIO Key Vol-";
>> + linux,code = <KEY_DOWN>;
>> + gpios = <&gpx2 0 GPIO_ACTIVE_LOW>;
>> + };
>> + };
>> +
>> + sound {
>> + compatible = "simple-audio-card";
>> + simple-audio-card,name = "wm-sound";
>> +
>> + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
>> + <&clock_audss EXYNOS_MOUT_I2S>,
>> + <&clock_audss EXYNOS_DOUT_SRP>,
>> + <&clock_audss EXYNOS_DOUT_AUD_BUS>;
>> + assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
>> + <&clock_audss EXYNOS_MOUT_AUDSS>;
>> + assigned-clock-rates = <0>,
>> + <0>,
>> + <112896000>,
>> + <11289600>;
>> +
>> + simple-audio-card,format = "i2s";
>> + simple-audio-card,bitclock-master = <&link0_codec>;
>> + simple-audio-card,frame-master = <&link0_codec>;
>> +
>> + simple-audio-card,widgets =
>> + "Microphone", "Mic Jack",
>> + "Line", "Line In",
>> + "Line", "Line Out",
>> + "Speaker", "Speaker",
>> + "Headphone", "Headphone Jack";
>> + simple-audio-card,routing =
>> + "Headphone Jack", "HP_L",
>> + "Headphone Jack", "HP_R",
>> + "Speaker", "SPK_LP",
>> + "Speaker", "SPK_LN",
>> + "Speaker", "SPK_RP",
>> + "Speaker", "SPK_RN",
>> + "LINPUT1", "Mic Jack",
>> + "LINPUT3", "Mic Jack",
>> + "RINPUT1", "Mic Jack",
>> + "RINPUT2", "Mic Jack";
>> +
>> + simple-audio-card,cpu {
>> + sound-dai = <&i2s0 0>;
>> + };
>> +
>> + link0_codec: simple-audio-card,codec {
>> + sound-dai = <&codec>;
>> + clocks = <&i2s0 CLK_I2S_CDCLK>;
>> + system-clock-frequency = <11289600>;
>> + };
>> + };
>> +
>> + beep {
>> + compatible = "pwm-beeper";
>> + pwms = <&pwm 0 4000000 PWM_POLARITY_INVERTED>;
> I have serious doubts that you run this code... if it does not even
> compile. Sorry, I cannot accept code that does not compile and was not
> tested.
>
> Please, test your DTS on top of current Linux tree, which would be one of:
> 1. Linus' master branch: v4.8-rc6,
> 2. one of my branches (for-next, next/dt etc),
When I sent those patches, I tested in "Add linux-next specific files
for 20160907"
> 3. recent linux-next.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v5 4/6] arm/arm64: vgic-new: Introduce VENG0 and VENG1 fields to vmcr struct
From: Marc Zyngier @ 2016-09-16 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474028453-29132-5-git-send-email-vijay.kilari@gmail.com>
On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> ICC_VMCR_EL2 supports virtual access to ICC_IGRPEN1_EL1.Enable
> and ICC_IGRPEN0_EL1.Enable fields. Add grpen0 and grpen1 member
> variables to struct vmcr to support read and write of these fields.
>
> ICH_VMCR_CTLR_MASK is changed to mask only ICC_CTLR_EL1 fields.
This comment doesn't match the patch.
> Also refactor vgic_set_vmcr and vgic_get_vmcr() code.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
> include/linux/irqchip/arm-gic-v3.h | 15 +++++++++++----
> virt/kvm/arm/vgic/vgic-mmio-v2.c | 16 ----------------
> virt/kvm/arm/vgic/vgic-mmio.c | 16 ++++++++++++++++
> virt/kvm/arm/vgic/vgic-v3.c | 10 ++++++++--
> virt/kvm/arm/vgic/vgic.h | 5 +++++
> 5 files changed, 40 insertions(+), 22 deletions(-)
>
> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> index 99ac022..88d83d3 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -352,8 +352,9 @@
> /*
> * CPU interface registers
> */
> -#define ICC_CTLR_EL1_EOImode_drop_dir (0U << 1)
> -#define ICC_CTLR_EL1_EOImode_drop (1U << 1)
> +#define ICC_CTLR_EL1_EOImode_SHIFT (1)
> +#define ICC_CTLR_EL1_EOImode_drop_dir (0U << ICC_CTLR_EL1_EOImode_SHIFT)
> +#define ICC_CTLR_EL1_EOImode_drop (1U << ICC_CTLR_EL1_EOImode_SHIFT)
> #define ICC_SRE_EL1_SRE (1U << 0)
>
> /*
> @@ -382,14 +383,20 @@
> #define ICH_HCR_EN (1 << 0)
> #define ICH_HCR_UIE (1 << 1)
>
> -#define ICH_VMCR_CTLR_SHIFT 0
> -#define ICH_VMCR_CTLR_MASK (0x21f << ICH_VMCR_CTLR_SHIFT)
> +#define ICH_VMCR_CBPR_SHIFT 4
> +#define ICH_VMCR_CBPR_MASK (1 << ICH_VMCR_CBPR_SHIFT)
> +#define ICH_VMCR_EOIM_SHIFT 9
> +#define ICH_VMCR_EOIM_MASK (1 << ICH_VMCR_EOIM_SHIFT)
> #define ICH_VMCR_BPR1_SHIFT 18
> #define ICH_VMCR_BPR1_MASK (7 << ICH_VMCR_BPR1_SHIFT)
> #define ICH_VMCR_BPR0_SHIFT 21
> #define ICH_VMCR_BPR0_MASK (7 << ICH_VMCR_BPR0_SHIFT)
> #define ICH_VMCR_PMR_SHIFT 24
> #define ICH_VMCR_PMR_MASK (0xffUL << ICH_VMCR_PMR_SHIFT)
> +#define ICH_VMCR_ENG0_SHIFT 0
> +#define ICH_VMCR_ENG0_MASK (1 << ICH_VMCR_ENG0_SHIFT)
> +#define ICH_VMCR_ENG1_SHIFT 1
> +#define ICH_VMCR_ENG1_MASK (1 << ICH_VMCR_ENG1_SHIFT)
>
> #define ICC_IAR1_EL1_SPURIOUS 0x3ff
I've asked you to make this a separate patch, which you've ignored.
Please make this change a separate patch, independent of any KVM change.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Gerd Hoffmann @ 2016-09-16 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916133027.GA27036@cbox>
Hi,
> That being said, I'm not categorically against these patches, but I
> share Marc's view that we've already seen that non-vgic support had been
> broken for multiple versions without anyone complaining,
Oh, did this ever work? Work as in "can actually run a virtual
machine", not as in "kvm doesn't throw an error on initialization".
> and without
> automated testing or substantial interest in the work, the patches
> really are likely to bit-rot.
Well, as far I know the rpi3 is the *only* aarch64 hardware which is
easily available and can (with these patches) run kvm.
More powerful stuff with more ram and sata storage and gbit network
(which I'd love to have to play with arm virt on real hardware) is
announced to be available really soon now since ... half a year at
least?
cheers,
Gerd
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Arnd Bergmann @ 2016-09-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBAB2F.3040905@ti.com>
On Friday, September 16, 2016 1:49:59 PM CEST Kishon Vijay Abraham I wrote:
>
> I think the offset information can come from the devicetree too. The phy can be
> modeled something like below.
>
> usb-phys at c0000000 {
> compatible = "amlogic,meson-gxbb-usb2-phy";
> reg = <0x0 0xc0000000 0x0 0x40>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xc0000000 0x0 0x40>;
> resets = <&reset 34>;
>
> usb0_phy: usb_phy at 0 {
> #phy-cells = <0>;
> reg = <0x0 0x0 0x0 0x20>;
> clocks = <&clkc CLKID_USB &clkc CLKID_USB0>;
> clock-names = "usb_general", "usb";
> status = "disabled";
> };
>
> usb1_phy: usb_phy at 20 {
> #phy-cells = <0>;
> reg = <0x0 0x20 0x0 0x20>;
> clocks = <&clkc CLKID_USB &clkc CLKID_USB1>;
> clock-names = "usb_general", "usb";
> status = "disabled";
> };
> };
>
> This way the driver will be probed only once (the reset can be done during
> probe). The phy driver should scan the dt node and for every sub-node it
> invokes phy_create?
Why not just use #phy-cells=<1> and pass the phy number as an argument
in the reference?
Arnd
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Andrew Jones @ 2016-09-16 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916133027.GA27036@cbox>
On Fri, Sep 16, 2016 at 03:30:27PM +0200, Christoffer Dall wrote:
> On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
> >
> >
> > On 16/09/2016 14:30, Christoffer Dall wrote:
> > > > > > This patch set allows user space to receive vtimer events as well as mask
> > > > > > them, so that we can handle all vtimer related interrupt injection from user
> > > > > > space, enabling us to use architected timer with user space gic emulation.
> > > > >
> > > > > I have already voiced my concerns in the past, including face to face,
> > > > > and I'm going to repeat it: I not keen at all on adding a new userspace
> > > > > interface that is going to bitrot extremely quickly.
> > > >
> > > > You don't have automated tests set up? It's not going to bitrot if you
> > > > test it, either with kvm-unit-tests or just by smoke-testing Linux.
> > > > It's _for_ the raspi, but it's not limited to it.
> > >
> > > Our automated testing situation is not great, no. Something we're
> > > looking at, but have resource problems with.
> >
> > But it's not a good reason to hold back a feature...
> >
>
> I didn't say that exactly, but choosing not to merge something we cannot
> maintain and which we're not paid to look after and where there's a
> minimal interest, is not entirely unreasonable.
>
> That being said, I'm not categorically against these patches, but I
> share Marc's view that we've already seen that non-vgic support had been
> broken for multiple versions without anyone complaining, and without
> automated testing or substantial interest in the work, the patches
> really are likely to bit-rot.
>
> But I haven't even looked at the patches in detail, I was just replying
> to the comment about testing.
This may be a great time to start encouraging feature writers to submit
kvm-unit-tests patches at the same time as the feature (Hi Alex :-) I'm
happy to help when a test isn't easy to write due to a lack of framework,
but don't have nearly enough bandwidth to write all the tests myself.
As for additional motivation for this series, I'll point out that it's
good for bug isolation. When a guest fails to boot over KVM I can try
TCG. If that works, then I've likely narrowed it to KVM. If I can
further try kernel_irqchip=no, then I may further narrow it down to
the vgic implementation.
Thanks,
drew
^ permalink raw reply
* [GIT PULL 4/5] Freescale arm64 device tree updates for 4.9
From: Arnd Bergmann @ 2016-09-16 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916014703.GC7398@tiger>
On Friday, September 16, 2016 9:47:03 AM CEST Shawn Guo wrote:
> On Wed, Sep 14, 2016 at 05:30:49PM +0200, Arnd Bergmann wrote:
> > On Monday, September 12, 2016 5:02:27 PM CEST Shawn Guo wrote:
> > > i.MX arm64 device tree changes for 4.9:
> > > - Add property dma-coherent for ls2080a PCI device to save software
> > > cache maintenance.
> > > - Update serial aliases and use stdout-path to sepecify console for
> > > ls2080a and ls1043a boards.
> > > - Add DDR memory controller device node for ls2080a and ls1043a SoCs.
> > >
> >
> > Pulled into next/dt64, thanks!
> >
> > The "dma-coherent" change sounds like a bugfix, should that be backported
> > to stable kernels? Usually if you lack that property on a device that
> > is actually coherent, you can get silent data corruption by treating it as
> > non-coherent.
>
> My impression is that those cache maintenance enforced for non-coherent
> device will hurt performance on coherent device. I don't know it will
> cause data corruption.
The problem is that the device in this case is accessing data from
the cache, while the CPU bypasses the cache for coherent mappings.
The cache might have a stale cache line as the device reads data, or
it could be in a writeback configuration, where the data written
from the device to the cache has not made it into RAM at the time it
is accessed by the CPU.
For streaming mappings, the CPU will invalidate cache lines
before reading the data, so again if the device has written data
into the cache but not yet into memory, we will see stale data
after dma_unmap_single().
Arnd
^ permalink raw reply
* [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks
From: Gabriele Paoloni @ 2016-09-16 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42c3f965-b40c-f2bb-e12c-34da6af1a4b7@codeaurora.org>
Hi Cov
> -----Original Message-----
> From: Christopher Covington [mailto:cov at codeaurora.org]
> Sent: 16 September 2016 13:28
> To: Gabriele Paoloni; Lorenzo Pieralisi; liudongdong (C)
> Cc: Tomasz Nowicki; helgaas at kernel.org; will.deacon at arm.com;
> catalin.marinas at arm.com; rafael at kernel.org; arnd at arndb.de;
> hanjun.guo at linaro.org; okaya at codeaurora.org; jchandra at broadcom.com;
> dhdang at apm.com; ard.biesheuvel at linaro.org;
> robert.richter at caviumnetworks.com; mw at semihalf.com;
> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> msalter at redhat.com; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org;
> jcm at redhat.com; andrea.gallo at linaro.org; jeremy.linton at arm.com;
> jhugo at codeaurora.org; linux-acpi at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM
> quirks
>
> On 09/16/2016 05:02 AM, Gabriele Paoloni wrote:
> > Hi Lorenzo and Tomasz
> >
> > Many Thanks for looking at this
> >
> >> -----Original Message-----
> >> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi at arm.com]
> >> Sent: 15 September 2016 11:59
> >> To: liudongdong (C)
> >> Cc: Tomasz Nowicki; helgaas at kernel.org; will.deacon at arm.com;
> >> catalin.marinas at arm.com; rafael at kernel.org; arnd at arndb.de;
> >> hanjun.guo at linaro.org; okaya at codeaurora.org; jchandra at broadcom.com;
> >> cov at codeaurora.org; dhdang at apm.com; ard.biesheuvel at linaro.org;
> >> robert.richter at caviumnetworks.com; mw at semihalf.com;
> >> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> >> msalter at redhat.com; linux-pci at vger.kernel.org; linux-arm-
> >> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org;
> >> jcm at redhat.com; andrea.gallo at linaro.org; jeremy.linton at arm.com;
> >> Gabriele Paoloni; jhugo at codeaurora.org; linux-acpi at vger.kernel.org;
> >> linux-kernel at vger.kernel.org
> >> Subject: Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM
> >> quirks
> >>
> >> On Tue, Sep 13, 2016 at 07:38:39PM +0800, Dongdong Liu wrote:
> >>
> >> [...]
> >>
> >>> Our host bridge is non ECAM only for the RC bus config space;
> >>> for any other bus underneath the root bus we support ECAM access.
> >>>
> >>> RC config resource with hardcode as DEFINE_RES_MEM(0xb0070000,
> >> SZ_4K),
> >>> EP config resource we get it from MCFG table.
> >>> So we need to override ops, but config resource we only need to
> >> hardcode with RC config resource.
> >>>
> >>> Our host controller ACPI support patch can be found:
> >>> https://lkml.org/lkml/2016/8/31/340
> >>
> >> Sorry I misread your code. IIUC you create an array of resources
> that
> >> represent non-ECAM config space (and incidentally contain debug
> >> registers to check the link status - that you need to check for
> every
> >> given config access (?)), but you still need to have an MCFG entry
> that
> >
> > The link status check is inherited from the designware framework (see
> > http://lxr.free-electrons.com/source/drivers/pci/host/pcie-
> designware.c#L678)
> >
> > However I think that in this case we can just check the link status
> > in our init function and return an error if the link is down
> >
> >> covers the bus number subject to quirk to make sure this mechanism
> >> works. Correct ?
> >
> > Well we need the quirks for the root bus numbers but if read this v6
> > quirk mechanism correctly even if we do not specify an mcfg entry for
> > bus 0 oci_mcfg_match_quirks() is called anyway and we can set our
> > special configuration space addresses for the root buses (i.e. I
> think
> > we can have a clean MCFG table with entries only for those bus ranges
> > that are really ECAM)
> >
> >>
> >> This also means that, with the MCFG tables you have and current
> >> mainline kernel you are able to probe a root bridge (because the
> MCFG
> >> table covers the bus number that is not ECAM), with enumeration
> >> going haywire because it is trying to carry out ECAM accesses on
> >> non-ECAM space.
> >
> > Yes correct, we cannot access the host controller configuration space
> > with our current MCFG table and current Linux mainline
> >
> >>
> >> Is my reading correct ?
> >>
> >> Anyway, that's not stricly related to this discussion, it is time we
> >> converge on this patchset, we can add a domain range if that
> >> simplifies things.
> >
> > IMO it would be better to have the domain range to avoid
> > a very large and repetitive static quirk array
>
> The v6 framework requires what, 21 additional lines of quirk data? What
> if you were to define some preprocessor macros to slim it down? I think
> something like the following would bring it down to roughly 7
> additional
> lines.
Thanks, yes this would work as well. To be honest this is not a big issue.
So either we go this way or we introduce domain range...
Cheers
Gab
>
> #define PCI_ACPI_QUIRK_QUAD_DOM(rev, dom, ops) \
> { "HISI ", rev, 0, dom+0, MCFG_BUS_ANY, ops,
> MCFG_RES_EMPTY}, \
> { "HISI ", rev, 0, dom+1, MCFG_BUS_ANY, ops,
> MCFG_RES_EMPTY}, \
> { "HISI ", rev, 0, dom+2, MCFG_BUS_ANY, ops,
> MCFG_RES_EMPTY}, \
> { "HISI ", rev, 0, dom+3, MCFG_BUS_ANY, ops,
> MCFG_RES_EMPTY},
>
> PCI_ACPI_QUIRK_QUAD_DOM("HIP05 ", 0, &hisi_pcie_hip05_ops)
> PCI_ACPI_QUIRK_QUAD_DOM("HIP06 ", 0, &hisi_pcie_hip05_ops)
> PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 0, &hisi_pcie_hip06_ops)
> PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 4, &hisi_pcie_hip07_ops)
> PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 8, &hisi_pcie_hip07_ops)
> PCI_ACPI_QUIRK_QUAD_DOM("HIP07 ", 12, &hisi_pcie_hip07_ops)
>
> Cov
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
> Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v10 0/4] ACPI: parse the SPCR table
From: Aleksey Makarov @ 2016-09-16 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160905123617.18775-1-aleksey.makarov@linaro.org>
+ CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
On 09/05/2016 03:36 PM, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requirements' [1] mentions SPCR (Serial Port Console
> Redirection Table) [2] as a mandatory ACPI table that specifies the
> configuration of serial console.
Hi Rafael,
Could you pull these patches please?
Each of them is ACKed now.
Thank you
Aleksey Makarov
> Move "earlycon" early_param handling to earlycon.c to parse this option once
>
> Parse SPCR table, setup earlycon and register specified console.
>
> Enable parsing this table on ARM64. Earlycon should be set up as early as
> possible. ACPI boot tables are mapped in
> arch/arm64/kernel/acpi.c:acpi_boot_table_init() called from setup_arch() and
> that's where we parse spcr. So it has to be opted-in per-arch. When
> ACPI_SPCR_TABLE is defined initialization of DT earlycon is deferred until the
> DT/ACPI decision is done.
>
> Implement console_match() for pl011.
>
> Based on the work by Leif Lindholm [3]
> Thanks to Peter Hurley for explaining how this should work.
>
> Should be applied to v4.8-rc5
> Tested on QEMU and ThunderX.
> SPCR support is included in QEMU's ARM64 mach-virt since 2.4 release.
>
> v10:
> - rebase to v4.8-rc5
> - fix the issue with comparing the console name in pl011_console_match()
> (Russell King)
> - fix build on sh arch (kbuild test robot)
> - add Acked-by: Russell King <rmk+kernel@armlinux.org.uk> for 4/4
> - add Tested-by: Christopher Covington <cov@codeaurora.org>
>
> v9:
> https://lkml.kernel.org/g/20160811153152.755-1-aleksey.makarov at linaro.org
> - rebase to v4.8-rc1
> - fix compilation for !CONFIG_SERIAL_EARLYCON case
> - add Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> for ACPI part
> - move constant check out of loop (Yury Norov)
> - add '\n' to info message
>
> v8:
> https://lkml.kernel.org/g/1463749405-11640-1-git-send-email-aleksey.makarov at linaro.org
> - rebase to next-20160520
> - remove the patch "ACPICA: Headers: Add new constants for the DBG2 ACPI table"
> as it have got to linux-next
> - add Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Reviewed-by:
> Peter Hurley <peter@hurleysoftware.com> (but see below)
> - fix the patch "serial: pl011: add console matching function". The patch by
> Christopher Covington [4] specifies that SBSA uart does 32-bit access to
> registers and this breaks the match function. In this series the function
> was changed to match when SPCR specifies both mmio32 and mmio access.
> I removed Acked-by: Greg from this patch because of these changes.
>
> v7:
> https://lkml.kernel.org/g/1459431629-27934-1-git-send-email-aleksey.makarov at linaro.org
> - add Acked-by: Rob Herring for "of/serial: move earlycon early_param handling
> to serial"
> - call DT earlycon initialization from the arch ACPI code, not from parse_spcr()
> (Rafael J. Wysocki)
> - fix a few minor issues (Rafael J. Wysocki)
>
> v6:
> https://lkml.kernel.org/g/1458823925-19560-1-git-send-email-aleksey.makarov at linaro.org
> - add documentation for parse_spcr() functioin (Yury Norov)
> - don't initialize err variable (Yury Norov)
> - add __initdata for the earlycon_init_is_deferred flag variable
> - rename the function exported in "of/serial: move earlycon early_param handling
> to serial" to avoid clash with the function from arch/microblaze/kernel/prom.c
> - defer initialization of DT earlycon until DT/ACPI decision is made
> (Rob Herring, Peter Hurley)
> - use snprintf instead of sprintf (Andy Shevchenko)
> - drop patch that adds EARLYCON_DECLARE for pl011 as EARLYCON_DECLARE is
> equivalent to OF_EARLYCON_DECLARE for 4.6+ (Peter Hurley). This means that
> SPCR earlycon will not work on the kernels before 4.6
>
> v5:
> https://lkml.kernel.org/g/1458643595-14719-1-git-send-email-aleksey.makarov at linaro.org
> - drop patch "serial: pl011: use ACPI SPCR to setup 32-bit access" because
> it is ugly. Also because Christopher Covington came with a better solution [4]
> - remove error message when the table is not provided by ACPI (Andy Shevchenko)
> - rewrite spcr.c following the suggestions by Peter Hurley
> - add console_match() for pl011 in a separate patch
> - add EARLYCON_DECLARE for pl011 in a separate patch
> - add patch "of/serial: move earlycon early_param handling to serial" from
> the GDB2 series
>
> v4:
> https://lkml.kernel.org/g/1456747355-15692-1-git-send-email-aleksey.makarov at linaro.org
> - drop patch "ACPI: change __init to __ref for early_acpi_os_unmap_memory()"
> ACPI developers work on a new API and asked not to do that.
> Instead, use acpi_get_table_with_size()/early_acpi_os_unmap_memory() once
> and cache the result. (Lv Zheng)
> - fix some style issues (Yury Norov)
>
> v3:
> https://lkml.kernel.org/g/1455559532-8305-1-git-send-email-aleksey.makarov at linaro.org
>
> Greg Kroah-Hartman did not like v2 so I have rewritten this patchset:
>
> - drop acpi_match() member of struct console
> - drop implementations of this member for pl011 and 8250
> - drop the patch that renames some vars in printk.c as it is not needed anymore
> - drop patch that introduces system wide acpi_table_parse2().
> Instead introduce a custom acpi_table_parse_spcr() in spcr.c
>
> Instead of introducing a new match_acpi() member of struct console,
> this patchset introduces a new function acpi_console_check().
> This function is called when a new uart is registered at serial_core.c
> the same way OF code checks for console. If the registered uart is the
> console specified by SPCR table, this function calls add_preferred_console()
>
> The restrictions of this approach are:
>
> - only serial consoles can be set up
> - only consoles specified by the memory/io address can be set up
> (SPCR can specify devices by PCI id/PCI address)
>
> v2:
> https://lkml.kernel.org/g/1455299022-11641-1-git-send-email-aleksey.makarov at linaro.org
> - don't use SPCR if user specified console in command line
> - fix initialization order of newcon->index = 0
> - rename some variables at printk.c (Joe Perches, Peter Hurley)
> - enable ACPI_SPCR_TABLE in a separate patch (Andy Shevchenko)
> - remove the retry loop for console registering (Peter Hurley).
> Instead, obtain SPCR with acpi_get_table(). That works after
> call to acpi_early_init() i. e. in any *_initcall()
> - describe design decision behind introducing acpi_match() (Peter Hurley)
> - fix compilation for x86 + ACPI (Graeme Gregory)
> - introduce DBG2 constants in a separate patch (Andy Shevchenko)
> - fix a typo in DBG2 constants (Andy Shevchenko)
> - add ACPI_DBG2_ARM_SBSA_32BIT constant (Christopher Covington)
> - add support for ACPI_DBG2_ARM_SBSA_* consoles (Christopher Covington)
> - add documentation for functions
> - add a patch that uses SPCR to find if SBSA serial driver should use 32-bit
> accessor functions (Christopher Covington)
> - change __init to __ref for early_acpi_os_unmap_memory() in a separate patch
> - introduce acpi_table_parse2() in a separate patch
> - fix fetching the SPCR table early (Mark Salter)
> - add a patch from Mark Salter that introduces support for matching 8250-based
> consoles
>
> v1:
> https://lkml.kernel.org/g/1453722324-22407-1-git-send-email-aleksey.makarov at linaro.org
>
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> [2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
> [3] https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org
> [4] https://lkml.kernel.org/g/1457415800-8799-1-git-send-email-cov at codeaurora.org
>
> Aleksey Makarov (3):
> ACPI: parse SPCR and enable matching console
> ARM64: ACPI: enable ACPI_SPCR_TABLE
> serial: pl011: add console matching function
>
> Leif Lindholm (1):
> of/serial: move earlycon early_param handling to serial
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/acpi.c | 11 +++-
> drivers/acpi/Kconfig | 3 ++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/spcr.c | 111 ++++++++++++++++++++++++++++++++++++++++
> drivers/of/fdt.c | 11 +---
> drivers/tty/serial/amba-pl011.c | 55 ++++++++++++++++++++
> drivers/tty/serial/earlycon.c | 19 ++++++-
> include/linux/acpi.h | 6 +++
> include/linux/of_fdt.h | 3 ++
> include/linux/serial_core.h | 9 +++-
> 11 files changed, 216 insertions(+), 14 deletions(-)
> create mode 100644 drivers/acpi/spcr.c
>
^ permalink raw reply
* [PATCH v1 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight
From: Marcel Ziswiler @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dff8d58c4021719184af2c83773e86f175ad910e.1473833908.git.maitysanchayan@gmail.com>
On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> Use enable-gpios property of PWM backlight driver for backlight
> control. While at it also fix the use of brightness levels required
> by EDT displays which require inverted PWM's.
That part I am missing below. Did you forget to include it?
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> ?arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +++++++++
> ?1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 8c67dd8..9100bde 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -49,7 +49,10 @@
> ?
> ? backlight: backlight {
> ? compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_bl_on>;
> ? pwms = <&pwm4 0 5000000>;
> + enable-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
> ? status = "disabled";
> ? };
> ?
> @@ -614,6 +617,12 @@
> ? >;
> ? };
> ?
> + pinctrl_gpio_bl_on: gpioblon {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
> + >;
> + };
> +
> ? pinctrl_gpio_keys: gpio1io04grp {
> ? fsl,pins = <
> ? /* Power button */
^ permalink raw reply
* [PATCH v1 2/3] ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
From: Marcel Ziswiler @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6111feb57b5fbaa29eeb6ba089bb2824bbf2f8ff.1473833908.git.maitysanchayan@gmail.com>
On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> Remove use of pwm-leds and use the standard /sys/class/pwm
> interface from PWM subsystem.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> ?arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 ----------------------
> ?1 file changed, 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index d99979e..70a3da0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -146,28 +146,6 @@
> ? gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
> ? };
> ? };
> -
> - pwmleds {
> - compatible = "pwm-leds";
> -
> - ledpwm1 {
> - label = "PWM1";
> - pwms = <&pwm1 0 50000>;
> - max-brightness = <255>;
> - };
> -
> - ledpwm2 {
> - label = "PWM2";
> - pwms = <&pwm2 0 50000>;
> - max-brightness = <255>;
> - };
> -
> - ledpwm3 {
> - label = "PWM3";
> - pwms = <&pwm3 0 50000>;
> - max-brightness = <255>;
> - };
> - };
> ?};
> ?
> ?&backlight {
Tested working fine analogous to what we documented for Vybrid:
http://developer.toradex.com/knowledge-base/pwm-(linux)#Colibri_VFxx
^ permalink raw reply
* [PATCH RFC 8/8] ARM: dts: sk-rzg1m: initial device tree
From: Sergei Shtylyov @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Add the initial device tree for the R8A7743 SoC based SK-RZG1M board.
The board has one debug serial port (SCIF0); include support for it, so
that the serial console can work.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 44 +++++++++++++++++++++++++++++++++
2 files changed, 45 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -654,6 +654,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r7s72100-rskrza1.dtb \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
+ r8a7743-sk-rzg1m.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for the SK-RZG1M board
+ *
+ * Copyright (C) 2016 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
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7743.dtsi"
+
+/ {
+ model = "SK-RZG1M";
+ compatible = "renesas,sk-rzg1m", "renesas,r8a7743";
+
+ aliases {
+ serial0 = &scif0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+
+ memory at 200000000 {
+ device_type = "memory";
+ reg = <2 0x00000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif0 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH v1 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: Marcel Ziswiler @ 2016-09-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d2c17aa2e00e6ff4349a53de8247860d2382607.1473833908.git.maitysanchayan@gmail.com>
On Wed, 2016-09-14 at 12:05 +0530, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> ---
> Hello,
>
> This patch is tested with the following patch applied
> https://patchwork.kernel.org/patch/9296883/
>
> and is based on the suggestions from Vladimir
> https://lkml.org/lkml/2016/8/29/322
>
> This and following two patches are based on top of shawn's
> for-next branch.
>
> Regards,
> Sanchayan.
> ---
> ?arch/arm/boot/dts/imx6q-apalis-ixora.dts |??6 ------
> ?arch/arm/boot/dts/imx6qdl-apalis.dtsi????| 25 +++++++++-------------
> ---
> ?2 files changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..d99979e 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,7 +55,6 @@
> ? ?????"fsl,imx6q";
> ?
> ? aliases {
> - i2c0 = &i2cddc;
> ? i2c1 = &i2c1;
> ? i2c2 = &i2c2;
> ? i2c3 = &i2c3;
I would suggest rising them up in rank.
> @@ -186,11 +185,6 @@
> ?};
> ?
> ?&hdmi {
> - ddc-i2c-bus = <&i2cddc>;
> - status = "okay";
> -};
> -
> -&i2cddc {
> ? status = "okay";
> ?};
> ?
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
> ? status = "disabled";
> ? };
> ?
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c at 0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_i2c_ddc>;
> - gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
> - ?&gpio2 30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>; /* ~100 kHz */
> - status = "disabled";
> - };
> -
> ? reg_1p8v: regulator-1p8v {
> ? compatible = "regulator-fixed";
> ? regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
> ? };
> ?};
> ?
> +&hdmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hdmi_ddc>;
> + status = "disabled";
> +};
> +
> ?/*
> ? * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
> ? * board)
> @@ -633,11 +627,10 @@
> ? >;
> ? };
> ?
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
> ? fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL
> 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA
> 0x4001b8b1
> ? >;
> ? };
?
Rest looks fine and tested working fine on top of 4.8.0-rc6-next-20160916.
^ permalink raw reply
* [PATCH RFC 7/8] ARM: dts: r8a7743: add [H]SCIF support
From: Sergei Shtylyov @ 2016-09-16 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Describe [H]SCIFs in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 262 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 262 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -154,6 +154,268 @@
dma-channels = <15>;
};
+ scifa0: serial at e6c40000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c40000 0 64>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFA0>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>,
+ <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa1: serial at e6c50000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c50000 0 64>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFA1>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x25>, <&dmac0 0x26>,
+ <&dmac1 0x25>, <&dmac1 0x26>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa2: serial at e6c60000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c60000 0 64>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFA2>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x27>, <&dmac0 0x28>,
+ <&dmac1 0x27>, <&dmac1 0x28>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa3: serial at e6c70000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c70000 0 64>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp11_clks R8A7743_CLK_SCIFA3>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1b>, <&dmac0 0x1c>,
+ <&dmac1 0x1b>, <&dmac1 0x1c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa4: serial at e6c78000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c78000 0 64>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp11_clks R8A7743_CLK_SCIFA4>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1f>, <&dmac0 0x20>,
+ <&dmac1 0x1f>, <&dmac1 0x20>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa5: serial at e6c80000 {
+ compatible = "renesas,scifa-r8a7743",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c80000 0 64>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp11_clks R8A7743_CLK_SCIFA5>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x23>, <&dmac0 0x24>,
+ <&dmac1 0x23>, <&dmac1 0x24>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb0: serial at e6c20000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c20000 0 64>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFB0>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb1: serial at e6c30000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c30000 0 64>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFB1>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x19>, <&dmac0 0x1a>,
+ <&dmac1 0x19>, <&dmac1 0x1a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb2: serial at e6ce0000 {
+ compatible = "renesas,scifb-r8a7743",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6ce0000 0 64>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp2_clks R8A7743_CLK_SCIFB2>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1d>, <&dmac0 0x1e>,
+ <&dmac1 0x1d>, <&dmac1 0x1e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif0: serial at e6e60000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e60000 0 64>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF0>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+ <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif1: serial at e6e68000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e68000 0 64>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF1>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+ <&dmac1 0x2d>, <&dmac1 0x2e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif2: serial at e6e58000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e58000 0 64>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF2>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+ <&dmac1 0x2b>, <&dmac1 0x2c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif3: serial at e6ea8000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ea8000 0 64>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF3>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+ <&dmac1 0x2f>, <&dmac1 0x30>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif4: serial at e6ee0000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif",
+ "renesas,scif";
+ reg = <0 0xe6ee0000 0 64>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF4>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfb>, <&dmac0 0xfc>,
+ <&dmac1 0xfb>, <&dmac1 0xfc>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif5: serial at e6ee8000 {
+ compatible = "renesas,scif-r8a7743",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee8000 0 64>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_SCIF5>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfd>, <&dmac0 0xfe>,
+ <&dmac1 0xfd>, <&dmac1 0xfe>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif0: serial at e62c0000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c0000 0 96>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_HSCIF0>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+ <&dmac1 0x39>, <&dmac1 0x3a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif1: serial at e62c8000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c8000 0 96>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_HSCIF1>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+ <&dmac1 0x4d>, <&dmac1 0x4e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif2: serial at e62d0000 {
+ compatible = "renesas,hscif-r8a7743",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62d0000 0 96>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp7_clks R8A7743_CLK_HSCIF2>, <&zs_clk>,
+ <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x3b>, <&dmac0 0x3c>,
+ <&dmac1 0x3b>, <&dmac1 0x3c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks at e6150000 {
compatible = "renesas,r8a7743-cpg-clocks",
^ permalink raw reply
* [PATCH RFC 6/8] ARM: dts: r8a7743: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-09-16 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -90,6 +90,70 @@
#power-domain-cells = <1>;
};
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&mstp2_clks R8A7743_CLK_SYS_DMAC0>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&mstp2_clks R8A7743_CLK_SYS_DMAC1>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks at e6150000 {
compatible = "renesas,r8a7743-cpg-clocks",
^ permalink raw reply
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
From: Alban Browaeys @ 2016-09-16 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBEBC8.7000209@arm.com>
Le vendredi 16 septembre 2016 ? 13:55 +0100, Marc Zyngier a ?crit?:
> At that stage, I'm not sure I should care. Does the workaround make
> your
> platform usable?
However awkward this was all about logs and clearing worries. There was
no change in behavior ?between the three cases : upstream, upstream
commit reverted and patched upstream.
Mind this hardware (the Odroid U2) has no hardware buttons. Only power
on plug.
Best regards,
Alban
^ permalink raw reply
* [PATCH RFC 5/8] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-09-16 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 210 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 210 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,210 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 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
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-clock.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg_clocks R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ cpu1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ clock-frequency = <1500000000>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU1>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller at 0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller at f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ sysc: system-controller at e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x0200>;
+ #power-domain-cells = <1>;
+ };
+
+ /* Special CPG clocks */
+ cpg_clocks: cpg_clocks at e6150000 {
+ compatible = "renesas,r8a7743-cpg-clocks",
+ "renesas,rcar-gen2-cpg-clocks";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk &usb_extal_clk>;
+ #clock-cells = <1>;
+ clock-output-names = "main", "pll0", "pll1", "pll3",
+ "lb", "qspi", "sdh", "sd0", "z",
+ "rcan";
+ #power-domain-cells = <0>;
+ };
+
+ /* Fixed factor clocks */
+ pll1_div2_clk: pll1_div2 {
+ compatible = "fixed-factor-clock";
+ clocks = <&cpg_clocks R8A7743_CLK_PLL1>;
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ zs_clk: zs {
+ compatible = "fixed-factor-clock";
+ clocks = <&cpg_clocks R8A7743_CLK_PLL1>;
+ #clock-cells = <0>;
+ clock-div = <6>;
+ clock-mult = <1>;
+ };
+ p_clk: p {
+ compatible = "fixed-factor-clock";
+ clocks = <&cpg_clocks R8A7743_CLK_PLL1>;
+ #clock-cells = <0>;
+ clock-div = <24>;
+ clock-mult = <1>;
+ };
+ mp_clk: mp {
+ compatible = "fixed-factor-clock";
+ clocks = <&pll1_div2_clk>;
+ #clock-cells = <0>;
+ clock-div = <15>;
+ clock-mult = <1>;
+ };
+
+ /* Gate clocks */
+ mstp2_clks: mstp2_clks at e6150138 {
+ compatible = "renesas,r8a7743-mstp-clocks",
+ "renesas,cpg-mstp-clocks";
+ reg = <0 0xe6150138 0 4>, <0 0xe6150040 0 4>;
+ clocks = <&mp_clk>, <&mp_clk>, <&mp_clk>, <&mp_clk>,
+ <&mp_clk>, <&mp_clk>, <&zs_clk>, <&zs_clk>;
+ #clock-cells = <1>;
+ clock-indices = <
+ R8A7743_CLK_SCIFA2 R8A7743_CLK_SCIFA1
+ R8A7743_CLK_SCIFA0 R8A7743_CLK_SCIFB0
+ R8A7743_CLK_SCIFB1 R8A7743_CLK_SCIFB2
+ R8A7743_CLK_SYS_DMAC1 R8A7743_CLK_SYS_DMAC0
+ >;
+ clock-output-names =
+ "scifa2", "scifa1", "scifa0",
+ "scifb0", "scifb1", "scifb2",
+ "sys-dmac1", "sys-dmac0";
+ };
+ mstp7_clks: mstp7_clks at e615014c {
+ compatible = "renesas,r8a7743-mstp-clocks",
+ "renesas,cpg-mstp-clocks";
+ reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
+ clocks = <&zs_clk>, <&p_clk>, <&p_clk>, <&zs_clk>,
+ <&zs_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+ <&p_clk>;
+ #clock-cells = <1>;
+ clock-indices = <
+ R8A7743_CLK_HSCIF2 R8A7743_CLK_SCIF5
+ R8A7743_CLK_SCIF4 R8A7743_CLK_HSCIF1
+ R8A7743_CLK_HSCIF0 R8A7743_CLK_SCIF3
+ R8A7743_CLK_SCIF2 R8A7743_CLK_SCIF1
+ R8A7743_CLK_SCIF0
+ >;
+ clock-output-names =
+ "hscif2", "scif5", "scif4", "hscif1", "hscif0",
+ "scif3", "scif2", "scif1", "scif0";
+ };
+ mstp11_clks: mstp11_clks at e615099c {
+ compatible = "renesas,r8a7743-mstp-clocks",
+ "renesas,cpg-mstp-clocks";
+ reg = <0 0xe615099c 0 4>, <0 0xe61509ac 0 4>;
+ clocks = <&mp_clk>, <&mp_clk>, <&mp_clk>;
+ #clock-cells = <1>;
+ clock-indices = <
+ R8A7743_CLK_SCIFA3 R8A7743_CLK_SCIFA4
+ R8A7743_CLK_SCIFA5
+ >;
+ clock-output-names = "scifa3", "scifa4", "scifa5";
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overriden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ permalink raw reply
* [PATCH v9 08/10] arm64: pmu: Detect and enable multiple PMUs in an ACPI system
From: Punit Agrawal @ 2016-09-16 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473892358-22574-9-git-send-email-jeremy.linton@arm.com>
Jeremy Linton <jeremy.linton@arm.com> writes:
> Its possible that an ACPI system has multiple CPU types in it
> with differing PMU counters. Iterate the CPU's and make a determination
> about how many of each type exist in the system. Then take and create
> a PMU platform device for each type, and assign it the interrupts parsed
> from the MADT. Creating a platform device is necessary because the PMUs
> are not described as devices in the DSDT table.
>
> This code is loosely based on earlier work by Mark Salter.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/perf/arm_pmu.c | 8 +-
> drivers/perf/arm_pmu_acpi.c | 224 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 231 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 63f16a5..47ab4e9 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -1074,7 +1074,13 @@ int arm_pmu_device_probe(struct platform_device *pdev,
> if (!ret)
> ret = init_fn(pmu);
> } else if (probe_table) {
> - ret = probe_plat_pmu(pmu, probe_table, read_cpuid_id());
> + if (acpi_disabled) {
> + /* use the current cpu. */
> + ret = probe_plat_pmu(pmu, probe_table,
> + read_cpuid_id());
> + } else {
> + ret = probe_plat_pmu(pmu, probe_table, pdev->id);
> + }
> }
>
> if (ret) {
> diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
> index dbd4e10..7c56ee4 100644
> --- a/drivers/perf/arm_pmu_acpi.c
> +++ b/drivers/perf/arm_pmu_acpi.c
> @@ -2,13 +2,17 @@
> * ARM ACPI PMU support
> *
> * Copyright (C) 2015 Red Hat Inc.
> + * Copyright (C) 2016 ARM Ltd.
> * Author: Mark Salter <msalter@redhat.com>
> + * Jeremy Linton <jeremy.linton@arm.com>
> *
> * This work is licensed under the terms of the GNU GPL, version 2. See
> * the COPYING file in the top-level directory.
> *
> */
>
> +#define pr_fmt(fmt) "ACPI-PMU: " fmt
> +
> #include <asm/cpu.h>
> #include <linux/acpi.h>
> #include <linux/irq.h>
> @@ -23,6 +27,12 @@ struct pmu_irq {
> bool registered;
> };
>
> +struct pmu_types {
> + struct list_head list;
> + int cpu_type;
Apologies for not noticing this earlier but cpu_type should be u32 to
match partnum (which is derived from reg_midr).
> + int cpu_count;
> +};
> +
> static struct pmu_irq pmu_irqs[NR_CPUS];
>
> /*
> @@ -38,3 +48,217 @@ void __init arm_pmu_parse_acpi(int cpu, struct acpi_madt_generic_interrupt *gic)
> else
> pmu_irqs[cpu].trigger = ACPI_LEVEL_SENSITIVE;
> }
> +
> +static void __init arm_pmu_acpi_handle_alloc_failure(struct list_head *pmus)
> +{
> + struct pmu_types *pmu, *safe_temp;
> +
> + list_for_each_entry_safe(pmu, safe_temp, pmus, list) {
> + list_del(&pmu->list);
> + kfree(pmu);
> + }
> +}
> +
> +/* Count number and type of CPU cores in the system. */
> +static bool __init arm_pmu_acpi_determine_cpu_types(struct list_head *pmus)
> +{
> + int i;
> + bool unused_madt_entries = false;
> +
> + for_each_possible_cpu(i) {
> + struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
> + u32 partnum = MIDR_PARTNUM(cinfo->reg_midr);
> + struct pmu_types *pmu;
> +
> + if (cinfo->reg_midr == 0) {
When can the above condition be true? Worth a comment.
> + unused_madt_entries = true;
> + continue;
> + }
> +
> + list_for_each_entry(pmu, pmus, list) {
> + if (pmu->cpu_type == partnum) {
> + pmu->cpu_count++;
> + break;
> + }
> + }
> +
> + /* we didn't find the CPU type, add an entry to identify it */
> + if (&pmu->list == pmus) {
> + pmu = kzalloc(sizeof(struct pmu_types), GFP_KERNEL);
> + if (!pmu) {
> + pr_err("Unable to allocate pmu_types\n");
> + /*
> + * Instead of waiting to cleanup possible
> + * allocation failures in the caller clean
> + * them up immediately. Functionally this
> + * doesn't make any difference, except in
> + * genuine heterogeneous systems where it
> + * guarantees the whole subsystem is
> + * disabled rather than running with just
> + * a single set of homogeneous CPU's PMU
> + * active. That assumes there aren't
> + * any further memory allocation failures.
> + */
> + arm_pmu_acpi_handle_alloc_failure(pmus);
> + break;
> + } else {
> + pmu->cpu_type = partnum;
> + pmu->cpu_count++;
> + list_add_tail(&pmu->list, pmus);
> + }
> + }
> + }
> +
> + return unused_madt_entries;
> +}
> +
> +/*
> + * Registers the group of PMU interfaces which correspond to the 'last_cpu_id'.
> + * This group utilizes 'count' resources in the 'res'.
> + */
> +static int __init arm_pmu_acpi_register_pmu(int count, struct resource *res,
> + int last_cpu_id)
> +{
> + int i;
> + int err = -ENOMEM;
> + bool free_gsi = false;
> + struct platform_device *pdev;
> +
> + if (count) {
> + pdev = platform_device_alloc(ARMV8_PMU_PDEV_NAME, last_cpu_id);
> + if (pdev) {
> + err = platform_device_add_resources(pdev, res, count);
> + if (!err) {
> + err = platform_device_add(pdev);
> + if (err) {
> + pr_warn("Unable to register PMU device\n");
> + free_gsi = true;
> + }
> + } else {
> + pr_warn("Unable to add resources to device\n");
> + free_gsi = true;
> + platform_device_put(pdev);
> + }
> + } else {
> + pr_warn("Unable to allocate platform device\n");
> + free_gsi = true;
> + }
> + }
The above if block is quite hard to review. I've had the same comment on
previous versions as well.
> +
> + /* unmark (and possibly unregister) registered GSIs */
> + for_each_possible_cpu(i) {
> + if (pmu_irqs[i].registered) {
> + if (free_gsi)
> + acpi_unregister_gsi(pmu_irqs[i].gsi);
> + pmu_irqs[i].registered = false;
> + }
> + }
> +
> + return err;
> +}
> +
> +int arm_pmu_acpi_retrieve_irq(struct resource *res, int cpu)
The return value of this function isn't used anywhere. Any reason it
can't be void?
> +{
> + int irq = -ENODEV;
> +
> + if (pmu_irqs[cpu].registered) {
> + pr_info("CPU %d's interrupt is already registered\n", cpu);
> + } else {
> + irq = acpi_register_gsi(NULL, pmu_irqs[cpu].gsi,
> + pmu_irqs[cpu].trigger,
> + ACPI_ACTIVE_HIGH);
> + pmu_irqs[cpu].registered = true;
> + res->start = irq;
> + res->end = irq;
> + res->flags = IORESOURCE_IRQ;
> + if (pmu_irqs[cpu].trigger == ACPI_EDGE_SENSITIVE)
> + res->flags |= IORESOURCE_IRQ_HIGHEDGE;
> + else
> + res->flags |= IORESOURCE_IRQ_HIGHLEVEL;
> + }
> + return irq;
> +}
> +
> +/*
> + * For the given cpu/pmu type, walk all known GSIs, register them, and add
> + * them to the resource structure. Return the number of GSI's contained
> + * in the res structure, and the id of the last CPU/PMU we added.
> + */
> +static int __init arm_pmu_acpi_gsi_res(struct pmu_types *pmus,
> + struct resource *res, int *last_cpu_id)
> +{
> + int i, count;
> +
> + /* lets group all the PMU's from similar CPU's together */
> + count = 0;
> + for_each_possible_cpu(i) {
> + struct cpuinfo_arm64 *cinfo = per_cpu_ptr(&cpu_data, i);
> +
> + if (pmus->cpu_type == MIDR_PARTNUM(cinfo->reg_midr)) {
> + if ((pmu_irqs[i].gsi == 0) && (cinfo->reg_midr != 0)) {
> + pr_info("CPU %d is assigned interrupt 0\n", i);
> + continue;
> + }
> + /* likely not online */
> + if (!cinfo->reg_midr)
> + continue;
> +
> + arm_pmu_acpi_retrieve_irq(&res[count], i);
> + count++;
> + (*last_cpu_id) = cinfo->reg_midr;
> + }
> + }
> + return count;
> +}
> +
> +static int __init pmu_acpi_init(void)
> +{
> + struct resource *res;
> + int err = -ENOMEM;
> + int count, cpu_id;
> + struct pmu_types *pmu, *safe_temp;
> + bool unused_madt_entries;
> + LIST_HEAD(pmus);
> +
> + if (acpi_disabled)
> + return 0;
> +
> + unused_madt_entries = arm_pmu_acpi_determine_cpu_types(&pmus);
> +
> + list_for_each_entry_safe(pmu, safe_temp, &pmus, list) {
> + if (unused_madt_entries)
> + pmu->cpu_count = num_possible_cpus();
So if there is any unbooted cpu ...
> +
> + res = kcalloc(pmu->cpu_count,
> + sizeof(struct resource), GFP_KERNEL);
... we allocate potentially large number (num_possible_cpus()) of
resources for each PMU.
This is needlessly wasteful. Under what conditions have you found
reg_midr to be 0?
> +
> + /* for a given PMU type collect all the GSIs. */
> + if (res) {
> + count = arm_pmu_acpi_gsi_res(pmu, res,
> + &cpu_id);
> + /*
> + * register this set of interrupts
> + * with a new PMU device
> + */
> + if (count) {
> + if (unused_madt_entries)
> + count = num_possible_cpus();
> + err = arm_pmu_acpi_register_pmu(count, res,
> + cpu_id);
> + if (!err)
> + pr_info("Register %d devices for %X\n",
> + count, pmu->cpu_type);
> + kfree(res);
> + }
> + } else {
> + pr_warn("PMU unable to allocate interrupt resource\n");
> + }
> +
> + list_del(&pmu->list);
> + kfree(pmu);
> + }
> +
> + return err;
> +}
> +
> +arch_initcall(pmu_acpi_init);
^ permalink raw reply
* [PATCH RFC 4/8] ARM: shmobile: r8a7743: basic SoC support
From: Sergei Shtylyov @ 2016-09-16 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3533019.Wim1Kuh1ic@wasted.cogentembedded.com>
Add minimal support for the RZ/G1M (R8A7743) SoC.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/mach-shmobile/Kconfig | 5 ++++
arch/arm/mach-shmobile/Makefile | 1
arch/arm/mach-shmobile/setup-r8a7743.c | 34 +++++++++++++++++++++++++++++++++
3 files changed, 40 insertions(+)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -68,6 +68,11 @@ config ARCH_R8A7740
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN
+config ARCH_R8A7743
+ bool "RZ/G1M (R8A77430)"
+ select ARCH_RCAR_GEN2
+ select I2C
+
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
Index: renesas/arch/arm/mach-shmobile/Makefile
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Makefile
+++ renesas/arch/arm/mach-shmobile/Makefile
@@ -9,6 +9,7 @@ obj-y := timer.o
obj-$(CONFIG_ARCH_SH73A0) += setup-sh73a0.o
obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
+obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
Index: renesas/arch/arm/mach-shmobile/setup-r8a7743.c
===================================================================
--- /dev/null
+++ renesas/arch/arm/mach-shmobile/setup-r8a7743.c
@@ -0,0 +1,34 @@
+/*
+ * r8a7743 processor support
+ *
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation; of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/init.h>
+
+#include <asm/mach/arch.h>
+
+#include "common.h"
+#include "rcar-gen2.h"
+
+static const char * const r8a7743_boards_compat_dt[] __initconst = {
+ "renesas,r8a7743",
+ NULL,
+};
+
+DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_time = rcar_gen2_timer_init,
+ .init_late = shmobile_init_late,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = r8a7743_boards_compat_dt,
+MACHINE_END
^ permalink raw reply
* [PATCH v7 0/5] mfd: tps65218: Clean ups
From: Mark Brown @ 2016-09-16 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab94aff0-8470-57e5-2039-12f09bb0ca33@ti.com>
On Fri, Sep 16, 2016 at 05:12:38PM +0530, Keerthy wrote:
> Should i repost this series? I do not see this series in linux-next yet.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, though there are some other maintainers who like them - if in
doubt look at how patches for the subsystem are normally handled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/aff69cd5/attachment.sig>
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Christoffer Dall @ 2016-09-16 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da8191ca-6fb1-f960-872c-d6bc27172db8@redhat.com>
On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
>
>
> On 16/09/2016 14:30, Christoffer Dall wrote:
> > > > > This patch set allows user space to receive vtimer events as well as mask
> > > > > them, so that we can handle all vtimer related interrupt injection from user
> > > > > space, enabling us to use architected timer with user space gic emulation.
> > > >
> > > > I have already voiced my concerns in the past, including face to face,
> > > > and I'm going to repeat it: I not keen at all on adding a new userspace
> > > > interface that is going to bitrot extremely quickly.
> > >
> > > You don't have automated tests set up? It's not going to bitrot if you
> > > test it, either with kvm-unit-tests or just by smoke-testing Linux.
> > > It's _for_ the raspi, but it's not limited to it.
> >
> > Our automated testing situation is not great, no. Something we're
> > looking at, but have resource problems with.
>
> But it's not a good reason to hold back a feature...
>
I didn't say that exactly, but choosing not to merge something we cannot
maintain and which we're not paid to look after and where there's a
minimal interest, is not entirely unreasonable.
That being said, I'm not categorically against these patches, but I
share Marc's view that we've already seen that non-vgic support had been
broken for multiple versions without anyone complaining, and without
automated testing or substantial interest in the work, the patches
really are likely to bit-rot.
But I haven't even looked at the patches in detail, I was just replying
to the comment about testing.
-Christoffer
^ permalink raw reply
* [PATCH v9 07/10] arm: arm64: pmu: Assign platform PMU CPU affinity
From: Will Deacon @ 2016-09-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473892358-22574-8-git-send-email-jeremy.linton@arm.com>
On Wed, Sep 14, 2016 at 05:32:35PM -0500, Jeremy Linton wrote:
> On systems with multiple PMU types the PMU to CPU affinity
> needs to be detected and set. The CPU to interrupt affinity
> should also be set.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/perf/arm_pmu.c | 63 ++++++++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 58117d7..63f16a5 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -11,6 +11,7 @@
> */
> #define pr_fmt(fmt) "hw perfevents: " fmt
>
> +#include <linux/acpi.h>
> #include <linux/bitmap.h>
> #include <linux/cpumask.h>
> #include <linux/cpu_pm.h>
> @@ -24,6 +25,7 @@
> #include <linux/irq.h>
> #include <linux/irqdesc.h>
>
> +#include <asm/cpu.h>
> #include <asm/cputype.h>
> #include <asm/irq_regs.h>
>
> @@ -876,25 +878,67 @@ static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
> }
>
> /*
> - * CPU PMU identification and probing.
> + * CPU PMU identification and probing. Its possible to have
> + * multiple CPU types in an ARM machine. Assure that we are
> + * picking the right PMU types based on the CPU in question
> */
> -static int probe_current_pmu(struct arm_pmu *pmu,
> - const struct pmu_probe_info *info)
> +static int probe_plat_pmu(struct arm_pmu *pmu,
> + const struct pmu_probe_info *info,
> + unsigned int pmuid)
> {
> - int cpu = get_cpu();
> - unsigned int cpuid = read_cpuid_id();
> int ret = -ENODEV;
> + int cpu;
> + int aff_ctr = 0;
> + static int duplicate_pmus;
> + struct platform_device *pdev = pmu->plat_device;
> + int irq = platform_get_irq(pdev, 0);
>
> - pr_info("probing PMU on CPU %d\n", cpu);
> + if (irq >= 0 && !irq_is_percpu(irq)) {
> + pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
> + GFP_KERNEL);
> + if (!pmu->irq_affinity)
> + return -ENOMEM;
> + }
>
> + for_each_possible_cpu(cpu) {
> + unsigned int cpuid = read_specific_cpuid(cpu);
> +
> + if (cpuid == pmuid) {
> + cpumask_set_cpu(cpu, &pmu->supported_cpus);
> + if (pmu->irq_affinity) {
> + pmu->irq_affinity[aff_ctr] = cpu;
> + aff_ctr++;
> + }
> + }
> + }
> +
> + /* find the type of PMU given the CPU */
> for (; info->init != NULL; info++) {
> - if ((cpuid & info->mask) != info->cpuid)
> + if ((pmuid & info->mask) != info->cpuid)
> continue;
> ret = info->init(pmu);
> + /*
> + * if this pmu declaration is unspecified and we have
> + * previously found a PMU on this platform then append
> + * a PMU number to the pmu name. This avoids changing
> + * the names of PMUs that are specific to a class of CPUs.
> + * The assumption is that if we match a specific PMU in the
> + * provided pmu_probe_info then it's unique, and another PMU
> + * in the system will match a different entry rather than
> + * needing the _number to assure its unique.
> + */
> + if ((!info->cpuid) && (duplicate_pmus)) {
Hmm, the duplicate_pmus check looks a little odd here. Doesn't it mean
that you'd end up with things like:
"arm,armv8-pmuv3"
"arm,armv8-pmuv3_1"
which looks needlessly fiddly to parse. Is this intentional?
Will
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
From: Marcel Ziswiler @ 2016-09-16 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <97a3d506-35a0-2a15-18ef-2719c0596cc1@mentor.com>
Hi Vladimir
On Mon, 2016-08-29 at 16:28 +0300, Vladimir Zapolskiy wrote:
> Hi Marcel,
>
> On 02/05/2016 06:12 PM, Marcel Ziswiler wrote:
> >
> > From: Petr ?tetiar <ynezz@true.cz>
> >
> > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > Signed-off-by: Petr ?tetiar <ynezz@true.cz>
> > Reviewed-by: Stefan Agner <stefan@agner.ch>
> > ---
> >
> because the change is in mainline now below is kind of out of date
> information, but you may find it helpful.
>
> [snip]
>
> >
> > - fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
> This is not needed.
>
> [snip]
>
> >
> > + /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> > + i2cddc: i2c at 0 {
> > + compatible = "i2c-gpio";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_i2c_ddc>;
> > + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
> > + ?&gpio2 30 GPIO_ACTIVE_HIGH /* scl */
> > + >;
> > + i2c-gpio,delay-us = <2>; /* ~100 kHz */
> > + status = "disabled";
> > + };
> > +
> This is not needed.
>
> [snip]
>
> >
> > + pinctrl_i2c_ddc: gpioi2cddcgrp {
> > + fsl,pins = <
> > + /* DDC bitbang */
> > + MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> > + MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> > + >;
> > + };
> > +
> Practically you don't need this overcomplicated GPIO-based bitbanging
> to emulate I2C, because the DW HDMI controller has a reduced I2C
> controller on board, you may take a look at its support published
> here:
>
> ????http://www.spinics.net/lists/dri-devel/msg116308.html
>
> To utilize it the pads should be set to HDMI function instead of
> I2C or GPIO.
Works nicely indeed, thanks for letting us know.
> --
> With best wishes,
> Vladimir
Best wishes to you too!
Cheers
Marcel
^ permalink raw reply
* [PATCH RFC 0/8] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-09-16 13:26 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 8 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160916-v4.8-rc6' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. Only serial console is supported
for now, no DHCP/NFS support yet, it will be done RSN... :-)
[1/8] ARM: shmobile: r8a7743: add clock index macros
[2/8] ARM: shmobile: r8a7743: add power domain index macros
[3/8] soc: renesas: rcar-sysc: add R8A7743 support
[4/8] ARM: shmobile: r8a7743: basic SoC support
[5/8] ARM: dts: r8a7743: initial SoC device tree
[6/8] ARM: dts: r8a7743: add SYS-DMAC support
[7/8] ARM: dts: r8a7743: add [H]SCIF support
[8/8] ARM: dts: sk-rzg1m: initial device tree
WBR, Sergei
^ permalink raw reply
* genirq: Setting trigger mode 0 for irq 11 failed (txx9_irq_set_type+0x0/0xb8)
From: Krzysztof Kozlowski @ 2016-09-16 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBEBC8.7000209@arm.com>
On Fri, Sep 16, 2016 at 2:55 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> +Krzystof, Kukjin,
>
> On 16/09/16 12:03, Alban Browaeys wrote:
>> Le vendredi 16 septembre 2016 ? 08:51 +0100, Marc Zyngier a ?crit :
>>> Hi Alban,
>>>
>>> On 16/09/16 00:02, Alban Browaeys wrote:
>>>> I am seeing this on arm odroid u2 devicetree :
>>>> genirq: Setting trigger mode 0 for irq 16 failed
>>>> (gic_set_type+0x0/0x64)
>>>
>>> Passing IRQ_TYPE_NONE to a cascading interrupt is risky at best...
>>> Can you point me to the various DTs and their failing interrupts?
>>
>> mine is:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts
>>
>> I got a report of this issue to another odroid :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidx2.dts
>>
>>
>>
>> they both get their settings from :
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412.dtsi
>>
>> relevant in the chain are:
>> - combiner modified:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4x12.dtsi#n460
>
> How wonderful. This section is an utter pile of crap. Really.
> Having 0 as the trigger is illegal, and the valid values are fully
> documented in the GIC binding. No wonder things start breaking.
+CC Marek Szyprowski,
Yes, that is interesting pile. Lately we stomped into it as well... I
started fixing this today but didn't finish it yet.
> And that's from the following stuff:
>
> &pinctrl_0 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x11400000 0x1000>;
> interrupts = <0 47 0>;
> };
>
> &pinctrl_1 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x11000000 0x1000>;
> interrupts = <0 46 0>;
>
> wakup_eint: wakeup-interrupt-controller {
> compatible = "samsung,exynos4210-wakeup-eint";
> interrupt-parent = <&gic>;
> interrupts = <0 32 0>;
> };
> };
>
> [...]
>
> &pinctrl_3 {
> compatible = "samsung,exynos4x12-pinctrl";
> reg = <0x106E0000 0x1000>;
> interrupts = <0 72 0>;
> };
>
> which perpetuates this fine tradition...
>
> At that stage, I'm not sure I should care. Does the workaround make your
> platform usable? The Samsung maintainers should really try and fix their
> DT, because it is a miracle this has made it that far.
Miracle or coincidence. :)
Thanks Geert and Alban for bringing this up, I'll add also yours reported-by.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH -next] clk: zx296718: use builtin_platform_driver to simplify the code
From: Wei Yongjun @ 2016-09-16 13:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Use the builtin_platform_driver() macro to make the code simpler.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/clk/zte/clk-zx296718.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/zte/clk-zx296718.c b/drivers/clk/zte/clk-zx296718.c
index 025e324..b4fe8dd 100644
--- a/drivers/clk/zte/clk-zx296718.c
+++ b/drivers/clk/zte/clk-zx296718.c
@@ -917,8 +917,4 @@ static struct platform_driver zx_clk_driver = {
},
};
-static int __init zx_clkc_init(void)
-{
- return platform_driver_register(&zx_clk_driver);
-}
-device_initcall(zx_clkc_init);
+builtin_platform_driver(zx_clk_driver);
^ 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