* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-10-29 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477696028.31471.3.camel@embedded.rocks>
> J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober 2016 um 01:07
> geschrieben:
>
>
> You mentioned [1] an optimization in the Freescale vendor Linux kernel
> [2]. I would really like to see this optimization in the mainline
> kernel.
>
> Did you ever tried to port this code from Freescale to mainline?
Yes, i tried once but i was frustrated soon because of the lot of required
changes and resulting issues.
>
> Is it even possible, as the mainline driver uses the DMA engine?
I think the more important part would be analyse why the Mainline driver is
slowlier. I mean to exactly identify the bottleneck.
I don't have enough time and equipment for this. I better concentrate on standby
support.
>
> [1] http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-
> 3-mmc-mxs-mmc-implement-ddr-support#post8
> [2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/
> ?h=imx_2.6.35_maintain&id=b09358887fb4b67f6d497fac8cc48475c8bd292d
>
> Best regards,
> J?rg Krause
^ permalink raw reply
* [PATCH v3 1/6] pinctrl: sunxi: Deal with configless pins
From: Linus Walleij @ 2016-10-29 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae812275bfb0f0ded2a73b571bfcecffcd747126.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Even though the our binding had the assumption that the allwinner,pull and
> allwinner,drive properties were optional, the code never took that into
> account.
>
> Fix that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC][PATCH] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Ard Biesheuvel @ 2016-10-29 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a76edf2-3f80-fb18-4fc1-2e0b1f085d20@redhat.com>
On 28 October 2016 at 23:07, Laura Abbott <labbott@redhat.com> wrote:
>>>> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>>>> new file mode 100644
>>>> index 0000000..6c271e2
>>>> --- /dev/null
>>>> +++ b/arch/arm64/mm/physaddr.c
>>>> @@ -0,0 +1,17 @@
>>>> +#include <linux/mm.h>
>>>> +
>>>> +#include <asm/memory.h>
>>>> +
>>>> +unsigned long __virt_to_phys(unsigned long x)
>>>> +{
>>>> + phys_addr_t __x = (phys_addr_t)x;
>>>> +
>>>> + if (__x & BIT(VA_BITS - 1)) {
>>>> + /* The bit check ensures this is the right range */
>>>> + return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>>>> + } else {
>>>> + VIRTUAL_BUG_ON(x < kimage_vaddr || x > (unsigned long)_end);
>>>
>>>
>>> IIUC, in (3) you were asking if the last check should be '>' or '>='?
>>>
>>> To match high_memory, I suspect the latter, as _end doesn't fall within
>>> the mapped virtual address space.
>>>
>>
>> I was actually concerned about if _end would be correct with KASLR.
>> Ard confirmed that it gets fixed up to be correct. I'll change the
>> check to check for >=.
>>
>
> While testing this, I found two places with __pa(_end) to get bounds,
> one in arm64 code and one in memblock code. x86 gets away with this
> because memblock is actually __pa_symbol and x86 does image placement
> different and can check against the maximum image size. I think
> including _end in __pa_symbol but excluding it from the generic
> __virt_to_phys makes sense. It's a bit nicer than doing _end - 1 +
> 1 everywhere.
>
Could we redefine __pa_symbol() under CONFIG_DEBUG_VIRTUAL to
something that checks (x >= kimage_vaddr + TEXT_OFFSET || x <=
(unsigned long)_end), i.e., reject linear virtual addresses? (Assuming
my understanding of the meaning of __pa_symbol() is correct)
^ permalink raw reply
* pinctrl: mediatek: build failure if CONFIG_IRQ_DOMAIN is not set
From: Linus Walleij @ 2016-10-29 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477675233.2167.11.camel@tiscali.nl>
On Fri, Oct 28, 2016 at 7:20 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> 3) Would you like me to submit a proper (but lightly tested) patch or
> do you prefer to fix this yourself?
Please send a tested patch, I'll apply it.
Thanks for finding this!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] video: ARM CLCD: fix Vexpress regression
From: Linus Walleij @ 2016-10-29 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476945992-5164-1-git-send-email-linus.walleij@linaro.org>
On Thu, Oct 20, 2016 at 8:46 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The CLCD does not come up on Versatile Express as it does not
> (currently) have a syscon node for controlling the block apart
> from the CLCD itself. Make sure the .init() function can bail
> out without an error making it probe again.
>
> Reported-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tomi can you please pick this up?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-10-29 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477688219-3871-3-git-send-email-jon.mason@broadcom.com>
On Fri, Oct 28, 2016 at 04:56:55PM -0400, Jon Mason wrote:
> The BCM54810 PHY requires some semi-unique configuration, which results
> in some additional configuration in addition to the standard config.
> Also, some users of the BCM54810 require the PHY lanes to be swapped.
> Since there is no way to detect this, add a device tree query to see if
> it is applicable.
>
> Inspired-by: Vikas Soni <vsoni@broadcom.com>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> drivers/net/phy/Kconfig | 2 +-
> drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/brcmphy.h | 10 ++++++++
Hi Jon
The binding documentation is missing.
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> + /* Lane Swap - Undocumented register...magic! */
> + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> + 0x11B);
> + if (ret < 0)
> + return ret;
> + }
> +
I wounder if this property could be made generic? What exactly are you
swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
Andrew
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: Support DT property for ignoring aborts when probing
From: Rafał Miłecki @ 2016-10-29 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b58db80-c9ff-d4d6-0df1-d80d1c03bc45@broadcom.com>
On 28 October 2016 at 18:58, Ray Jui <ray.jui@broadcom.com> wrote:
> On 10/28/2016 8:31 AM, Rafa? Mi?ecki wrote:
>> On 20 April 2016 at 20:18, Ray Jui <ray.jui@broadcom.com> wrote:
>>> Hi Rafal/Florian/Arnd,
>>>
>>> After a couple days of email exchange with the ASIC team, I think I've
>>> figured out the behavior on all of the Broadcom SoCs that use this iProc
>>> PCIe controller.
>>>
>>> On NSP, Cygnus, and NS2:
>>> - There's an APB error enable register at offset 0xf40 from the iProc PCIe
>>> controller's base address. If one clears bit 0 (enabled by default after
>>> chip POR) of that register, one can stop this from being forwarded to "iProc
>>> host" as an APB error/external imprecise abort
>>> - I will submit a patch to the iProc PCIe driver to disable this error
>>> forwarding
>>>
>>> On NS:
>>> - Unfortunately, there's no such control register in NS. In other words, we
>>> cannot disable this error at the PCIe controller level
>>> - FSR code corresponds to external (bit[12] = '1'), read (bit[11] = '0'),
>>> imprecise abort (bits[10][3:0] = '1''0110'), i.e., external imprecise abort
>>> triggered by read access. Our ASIC team believes a read access to a
>>> non-exist APB register can also trigger an abort with the same FSR code.
>>> Note this is the tricky part, by registering an abort hook that skips this
>>> particular FSR, one has a chance of skipping other aborts triggered by
>>> accessing invalid APB registers. But given that this cannot be disabled for
>>> the PCIe controller NS, I'm not sure what approach we should take. Any
>>> thoughts?
>>
>> It's really late reply but I wanted to finally handle this problem.
>>
>> From Ray's e-mail it seems Northstar is the only platform requiring
>> this workaround. So we don't have to worry about arm64.
>
> Yes, Northstar is the only platform that requires this workaround. Even
> the arm32 platforms like NSP and Cygnus can disable unsupported request
> being forwarded as APB error. I've recently sent out a patch series to
> fix this for all other platforms, and sorry I should have included you
> in the email but I did not. I'll include you when revision 2 is sent out.
>
>>
>> We have two options then:
>> 1) Add workaround in arch/arm/mach-bcm/bcm_5301x.c
>> 2) Add workaround into built-in drivers/pci/host/pcie-iproc-fault.c
>
> How do you plan to implement pcie-iproc-fault.c? If it's similar to what
> you have now, then I think it fits more to bcm_5301x.c
Yes, I just wanted to have a simple file with 2 functions there: one
adding a hook and second being a callback.
--
Rafa?
^ permalink raw reply
* [PATCH v2 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Ding Tianhong @ 2016-10-29 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8267644f-c488-2d02-3dd0-c7d0ed23babf@arm.com>
On 2016/10/27 20:23, Marc Zyngier wrote:
> On 27/10/16 13:17, Ding Tianhong wrote:
>>
>>
>> On 2016/10/27 18:58, Marc Zyngier wrote:
>>> On 27/10/16 08:34, Ding Tianhong wrote:
>>>> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
>>>> potential to contain an erroneous value when the timer value changes".
>>>> Accesses to TVAL (both read and write) are also affected due to the implicit counter
>>>> read. Accesses to CVAL are not affected.
>>>>
>>>> The workaround is to reread the system count registers until the value of the second
>>>> read is larger than the first one by less than 32, the system counter can be guaranteed
>>>> not to return wrong value twice by back-to-back read and the error value is always larger
>>>> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>>>>
>>>> The workaround is enabled if the hisilicon,erratum-161601 property is found in
>>>> the timer node in the device tree. This can be overridden with the
>>>> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
>>>> users to enable the workaround until a mechanism is implemented to
>>>> automatically communicate this information.
>>>>
>>>> Fix some description for fsl erratum a008585.
>>>>
>>>> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
>>>> to another patch, update the erratum name and remove unwanted code.
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> ---
>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>> Documentation/kernel-parameters.txt | 9 ++++
>>>> arch/arm64/include/asm/arch_timer.h | 28 ++++++++++-
>>>> drivers/clocksource/Kconfig | 14 +++++-
>>>> drivers/clocksource/arm_arch_timer.c | 88 ++++++++++++++++++++++++++--------
>>>> 5 files changed, 118 insertions(+), 22 deletions(-)
>>>>
>>>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>>>> index 405da11..70c5d5e 100644
>>>> --- a/Documentation/arm64/silicon-errata.txt
>>>> +++ b/Documentation/arm64/silicon-errata.txt
>>>> @@ -63,3 +63,4 @@ stable kernels.
>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>>>> | | | | |
>>>> | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
>>>> +| Hisilicon | Hip05/Hip06/Hip07 | #161601 | HISILICON_ERRATUM_161601|
>>>
>>> I've already commented on the alignment. Please read my initial review.
>>>
>>
>> It sees misunderstood, fix it this time.
>>
>>>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>>>> index 6fa1d8a..735b4b6 100644
>>>> --- a/Documentation/kernel-parameters.txt
>>>> +++ b/Documentation/kernel-parameters.txt
>>>> @@ -707,6 +707,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>>> erratum. If unspecified, the workaround is
>>>> enabled based on the device tree.
>>>>
>>>> + clocksource.arm_arch_timer.hisilicon-161601=
>>>> + [ARM64]
>>>> + Format: <bool>
>>>> + Enable/disable the workaround of Hisilicon
>>>> + erratum 161601. This can be useful for KVM
>>>> + guests, if the guest device tree doesn't show the
>>>> + erratum. If unspecified, the workaround is
>>>> + enabled based on the device tree.
>>>> +
>>>> clearcpuid=BITNUM [X86]
>>>> Disable CPUID feature X for the kernel. See
>>>> arch/x86/include/asm/cpufeatures.h for the valid bit
>>>> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
>>>> index 118719d8..49b3041 100644
>>>> --- a/arch/arm64/include/asm/arch_timer.h
>>>> +++ b/arch/arm64/include/asm/arch_timer.h
>>>> @@ -29,7 +29,7 @@
>>>>
>>>> #include <clocksource/arm_arch_timer.h>
>>>>
>>>> -#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
>>>> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585) || IS_ENABLED(CONFIG_HISILICON_ERRATUM_161601)
>>>> extern struct static_key_false arch_timer_read_ool_enabled;
>>>> #define needs_timer_erratum_workaround() \
>>>> static_branch_unlikely(&arch_timer_read_ool_enabled)
>>>> @@ -65,11 +65,35 @@ extern struct arch_timer_erratum_workaround *erratum_workaround;
>>>> _new; \
>>>> })
>>>>
>>>> +
>>>> +
>>>> +/*
>>>> + * The number of retries is an arbitrary value well beyond the highest number
>>>> + * of iterations the loop has been observed to take.
>>>> + * Verify whether the value of the second read is larger than the first by
>>>> + * less than 32 is the only way to confirm the value is correct, the system
>>>> + * counter can be guaranteed not to return wrong value twice by back-to-back read
>>>> + * and the error value is always larger than the correct one by 32.
>>>> + */
>>>> +#define __hisi_161601_read_reg(reg) ({ \
>>>> + u64 _old, _new; \
>>>> + int _retries = 200; \
>>>
>>> Please document how this value was found (either in the code or in the
>>> commit message).
>>
>> It really difficult to give the accurate standard, theoretically the error should not happened
>> twice together, so maybe 2 is enough here, I just give a arbitrary value.
>>
>>>
>>>> + \
>>>> + do { \
>>>> + _old = read_sysreg(reg); \
>>>> + _new = read_sysreg(reg); \
>>>> + _retries--; \
>>>> + } while (unlikely((_new - _old) >> 5) && _retries); \
>>>> + \
>>>> + WARN_ON_ONCE(!_retries); \
>>>> + _new; \
>>>> +})
>>>
>>> Same remark as in the previous patch.
>>>
>>
>> I think the sentence *Verify whether the value of the second read is larger than the first by
>> less than 32 is the only way to confirm the value is correct* could explain why should *(_new - _old) >> 5*.
>> it is the same as (_new - _old)/32, also mean the _new should never bigger than _old more than 32.
>
> This is not about the explanation of the erratum, but about the location
> of the #define, which can be made private to the .c file instead of
> being globally visible.
>
Ok, update it .
Thanks
Ding
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH v2 3/4] arm64: arch_timer: Work around Erratum Hisilicon-161601
From: Ding Tianhong @ 2016-10-29 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028160000.GB1076@arm.com>
On 2016/10/29 0:00, Will Deacon wrote:
> Hi Ding,
>
> On Thu, Oct 27, 2016 at 03:34:10PM +0800, Ding Tianhong wrote:
>> Erratum Hisilicon-161601 says that the ARM generic timer counter "has the
>> potential to contain an erroneous value when the timer value changes".
>> Accesses to TVAL (both read and write) are also affected due to the implicit counter
>> read. Accesses to CVAL are not affected.
>>
>> The workaround is to reread the system count registers until the value of the second
>> read is larger than the first one by less than 32, the system counter can be guaranteed
>> not to return wrong value twice by back-to-back read and the error value is always larger
>> than the correct one by 32. Writes to TVAL are replaced with an equivalent write to CVAL.
>>
>> The workaround is enabled if the hisilicon,erratum-161601 property is found in
>> the timer node in the device tree. This can be overridden with the
>> clocksource.arm_arch_timer.hisilicon-161601 boot parameter, which allows KVM
>> users to enable the workaround until a mechanism is implemented to
>> automatically communicate this information.
>>
>> Fix some description for fsl erratum a008585.
>>
>> v2: Significant rework based on feedback, including seperate the fsl erratum a008585
>> to another patch, update the erratum name and remove unwanted code.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>
> [...]
>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 8a753fd..4aafb6a 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -312,8 +312,20 @@ config FSL_ERRATUM_A008585
>> help
>> This option enables a workaround for Freescale/NXP Erratum
>> A-008585 ("ARM generic timer may contain an erroneous
>> - value"). The workaround will only be active if the
>> + value"). The workaround will be active if the
>> fsl,erratum-a008585 property is found in the timer node.
>> + This can be overridden with the clocksource.arm_arch_timer.fsl-a008585
>> + boot parameter.
>> +
>> +config HISILICON_ERRATUM_161601
>> + bool "Workaround for Hisilicon Erratum 161601"
>> + default y
>> + depends on ARM_ARCH_TIMER && ARM64
>> + help
>> + This option enables a workaround for Hisilicon Erratum
>> + 161601. The workaround will be active if the hisilicon,erratum-161601
>> + property is found in the timer node. This can be overridden with
>> + the clocksource.arm_arch_timer.hisilicon-161601 boot parameter.
>
> I'm really not keen on having a kernel commandline parameter for this.
> It's not something we've done for other, similar errata (e.g. CNTFRQ
> reporting the wrong value) and I think it's a slippery slope to having
> more of these workarounds controlled at boot-time. If you have a board
> that is affected by this, it's always going to need the workaround. Why
> would you turn it off?
>
OK, miss it.
> Will
>
> .
>
^ permalink raw reply
* [PATCH 1/1] arm64: dts: msm8996: Add SCM DT node
From: Sarangdhar Joshi @ 2016-10-29 0:14 UTC (permalink / raw)
To: linux-arm-kernel
Add SCM DT node to enable SCM functionality on MSM8996.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 9e960c1..4927097 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -164,6 +164,12 @@
};
+ firmware {
+ scm {
+ compatible = "qcom,scm-msm8996";
+ };
+ };
+
tcsr_mutex: hwlock {
compatible = "qcom,tcsr-mutex";
syscon = <&tcsr_mutex_regs 0 0x1000>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH] fpga zynq: Check the bitstream for validity
From: Moritz Fischer @ 2016-10-29 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028220546.GA19693@obsidianresearch.com>
Jason,
On Fri, Oct 28, 2016 at 04:05:46PM -0600, Jason Gunthorpe wrote:
> On Fri, Oct 28, 2016 at 02:00:15PM -0700, Moritz Fischer wrote:
>
> > > What did you do to get a working bitfile? Are you using one of the
> > > Vivado automatic flows that 'handles' this for you? I am not.
> >
> > https://github.com/EttusResearch/fpgadev/blob/master/usrp3/tools/scripts/viv_utils.tcl#L165
>
> Hm 404
Whooopsie ... that was the internal link. Try that one:
https://github.com/EttusResearch/fpga/blob/master/usrp3/tools/scripts/viv_utils.tcl#L165
It's not a single command but rather a sequence of steps we take to
create an image that works (using write_cfgmem instead of write_binfile)
>
> > Is what our build process does (we set the byte_swap_bin parameter to
> > 1). You're right in that write_bitstream will give you a non-swapped
> > version.
>
> ?? byte_swap_bin is not documented in UG835
>
> > If we reevaluate now that we wanna support swapping we should do this at
> > a framework level. Maybe a preprocess callback or a FPGA_MGR_SWAP flag.
> > I'll need to think about this :-)
>
> I'm perfectly fine with the driver only working with a single canonical
> bitfile format. That seems completly reasonable, and I prefer an
> efficient programming sequence for performance.
>
> Further, eventually this framework is going to have to be fixed to be
> able to DMA out of the page cache and in that world there is no
> sensible option to process the data before sending it on to the
> hardware.
>
> > > So from my perspective, this driver is incompatible with the output of
> > > the Xilinx tools. I don't really care, we always post-process the
> > > output of write_bitfile, and I am happy to provide a canonized
> > > bitstream, but the driver needs to do more to help people get this
> > > right.
> >
> > Ok, so I'm fine with adding the checks and a warning if you don't find
> > the sync word. We could add documentation describing which format we
> > expect.
>
> Maybe you could send a patch to update the comments for the driver, or
> add a documentation file how to produce an acceptable format using
> Xilinx tools..
Yeah will do. I don't know if the generation flow outlined above is perfect,
we just pad our images and I haven't run into issues so far.
> So, the question still remains, should the driver require the header
> be stripped (eg the sync word is the first 4 bytes), or should it
> search the first bit for an aligned sync word?
So currently we don't require it to be stripped, changing it so it does
require stripping would break people's setups that already use the
current implementation.
That being said, I don't like the idea of the driver having to search
either...
Michal, S?ren you guys have a preference / input?
> Either requirement is acceptable to the hardware. My patch does the
> former, I suspect you need the later?
For my usecases I could deal with either way, looking at backwards
compat the latter one would be preferential I supose ...
Cheers,
Moritz
^ permalink raw reply
* [PATCH 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Sarangdhar Joshi @ 2016-10-29 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477699729-18451-1-git-send-email-spjoshi@codeaurora.org>
Add SCM DT bindings for Qualcomm's MSM8996 platform.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 3b4436e..20f26fb 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -10,8 +10,10 @@ Required properties:
* "qcom,scm-apq8064" for APQ8064 platforms
* "qcom,scm-msm8660" for MSM8660 platforms
* "qcom,scm-msm8690" for MSM8690 platforms
+ * "qcom,scm-msm8996" for MSM8996 platforms
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
- clocks: One to three clocks may be required based on compatible.
+ * No clock required for "qcom,scm-msm8996"
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
* Core, iface, and bus clocks required for "qcom,scm"
- clock-names: Must contain "core" for the core clock, "iface" for the interface
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 0/3] Remove clocks dependency from SCM driver
From: Sarangdhar Joshi @ 2016-10-29 0:08 UTC (permalink / raw)
To: linux-arm-kernel
On earlier chiptsets (APQ8064, MSM8660, MSM8690, MSM8916,
APQ8084, MSM8974) crypto operations of TZ were depends on crypto
clocks controlled by users/clients. However on MSM8996 crypto clocks
control is handled internally in TZ itself. The current series of
patches handle this clock dependency in SCM driver.
Sarangdhar Joshi (3):
dt-bindings: firmware: scm: Add MSM8996 DT bindings
firmware: qcom: scm: Remove core, iface and bus clocks dependency
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
.../devicetree/bindings/firmware/qcom,scm.txt | 2 +
drivers/firmware/qcom_scm.c | 65 +++++++++++++++-------
2 files changed, 48 insertions(+), 19 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-10-28 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028233617.GP16026@codeaurora.org>
* Stephen Boyd <sboyd@codeaurora.org> [161028 16:37]:
> On 10/28, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [161028 00:43]:
> > > On 28/10/16 03:50, Stephen Boyd wrote:
> > > > I suppose a PRCM is
> > > > like an MFD that has clocks and resets under it? On other
> > > > platforms we've combined that all into one node and just had
> > > > #clock-cells and #reset-cells in that node. Is there any reason
> > > > we can't do that here?
> > >
> > > For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> > > for example has:
> > >
> > > cm1 @ 0x4a004000 (clocks + clockdomains)
> > > cm2 @ 0x4a008000 (clocks + clockdomains)
> > > prm @ 0x4a306000 (few clocks + resets + power state handling)
> > > scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
> > >
> > > These instances are also under different power/voltage domains which means
> > > their PM behavior is different.
> > >
> > > The idea behind having a clockdomain as a provider was mostly to have the
> > > topology visible : prcm-instance -> clockdomain -> clocks
> >
> > Yeah that's needed to get the interconnect hierarchy right for
> > genpd :)
> >
> > > ... but basically I think it would be possible to drop the clockdomain
> > > representation and just mark the prcm-instance as a clock provider. Tony,
> > > any thoughts on that?
> >
> > No let's not drop the clockdomains as those will be needed when we
> > move things into proper hierarchy within the interconnect instances.
> > This will then help with getting things right with genpd.
> >
> > In the long run we just want to specify clockdomain and the offset of
> > the clock instance within the clockdomain in the dts files.
> >
>
> Sorry, I have very little idea how OMAP hardware works. Do you
> mean that you will have different nodes for each clockdomain so
> that genpd can map 1:1 to the node in dts? But in hardware
> there's a prcm that allows us to control many clock domains
> through register read/writes? How is the interconnect involved?
There are multiple clockdomains, at least one for each interconnect
instance. Once a clockdomain is idle, the related interconnect can
idle too. So yeah genpd pretty much maps 1:1 with the clockdomains.
There's more info in for example omap4 TRM section "3.4.1 Device
Power-Management Layout" that shows the voltage/power/clock domains.
The interconnect instances are mostly named there too looking at
the L4/L3 naming.
Regards,
Tony
^ permalink raw reply
* [PATCHv4 00/15] clk: ti: add support for hwmod clocks
From: Stephen Boyd @ 2016-10-28 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2cfa10a9-9ea0-23e4-30de-9aece13e47e3@ti.com>
On 10/28, Tero Kristo wrote:
> Eventually that should happen. However, we have plenty of legacy
> code still in place which depend on clk_get functionality within
> kernel. The major contributing factor is the hwmod codebase, for
> which we have plans to:
>
> - get this clock driver merged
> - implement a new interconnect driver for OMAP family SoCs
> - interconnect driver will use DT handles for fetching clocks,
> rather than clock aliases
> - reset handling will be implemented as part of the interconnect
> driver somehow (no prototype / clear plans for that as of yet)
> - all the hwmod stuff can be dropped
>
> The clock alias handling is still needed as a transition phase until
> all the above is done, then we can start dropping them. Basically
> anything that is using omap_hwmod depends on the clock aliases right
> now.
Ok, sounds good. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Stephen Boyd @ 2016-10-28 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028125112.xfyrx7l7m64z6cu6@atomide.com>
On 10/28, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [161028 00:43]:
> > On 28/10/16 03:50, Stephen Boyd wrote:
> > > I suppose a PRCM is
> > > like an MFD that has clocks and resets under it? On other
> > > platforms we've combined that all into one node and just had
> > > #clock-cells and #reset-cells in that node. Is there any reason
> > > we can't do that here?
> >
> > For OMAPs, there are typically multiple instances of the PRCM around; OMAP4
> > for example has:
> >
> > cm1 @ 0x4a004000 (clocks + clockdomains)
> > cm2 @ 0x4a008000 (clocks + clockdomains)
> > prm @ 0x4a306000 (few clocks + resets + power state handling)
> > scrm @ 0x4a30a000 (few external clocks + plenty of misc stuff)
> >
> > These instances are also under different power/voltage domains which means
> > their PM behavior is different.
> >
> > The idea behind having a clockdomain as a provider was mostly to have the
> > topology visible : prcm-instance -> clockdomain -> clocks
>
> Yeah that's needed to get the interconnect hierarchy right for
> genpd :)
>
> > ... but basically I think it would be possible to drop the clockdomain
> > representation and just mark the prcm-instance as a clock provider. Tony,
> > any thoughts on that?
>
> No let's not drop the clockdomains as those will be needed when we
> move things into proper hierarchy within the interconnect instances.
> This will then help with getting things right with genpd.
>
> In the long run we just want to specify clockdomain and the offset of
> the clock instance within the clockdomain in the dts files.
>
Sorry, I have very little idea how OMAP hardware works. Do you
mean that you will have different nodes for each clockdomain so
that genpd can map 1:1 to the node in dts? But in hardware
there's a prcm that allows us to control many clock domains
through register read/writes? How is the interconnect involved?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-28 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2003579366.391192.0cc5acd0-af27-4ef7-892f-3c2dd86176ba.open-xchange@email.1und1.de>
On Sat, 2016-10-15 at 18:16 +0200, Stefan Wahren wrote:
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016
> > um 11:41
> > geschrieben:
> >
> >
> >
> >
> > Hi Stefan,
> >
> > Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren
> > <stefan.wahren@i2se.com>:
> > > Hi J?rg,
> > >
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober
> > > > 2016 um
> > >
> > > 10:46
> > > > geschrieben:
> > > >
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > For the record:
> > > >
> > > > Note, this is the result for the wireless interface.
> > > >
> > > > I got one of my custom boards running the legacy Linux Kernel
> > > > 2.6.35
> > > > officially supported from Freescale (NXP) and the bcmdhd driver
> > > > from
> > > > the Wiced project, where I get >20Mbps TCP throughput. The
> > > > firmware
> > > > version reported is:
> > > >
> > > > # wl ver
> > > > 5.90 RC115.2
> > > > wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-
> > > > bc2d0891
> > > >
> > > >
> > > > I got it also running with the Linux Kernel 4.1.15 from
> > > > Freescale
> > >
> > > [2],
> > > > which is not officially supported for the i.MX28 target, with
> > > > the
> > > > latest bcmdhd version where I get <7Mbps TCP throughput (which
> > > > is
> > >
> > > much
> > > > the same I get with the brcmfmac driver). The firmware version
> > >
> > > reported
> > > > is:
> > > >
> > > > # wl ver
> > > > 1.107 RC5.0
> > > > wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
> > > >
> > > > So, probably something is missing in the newer Kernel version,
> > > > which
> > >
> > > is
> > > > present in the legacy Kernel 2.6.35.
> > > >
> > > > [1]
> > >
> > > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?
> > > h=
> > > > imx_2.6.35_1.1.0
> > > > [2]
> > >
> > > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?
> > > h=
> > > > imx_4.1.15_1.0.0_ga
> > >
> > > during implementation of DDR mode for the mmc driver [1] i
> > > noticed a
> > > performance
> > > gap between the vendor kernel and mainline by a factor of 2. I
> > > expect
> > > that your
> > > wireless interface is connected via SDIO.
> >
> > Yes, it is. I had the suspicion that the MMC or the DMA driver is
> > the
> > bootleneck, too.
> >
> > >
> > > [1] -
> > > http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-
> > > 0-3-mmc-mxs-mmc-implement-ddr-support
> >
> > Looks like the patches might help.
>
> Unfortunately not, the performance gain is smaller than expected.
>
> > Have you tried SDIO wifi so far?
>
> No.
You mentioned [1] an optimization in the Freescale vendor Linux kernel
[2]. I would really like to see this optimization in the mainline
kernel.
Did you ever tried to port this code from Freescale to mainline?
Is it even possible, as the mainline driver uses the DMA engine?
[1] http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-
3-mmc-mxs-mmc-implement-ddr-support#post8
[2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/
?h=imx_2.6.35_maintain&id=b09358887fb4b67f6d497fac8cc48475c8bd292d
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCH 11/12] ARM: dts: sk-rzg1e: add Ether support
From: Sergei Shtylyov @ 2016-10-28 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Define the SK-RZG1E board dependent part of the Ether device node.
Enable DHCP and NFS root for the kernel booting.
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/r8a7745-sk-rzg1e.dts | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
+++ renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = "ignore_loglevel";
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = "serial0:115200n8";
};
@@ -37,3 +37,16 @@
&scif2 {
status = "okay";
};
+
+ðer {
+ phy-handle = <&phy1>;
+ renesas,ether-link-active-low;
+ status = "okay";
+
+ phy1: ethernet-phy at 1 {
+ reg = <1>;
+ interrupt-parent = <&irqc>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ micrel,led-mode = <1>;
+ };
+};
^ permalink raw reply
* [PATCH 10/12] ARM: dts: sk-rzg1e: initial device tree
From: Sergei Shtylyov @ 2016-10-28 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Add the initial device tree for the R8A7745 SoC based SK-RZG1E board.
The board has 1 debug serial port (SCIF2); 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/r8a7745-sk-rzg1e.dts | 39 +++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -678,6 +678,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
r8a7743-sk-rzg1m.dtb \
+ r8a7745-sk-rzg1e.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for the SK-RZG1E 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 "r8a7745.dtsi"
+
+/ {
+ model = "SK-RZG1E";
+ compatible = "renesas,sk-rzg1e", "renesas,r8a7745";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif2 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH 10/12] ARM: dts: sk-rzg1e: initial device tree
From: Sergei Shtylyov @ 2016-10-28 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20818256.cBLNrMkA9r@wasted.cogentembedded.com>
On 10/29/2016 01:25 AM, Sergei Shtylyov wrote:
> ---
Oops, no description! :-/
I'll repost.
MBR, Sergei
^ permalink raw reply
* [PATCH 10/12] ARM: dts: sk-rzg1e: initial device tree
From: Sergei Shtylyov @ 2016-10-28 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
---
arch/arm/boot/dts/Makefile | 1
arch/arm/boot/dts/r8a7745-sk-rzg1e.dts | 39 +++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===================================================================
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -678,6 +678,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a73a4-ape6evm.dtb \
r8a7740-armadillo800eva.dtb \
r8a7743-sk-rzg1m.dtb \
+ r8a7745-sk-rzg1e.dtb \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
Index: renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7745-sk-rzg1e.dts
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for the SK-RZG1E 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 "r8a7745.dtsi"
+
+/ {
+ model = "SK-RZG1E";
+ compatible = "renesas,sk-rzg1e", "renesas,r8a7745";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x40000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <20000000>;
+};
+
+&scif2 {
+ status = "okay";
+};
^ permalink raw reply
* [PATCH 08/12] ARM: dts: r8a7745: add IRQC support
From: Sergei Shtylyov @ 2016-10-28 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Describe the IRQC interrupt controller in the R8A7745 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/r8a7745.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -62,6 +62,25 @@
IRQ_TYPE_LEVEL_HIGH)>;
};
+ irqc: interrupt-controller at e61c0000 {
+ compatible = "renesas,irqc-r8a7745", "renesas,irqc";
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ reg = <0 0xe61c0000 0 0x200>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 407>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
^ permalink raw reply
* [PATCH 07/11] ARM: dts: r8a7745: add Ether support
From: Sergei Shtylyov @ 2016-10-28 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Define the generic R8A7745 part of the Ether device node.
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/r8a7745.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -418,6 +418,18 @@
power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
status = "disabled";
};
+
+ ether: ethernet at ee700000 {
+ compatible = "renesas,ether-r8a7745";
+ reg = <0 0xee700000 0 0x400>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ phy-mode = "rmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH 06/11] ARM: dts: r8a7745: add [H]SCIF{A|B} support
From: Sergei Shtylyov @ 2016-10-28 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Describe [H]SCIF{|A|B} ports in the R8A7745 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/r8a7745.dtsi | 261 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 261 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -157,6 +157,267 @@
#dma-cells = <1>;
dma-channels = <15>;
};
+
+ scifa0: serial at e6c40000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rzg-scifa", "renesas,scifa";
+ reg = <0 0xe6c40000 0 0x40>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 204>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>,
+ <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa1: serial at e6c50000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rzg-scifa", "renesas,scifa";
+ reg = <0 0xe6c50000 0 0x40>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 203>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x25>, <&dmac0 0x26>,
+ <&dmac1 0x25>, <&dmac1 0x26>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa2: serial at e6c60000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rzg-scifa", "renesas,scifa";
+ reg = <0 0xe6c60000 0 0x40>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 202>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x27>, <&dmac0 0x28>,
+ <&dmac1 0x27>, <&dmac1 0x28>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa3: serial at e6c70000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rzg-scifa", "renesas,scifa";
+ reg = <0 0xe6c70000 0 0x40>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1106>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1b>, <&dmac0 0x1c>,
+ <&dmac1 0x1b>, <&dmac1 0x1c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa4: serial at e6c78000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rzg-scifa", "renesas,scifa";
+ reg = <0 0xe6c78000 0 0x40>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1107>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1f>, <&dmac0 0x20>,
+ <&dmac1 0x1f>, <&dmac1 0x20>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa5: serial at e6c80000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rzg-scifa", "renesas,scifa";
+ reg = <0 0xe6c80000 0 0x40>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1108>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x23>, <&dmac0 0x24>,
+ <&dmac1 0x23>, <&dmac1 0x24>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb0: serial at e6c20000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rzg-scifb", "renesas,scifb";
+ reg = <0 0xe6c20000 0 0x100>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 206>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb1: serial at e6c30000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rzg-scifb", "renesas,scifb";
+ reg = <0 0xe6c30000 0 0x100>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 207>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x19>, <&dmac0 0x1a>,
+ <&dmac1 0x19>, <&dmac1 0x1a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb2: serial at e6ce0000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rzg-scifb", "renesas,scifb";
+ reg = <0 0xe6ce0000 0 0x100>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 216>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1d>, <&dmac0 0x1e>,
+ <&dmac1 0x1d>, <&dmac1 0x1e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif0: serial at e6e60000 {
+ compatible = "renesas,scif-r8a7745", "renesas,rzg-scif",
+ "renesas,scif";
+ reg = <0 0xe6e60000 0 0x40>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 721>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif1: serial at e6e68000 {
+ compatible = "renesas,scif-r8a7745", "renesas,rzg-scif",
+ "renesas,scif";
+ reg = <0 0xe6e68000 0 0x40>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 720>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif2: serial at e6e58000 {
+ compatible = "renesas,scif-r8a7745", "renesas,rzg-scif",
+ "renesas,scif";
+ reg = <0 0xe6e58000 0 0x40>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 719>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif3: serial at e6ea8000 {
+ compatible = "renesas,scif-r8a7745", "renesas,rzg-scif",
+ "renesas,scif";
+ reg = <0 0xe6ea8000 0 0x40>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 718>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif4: serial at e6ee0000 {
+ compatible = "renesas,scif-r8a7745", "renesas,rzg-scif",
+ "renesas,scif";
+ reg = <0 0xe6ee0000 0 0x40>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 715>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif5: serial at e6ee8000 {
+ compatible = "renesas,scif-r8a7745", "renesas,rzg-scif",
+ "renesas,scif";
+ reg = <0 0xe6ee8000 0 0x40>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 714>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif0: serial at e62c0000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rzg-hscif", "renesas,hscif";
+ reg = <0 0xe62c0000 0 0x60>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 717>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif1: serial at e62c8000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rzg-hscif", "renesas,hscif";
+ reg = <0 0xe62c8000 0 0x60>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 716>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif2: serial at e62d0000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rzg-hscif", "renesas,hscif";
+ reg = <0 0xe62d0000 0 0x60>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 713>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&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 R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH 05/11] ARM: dts: r8a7745: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-10-28 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4121805.SRTmqJtRfv@wasted.cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7745 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/r8a7745.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -93,6 +93,70 @@
compatible = "renesas,r8a7745-rst";
reg = <0 0xe6160000 0 0x0200>;
};
+
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7745",
+ "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 = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7745",
+ "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 = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
^ permalink raw reply
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